1. Trang chủ
  2. » Luận Văn - Báo Cáo

báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông

59 9 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Hệ thống IoT giám sát phương tiện giao thông
Tác giả Trần Thu Mai Anh, Nguyễn Quang Lê Kiên, Trần Trọng Năm, Nguyễn Văn Tuấn
Người hướng dẫn PGS. TS. Nguyễn Đức Minh
Trường học Trường Đại học Bách Khoa Hà Nội
Chuyên ngành Điện - Điện tử
Thể loại Báo cáo đồ án thiết kế thiết bị nhúng
Năm xuất bản 2023
Thành phố Hà Nội
Định dạng
Số trang 59
Dung lượng 10,13 MB

Cấu trúc

  • CHƯƠNG 1. GIỚI THIỆU CHUNG (10)
    • 1.1 Đặt vấn đề (10)
    • 1.2 Tổng quan ứng dụng (11)
  • CHƯƠNG 2. CƠ SỞ LÝ THUYẾT (12)
    • 2.1 Giao tiếp UART (12)
      • 2.1.1 Giới thiệu về chuẩn giao tiếp UART (12)
      • 2.1.2 Nguyên lý hoạt động của UART (13)
      • 2.1.3 Các bước truyền nhận dữ liệu bằng giao tiếp UART (16)
    • 2.2 Giao tiếp I2C (18)
      • 2.2.1 Giới thiệu chung về giao tiếp I2C (18)
      • 2.2.2 Nguyên lý hoạt động (19)
      • 2.2.3 Các chế độ hoạt động của I2C (24)
    • 2.3 Giao tiếp SPI (26)
      • 2.3.1 Giới thiệu chung về giao tiếp SPI (26)
      • 2.3.2 Đặc điểm của giao tiếp SPI (26)
      • 2.3.3 Nguyên lý hoạt động (28)
      • 2.3.4 Các sơ đồ kết nối giao tiếp SPI (29)
    • 2.4 Giao thức MQTT (30)
      • 2.4.1 MQTT (30)
      • 2.4.2 Public, subscribe (30)
      • 2.4.3 Quality of service (QoS) (31)
      • 2.4.4 Retain (31)
      • 2.4.5 MQTT bridge (31)
    • 2.5 Tập lệnh AT (32)
  • CHƯƠNG 3. TỔNG QUAN HỆ THỐNG (34)
    • 3.1 Mô hình hệ thống (34)
    • 3.2 Khối thiết bị (35)
    • 3.3 Khối backend (35)
  • CHƯƠNG 4. TRIỂN KHAI HỆ THỐNG (36)
    • 4.1 Khối thiết bị (36)
      • 4.1.1 Khối xử lý (36)
      • 4.1.2 Khối cảm biến (36)
    • 4.3 Khối truyền thông (40)
    • 4.4 Khối hiển thị (43)
      • 4.4.1 Kiến trúc tổng thể của IoT với Aws (44)
      • 4.4.2 Cấu hình quyền và bảo mật cho các mối quan hệ giữa người dùng và thiết bị IoT (45)
      • 4.4.3 Cấu hình nhận bản tin MQTT (49)
  • CHƯƠNG 5. KẾT QUẢ (54)
    • 5.1 Lấy dữ liệu gia tốc (54)
    • 5.2 Lấy dữ liệu GPS (54)
    • 5.3 Kết nối MQTT (55)
    • 5.4 Giao diện Web (55)
      • 5.4.1 Publish bản tin tới một topic (55)
      • 5.4.2 Giao diện app (58)
  • KẾT LUẬN (59)

Nội dung

CHƯƠNG 2.CƠ SỞ LÝ THUYẾT2.1.1 Giới thiệu về chuẩn giao tiếp UARTUART Universal Asynchronous Receiver - Transmitter – Bộ truyền nhận dữ liệunối tiếp bất đồng bộ là một trong những giao th

GIỚI THIỆU CHUNG

Đặt vấn đề

Trong thời đại công nghệ 4.0 hiện nay, việc sử dụng các thiết bị kết nối Internet đã trở thành xu hướng phổ biến và được áp dụng trong nhiều lĩnh vực khác nhau Trong lĩnh vực giao thông vận tải, việc sử dụng hệ thống IoT (Internet of Things) để theo dõi và quản lý phương tiện di chuyển đang được phát triển rất nhiều Tuy nhiên, vấn đề quản lý xe máy vẫn đang là một thách thức lớn.

Hiện nay, việc quản lý và theo dõi xe máy đang gặp nhiều khó khăn, khiến cho việc đảm bảo an ninh và an toàn giao thông trở nên khó khăn hơn Theo báo cáo của Tổng cục Đường bộ Việt Nam, việc quản lý xe máy vẫn chưa được đảm bảo một cách toàn diện và hiệu quả Đây là một vấn đề đang được quan tâm bởi cả chính phủ và người dân, đặc biệt là khi xe máy là phương tiện di chuyển phổ biến nhất ở Việt Nam. Tình trạng này phần lớn là do các hệ thống quản lý xe máy hiện tại chưa đáp ứng được yêu cầu của người dùng Một số hạn chế của các hệ thống quản lý xe máy hiện tại bao gồm:

− Khả năng theo dõi và quản lý không đáp ứng được nhu cầu thực tế của người dùng.

− Các thiết bị định vị thường bị giảm hiệu suất khi xe di chuyển trong các khu vực có sóng yếu hoặc không có sóng tín hiệu.

− Các thiết bị định vị thường cần thay pin thường xuyên, gây phiền toái cho người dùng.

− Chi phí cho việc lắp đặt và sử dụng hệ thống quản lý xe máy hiện tại còn khá cao và không phù hợp với nhu cầu của người dân.

Với những hạn chế của các hệ thống quản lý xe máy hiện tại, việc áp dụng các giải pháp mới, đặc biệt là các giải pháp sử dụng công nghệ IoT sẽ giúp nâng cao hiệu quả quản lý và theo dõi xe máy.

Hệ thống IoT tracking xe máy là một giải pháp hiện đại, giúp quản lý và theo dõi xe máy một cách hiệu quả Hệ thống này sử dụng các cảm biến để theo dõi vị trí và hoạt động của xe máy, từ đó giúp cung cấp thông tin chi tiết về vị trí, tốc độ và hướng đi của xe máy.

Tổng quan ứng dụng

Thiết bị IoT theo dõi tài sản và phương tiện giao thông là những thiết bị kết nối Internet, được sử dụng để theo dõi và quản lý các tài sản và phương tiện giao thông trong thời gian thực Những thiết bị này có thể được gắn vào bất kỳ tài sản hoặc phương tiện giao thông nào như ô tô, xe máy, container, máy móc, thiết bị y tế, v.v để giúp chủ sở hữu và quản lý tài sản và phương tiện giao thông theo dõi chúng một cách chính xác, nhanh chóng và hiệu quả

Các thiết bị này sử dụng các công nghệ như GPS và các cảm biến để thu thập và truyền tải dữ liệu về vị trí, tốc độ, hướng đi, trạng thái của tài sản và phương tiện giao thông đến các hệ thống quản lý tài sản và phương tiện giao thông Các dữ liệu này được lưu trữ và phân tích để cung cấp thông tin về tình trạng, vị trí, tốc độ và thời gian hoạt động của các tài sản và phương tiện giao thông

