Trang chủ » So sánh OPC-UA và MQTT : lựa chọn giao thức nào cho công nghiệp số ?
So sánh OPC-UA và MQTT : lựa chọn giao thức nào cho công nghiệp số ?
Edge ComputingInternet Of Things (IoT)Technology

So sánh OPC-UA và MQTT : lựa chọn giao thức nào cho công nghiệp số ?

Admin 10 Th11, 2021
Chia sẻ:
29 0

Khi nói về các giải pháp IIoT , Có một số kiến ​​trúc và giao thức khác nhau có thể được sử dụng để thu thập dữ liệu tại khu vực sản xuất. 2 giao thức phổ biến nhất rất khác nhau, điều này khiến chúng đáng so sánh về hiệu quả của chúng trong IIoT là  : OPC UA và MQTT.IoT công nghiệp phát triển tuy nhanh, chưa được hưởng lợi nhiều từ các tiêu chuẩn thống nhất. Có một số kiến ​​trúc và giao thức khác nhau có thể được sử dụng để thu thập dữ liệu khu vực sản xuất và cung cấp cho người sử dụng dữ liệu trên toàn doanh nghiệp. Một số tùy chọn phổ biến là CoAP, DDS, HTTP, MQTT và OPC UA.  Bài viết này nhằm so sánh hai trong số các giao thức phổ biến nhất trong môi trường Internet vạn vật công nghiệp (IIoT): MQTT và OPC-UA.

Xem thêm : Giao thức MQTT trong IoT là gì ? Những ứng dụng của MQTT như thế nào

OPC-UA

OPC classic được phát hành vào năm 1996 và được thiết kế để trừu tượng các giao thức cụ thể của PLC thành một giao diện được tiêu chuẩn hóa để cho phép các hệ thống SCADA truy cập dữ liệu. Ban đầu nó được phát triển cho Windows và theo truyền thống yêu cầu một PC Windows chuyên dụng để trao đổi dữ liệu OT với các hệ thống cũ trên mạng cục bộ. OPC sử dụng kiến ​​trúc client / server trong đó server OPC chuyển đổi giao thức giao tiếp phần cứng, sau đó bất kỳ chương trình nào cần kết nối với phần cứng sẽ trở thành client OPC. Tuy nhiên, một lời kêu gọi về khả năng mở rộng và kiến ​​trúc độc lập với nền tảng đã dẫn đến sự phát triển của OPC UA.

OPC UA là tiêu chuẩn thế hệ tiếp theo của OPC Foundation, được phát hành năm 2008 dưới dạng cập nhật cho tiêu chuẩn tương tác OPC ban đầu để trao đổi dữ liệu an toàn và đáng tin cậy trong tự động hóa công nghiệp. Theo Tổ chức OPC, Ngay khi giới thiệu các kiến ​​trúc hướng dịch vụ trong các hệ thống sản xuất đã đưa ra những thách thức mới trong bảo mật và mô hình hóa dữ liệu. Quỹ OPC đã phát triển các thông số kỹ thuật OPC UA để giải quyết các nhu cầu này, đồng thời cung cấp kiến ​​trúc nền tảng mở công nghệ giàu tính năng, có khả năng mở rộng và có thể mở rộng trong tương lai.

OPC UA nhằm mục đích mở rộng khả năng tương tác cho các ứng dụng thiết bị và doanh nghiệp và gần đây thêm publish / subscribe vào cơ sở hạ tầng truyền thông client / server ban đầu. Thông số kỹ thuật cũng cố gắng loại bỏ yêu cầu đối với PC Windows chuyên dụng bằng cách cho phép server được nhúng vào sản phẩm cạnh. Quỹ OPC đã mở nguồn tiêu chuẩn OPC UA để tăng sự chấp nhận.

OPC có một số hạn chế, mà OPC UA cố gắng giải quyết. Hãy xem xét các thách thức sau đây trước khi triển khai kiến ​​trúc OPC hoặc OPC UA.

