Nếu nhận được phản hồi lỗi,chuyển hướng truyền dữ liệu lên bộđiều khiển Controller và phânluồng nhận dữ liệu từ các thiết bị vàlưu trữ, đồng thời gửi tín hiệu điềukhiển đến cơ cấp chấp h
GIỚI THIỆU CHUNG
Bối cảnh
Internet of Things (IoT) đang trở thành lĩnh vực công nghệ chủ chốt với sự phát triển mạnh mẽ và tác động sâu rộng toàn cầu Sự bùng nổ của các thiết bị thông minh và kết nối đã dẫn đến việc IoT được áp dụng rộng rãi trong nhiều lĩnh vực, bao gồm sản xuất (Industry 4.0), chăm sóc sức khỏe, giao thông thông minh, thành phố thông minh, và nông nghiệp chính xác.
Sự phát triển của công nghệ 5G, điện toán đám mây và trí tuệ nhân tạo (AI) đã nâng cao hiệu quả của các hệ thống IoT, cho phép truyền dữ liệu với tốc độ cao và xử lý thông tin theo thời gian thực Tuy nhiên, vấn đề bảo mật và quyền riêng tư ngày càng trở nên quan trọng khi số lượng thiết bị kết nối và khối lượng dữ liệu phát sinh không ngừng gia tăng.
Với tiềm năng kinh tế lên tới hàng nghìn tỷ USD, IoT đang cách mạng hóa hoạt động của các doanh nghiệp và tác động sâu sắc đến đời sống hàng ngày, góp phần đưa nhân loại tiến gần hơn đến một xã hội số hóa toàn diện.
Vấn đề nghiên cứu
Dù IoT mang lại nhiều lợi ích, các nhà phát triển phải đối mặt với nhiều thách thức như:
Lựa chọn và triển khai giao thức phù hợp với từng ứng dụng cụ thể.
Xử lý tình huống mất kết nối giữa thiết bị IoT và cloud, đảm bảo hệ thống vẫn hoạt động mượt mà.
Bảo mật dữ liệu trong bối cảnh các mối đe dọa an ninh mạng ngày càng gia tăng.
Làm quen và tùy chỉnh các nền tảng quản lý IoT để đáp ứng yêu cầu thực tế.
Dự án này tập trung vào việc khắc phục các thách thức hiện tại bằng cách áp dụng các giải pháp thực tiễn thông qua các giao thức MQTT, CoAP và HTTP, đồng thời sử dụng nền tảng ThingsBoard để quản lý thiết bị hiệu quả.
Mục tiêu
Dự án tập trung vào các mục tiêu cụ thể sau:
Hiểu về mô hình IoT: Nắm vững cấu trúc và hoạt động của hệ thống IoT, bao gồm thiết bị, gateway, và cloud.
Triển khai giao thức truyền thông: Xây dựng các ứng dụng IoT sử dụng
MQTT, CoAP, và HTTP để truyền dữ liệu từ cảm biến lên cloud và thực hiện điều khiển thiết bị.
Để xử lý vấn đề mất kết nối, cần phát triển các giải pháp dự phòng thông qua việc sử dụng thiết bị điều khiển (controller) Thiết bị này sẽ lưu trữ và xử lý dữ liệu ngay cả khi kết nối với cloud bị gián đoạn, đảm bảo tính liên tục trong việc quản lý và xử lý thông tin.
Bảo mật hệ thống: Thực hiện mã hóa dữ liệu và đảm bảo an toàn truyền thông qua các giao thức.
Tích hợp nền tảng ThingsBoard: Quản lý, giám sát thiết bị IoT và tùy chỉnh giao diện hiển thị dữ liệu.
Phạm vi nghiên cứu
Dự án này giới hạn trong việc triển khai và thử nghiệm các giải pháp IoT như sau:
Các giao thức truyền thông được nghiên cứu gồm: MQTT, CoAP, và HTTP.
Các thiết bị IoT sử dụng: cảm biến nhiệt độ, độ ẩm đất, ánh sáng và các bộ điều khiển (LED, bơm tưới nước).
Nền tảng quản lý: sử dụng ThingsBoard Cloud để hiển thị dữ liệu và quản lý thiết bị.
Phạm vi bảo mật: tập trung vào mã hóa dữ liệu truyền giữa các thiết bị và cloud.
Kết nối mạng: sử dụng mạng LAN và Wi-Fi cho các thí nghiệm.
Không mở rộng phạm vi nghiên cứu sang các giao thức hoặc nền tảng IoT khác như LoRa, Zigbee hay AWS IoT.
Cấu trúc báo cáo
Báo cáo sẽ bắt đầu bằng việc trình bày cơ sở lý thuyết trong chương 2, nơi người đọc sẽ được giới thiệu những kiến thức cơ bản về các giao thức CoAP, MQTT và HTTP.
Chương tiếp theo trình bày phương pháp nghiên cứu, mô hình hóa hệ thống và các công cụ được sử dụng.
Chương 4 trình bày kết quả thực nghiệm (triển khai trên phần cứng)
Chương 5 trình bày nhận xét và kết luận rút ra từ thực nghiệm, đồng thời nêu ra những hướng phát triển trong tương lai
Chương 6 là lời kết và chương 7 là phụ lục
CƠ SỞ LÝ THUYẾT
HTTP Protocol
HTTP là giao thức request/response, trong đó trình duyệt web thường là client gửi yêu cầu đến máy chủ Giao thức này sử dụng ba kiểu bản tin chính để giao tiếp: GET, POST và PUT.
- GET: Đây là yêu cầu dữ liệu từ client Một client (trình duyệt web) gửi bản tin GET tới máy chủ để yêu cầu trang HTML pages.
- POST: Kiểu bản tin này sẽ gửi dữ liệu lên máy chủ.
- PUT: Kiểu bản tin này gửi tài nguyên (resources) hoặc là nội dung
(content) (ví dụ như một bức ảnh) lên máy chủ.
Hình CƠ SỞ LÝ THUYẾT-3 Ví dụ HTTP GET Message
Mặc dù HTTP linh hoạt, nhưng không an toàn vì thông tin gửi lên máy chủ ở dạng plaintext có thể bị chặn và đọc Để đảm bảo an toàn khi giao tiếp qua Internet, giao thức HTTP Secure (HTTPS) được sử dụng, với xác thực và mã hóa để bảo vệ dữ liệu giữa client và server Quá trình yêu cầu và phản hồi giữa HTTPS và HTTP giống nhau, nhưng dữ liệu được mã hóa bằng TLS (Transport Layer Security) hoặc SSL (Secure Socket Layer) trước khi truyền qua mạng.
Có thể tóm tắt một vài đặc điểm chính của HTTP Protocol như sau:
Mục đích Đươc phát triển nhằm mục đích chia sẻ tài liệu trên
Mô hình hoạt động Request/Response
Cách truyền dữ liệu Chỉ truyền thông tin từ client đến server
Giao thức Hỗ trợ cả TCP và UDP
Loại nội dung Văn bản (sử dụng mã hóa Base64 cho dữ liệu nhị phân) Chế độ truyền tin Đồng bộ
Kích thước tiêu đề 8 bytes
Bảng CƠ SỞ LÝ THUYẾT.5 Một số đặc điểm của HTTP Protocol
MQTT Protocol
MQTT (Message Queuing Telemetry Transport) là giao thức truyền thông theo mô hình publish/subscribe, được tối ưu hóa cho mạng băng thông thấp và thiết bị có tài nguyên hạn chế Được giới thiệu bởi IBM vào năm 1999, MQTT hiện nay đã trở thành tiêu chuẩn trong lĩnh vực truyền thông IoT.
3 chuẩn hóa trong OASIS, MQTT nổi bật nhờ sự nhẹ nhàng, hiệu quả và đáng tin cậy trong các ứng dụng IoT.
MQTT là một giao thức dựa trên TCP/IP, chuyên truyền tải dữ liệu dưới dạng tin nhắn nhỏ gọn giữa các thiết bị, từ cảm biến đến đám mây, thông qua một "broker" trung gian.
MQTT hoạt động theo mô hình publish/subscribe, gồm ba thành phần chính:
1 Publisher: Thiết bị phát thông điệp, chẳng hạn cảm biến gửi dữ liệu nhiệt độ.
2 Subscriber: Thiết bị nhận thông điệp, chẳng hạn hệ thống giám sát nhiệt độ.
3 Broker: Máy chủ trung gian nhận thông điệp từ publisher và chuyển tiếp tới các subscriber đăng ký đúng chủ đề (topic).
CoAP Protocol
CoAP (Giao thức Ứng dụng Hạn chế) là một giao thức được phát triển đặc biệt cho các thiết bị IoT có tài nguyên hạn chế như cảm biến và thiết bị điều khiển Được chuẩn hóa bởi IETF trong RFC 7252, CoAP dựa trên mô hình REST (Chuyển trạng thái đại diện), tương tự như HTTP, nhưng được tối ưu hóa cho mạng băng thông thấp và thiết bị có bộ nhớ và CPU hạn chế.
CoAP sử dụng giao thức UDP thay vì TCP nhằm giảm độ trễ, tiết kiệm tài nguyên và cải thiện hiệu suất cho các ứng dụng IoT Giao thức này hỗ trợ các phương thức cơ bản như GET, POST, PUT và DELETE, giúp truy cập tài nguyên trên thiết bị IoT một cách đơn giản và hiệu quả.
CoAP được xây dựng dựa trên hai thành phần chính:
Client và Server là hai thành phần chính trong giao tiếp mạng, trong đó Client gửi yêu cầu đến Server để truy cập hoặc thay đổi trạng thái tài nguyên Sau khi nhận yêu cầu, Server sẽ phản hồi với dữ liệu hoặc trạng thái tương ứng, đảm bảo quá trình trao đổi thông tin diễn ra hiệu quả.
Mỗi tài nguyên trên thiết bị được biểu diễn dưới dạng URI (Uniform Resource Identifier), giúp truy cập dễ dàng thông qua các phương thức RESTful.
Các tính năng chính của CoAP
Tối ưu hóa tài nguyên: CoAP được thiết kế để hoạt động hiệu quả trên các thiết bị có tài nguyên hạn chế
Sử dụng UDP để giảm overhead so với TCP.
Gói tin CoAP nhỏ gọn và phù hợp với các mạng IoT như 6LoWPAN.
Tương tác RESTful: CoAP sử dụng mô hình REST, giúp các thiết bị giao tiếp với nhau thông qua các phương thức tiêu chuẩn:
GET: Lấy dữ liệu từ server (ví dụ, đọc giá trị cảm biến).
POST: Gửi dữ liệu lên server để tạo mới tài nguyên.
PUT: Cập nhật trạng thái tài nguyên hiện tại.
DELETE: Xóa tài nguyên từ server.
CoAP cung cấp cơ chế "observe" cho phép client đăng ký nhận thông báo tự động từ server khi có sự thay đổi trạng thái tài nguyên, giúp tối ưu hóa việc giám sát mà không cần gửi yêu cầu liên tục Ngoài ra, CoAP đảm bảo giao tiếp an toàn bằng cách sử dụng DTLS (Datagram Transport Layer Security).
Security) để bảo vệ dữ liệu truyền qua mạng Các cơ chế bảo mật bao gồm:
Xác thực: Đảm bảo rằng các thiết bị giao tiếp đúng danh tính.
Mã hóa: Bảo vệ dữ liệu khỏi bị đọc lén trong quá trình truyền.
Bảo vệ toàn vẹn dữ liệu: Phát hiện và ngăn chặn dữ liệu bị sửa đổi.
ICMP
Giao thức ICMP (Internet Control Message Protocol) là một phần quan trọng trong tầng mạng của bộ giao thức TCP/IP, được thiết kế nhằm trao đổi thông điệp điều khiển và báo lỗi giữa các thiết bị mạng ICMP không phục vụ cho việc truyền tải dữ liệu người dùng, mà chủ yếu hỗ trợ quản lý và giám sát hoạt động mạng hiệu quả.
ICMP hoạt động thông qua việc gửi các gói tin, hay còn gọi là thông điệp ICMP, giữa các thiết bị mạng như router, máy tính và server Các thông điệp ICMP phổ biến bao gồm nhiều loại thông tin khác nhau, giúp quản lý và xử lý các vấn đề trong mạng.
Echo Request và Echo Reply: Được sử dụng để kiểm tra khả năng kết nối giữa hai thiết bị mạng, ví dụ thông qua công cụ ping.
Destination Unreachable: Thông báo rằng một địa chỉ đích không thể truy cập.
Time Exceeded: Báo hiệu rằng thời gian sống (TTL) của gói tin đã hết trước khi đến đích.
ICMP được sử dụng phổ biến để kiểm tra kết nối mạng và chẩn đoán sự cố, với lệnh ping là một ví dụ điển hình Lệnh ping sử dụng ICMP Echo Request để xác định xem một thiết bị mạng, thường là máy chủ, có phản hồi hay không Ngoài việc xác nhận sự tồn tại của kết nối, ping còn đo lường thời gian trễ (latency) giữa hai điểm.
Công cụ traceroute sử dụng ICMP để xác định lộ trình của gói tin qua các thiết bị trung gian trong mạng Nhờ vào ICMP, quản trị viên mạng có thể nhanh chóng phát hiện và khắc phục các sự cố như mất gói tin, độ trễ cao, và các vấn đề liên quan đến cấu hình thiết bị.
Bảo mật
2.5.1 Các thuật toán mã hóa
Mã hóa đối xứng là phương pháp mã hóa sử dụng cùng một khóa bí mật cho cả quá trình mã hóa và giải mã, làm cho nó trở thành phương pháp phổ biến nhất để bảo vệ dữ liệu truyền nhận giữa hai bên Để đảm bảo an toàn, cả bên gửi và bên nhận cần thống nhất về khóa bí mật này, vì chỉ cần có khóa là có thể giải mã thông tin.
Để đảm bảo an toàn thông tin, bên gửi và bên nhận cần thỏa thuận một khóa bí mật (secret key) dùng cho việc mã hóa và giải mã dữ liệu Việc giữ bí mật khóa này là rất quan trọng, vì nếu bên thứ ba biết được, họ có thể dễ dàng giải mã thông tin Do đó, cần có biện pháp bảo vệ để truyền tải thông tin một cách an toàn.
Trong phương pháp mã hóa đối xứng, bên gửi sử dụng một thuật toán mã hóa cùng với secret key để mã hóa dữ liệu trước khi truyền đi Bên nhận sẽ sử dụng chính secret key đó để giải mã dữ liệu Tuy nhiên, thách thức lớn nhất của phương pháp này là làm thế nào để thỏa thuận và truyền tải secret key một cách an toàn giữa bên gửi và bên nhận, bởi nếu secret key được truyền mà không có biện pháp bảo vệ, bên thứ ba có thể dễ dàng đánh cắp nó.
Hình CƠ SỞ LÝ THUYẾT-4 Minh họa mã hóa đối xứng
2.5.1.2 Mã hóa bất đối xứng
Mã hóa bất đối xứng, hay còn gọi là mã hóa khóa công khai, là một phương pháp mã hóa trong đó khóa mã hóa (khóa công khai) và khóa giải mã (khóa bí mật) là hai khóa khác nhau Khóa công khai có thể được biết đến và sử dụng bởi bất kỳ ai, bao gồm cả hacker, để mã hóa thông tin Tuy nhiên, chỉ có người nhận mới nắm giữ khóa bí mật, do đó chỉ họ mới có khả năng giải mã thông tin.
Bên nhận sẽ tạo ra một cặp khóa bao gồm khóa công khai (public key) và khóa riêng (private key) Khóa riêng sẽ được giữ bí mật bởi bên nhận, trong khi khóa công khai có thể được gửi cho bên gửi mà không cần bảo mật, vì nó là thông tin công khai.
Bên gửi trước khi gửi dữ liệu sẽ mã hóa dữ liệu bằng thuật toán mã hóa bất đối xứng với key là public key từ bên nhận.
Bên nhận sẽ sử dụng thuật toán mã hóa của bên gửi để giải mã dữ liệu, với private key làm chìa khóa giải mã Tuy nhiên, mã hóa bất đối xứng có nhược điểm lớn là tốc độ mã hóa và giải mã chậm hơn so với mã hóa đối xứng, dẫn đến chi phí cao khi áp dụng cho việc truyền nhận dữ liệu giữa hai bên.
Mã hóa bất đối xứng được sử dụng để bảo mật secret key trong mã hóa đối xứng Cụ thể, bên gửi sẽ sử dụng phương pháp mã hóa bất đối xứng để truyền secret key cho bên nhận Sau khi nhận được secret key, cả hai bên sẽ sử dụng nó để trao đổi thông tin thông qua mã hóa đối xứng.
Hình CƠ SỞ LÝ THUYẾT-5 Minh họa mã hóa bất đối xứng
2.5.2 Các giao thức bảo mật
SSL (Secure Sockets Layer) là giao thức mã hóa thiết yếu cho việc truyền thông an toàn qua internet, đảm bảo mã hóa và xác thực dữ liệu giữa nguồn và đích Hoạt động ở tầng vận chuyển trong bộ giao thức TCP/IP, SSL tạo ra kênh mã hóa bảo vệ thông tin nhạy cảm như thẻ tín dụng và thông tin đăng nhập khỏi truy cập trái phép và giả mạo.
Trong thời đại kỹ thuật số hiện nay, việc bảo vệ dữ liệu cá nhân trong quá trình truyền tải qua internet là rất quan trọng Dữ liệu thường đi qua nhiều trạm trung gian, làm tăng nguy cơ bị chặn hoặc sửa đổi SSL giải quyết vấn đề này bằng cách mã hóa dữ liệu, giúp nó trở nên không thể đọc được đối với những người không có quyền truy cập Hơn nữa, SSL còn đảm bảo rằng dữ liệu được gửi đến đúng người nhận và không bị thay đổi trong quá trình truyền tải.
7 đổi trong quá trình truyền Điều này là rất quan trọng để duy trì tính tin cậy và bảo mật trong các giao dịch trực tuyến.
SSL và TLS là các giao thức mã hóa quan trọng cho việc truyền thông an toàn trên internet SSL, do Netscape Communications phát triển, đã được nâng cấp thành TLS (Transport Layer Security) bởi Internet Engineering Task Force (IETF) Mặc dù SSL và TLS thường được sử dụng thay thế cho nhau, TLS đã trở thành tiêu chuẩn công nghiệp với các tính năng bảo mật và thuật toán mã hóa tiên tiến hơn, mang lại độ an toàn và độ tin cậy cao hơn Tuy nhiên, cả hai giao thức này đều có chức năng và mục đích giống nhau là thiết lập kết nối an toàn và bảo vệ dữ liệu trong quá trình truyền.
DTLS (Datagram Transport Layer Security) là một phiên bản của TLS hoạt động trên giao thức UDP (User Datagram Protocol), khác với TCP (Transmission Control Protocol) DTLS được thiết kế để sử dụng trên các mạng không đáng tin cậy, phù hợp cho các ứng dụng thời gian thực như truyền thông VoIP và phát trực tuyến Nó cung cấp tính toàn vẹn, mã hóa và xác thực cho các thông điệp trong giao tiếp UDP, làm cho DTLS trở thành lựa chọn lý tưởng cho những ứng dụng mà độ trễ quan trọng hơn độ tin cậy.
Chứng chỉ CA, hay Chứng chỉ Kỹ thuật số, được phát hành bởi Tổ chức Chứng nhận (Certificate Authority - CA) là một bên thứ ba đáng tin cậy, giúp xác thực danh tính của các thực thể như trang web, tổ chức hoặc cá nhân trên mạng Vai trò của chứng chỉ CA rất quan trọng trong việc đảm bảo tính bảo mật, toàn vẹn và độ tin cậy của các giao dịch cũng như truyền thông trực tuyến.
Vai trò của chứng chỉ CA
Xác thực danh tính là quá trình mà các Tổ chức Chứng thực (CA) thực hiện để xác minh danh tính của cá nhân hoặc tổ chức trước khi cấp chứng chỉ Điều này đảm bảo rằng thực thể được chứng thực là đáng tin cậy Chẳng hạn, một chứng chỉ SSL/TLS từ CA cho một trang web giúp người dùng yên tâm rằng họ đang giao tiếp với đúng trang web đó, không phải một trang giả mạo.
Mã hóa dữ liệu là một phần quan trọng trong bảo mật thông tin, với các chứng chỉ do CA cấp thường được sử dụng trong các giao thức như SSL/TLS Những chứng chỉ này giúp mã hóa dữ liệu giữa máy khách và máy chủ, bảo vệ thông tin khỏi việc nghe lén và can thiệp.
Tạo niềm tin là yếu tố quan trọng, vì CA là tổ chức trung gian được công nhận, người dùng có thể hoàn toàn yên tâm về tính xác thực và bảo mật của các chứng chỉ mà CA phát hành.
Cấu trúc của chứng chỉ CA
Chứng chỉ CA thường tuân theo tiêu chuẩn X.509 và chứa các thông tin sau:
Tên của chủ thể được cấp chứng chỉ (Common Name - CN).
Khóa công khai của thực thể được chứng thực.
Tên của tổ chức phát hành (CA).
Thời hạn hiệu lực của chứng chỉ.
Chữ ký số của CA, xác nhận tính hợp lệ và không bị giả mạo của chứng chỉ. Quy trình hoạt động của chứng chỉ CA
Tạo yêu cầu chứng chỉ (CSR - Certificate Signing Request):
Một tổ chức hoặc cá nhân gửi CSR đến CA, chứa thông tin khóa công khai và danh tính.
CA kiểm tra danh tính của bên yêu cầu thông qua các biện pháp như xác minh tên miền, giấy tờ pháp lý hoặc liên hệ trực tiếp.
Sau khi xác minh thành công, CA phát hành chứng chỉ kỹ thuật số và ký bằng khóa riêng của mình.
Chứng chỉ được cài đặt trên máy chủ hoặc ứng dụng, giúp xác thực và mã hóa kết nối với máy khách.
PHƯƠNG PHÁP NGHIÊN CỨU
ThingsBoard – Open-source IoT Platform
Dưới đây là môt vài entities cơ bản của ThingsBoard
- Devices: các IoT entities cơ bản mà có thể tạo ra telemetry data, xử lí các lệnh RPC Ví dụ như cảm biến, cơ cấu chấp hành, …
- Assets: các IoT entities trìu tượng mà có thể liên quan đến các devices và assets khác Ví dụ như factory, field, vehicle
- Dashboards: trực quan hóa dữ liệu IoT và có thể dùng để điều khiển các devices cụ thể thông qua user interfeace
- Attributes: cặp key-value tĩnh và bán tĩnh được liên kết với các thực thể
Ví dụ: serial number, model, firmware version.
- Time-series data: time-series data points cho lưu trữ, truy vấn và trực quan Ví dụ nhiệt độ, nhiệt độ, …
- Relations: các kết nối có hướng tới các entities khác Ví dụ như contains, manages, owns, …
Entity relation định nghĩa kết nối giữa 2 ThingsBoard entities cùng thuộc 1 Tenant
In ThingsBoard, relations can take various forms such as Contains, Manages, or Supports, and they also have a directional aspect These relations can be likened to Has-a relationships found in object-oriented programming, emphasizing the interconnectedness of different entities within the platform.
Relations trong ThingsBoard cho phép mô hình hóa các đối tượng vật lý, như trong ứng dụng thu thập dữ liệu từ cảm biến độ ẩm đất và nhiệt độ Người dùng có thể trực quan hóa dữ liệu qua dashboard, xác định vấn đề, nâng cao cảnh báo và điều khiển quá trình tưới tiêu Hệ thống hỗ trợ nhiều trường với hàng trăm cảm biến, và các trường có thể được gộp theo vùng địa lý Hình minh họa dưới đây thể hiện các entities được cấu hình và lưu trữ trên ThingsBoard.
Hình PHƯƠNG PHÁP NGHIÊN CỨU-6 Một ví dụ các thực thể được cấu hình và lưu trữ trên ThingsBoard
3.1.2 Rule Engine Định nghĩa: Rule Engine là một framework dễ dùng để xây dựng quy trình làm việc dựa trên sự kiện, có 3 thành phần chính:
- Message: bất kì event tới nào, có thể là data tới từ devices, device life- cycle event, REST API event, RPC request, etc.
- Rule Node: là hàm thực hiện trên các message tới Có nhiều loại Node để filter, transform hoặc thực hiện một vài hành động trên Message tới
- Rule Chain: các nodes được kết nối với nhau bằng các relations, các message gửi theo chiều relations.
Hình PHƯƠNG PHÁP NGHIÊN CỨU-7 Root Rule Chain mặc định của ThingsBoard Các kiểu Rule Node:
- Filter Nodes: được sử dụng để lọc message và routing
- Enrichment Nodes: được sử dụng để cập nhật meta-data của message tới
- Transformation Nodes: được sử dụng để biến đổi các trường message tới như Originator, Type, Payload, Metadata
- Action nodes: chạy các hành động khác nhau dựa trên message tới
- External Nodes: được sử dụng để tương tác với hệ thống bên ngoài
ThingsBoard enables Remote Procedure Calls (RPC) between server-side applications and devices, facilitating the sending of commands to and from devices while receiving execution results.
Client-side RPC cho phép gửi request từ device đến nền tảng và nhận phản hồi về thiết bị
Một số trường hợp sử dụng điển hiển của client-side RPC calls:
- Hệ thống tưới tiêu lấy dự báo thời tiết từ dịch vụ trực tuyến qua nền tảng
- Các thiết bị với tài nguyên hạn chế, không có system clock, requests timestamps hiện tại từ nền tảng
Thiết bị gửi tin nhắn đến nền tảng, nơi tin nhắn được xử lý bởi Rule Engine Rule Engine thực hiện các tính toán dựa trên thuộc tính thiết bị, dữ liệu telemetry và các thông tin khác lưu trữ trên nền tảng Nếu cần, Rule Engine cũng có thể truy cập hệ thống bên ngoài Sau khi xử lý xong, kết quả sẽ được gửi trở lại thiết bị.
Hình PHƯƠNG PHÁP NGHIÊN CỨU-8 Cilent-side RPC
Client-side RPC request gồm 2 trường, và cả hai đều là bắt buộc:
- method: tên của method đặc trưng cho RPC calls Ví dụ,
“getCurrentTime” or “getWeatherForecast” Giá trị của tham số là một string.
Các tham số phụ trong xử lý request được định dạng dưới dạng JSON và có thể để trống nếu không sử dụng ({}) ThingsBoard hỗ trợ gửi client-side RPC từ thiết bị thông qua các giao thức MQTT, CoAP và HTTP.
Server-side RPC cho phép người dùng gửi request từ nền tảng tới device và tùy chọn nhận phản hồi ngược lại nền tảng.
Các trường hợp sử dụng phổ biến là reboot, tắt bật động cơ, thay đổi trạng thái gpio/actuators, thay đổi cấu thình tham số, etc.
Server-side RPC được chia thành one-way và two-way
- One-way RPC request không cần device cung cấp bấy kỳ phản hồi nào
Hình PHƯƠNG PHÁP NGHIÊN CỨU-9 One-way server-side RPC
- Two-way RPC request cần nhận phản hồi từ device trong khoảng thời gian timeout
Hình PHƯƠNG PHÁP NGHIÊN CỨU-10 Two-way server-side RPC
Cấu trúc Server-side RPC structure
- method: bắt buộc, tên của method đặc trưng cho RPC calls Ví dụ,
“getCurrentTime” hoặc “getWeatherForecast” Giá trị của tham số là string.
- params: bắt buộc, các tham số được sử dụng cho xử lí request Giá trị là
JSON Bỏ trống ({}) nếu không cần tham số.
- timeout: tùy chọn, giá trị thời gian chờ xử lí tính bằng milliseconds Mặc định là 10s, giá trị nhỏ nhất là 5s.
To send server-side RPC, it is typically done through REST API or dashboard widgets, which utilize the same REST API Once the platform receives the RPC, it evaluates the payload and performs authorization checks The server-side RPC command is then forwarded to the Rule Engine, which can enrich the command with additional parameters before ultimately dispatching it to the device.
Socket Programming với Python
Python hỗ trợ socket programming thông qua thư viện built-in socket Dưới đây là cách sử dụng cơ bản của thư viện này
3.2.1 Tạo client Để khởi tạo chế độ này, ta làm các bước sau:
- Tạo socket object sử dụng lớp socket của thư viện, theo kèm là hai đối số AF_INET và SOCK_STREAM với TCP hoặc SOCK_DGAM với UDP
Để truyền dữ liệu qua TCP, cần thiết lập một kết nối, vì vậy phương thức connect yêu cầu một tuple chứa địa chỉ IP và PORT Ngược lại, UDP không yêu cầu quá trình này.
To send a TCP request, use the send method with the message encoded in binary format In contrast, for UDP, the sendto method is utilized along with the message and a tuple containing the IP address and port number.
- Để đọc dữ liệu nhận về sử dụng method recv, với đối số là bufsize
- Đóng socket sử dụng close.
Có thể sử dụng method settimeout với đối số là thời gian theo giây, để định nghĩa thời gian chờ.
3.2.2 Tạo server Để tạo localhost sử dụng socket có thể thực hiện theo các bước sau:
- Tạo socket object sử dụng lớp socket của thư viện, theo kèm là hai đối số AF_INET và SOCK_STREAM với TCP hoặc SOCK_DGAM với UDP
- Sử dụng method bind để gán địa chỉ và cổng cho Socket, đối với localhost sẽ là “0.0.0.0” với PORT người dùng định nghĩa
- Chỉ định socket lắng nghe kết nối với method listen, có thể thêm số lượng tối đa các kết nối đang chờ làm đối số
Khi chờ chấp nhận kết nối với TCP, phương thức accept sẽ được sử dụng để nhận một cặp socket mới, cho phép gửi và nhận dữ liệu kết nối cùng với địa chỉ của bên đối diện Ngược lại, UDP không yêu cầu quá trình này.
- Nhận dữ liệu được gửi đến bằng method recv đối với TCP và recvfrom đối với UDP
- Server có thể phản hồi thông qua method send đối với TCP và sendto với UDP
- Để đóng socket có thể sử dụng method close
KẾT QUẢ THỰC NGHIỆM
ThingsBoard Tenant
Tenant là một thực thể trong ThingsBoard, tương tự như một tài khoản cho phép người dùng định nghĩa và quản lý các thực thể khác Trong phần này, nhóm sẽ định nghĩa các thực thể và rule chain, tạo nền tảng cho việc triển khai các thử nghiệm phía dưới.
Nhóm sử dụng 2 entities lần lượt là Sensors và Measurement and Control System
- Sensors được thể hiện là Device với tên là Sensors, nhãn là Sensors
- Measurement and Control System là một Asset với tên là Measurement and Control system và nhãn giống như tên
- Relation giữa 2 entities là from Measurement and Control System to Sensors với kiểu là Contains
Hình KẾT QUẢ THỰC NGHIỆM-11 Rule Chain Configuration
Rule Chain trong Hình KẾT QUẢ THỰC NGHIỆM-11 kế thừa Rule Chain mặc đ ịnh Có 2 thay đổi chính:
- Tất cả dữ liệu từ Devices được Asset Contains sẽ được cập nhật vào dữ liệu của Asset
- Các RPC Request thực hiện lấy dữ liệu từ Asset, biến đổi và thực hiện RPC Reply về các Clients
Với Rule Chain, nhóm có khả năng quản lý tất cả dữ liệu cảm biến và các yêu cầu RPC gửi đến thiết bị cảm biến Dưới đây là một số cuộc gọi RPC mà nhóm đã định nghĩa để sử dụng trong dự án môn học.
- “getLightControlSignal”, không tham số: Trả về tín hiệu điều khiển dựa trên dữ liệu ánh sáng cuối cùng nhận được
- “getHumidityControlSignal”, không tham số: Trả về tín hiêu điều khiển dựa trên dữ liệu độ ẩm cuối cùng nhận được
- “getLightBoundValues”, không tham số: Trả về các giá trị ngưỡng được người dùng gửi lên
- “getHumidityBounđValues”, không tham số: Trả về các giá trị ngưỡng được người dùng gửi lên
Kết quả thực nghiệm từ nút Transformation dựa trên dữ liệu cuối cùng của cảm biến ánh sáng, cung cấp giá trị điều khiển cho cơ cấu chấp hành.
Sử dụng các widgets của ThingsBoard nhóm xây dựng một vài biểu đồ để giám sát hệ thống trong quá trình vận hành
Hình KẾT QUẢ THỰC NGHIỆM-13 DashBoards đơn giản để giám sát hệ thống
Controller
Controller sẽ lưu trữ các giá trị cảm biến và điều khiển các cơ cấu chấp hành dựa trên những giá trị này Để phát triển một Controller nhóm, chúng ta sẽ sử dụng ngôn ngữ lập trình Python cùng với thư viện Socket như đã đề cập trước đó.
Do không thể đưa tất cả code vào đây nên phần này sẽ chỉ mô tả các thành phần chính của controller
Hình KẾT QUẢ THỰC NGHIỆM-14 Sơ đồ thuật toán của Controller
4.2.1 Xây dựng khối Connected to the Internet Để biết khi nào hoạt động ở chế độ server khi nào hoạt động ở chế độ client, cần phải biết trạng thái Internet hiện tại Để làm được điều đó, nhóm sử dụng socket, cố gắng kết nối đến một server nổi tiếng như “google.com” trong một khoảng thời gian chờ định nghĩa trước (khoảng 1s), nếu không có phản hồi tức là không có Internet.
Controller gửi các yêu cầu RPC đến server để nhận giá trị ngưỡng từ người dùng Vì tính chất ít thay đổi của các giá trị này, thời gian giữa các lần gửi yêu cầu có thể kéo dài khoảng 10 giây.
Khi Internet được khôi phục, Controller sẽ gửi các dữ liệu đã được lưu trữ trong bộ đệm cùng với timestamps lên ThingsBoard trước khi thực hiện các RPC calls, nhằm đồng bộ hóa với dữ liệu trong thời gian mất kết nối.
Nhóm đã sử dụng socket cho cả HTTP và CoAP, với các thủ tục cơ bản tương tự nhau Điều quan trọng là phải chuẩn bị message và các header đúng cách, nhằm đảm bảo server có thể hiểu và phản hồi theo yêu cầu của chúng ta.
Với HTTP, nhóm sử dụng header đơn giản như sau
Hình KẾT QUẢ THỰC NGHIỆM-15 HTTP header với POST request
Với CoAP, nhóm sử dụng header như sau:
Hình KẾT QUẢ THỰC NGHIỆM-16 CoAP header với POST request kiểu NON-
Header của CoAP không giống như HTTP và việc mã hóa thành header chuẩn gặp nhiều khó khăn Do đó, nhóm đã quyết định viết header CoAP dưới dạng nhị phân, đồng thời sử dụng phần mềm WireShark để hỗ trợ quá trình này.
MQTT không hoạt động theo mô hình client-server, do đó việc xây dựng trên socket sẽ tốn nhiều thời gian Nhóm đã quyết định sử dụng thư viện Python Client SDK 1 do ThingsBoard phát triển để tiết kiệm công sức và thời gian.
Để xây dựng server, nhóm đã thiết lập localhost với PORT 10000 cho HTTP và CoAP, cùng với PORT 9999 cho MQTT Cụ thể, CoAP và HTTP sẽ được cấu hình để thêm thời gian timeout, nhằm kiểm tra lại kết nối Internet và tự động reconnect khi Internet được phục hồi.
Trong sơ đồ thuật toán, Controller hoạt động như một Tennant trong chế độ server, tương tự như Rule Chain đã đề cập trước đó Thuật toán nhóm xây dựng hỗ trợ việc cập nhật dữ liệu Telemetry và một số lệnh RPC như “getLightControlSignal”.
Ngay khi có kết nối Internet các dữ liệu được lưu trữ khi Offline sẽ được đẩy lại lên ThingsBoard server.
4.2.4 Phân luồng Để Controller có thể xử lí cùng một lúc 3 giao thức HTTP, CoAP và MQTT Ta cần phân luồng xử lí Ở đây nhóm sử dụng thư viện built-in Threading của Python. Dưới đây là đoạn code thực hiện việc phân luồng.
Hình KẾT QUẢ THỰC NGHIỆM-17 Threading
1 https://ThingsBoard.io/docs/reference/python-client-sdk/
Đo và điều khiển ánh sáng từ thiết bị (giao thức HTTP)
- ThingsBoard platform và Controller đã được cấu hình ở trên
- ESP32 (Device): Đồng thời đóng vai trò thu thập dữ liệu và điều khiển cơ cấu chấp hành
- Trình biên dịch: Arduino IDE, thư viện liên quan (WiFi, HTTPClient)
4.3.2.1 Cập nhật telemetry data và thực hiện RPC call lên ThingsBoard
Giả sử người dùng đã thiết lập giới hạn trên là 100 và giới hạn dưới là 50 Tín hiệu thu được từ cảm biến sẽ là các số ngẫu nhiên phân bố đều trong khoảng này.
Thiết bị sẽ gửi telemetry data lên Server, đồng thời gọi RPC calls để nhận về tín hiệu điều khiển cho cơ cấu chấp hành.
Hình KẾT QUẢ THỰC NGHIỆM-18 DashBoards giám sát dữ liệu được gửi lên bởi cảm biến ánh sáng
Hình KẾT QUẢ THỰC NGHIỆM-19 Serial Monitor của ESP32 thực hiện đo và điều khiển ánh sáng, update telemetry data và request RPC calls
4.3.2.2 Cập nhật telemetry data và thực hiện RPC call lên Controller
Controller sẽ tạm thời lưu trữ các dữ liệu telemetry khi mất kết nối Internet và tự động chuyển chúng lên Server ngay khi có lại kết nối Dưới đây là một số kết quả demo liên quan đến giao thức HTTP.
Hình KẾT QUẢ THỰC NGHIỆM-20 Terminal của Controller, thực hiện chứa các thông tin về ánh sáng và xử lí các RPC calls khi không có kết nối Internet
Hình KẾT QUẢ THỰC NGHIỆM-21 Serial Monitor của ESP32 khi gửi dữ liệu ánh sáng và request RPC calls lên Controller
4.3.3 HTTPS Để thực hiện HTTP bảo mật, ta cần sử dụng thư viện WiFiSecureClient thay vì WiFi như đối với các giao thức không có bảo mật Bên cạnh đó, ta cần có thông tin về chứng chỉ số (CA certificate) của server ThingsBoard để xác nhận kết nối an toàn, từ đó gửi những bản tin mã hóa thông quan thư viện WiFiSecureClient.
4.3.3.1 Gửi dữ liệu ánh sáng từ thiết bị lên ThingsBoard
Hình KẾT QUẢ THỰC NGHIỆM-22 Chương trình gửi dữ liệu ánh sáng từ thiết bị lên
4.3.3.2 Gửi dữ liệu ánh sáng từ controller lên ThingsBoard
Hình KẾT QUẢ THỰC NGHIỆM-23 Gửi dữ liệu ánh sáng từ controller lên Thinsboard
Đo và điều khiển độ ẩm từ thiết bị (CoAP)
ThingsBoard platform và Controller được cấu hình như trên.
Arduino IDE: sử dụng thư viện coap-simple
Micropython: sử dụng thư viện microcoapy
4.4.2 Phương thức Để gửi dữ liệu đo từ xa (telemetry) lên ThingsBoard, ta sử dụng phương thức POST trong CoAP Đích đến sẽ là trường “telemetry” của ThingsBoard với port mặc định của ThingsBoard là port 5683. Để gửi lệnh RPC lên ThingsBoard, ta tiếp tục sử dụng phương thức POST trong CoAP Đích đến sẽ là trường “rpc” của ThingsBoard Lúc này, ESP32 sẽ nhận được phản hồi từ ThingsBoard những dữ liệu hoặc lệnh đã thiết lập trước tại Rule Chain và Rule Engine trên ThingsBoard Ở đây, Rule Chain được thiết lập 1 cách khá tương đồng với Rule Chain trong phần mục HTTP Tín hiệu trả về sẽ là tín hiệu điều khiển đặc trưng cho 3 mức độ hoạt động của cơ cấp chấp hành, ở đây là máy bơm nước hoặc hệ thống tưới tiêu.
Hình KẾT QUẢ THỰC NGHIỆM-24: Chương trình gửi dữ liệu độ ẩm bằng CoAP trên ESP32 sử dụng MicroPython
Hình KẾT QUẢ THỰC NGHIỆM-25: Kết quả trên consolo MicroPython
Hình KẾT QUẢ THỰC NGHIỆM-26: Chương trình gửi lệnh RPC lên ThingsBoard trên ESP32 sử dụng MicroPython
Kết quả thực nghiệm-27 cho thấy phản hồi từ ThingsBoard dựa trên dữ liệu độ ẩm mà server nhận được Để sử dụng thư viện coap-simple trên Arduino IDE, cần chỉnh sửa mã nguồn theo hướng dẫn trong file Log.docx.
Sau khi thiết lập ThingsBoard và Controller như mục 4.1 và 4.2, việc gửi và chuyển hướng dữ liệu bằng CoAP cũng được thực hiện tương tự.
Hình KẾT QUẢ THỰC NGHIỆM-28 Chương trình gửi dữ liệu và RPC CoAP bằng thư viện coap-simple bởi Arduino
4.4.3.1 Cập nhật telemetry data và gửi RPC call lên ThingsBoard
Hình KẾT QUẢ THỰC NGHIỆM-29 Kết quả cập nhật dữ liệu độ ẩm từ thiết bị lên
Hình KẾT QUẢ THỰC NGHIỆM-30 Kết quả trên Serial Monitor gửi dữ liệu độ ẩm bằng CoAP 4.4.3.2 Cập nhật telemetry data và gửi RPC call lên Controller
Hình KẾT QUẢ THỰC NGHIỆM-31 Truyền thông giữa thiết bị và Controller khi mất
Hình KẾT QUẢ THỰC NGHIỆM-32 Kết quả trên Serial Monitor truyền thông CoAP từ thiết bị
Đo và gửi dữ liệu nhiệt độ từ thiết bị (giao thức MQTT)
- ThingsBoard platform và controller được thiết lập như trên.
- Arduino IDE và các thư viện liên quan (WiFi, PubSubClient).
4.5.2 Triển khai Đầu tiên, ta sẽ tạo một kết nối giữa thiết bị và server bởi câu lệnh setServer(server, port) Sau đó, ta sẽ gửi một payload lên bằng cách đăng ký client với topic
“telemetry” trên ThingsBoard bởi câu lệnh “publish”.
Hình KẾT QUẢ THỰC NGHIỆM-33 Chương trình gửi dữ liệu nhiệt độ từ thiết bị đến server bằng MQTT
4.5.3.1 Cập nhật telemetry data lên ThingsBoard
Hình KẾT QUẢ THỰC NGHIỆM-34 Cập nhật dữ liệu nhiệt độ trên ThingsBoard từ thiết bị bằng MQTT
Hình KẾT QUẢ THỰC NGHIỆM-35 Kết quả trên console Arduino IDE gửi dữ liệu nhiệt độ lên ThingsBoard bằng MQTT 4.5.3.2 Cập nhật telemetry data lên Controller
Hình KẾT QUẢ THỰC NGHIỆM-36 Cập nhật dữ liệu nhiệt độ từ thiết bị lên
Hình KẾT QUẢ THỰC NGHIỆM-37 Kết quả gửi dữ liệu nhiệt độ từ thiết bị bằng
Triển khai ICMP
Thư viện ESPping có sẵn trên Arduino IDE
Trường hợp 1: Sử dụng mạng Wifi có kết nối Internet đã biết (tại nhà)
Trong trường hợp này, ta kỳ vọng sẽ “Ping” được server/IP
Trường hợp 2: Sử dụng mạng Wifi không có kết nối Internet
Trong trường hợp này, ta kỳ vọng sẽ không “Ping” được server/IP
Hình KẾT QUẢ THỰC NGHIỆM-38: Chương trình thực hiện Ping một vài server “đã biết” trên ESP32
Hình KẾT QUẢ THỰC NGHIỆM-39: Phản hồi khi có kết nối Internet
Hình KẾT QUẢ THỰC NGHIỆM-40: Phản hồi khi không có kết nối Internet nhưng vẫn kết nối Wifi
LỜI KẾT
Bài tập lớn này là kết quả của sự làm việc hiệu quả và kỷ luật của Tú Linh và Ngọc Thuận Thành công này có được nhờ vào những buổi thảo luận, trao đổi vấn đề và hỗ trợ sửa lỗi lẫn nhau Đặc biệt, xin gửi lời cảm ơn đến Ngọc Thuận vì đã đóng góp quan trọng trong việc sửa lỗi nhờ vào kiến thức vững vàng về các giao thức Cuối cùng, cảm ơn thầy và anh trợ giảng đã tổ chức nhiều buổi trao đổi, giúp cả nhóm hiểu rõ hơn về bài tập lớn.