Nhờ vào các thiết bị IoT này, chủ sở hữu và quản lý tài sản và phương tiện giao thông có thể giám sát các hoạt động và quản lý chúng một cách chính xác và nhanh chóng Ví dụ, họ có thể theo dõi lộ trình, thời gian vận chuyển, tình trạng sử dụng của phương tiện giao thông và theo dõi tài sản của họ để đảm bảo an toàn và tối ưu hóa hiệu quả sử dụng

Trong tổng thể, thiết bị IoT theo dõi tài sản và phương tiện giao thông đóng một vai trò quan trọng trong việc quản lý tài sản và phương tiện giao thông, giúp chủ sở hữu và quản lý tài sản và phương tiện giao thông tăng cường khả năng quản lý, tối ưu hóa chi phí và nâng cao hiệu suất hoạt động.

CƠ SỞ LÝ THUYẾT

Giao tiếp UART

2.1.1 Giới thiệu về chuẩn giao tiếp UART

UART (Universal Asynchronous Receiver - Transmitter – Bộ truyền nhận dữ liệu nối tiếp bất đồng bộ) là một trong những giao thức truyền thông giữa thiết bị với thiết bị được sử dụng nhiều nhất.

Khi được cấu hình đúng cách, UART có thể hoạt động với nhiều loại giao thức nối tiếp khác nhau liên quan đến việc truyền và nhận dữ liệu nối tiếp Trong giao tiếp nối tiếp, dữ liệu được truyền từng bit bằng cách sử dụng một đường dây Trong giao tiếp hai chiều, chúng ta sử dụng hai dây để truyền dữ liệu nối tiếp thành công Tùy thuộc vào ứng dụng và yêu cầu hệ thống, truyền thông nối tiếp cần ít mạch và dây hơn, điều này làm giảm chi phí thực hiện.

Dưới đây là cách thức hoạt động của giao tiếp UART, các tiêu chuẩn của UART để tối đa hóa khả năng và ứng dụng, đặc biệt là khi phát triển các sản phẩm mới.

Hình 2.1 Cách thức hoạt động giao tiếp UART

Trong giao tiếp UART, hai UART giao tiếp trực tiếp với nhau UART truyền chuyển đổi dữ liệu song song từ một thiết bị điều khiển như CPU thành dạng nối tiếp,truyền nó nối tiếp đến UART nhận, sau đó chuyển đổi dữ liệu nối tiếp trở lại thành dữ liệu song song cho thiết bị nhận.

Hình 2.2 Kết nối chân giao tiếp UART

Thay vì tín hiệu đồng hồ, UART truyền thêm các bit start và stop vào gói dữ liệu được chuyển Các bit này xác định điểm bắt đầu và điểm kết thúc của gói dữ liệu để UART nhận biết khi nào bắt đầu đọc các bit Khi UART nhận phát hiện một bit start, nó bắt đầu đọc các bit đến ở một tần số cụ thể được gọi là tốc độ truyền (baud rate). Tốc độ truyền là thước đo tốc độ truyền dữ liệu, được biểu thị bằng bit trên giây (bps – bit per second) Cả hai UART đều phải hoạt động ở cùng một tốc độ truyền Tốc độ truyền giữa UART truyền và nhận chỉ có thể chênh lệch khoảng 10% trước khi thời gian của các bit bị lệch quá xa Cả hai UART cũng phải được cấu hình để truyền và nhận cùng một cấu trúc gói dữ liệu.

Bảng 2.1 Cấu hình truyền UART

921600, 1000000, 1500000 Phương pháp truyền Bất đồng bộ

Số lượng thiết bị master 1

Số lượng thiết bị slave 1

2.1.2 Nguyên lý hoạt động của UART

UART sẽ truyền dữ liệu nhận được từ một bus dữ liệu (Data Bus) Bus dữ liệu được sử dụng để gửi dữ liệu đến UART bởi một thiết bị khác như CPU, bộ nhớ hoặc vi điều khiển Dữ liệu được chuyển từ bus dữ liệu đến UART truyền ở dạng song song.

Sau khi UART truyền nhận dữ liệu song song từ bus dữ liệu, nó sẽ thêm một bit start, một bit chẵn lẻ và một bit stop, tạo ra gói dữ liệu Tiếp theo, gói dữ liệu được xuất ra nối tiếp từng bit tại chân Tx UART nhận đọc gói dữ liệu từng bit tại chân Rx của nó. UART nhận sau đó chuyển đổi dữ liệu trở lại dạng song song và loại bỏ bit start, bit chẵn lẻ và bit stop Cuối cùng, UART nhận chuyển gói dữ liệu song song với bus dữ liệu ở đầu nhận.

Hình 2.3 Nguyên lý hoạt động của UART

Dữ liệu truyền qua UART được tập hợp thành gói (packet) Mỗi gói chứa 1 bit start, 5 đến 9 bit dữ liệu (tùy thuộc vào UART), một bit chẵn lẻ (parity bit) tùy chọn và

Hình 2.4 Một gói truyền dữ liệu của UART

2.1.2.1Start bit (Bit bắt đầu) Đường truyền dữ liệu UART thường được giữ ở mức điện áp cao khi nó không truyền dữ liệu Để bắt đầu truyền dữ liệu, UART truyền sẽ kéo đường truyền từ mức cao xuống mức thấp trong một chu kỳ đồng hồ Khi UART nhận phát hiện sự chuyển đổi điện áp cao xuống thấp, nó bắt đầu đọc các bit trong khung dữ liệu ở tần số của tốc độ truyền.

2.1.2.2Data Frame (Khung dữ liệu)

Khung dữ liệu chứa dữ liệu thực tế đang được truyền Nó có thể dài từ 5 bit đến 8 bit nếu sử dụng bit chẵn lẻ Nếu không sử dụng bit chẵn lẻ, khung dữ liệu có thể dài 9 bit Trong hầu hết các trường hợp, dữ liệu được truyền với bit có trọng số bé nhất (LSB – Least Significant Bit) trước tiên.

2.1.2.3Parity Bit (Bit chẵn lẻ)

Tính chẵn lẻ mô tả tính chẵn hoặc lẻ của một số Bit chẵn lẻ là một cách để UART nhận cho biết liệu có bất kỳ dữ liệu nào đã thay đổi trong quá trình truyền hay không. Bit có thể bị thay đổi bởi bức xạ điện từ, tốc độ truyền không khớp hoặc truyền dữ liệu đường dài Sau khi UART nhận đọc khung dữ liệu, nó sẽ đếm số bit có giá trị là 1 và kiểm tra xem tổng số là số chẵn hay lẻ Nếu bit parity là 0 (even parity – parity chẵn), thì tổng số bit 1 trong khung dữ liệu phải luôn là một số chẵn Nếu bit parity là 1 (odd parity – parity lẻ) thì số tổng bit 1 trong khung dữ liệu là một số lẻ.

Khi bit chẵn lẻ khớp với dữ liệu, UART biết rằng quá trình truyền không có lỗi. Nhưng nếu bit chẵn lẻ là 0 và tổng là số lẻ, hoặc bit chẵn lẻ là 1 và tổng số là chẵn, thì UART biết rằng các bit trong khung dữ liệu đã thay đổi.

