インターネットの開発は、すぐに「ちょうどそこに」あるレベルに達します。 ますます、ネットワークにどのように接続されているか、通信事業者が誰であるか、さらには接続がどのように技術的に編成されているかを考える必要がなくなりました。 ワイヤレスネットワークの普及とIPv6の段階的な普及により、数千の単純なデバイスとセンサーが相互に継続的に通信し、データを「クラウド」に送信できるようになりました。 インフラストラクチャの急速な複雑化により、「マシンツーマシン」（マシンツーマシン、M2M）という用語が、より新しい用語「モノのインターネット」（モノのインターネット、IoT）に置き換えられました。







分散インテリジェンスのようなものを形成するために、モノのインターネットのデバイスには、集中管理、収集されたデータを構成、保存、解釈するためのシステムまたはサービスが必要です。 デバイスクラウドインフラストラクチャの中心的な「頭脳」である制御システムは、接続されたデバイスのマシンナレッジベースを補充し、ソフトウェアを更新します。







オペレーターは、デバイスグループと期間ごとに集計されたデータを調査し、さまざまなセクションで視覚化します。 より詳細な分析のために、同じデータがBusiness Intelligenceクラスのさまざまなシステムに転送されます。 個人用デバイス（フィットネストラッカーなど）についても、収集されたデータの使用と使用に関する統計の匿名分析の可能性を否定して、デバイスとサービスをさらに改善するクラウドサービスオペレーターはほとんどありません。



モノのインターネット用のデバイスの開発は常に簡素化され、安価になり、中小企業がこの市場に参入できるようになっています。 管理システムを作成する必要性を認識し、多くの企業はその開発の複雑さを過小評価しており、産業用サーバーテクノロジー（フォールトトレランスのためのクラスタリングやマルチサーバー分散アーキテクチャなど）を使用する必要性を考慮していません。 多くの場合、開発はそれ自体で、「社内」で開始されます。 市場でのIoTデバイスの成功は、ユーザー数の急速な増加につながり、サービスのスケーリングとそのパフォーマンスの確保に関する解決不可能な問題を迅速に作成します。



さらなる問題を恐れて、サーバーソフトウェア開発部門を迅速に作成できないため、IoTオペレーターは多くの場合、デバイス自体に集中して中央システムの開発を外部委託します。 しかし、これは問題を解決しません-サードパーティの開発者は、同じ方法でシステムをゼロから作成し始め、基盤に深刻な技術を導入するのに十分なリソースと時間がありません。



プラットフォームAggreGateは2002年に誕生しました。 その間、私たちはSerial-over-IPコンバーターの生産に積極的に携わっており、ファイアウォールやNATの背後に隠れて直接通信できないコンバーター間でデータを送信する中央サーバーが必要でした。 LinkServerと呼ばれる製品の最初のバージョンはC ++で記述されており、サービスとしてのみ利用可能です。 LinkServerは、処理せずにデータストリームをそれ自体にポンプで送ります。



少し後に、当社のコンバーターは自由にプログラム可能なコントローラーに変わりました。 彼らは通過するデータを「理解」し始め、中央サーバーに同じことを教えるという論理的な欲求が生じました。 ほぼ同時に、あらゆる産業向けの監視およびデバイス管理システムの作成作業の90％が「自転車の発明」であり、特定のビジネスに固有のタスクに費やす労力はごくわずかであることがわかりました。



2004年、システムはJavaに移植され、その瞬間から「デバイス管理フレームワーク」として開発されました。 数年間、私たちはほとんど盲目的に動いて、結果として得たいものを完全に理解していませんでした。 幸いなことに、特定の業界に「頭を抱えて」離れることなく、システムの普遍性を維持するために、モノの顧客を避けることができました。



現在、このプラットフォームは、リモート監視とメンテナンス、ITインフラストラクチャ管理とネットワーク監視、SCADAとプロセス自動化、物理的アクセス制御、ビル自動化、車両管理、自動販売機および支払い機管理、センサーネットワーク監視、カウントなど、さまざまな分野で使用されています訪問者と車、イベントとインシデントの集中管理、広告と情報パネルの管理、モバイルデバイス管理。

プラットフォームの主な目的

