SMSからAWSへ：プロジェクト固有の制御テクノロジの選択

この投稿は、最初の管理システムの作成を考えている人々を対象としています。経験豊富な専門家は、「モノのインターネット」のさまざまな制御技術の「トップダウン」ビュー、結論、および結論の短い予測に興味があるかもしれません。

仕事

でシナジーチーム、我々は産業用コントローラを設計し、製造しています。これらは、リソースアカウンティング、エネルギー施設管理、および一般にInternet of Things（IoT）と呼ばれるその他のアプリケーション向けに設計されています。多くの場合、お客様はコントローラーだけを必要としません。彼らは、制御システムを含む完全なソリューションを必要としています。



そして、このシステムは最適に近いはずです：高速、軽量、そして信頼性。しかし、よく知られている逸話によれば、これらすべての要件を同時に満たすことは不可能です。やろうとした課題に応じてバランスを探す必要があります。





この投稿では、IoTコントローラーが制御システムに直接接続されている場合（直接接続されているIoT）のタスクのクラスに限定しました。したがって、私たちのタスクは、次のような管理システムを開発することです。

• コントローラに接続されたセンサーからデータを転送し、
• イベントの送信（たとえば、温度上昇、ドアの開放、通信の喪失など）、
• 制御コマンドをアクチュエータに送信し、

システムが多数のオブジェクトで構成されている場合、および/または重要なタスクを実行する場合は、さらに次のことを行う必要があります。

• オブジェクトとの通信の存在を常に監視し、
• あなたの仕事に関する統計を収集し、
• コントローラの設定とソフトウェアを更新します（要求に応じて）。
• 不正アクセスから保護されます。州および大規模な民間企業の場合、システムは重要な情報インフラストラクチャ（CII）の操作に関する法律にも準拠する必要があります。特に、187-FZ、FSB、FSTECの要件、電気通信マス通信省の命令など。

専用サーバーなしの管理

いくつかのオブジェクトの場合、問題はSMSコマンドまたは呼び出しによるGSMネットワークの制御で簡単に解決されます。このアプローチは2010年代初頭に普及し、その長所と短所は、たとえばここで説明されています。最も深刻なシステムの場合、このアプローチは今日その関連性を失っています。





もう少し複雑なのは、WEBまたはコマンドライン（CLI）を介した専用IPを介したコントローラーの「手動」制御です。コントローラは、ネットワークに永続的に接続され、静的な「白」または「灰色」のIPアドレスを持っている必要があります。また、あなたが使用してスタティックドメイン名に結合して、動的IPを使用することができますダイナミックDNS技術または類似しました。これは、オブジェクトが少なく、信頼性に関する特別な要件がない場合にうまく機能します。



短所：

• , WEB () ;
• IP ;
• , NAT;
• IP . , GSM APN ;
• , «»;
• ().

簡単なデモンストレーション、複数のオブジェクトの制御には、IP、SMS、または電話による制御を使用するだけで十分です。



ここでは、ディスパッチャが同じコンピュータで実行されており、制御システムがインストールされている場合の状況は考慮していません。これは、次の項目の縮退したケースと見なすためです。

専用サーバー管理

残りのケースでは、コントローラー、ディスパッチャー、およびサードパーティシステムが接続するための専用IPを備えたサーバーが必要です。



コントローラーがサーバーの方向にのみデータを送信する場合（たとえば、水量計や最も単純なナビゲーションデバイス（トラッカー））、単方向接続で十分です。この場合、コントローラーはサーバーIPを知っているだけで済みます。



私たちのタスクでは、コントローラーソフトウェアを更新してコマンドを送信するために、双方向のデータ交換が必要です。このような交換を組織するには、次のことを行う必要があります。

• コントローラの主導でサーバーから設定またはコマンドを定期的に読み取る（コマンドへの迅速な応答が必要ない場合は許容されます）、または
• コントローラで静的IPまたはドメイン名を使用して、サーバーが独自にそれらに「到達」できるようにする、または
• , . , MQTT, EGTS ( ). IP. , .

