Một thách thức lớn trong IoT chính là khả năng tương tác giữa các hệ thống. Trong một khảo sát gần đây của Nexus, 77% số người được hỏi nói rằng khả năng tương tác là thách thức lớn nhất của họ trong IoT. Kết nối các thiết bị công nghiệp với nền tảng IT và OT là một công việc lớn và đó là nơi có rất nhiều từ viết tắt về giao thức. Có nhiều giao thức để thực hiện điều này: một số là độc quyền và một số khác là các tiêu chuẩn mở: OPC UA, Profinet, Modbus,…Tất cả đang đua nhau trở thành giao thức IoT một và duy nhất, nhưng rõ ràng điều này sẽ không bao giờ xảy ra. Các giao thức này sẽ cùng tồn tại với nhau với các điểm mạnh và điểm yếu riêng của chúng và đó là công việc của chúng ta để hiểu vị trí và thời điểm sử dụng chúng.
Tùy thuộc vào hoạt động cụ thể, các SI thường gặp phải nhiều giao thức tự động hóa khác nhau phải được kết nối để đạt được các mục tiêu hoạt động của hoạt động. Ví dụ, thế giới OT, bao gồm các hệ thống thực thi sản xuất (MES), hệ thống điều khiển giám sát và thu thập dữ liệu (SCADA), bộ điều khiển logic lập trình (PLC), mét, van, cảm biến và động cơ, v.v … Chủ yếu sử dụng các giao thức như PROFINET , PROFIBUS, EtherNet / IP và Modbus. Các hệ thống IT bao gồm hệ thống hoạch định nguồn lực doanh nghiệp (ERP) chạy các giao thức SNMP, HTTP, SOAP và XML. Ngoài ra, các giao thức chính cho việc áp dụng IIoT hoặc Công nghiệp 4.0 là MQTT, AMQP và CoAP. Mặc dù có vô số giao thức không tương thích với nhau, nhưng có một tin tốt.
Bài viết này tập trung vào các tiêu chuẩn mở để kết nối ngành công nghiệp với hệ thống IT và các case study cụ thể.
Client / Server so với Publisher/ Subscribe
Với mục đích của cuộc thảo luận này, điều quan trọng là nhóm các giao thức thành hai loại: Client / server và Publisher/ Subscribe.
Giao thức Client / server yêu cầu Client kết nối với server và thực hiện các yêu cầu. Trong mô hình này, server giữ dữ liệu và trả lời các yêu cầu từ Client. Ví dụ, Subscribe có thể đọc nhiệt độ. Điều này đòi hỏi Subscribe phải biết về server trước và có thể kết nối.
Các giao thức Publisher/ Subscribe yêu cầu các thiết bị kết nối và Publisher dữ liệu đến một chủ đề trên một nhà broker trung gian. Người tiêu dùng có thể kết nối với nhà broker và Subscribe dữ liệu từ chủ đề. Ví dụ, một thiết bị có thể lấy mẫu nhiệt độ mỗi phút và Publishermỗi giờ một lần. Một ứng dụng được Subscribe vào luồng dữ liệu sẽ nhận được các mẫu có giá trị một giờ mỗi giờ. Mô hình này tách riêng nhà sản xuất dữ liệu từ người sử dụng dữ liệu.Giao thức Client / server được sử dụng tốt nhất khi bạn hiểu cơ sở hạ tầng của mình.
Ví dụ: bạn biết rằng server của bạn trong trường có địa chỉ IP là 55,55,55,55 và đang lắng nghe trên cổng 1234. Client có thể kết nối và thực hiện các yêu cầu.
Các giao thức Publisher/ Subscribe phù hợp hơn khi cơ sở hạ tầng của bạn không xác định. Ví dụ: nếu một thiết bị từ xa thay đổi mạng hoặc có kết nối không liên tục, thiết bị sẽ dễ dàng gọi về nhà hơn khi trực tuyến và Publisher dữ liệu của thiết bị.
Về mặt ưu và nhược điểm, các giao thức Client / server có khả năng tương tác và bảo mật cao hơn vì chúng dựa trên các kết nối điểm-điểm. Tuy nhiên, chúng ít có khả năng mở rộng hơn, bởi vì các kết nối điểm-điểm khó quản lý hơn và tốn nhiều tài nguyên hơn.
Ngược lại, các giao thức Publisher / Subscribe có khả năng mở rộng hơn vì việc tách rời các nhà sản xuất và người tiêu dùng cho phép mỗi giao thức được thêm và xóa độc lập. Điều đó nói rằng, việc bảo mật các giao thức này phức tạp hơn vì có nhiều phần liên quan hơn. Họ cũng có thể có các vấn đề về khả năng tương tác do sự mất khớp nối của nhà sản xuất và người tiêu dùng. Ví dụ: thay đổi định dạng tin nhắn mà nhà sản xuất gửi yêu cầu tất cả người tiêu dùng thích ứng với loại tin nhắn mới.
Bây giờ chúng ta đã hiểu các danh mục cơ bản, hãy xem xét các giao thức khách / server và Publisher/ Subscribe các giao thức chi tiết hơn.
Giao thức thông dụng
Các giao thức chúng ta sẽ thảo luận có khả năng kết nối các thiết bị công nghiệp với Platform IoT. Có thể không cần phải nói, nhưng nếu bạn đang cố gắng kết nối hai ứng dụng và cả hai đều hỗ trợ HTTP, trước tiên hãy thử HTTP. Nếu điều đó không hoạt động hoặc nếu môi trường của bạn không hỗ trợ nó, hãy tiếp tục đọc. Chúng tôi sẽ mô tả từng giao thức và khi nào sử dụng nó. Dưới đây là danh sách ngắn mà chúng tôi sẽ đề cập:
• OPC UA
• HTTP (REST / JSON)
• MQTT
• CoAP
• DDS
• AMQP
OPC UA
Kiến trúc hợp nhất OPC (OPC UA) là tiêu chuẩn thế hệ tiếp theo từ OPC Foundation. OPC classic nổi tiếng trong lĩnh vực công nghiệp và cung cấp giao diện chuẩn để giao tiếp với các PLC. OPC UA nhằm mục đích mở rộng khả năng tương tác của OPC đến cấp độ thiết bị và doanh nghiệp.
Tìm hiểu thêm giao thức OPC UA tại đây
OPC UA là một giao thức máy khách / máy chủ. Subscribe kết nối, duyệt, đọc và ghi vào thiết bị công nghiệp. UA định nghĩa truyền thông từ ứng dụng đến lớp vận chuyển, làm cho nó rất tương thích giữa các nhà cung cấp. Nó cũng có độ an toàn cao và sử dụng mã hóa tin nhắn hai chiều và mã hóa vận chuyển.
OPC UA có một cơ sở cài đặt rộng rãi trong lĩnh vực công nghiệp. Đây là một giải pháp tốt để gắn dữ liệu PLC và cảm biến vào các ứng dụng công nghiệp hiện có như hệ thống SCADA và MES, nơi có sẵn kết nối OPC và OPC UA.
OPC UA là mới đối với không gian IT , tuy nhiên. Một số người trong IT bị đe dọa bởi sự phức tạp của UA so với các giao thức IT khác. Rất nhiều sự phức tạp này là kết quả của OPC UA là một giao thức công nghiệp, nhưng nhận thức này đã dẫn đến việc các Platform IoT và cộng đồng nguồn mở bị chậm chấp nhận.
Tuy nhiên, mọi thứ đang thay đổi: gần đây, OPC Foundation đã mở ra tiêu chuẩn OPC UA để làm cho nó dễ tiếp cận hơn và giúp tăng sự chấp nhận.
Hiện tại, hãy sử dụng OPC UA khi bạn cần lấy dữ liệu PLC và cảm biến vào các giải pháp SCADA và MES hiện có và để mắt đến việc áp dụng OPC UA bởi các nhà cung cấp Platform IoT và cộng đồng nguồn mở.
HTTP (REST / JSON)
Giao thức truyền siêu văn bản (HTTP) là giao thức máy khách / máy chủ không kết nối có mặt khắp nơi trong IT và web. Bởi vì có vô số công cụ nguồn mở sử dụng HTTP và mọi ngôn ngữ mã hóa đều có thư viện HTTP, nên nó rất dễ truy cập.
Trọng tâm của HTTP trong IoT là xung quanh Chuyển giao trạng thái đại diện (REST), đây là mô hình không trạng thái nơi khách hàng có thể truy cập tài nguyên trên máy chủ thông qua các yêu cầu. Trong hầu hết các trường hợp, tài nguyên là một thiết bị và dữ liệu mà thiết bị chứa.
HTTP cung cấp một phương tiện vận chuyển, nhưng không xác định việc trình bày dữ liệu. Như vậy, các yêu cầu HTTP có thể chứa HTML, JavaScript, Ký hiệu đối tượng JavaScript (JSON), XML, v.v. Trong hầu hết các trường hợp, IoT đang chuẩn hóa xung quanh JSON qua HTTP. JSON tương tự như XML XML mà không cần tất cả các xác thực lược đồ và lược đồ làm cho nó nhẹ hơn và linh hoạt hơn. JSON cũng được hỗ trợ bởi hầu hết các công cụ và ngôn ngữ lập trình.
Công nghiệp có một số kinh nghiệm sử dụng HTTP cho cấu hình thiết bị và sản phẩm, nhưng không phải để truy cập dữ liệu. Do đó, nhiều Platform IoT và IT hỗ trợ tiêu thụ và cung cấp dữ liệu ở dạng HTTP, nhưng rất ít nền tảng công nghiệp làm được. Điều này đang thay đổi khi nhiều cổng và PLC bắt đầu thêm hỗ trợ HTTP gốc.
Sử dụng HTTP để gửi khối dữ liệu, như đọc nhiệt độ một phút mỗi giờ. Không sử dụng HTTP để truyền dữ liệu tốc độ cao. HTTP có thể thực hiện dữ liệu dưới giây, nhưng cập nhật 100 ms qua HTTP rất khó. Nó có rất nhiều chi phí cho mỗi tin nhắn, vì vậy việc truyền phát các tin nhắn nhỏ là không hiệu quả. Và luôn luôn bảo mật thông tin liên lạc với HTTPS. Chi phí tối thiểu.
Hãy nhận biết các vấn đề về khả năng tương tác với các sản phẩm HTTP. Chỉ vì hai sản phẩm hỗ trợ HTTP / REST / JSON không có nghĩa là chúng sẽ hoạt động tốt. Thông thường các định dạng JSON là khác nhau và yêu cầu tích hợp tối thiểu để mọi thứ hoạt động.
MQTT
Truyền tin xếp hàng từ xa (MQTT) là một giao thức Publisher / Subscribe được thiết kế cho SCADA và các mạng từ xa. Nó tập trung vào chi phí tối thiểu (tiêu đề 2 byte) và thông tin liên lạc đáng tin cậy. Nó cũng rất đơn giản. Giống như HTTP, tải trọng của MQTT là dành riêng cho ứng dụng và hầu hết các triển khai đều sử dụng định dạng nhị phân hoặc JSON tùy chỉnh.
MQTT không được sử dụng rộng rãi như HTTP, nhưng nó vẫn có thị phần lớn trong IT . Có nhiều Subscribe / publisher, broker, dự án và ví dụ nguồn mở trong mọi ngôn ngữ. Nhiều Platform IoT hỗ trợ HTTP và MQTT là hai giao thức gửi dữ liệu đầu tiên của họ.
Sử dụng MQTT khi băng thông ở mức cao và bạn không biết cơ sở hạ tầng của mình. Hãy chắc chắn rằng bạn hoặc nhà cung cấp của bạn có một broker MQTT, bạn có thể Publisher dữ liệu lên mạng và luôn bảo mật liên lạc thông qua Bảo mật lớp vận chuyển (TLS).
Ứng dụng cuối không hỗ trợ MQTT? Nếu vậy, có rất nhiều công cụ nguồn mở để nhận dữ liệu MQTT vào cơ sở dữ liệu và các định dạng khác như HTTP.
Hãy chú ý các vấn đề về khả năng tương tác tương tự như HTTP. Chỉ vì hai ứng dụng hỗ trợ MQTT không có nghĩa là chúng có thể tương tác với nhau. Các định dạng chủ đề và JSON có thể cần được điều chỉnh để làm cho hai sản phẩm tương thích với nhau.
CoAP
Giao thức ứng dụng ràng buộc (CoAP) được tạo bởi Lực lượng kỹ thuật Internet (IETF) để cung cấp khả năng tương tác của HTTP với chi phí tối thiểu. CoAP tương tự như HTTP, nhưng sử dụng UDP / multicast thay vì TCP. Nó cũng đơn giản hóa tiêu đề HTTP và giảm kích thước của từng yêu cầu. CoAP được sử dụng trong các thiết bị dựa trên cạnh trong đó HTTP sẽ quá tốn tài nguyên và thường là giao thức thứ ba được hỗ trợ bởi các Platform IoT sau HTTP và MQTT. Tương tự như HTTPS, CoAP sử dụng Datagram Transport Layer Security (DTLS) để bảo mật liên lạc.
Sử dụng CoAP khi HTTP quá tải băng thông. Hãy nhớ rằng việc áp dụng thị trường của CoAP không lớn như HTTP, vì vậy nó có thể giới hạn các tùy chọn phần mềm và phần cứng của bạn. Có các giải pháp để chuyển đổi các thông báo CoAP sang và từ HTTP giúp các giải pháp CoAP tương thích hơn.
DDS
Dịch vụ phân phối dữ liệu DDS (DDS) là một giao thức Publisher / Subscribe tập trung vào giao tiếp ở rìa mạng. DDS là một tiêu chuẩn mở được quản lý bởi Nhóm quản lý đối tượng (OMG). Không giống như MQTT yêu cầu một broker tập trung, DDS được phân cấp. Các nút DDS giao tiếp trực tiếp theo kiểu ngang hàng bằng cách sử dụng đa tuyến UDP. Điều này loại bỏ nhu cầu quản lý mạng tập trung và cũng làm cho DDS trở thành giao thức nhanh hơn, đạt độ phân giải dưới một phần nghìn giây.
DDS là một giải pháp tốt để cung cấp dữ liệu thời gian thực đáng tin cậy ở rìa. Sử dụng nó để liên lạc M2M nhanh chóng.
DDS hỗ trợ các broker tích hợp mạng DDS với doanh nghiệp, nhưng trên thực tế, nó không được định vị tốt vì điểm tích hợp giữa ngành và IT vì các broker thường là thứ yếu so với mạng DDS.
AMQP
Giao thức xếp hàng tin nhắn nâng cao AMQP (AMQP) là một giao thức Publisher / Subscribe khác xuất phát từ lĩnh vực dịch vụ tài chính. Nó có sự hiện diện trong IT , nhưng sự hiện diện hạn chế trong ngành công nghiệp.
Lợi ích lớn nhất của AMQP là mô hình truyền thông mạnh mẽ hỗ trợ các giao dịch. Không giống như MQTT, AMQP có thể đảm bảo hoàn thành các giao dịch, mặc dù rất hữu ích nhưng không phải lúc nào cũng được các ứng dụng IoT yêu cầu.
AMQP thường được nhóm với các giao thức IoT và đó là một giao thức nhưng điều lớn nhất của nó là giao thức nặng. Nó có nghĩa là cho các hệ thống IT phụ trợ, và không phải là cạnh của mạng.
Kết Luận
OPC UA, HTTP, MQTT, CoAP, DDS và AMQP đều có một vị trí trong công nghệ IoT. Những giao thức nào chiếm thị phần đa số là không rõ ràng, nhưng mỗi giao thức đều có ưu và nhược điểm. Điều quan trọng là chọn giao thức phù hợp nhất với nhu cầu của bạn và chọn đối tác công nghệ có thể thích ứng với các giao thức này. Điều này sẽ đảm bảo sự thành công của các ứng dụng IoT của bạn và bảo vệ bạn khỏi các cuộc chiến giao thức.
Một thách thức lớn trong IoT chính là khả năng tương tác giữa các hệ thống. Trong một khảo sát gần đây của Nexus, 77% số người được hỏi nói rằng khả năng tương tác là thách thức lớn nhất của họ trong IoT. Kết nối các thiết bị công nghiệp với nền tảng IT và OT là một công việc lớn và đó là nơi có rất nhiều từ viết tắt về giao thức. Có nhiều giao thức để thực hiện điều này: một số là độc quyền và một số khác là các tiêu chuẩn mở: OPC UA, Profinet, Modbus,…Tất cả đang đua nhau trở thành giao thức IoT một và duy nhất, nhưng rõ ràng điều này sẽ không bao giờ xảy ra. Các giao thức này sẽ cùng tồn tại với nhau với các điểm mạnh và điểm yếu riêng của chúng và đó là công việc của chúng ta để hiểu vị trí và thời điểm sử dụng chúng.
Tùy thuộc vào hoạt động cụ thể, các SI thường gặp phải nhiều giao thức tự động hóa khác nhau phải được kết nối để đạt được các mục tiêu hoạt động của hoạt động. Ví dụ, thế giới OT, bao gồm các hệ thống thực thi sản xuất (MES), hệ thống điều khiển giám sát và thu thập dữ liệu (SCADA), bộ điều khiển logic lập trình (PLC), mét, van, cảm biến và động cơ, v.v … Chủ yếu sử dụng các giao thức như PROFINET , PROFIBUS, EtherNet / IP và Modbus. Các hệ thống IT bao gồm hệ thống hoạch định nguồn lực doanh nghiệp (ERP) chạy các giao thức SNMP, HTTP, SOAP và XML. Ngoài ra, các giao thức chính cho việc áp dụng IIoT hoặc Công nghiệp 4.0 là MQTT, AMQP và CoAP. Mặc dù có vô số giao thức không tương thích với nhau, nhưng có một tin tốt.
Bài viết này tập trung vào các tiêu chuẩn mở để kết nối ngành công nghiệp với hệ thống IT và các case study cụ thể.
Client / Server so với Publisher/ Subscribe
Với mục đích của cuộc thảo luận này, điều quan trọng là nhóm các giao thức thành hai loại: Client / server và Publisher/ Subscribe.
Giao thức Client / server yêu cầu Client kết nối với server và thực hiện các yêu cầu. Trong mô hình này, server giữ dữ liệu và trả lời các yêu cầu từ Client. Ví dụ, Subscribe có thể đọc nhiệt độ. Điều này đòi hỏi Subscribe phải biết về server trước và có thể kết nối.
Các giao thức Publisher/ Subscribe yêu cầu các thiết bị kết nối và Publisher dữ liệu đến một chủ đề trên một nhà broker trung gian. Người tiêu dùng có thể kết nối với nhà broker và Subscribe dữ liệu từ chủ đề. Ví dụ, một thiết bị có thể lấy mẫu nhiệt độ mỗi phút và Publishermỗi giờ một lần. Một ứng dụng được Subscribe vào luồng dữ liệu sẽ nhận được các mẫu có giá trị một giờ mỗi giờ. Mô hình này tách riêng nhà sản xuất dữ liệu từ người sử dụng dữ liệu.Giao thức Client / server được sử dụng tốt nhất khi bạn hiểu cơ sở hạ tầng của mình.
Ví dụ: bạn biết rằng server của bạn trong trường có địa chỉ IP là 55,55,55,55 và đang lắng nghe trên cổng 1234. Client có thể kết nối và thực hiện các yêu cầu.
Các giao thức Publisher/ Subscribe phù hợp hơn khi cơ sở hạ tầng của bạn không xác định. Ví dụ: nếu một thiết bị từ xa thay đổi mạng hoặc có kết nối không liên tục, thiết bị sẽ dễ dàng gọi về nhà hơn khi trực tuyến và Publisher dữ liệu của thiết bị.
Về mặt ưu và nhược điểm, các giao thức Client / server có khả năng tương tác và bảo mật cao hơn vì chúng dựa trên các kết nối điểm-điểm. Tuy nhiên, chúng ít có khả năng mở rộng hơn, bởi vì các kết nối điểm-điểm khó quản lý hơn và tốn nhiều tài nguyên hơn.
Ngược lại, các giao thức Publisher / Subscribe có khả năng mở rộng hơn vì việc tách rời các nhà sản xuất và người tiêu dùng cho phép mỗi giao thức được thêm và xóa độc lập. Điều đó nói rằng, việc bảo mật các giao thức này phức tạp hơn vì có nhiều phần liên quan hơn. Họ cũng có thể có các vấn đề về khả năng tương tác do sự mất khớp nối của nhà sản xuất và người tiêu dùng. Ví dụ: thay đổi định dạng tin nhắn mà nhà sản xuất gửi yêu cầu tất cả người tiêu dùng thích ứng với loại tin nhắn mới.
Bây giờ chúng ta đã hiểu các danh mục cơ bản, hãy xem xét các giao thức khách / server và Publisher/ Subscribe các giao thức chi tiết hơn.
Giao thức thông dụng
Các giao thức chúng ta sẽ thảo luận có khả năng kết nối các thiết bị công nghiệp với Platform IoT. Có thể không cần phải nói, nhưng nếu bạn đang cố gắng kết nối hai ứng dụng và cả hai đều hỗ trợ HTTP, trước tiên hãy thử HTTP. Nếu điều đó không hoạt động hoặc nếu môi trường của bạn không hỗ trợ nó, hãy tiếp tục đọc. Chúng tôi sẽ mô tả từng giao thức và khi nào sử dụng nó. Dưới đây là danh sách ngắn mà chúng tôi sẽ đề cập:
• OPC UA
• HTTP (REST / JSON)
• MQTT
• CoAP
• DDS
• AMQP
OPC UA
Kiến trúc hợp nhất OPC (OPC UA) là tiêu chuẩn thế hệ tiếp theo từ OPC Foundation. OPC classic nổi tiếng trong lĩnh vực công nghiệp và cung cấp giao diện chuẩn để giao tiếp với các PLC. OPC UA nhằm mục đích mở rộng khả năng tương tác của OPC đến cấp độ thiết bị và doanh nghiệp.
Tìm hiểu thêm giao thức OPC UA tại đây
OPC UA là một giao thức máy khách / máy chủ. Subscribe kết nối, duyệt, đọc và ghi vào thiết bị công nghiệp. UA định nghĩa truyền thông từ ứng dụng đến lớp vận chuyển, làm cho nó rất tương thích giữa các nhà cung cấp. Nó cũng có độ an toàn cao và sử dụng mã hóa tin nhắn hai chiều và mã hóa vận chuyển.
OPC UA có một cơ sở cài đặt rộng rãi trong lĩnh vực công nghiệp. Đây là một giải pháp tốt để gắn dữ liệu PLC và cảm biến vào các ứng dụng công nghiệp hiện có như hệ thống SCADA và MES, nơi có sẵn kết nối OPC và OPC UA.
OPC UA là mới đối với không gian IT , tuy nhiên. Một số người trong IT bị đe dọa bởi sự phức tạp của UA so với các giao thức IT khác. Rất nhiều sự phức tạp này là kết quả của OPC UA là một giao thức công nghiệp, nhưng nhận thức này đã dẫn đến việc các Platform IoT và cộng đồng nguồn mở bị chậm chấp nhận.
Tuy nhiên, mọi thứ đang thay đổi: gần đây, OPC Foundation đã mở ra tiêu chuẩn OPC UA để làm cho nó dễ tiếp cận hơn và giúp tăng sự chấp nhận.
Hiện tại, hãy sử dụng OPC UA khi bạn cần lấy dữ liệu PLC và cảm biến vào các giải pháp SCADA và MES hiện có và để mắt đến việc áp dụng OPC UA bởi các nhà cung cấp Platform IoT và cộng đồng nguồn mở.
HTTP (REST / JSON)
Giao thức truyền siêu văn bản (HTTP) là giao thức máy khách / máy chủ không kết nối có mặt khắp nơi trong IT và web. Bởi vì có vô số công cụ nguồn mở sử dụng HTTP và mọi ngôn ngữ mã hóa đều có thư viện HTTP, nên nó rất dễ truy cập.
Trọng tâm của HTTP trong IoT là xung quanh Chuyển giao trạng thái đại diện (REST), đây là mô hình không trạng thái nơi khách hàng có thể truy cập tài nguyên trên máy chủ thông qua các yêu cầu. Trong hầu hết các trường hợp, tài nguyên là một thiết bị và dữ liệu mà thiết bị chứa.
HTTP cung cấp một phương tiện vận chuyển, nhưng không xác định việc trình bày dữ liệu. Như vậy, các yêu cầu HTTP có thể chứa HTML, JavaScript, Ký hiệu đối tượng JavaScript (JSON), XML, v.v. Trong hầu hết các trường hợp, IoT đang chuẩn hóa xung quanh JSON qua HTTP. JSON tương tự như XML XML mà không cần tất cả các xác thực lược đồ và lược đồ làm cho nó nhẹ hơn và linh hoạt hơn. JSON cũng được hỗ trợ bởi hầu hết các công cụ và ngôn ngữ lập trình.
Công nghiệp có một số kinh nghiệm sử dụng HTTP cho cấu hình thiết bị và sản phẩm, nhưng không phải để truy cập dữ liệu. Do đó, nhiều Platform IoT và IT hỗ trợ tiêu thụ và cung cấp dữ liệu ở dạng HTTP, nhưng rất ít nền tảng công nghiệp làm được. Điều này đang thay đổi khi nhiều cổng và PLC bắt đầu thêm hỗ trợ HTTP gốc.
Sử dụng HTTP để gửi khối dữ liệu, như đọc nhiệt độ một phút mỗi giờ. Không sử dụng HTTP để truyền dữ liệu tốc độ cao. HTTP có thể thực hiện dữ liệu dưới giây, nhưng cập nhật 100 ms qua HTTP rất khó. Nó có rất nhiều chi phí cho mỗi tin nhắn, vì vậy việc truyền phát các tin nhắn nhỏ là không hiệu quả. Và luôn luôn bảo mật thông tin liên lạc với HTTPS. Chi phí tối thiểu.
Hãy nhận biết các vấn đề về khả năng tương tác với các sản phẩm HTTP. Chỉ vì hai sản phẩm hỗ trợ HTTP / REST / JSON không có nghĩa là chúng sẽ hoạt động tốt. Thông thường các định dạng JSON là khác nhau và yêu cầu tích hợp tối thiểu để mọi thứ hoạt động.
MQTT
Truyền tin xếp hàng từ xa (MQTT) là một giao thức Publisher / Subscribe được thiết kế cho SCADA và các mạng từ xa. Nó tập trung vào chi phí tối thiểu (tiêu đề 2 byte) và thông tin liên lạc đáng tin cậy. Nó cũng rất đơn giản. Giống như HTTP, tải trọng của MQTT là dành riêng cho ứng dụng và hầu hết các triển khai đều sử dụng định dạng nhị phân hoặc JSON tùy chỉnh.
MQTT không được sử dụng rộng rãi như HTTP, nhưng nó vẫn có thị phần lớn trong IT . Có nhiều Subscribe / publisher, broker, dự án và ví dụ nguồn mở trong mọi ngôn ngữ. Nhiều Platform IoT hỗ trợ HTTP và MQTT là hai giao thức gửi dữ liệu đầu tiên của họ.
Sử dụng MQTT khi băng thông ở mức cao và bạn không biết cơ sở hạ tầng của mình. Hãy chắc chắn rằng bạn hoặc nhà cung cấp của bạn có một broker MQTT, bạn có thể Publisher dữ liệu lên mạng và luôn bảo mật liên lạc thông qua Bảo mật lớp vận chuyển (TLS).
Ứng dụng cuối không hỗ trợ MQTT? Nếu vậy, có rất nhiều công cụ nguồn mở để nhận dữ liệu MQTT vào cơ sở dữ liệu và các định dạng khác như HTTP.
Hãy chú ý các vấn đề về khả năng tương tác tương tự như HTTP. Chỉ vì hai ứng dụng hỗ trợ MQTT không có nghĩa là chúng có thể tương tác với nhau. Các định dạng chủ đề và JSON có thể cần được điều chỉnh để làm cho hai sản phẩm tương thích với nhau.
CoAP
Giao thức ứng dụng ràng buộc (CoAP) được tạo bởi Lực lượng kỹ thuật Internet (IETF) để cung cấp khả năng tương tác của HTTP với chi phí tối thiểu. CoAP tương tự như HTTP, nhưng sử dụng UDP / multicast thay vì TCP. Nó cũng đơn giản hóa tiêu đề HTTP và giảm kích thước của từng yêu cầu. CoAP được sử dụng trong các thiết bị dựa trên cạnh trong đó HTTP sẽ quá tốn tài nguyên và thường là giao thức thứ ba được hỗ trợ bởi các Platform IoT sau HTTP và MQTT. Tương tự như HTTPS, CoAP sử dụng Datagram Transport Layer Security (DTLS) để bảo mật liên lạc.
Sử dụng CoAP khi HTTP quá tải băng thông. Hãy nhớ rằng việc áp dụng thị trường của CoAP không lớn như HTTP, vì vậy nó có thể giới hạn các tùy chọn phần mềm và phần cứng của bạn. Có các giải pháp để chuyển đổi các thông báo CoAP sang và từ HTTP giúp các giải pháp CoAP tương thích hơn.
DDS
Dịch vụ phân phối dữ liệu DDS (DDS) là một giao thức Publisher / Subscribe tập trung vào giao tiếp ở rìa mạng. DDS là một tiêu chuẩn mở được quản lý bởi Nhóm quản lý đối tượng (OMG). Không giống như MQTT yêu cầu một broker tập trung, DDS được phân cấp. Các nút DDS giao tiếp trực tiếp theo kiểu ngang hàng bằng cách sử dụng đa tuyến UDP. Điều này loại bỏ nhu cầu quản lý mạng tập trung và cũng làm cho DDS trở thành giao thức nhanh hơn, đạt độ phân giải dưới một phần nghìn giây.
DDS là một giải pháp tốt để cung cấp dữ liệu thời gian thực đáng tin cậy ở rìa. Sử dụng nó để liên lạc M2M nhanh chóng.
DDS hỗ trợ các broker tích hợp mạng DDS với doanh nghiệp, nhưng trên thực tế, nó không được định vị tốt vì điểm tích hợp giữa ngành và IT vì các broker thường là thứ yếu so với mạng DDS.
AMQP
Giao thức xếp hàng tin nhắn nâng cao AMQP (AMQP) là một giao thức Publisher / Subscribe khác xuất phát từ lĩnh vực dịch vụ tài chính. Nó có sự hiện diện trong IT , nhưng sự hiện diện hạn chế trong ngành công nghiệp.
Lợi ích lớn nhất của AMQP là mô hình truyền thông mạnh mẽ hỗ trợ các giao dịch. Không giống như MQTT, AMQP có thể đảm bảo hoàn thành các giao dịch, mặc dù rất hữu ích nhưng không phải lúc nào cũng được các ứng dụng IoT yêu cầu.
AMQP thường được nhóm với các giao thức IoT và đó là một giao thức nhưng điều lớn nhất của nó là giao thức nặng. Nó có nghĩa là cho các hệ thống IT phụ trợ, và không phải là cạnh của mạng.
Kết Luận
OPC UA, HTTP, MQTT, CoAP, DDS và AMQP đều có một vị trí trong công nghệ IoT. Những giao thức nào chiếm thị phần đa số là không rõ ràng, nhưng mỗi giao thức đều có ưu và nhược điểm. Điều quan trọng là chọn giao thức phù hợp nhất với nhu cầu của bạn và chọn đối tác công nghệ có thể thích ứng với các giao thức này. Điều này sẽ đảm bảo sự thành công của các ứng dụng IoT của bạn và bảo vệ bạn khỏi các cuộc chiến giao thức.