2.1.2.4Stop Bit (Bit kết thúc) Để báo hiệu sự kết thúc của gói dữ liệu, UART gửi sẽ điều khiển đường truyền dữ liệu từ điện áp thấp đến điện áp cao trong ít nhất hai khoảng thời gian bit.

Hình 2.12 Stop Bit trong quá trình giao tiếp UART

2.1.3 Các bước truyền nhận dữ liệu bằng giao tiếp UART

2.1.3.1UART truyền nhận dữ liệu song song từ bus dữ liệu.

Hình 2.5 UART truyền nhận dữ liệu song song từ bus dữ liệu

2.1.3.2UART truyền thêm bit start, bit chẵn lẻ và bit dừng vào khung dữ liệu.

Hình 2.6 UART truyền thêm bit start, bit chẵn lẻ và bit dừng vào khung dữ liệu

2.1.3.33 Toàn bộ gói được gửi nối tiếp từ UART truyền đến UART nhận UART nhận lấy mẫu đường dữ liệu ở tốc độ truyền được định cấu hình trước.

Hình 2.7 UART nhận lấy mẫu đường dữ liệu ở tốc độ truyền được định cấu hình trước

2.1.3.4UART nhận loại bỏ bit start, bit chẵn lẻ và bit stop khỏi khung dữ liệu.

Hình 2.8 UART nhận loại bỏ bit start, bit chẵn lẻ và bit stop khỏi khung dữ liệu

2.1.3.5UART nhận chuyển đổi dữ liệu nối tiếp trở lại thành song song và chuyển nó đến bus dữ liệu ở đầu nhận.

Hình 2.9 UART nhận chuyển đổi dữ liệu nối tiếp trở lại thành song song

Giao tiếp I2C

2.2.1 Giới thiệu chung về giao tiếp I2C

I2C là tên viết tắt của cụm từ tiếng anh “Inter-Integrated Circuit” Nó là một giao thức giao tiếp được phát triển bởi Philips Semiconductors để truyền dữ liệu giữa một bộ xử lý trung tâm với nhiều IC trên cùng một board mạch chỉ sử dụng hai đường truyền tín hiệu Do tính đơn giản của nó nên loại giao thức này được sử dụng rộng rãi cho giao tiếp giữa vi điều khiển và mảng cảm biến, các thiết bị hiển thị, thiết bị IoT, EEPROMs, v.v … Đây là một loại giao thức giao tiếp nối tiếp đồng bộ Nó có nghĩa là các bit dữ liệu được truyền từng bit một theo các khoảng thời gian đều đặn được thiết lập bởi một tín hiệu đồng hồ tham chiếu.

Giống như giao tiếp UART, I2C chỉ sử dụng hai dây để truyền dữ liệu giữa các thiết bị:

− SDA (Serial Data) - đường truyền cho master và slave để gửi và nhận dữ liệu.

− SCL (Serial Clock) - đường mang tín hiệu xung nhịp.

I2C là một giao thức truyền thông nối tiếp, vì vậy dữ liệu được truyền từng bit dọc theo một đường duy nhất (đường SDA).

Giống như SPI, I2C là đồng bộ, do đó đầu ra của các bit được đồng bộ hóa với việc lấy mẫu các bit bởi một tín hiệu xung nhịp được chia sẻ giữa master và slave Tín hiệu xung nhịp luôn được điều khiển bởi master.

Bus I2C (dây giao tiếp) chỉ gồm hai dây và được đặt tên là Serial Clock Line (SCL) và Serial Data Line (SDA) Dữ liệu được truyền đi được gửi qua dây SDA và được đồng bộ với tín hiệu đồng hồ (clock) từ SCL Tất cả các thiết bị/IC trên mạng I2C được kết nối với cùng đường SCL và SDA như sau:

Cả hai đường bus I2C (SDA, SCL) đều hoạt động như các bộ lái cực máng hở (open drain) Nó có nghĩa là bất kỳ thiết bị/ IC trên mạng I2C có thể lái SDA và SCL xuống mức thấp, nhưng không thể lái chúng lên mức cao Vì vậy, một điện trở kéo lên (khoảng 1 kΩ đến 4,7 kΩ) được sử dụng cho mỗi đường bus, để giữ cho chúng ở mức cao (ở điện áp dương) theo mặc định.

Lý do sử dụng một hệ thống cực máng hở (open drain) là để không xảy ra hiện tượng ngắn mạch, điều này có thể xảy ra khi một thiết bị cố gắng kéo đường dây lên cao và một số thiết bị khác cố gắng kéo đường dây xuống thấp.

2.2.2.2Thiết bị chủ (Master) và tớ (Slave)

Các thiết bị kết nối với bus I2C được phân loại hoặc là thiết bị Chủ (Master) hoặc là thiết bị Tớ (Slave) Ở bất cứ thời điểm nào thì chỉ có duy nhất một thiết bị Master ở trang thái hoạt động trên bus I2C Nó điều khiển đường tín hiệu đồng hồ SCL và quyết định hoạt động nào sẽ được thực hiện trên đường dữ liệu SDA.

Tất cả các thiết bị đáp ứng các hướng dẫn từ thiết bị Master này đều là Slave Để phân biệt giữa nhiều thiết bị Slave được kết nối với cùng một bus I2C, mỗi thiết bị Slave được gán một địa chỉ vật lý 7-bit cố định Khi một thiết bị Master muốn truyền dữ liệu đến hoặc nhận dữ liệu từ một thiết bị Slave, nó xác định địa chỉ thiết bị Slave cụ thể này trên đường SDA và sau đó tiến hành truyền dữ liệu Vì vậy, giao tiếp có hiệu quả diễn ra giữa thiết bị Master và một thiết bị Slave cụ thể Tất cả các thiết bị Slave khác không phản hồi trừ khi địa chỉ của chúng được chỉ định bởi thiết bị Master trên dòng SDA.

Hình 2.12 Thiết bị chủ (Master) và tớ (Slave) trong giao tiếp I2C

2.2.2.3Giao thức truyền nhận dữ liệu

Giao thức sau đây (tập hợp các quy tắc) được theo sau bởi thiết bị Master và các thiết bị Slave để truyền dữ liệu giữa chúng.

Dữ liệu được truyền giữa thiết bị Master và các thiết bị Slave thông qua một đường dữ liệu SDA duy nhất, thông qua các chuỗi có cấu trúc gồm các số 0 và 1 (bit) Mỗi chuỗi số 0 và 1 được gọi là giao dịch (transaction) và dữ liệu trong mỗi giao dịch có cấu trúc như sau:

Hình 2.13 Gói truyền dữ liệu của giao tiếp I2C

− Điều kiện bắt đầu (Start Condition)

Bất cứ khi nào một thiết bị chủ/ IC quyết định bắt đầu một giao dịch, nó sẽ chuyển mạch SDA từ mức điện áp cao xuống mức điện áp thấp trước khi đường SCL chuyển từ cao xuống thấp.

Khi điều kiện bắt đầu được gửi bởi thiết bị Master, tất cả các thiết bị Slave đều hoạt động ngay cả khi chúng ở chế độ ngủ (sleep mode) và đợi bit địa chỉ.

