I-IoTとは
1760年に蒸気エンジンが導入された後、農業用から繊維用まで、すべての動力に蒸気が使用されました。これは最初の産業革命と機械製造の時代を引き起こしました。19世紀の終わりには、電気、仕事を組織化する新しい方法、大量生産が始まり、第二次産業革命の始まりを示しました。20世紀後半、半導体の開発と電子制御装置の導入により、自動化の時代と第三次産業革命が起こりました。2011年のハノーバーフェアで、ヘニングカガーマン、ウルフディータールーカス、ウォルフガングウォルスターは、最新のデジタル技術を使用してドイツの生産システムを更新するプロジェクトのために、インダストリー4.0という用語を作り出しました。
インダストリー4.0は、以下を実装できると期待されています。
- 生産と情報通信技術を組み合わせる
- 顧客データと生産データを組み合わせる
- マシン間通信を最大限に活用する
- 生産を自律的、柔軟かつ効率的に節約して管理
世界経済フォーラムの創設者であり会長であるクラウスシュワブは、第4次産業革命の独立は3つの要因によって正当化できると考えています。
- 開発のペース。以前のものとは異なり、この産業革命は直線的に進んでいるのではなく、指数関数的に進んでいます。これは、私たちが暮らしている多面的で相互に依存し合う世界と、新しいテクノロジー自体がますます高度で効率的なテクノロジーを統合しているという事実の産物です。
- . , , , . , «» «» , , «» .
- . , , .
定義により、IoTは、ビッグデータ分析、クラウドテクノロジー、ロボット工学などのテクノロジー、そして最も重要なことには、ITと製造業の統合と収束などの業界をさらに発展させる鍵です。
I-IoT(産業用モノのインターネット)という用語は、自然ビジネスのデジタル変換であるIoTの産業用サブセットを指します。 I-IoTは、ビジネスをより柔軟に、より収益性が高く、理解しやすくし、新しいデジタルバリューチェーンを作成します。
従来の生産チェーンは、製品開発、原材料の調達と調達、製品の製造とサービスなどの簡単で連続したステップです。新しいデジタルトランスフォーメーションの本質は、サービスエコシステムと新しいビジネスモデルが特定のデジタルコアを中心に作成され、生産に新しい品質を与えることです。生産準備、試運転、運用の異なる段階間のコスト削減など。異なる部門とステージ間のリンクがより高速になり、市場でより効率的かつ競争力のある作業が可能になります。
I-IoTは、より多くのビジネス価値を生み出し、人間社会に多大な影響を与えることが期待されており、第4次産業革命の先駆けとなるでしょう。
フォーブスによると:
- IoT 157 2016 457 2020 , 28,5%
- , , IoT 2020 , 40 .
IoT I-IoT –
- , . , , . , .
- , , ; .
- I-IoT , .
- — , , . I-IoT, , .
- .
- , . , , , .
- . I-IoT .
- , .
CIM(コンピュータ統合製造)は、製造プロセス、自動化システム、および情報技術システムを企業レベルまたはエンタープライズレベルで統合するために1990年代に開発された製造システムの論理モデルです。CIMは、自動化された工場を作成するための設計方法としてではなく、ソフトウェアアプリケーションと通信ネットワークを介して異なるシステムとサブシステム間でデータと情報の収集、調整、共有、転送に基づく産業オートメーションの実装のための参照モデルとして見なされるべきです。CIMは、次の図に示すように、6つの機能レベルを持つピラミッドとして表現されることがよくあります。
レベル1-センサー、トランスデューサー、アクチュエーター
電子センサーは、1つまたは複数の物理量を電気信号に変換して、その後の変換、伝送、処理、および測定情報の表示が可能な、構造的に完全な測定機器です。アクチュエーター(アクチュエーター)は、制御コマンドをプロセスの物理的効果に変換するデバイスです。実際、その機能はセンサーの機能を補完します。アクチュエータは、制御信号を制御システムへの入力として受け入れ、エネルギーを出力として機構に送信します。
レベル2-RTU、マイクロコントローラー、CNC、PLC、DCS
- (Remote terminal unit RTU) — , . , , . , .
- (Embedded controller), , , . .
- (CNC) – , . . , - .
- PLC — , . PLC , , , . , , , . 10 100 .
- DCSは、製油所、発電所、化学プラントなどの連続プロセスで一般的に使用されます。PLCに実装されている制御機能と監視制御システム(SCADA)機能の両方を組み合わせています。PLCとSCADAは2つの別個のシステムであり、それぞれに独自のアドレススペースがありますが、DCSではこれらのシステムは同じ変数とデータ構造を使用します。
レベル3-SCADA、歴史家
SCADAシステムは、監視または制御オブジェクトに関する情報をリアルタイムで収集、処理、表示、およびアーカイブするためのソフトウェアパッケージです。データ収集システム(履歴)は、機器の稼働状況に関するリアルタイム情報を収集します。SCADAシステムは、次の主な機能を実装しています。
- PLC, , RTU , CIM.
- , .
- , , .
- - (HMI).
- HMI PLC.
4 -MES
MESは、ERPとSCADAまたはPLCの間にあるソフトウェアシステムで、会社の生産プロセスを効率的に管理するように設計されています。MESの主な機能は、計画と制御レベルを組み合わせてプロセスとリソースを最適化することにより、ビジネスと生産システムの管理を同期させることです。
MESシステムの主な機能は次のとおりです。
- 注文管理と生産計画
- 入ってくる原材料と半製品の管理
- 資産管理とモニタリング
- 生産追跡
- メンテナンス管理
- 品質チェック
レベル5-ERP
ERPには、会計、購買、プロジェクト管理、製造など、ビジネスの日常的な活動を管理するために組織が使用するソフトウェアパッケージが含まれています。ERPは、関連するシステム間の情報とデータの交換を管理する一連のビジネスプロセスを統合および定義します。ERPは組織のさまざまな部門からトランザクションデータを収集して送信するため、単一のソースとして機能することでデータの整合性を確保します。
生産ネットワーク
統合生産システムには、それぞれが特定のタスク専用のさまざまなタイプの通信ネットワークが必要です
- レベル1:フィールドバス
- レベル2:コントローラーのネットワーク
- レベル3、4、5:企業ネットワーク
コントローラー、センサー、アクチュエーターのインターフェースとしてフィールドネットワークが導入され、複雑な配線の必要性が低減されています。フィールドバスでは、センサーとアクチュエーターは、決定論的な方法で情報を確実に転送するための最小限の処理セットを備えています。
コントローラネットワークは、PLCノード間の通信を提供する必要があります。データ送信は特定の間隔で発生する必要があります。制御ネットワークとフィールドバスは、データと情報の送信のタイミングのため、しばしばリアルタイムネットワークとも呼ばれます。
企業ネットワークは、管理システムと計画および管理システムの間にあるネットワークです。ネットワークのこの層は、複雑な情報の処理を保証する必要がありますが、より短い期間です。したがって、このネットワーク層に厳しい時間枠を設定する必要はありません。
OPCサーバー
他の産業用通信規格は、OPCほど多くの産業や機器メーカーの間で広く受け入れられていません。多種多様な産業用システムとビジネスシステムを統合するために使用されます。 SCADA、セキュリティシステム(SIS)、プログラマブルロジックコントローラー(PLC)、および分散制御システム(DCS)は、OPCを使用して相互に通信します。また、ヒストリアンデータベース、MESおよびERPシステムとも通信します。 OPCの成功の理由は非常に単純です。これは、制御システムで使用されているメーカー、ソフトウェア、プロトコルに関係なく、さまざまな産業用デバイスやアプリケーションとの通信に使用できる唯一の真にユニバーサルなインターフェースです。 OPC標準の出現後、ほとんどすべてのSCADAがOPCクライアントとして再設計され、各ハードウェアメーカーは、コントローラー、I / Oモジュール、スマートセンサー、およびアクチュエーターに標準のOPCサーバーを提供し始めました。
OPCクラシック(データアクセスDA)
1995年、さまざまな企業が相互運用性の標準を定義するワーキンググループを作成することを決定しました。これらの企業は、Fisher Rosemount、Intellution、Intuitive Technology、Opto22、Rockwell、Siemens AGでした。
マイクロソフトメンバーも必要なサポートを提供するよう招待されました。ワーキンググループのタスクは、当時の最新のテクノロジに基づいて、Windows環境の情報へのアクセスの標準を定義することでした。開発されたテクノロジは、プロセス制御(OPC)用のオブジェクトリンクおよび埋め込み(OLE)と呼ばれていました。1996年8月、OPCの最初のバージョンが定義されました。
次の図は、主要な通信プロトコル-COM、DCOM、およびリモートプロシージャコール(RPC)を備えたOPC Classicのさまざまなレイヤーを示しています
COMは、コンポーネントアプリケーションを構築するためにMicrosoftが開発したソフトウェアアーキテクチャです。当時、これによりプログラマーは、他のアプリケーションが実装の詳細を気にすることなくそれらを使用できるように、再利用可能なコードをカプセル化することができました。 COMオブジェクトは、それを使用するアプリケーションを書き直すことなく、新しいバージョンに置き換えることができます。 DCOMはCOMのネットワークバージョンです。 DCOMは、あるコンピュータで実行されているCOMオブジェクトと別のコンピュータでリモートで実行されているCOMオブジェクトの違いをソフトウェア開発者から隠そうとします。このため、すべてのパラメーターを値で渡す必要があります。つまり、COMオブジェクトによって提供される関数を呼び出すとき、呼び出し元は関連するパラメーターを値で渡す必要があります。一方、COMオブジェクトは、結果も値で渡すことにより、呼び出し元に応答します。パラメータをネットワーク経由で送信されるデータに変換するプロセスは、マーシャリングと呼ばれます。マーシャリングが完了すると、データストリームはシリアル化され、送信され、接続のもう一方の端で元のデータの順序に復元されます。
DCOMはRPCメカニズムを使用して、同じネットワーク上のCOMコンポーネント間で情報を透過的に転送および受信します。RPCメカニズムは、システム開発者がサーバー用の特別な手順を開発する必要なしにリモートプログラムの実行を要求できるようにするためにMicrosoftによって開発されました。クライアントプログラムは適切な引数を使用してサーバーにメッセージを送信し、サーバーは実行されたプログラムの結果を含むメッセージを返します。
OPC Classicにはいくつかの制限があります。
- Microsoft Windowsファミリのオペレーティングシステムでのみ使用できます。
- ソースコードが閉じているDCOMテクノロジとの接続。
- DCOMに関連する構成の問題。
- 不正確なDCOM通信中断メッセージ。
- DCOMがインターネット経由でデータを交換できないこと。
- DCOMが情報セキュリティを確保できない。
OPC Classicデータ収集モデル
OPC Classic標準の目的は次のとおりです。
- サーバー側でデータを構造化して、クライアント側でデータを収集しやすくします。
- 通信サービスと標準の通信メカニズムを定義する
本質的に、OPC Classic標準は次のように機能します。
サーバーはすべての利用可能なデータを管理します。
サーバーはオンデマンドでデバイスからのデータ要求を送信し、内部キャッシュを定期的に更新します。サーバーは、OPCクライアントによって要求された変数の各グループのキャッシュを初期化および管理します。 OPCクライアント側のスキャンレートは、デバイスからデータを収集してその内部キャッシュを更新するOPCサーバーのスキャンレートよりも低くすることはできません。 OPCサーバーがデバイスをスキャンする速度の2倍の速度でキャッシュから読み取り、更新するようにOPCクライアントを構成することをお勧めします。交換される各データには、タイムスタンプと品質によって示される独自の意味があります。データ交換には、値の変更時の読み取り、書き込み、自動更新が含まれます。読み取りまたはポーリングはOPCクライアントによって実行され、OPCクライアントは定期的にグループデータのリクエストを送信します。記録フェーズは同期または非同期です。自動更新は、OPCクライアントによって提供される要求レートを使用します。 OPCサーバーは、各更新をチェックして、キャッシュされた値の絶対値から現在の値を引いた値が、クライアントが指定したデッドゾーンにその変数に構成された範囲を掛けた値より大きいかどうかを確認します。次のように書くことができます:
if (abs(last_cached_value – current_value) > (PERCENT_DEAD_BAND/100) * range) {
//cache is updated, and the client is notified through a callback mechanism
}
OPCサーバーからの情報は、効率のために関連アイテムのグループに編成されています。グループには2つの異なるタイプがあります。
- パブリックグループ:すべてのクライアントが利用可能
- ローカルグループ:それらを作成したクライアントのみが使用できます
OPC UA
COMとDCOMの採用の増大する制約に対するOPC財団の最初の対応は、OPC XML-DAの開発でした。 OPCの特性を保持していますが、製造元にも特定のソフトウェアプラットフォームにも関連付けられていない通信インフラストラクチャを採用しています。 OPC-DA仕様からWebサービスベースのバージョンへの変換は、企業や外部の世界とますます相互作用し、統合する企業のニーズを満たすには不十分であることが証明されています。
OPC UAアーキテクチャについては、opcfoundation.org/developer-tools/specifications-unified- architectureを参照してください。
したがって、OPC UAプロトコルは、既存のすべてのCOMベースのバージョンを置き換え、セキュリティとパフォーマンスの問題を克服するために開発されました。この標準は、プラットフォームに依存しないインターフェースのニーズに対応し、機能を失うことなく複雑なシステムを記述する拡張可能なデータモデルの作成を可能にします。OPC UAは、IEC 62451規格で定義されたサービス指向のアプローチに基づいており、次の目的があります。
- Windows以外のプラットフォームでのOPCコンポーネントの使用
- 主なコンポーネントを小さなデバイスに統合することができます
- ファイアウォールベースのシステム全体に標準的な通信を実装
技術的な観点から、OPC UAは次のように機能します。
- APIはクライアントとサーバーのコードをOPC UAスタックから分離します
- UAスタックはAPI呼び出しをメッセージに変換します
- UAスタックは、APIを介してクライアントまたはサーバーにメッセージを送信してメッセージを受信します
OPC UA情報モデル
OPC UAでの情報モデリングの基本原則:
- 継承階層を含むオブジェクト指向メソッドの使用。
- タイプとインスタンスへのアクセスにも同じメカニズムが使用されます。
- 情報は、ネットワーク内の完全に接続されたノードを使用することにより利用可能になります。
- ノード間のデータ型階層とリンクは拡張可能です。
- 情報をモデル化する方法に制限はありません。
- Information Modelingは常にサーバー側でホストされます。
OPC UAサーバーがクライアントに提供するオブジェクトと関連情報のセットは、アドレススペースです。アドレススペースは、OPC UA情報モデルの実装と考えることができます。
OPC UAアドレススペースは、リンクによってリンクされたノードのコレクションです。各ノードには、属性と呼ばれるプロパティがあります。特定の属性セットがすべてのノードに存在する必要があります。ノード、属性、リンクの関係を次の図に示します
ノードは、特定の目的に応じて、ノードのさまざまなクラスに属することができます。OPC UAには、変数、オブジェクト、メソッド、ビュー、データタイプ、変数タイプ、オブジェクトタイプ、および参照タイプの8つの標準ノードクラスがあります。OPC UAで最も重要なノードクラスは、オブジェクト、変数、およびメソッドです。
OPC UAセッション
OPC UAは、状態情報を含むクライアントサーバー通信モデルを提供します。この状態情報はセッションに関連しています。セッションは、クライアントとサーバー間の論理接続として定義されます。各セッションは、基礎となる通信プロトコルから独立しています。プロトコルレベルで問題が発生しても、セッションは自動的に終了しません。セッションは、クライアントからの明示的な要求の後、またはクライアントの非アクティブのために終了します。アイドル間隔は、セッションの作成中に設定されます。
OPC UAセキュリティモデル
OPC UAセキュリティモデルは、セッションのベースとなるセキュアチャネルを定義することによって実装されます。セキュアチャネルは、次のようにデータを交換します。
- デジタル署名を使用してデータの整合性を保証します。
- 暗号化によりプライバシーを提供します。
- X.509証明書を使用してアプリケーションを認証および承認します。
この図は、アプリケーション層、セッション層、トランスポート層の各層を示しています。
アプリケーション層は、OPC UAセッションを確立したクライアントとサーバーの間で情報を転送するために使用されます。OPC UAセッションは安全なチャネルで確立されます。トランスポート層は、ソケット接続を介したデータの送受信を担当する層であり、エラー処理メカニズムが適用されて、システムがサービス拒否(DoS)などの攻撃から確実に保護されるようにします。
OPC UAデータ交換
OPC UAクライアントとサーバー間でデータを交換する最も簡単な方法は、読み取りおよび書き込みサービスを使用することです。読み取りおよび書き込みサービスは、単一のデータや複数の値ではなく、データのグループを転送するために最適化されています。これらを使用すると、ノードの値または属性のいずれかを読み書きできます。読み取りサービスには次のパラメーターがあります
。maxAge:これは、値を取得するのにかかる最大時間です。これはクライアントによって示されます。キャッシュ内のコピーがクライアントによって構成されたmaxAgeパラメーターより古い場合、サーバーはデバイス(センサーなど)に接続するように強制します。 maxAgeがゼロに設定されている場合、サーバーは現在の値を提供し、常にデバイスから直接読み取る必要があります。
タイムスタンプタイプ:OPC UAは、ソースタイムスタンプとサーバータイムスタンプの2つのタイムスタンプを定義します。元のタイムスタンプはデバイスからのタイムスタンプであり、サーバーのタイムスタンプはOPC UAサーバーが実行されているオペレーティングシステムからのタイムスタンプです。
ノードと属性のリストは次のようになります。
- NodeId
- インスタンス値のAttributeId
- DataEncoding:これにより、クライアントは適切なデータエンコーディングを選択でき、デフォルトはXML、UAバイナリです。
OPCプロトコルの機能
OPCプロトコルを完全にフリーと呼ぶことはできません。OPC SDKを使用してソフトウェアを開発するには、OPC Foundationのメンバーである必要があります。ただし、今ではfreeopcua.github.ioなどのクライアントおよびサーバーライブラリの無料の実装がありますが、それらにはまだpub / sub実装がありません。
MQTTなどの他のプロトコルと比較して、OPCは軽量ではありません。
PLCプログラマブルロジックコントローラー
PLC(プログラマブルロジックコントローラー、PLC)という用語は、その後EN 61131(IEC 61131)規格で定義されました。PLCは、産業環境で使用するために特別に設計された統合デジタル電子制御システムです。PLCは常に入力デバイスの状態を監視し、ユーザープログラムに基づいて決定を行い、出力デバイスの状態を制御します。
PLCの要件:
- それは、極端な温度、汚れ、低品質の電源ネットワークなどの過酷な産業条件で機能できる必要があります。
- 業界固有の24VDCまたは240VACディスクリート入出力信号とアナログ信号(±10V、4-20mAなど)で動作する必要があります。
- プログラミング言語は、自動化エンジニアが理解する必要があります
- PLCは産業施設の動作を継続的に監視する必要があります
- オペレーティングシステムは、スキャンサイクルを実行するのに十分な速さである必要があります(20〜100ミリ秒)
次の図は、PLCの基本的な動作モードの構造を示しています(CPU Simaticの例を使用)。
SIMATIC S7-1500を搭載したOPC UA
前提条件- SIMATIC TIAポータルV13 - 16がインストールされている必要があり
OPCサーバとコントローラをシミュレートするには、インストールと設定SIMATIC S7-PLCSIM上級バージョン2または3必要があります
support.industry.siemens.com/cs/document/109772889/trial -download%3A-simatic-s7-plcsim-advanced-v3-0?dti = 0&lc = en-WW既存のSimatic TIA Portal V14 SP1パッケージがインストールされているシステムにシミュレーターバージョン3をインストールしました。インストール前に、インストーラーはPLCSIM V14がSIMATIC S7-PLCSIM V3と互換性がなく、削除する必要があることを通知しました。これらの手順を実行した後、インストールが中断されました。テストプロジェクトは、CPU 1512C-1 PNを使用してTIAポータルで作成されています。特別な機能として、「シミュレーションの開始」ボタンを使用してシミュレーションを実行できなくなりましたが、PLCSIM Advancedの実行中に「デバイスにダウンロード」ボタンは機能します。
ネットワーク経由でシミュレーターにアクセスするには、PLCSIM Virtual Ethを有効にする必要があります。アダプター。最初にWinPcapソフトウェアをインストールする必要があります。次に標準のイーサネット設定です。
「開始」ボタンを押すと、シミュレーターがアクティブになり、ネットワーク上に表示されます
次に、プロジェクトルートの[プロパティ]ショートカットメニューを呼び出すために、ダイアログボックスの[保護]タブにある[ブロックコンパイル中のシミュレーションをサポートする]チェックボックスを設定する必要があります。
次のステップは、プロジェクトでOPCサーバーをアクティブ化し、ライセンスのタイプを選択することです(それを見落とすと、プロジェクトはコンパイルされません)。
さらに、ソフトウェアをPLCSIM Advancedにアップロードするプロセスは、前に説明したものを除いて、標準シミュレータへのアップロードと似ています。
TIAポータルテストプロジェクトでは、DB1は1つのタグ「pressure」で作成され、デジタル出力「Q0.1 Tag_2」が割り当てられました。
OPCサーバに接続し、ネットワーク、ノードやタグを監視するには、からダウンロードすることができUaExpert OPCクライアント、使用することができwww.unified-automation.com/products/development-tools/uaexpert.htmlを。
OPCサーバーに接続するには、新しい接続を追加して、以前にTIAポータルのOPCサーバープロジェクト設定で設定したエンドポイントURLを登録する必要があります。私の場合は、opc.tcp://192.168.1.113:4840です。
OPCクライアントをシミュレータサーバーに接続すると、作成されたノードとタグを確認できます。
OPCクライアントとサーバーの相互作用のプログラムによる実装では、Python github.com/FreeOpcUa/python-opcuaのライブラリのオープンソース実装を使用できます。コードの例もあります。使用する前に、必要な依存関係をインストールする必要があります。
pip install freeopcua
pip install cryptography
3つのタグを持つOPCサーバーを作成する最も簡単な例
from opcua import Server
from random import randint
import datetime
import time
class Opc:
def __init__(self):
self.server = Server()
self.url = "opc.tcp://127.0.0.1:4848"
self.server.set_endpoint(self.url)
self.namespace_uri = "OPCUA_SIMULATION_SERVER"
self.namespace = self.server.register_namespace(self.namespace_uri)
self.root_node = self.server.get_objects_node()
self.parameters = self.root_node.add_object(self.namespace, "Parameters")
def create_variable(self, name, initial=0):
variable = self.parameters.add_variable(self.namespace, name, initial)
variable.set_writable()
return variable
def main():
opc = Opc()
tag_1 = opc.create_variable("Temperature", 25)
tag_2 = opc.create_variable("Pressure")
tag_3 = opc.create_variable("Time")
opc.server.start()
print("Server started at {}".format(opc.url))
while True:
#tag_1.set_value(randint(10, 50))
tag_2.set_value(randint(200, 999))
tag_3.set_value(datetime.datetime.now())
time.sleep(2)
if __name__ == '__main__':
main()
クライアント部分の同じ最も単純な例
from opcua import Client
import time
url = "opc.tcp://127.0.0.1:4848"
client = Client(url)
client.connect()
print("Client connected")
Temp = client.get_node("ns=2;i=2")
Temp.set_value(25)
if __name__ == '__main__':
while True:
temperature = Temp.get_value()
print(temperature)
time.sleep(1)
UaExpertクライアントを使用して接続を監視することも可能です
I-IoT Edgeのコンセプト
Edgeは、本番環境とクラウドのIoTワールドの間のハブです。 Edgeは3つのマクロコンポーネントに分解できます:Edge Gateway、Edge tools、Edge Computing
2017年、ガートナーは次のように発表しました:「Edgeはクラウドを食べる」。このステートメントは少し物議を醸すように聞こえるかもしれませんが、エッジが長年にわたって果たしてきた役割を強調しています。クラウドへの移行段階の後、産業企業は、すべてを遠隔地で行うことが常に可能であるとは限らないことに気づきました。この理由は次のとおりです。
- . . , , . .
- : . , , , , 1 50 .
- ネットワークレイテンシ:高度なプロセス制御または分析により、短い時間枠で機器の動作をプロファイルするためのデータ変更に関連して、ネットワークレイテンシが大きく変動します。機器の最適化は、特定の時間間隔内で最速で実行するために必要です。
- データの接続。ワークフローを最適化したり、機器を保守したりするには、インターネット接続にアクセスせずにコンポーネントを交換する必要があります。
Edgeゲートウェイ
エッジゲートウェイは、エッジデバイスの中核です。エッジゲートウェイの主な役割は、MQTT、CoAP、HTTPS、AMQPなどの伝送プロトコルを使用してデータを収集し、I-IoTハブに送信するために産業用ソースに接続することです。
エッジゲートウェイの最も重要なコンポーネントは、産業用アダプターとIoTアダプターです。産業用アダプターは通常、フィールドエリアからのデータをサブスクライブし、データバス上に公開します。通常、選択したデバイスのコネクタを実装し、I-IoTデータストリームのソースとして機能し、エッジデータバスで利用できるようにします。一方、IoTアダプターは、データバスから値を受信し、それらをIoT Data Hubに送信します。ゲートウェイエッジの重要な部分は、ストアアンドフォワードコンポーネントです。これは、一時的なローカルストレージにデータを保存するための一般的なメカニズムです。ネットワークの不安定性に対するデータ伝送の堅牢性を提供します。グローバルネットワークでは、通信チャネルの不安定性と遅延が非常に高くなります。保存と転送のメカニズムは次のとおりです。
- 短時間の非アクティブをカバーする限られたメモリバッファ
- 長期間の非アクティブまたは大量のデータトラフィックに対応できるディスク上の専用ストレージ領域。
データ転送を保証する必要がある時間枠の範囲は、特定のシナリオと、エッジメモリおよびストレージの物理リソースによって異なります。
構成ユーティリティ(エッジツール)
エッジツールには次の機能が必要です。
- リモートおよびローカルの両方でデータ収集を簡単に管理および構成する機能
- 修正および更新に登録する可能性
- ロギングアクションの可能性
- ユーザーインターフェイスを使用してデータを表示および変更する機能
- 起動時のクラウドでの自己構成と自己登録
- クラウドからコマンドを受信して実行する機能
エッジコンピューティング
エッジコンピューティングには次の機能があります。
- I-IoT(ミドルウェア)ソフトウェアを使用して、オフラインとオンラインの両方でアクションを実行する機能。
- カスタムアプリケーションをホストする可能性
- I-IoTミドルウェアと連携して、またはリモートで分析をオフラインで実行する機能。
- I-IoTミドルウェアからアクションを実行したり分析をロードしたりする機能
- 非構造化および特定のデータをオンデマンドまたは条件付きスタートアップでI-IoTミドルウェアに送信する機能
エッジの実装
クラウドおよび相手先ブランド供給(OEM)ベンダーは、独自のオペレーティングシステムに基づいてさまざまなソリューションを開発するか、クラウドに依存しないソフトウェア開発キット(SDK)を提供しています。
Azure IoT Edge
Azure IoT Edgeは、MicrosoftのAzure IoT向けEdgeソリューションです。このプラットフォームは、ストレージと転送、Edge Analytics、およびネイティブまたは標準プロトコルをインターネットプロトコルに変換するための複数のアダプターをサポートしています。Azure IoT Edgeは、OPCクラシックおよびOPC-UA実装でOPCサーバーもサポートします。製品の概要:
- コンテナサブシステムをサポートするLinuxまたはWindowsデバイスで動作します。
- 無料、オープンソース、MITライセンスのランタイム
- AzureサービスまたはMicrosoftパートナーのCloudフロントエンドからのDocker互換コンテナー。IoT Hubを使用してクラウドからワークロードをリモートで管理およびデプロイできます
緑の草
Greengrassは、AWSが提供する次世代のIoT Edgeです。AWSは、AWS Edgeを構築するためのSDKを提供し、クラウド機能をGreengrassを備えたエッジデバイスに拡張します。これにより、管理、分析、永続ストレージにクラウドを使用しながら、デバイスがローカルでアクションを実行できます。GreengrassはOPC UAをサポートし、OPC Classicはサポートしません。利点:
- ほぼリアルタイムのイベント応答
- オフライン作業
- AWS IoT Greengrassは、LAN経由とクラウドの両方でデバイスデータを認証および暗号化します
- コンテナーサポートによる簡略化されたデバイスプログラミング
Android Things
GoogleはEdge開発用のSDKを提供しています。Androidを次世代のEdgeデバイスとして後援しています。プラットフォームの機能:
- Android SDKおよびAndroid Studioを使用した開発
- Androidプラットフォームを介したディスプレイやカメラなどのハードウェアへのアクセス
- アプリをGoogleサービスに接続する
- 周辺I / O API(GPIO、I2C、SPI、UART、PWM)を介した追加の周辺機器の統合
- Android Things Consoleを使用してアップデートを無線で送信するおよびセキュリティアップデート
Node-RED
これは、モノのインターネット用のビジュアルプログラミングツールであり、デバイス、API、およびオンラインサービスを相互に接続できます。Node-REDランタイムはNode.jsの上に構築されているため、イベント駆動型の非ブロッキングモデルを最大限に活用します。Node-REDは、もともとIBM Emerging Technology Servicesチームによって開発され、現在はJS Foundationの一部であるストリーミングプログラミングツールです。
特徴:
- ブラウザで直接プログラムロジックを作成する
- Node-REDランタイムはNode.jsの上に構築されています
- Node-REDで作成されたストリーム(論理ユニット)は、簡単にエクスポートおよびインポートできるJSONファイルに保存されます
- node.jsをサポートするすべてのデバイスで実行可能
- 膨大な数の拡張機能
インテルIoTゲートウェイ
特徴:
- クラウドとエンタープライズ接続。
- センサーや既存のコントローラーに接続可能。
- 選択したデータを事前にフィルタリングして配信します。
- レガシーシステムへの接続を容易にするためのローカルの意思決定。
- ハードウェアデータの暗号化とソフトウェアロック。
- デバイスのローカルコンピューティングと分析。
Flogo IoT
Project Flogoは、イベント駆動型アプリケーションを構築するための軽量なオープンソースのGoベースのエコシステムです。トリガーとアクションは、インバウンドイベントの処理に使用されます。対話インターフェースは、アプリケーション統合、ストリーム処理などの主要な機能を提供します。
- 条件付き分岐およびビジュアル開発環境を備えた統合フローアプリケーションエンジン
- ストリーミングは、単純なパイプラインベースのストリーム処理アクションであり、複数のトリガー間でイベントを集計し、時間枠全体で集計することができます。
- リアルタイムのコンテキスト決定のための宣言ルール
- コンテンツベースの条件付きルーティング、JWT検証、レート制限、回路遮断などのMicrogatewayパターン
エクリプスクラ
Eclipse Kuraは、Java / OSGiに基づく、オープンソースで拡張可能なIoT Edgeフレームワークです。Kuraは、IoTゲートウェイのハードウェアインターフェイス(シリアルポート、GPS、ウォッチドッグ、GPIO、I2Cなど)へのAPIアクセスを提供します。これには、すぐに使用できるフィールドプロトコル(Modbus、OPC-UA、S7を含む)、アプリケーションコンテナー、およびデータの取得、処理、クラウドプラットフォームへの公開のためのWebベースのビジュアルプログラミングが含まれます。
EdgeX Foundry
EdgeX FoundryTMは、IoTエッジコンピューティング用の共通のオープン環境を作成する、Linux Foundationによってサポートされるベンダー中立のオープンソースプロジェクトです。プロジェクトの中心には、完全なOSに依存しない参照ソフトウェアプラットフォームでホストされる相互運用性インフラストラクチャがあり、市場を統合してIoTソリューションの展開を加速するプラグアンドプレイエコシステムを作成します。
産業用データソースのエッジ接続オプション
- フィールドバスのエッジ
- OPC DCOMのEdge
- OPCプロキシのエッジ
- OPC UAのエッジ
- コントローラー上のOPC UA
OPC UAおよびコントローラー上のEdge
OPC UAの機能を最大化するため、OPC UAサーバーに接続することをお勧めします。OPCサーバーへの接続は、2つの異なる方法で展開できます。最初のケースでは、EdgeはOPC UAクライアントインターフェイスを介してOPC UAサーバーに接続します。データソースは、PLC、DCS、SCADA、またはHistorianのいずれかです。
2番目のケースでは、以前にSimatic CPU 1500で説明したように、エッジはPLCに直接インストールされたOPCサーバーに接続します。
MQTTプロトコル
Pub / Subは、メッセージを送信するクライアントを、メッセージを受信する別のクライアントから分離する方法です。クライアント/サーバーモデルとは異なり、クライアントはIPアドレスやポートなどの物理識別子を認識しません。 MQTTはパブ/サブアーキテクチャであり、メッセージキューではありません。メッセージキューは、その性質上、メッセージを保存しますが、MQTTは保存しません。 MQTTでは、誰もトピックをサブスクライブ(またはリッスン)しない場合、単に無視されて失われます。
メッセージを送信するクライアントはパブリッシャーと呼ばれます。メッセージを受信するクライアントはサブスクライバーと呼ばれます。中心となるのは、クライアントの接続とデータのフィルタリングを担当するMQTTブローカーです。そのようなフィルターは以下を提供します:
- トピックによるフィルタリング-設計により、顧客はトピックと特定のトピックブランチにサブスクライブし、必要以上のデータを受け取りません。投稿されたすべてのメッセージには件名が含まれている必要があり、ブローカーはこのメッセージをサブスクライバーに再送信するか、無視する責任があります。
- コンテンツフィルタリング-ブローカーは、公開されたデータをチェックしてフィルタリングすることができます。したがって、暗号化されていないデータは、他のクライアントに保存または転送する前にブローカーで管理できます。
- タイプによるフィルタリング-サブスクライブしているデータのストリームをリッスンしているクライアントも、独自のフィルターを適用できます。受信データを分析できます。これに応じて、データストリームはさらに処理されるか無視されます。
MQTTには3つのレベルのサービス品質があります。
- QoS-0 ( ) – QoS. « », . ;
- QoS-1 ( ) – . , PUBACK;
- QoS-2 ( ) – QoS, , . - . QoS-2, PUBREC. , PUBREL. PUBREL . PUBREL PUBCOMP. PUBCOMP , .
現在、MQTTプロトコル仕様には3.1.1と5.0の2つのバージョンがあります。プロトコルの詳細な説明をすることができますここで見つけるか、私のプレゼンテーションの記録github.com/vladipirogov/Message-Queue-Telemetry-Transport、www.youtube.com/watch?v=fYoGubQFz5c&t=5sとwww.youtube.com/watch?v=8mupuCjedlc。
次回の記事では、Node-redをEdgeゲートウェイとして、Apache Kafkaをデータマネージャーおよび一時ストレージとして、Kafka Streamsをルールエンジンとして、Mosquitto(別の実装も可能)をMQTTコネクタとして使用して、カスタムEdge I-IoTプラットフォームの実装例を示します... InfluxDataテクノロジは、時系列データを格納するために使用されます。
交流会の動画へのリンク。
情報源
- デジタル変革プラットフォーム
- OPC統合アーキテクチャ仕様
- ACS TPの百科事典
- FreeOpcUaは、オープンソース(LGPL)OPC-UAスタックと関連ツールを実装するプロジェクトです。
- GR Kanagachidambaresan Internet of Things for Industry 4.0
- インダストリー4.0向けMax Hoffmannスマートエージェント
- Wolfgang Mahnke OPC統合アーキテクチャ
- クラウスシュワブ第4次産業革命
- ペリーリーモノのインターネットのアーキテクチャ
- Ismail ButunインダストリアルIoT
- MQTT仕様