実績のある信頼性の高いソリューションに基づく制御システムに関しては、SCADAが最初に覚えておくべきことです。そして、これは、生産の自動化や大規模なエネルギー施設に関しては完全に正当化されます。つまり、システムにさまざまなタイプのセンサーとアクチュエーターが多数含まれている場合。このようなシステムでは、オブジェクトごとに固有の機器の相互作用のためのニーモニック図とアルゴリズムの開発が必要です。これは、SCADAで非常によく考えられています。



（提案されたタスクのように）同じタイプのオブジェクトを監視および/または管理する必要がある場合、SCADAを使用すると、セットアップの複雑さ、標準オブジェクトの追加の面倒さ、およびサーバーパフォーマンスの要件の増加により、ソリューションが「重く」なりすぎる可能性があります。このタスクに最も適した、市販の専用ボックスシステムの1つを使用するのが最善です。例えば：

• ネットワーク機器の監視および管理システム-ネットワーク管理システム（SNMP、TR-069、CLI）;
• 熱、電気、ガス、水のための自動計量システム。簡潔にするために-ASKUE;
• オンボードシステム制御を備えたモバイルオブジェクトのナビゲーション追跡システム。
• 気候制御システム（換気、空調、暖房）-HVAC;
• スマートホーム/オフィス/ビルディングシステム;
• : , () , ;
• - , ..

これらのシステムは、多くの場合、互いの機能と重複しています。たとえば、ASKUEに基づいて屋外照明の制御を実装したり、「スマートハウス」に基づいて気候とアクセスを制御したりすることができます。 「生きている」システムの機能の拡張は進行中です。ボックス化された製品を顧客のソリューションに統合し、ボックス化されたソフトウェアのカスタム機能をサポートするための新しいAPIが登場しています。ボックス化された製品の大きな利点は、閉じた顧客回路で機能する疎外されたソリューションを受け取ったため、購入してサーバーに配置できることです。



独自のシステムを無料市場で販売する計画がある場合は、競合他社が今日の箱入りソフトウェアサプライヤーから明日成長する可能性があることを理解する必要があります。さらに、ボックスシステムの使用には、次のような追加のリスクが伴います。

• ライセンスの価格の上昇、
• システムに対する制御が弱い（ソースコードがない場合でも、維持するのが非常に難しい）、
• 多くのシステムはクラウドサービスとしてのみ使用でき、大規模なプロジェクトや政府のプロジェクトには受け入れられない場合があります。

IoTプラットフォームに基づく開発

ボックス化されたソフトウェアを使用できない場合は、人気のあるIoTプラットフォームの1つで開発することをお勧めします。このようなプラットフォームには、次の目的でIoTシステムに必要なユニバーサルモジュールが含まれています。

• IoTデバイスの登録と削除、
• IoTデバイスの安全な認証とそれらとの通信の維持、
• データ（さまざまなタスク用に最適化されたデータベース）の操作、
• ユーザーの登録とアクセス権の管理、
• 収集されたデータに基づく分析の形成、
• ユーザーへの通知の生成（SMS、電子メール、プッシュメッセージなど）、
• IoTデバイスから読み取った最新のデータを保存します。
• イベントに対してさまざまなアクションを実行し、
• データの視覚化など。

IoTプラットフォームのシステムアーキテクチャは、そのサイズに実質的に依存していません。負荷分散、データベースの「ブレーキ」および「重い」機能の排除に関連するすべてのタスクは、プラットフォームによって実行されます。さらに、アプリケーションのサーバー側は、「キューブ」（マイクロサービス）からすばやく組み立てられます。プログラマーの作業の支払いに直接依存する、市場投入までの時間とソリューションのコストの両方が削減されます。



IoTプラットフォーム上のシステムは、最小限の時間で開発できます。そのアーキテクチャは、サイズが大きくなってもあまり変わりません。



クラウドベースのIoTプラットフォームで開発することの長所：

• . AWS . . .
• , , , MQTT- – . , .
• IoT . ( ) ( IoT ).
• .
• 主要な開発タスクは外部委託できます。将来的には、このソリューションは、通常の場合のように、元のシステムの開発者だけでなくサポートできるようになります。結局のところ、IoTプラットフォームには強力な技術サポートがあり、十分に文書化されており、それらを使用できる開発者の数は着実に増えています。

