端末制御センサーまたはデバイスを共有してループ制御インスタンスを形成する

21.1 概要

ServerSuperIO によって行われた以前の作業は、サービス コネクタやデバイス ドライバ コネクタの開発と適用など、ループ制御またはカスケード制御の形成の基礎を徐々に築きました。つまり、クラウドは現場や監視ポイントのセンサーを制御し、アプリや他の端末はセンサーを制御し、センサーが収集したデータに基づいて別のセンサーを制御するために、さまざまな形式でデバイス（ドライバー）やセンサーを制御します。 。

以下では、クラウド、アプリ、またはその他の端末がセンサー デバイスを制御する方法について説明します (センサー制御センサーも同様です。12. サービス インターフェイスの開発とクラウドとの双方向対話を参照してください)。通信プロトコルに従って、構造化されたソリューションでは、対応する機能を完了するためにあまり多くのコードを必要としません。効果は次のとおりです。

21.2 構造図

制御端末は制御コマンドを開始し、ServerSuperIO サービス インターフェイスを使用して単純なプロキシ サービスを開発し、サービス コネクタ IServiceConnector を介してデバイス ドライバーと対話します。制御コマンドはデバイスまたはセンサーに送信され、制御から返される確認メッセージを待ち、元のルートを介して制御端末に戻ります。

21.3 通信プロトコル

さまざまなデバイスやセンサーのプロトコルと互換性を持たせるにはどうすればよいのか、MQTT プロトコルを使用しないのではないかという質問がありました。中国の実情を踏まえると、経済状況が悪化すると、企業がオリジナルのハードウェア設備の交換に投資することが不可能であることは明らかです。また、プロトコルの独立性を実現するという ServerSuperIO 設計の原則にも準拠しておらず、標準プロトコルまたは非標準プロトコルを統合できます。川を渡りたいなら、橋を修理し、索道を敷設し、船を手配しなければなりません。どうやって川を渡るかはあなた次第です。

ServerSuperIO が統合されているプロトコルは何ですか? と誰かが質問しました。答えは上記にありますが、私が言いたいのは、すべての問題を解決できるフレームワークはないということです。逆の観点から考えると、設定などのプロトコルを追加する場合、企業は P2P 交換にどの程度の価値を提供したいので、プロトコル ドライバーは各自で作成することになります。

デモしたプロトコルは次のとおりです:

21.4 制御端末

制御端末には多くの種類があります: クラウドが制御コマンドを下位レベルに送信し、アプリまたは PC ソフトウェアがサービスに接続して制御コマンドを送信します。 、など。以下に示すように制御コマンドを送信します。

21.5 プロキシ サービス (SSIO サービス インターフェイス)

プロキシ サービスは、ServerSuperIO の IService インターフェイスを通じて実装されます。プロキシ サービスは、ServerSuperIO フレームワーク自体のシングルトン モードを使用して開発されます。継承クラスのコードは次のとおりです。

このイベントに対してプロキシ サービスがサブスクライブする Dev_ReceiveRequestInfos 関数に渡します。コードは以下のとおりです。

プロキシ サービスの Dev_ReceiveRequestInfos 関数は、サービス コネクタ インターフェイス IServiceConnector を介して、DeviceCode (addr) に従って、対応するデバイス ドライバーに情報を渡します。コードは次のとおりです。

プロキシ サービスは、ServiceConnectorCallback および ServiceConnectorCallbackError 関数インターフェイスを介して、デバイス ドライバーからフィードバックされた結果情報を受け取ります。途中で例外が発生した場合、ServiceConnectorCallbackError が呼び出されます。通常、ServiceConnectorCallback 関数が呼び出され、記録されたコマンドの対応関係に基づいて IO チャネルと通信し、結果を制御側に送信します。 ServiceConnectorCallback コードは以下のとおりです。

ここで注意すべき点が 1 つあります。それは、デバイス ドライバーが指定された時間内に制御コマンドの確認情報をフィードバックしない、つまりセンサーがフィードバックしないことです。対応する情報。この場合、タイミング検出サービスを追加する必要があります。タイムアウト後にフィードバック情報がない場合は、対応するメッセージが制御側に送信されます。コードは以下のとおりです:

21.6 デバイスドライバー

このデバイスドライバーはセンサーに対応し、データで相互作用します。デバイス ドライバーの RunServiceConnector インターフェイスは、プロキシ サービスの Dev_ReceiveRequestInfos (OnServiceConnector) 関数によって渡されたコマンド情報を受信する役割を果たします。コードは以下に示すとおりです:

説明は 2 つあります: 1. コマンド データを受信した後、OnSendData 関数を通じてすぐにデータ情報を送信し、設定された IP を使用して対応する IO チャネルを見つけることができます。自動制御モードに適しています。 2. コマンド データを受信したら、this.Protocol.SendCache プロトコル キャッシュに配置し、コマンドが発行されるのを待ちます。これは、ポーリング モードと同時実行モードに適しています。

