web-dev-qa-db-ja.com

OPC-UAの代替

さまざまなPLCで構成されるシステムのプロセスデータにアクセスするためのソリューションとして、OPC-UAに代わる適切な方法はありますか？プラットフォームに依存せず、さまざまなブランドの製品と「話す」ことができるものはありますか？

[〜＃〜] mqtt [〜＃〜] と聞いたことがありますが、トランスポートプロトコルに非常に似ているようで、それだけです。情報モデリングなど、より高いレベルのものがすべて含まれているわけではありません。

ご協力いただきありがとうございます！

mqttplcopcscadaopc-ua
17
cid

OPCは、PLCと通信するための唯一の標準的な方法です。 OPCDAは古い代替手段です。 OPC UAは新しいものであり、最近では推奨されています。 OPCの前は、Modbusのような独自のプロトコルと共有プロトコルしかありませんでしたが、あなたが言及したように、それらは単なる低レベルのトランスポートプロトコルです。

OPC UAは、特に情報モデリングで非常にユニークです。この機能により、プレーンなPLC通信に加えて、より高いレベルのシステムやアプリケーションでも新しい通信の可能性が実現します。

一部のPLCはOPCUAをネイティブに通信することもできるため、そのように標準になっていることに注意してください。

また、OPCUAは実際にはIEC 62541として標準化されており、独立していることが保証されています。

更新17/07/19：OPC UAは、最近の記事で書いたように、 Industry 4.0 Communication としても定義されるようになりました。

また、OPC UAの次のバージョン1.04（現時点ではRC）は、Pub/Subの代替を定義し（後でUDPとAMQPの最初のMQTTを使用）、WebSocket/JSONプロトコルの代替も定義します。これにより、Webアプリケーションでの使用が容易になります。 。

16
Jouni Aro

OPC-UAには、特に情報モデリング、相互運用性、およびパブリッシュ/サブスクライブパターンに関して、いくつかの非常に興味深い部分があります。

ただし、これは厳密な意味での標準ですが、Webアプリで使用するには、ゲートウェイサーバーをコーディングする必要があることがわかりました。これは、rawソケットとバイナリ（高速ではありますが）シリアル化プロトコルを使用しているためです。

これが、私の大学でWoopsaと呼ばれる代替プロトコルを作成した理由です。 HTTP + JSONに基づくことにしました。 OPC-UAに似たプロトコルを作成しようとしました。情報モデリング、パブリッシュ/サブスクライブ、さらにはマルチリクエストも含まれています。それはすべて完全にオープンソースです。

ここでバージョン1.0をリリースしました： http://www.woopsa.org/

ソースコードはGitHubで直接入手できます： https://github.com/woopsa-protocol/Woopsa

基本的に、私たちのプロトコルは、HTTP + JSONを使用した標準化されたRESTfulAPIです。たとえば、GET /woopsa/read/Temperatureを作成して値を読み取ると、JSONで返信されます。

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

meta Wordを使用してオブジェクトツリーを取得することもできます。例：GET /woopsa/meta/これにより、次のようになります。

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

実際の産業用アプリケーションでは、MQTTはOPC-UAの代替ではありません。 90年代のOPCの当初の目標は、仕様を実装したクライアントとサーバー間の相互運用性を提供する標準の通信メカニズムとデータモデルを提供することでした。 OPC-UAは、そのコア目標をあきらめることなく、データモデルと通信を拡張および一般化します。これを行うために、標準では、タイムスタンプの形式、データ型のエンコード、履歴値、アラームなどを指定する必要があります。

MQTTは、設計上相互運用性を提供しないメッセージトランスポート層です。ペイロードの形式を規定したり、特定のデータ型、タイムスタンプ、値、階層など、アプリケーションが送信されているデータを理解できるようにする方法を指定したりすることはありません。 XML、JSON、またはプレーンテキスト、暗号化、base-64エンコード、またはその他の任意のカスタム形式のデータを出力する有効なMQTTサーバーを作成できます。クライアントアプリケーションがサーバーと対話できる唯一の方法は、サーバーが生成して受け入れるデータ形式を事前に知ることです。

OPC-UAは最近、帯域幅の使用率を改善するためのパブリッシュ/サブスクライブメカニズムを導入し、MQTTが現在提供している通信帯域幅の利点を減らしています。同時に、相互運用性を促進するために、MQTT仕様を拡張してデータ形式を指定する必要があります。 MQTTとOPC-UAの間で機能が収束することを期待してください。ほとんどの場合、MQTTはOPC-UAを満たすために成長しています。

MQTTは現時点でははるかに単純な実装であり、組み込みシステムやリソースに制約のあるシステムに利点があります。データモデリング仕様を追加すると、この利点が減少します。

要するに、OPC-UAは相互運用性のためのものであり、MQTTは単純なカスタム通信のためのものです。 MQTTは、OPC-UAの代わりになる前に成長する必要があります。

7
asthomas

MQTTは、I.o.Tに最適なプロトコルとして人気が高まっています。それには欠点がありますが、OPCUAが委員会による設計のオーバーヘッドを担っているのに対し、その単純さはしばしば強みと見なされます。

2つを組み合わせる必要がある場合は、単純なゲートウェイを試すことを検討してください mqtt2opcua

1
NZ Farmer

nserver は、この質問で説明されている問題を正確に解決するために設計された製品です。

さまざまなフィールドデバイスと通信し、それらの上に統合HTTPAPIを提供することができます。 Modbus RTUを介してデバイスと統合されますが、他の一般的なプロトコルが将来追加される予定です。

つまり、最初に次のようにデータ「タグ」を構成します。

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

次に、自動的に作成されたAPIエンドポイントを使用してタグを操作できます。

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

{
  data:{
    level: 1
  }
}

詳細については、 ドキュメント を確認してください。この製品は、評価および非営利目的で無料で使用できます。

免責事項：私はチームの一員です。これがお役に立てば幸いです。

1
astreltsov