Phức tạp : Khiếu nại phổ biến nhất về OPC UA là mức độ phức tạp khi thực hiện. Thông số OPC UA có 1250 trang. Nhiều công ty không triển khai server OPC đầy đủ và ngay cả khi họ làm điều đó cũng yêu cầu bộ định tuyến, tường lửa và VPN. Các thiết bị mới phải được cấu hình và kết nối thay vì tự động phát hiện và cấu hình

Nặng:   Khi server OPC nói chuyện với client , vì các subscribe không được báo cáo bằng các ngoại lệ nhưng theo truyền thống sử dụng giao thức thăm dò / phản hồi, chúng rất nặng nề. Rất nhiều thiết bị hỗ trợ OPC không thể xử lý nhiều subscribe làm hạn chế số lượng người sử dụng dữ liệu trên hệ thống. Mặc dù nó nặng, dữ liệu OPC chỉ đi kèm với các thẻ tag và giá trị cơ bản – không có dữ liệu hoặc đối tượng meta.

Không linh hoạt : khu vực sản xuất ngày càng trở nên đa dạng – với cả thiết bị hiện đại và legacy, hệ điều hành khác nhau, kiến ​​trúc mạng và nhiều hơn nữa. OPC có một thời gian khó xử lý các cấu trúc dữ liệu khác nhau và các thiết bị không đồng nhất. Trọng tâm là dữ liệu OT và giải pháp không phù hợp với các ứng dụng phân tích dữ liệu lớn, vì nó chỉ thu thập dữ liệu OT chứ không phải CNTT.

Đắt tiền: Khi OPC UA được thực hiện đầy đủ, nó rất tốn kém và nặng nề. Kiến trúc yêu cầu nhúng server OPC UA vào các sản phẩm làm tăng chi phí và thời gian tiếp thị, tăng kích thước footprint , sử dụng CPU, chi phí phát triển và chi phí hỗ trợ liên tục.

Thiếu hỗ trợ từ nhà cung cấp: OPC đã xuất hiện trong nhiều năm, nhưng nhiều công nghệ IIoT không hỗ trợ riêng cho kết nối OPC. Microsoft là nhà cung cấp đám mây duy nhất sử dụng cả kết nối server-client OPC UA cũng như các kết nối subscribe publish OPC UA mới. Sự tham gia của nhà cung cấp phần cứng rất mờ nhạt và chỉ có một vài client phần mềm OPC UA có sẵn.

Gặp nhiều vấn đề với nhiều người sử dụng dữ liệu : Kiến trúc OPC đấu tranh để cung cấp tất cả dữ liệu cho nhiều người sử dụng dữ liệu . Một server OPC UA không cung cấp các khả năng một-một nhưng không thực hiện việc tách rời thực sự cần thiết cho một-nhiều người. Ngoài ra, hầu hết các triển khai không bao gồm dữ liệu tag meta , điều này một lần nữa có nghĩa là việc thiếu dữ liệu cho các chức năng CNTT ở định dạng có thể sử dụng được.

Hình 1: Các hệ thống SCADA truyền thống cô lập dữ liệu OT và không thể xử lý nhiều người sử dụng dữ liệu

Một hệ thống OPC truyền thống được hiển thị trong Hình 1, trong đó SCADA sở hữu đường dẫn dữ liệu được xây dựng cho các hoạt động hoặc dữ liệu OT. Khi người tiêu dùng mới yêu cầu dữ liệu OT, ứng dụng mới hoặc mã tùy chỉnh được viết để lấy dữ liệu ra khỏi SCADA. Khi người sử dụng dữ liệu mới được thêm vào, một doanh nghiệp dễ vỡ của các ứng dụng được xây dựng, gây tốn kém cho việc quản lý và trở nên quá phức tạp để thay đổi.

Các case study : Các nhà sản xuất quy trình và rời rạc truyền thống là trường hợp sử dụng lý tưởng cho OPC. Nếu không có bất kỳ tài sản phân tán nào, sẽ khó tạo ra trường hợp chuyển đổi từ OPC thành MQTT. Nếu khu vực sản xuất đã được xây dựng như một hệ thống SCADA và nó đang hoạt động, thì OPC hoặc OPC UA cũng hoạt động.