返された結果オブジェクト ServiceConnectorCallbackResult の isAsyn パラメーターについて、それが true の場合、結果情報が AsyncServiceConnectorCallback コールバックを通じて返されることを意味します。これは、センサーが確認情報を返し、デバイスが返すのを待つ必要があることを意味します。ドライバーはそれをプロキシ サービスにフィードバックする前に受信します。それが false の場合、指示はすぐにプロキシ サービスにフィードバックされ、センサーとの対話が成功したかどうかに関係なく、データ情報を配信するのに適しています。

この関数でコールバック パラメーターを一時的に保存し、センサーが確認情報を返すのを待ってから、Communicate 関数でプロキシ サービスへの非同期コールバックをトリガーできます。コードは以下のとおりです。

21.7 デモ手順

2 つの TestDevice プログラムを開きます。1 つはデバイス センサーとして、もう 1 つは制御端末として使用されます。TestDeviceDriver はデバイス ドライバーであり、それにロードされます。サービス インスタンスを使用します。セルフ コントロール モードでは、TestSelfMain プロジェクトを使用します。これはプロキシ サービスであり、TestSelfMain にロードされます。詳細については、プロジェクトコード:を参照してください。

注: 将来的には、ビッグ データ プラットフォームもこのモードを通じてサイトに制御コマンドを発行できるようになります。

---

1. [連載] 「C# 通信 (シリアルポートとネットワーク) フレームワークの設計と実装」

2. [オープンソース] C# クロスプラットフォーム IoT 通信フレームワーク ServerSuperIO (SSIO) の紹介

2 . SuperIO (SIO) とオープンソースのクロスプラットフォーム IoT フレームワーク ServerSuperIO (SSIO) を応用して、全体的なシステム ソリューションを構築します

産業用 IoT および統合システム ソリューションのための C# 技術ルート (データ ソース、データ収集、データ アップロード、受付、ActiveMQ、Mongodb、WebApi、モバイルアプリ)

5. ServerSuperIO オープンソース アドレス:

モノのインターネットと統合テクノロジ (.NET) QQ グループ:

ダウンロード アドレス:

---

1.C# クロスプラットフォーム モノのインターネット 通信フレームワーク ServerSuperIO (SSIO) の紹介

「シリアル | モノのインターネット フレームワーク ServerSuperIO チュートリアル」 1.4 通信モード メカニズム。

「シリアル | Internet of Things Framework ServerSuperIO チュートリアル」 2. サービス インスタンスの構成パラメータの説明

「シリアル | Internet of Things Framework ServerSuperIO チュートリアル」 - 3. デバイス ドライバーの紹介

「シリアル | Internet of Things Framework ServerSuperIO チュートリアル」 - 4. シリアル ポートとネットワーク通信の両方をサポートするデバイス ドライバーのセットを開発するなど。

「連載 | Internet of Things Framework ServerSuperIO チュートリアル」 - 5. ポーリング通信モードの開発と注意点。

「連載 | Internet of Things Framework ServerSuperIO チュートリアル」 - 6. 同時通信モードの開発と注意点

「連載 | Internet of Things Framework ServerSuperIO チュートリアル」 - 7. 自律通信モードの開発と注意点

「連載 | インターネット」 of Things Framework ServerSuperIO チュートリアル》 - 8. シングルトン通信モードの開発と注意事項

《シリアル | Internet of Things Framework ServerSuperIO チュートリアル》 - 9. 複数パケット、スティッキーパケット、冗長データの問題を解決するプロトコルフィルター

《シリアル| モノのインターネット フレームワーク ServerSuperIO チュートリアル」 - 10. 大きなデータ ストリーム (ファイルなど) を継続的に送信する 2 つの方法

「モノのインターネット フレームワーク ServerSuperIO チュートリアル」 - 11. デバイス (ドライバー) とデバイス (ドライバー) の相互作用の実装そしてカスケード制御。

「シリアル | モノのインターネット フレームワーク ServerSuperIO チュートリアル」 - 12. サービス インターフェイスの開発とクラウドとの双方向対話

「シリアル | モノのインターネット フレームワーク ServerSuperIO チュートリアル」 - 13.さまざまな表示ニーズを満たすカスタム ビュー表示インターフェイスの開発

「シリアル | Internet of Things Framework ServerSuperIO チュートリアル」 - 14.構成ツールの紹介、デバイス ドライバー、ビュー ドライバー、サービス インスタンスのマウント

「シリアル | モノのインターネット フレームワーク ServerSuperIO チュートリアル」 - 15.データ永続化インターフェイスの使用法

「シリアル | IoT Framework ServerSuperIO チュートリアル」 - 16. OPC サーバーを使用する手順

「シリアル | IoT Framework ServerSuperIO チュートリアル」 - 17. リアルタイム データベースをサポートし、測定点データを保存するための高い同時実行性

「連載 | Internet of Things Framework ServerSuperIO チュートリアル」 - 18． OPC クライアントの統合と使用手順

「シリアル | Internet of Things Framework ServerSuperIO チュートリアル」-19. デバイス ドライバーと OPC クライアントは、mysql、oracle、sqlite、sqlserver の永続化をサポートします

「Internet of Things Framework ServerSuperIO チュートリアル」- 20. ネットワーク通信コントローラーは、対話型の負荷分散機能を向上させるためにグループ化されています。 v3.6.6バージョンがリリースされました

以上が端末制御センサーまたはデバイスを共有してループ制御インスタンスを形成するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。