比ur的に言えば、AggreGateは、デバイスクラウドへのインターフェイスをすばやく作成するためのレゴコンストラクターです。 IoTソリューションのアーキテクトが機器とビジネスロジックに集中できるようにして、インフラストラクチャの問題を解決します。

• 信頼性の低いセルラーおよび衛星チャネルを介して作業する場合のサーバーとデバイス間の通信の維持
• 物理的な意味に関係なく、これらのデバイスでの作業の統合
• さまざまな種類のデータベース（リレーショナル、リング、NoSQL）に収集された大量のイベントと履歴データのストレージ
• ソースデータ分析とイベント相関の複雑なチェーンの視覚的構築
• 複数のデバイスからのデータを結合し、インフラストラクチャ全体のKPIを計算するプロセスのモデリング
• プログラミングなしで、既成のキューブからオペレーターとシステムエンジニアのインターフェイスを迅速に構築
• 既製のユニバーサルコネクタ（SQL、HTTP / HTTPS、SOAP、CORBA、SNMPなど）を使用した統合スクリプトの実装

システム統合

このプラットフォームは普遍的であるため、さまざまな監視および制御システムの統合に役立ちます。 これにより、不必要な統合ポイントが回避され、統合シナリオの数が削減されます。 たとえば、統合監視システムには、インシデント（アラーム）を配信するためのサービスデスク/ ITSM /メンテナンス管理システムとの単一の統合ポイントがあり、在庫/資産管理システムとの単一の統合により、利用可能な物理資産とビジネスサービスへの影響の程度に関する情報を取得します。



このような場合、ロールアクセスを編成することで、システムを使用するための個々のシナリオとオペレーターインターフェイスの一意性をさまざまな部門に提供できます。

プラットフォームアーキテクチャ

プラットフォームの主なコンポーネントは次のとおりです。

• サーバーは、デバイス、データストレージ、およびそれらの自動処理との通信を提供するJavaアプリケーションです。 サーバーをクラスター化して、高可用性を提供し、分散インストールで相互のピアツーピア関係を維持できます。 AggreGateサーバーは、Webインターフェースサポートを提供する組み込みWebサーバーを管理します。
• 単一のコンソールは、管理者モード、システムエンジニアモード、またはオペレータモードで1つまたは複数のサーバーとの同時作業を提供するクロスプラットフォームのデスクトップクライアントソフトウェアです。
• エージェント -サーバーとの通信を提供し、デバイス設定を統合し、それを使用して操作を実行し、イベントを非同期的に送信するために、デバイスのIoTファームウェアに埋め込むことができるライブラリ。 多くのライブラリー実装（Java、.NET、C / C ++、Android Javaなど）があります。標準または独自のプロトコルを使用してサーバーとの通信が実行される場合、エージェント実装は必要ありません。後者の場合、サーバー用に個別のデバイスドライバーが開発されます。 エージェントは、個別のハードウェアデバイス（ゲートウェイ）として構成することもできます。
• 他のすべてのコンポーネントの機能を拡張し、複雑な統合シナリオを実装するためのオープンソースAPI

サーバーは、デバイスからのデータの読み取りと変更の記録を管理します。このプロセスは双方向同期と呼ばれます。 サーバー側では、いわゆるデバイススナップショットが作成されます。これには、最新のデバイスメトリックのコピーと、オペレーターおよびシステムモジュールによって行われた変更が含まれ、通信不足のためデバイスに書き込まれません。 構成の変更は、最初の機会の原則に従ってデバイスに配信され、デバイスの構成が同時にオンラインになるのを待たずに、グループの変更をデバイス構成に加えることができます。



サーバーは、静的な「ホワイト」IPアドレスを持たないデバイスの着信接続の受信と保守も提供します。 この機能は、IoTプラットフォームにとって重要です。



デバイスデータとイベントは、 単一のデータモデルの一部になります。 このモデル内では、各デバイスは、コンテキストの階層構造の一部であるいわゆるコンテキストによって表されます。 各コンテキストには、変数（プロパティ、設定、属性）、関数（メソッド、操作）、イベント（アラート）の3種類の形式化されたデータ要素が含まれます。 コンテキストには、使用可能なすべての要素を記述するメタデータも含まれます。 したがって、すべてのデータとコンテキストメタデータは、それ自体に完全に集中しています。 この技術は、 デバイスの正規化と呼ばれます 。 さまざまなタイプのデバイスの正規化されたプレゼンテーションは、デバイスドライバーとエージェントによって作成されます。