短所：

• IoTプラットフォームのコンポーネントは、所有者の施設でのみ動作し、まれに、顧客のデータセンターで機能する完全に疎外可能なシステムを作成します。
• 大規模なプロジェクトにIoTプラットフォームを使用するコストは、データセンターで仮想マシンをレンタルするコストよりも高くなる可能性があります。
• あるIoTプラットフォームから別のプラットフォームへの移行には、適切な量のコードの変更が含まれます。現在、APIの標準化に向かう​​傾向があります。
• すべてのIoTプラットフォームがロシア内のデータセンターに導入されているわけではないため、政府の顧客の利益のためにそれらを使用することは不可能です。

完全に独自の開発

以前のソリューションの欠点が重大な場合は、独自のソリューションを開発する必要があります。そして、計画がどれほど優れていても、システムの最初のバージョンは曲がっています。



独自のソリューションは、ThingsBoard、OpenSCADA、MajorDoMo、Home Assistant、iobroker、Nokiaglialなどのオープンソースシステムに基づいて実装されることがよくあります。小規模なプロジェクトの場合、次の理由で「重すぎる」可能性があります。

• 長い開発時間とそれに対応する財務コスト。通常、カウントは人年単位です。
• オブジェクトの数が増えると、遅いデータベース、コレクター、レポートジェネレーターなどの形でボトルネックが発生します。その解決には、アーキテクチャを変更し、バランサーと重複リソースで補足する必要があります。
• 継続的な管理と技術サポートのコスト。

同時に：

政府の命令、野心的な計画と多額の予算を伴うプロジェクト、または独立性とセキュリティが重要な場合、独自の開発が正当化されます。



簡単なデモンストレーション（MVP）が必要な場合は、IoTプラットフォームまたはボックス化されたソフトウェアで実行でき、独自の大規模なソリューションを並行して開発しながら、実績のあるアプローチを採用します。

結論

さまざまなシステムの分析に基づいて、次の制御システム選択アルゴリズムを提案します。







複数のオブジェクトのデモンストレーションおよび小規模なIoTプロジェクトの場合、IP、SMS、またはGSM呼び出しを直接制御できます。それ以外の場合は、トップレベルのシステムが必要です。 SCADAの使用は、産業用自動化および大規模なエネルギー施設で正当化されます。リソースアカウンティング、ネットワーク機器管理、追跡、セキュリティ、「スマートホーム」など。必要な専門分野の箱入りソリューションを使用すると便利です。 IoTプラットフォームでシステムを開発することはより困難ですが、より多くの視点と柔軟性を提供します。外国のIoTプラットフォームでのソリューションは、ロシアの規模とアプリケーション分野で深刻に制限されています。最も難しいのは完全に自分の開発です。そして、それは政府の命令と最も野心的なプロジェクトに対してのみ正当化されます。同時に、迅速なデモンストレーションとベストプラクティスのコピーのために、独自の開発と並行して、IoTプラットフォームでドラフトデザインを作成すると便利です。



最後に、小さな予測を共有したいと思います。

• クラウドIoTプラットフォームでは、「スマートホーム」、ASKUE、NMS、ACSなどの事前構成済みテンプレートが表示されるのを待つ価値があります。これにより、IoTプラットフォームの使用がさらに簡素化され、さらに多くの視聴者を引き付けることができます。
• SCADAおよびその他のボックス化されたソリューションの従来の開発者は、IoTプラットフォームで実績のある外部開発者向けにさらに多くのツールを提供します。クローズドボックスソリューションは、市場の競争に耐える可能性は低いです。
• パブリックおよび大規模なプライベート顧客向けの国内IoTプラットフォームは、さらに積極的に開発されます。
• さまざまなIoTプラットフォームのAPIは、時間の経過とともにより類似するようになります。このため、あるIoTプラットフォームから別のIoTプラットフォームへの移行が簡素化されます。

次のより技術的な投稿では、AWSプラットフォームとGICコントローラー上の通信システムを監視するためのプロジェクトについて説明します。



重要なことを見逃した場合は、必ずコメントに書き込んでください。私たちのブログの目標の1つは、建設的なフィードバックを得ることです。