MQTT so với HTTP so với Modbus TCP so với OPC UA cho Cổng IoT công nghiệp

Dữ liệu cảm biến giống nhau có thể được phân phối theo những cách khác nhau

Cảm biến không xác định đám mây cuối cùng hoặc giao thức SCADA. RS485 Modbus RTU thường được sử dụng ở lớp thiết bị hiện trường, trong khi cổng dịch hoặc đóng gói lại dữ liệu đó cho lớp ứng dụng. Giao thức ngược dòng chính xác phụ thuộc vào người bắt đầu giao tiếp, nơi lưu trữ dữ liệu, liệu các lệnh có phải quay lại thiết bị hay không và khách hàng đã vận hành phần mềm nào.

MQTT: Tốt nhất cho Hệ thống xuất bản/đăng ký theo định hướng đám mây

MQTT tách người gửi và người nhận thông qua một nhà môi giới. Cổng xuất bản dữ liệu cảm biến cho một chủ đề, trong khi một hoặc nhiều ứng dụng đăng ký chủ đề đó. Điều này rất hữu ích cho các trang web giám sát phân tán vì cổng không cần biết mọi người sử dụng dữ liệu cuối cùng.

Cấu hình MQTT chính xác thường bao gồm địa chỉ nhà môi giới, cổng, ID khách hàng, xác thực và quy tắc chủ đề. Một lỗi phổ biến là cho rằng “thiết bị trực tuyến” có nghĩa là “dữ liệu đã đến”. Trạng thái kết nối MQTT chỉ chứng minh rằng phiên đã được thiết lập. Cổng vẫn có thể xuất bản sai chủ đề, máy chủ có thể đăng ký một chủ đề khác hoặc lớp thu thập cảm biến có thể không có dữ liệu hợp lệ.

Xuất bản và đăng ký không được nhầm lẫn

Chủ đề xuất bản là nơi thiết bị gửi dữ liệu đo từ xa. Chủ đề đăng ký thường được sử dụng cho các lệnh hoặc tin nhắn được gửi từ nền tảng trở lại thiết bị. Nếu máy chủ muốn nhận số đo, nó phải đăng ký chủ đề xuất bản cổng. Việc sử dụng cùng một chủ đề xuất bản và đăng ký có thể tạo ra các vòng lặp không mong muốn trong một số hoạt động triển khai và không được coi là cấu hình mặc định.

MQTTS và Cổng 8883

MQTTS thường có nghĩa là MQTT trên TLS. Cổng 8883 là cổng TLS phổ biến, nhưng việc sử dụng thành công phụ thuộc vào nhiều thứ hơn là số cổng. Thư viện TLS, phương thức xác thực CA, chứng chỉ máy chủ, chứng chỉ ứng dụng khách tùy chọn và phiên bản MQTT phải tương thích. Trong thử nghiệm đám mây thực sự của bên thứ ba, một cổng đôi khi có thể kết nối với một nhà môi giới TLS nhưng không thành công với một nhà môi giới khác cho đến khi chương trình cơ sở được cập nhật.

Đối với các dự án sản xuất, hãy kiểm tra chính xác nhà môi giới, chế độ chứng chỉ và chương trình cơ sở trước khi vận chuyển một lô lớn. Chứng chỉ phải đến từ hoặc khớp với máy chủ của khách hàng hoặc nền tảng đám mây; chúng không phải là các tệp chung mà nhà sản xuất cổng có thể phát minh độc lập với máy chủ.

HTTP POST: Tốt nhất khi khách hàng sở hữu Web Endpoint

HTTP thường là lựa chọn đơn giản nhất khi khách hàng có ứng dụng máy chủ có thể nhận được yêu cầu POST. Cổng có thể được định cấu hình như một máy khách HTTP và định kỳ gửi JSON tới URL mục tiêu. Điều này phù hợp với các môi trường và chương trình phụ trợ web tùy chỉnh nơi nhóm phần mềm thích xử lý yêu cầu/phản hồi trực tiếp thay vì vận hành một nhà môi giới MQTT.

Tải trọng thông thường có thể chứa dấu thời gian, ID trạm và đối tượng thông số có giá trị cảm biến. Tên trường chính xác là quy ước của dự án. Bước quan trọng là thống nhất về loại dữ liệu, đơn vị, hành vi thiếu dữ liệu và phản hồi của máy chủ trước khi triển khai.

Modbus TCP: Tốt nhất khi SCADA hoặc PLC nên truy vấn dữ liệu

Modbus TCP mang mô hình thanh ghi Modbus quen thuộc qua Ethernet. Nó thường phù hợp khi hệ thống PLC, HMI hoặc SCADA đã được thiết kế dưới dạng Modbus chính. Cổng có thể kết nối các thiết bị RS485 Modbus RTU với phía Ethernet hoặc hiển thị các giá trị được thu thập thông qua bản đồ đăng ký được xác định.

Nếu khách hàng nói: “Hãy cung cấp cho chúng tôi địa chỉ IP và cho chúng tôi biết nơi mỗi tín hiệu được lưu trữ; hệ thống của chúng tôi sẽ đọc nó”, Modbus TCP thường gần với kiến trúc được yêu cầu hơn MQTT hoặc HTTP.

OPC UA: Tốt nhất cho sự hội nhập công nghiệp phong phú hơn