オブジェクト指向のプログラミングでは、オブジェクト、プロパティ、メソッド、イベントも提供されます。 プロパティはデバイスの内部変数、メソッドは実行可能な操作、イベントはデバイスが内部データまたは外部環境の変更についてサーバーに通知する方法です。



ほぼすべてのデバイスは、プロパティ、メソッド、およびイベントのセットで記述できます。 たとえば、リモート制御の水タンクには、「水位」プロパティと、「バルブを開く」および「バルブを閉じる」という方法を使用して液体の流れを制御できます。 スマートタンクは、「ほぼ空」、「ほぼ満杯」、「オーバーフロー」などのアラートを生成することもできます。 Javaで100以上の通信プロトコルドライバーを開発し、正規化のアイデアがその価値を証明しました。 さらに、多くの最新の「ユニバーサル」プロトコル（OPC UA、JMX、WMIなど）は、非常に類似したデータモデルを使用しています。



すべてのサーバーコンテキストは、コンテキストツリーと呼ばれる階層構造に配置されます。 コンテキストはさまざまなオブジェクト（デバイス、ユーザー、レポート、アラームなど）に対応するという事実にもかかわらず、それらはすべて共通のインターフェースを持ち、サーバーのコンテキストツリー内で相互作用できるため、高度な柔軟性を提供します。 同じ原則により、異なるサーバーが分散インストールで相互に対話できるようになります。



接続された各デバイスにより、オペレーターは直接構成（デバイス構成の読み取りと編集）、直接制御（手動でデバイスにさまざまな操作を強制的に実行）、および直接監視（デバイスからのイベントを擬似リアルタイムモードで表示）を実行できます。







デバイスメトリックのイベントと変更は、サーバーストレージに保存されます。 システムのタスクに応じて、これはさまざまなタイプのストレージになります。 たとえば、Raspberry Pi内で実行されているマイクロサーバーの場合、最も単純なファイルストレージが使用され、大規模な分散インストールの中央サーバーは、Apache Cassandra NoSQLデータベースのクラスターを使用できます。



ただし、ほとんどの場合、通常のリレーショナルデータベースがストレージとして使用されます。 ORMレイヤー（Hibernate）を使用すると、MySQL、Oracle、Microsoft SQL Server、PostgreSQL、その他のDBMSとの互換性が提供されます。



デバイスから受信したデータとイベントは、「アクティブな」サーバーオブジェクトのライフサイクルに影響を与え、外部環境の変化に対応できるようにします。 アクティブなオブジェクトは次のとおりです。

• オブジェクトの特定の複雑な状態またはイベントの特定のチェーンを新しいタイプのイベントに変換するアラーム-インシデント
• ビジネスルールがソースイベントと値をユーザー定義のイベントタイプと値に変換できるようにするモデル
• 一時的なサーバーのシャットダウンの場合でも、スケジュールされたタスクとその実行を保証するスケジューラー
• センサーおよびその他の種類のオブジェクト

アクティブオブジェクトは、新しいタイプの変数、関数、イベントを単一のデータモデルに追加し、ユーザー変数とイベントへの変更をリポジトリに送信し、デバイスやその他のオブジェクトの自動操作をトリガーできます。



データ入力フォーム、テーブル、動的マップ、グラフ、ニーモニック図を作成するためのウィジェットがあります。 これらは、インフラストラクチャ全体の状態と集約されたKPIに基づくグローバル、およびインフラストラクチャの1つのデバイスまたはコンポーネントのステータスを示す「オブジェクトベース」の両方のダッシュボードに結合できます。







ウィジェットとレポートテンプレートは、プラットフォームの一部であり、そのエコシステムに密接に統合されている専用のビジュアルエディターで編集されます。 ウィジェットエディターを使用すると、多数の入れ子になったコンテナーパネルで構成される複雑なインターフェイスを構築し、そこに視覚的なコンポーネントを配置できます。 SCADAシステムで使用されるエディターに一般的な絶対配置に加えて、HTMLページ内のテーブルの編集に遭遇した人なら誰でも知っているグリッドレイアウトを使用できます。 グリッドレイアウトを使用すると、あらゆる画面サイズに合わせて適切にスケーラブルなデータ入力フォームとテーブルを作成できます。