Tuy nhiên, bất kỳ khu vực sản xuất nào muốn triển khai các công nghệ tiên tiến như machine learning , AI hoặc bảo trì dự đoán sẽ có một thời gian gặp khó khăn với OPC UA. Nó không được thực hiện cho những thách thức hiện đại này.

MQTT thì sao ?

MQTT là một giao thức truyền tải được phát minh vào năm 1999 như một giao thức mạng nhẹ, cho phép nhiều người sử dụng dữ liệu và được thiết kế cho các thiết bị bị hạn chế và các mạng băng thông thấp, độ trễ cao hoặc không đáng tin cậy. MQTT dựa trên cách tiếp cận middleware hướng thông điệp.

MQTT được phát minh để phục vụ nhiều người sử dụng dữ liệu và nhiều nhà sản xuất dữ liệu. Để Chuyển đổi số thành công, dữ liệu phải được tách rời và cung cấp qua kiến ​​trúc giải pháp toàn doanh nghiệp. MQTT cho phép nhiều người sử dụng dữ liệ. Các công ty có thể publish dữ liệu từ một tài sản sản xuất và nhiều ứng dụng có thể nhận nó cùng một lúc.

Công ty Cirrus Link gần đây đã tạo ra một đặc tả trong dự án có tên Sparkplug , định nghĩa cách sử dụng MQTT trong môi trường thời gian thực, quan trọng. Sparkplug định nghĩa một không gian chủ đề MQTT tiêu chuẩn, tải trọng và quản lý trạng thái phiên cho các ứng dụng công nghiệp trong khi đáp ứng các yêu cầu của việc triển khai SCADA thời gian thực.

Sparkplug là một tiêu chuẩn mở không có license và được xây dựng trên 20 năm kinh nghiệm về cách sử dụng MQTT. Đặc tả Sparkplug cung cấp dữ liệu ngữ cảnh cần xác định giá trị thẻ tag để sử dụng với OT, đồng thời cung cấp dữ liệu cho CNTT, giúp nó có thể tự khám phá 100% và dễ tiếp nhận.

Việc sử dụng MQTT với Sparkplug tiêu chuẩn mở cho phép dữ liệu OT được sử dụng với các cấu hình đơn giản trên các công cụ phần mềm đã được chứng minh giúp thu hẹp khoảng cách OT / IT và cung cấp thông tin theo ngữ cảnh cho các nhà khoa học dữ liệu sử dụng Big Data Analytics, ML và AI để hiểu rõ hơn và tăng năng suất và lợi nhuận. Các điểm sau đây giải thích cách MQTT giải quyết các điểm đau không được OPC UA giải quyết.

Đơn giản: Thông số MQTT là 80 trang và Sparkplug thêm 60 trang. Các nhà phát triển có thể theo dõi thông số kỹ thuật và tự thực hiện nó trong vòng vài ngày hoặc vài tuần. MQTT rất dễ thực hiện vì các thiết bị có thể được thêm và tự động phát hiện và có rất nhiều mã tham chiếu giúp mọi người dễ dàng chạy MQTT.

Nhẹ: Báo cáo MQTT bằng ngoại lệ, giảm thiểu data footprint và dẫn đến giao tiếp hiệu quả hơn. Chi phí giao thức cực kỳ nhỏ, gói nhỏ nhất chỉ có 2 byte trên không. Với Sparkplug, MQTT cũng bao gồm dữ liệu meta thiết yếu mà không cần thêm công việc nào, và vẫn giữ cho nó nhẹ.

Linh hoạt: MQTT dựa trên mô hình pub / sub tách riêng nhà publish dữ liệu từ người tiêu dùng, điều đó có nghĩa là người subscribe không cần biết ai cung cấp thông tin mà họ subscribe . Thông báo có thể ở bất kỳ định dạng dữ liệu nào cho tải trọng, chẳng hạn như JSON, XML, nhị phân được mã hóa hoặc Base64, mang lại sự linh hoạt cho giao thức.

