替代OPC-UA

作爲訪問由各種PLC組成的系統的過程數據的解決方案，OPC-UA是否有任何體面的替代方案？某些獨立於平臺的產品可以與不同品牌的產品「說話」？替代OPC-UA

我聽說過MQTT，但它似乎更像是一個傳輸協議，只有這一點。它沒有像信息建模等所有更高級別的東西。

感謝您的幫助！

來源

2014-10-05 cid

OPC是與PLC通信的唯一標準方式。 OPC DA是舊的選擇。 OPC UA是現在推薦的新產品。在OPC之前，只有專有協議和像Modbus這樣的共享協議，但它們只是您提到的較低級別的傳輸協議。

OPC UA在信息建模方面非常獨特，特別是。除了普通的PLC通訊功能之外，該功能還可以爲更高級別的系統和應用程序提供新的通訊功能。

請注意，某些PLC本身也可以使用OPC UA，這使得它成爲標準。

而且OPC UA確實標準化爲IEC 62541，確保它是獨立的。

更新17/07/19：OPC UA現在定義爲Industry 4.0 Communication，正如我在我最近的文章中所寫的那樣。此外，OPC UA即將發佈的1.04版本（目前在RC中）將定義Pub/Sub備選方案（稍後使用UDP & AMQP首先MQTT），並且還將定義WebSocket/JSON協議替代方案，這將使啓用Web應用程序中的使用。

來源

2014-10-06 08:43:33

作爲I.O.T.的選擇協議，MQTT越來越流行。它確實有其不足之處 - 然而它的簡單性往往被視爲一種優勢，而OPCUA則承擔了委員會設計的開銷。

如果您需要將兩者結合起來，你可能想考慮嘗試我們簡單的網關mqtt2opcua

來源

2015-07-27 18:59:01

@NZFarmer作爲OPC/OPC-UA的替代品，MQTT對我來說確實非常有前景。但是，MQTT是否處理信息建模？如果是，如何？ – cid 2015-08-04 12:02:55

@cid MQTT的核心是一個非常pub/sub的框架。建議您查看規格。 – 2015-08-05 15:57:39

@NZFarmer是的，它可以在pub/sub架構中工作，很好。這回答了問題_如何。這個問題怎麼樣_什麼？我的意思是OPC/OPC-UA最大的優勢之一是它定義了數據的表示/建模。即這種類型的數據將具有字段值，字段時間戳，字段單位等。MQTT如何？它是否定義了這個？ – cid 2015-08-07 07:32:28

OPC-UA有一些非常有趣的部分，特別是關於信息建模，互操作性和發佈/訂閱模式。但是，儘管它是最嚴格意義上的標準，但我發現要在webapp中使用它，您需要編寫一個網關服務器。因爲它使用原始套接字和二進制（儘管很快）的序列化協議。

這就是爲什麼我們在我的大學創建了一個名爲Woopsa的替代協議。我們決定將其基於HTTP + JSON。我們試圖制定一個類似於OPC-UA的協議：它具有信息建模，發佈/訂閱，甚至多重請求。它完全是開源的。

我們剛剛發佈了1.0版本，在這裏：http://www.woopsa.org/

您可以在我們的GitHub上直接獲取源代碼：https://github.com/woopsa-protocol/Woopsa

基本上，我們的協議僅僅是使用HTTP + JSON標準化的RESTful API。例如，你可以通過一個GET /woopsa/read/Temperature讀取值，它會回覆您在JSON：

{"Value":24.2,"Type":"Real"}

您還可以通過使用meta搭話對象樹，例如：GET /woopsa/meta/，這將給你像即：

{ 
    "Name":"WeatherStation", 
    "Properties": [ 
    {"Name":"Temperature","Type":"Real"}, 
    ... 
    ], 
    "Methods": { ... } 
    "Items": [ 
    "Thermostat", 
    ... 
    ] 
}

來源

2015-10-13 06:36:23

在實際工業應用中，MQTT不是OPC-UA的替代品。早在90年代，OPC的最初目標就是提供一種標準的通信機制和數據模型，以提供實現該規範的客戶端和服務器之間的互操作性。 OPC-UA在不放棄該核心目標的情況下擴展並推廣了數據模型和通信。爲此，標準必須指定諸如時間戳的格式，數據類型的編碼，歷史值，警報等等。

MQTT是一種消息傳輸層，不提供設計的互操作性。它沒有規定有效負載的格式，也沒有規定如何傳輸特定的數據類型，時間戳，值，層次結構或其他任何可以讓應用程序理解正在傳輸的數據的內容。您可以創建一個有效的MQTT服務器，以發出純文本，加密，base-64編碼或其他任何您喜歡的XML，JSON或自定義格式的數據。客戶端應用程序與服務器進行交互的唯一方法是事先知道服務器將生成和接受的數據格式。最近OPC-UA引入了發佈/訂閱機制來提高帶寬利用率，從而降低了MQTT目前提供的通信帶寬優勢。同時，爲了促進互操作性，MQTT規範將需要發展以指定數據格式。期望看到MQTT和OPC-UA之間功能的融合，大多數MQTT正在不斷髮展以滿足OPC-UA。

MQTT目前簡單得多，這對於嵌入式和資源受限的系統具有優勢。數據建模規範的添加將起到減少這種優勢的作用。

底線是OPC-UA是用於互操作性的，MQTT用於簡單的定製通信。 MQTT需要成長才能成爲OPC-UA的替代品。

來源

2016-05-05 11:17:58 asthomas

Unserver是專爲解決此問題中描述的確切問題而設計的產品。

它能夠與不同的現場設備交談並在其上面提供統一的HTTP API（）。它通過Modbus RTU與設備集成，但將來會添加其他常用協議。

簡而言之，首先你配置一個數據「標籤」是這樣的：

GET http://localhost:9000/tags/tank1 

{ 
    data:{ 
    level: 1 
    } 
}

退房的documentation：

{ 
    "name": "tank1", 
    "device": "plc1", 
    "properties": [ 
    { 
     "name": "level", 
     "address": "HR0", 
     "type": "numeric", 
     "raw": "int16" 
    } 
    ] 
}

然後你可以使用API端點自動創建與標籤工作獲取更多信息。該產品免費供評估和非商業用途。

聲明：我是團隊的一員。希望這是有用的。

來源

2017-03-22 18:37:08 astreltsov

回答

相關問題