OPC UA và MQTT là hai chuẩn mở phổ biến nhất để đưa dữ liệu từ máy móc lên hệ thống công nghệ thông tin, nhưng chúng giải hai bài toán khác nhau. OPC UA là một khung hoàn chỉnh để mô tả dữ liệu của máy với ngữ nghĩa, kiểu dữ liệu, cấu trúc phân cấp và bảo mật tích hợp. MQTT là một giao thức nhắn tin rất nhẹ theo mô hình xuất bản – đăng ký, chỉ lo chuyển thông điệp qua một máy chủ môi giới, không quan tâm bên trong thông điệp là gì.
Vì thế câu hỏi "chọn OPC UA hay MQTT" thường đặt sai. Trong nhiều kiến trúc hiện đại, OPC UA được dùng gần máy để đọc dữ liệu có cấu trúc từ bộ điều khiển, còn MQTT dùng để phân phối dữ liệu lên các hệ thống phía trên và đám mây. Bài này giải thích cơ chế từng giao thức, so sánh có hệ thống và mô tả các mẫu kết hợp thường gặp, ở mức đủ để nhà quản lý dự án và kỹ sư ngoài ngành tự động hoá ra quyết định.
OPC UA: từ OPC cổ điển đến mô hình thông tin
Tiền thân là OPC cổ điển ra đời giữa thập niên 1990, xây trên công nghệ COM/DCOM của Microsoft, giúp phần mềm giám sát trên Windows đọc dữ liệu từ thiết bị của nhiều hãng qua một giao diện chung. Nó giải quyết được cơn ác mộng mỗi hãng một trình điều khiển, nhưng gắn chặt với Windows và DCOM vốn khó cấu hình qua tường lửa. OPC Foundation phát triển OPC UA (Unified Architecture) để khắc phục, với bản đặc tả đầu tiên phát hành khoảng năm 2008, sau đó được chuẩn hoá thành bộ tiêu chuẩn IEC 62541.
OPC UA độc lập nền tảng và có ba đặc điểm quan trọng. Thứ nhất, mô hình thông tin: dữ liệu không chỉ là giá trị mà là các nút trong không gian địa chỉ, có kiểu, đơn vị, quan hệ cha con, phương thức gọi được. Một máy ép có thể được mô tả như một đối tượng gồm khuôn, bộ gia nhiệt, bộ đếm chu kỳ. Thứ hai, bảo mật tích hợp với chứng chỉ, mã hoá, ký số và phân quyền người dùng. Thứ ba, đặc tả đồng hành (companion specifications): các hiệp hội ngành định nghĩa mô hình chuẩn cho từng loại thiết bị như máy công cụ, máy ép nhựa, robot, để mọi máy cùng loại "nói" cùng một cấu trúc.
Mô hình truyền thống của OPC UA là khách – chủ: máy chủ OPC UA chạy trên hoặc gần bộ điều khiển, khách hàng như SCADA hay cổng biên kết nối và đọc, ghi, đăng ký theo dõi thay đổi. Phần 14 của đặc tả bổ sung mô hình xuất bản – đăng ký, có thể chạy qua MQTT, làm mờ thêm ranh giới.
MQTT: giao thức nhẹ sinh ra cho đường ống dầu
MQTT được Andy Stanford-Clark của IBM và Arlen Nipper thiết kế năm 1999 để giám sát đường ống dầu qua kết nối vệ tinh đắt đỏ, chập chờn. Yêu cầu thiết kế quyết định tính cách của nó: tiêu đề gói tin cực nhỏ, chịu được mạng chập chờn, thiết bị đầu cuối đơn giản. MQTT trở thành chuẩn OASIS với phiên bản 3.1.1 năm 2014, và phiên bản 5 năm 2019 bổ sung nhiều tính năng như thuộc tính người dùng, mã lý do, hết hạn thông điệp.
Cơ chế rất gọn: các thiết bị xuất bản thông điệp lên một chủ đề (topic) dạng chuỗi phân cấp, ví dụ nhà máy/xưởng A/chuyền 2/máy 7/trạng thái; một môi giới (broker) nhận và chuyển cho mọi bên đã đăng ký chủ đề đó. Bên gửi và bên nhận không cần biết nhau, nên thêm một ứng dụng mới chỉ cần đăng ký chủ đề, không phải sửa thiết bị. MQTT có ba mức đảm bảo giao nhận: tối đa một lần, ít nhất một lần, đúng một lần, và cơ chế thông điệp giữ lại (retained) cùng di chúc (last will) để báo khi thiết bị mất kết nối.
Điểm yếu cũng đến từ sự đơn giản: MQTT không quy định nội dung thông điệp. Mỗi nhà tích hợp có thể dùng JSON với tên trường khác nhau, đơn vị khác nhau, cấu trúc chủ đề khác nhau. Đặc tả Sparkplug do Eclipse Foundation quản lý ra đời để bổ sung quy ước chủ đề, định dạng tải và quản lý trạng thái cho môi trường công nghiệp.
So sánh có hệ thống
Bảng dưới đây so sánh ở mức điển hình của hai giao thức khi dùng nguyên bản.
| Tiêu chí | OPC UA | MQTT |
|---|---|---|
| Bản chất | Khung tương tác và mô hình thông tin | Giao thức chuyển thông điệp |
| Mô hình giao tiếp | Khách – chủ, bổ sung xuất bản – đăng ký | Xuất bản – đăng ký qua môi giới |
| Ngữ nghĩa dữ liệu | Có sẵn: kiểu, đơn vị, cấu trúc, đặc tả ngành | Không có; cần quy ước riêng hoặc Sparkplug |
| Độ nặng | Nặng hơn, triển khai phức tạp hơn | Rất nhẹ, chạy được trên thiết bị nhỏ |
| Bảo mật | Tích hợp sâu: chứng chỉ, ký, mã hoá, phân quyền | Dựa vào TLS và cấu hình môi giới |
| Khả năng mở rộng nhiều bên nhận | Mỗi khách kết nối tới máy chủ, tải tăng theo số khách | Môi giới phân phối, bên nhận tăng không ảnh hưởng thiết bị |
| Hợp nhất | Đọc dữ liệu có cấu trúc từ máy, tương tác hai chiều | Phân phối dữ liệu nhiều nơi, kết nối đám mây, thiết bị rải rác |
Nhìn bảng có thể thấy hai giao thức bổ sung cho nhau. OPC UA mạnh ở gần máy, nơi cần hiểu dữ liệu và tương tác có kiểm soát. MQTT mạnh ở tầng phân phối, nơi nhiều hệ thống cần cùng một dữ liệu và kết nối có thể chập chờn.
Ba mẫu kiến trúc kết hợp thường gặp
Cổng biên dịch OPC UA sang MQTT. Cổng biên đọc dữ liệu từ máy chủ OPC UA của PLC (hoặc từ Modbus, giao thức riêng của hãng), chuẩn hoá và xuất bản lên môi giới MQTT. Đây là mẫu phổ biến nhất trong dự án gắn thêm cho nhà máy có sẵn, vì không phải thay đổi bộ điều khiển.
Không gian tên hợp nhất. Mọi hệ thống trong nhà máy, từ máy, MES, ERP đến chất lượng, đều xuất bản trạng thái hiện tại của mình lên một cấu trúc chủ đề MQTT duy nhất theo cây phân cấp tổ chức. Ứng dụng nào cần dữ liệu thì đăng ký, thay vì tích hợp điểm – điểm. Khái niệm này được cộng đồng thực hành công nghiệp quảng bá mạnh vài năm gần đây; ưu điểm là giảm số mối tích hợp, thách thức là quản trị cấu trúc chủ đề và định dạng thông điệp chặt chẽ.
OPC UA đến tận đám mây. Dùng OPC UA cả ở tầng trên, kể cả xuất bản – đăng ký theo Phần 14, để giữ nguyên mô hình thông tin từ máy đến ứng dụng. Mẫu này hợp khi doanh nghiệp đầu tư nhiều vào đặc tả đồng hành và muốn ngữ nghĩa nhất quán, đổi lại độ phức tạp cao hơn.
Cách chọn cho dự án của bạn
Thay vì hỏi giao thức nào tốt hơn, hãy đi qua các câu hỏi sau theo thứ tự.
- Máy hiện có hỗ trợ gì? Kiểm kê bộ điều khiển: đời nào, đã có máy chủ OPC UA tích hợp chưa, hay chỉ có Modbus hoặc giao thức riêng. Điều này quyết định tầng sát máy.
- Ai cần dữ liệu? Nếu chỉ một hệ SCADA đọc, OPC UA khách – chủ là đủ. Nếu MES, nền tảng phân tích, đám mây, ứng dụng di động cùng cần, một môi giới MQTT ở giữa giúp tránh để mỗi hệ thống kết nối thẳng vào máy.
- Có cần ghi lệnh xuống máy không? Ghi thông số, tải công thức sản xuất xuống máy là tương tác nhạy cảm, nên đi qua OPC UA với phân quyền rõ ràng, hoặc qua cơ chế có xác nhận, thay vì để bất kỳ bên nào xuất bản lên một chủ đề là máy thực hiện.
- Ai quản trị quy ước? Dùng MQTT thì phải có tài liệu quy ước chủ đề và định dạng tải, có người phê duyệt thay đổi, cân nhắc Sparkplug. Không có người quản trị, không gian chủ đề sẽ hỗn loạn sau một năm.
- Yêu cầu bảo mật thế nào? Bật mã hoá, xác thực bằng chứng chỉ, phân quyền theo chủ đề hoặc theo nút; không để môi giới hay máy chủ mở không mật khẩu, kể cả trong mạng nội bộ.
- Tính đến vòng đời: chọn sản phẩm hỗ trợ chuẩn mở, kiểm tra khả năng tương thích bằng thử nghiệm thật với thiết bị của bạn trước khi mua số lượng lớn.
Với đa số nhà máy vừa ở Việt Nam đang bắt đầu, mẫu thực dụng là: cổng biên đọc máy bằng giao thức máy hỗ trợ, xuất bản lên một môi giới MQTT trong nhà máy với quy ước chủ đề rõ ràng, các ứng dụng đăng ký từ đó. Khi mua máy mới, yêu cầu máy chủ OPC UA tích hợp và theo đặc tả đồng hành của ngành nếu có.
Những hiểu lầm cần tránh
"MQTT không an toàn." Bản thân giao thức hỗ trợ chạy trên TLS và xác thực; các vụ lộ dữ liệu thường do môi giới cấu hình mở ra Internet không mật khẩu. Vấn đề nằm ở cấu hình và quản trị, không ở giao thức.
"OPC UA quá nặng cho thiết bị nhỏ." Đặc tả có các hồ sơ (profile) rút gọn cho thiết bị nhúng, và nhiều bộ điều khiển hiện đại đã tích hợp sẵn máy chủ OPC UA. Nặng hay nhẹ phụ thuộc phần nào của đặc tả được dùng.
"Dùng chuẩn mở là hết khoá chặt." Chuẩn mở chỉ giải quyết tầng truyền tải. Nếu mô hình dữ liệu, tên biến, cấu trúc chủ đề do một nhà tích hợp tự đặt mà không bàn giao tài liệu, doanh nghiệp vẫn bị phụ thuộc. Cần yêu cầu bàn giao mô hình dữ liệu như một sản phẩm.
"Có giao thức là có dữ liệu dùng được." Giao thức chỉ mang dữ liệu đi. Ý nghĩa của "máy đang chạy", "sản phẩm đạt" vẫn phải được định nghĩa thống nhất ở tầng nghiệp vụ, thường trong MES hoặc tài liệu quy ước dữ liệu của nhà máy.
Câu hỏi thường gặp
Modbus còn dùng được không khi đã có OPC UA và MQTT?
Còn rất phổ biến trên thiết bị hiện có như đồng hồ điện, biến tần, bộ điều khiển nhiệt. Modbus đơn giản và đáng tin nhưng không có ngữ nghĩa và bảo mật. Cách thường làm là để cổng biên đọc Modbus rồi chuyển sang OPC UA hoặc MQTT với tên và đơn vị rõ ràng.
Sparkplug B giải quyết vấn đề gì của MQTT?
Sparkplug quy định cấu trúc chủ đề, định dạng tải nhị phân và cơ chế báo trạng thái sống chết của thiết bị và cổng biên. Nhờ đó các ứng dụng của nhiều nhà cung cấp hiểu được dữ liệu của nhau mà không cần quy ước riêng, gần hơn với tính tương tác của OPC UA.
Có nên đặt môi giới MQTT trên đám mây không?
Có thể với dữ liệu tổng hợp hoặc thiết bị rải rác nhiều địa điểm. Với dữ liệu điều hành trong nhà máy, nên có môi giới tại chỗ để xưởng vẫn hoạt động khi mất Internet, rồi đồng bộ có chọn lọc lên đám mây qua cầu nối.
OPC UA có thay thế các mạng trường như Profinet hay EtherNet/IP không?
Không trực tiếp. Các mạng trường thời gian thực phục vụ điều khiển nhanh giữa bộ điều khiển và thiết bị. OPC UA chủ yếu phục vụ trao đổi dữ liệu và tích hợp ở tầng trên. Có hướng phát triển kết hợp OPC UA với mạng nhạy thời gian để tiến xuống tầng điều khiển, nhưng chưa phổ biến rộng.
Làm sao biết máy mới có hỗ trợ đặc tả đồng hành phù hợp?
Hỏi nhà cung cấp máy tên đặc tả đồng hành cụ thể và phiên bản được hỗ trợ, yêu cầu tài liệu mô hình thông tin và nếu có thể thì thử kết nối bằng một phần mềm khách OPC UA trước khi nghiệm thu. Ghi yêu cầu này vào hợp đồng mua máy.
Một môi giới MQTT chịu được bao nhiêu thiết bị?
Phụ thuộc phần mềm, phần cứng và tần suất thông điệp. Môi giới phổ biến có thể phục vụ từ hàng nghìn đến rất nhiều kết nối đồng thời khi cấu hình phù hợp. Với nhà máy vừa, giới hạn hiếm khi nằm ở môi giới mà ở thiết kế chủ đề và tần suất xuất bản không cần thiết.