Hiệu quả về chi phí: IIoT được cung cấp bởi MQTT cung cấp giải pháp tiết kiệm chi phí để truy cập dữ liệu trên các thiết bị brownfield. MQTT có thể vận chuyển dữ liệu từ một cảm biến, đến một thiết bị (như PLC), đến gateway Edge, sau đó đến hệ thống SCADA / MES trên nhà máy .

Bảo mật : MQTT cung cấp bảo mật theo nhiều cách bắt đầu bằng tên người dùng và mật khẩu cần thiết để đăng nhập. MQTT sử dụng bảo mật lớp TCP / IP hiện tại nhất hiện nay là TLS. Tiếp theo các kết nối có nguồn gốc từ xa, vì vậy không có gateway nào được mở trong trường và chỉ có một gateway tại tường lửa chính được kết nối với nhà môi giới. Danh sách điều khiển truy cập (ACL) chỉ cho phép các thiết bị từ xa đã biết kết nối.

Hỗ trợ cho nhà cung cấp: Số lượng các nhà cung cấp thực hiện MQTT-Sparkplug, cả về phần cứng và phần mềm, đang tăng lên nhanh chóng. Tất cả các nhà cung cấp đám mây hàng đầu, nền tảng IoT, nền tảng điện toán cạnh, dữ liệu lớn và các ứng dụng của bên thứ ba khác đều hỗ trợ MQTT. Các nhà cung cấp đám mây tiến bộ đang triển khai Sparkplug để cung cấp mô hình dữ liệu khám phá tự động.

Hỗ trợ người sử dụng dữ liệu không giới hạn: Chuyển sang mô hình publish / subscribe với MQTT cho phép chuyển đổi từ cách tiếp cận thành một sang nhiều, khuyến khích đổi mới trong khi giúp dễ dàng áp dụng các công nghệ mới. Các nhà sản xuất dữ liệu publish dữ liệu ở định dạng Sparkplug lên server MQTT. server MQTT cho phép những người có quyền truy cập an toàn subscribe dữ liệu. Ứng dụng OT sẽ subscribe dữ liệu thay vì bỏ phiếu cho nó.

OPC UA và MQTT có thể làm việc cùng nhau

OPC UA và MQTT thực sự có thể phối hợp hài hòa với nhau. Chúng có thể là đối cực trong cách chúng di chuyển dữ liệu, nhưng vẫn có những thiết bị cũ cần server OPC để chia sẻ dữ liệu và có một cách sử dụng MQTT để vượt qua các thách thức được đưa ra.

Với một cảm biến được kết nối với PLC legacy, các nền tảng IoT có thể kết nối và dịch dữ liệu đó sang MQTT, di chuyển nó qua bất kỳ loại mạng nào trong mô hình pub / sub, sau đó gửi nó tới ứng dụng đám mây và doanh nghiệp hoặc một số nền tảng IoT sẽ dịch lại thành OPC cho các client OPC cũ.

Các nhà cung cấp phần cứng phải hỗ trợ cả OPC UA và MQTT / Sparkplug, để kết nối giữa cái cũ và cái mới. OPC vẫn có một vị trí trên một mạng riêng, bị ràng buộc và cho kết nối điểm-điểm, nơi không cần nhiều người tiêu dùng dữ liệu, và nó vẫn có cổ phần ở phía OT. OPC vẫn có một nơi dành cho một client có mạng riêng không quan tâm đến việc bổ sung các công nghệ mới và khả năng mới cho nhà máy được kết nối.

Sử dụng MQTT cho phép client nắm lấy các công nghệ và phần mềm IoT mới hơn như dữ liệu lớn, machine learning và hơn thế nữa. Giống như HTTP và HTML phối hợp với nhau để cho phép mở rộng nhanh chóng Internet, MQTT và Sparkplug cũng cung cấp cho người dùng một tùy chọn hiện đại để có khả năng tương tác dữ liệu tại khu vực sản xuất .

Từ khóa:
Chia sẻ:
29 0

Bình luận

Leave a Reply

avatar
  Subscribe  
Notify of