Hình 2.14 Điều kiện bắt đầu giao tiếp I2C

Nó bao gồm 7 bit và được lấp đầy với địa chỉ của thiết bị Slave đến/ từ đó thiết bị Master cần gửi/ nhận dữ liệu Tất cả các thiết bị Slave trên bus I2C so sánh các bit địa chỉ này với địa chỉ của chúng.

Bit này xác định hướng truyền dữ liệu Nếu thiết bị Master/ IC cần gửi dữ liệu đến thiết bị Slave, bit này được thiết lập là ‘0’ Nếu IC Master cần nhận dữ liệu từ thiết bị Slave, bit này được thiết lập là ‘1’.

ACK / NACK là viết tắt của Acknowledged / Not Acknowledged Nếu địa chỉ vật lý của bất kỳ thiết bị Slave nào trùng với địa chỉ được thiết bị Master phát, giá trị của bit này được set là ‘0’ bởi thiết bị Slave Ngược lại, nó vẫn ở mức logic ‘1’ (mặc định).

Nó bao gồm 8 bit và chúng được thiết lập bởi bên gửi, với các bit dữ liệu cần truyền tới bên nhận Khối này được theo sau bởi một bit ACK / NACK và được set thành ‘0’ bởi bên nhận nếu nó nhận thành công dữ liệu Ngược lại, nó vẫn ở mức logic

‘1’ Sự kết hợp của khối dữ liệu theo sau bởi bit ACK / NACK được lặp lại cho đến quá trình truyền dữ liệu được hoàn tất.

− Điều kiện kết thúc (Stop condition)

Sau khi các khung dữ liệu cần thiết được truyền qua đường SDA, thiết bị Master chuyển đường SDA từ mức điện áp thấp sang mức điện áp cao trước khi đường SCL chuyển từ cao xuống thấp.

Hình 2.15 Điều kiện kết thúc giao tiếp I2C

− Gửi dữ liệu đến thiết bị Slave

Trình tự hoạt động sau đây diễn ra khi một thiết bị Master gửi dữ liệu đến một thiết bị Slave cụ thể thông qua bus I2C:

− Thiết bị Master gửi điều kiện bắt đầu đến tất cả các thiết bị Slave

− Thiết bị Master gửi 7 bit địa chỉ của thiết bị Slave mà thiết bị Master muốn giao tiếp cùng với bit Read/Write

Hình 2.16 Master gửi điều kiện bắt đầu trong giao tiếp I2C

Giao tiếp SPI

2.3.1 Giới thiệu chung về giao tiếp SPI

