Clever Geek Handbook

Linux上の産業用交換プロトコルのゲートウェイ。 自分で組み立てる

私は、自動プロセス制御システム（ACS TP）の開発、実装、および運用に従事しています。 当初、彼はSCADAシステムで働いていました。 その後、彼はすぐに産業機器を交換するためのプロトコルの使用に切り替えました。 自己記述ドライバーとデータ収集システムのセットアップ。 現時点では、私の仕事はModbus-s、IEC-101 / 104-s、OPC、その他のプロトコルの雰囲気を通り抜けています。



画像

図 1.産業用制御システムで使用されるさまざまな通信プロトコル



典型的なデータ収集システムの仕組みについて簡単に説明します（少し簡略化）。



画像

図 2.データ収集システム



OPCサーバーと呼ばれる特別なソフトウェアは、RS-485インターフェースに接続されたデバイスをポーリングします。 OPCサーバーは、SCADAシステムとデバイス間の一種のレイヤーであり、デバイスが通信する言語をSCADAシステムが理解できる言語に翻訳します。 イーサネット/ RS-485コンバーターは、TCP / IPパケットをRS-485の物理環境を通過するパケットに変換するために使用されます。



このスキームには、いくつかの欠点があります。



  1. たとえば、200ミリ秒の応答を待つOPCサーバーのタイムアウトを設定します。 理想的なケースでは、パケットが遅延なくイーサネットに送られると、デバイスとの通信は適切な速度（強度）で進みます。 ただし、応答を含むパケットが300ミリ秒（200ミリ秒の応答タイムアウトを超える）遅延する場合、OPCサーバーは要求への応答が到着していないと見なし、次の要求を送信します。 この時点で、前のリクエストに対する回答が到着しますが、OPCサーバーはこれが現在のリクエストに対する回答であると判断し、不正なデータをトップに送信します。 その結果、ワークステーション上のデータは「ジャンプ」します。 このような状況から逃れるために、タイムアウトをさらに設定します。 3000 msのマージンで撮影してください。 回答が3000ミリ秒よりも早く到着した場合、残りの時間を待たずに次の要求に進みます。 これまでのところ、すべてが順調に進んでいますが、いくつかのデバイスが応答を停止するとすぐに、各デバイスに対して3000ミリ秒の遅延が生成されます。 ポーリング時間が増加しています。
  2. 産業用制御システム（Modbus、電気メーター）で使用されるプロトコルのほとんどは、同じパラメーターの連続ポーリングに基づいています。 ほとんどの場合、パラメータ値は変更されないままであるため、データネットワークを使用して同じ値を送信します。 伝送媒体がGPRSであり、トラフィックにお金がかかる場合、これは非合理的です。 さらに、GPRS伝送媒体では、パケット遅延が数秒に達する可能性があります。 同じものを転送する時間とリソースを無駄にするのはなぜですか？


上記の状況では、データは変更によって（散発的に）上方に送信され、複数の値によって1つのTCPパケットにグループ化されるプロトコルがより適しています。 そのようなプロトコルは、IEC-60870-5-104およびOPC UAです。 ModBus-TCPも適しています。変更送信はありませんが、データがあまりない場合は、1つのパッケージにパッケージ化できます。 DINレールに吊るし、RS-485を介してデバイスを接続し、イーサネットを介してSCADAシステムにデータを転送することができる何らかの種類のコントローラーがあれば良いと思います。



一般的に、かなりの数のハードウェアゲートウェイがあります。 しかし、既成の分割不可能なソリューションの形で。 すべてを1つに。 そして、私はそれが本当に好きではありません。 かつて、6つのRS-485ポートと2つのイーサネットを備えたSET-4TMメーターのプロトコルをOPC UAに変換するゲートウェイが必要でした。 あるメーカーには必要な通信プロトコルをサポートするゲートウェイがありますが、RS-485ポートはほとんどなく、他のメーカーには適切な数のRS-485ポートがありますが、イーサネットポートは2つありません。 3番目には2つのイーサネットポートがありますが、すべての通信プロトコルではありません。 4番目のものにはほとんどすべてのものがありますが、IEC-60870-5-104で使用可能なOPC UAはなく、ModBus-TCPはこれらのプロトコルにOPCサーバーを必要とします。



そして、それがいかにすばらしいか：あるメーカーからOSを搭載したコントローラーまたはミニPCを購入することです。 別のコントローラ用のソフトウェアを購入します。 あるソフトウェア製造元が何かをサポートしていない場合、別のソフトウェア製造元からソフトウェアを購入し、標準のソフトウェアインターフェイスを介してソフトウェアコンポーネントを組み合わせます。 ここは明るい未来のようです！



プロトコルゲートウェイは、コンポーネントに分割できないため、OPCサーバーおよびイーサネットからRS-485へのコンバーターバンドルよりも使用頻度が低いのはこのためです。



Linux版SCADAが未開発の理由の1つは、SCADAがあり、その中でサポートされている交換プロトコルがほとんどなく、機器と通信するためのOPCサーバーがないことです。 SCADAは、インテグレータをハードウェアと1対1のままにします。



読者はすでに質問をするかもしれません：あなたは何を提供できますか？ すでに何がありますか？ 次のプロトコル用のLinux用のOPC UAサーバーがあります。





OPC UAプロトコルだけでなく、上位レベルにデータを送信するために、「 OPC UAからModbusへの変換およびIEC 60870-5-104 」が作成されました。 これらのプロトコルのデータ転送機能に加えて、「コンバーター」にはWebサーバーが組み込まれています。 特別なエディターを使用して、ダイアグラムを描画し、その上にタグ値を表示してから、ブラウザーで開くことができます。 コントローラーでミニSCADAが直接判明します。 回路のアニメーションがどのように機能するか、私はすでにここで、エディタについてここで書いた 。 将来、「OPC UA to MQTT Converter」が計画されています。



OPC UAサーバーとコンバーターは、x64、ARMv7、およびAARCH64アーキテクチャで動作します。

したがって、ハードウェアには、ミニ産業用コンピューターに基づいた実績のあるソリューションと、すべての種類の「ラズベリーpi互換」ARMミニコンピューターの両方を使用できます。 サンプルを使用してソフトウェアをインストールおよび構成する方法については、 こちらまたはこちらをご覧ください 。



一般に、複合体の構造は次のようになります。



画像



システムはスケーラブルです。 現在の問題の解決にのみ必要なコンポーネントが使用されます。



OPC UAサーバーを使用して、スキームが変換されます。



画像



次のものがあります。





したがって、OPCサーバーと「Ethernet to RS-485 Converter」を接続する代わりに、それらの機能を組み合わせた1つのデバイスを取得します。 私はこのスキームがより好きです。 あなたはどうですか？


More articles:


All Articles