その結果、データを視覚化するツールを使用して視覚的に開発された1行目または2行目のオペレーターインターフェイスは、ウィジェット、フォーム、テーブル、チャート、レポート、ニーモニック図、およびそれらの間のナビゲーションを備えたダッシュボードで構成されます。







インターフェイスエディターを使用すると、ラベル、テキストフィールド、ボタン、チェックボックス、スライダーとスピナー、リスト、日付/時刻セレクター、スケール、ポインターなど、多数の既製のコンポーネントを使用できます。 ツリー、ビデオウィンドウ、動的ベクトルSVG画像、Googleマップ/ Bing / Yandex / OpenStreetMapに基づく地理的マップなど、より複雑なコンポーネントがあります。 サポートされているチャートタイプのリストには、古典的なチャートタイプのほか、さまざまな統計チャート、ガントチャート、極座標チャートが含まれます。



エディターで描画されるすべてのウィジェットは、Javaサポートのないブラウザーを含む、Webバージョンのインターフェースで動作します。 モバイルデバイスで。 HTML5およびJavaScriptのサポートのみが必要です。



サーバーオブジェクト（デバイス、モデル、アラーム）とユーザーインターフェイスコンポーネントのプロパティは、データを取得するタイミングと場所、データの処理方法、結果の配置場所を決定するバインディングを使用して相互に接続されます。 データを処理するとき、バインディングは式言語とクエリ言語を使用します。



式ベースのバインディングは、Microsoft Excelの式に似ています。 数式は複数のセルからデータを取得し、それらに数学演算またはさまざまなデータ処理関数を適用し、結果を現在のセルに入れます。 式は、データを取得する場所とデータに適用する必要がある変換を記述する式でもあります。



クエリ言語は通常のSQLに非常に似ています。 また、さまざまなテーブルのデータを1つに結合し、フィルタリング、並べ替え、グループ化などを適用できます。 組み込みクエリ言語と従来のSQLの違いは、通常のテーブルではなく、データソースが単一のモデルのさまざまなデータからオンザフライで生成される仮想テーブルであることです。 また、すべてのクエリは、それを実行するオペレータまたはシステムオブジェクトのアクセス権を自動的に考慮します。これは、サーバーデータベースへの直接SQLクエリと比較して有利です。



最も複雑なデータ処理タスクを解決するために、Javaスクリプトまたは別個のプラグインを作成できます。 ただし、パートナーのいずれかによって作成されたデータ処理用の各スクリプトは、私たちにとって驚くべき鐘です-古典的な開発が必要な場合や、通常の環境（EclipseやIdeaなど）以外でもプラットフォームが必要なのはなぜですか



また、分散アーキテクチャの技術的なデバイスについても話したいと思います。 この概念のフレームワーク内で、サーバー間のピアツーピア関係は、1つのサーバー（「プロバイダー」）がその単一データモデルの一部を別のサーバー（「消費者」）にアタッチするように設定されます。 これにより、コンシューマサーバーオブジェクトは、独自のプロバイダーサーバーオブジェクトと同等にやり取りできます。 1つのサーバーの接続数に制限はなく、隣接サーバーとの関係で同時にサプライヤーおよびコンシューマーとして機能できます。







分散アーキテクチャにより、大規模システムの多くの問題を解決できます。

• 水平システムのスケーリング
• ローカル監視サーバーとリモートサイトでの中間データストレージのインストールによる分散監視
• 垂直スケーリング、複数の論理レベルでのサーバー間の機能の分散

この投稿は、Habréでのデビューです。 次の記事では、プラットフォームの内部構造、それに基づいた独自のソリューション、および「重いPCソフトウェア」がモノのインターネットの組み込みシステムやデバイスにどのように浸透するかについての理解について詳しく説明する予定です。



PSモノのインターネット用のサーバーソフトウェアを開発している場合は、以下の質問に答えてください。