SPI – Serial Peripheral Interface – hay còn gọi là giao diện ngoại vi nối tiếp, được phát triển bởi hãng Motorola Chuẩn đồng bộ nối truyền dữ liệu ở chế độ full - duplex (hay gọi là "song công toàn phần" Nghĩa là tại 1 thời điểm có thể xảy ra đồng thời quá trình truyền và nhận Là giao tiếp đồng bộ, bất cứ quá trình nào cũng đều được đồng bộ với xung clock sinh ra bởi thiết bị Master Không cần phải lo lắng về tốc độ truyền dữ liệu SPI thường được sử dụng giao tiếp với bộ nhớ EEPROM, RTC (Đồng hồ thời gian thực), IC âm thanh, các loại cảm biến như nhiệt độ và áp suất, thẻ nhớ như MMC hoặc thẻ SD hoặc thậm chí các bộ vi điều khiển khác.

2.3.2 Đặc điểm của giao tiếp SPI

Sử dụng 4 đường giao tiếp nên đôi khi được gọi là chuẩn truyền thông “4 dây” 4 đường đó là :

− SCK (Serial Clock): Thiết bị Master tạo xung tín hiệu SCK và cung cấp choSlave Xung này có chức năng giữ nhịp cho giao tiếp SPI Mỗi nhịp trên chânSCK báo 1 bit dữ liệu đến hoặc đi → Quá trình ít bị lỗi và tốc độ truyền cao.

− MISO (Master Input Slave Output): Tín hiệu tạo bởi thiết bị Slave và nhận bởi thiết bị Master Đường MISO phải được kết nối giữa thiết bị Master và Slave.

− MOSI (Master Output Slave Input): Tín hiệu tạo bởi thiết bị Master và nhận bởi thiết bị Slave Đường MOSI phải được kết nối giữa thiết bị Master và Slave.

− SS (Slave Select): Chọn thiết bị Slave cụ thể để giao tiếp Để chọn Slave giao tiếp thiết bị Master chủ động kéo đường SS tương ứng xuống mức 0 (Low). Chân này đôi khi còn được gọi là CS (Chip Select) Chân SS của vi điều khiển (Master) có thể được người dùng tạo bằng cách cấu hình 1 chân GPIO bất kỳ chế độ Output.

Hình 2.23 Các chân tín hiệu của SPI

Mỗi chip Master hay Slave đều có một thanh ghi dữ liệu 8 bits Quá trình truyền nhận giữa Master và Slave xảy ra đồng thời sau 8 chu kỳ đồng hồ, một byte dữ liệu được truyền theo cả 2 hướng Quá trình trao đổi dữ liệu bắt đầu khi Master tạo 1 xung clock từ bộ tạo xung nhịp (Clock Generator) và kéo đường SS của Slave mà nó truyền dữ liệu xuống mức Low Cứ 1 xung clock, Master sẽ gửi đi 1 bit từ thanh ghi dịch (Shift Register) của nó đến thanh ghi dịch của Slave thông qua đường MOSI Đồng thời Slave cũng gửi lại 1 bit đến cho Master qua đường MISO Như vậy sau 8 chu kỳ clock thì hoàn tất việc truyền và nhận 1 byte dữ liệu Dữ liệu của 2 thanh ghi được trao đổi với nhau nên tốc độ trao đổi diễn ra nhanh và hiệu quả.

Lưu ý: Trong giao tiếp SPI, chỉ có thể có 1 Master nhưng có thể 1 hoặc nhiều Slave cùng lúc Ở trạng thái nghỉ, chân SS của các Slave ở mức 1, muốn giao tiếp với Slave nào thì ta chỉ việc kéo chân SS của Slave đó xuống mức 0.

Hình 2.24 Quá trình truyền dữ liệu SPI

SPI có 4 chế độ hoạt động phụ thuộc vào cực của xung giữ (Clock Polarity – CPOL) và pha (Phase - CPHA).

− CPOL dùng để chỉ trạng thái của chân SCK ở trạng thái nghỉ Chân SCK giữ ở mức cao khi CPOL=1 hoặc mức thấp khi CPOL=0.

− CPHA dùng để chỉ các mà dữ liệu được lấy mẫu theo xung Dữ liệu sẽ được lấy ở cạnh lên của SCK khi CPHA=0 hoặc cạnh xuống khi CPHA=1.

Hình 2.25 Các chế độ hoạt động của SPI

− Mode 0 (mặc định) – xung nhịp của đồng hồ ở mức thấp (CPOL = 0) và dữ liệu được lấy mẫu khi chuyển từ thấp sang cao (cạnh lên) (CPHA = 0).

− Mode 1 - xung nhịp của đồng hồ ở mức thấp (CPOL = 0) và dữ liệu được lấy mẫu khi chuyển từ cao sang thấp (cạnh xuống) (CPHA = 1).

− Mode 2 - xung nhịp của đồng hồ ở mức cao (CPOL = 1) và dữ liệu được lấy mẫu khi chuyển từ cao sang thấp (cạnh lên) (CPHA = 0).

− Mode 3 - xung nhịp của đồng hồ ở mức cao (CPOL = 1) và dữ liệu được lấy mẫu khi chuyển từ thấp sang cao (cạnh xuông) (CPHA = 1).

2.3.4 Các sơ đồ kết nối giao tiếp SPI:

2.3.4.11 thiết bị Master và 1 thiết bị Slave

Hình 2.26 Kết nối 1 Master và 1 Slave của giao tiếp SPI

2.3.4.21 thiết bị Master và nhiều thiết bị Slave (chế độ độc lập - Independent): Ở chế độ này, mỗi thiết bị Slave kết nối với Master được quy định riêng bởi những chân SS khác nhau Khi thiết bị Master muốn giao tiếp với Slave nào thì kéo chân SS tương ứng xuống mức 0, những chân SS còn lại giữ ở mức 1.

Hình 2.27 Kết nối 1 Master và nhiều Slave trong giao tiếp SPI

2.3.4.31 thiết bị Master và nhiều thiết bị Slave (chế độ dây chuyền - Daisy): Nếu chúng ta cần kết nối SPI với nhiều thiết bị, nếu dùng cách trên thì sẽ tốn nhiều chân SS của vi điều khiển Thay vào đó chúng ta có thể kết nối các thiết bị Slave theo kiểu dây chuyển như bên dưới mà chỉ cần 1 chân SS từ vi điều khiển Chân MOSI củaSlave này sẽ nối với MISO của Slave tiếp theo.

Dữ liệu gửi từ vi điều khiển (hay thiết bị Master), đi vào Slave 1 bằng đường MOSI Sau đó lại đi ra từ chân MISO của Slave 1, gửi tới chân MOSI của Slave 2, và cứ tiếp tục như vậy, Có thể thấy cách hoạt động này khá giống với các IC dịch.

Giao thức MQTT

2.4.1 MQTT Đây là một giao thức truyền thông điệp (message) theo mô hình publish/subscribe (publish – theo dõi), sử dụng băng thông thấp, độ tin cậy cao và có khả năng hoạt động trong điều kiện đường truyền không ổn định.

Kiến trúc mức cao (high-level) của MQTT gồm 2 phần chính là Broker và Clients. Trong đó, broker được coi như trung tâm, nó là điểm giao của tất cả các kết nối đến từ client Nhiệm vụ chính của broker là nhận mesage từ publisher, xếp các message theo hàng đợi rồi chuyển chúng tới một địa chỉ cụ thể Nhiệm vụ phụ của broker là nó có thể đảm nhận thêm một vài tính năng liên quan tới quá trình truyền thông như: bảo mật message, lưu trữ message, logs,…

Client thì được chia thành 2 nhóm là publisher và subscriber Client là các software components hoạt động tại edge device nên chúng được thiết kế để có thể hoạt động một cách linh hoạt (lightweight) Client chỉ làm ít nhất một trong 2 việc là publish các message lên một topic cụ thể hoặc subscribe một topic nào đó để nhận message từ topic này.

Bởi vì giao thức này sử dụng băng thông thấp trong môi trường có độ trễ cao nên nó là một giao thức lý tưởng cho các ứng dụng M2M (Machine to machine).

Trong một hệ thống sử dụng giao thức MQTT, nhiều node trạm (gọi là mqtt client – gọi tắt là client) kết nối tới một MQTT server (gọi là broker) Mỗi client sẽ đăng ký một vài kênh (topic), ví dụ như “/client1/channel1”, “/client1/channel2” Quá trình đăng ký này gọi là “subscribe”, giống như chúng ta đăng ký nhận tin trên một kênhYoutube vậy Mỗi client sẽ nhận được dữ liệu khi bất kỳ trạm nào khác gởi dữ liệu và kênh đã đăng ký Khi một client gởi dữ liệu tới kênh đó, gọi là “publish”.

Hình 2.28 Mô hình pub/sub của MQTT

Mỗi kết nối tới broker được đánh giá chất lượng bởi thông số chất lượng dịch vụ (QoS) như sau:

Nhiều nhất một lần: Tin nhắn chỉ được gửi một lần Client và broker không phải thực hiện thêm bước nào để xác nhận việc gửi có thành công hay không Cơ chế gởi và quên (tiếng Anh: fire and forget, tạm dịch: gởi và quên).

− Ít nhất một lần: Tin nhắn được người gửi thử lại nhiều lần cho đến khi nhận được xác nhận là đã gởi được (tiếng Anh: acknowledged delivery, tạm dịch: Xác nhận đã gởi được)

− Chính xác một lần: Phía gởi và phía nhận thực hiện quá trình bắt tay hai cấp để đảm bảo chỉ nhận được một bản sao của tin nhắn (tiếng Anh: assured delivery, tạm dịch: đảm bảo gởi được).

Trường này không ảnh hưởng đến việc xử lý các quá trình truyền dữ liệu TCP bên dưới; nó chỉ được sử dụng giữa người gửi và người nhận MQTT.

Retain là một cờ (flag) được gắn cho một message của giao thức MQTT Retain chỉ nhận giá trị 0 hoặc 1 (tương ứng 2 giá trị logic false hoặc true) Nếu retain = 1, broker sẽ lưu lại message cuối cùng của 1 topic kèm theo mức QoS tương ứng Khi client bắt đầu subscribe topic có message được lưu lại đó, client ngay lập tức nhận được message.

MQTT Bridge là một tính năng của MQTT Broker cho phép các MQTT Broker có thể kết nối và trao đổi dữ liệu với nhau Để sử dụng tính năng này, ta cần tối thiểu 2

Broker, trong đó, một Broker bất kỳ sẽ được cấu hình thành Bridge Khi cấu hình MQTT bridge, ta cần lưu ý tới các thông số sau:

− address: địa chỉ của broker cần kết nối

− bridge_protocol_version: phiên bản của giao thức MQTT đang sử dụng chung cho 2 broker

− topic: phần này định nghĩa 3 thong số: tên topic được trao đổi giữa 2 broker, chiều trao đổi (1 chiều hay 2 chiều) và topic mapping giữa 2 broker

Hình 2.29 Mô hình pub.sub giữa MQTT và Broker

Tập lệnh AT

Tập lệnh AT (Attention) là một tập lệnh điều khiển modem thông dụng được sử dụng để truy cập và cấu hình modem AT commands được sử dụng để thực hiện các hoạt động như gửi và nhận tin nhắn văn bản, cấu hình và quản lý kết nối mạng và thực hiện các chức năng khác của modem.

Dưới đây là một số lệnh AT thông dụng và ý nghĩa của chúng:

− AT - Kiểm tra kết nối với modem

− AT+CPIN - Nhập mã PIN SIM

− AT+CSQ - Kiểm tra tín hiệu mạng

− AT+COPS - Kiểm tra mạng điện thoại hiện tại

− AT+CREG - Kiểm tra trạng thái đăng ký mạng

− AT+CGATT - Kết nối/ ngắt kết nối với mạng GPRS

− AT+CGDCONT - Cấu hình thông tin APN của mạng GPRS

− AT+CGACT - Kết nối/ ngắt kết nối với mạng GPRS

− AT+CGPADDR - Lấy địa chỉ IP của thiết bị

− AT+CIPSTART - Bắt đầu kết nối TCP/UDP

− AT+CIPSEND - Gửi dữ liệu đến TCP/UDP

− AT+CIPCLOSE - Đóng kết nối TCP/UDP

TỔNG QUAN HỆ THỐNG

Mô hình hệ thống

Hình 3.30 Mô hình làm việc của hệ thống

Hệ thống bao gồm các thiết bị giám sát vị trí, xem như là các client, publish các bản tin bao gồm các thông tin về nhiệt độ, vị trí, gia tốc,… lên một topic xác định ở MQTT Broker.

Một client nào subcribe vào topic này có thể nhận được dữ liệu mà các thiết bị giám sát publish lên.

Dữ liệu này thông qua API có thể được sử dụng cho Web/ App để hiển thị nội dung mong muốn (VD: Bản đồ tracking, các thông số khác,…)

Khối thiết bị

Hình 3.31 Khối thiết bị của hệ thống

Khối thiết bị của hệ thống bao gồm vi xử lý đóng vai trò điều khiển, quản lý các thành phần trong thiết bị, như lấy dữ liệu gia tốc từ cảm biến gia tốc, lấy dữ liệu GPS từ module GNSS, và truyền thông thông qua module LTE.

Khối backend

Backend sử dụng AWS Cloud.

AWS IoT cung cấp các dịch vụ đám mây kết nối thiết bị IoT với các thiết bị khác và dịch vụ đám mây AWS AWS IoT cung cấp phần mềm thiết bị có thể giúp tích hợp các thiết bị IoT của mình vào các giải pháp dựa trên AWS IoT

Hình 3.32 Mô hình làm việc giữa IoT, AWS IoT và các dịch vụ khác của AWS

TRIỂN KHAI HỆ THỐNG

Khối thiết bị

Sử dụng vi xử lý STM32F401RCT6.

Hình 4.33 Vi xử lý STM32F401RCT6

4.1.2.1Cảm biến gia tốc SC7A20

Hình 4.34 Sơ đồ nối dây cảm biến gia tốc

Cảm biến gia tốc SC7A20 là một loại cảm biến gia tốc động lực học (accelerometer) được sử dụng trong nhiều ứng dụng khác nhau Trong đồ án này bọn em dùng để đo gia tốc của các phương tiện gia thông và nhiệt độ ngoài môi trường. Đầu tiên cần khai báo các địa chỉ:: địa chỉ I2C của SC7A20 là 0x18, thanh ghi ouput nhiệt độ (OUT_TEMP_L_REG_ADDR) 0x0C, địa chỉ thanh ghi control temp (SC7A20_TEMP_CFG_REG) 0x17, địa chỉ thanh ghi ctrl_reg1 của SC7A20 0x20, ctrl_reg4

Tiếp theo là config thanh ghi theo chức năng mà chúng ta muốn sử dụng. Config thanh ghi ctrl_reg1 về 0x47 để enable 3 trục XYZ, thanh ghi ctrl_reg4 về 0x80 để set full scale range = +/- 8g, thanh ghi SC7A20_TEMP_CFG_REG về 0x02 để enable temp Config I2C dùng I2C1 và clockspeed là 100000Hz.

Tiếp đến là đọc data qua hàm HAL_I2C_Master_Transmit và HAL_I2C_Master_Receive cho phép đọc giá trị của các thanh ghi truyền vào hàm và trả về kết quả uint8_t Mỗi dữ liệu sẽ có 2 thanh ghi để lưu data là thanh ghi OUT_L và thanh ghi OUT_H Sau ghi lấy được data chúng ta sẽ convert về int16_t bằng cách dịch thanh ghi OUT_H sang trái 8 bit và or với thanh ghi OUT_L.

Hình 4.35 Module GPS Quectel L76-LB

Hình 4.36 Sơ đồ chân module GPS

Hình 4.37 Sơ đồ nguồn điện trong module

Các chân quan trọng và chức năng của chúng:

− Chân VCC: Chân nguồn module luôn được kéo lên 3V3.

− Chân V_BCKP: Chân cấp nguồn cho miền RTC (Real Time Clock) Bộ RTC chứa tất cả thông tin GNSS cần thiết cho khởi động nhanh và một số biến số cấu hình người dùng.

− Chân STANDBY: Chân khởi tạo việc truyền dữ liệu Khi chân này được đọc ở mức cao module sẽ vào chế độ chờ, module sẽ ko truyền dữ liệu.

− Chân RESET: Chân bật lại module Kéo chân này xuống mức thấp với khoảng thời gian > 10ms thì module sẽ được khởi động lại.

− Chân FORCE_ON: Thuộc bộ RTC, chân tín hiệu này như một công tắc đóng mở để cung cấp nguồn cho bộ RTC.

− Chân L76 Rx: Module nhận lệnh điều khiển từ vi điều khiển.

− Chân L76 Tx: Khi Module ở trạng thái on, module sẽ liên tục truyền raw data gps cho vi điều khiển tùy theo cấu hình đã được vi điều khiển thiết lập khi gửi lệnh qua L76 Rx.

− Kéo chân V_BCKP xuống mức thấp vì chân này chỉ được khởi động khi module off để cấp nguồn cho bộ RTC.

HAL_GPIO_WritePin(_L76LB_GPIO_TypeDef,_L76LB_PWR_SUPPLY,

− Kéo chân STANDBY xuống mức thấp để thoát chề độ chờ. ã HAL_GPIO_WritePin(_L76LB_GPIO_TypeDef,_L76LB_STANDBY,

Sau khi khởi động module raw data gps sẽ được liên tục truyền về vi điều khiển qua chân L76 Tx và chúng ta sẽ phải xử lý raw data này bằng hàm_L76LB_Process_Data để có thể đưa ra kết quả trả về gồm các trường dữ liệu như thời gian (giờ, phút, giây, ngày, tháng, năm), tín hiệu GPS (kinh độ, vĩ độ), tốc độ dự tính trên mặt đất, hướng đi trên mặt đất COG(Course Over Ground).

Khối truyền thông

Sử dụng module SIM EC200.

Sơ đồ chân của module

Hình 4.39 Sơ đồ chân module SIM EC200

Module sim được sử dụng với mục đích là để có thể kết nối thiết bị với mạng và đưa các dữ liệu thu thập được thông qua các giao thức mạng lên client để người dùng có thể truy xuất đến chúng.

Hình 4.40 Sơ đồ thời gian khi module on

Các chân sử dụng và chức năng của chúng:

− MDSIM_PWR_SUPPLY: Kí hiệu cho chân VBAT là chân nguồn cho module.

Chân này luôn ở mức cao (4.3V) trong quá trình module chạy.

− MDSIM_PWRKEY: Kí hiệu cho chân PWRKEY là chân sử dụng như công tắc bật tắt module.

− MDSIM_RSTKEY: Kí hiệu cho chân RESET_N là chân reset module.

− MDSIM_STATUS: Kí hiệu cho chân STATUS là chân xác định thời gian truyền dữ liệu Khi chân này ở mức thấp, dữ liệu được truyền qua uart. Trạng thái module hoạt động:

− VBAT giữ trạng thái mức logic cao 4.3V.

− VDD_EXT ở mức logic cao 4.3V.

Trạng thái module truyền dữ liệu qua uart:

Sau khi khởi động thành công module, để sử dụng các tính năng của module chúng ta giao tiếp với module bằng cách gửi các lệnh AT đến module.

Dưới đây là một vài ví dụ liên quan đến các lệnh AT trong module EC200:

Chú ý: Dòng chữ màu đỏ là lệnh gửi đi.

Bảng 4.2 Bảng lệnh giao tiếp với module SIM

Lệnh và phản hồi Chú thích

Thông tin của thiết bị

Kiểm tra nhập Pin Sim

Kiểm tra nhà mạng của sim

Kiểm tra trạng thái đăng kí mạng

Sau khi cài đặt các chế độ cần thiết cho sim, tiếp đó chúng ta cần kết nối đến MQTT brker Thông qua kết nối đến MQTT broker, chúng ta có thể truyền tải dữ liệu lên mạng, kết nối đến với người dùng.

Dưới đây là một vài ví dụ liên quan đến các lệnh AT để kết nối với MQTT broker:

Bảng 4.3 Bảng lệnh tương tác với MQTT Broker

AT+QMTOPEN=0,"iot-as-mqtt.cn- Mở MQTT client kết nối với MQTT shanghai.aliyuncs.com",1883

Thông báo mở thành công MQTT AT+QMTOPEN?

+QMTOPEN: 0,"iot-as-mqtt.cn- shanghai.aliyuncs.com",1883

Kiểm tra kết nối với MQTT Broker

Kết nối client “clientExample” đến broker

Thông báo tạo kết nối thành công AT+QMTSUB=0,1,"topic/pub",0

+QMTSUB: 0,1,0,0 Đăng ký 1 topic trên client

Thông báo tạo thành công AT+QMTPUBEX=?

Lệnh yêu cầu gửi cách pub data lên topic

Khối hiển thị

Dữ liệu từ thiết bị được tải lên Aws IoT Core và được sử dụng tạo bản đồ cho App.App được viết bằng framework React Native.

4.4.1 Kiến trúc tổng thể của IoT với Aws

Hình 4.41 Kiến trúc tổng thể hỗ trợ Internet of Things của Aws

Kiến trúc tổng thể hỗ trợ IoT của Aws Cloud bao gồm 3 phần:

− Edge gồm Endpoints và Gateway

− Endpoints để chỉ một thiết bị hoặc ứng dụng giao tiếp với đám mây. Engpoints là một thiết bị vật lý hoặc ảo, chẳng hạn như cảm biến hoặc app, kết nối với AWS IoT Core bằng giao thức MQTT, HTTP hoặc WebSocket để gửi hoặc nhận dữ liệu.

− Gateway là một thiết bị hoạt động như một cầu nối giữa các thiết bị và cloud, cho phép truyền lệnh và dữ liệu Nó có trách nhiệm lọc, xử lý hay tổng hợp dữ liệu trước khi gửi lên đám mây.

− AWS Cloud: đề cập đến bộ dịch vụ Aws được thiết kế đặc biệt để hỗ trợ các ứng dụng IoT, trong đó bao gồm 2 dịch vụ quan trọng sau:

− AWS IoT Core là dịch vụ đám mây được quản lý cho phép các thiết bị được kết nối tương tác an toàn với các ứng dụng đám mây và các thiết bị khác.

Nó cung cấp các khả năng như môi giới tin nhắn, xác thực thiết bị và bảo mật.

− AWS IoT Event là một dịch vụ được quản lý hoàn toàn cho phép khách hàng phát hiện và phản hồi các sự kiện từ các thiết bị và ứng dụng IoT trong thời gian thực.

− Enterprise: đề cập đến bộ dịch vụ và giải pháp AWS được thiết kế để cho phép doanh nghiệp xây dựng và triển khai các ứng dụng IoT trên quy mô lớn. Ứng dụng tracking xe máy này chỉ sử dụng các thành phần sau:

− Things (có thể là thiết bị, cũng có thể là ứng dụng)

− AWS IoT Core: gồm MQTT Broker, Rule Engine, Certificate và Device shadow.

4.4.2 Cấu hình quyền và bảo mật cho các mối quan hệ giữa người dùng và thiết bị IoT

Một trong những nhiệm vụ đầy thách thức khi thiết lập dịch vụ IoT Core là cấu hình quyền cho các loại mối quan hệ khác nhau bằng cách sử dụng tài liệu chính sách.

Và, nếu đối với 1 người dùng: 1 vật, điều này có thể dễ dàng thực hiện, nhưng đối với các loại quan hệ khác như 1 người dùng: M vật, M người dùng: 1 vật và M người dùng: M vật, quá trình này không đơn giản như vậy, đặc biệt đối với các trường hợp người dùng và thiết bị có thể thay đổi liên kết nhóm của họ trong toàn bộ vòng đời. Dựa trên các yêu cầu được xác định trong phần tuyên bố vấn đề, xem xét kiến trúc chi tiết thô và sự tương tác giữa các dịch vụ của Amazon (Hình 4 42) được sử dụng để cung cấp cho nhóm người dùng quyền truy cập vào mọi vật.

Mọi thứ sử dụng giao thức MQTT để giao tiếp với AWS IoT Message Broker. Người dùng (hoặc ứng dụng người dùng) trong một nhóm có thể nhận dữ liệu và quản lý các thiết bị IoT trong thời gian gần bằng MQTT AWS Cognito kết hợp với dịch vụQuản lý truy cập và nhận dạng (IAM) được sử dụng để xác thực và ủy quyền cho người dùng cũng như cấp quyền cho các phần khác nhau của hệ thống Các quyền tài nguyên bổ sung, ví dụ như đăng ký chủ đề tin nhắn MQTT, xuất bản tin nhắn, v.v.được xác định bởi tài liệu chính sách AWS IoT Core.

Tại đây xác định được các ID token cho IAM, Cognito User Pool với Pool ID - mã định danh duy nhất cho nhóm người dùng, Pool ARN - mã định danh duy nhất cho nhóm người dùng được IAM sử dụng để kiểm soát quyền truy cập vào tài nguyên của nhóm người dùng. Đồng thời xác định một App clients trong User pool App client cấu hình xác định cài đặt cho app client muốn truy cập User pool.

Hình 4.42 Tương tác giữa các dịch vụ cung cấp cho người dùng tiếp cận thiết bị

Ngoài ra, cần cấu hình Cognito Identity Pool - cho phép người dùng xác thực với các nhà cung cấp danh tính bên ngoài hoặc Amazon và nhận thông tin xác thực AWS tạm thời, có đặc quyền hạn chế để truy cập tài nguyên AWS.

4.4.2.3IoT Core Policy Để xác định quyền truy cập và quyền trong dịch vụ AWS IoT Core, các bước sau phải được thực hiện:

− Tài liệu policy phải được tạo ra.

− Tài liệu policy phải được đính kèm với một thực thể cụ thể – chứng chỉ hoặc Cognito identity đã định nghĩa ở trên.

"Resource": "arn:aws:iot:ap-northeast-2:[account-id]:topic/*"

File json trên xác định một policy cho phép truy cập vào mọi quyền thực hiện với topic MQTT trong dịch vụ IoT.

Sau khi hoàn tất tạo policy và gán nó vào một Cognito Identity, cần thực hiện thêm phần xác thực này vào app client để AWS cho phép app tương tác với AWS. const awsmobile = {

"aws_project_region": "ap-northeast-2",

"aws_cognito_identity_pool_id": "ap-northeast-2:

"aws_cognito_region": "ap-northeast-2",

"aws_user_pools_id": "[user-pool-id]",

"aws_user_pools_web_client_id": "[app-client-id]"

4.4.3 Cấu hình nhận bản tin MQTT

Hình 4.43 Mô hình làm việc giữa thiết bị, AWS IoT Core, app và Device Shadow

Device Shadow là một dịch vụ của AWS IoT Core Shadow có thể cung cấp trạng thái của thiết bị thông qua các chủ đề MQTT cho dù thiết bị có được kết nối hay không Điều này cho phép Ứng dụng và Dịch vụ tương tác với trạng thái thiết bị bất kỳ lúc nào.

− Thiết bị thiết lập kết nối MQTT với endpoint AWS IoT Core , sau đó đăng ký topic deviceId/shadow/update/delta, deviceId/shadow/update/accepted và deviceId/shadow/update/rejected để nhận các cập nhật thay đổi trạng thái ẩn.

Sử dụng thư viện Amplify hỗ trợ tương tác với Aws IoT Core như sau:

− Thiết bị publish trạng thái ban đầu của nó cho topic deviceID/shadow/update. Đây là topic nhận được cập nhật trạng thái hiện tại và mong muốn.

− Trình môi giới AWS IoT Core ghi trạng thái thiết bị vào kho lưu trữ liên tục Device Shadow

Hình 4.44 Kết nối device shadow

− Ứng dụng thiết lập kết nối MQTT với endpoint AWS IoT Core , sau đó subcribe topic deviceId/shadow/update/documents, deviceId/shadow/update/acceptedvà deviceId/shadow/update/rejected để nhận các cập nhật thay đổi trạng thái ẩn.

Sử dụng thư viện Amplify hỗ trợ tương tác với Aws IoT Core như sau:

Amplify.addPluggable( new AWSIoTProvider({ aws_pubsub_region: 'ap-northeast-2', aws_pubsub_endpoint:

'wss://[endpoint].iot.ap-northeast-2.amazonaws.com/mqtt'

Amplify.PubSub.subscribe('$aws/things/real-time- tracking/shadow/get/accepted').subscribe({ next: data => { console.log('Message received:', data.value.message); setMessage(data.value.message);

}, error: error => console.error(error), close: () => console.log('Done'),

}); return () => { if (subscription) { subscription.unsubscribe();

4.4.3.2Cập nhật từ ứng dụng trả về thiết bị

Hình 4.45 Cập nhật từ ứng dụng tới thiết bị

4.4.3.3Cập nhật từ thiết bị tới ứng dụng

Hình 4.46 Cập nhật từ thiết bị tới ứng dụng

− Broker AWS IoT Core cập nhật trạng thái liên tục của Device Shadow

− Broker AWS IoT Core đăng một thông báo xác nhận cho topicdeviceId/shadow/update/accepted và thông báo tài liệu cho topic deviceId/shadow/update/documents.

Dữ liệu nhận về thu được 2 giá trị latitude và longitude, sử dụng Google Map API để trực quan hóa dữ liệu trên bản đồ.

Ngày đăng: 18/06/2024, 17:25

HÌNH ẢNH LIÊN QUAN

Hình 2.1 Cách thức hoạt động giao tiếp UART - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.1 Cách thức hoạt động giao tiếp UART (Trang 12)
Hình 2.2 Kết nối chân giao tiếp UART - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.2 Kết nối chân giao tiếp UART (Trang 13)
Hình 2.5 UART truyền nhận dữ liệu song song từ bus dữ liệu - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.5 UART truyền nhận dữ liệu song song từ bus dữ liệu (Trang 16)
Hình 2.6 UART truyền thêm bit start, bit chẵn lẻ và bit dừng vào khung dữ liệu - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.6 UART truyền thêm bit start, bit chẵn lẻ và bit dừng vào khung dữ liệu (Trang 16)
Hình 2.9 UART nhận chuyển đổi dữ liệu nối tiếp trở lại thành song song - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.9 UART nhận chuyển đổi dữ liệu nối tiếp trở lại thành song song (Trang 17)
Hình 2.7 UART nhận lấy mẫu đường dữ liệu ở tốc độ truyền được định cấu hình trước - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.7 UART nhận lấy mẫu đường dữ liệu ở tốc độ truyền được định cấu hình trước (Trang 17)
Hình 2.17 Slave so sánh địa chỉ được gửi từ thiết bị Master đến địa chỉ riêng của nó - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.17 Slave so sánh địa chỉ được gửi từ thiết bị Master đến địa chỉ riêng của nó (Trang 23)
Hình 2.18 Master gửi hoặc nhận khung dữ liệu trong giao tiếp I2C - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.18 Master gửi hoặc nhận khung dữ liệu trong giao tiếp I2C (Trang 23)
Hình 2.22 Chế độ hoạt động nhiều master nhiều slave giao tiếp I2C - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.22 Chế độ hoạt động nhiều master nhiều slave giao tiếp I2C (Trang 26)
Hình 2.23 Các chân tín hiệu của SPI - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.23 Các chân tín hiệu của SPI (Trang 27)
Hình 2.24 Quá trình truyền dữ liệu SPI - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.24 Quá trình truyền dữ liệu SPI (Trang 28)
Hình 2.27 Kết nối 1 Master và nhiều Slave trong giao tiếp SPI - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 2.27 Kết nối 1 Master và nhiều Slave trong giao tiếp SPI (Trang 29)
Hình 3.30 Mô hình làm việc của hệ thống - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 3.30 Mô hình làm việc của hệ thống (Trang 34)
Hình 3.31 Khối thiết bị của hệ thống - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 3.31 Khối thiết bị của hệ thống (Trang 35)
Hình 3.32 Mô hình làm việc giữa IoT, AWS IoT và các dịch vụ khác của AWS - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 3.32 Mô hình làm việc giữa IoT, AWS IoT và các dịch vụ khác của AWS (Trang 35)
Hình 4.36 Sơ đồ chân module GPS - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 4.36 Sơ đồ chân module GPS (Trang 38)
Sơ đồ chân của module - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Sơ đồ ch ân của module (Trang 40)
Hình 4.40 Sơ đồ thời gian khi module on - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 4.40 Sơ đồ thời gian khi module on (Trang 41)
Bảng 4.2 Bảng lệnh giao tiếp với module SIM - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Bảng 4.2 Bảng lệnh giao tiếp với module SIM (Trang 42)
Hình 4.41 Kiến trúc tổng thể hỗ trợ Internet of Things của Aws - báo cáo đồ án thiết kế thiết bị nhúng đề tài hệ thống iot giám sát phương tiện giao thông
Hình 4.41 Kiến trúc tổng thể hỗ trợ Internet of Things của Aws (Trang 44)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w