OPC UA được sử dụng rộng rãi trong phần mềm công nghiệp vì nó có thể trình bày dữ liệu dưới dạng thẻ hoặc nút được đặt tên có cấu trúc và siêu dữ liệu thay vì chỉ có địa chỉ thanh ghi số. Nó có thể phù hợp với SCADA, các ứng dụng PC và phần mềm trung gian công nghiệp cần hành vi đăng ký và khám phá được tiêu chuẩn hóa.

Không phải mọi cổng đều hỗ trợ OPC UA với vai trò giống nhau, vì vậy hãy xác nhận xem nó hoạt động như máy chủ, máy khách OPC UA hay cả hai. Trong các dự án NiuBoL, các cổng biên có khả năng cao hơn sẽ được ưu tiên khi OPC UA là yêu cầu cốt lõi.

Bạn nên chọn giao thức nào?

Không kết hợp giao thức trường và giao thức ngược dòng

Một hệ thống có thể sử dụng RS485 Modbus RTU từ cảm biến đến cổng và MQTT từ cổng đến đám mây cùng một lúc. Nó cũng có thể sử dụng 4–20mA cảm biến vào cổng ADC và sau đó hiển thị các giá trị đó thông qua Modbus TCP hoặc OPC UA. Giao diện trường và giao thức ứng dụng là các lớp thiết kế riêng biệt.

Xử lý sự cố: Đã kết nối MQTT nhưng không có dữ liệu

1. Xác nhận lớp cảm biến thực sự đang tạo ra dữ liệu bên trong cổng.
2. Kiểm tra khoảng thời gian tải lên và xác nhận cổng đang xuất bản chứ không chỉ được kết nối.
3. Xác minh chính xác chủ đề xuất bản, bao gồm các dấu gạch chéo ở đầu và phân biệt chữ hoa chữ thường trong đó nhà môi giới/nền tảng xử lý chúng theo cách khác.
4. Sử dụng ứng dụng khách MQTT độc lập để đăng ký cùng một chủ đề và tách biệt cổng khỏi nền tảng kinh doanh.
5. Kiểm tra xác thực, xung đột ID ứng dụng khách và liệu ứng dụng khách khác có đang sử dụng cùng thông tin xác thực hay không.
6. Đối với TLS, hãy xác minh khả năng tương thích chứng chỉ CA/máy chủ và thư viện chương trình cơ sở.
7. Sử dụng nhật ký cổng và, nếu cần, chụp mạng để xác định xem các gói có rời khỏi thiết bị hay không và cách máy chủ phản hồi.

Xử lý sự cố: Máy chủ HTTP không nhận được gì

Việc mua lại riêng biệt đầu tiên từ tải lên. Nếu nhật ký cổng cho biết thiết bị thấp hơn không phản hồi, hãy sửa lớp giao tiếp cảm biến trước khi gỡ lỗi máy chủ. Sau đó xác minh URL mục tiêu, cổng, khả năng tiếp cận DNS/mạng, loại nội dung, định dạng JSON và các yêu cầu HTTPS. Chức năng HTTP cổng trong kiến ​​trúc này là một ứng dụng khách chủ động POST dữ liệu; nó không tự động là một máy chủ HTTP để khách hàng duyệt.

Câu hỏi thường gặp

Q1: MQTT có tốt hơn HTTP cho IoT không?

A1: Cả hai đều không tốt hơn. MQTT mạnh mẽ cho nhóm xuất bản/đăng ký; HTTP rất đơn giản khi khách hàng đã có điểm cuối nhận web.

Q2: MQTT “trực tuyến” có nghĩa là nền tảng đã nhận được dữ liệu cảm biến?

A2: Không. Trạng thái trực tuyến chỉ xác nhận kết nối. Chủ đề, xuất bản, đăng ký và thu thập cảm biến vẫn phải được xác minh.

Q3: Sự khác biệt giữa các chủ đề xuất bản và đăng ký MQTT là gì?

A3: Xuất bản là nơi cổng gửi dữ liệu đo từ xa; đăng ký là nơi cổng lắng nghe các tin nhắn hoặc lệnh từ máy chủ đến thiết bị.

Q4: Cổng IoT có thể gửi JSON bằng HTTP POST không?

A4: Có, trên các cổng/chương trình cơ sở hỗ trợ tải lên ứng dụng khách HTTP. Đồng ý về cấu trúc JSON chính xác và cách xử lý phản hồi với nhóm máy chủ.

Q5: Cổng 8883 có luôn được hỗ trợ cho MQTTS không?

A5: 8883 là phổ biến, nhưng phần sụn cổng và chế độ chứng chỉ TLS phải tương thích với nhà môi giới mục tiêu. Yêu cầu dự án đối với tích hợp hệ thống cảm biến: Ghi lại dải đo đã thống nhất, phản ứng cảnh báo, kiểm tra giao diện và bằng chứng bảo trì trong hồ sơ chạy thử hoặc nghiệm thu.

Q6: Khi nào tôi nên sử dụng Modbus TCP thay vì MQTT?

A6: Sử dụng Modbus TCP khi một bậc thầy công nghiệp như PLC hoặc SCADA nên chủ động truy vấn các thanh ghi qua Ethernet.

Q7: Khi nào thì OPC UA thích hợp hơn?

A7: Sử dụng OPC UA khi phần mềm công nghiệp được hưởng lợi từ các thẻ/nút được tiêu chuẩn hóa, siêu dữ liệu và khả năng tương tác phong phú hơn.

Q8: Một cổng có thể sử dụng nhiều giao thức ngược dòng không?

A8: Nhiều cổng biên có thể, nhưng hành vi đa đích đồng thời phải được xác minh cho chương trình cơ sở và dự án chính xác.

Tóm tắt