分散アーキテクチャの静的モデル。マネージド分散アーキテクチャストレージレイヤー

L-Netの再構成可能なマルチパイプラインコンピューティング環境に基づく

制御システムの分野における緊急の課題の1つは、分散型フォールトトレラント制御システム用のソフトウェアの開発です。現在この分野に存在するソリューションは独自のものであり、その結果、高価であり、常に効果的であるとは限りません。

これらのソリューションは、冗長ベース、技術、およびソフトウェアのリソースを効率的に使用することを提供しません。これは、このようなソリューションのフォールトトレランスとスケーラビリティの両方に悪影響を及ぼします。ネットワークアーキテクチャに違反した場合、情報処理プロセスとデータストリームの送信（制御と情報の両方）の両方を動的に再構成する可能性はありません。特定のマイクロコントローラーの使用、DCS / SCADAの使用は、システムの開発とサポート、それらの機能の拡張を複雑にします。

分散制御システムアーキテクチャ

分散制御システム（DCS）の一般化された典型的なアーキテクチャには、3つの階層的に関連するレベルが含まれます。オペレーターレベル、制御レベル、およびI / Oレベルです（図1を参照）。

オペレーターレベルの主なタスクは、システム全体の機能の構成と制御を確実にするためのヒューマンマシンインターフェイス（HMI）を提供することです。制御レベルは、センサーからのデータの受信と処理、オペレーターレベルへのデータの送信、およびアクチュエーターでの制御アクションの生成を担当します。 I / Oレベルは、制御対象に直接接続されたセンサーとアクチュエーターを表します。

DCSの一般化されたアーキテクチャのフレームワーク内でのソフトウェアのタスクは、オペレータレベルの機能と、システムの制御レベルとの接続を保証することです。したがって、ソフトウェアの設計とハードウェアとの相互作用の問題の解決における基本的なレベルは、オペレーターのレベルです。ソフトウェアは、ハードウェアの内部アーキテクチャから可能な限り独立した状態で、システムの利用可能なハードウェアリソースを最大限に活用する必要があります。

ハードウェアは、システム内のノード間でコンピューティングリソース、メモリ、および通信メディアを提供します。システムの一般的なアーキテクチャを設計する場合、特定の実装でシステムに接続されるI / Oレベルの特定のノードは考慮されないため、一般的なアーキテクチャではオペレータレベルと制御レベルが考慮されます。ハードウェアは広く普及しており、最新の標準に準拠しており、アーキテクチャの実装に必要なすべてのプロパティと機能を備えている必要があります。

DCS要件

DCSの要件は、システム全体だけでなく、ハードウェアコンポーネントとソフトウェアコンポーネントにも個別に適用されます。これらのコンポーネントに対するこれらの要件を満たすための特定のアプローチは根本的に異なる可能性があるためです。 DCSは、まず第一に、フォールトトレラントである必要があります。フォールトトレランスを向上させる最も簡単な方法は、機能ユニットまたはその集合体の冗長性（複製）です。 2番目に重要なプロパティはスケーラビリティです。スケーラビリティは、ソフトウェアでの特別なアルゴリズムの実装と、新しいノードまたはそのコンポーネントパーツを交換および追加するハードウェア機能に基づいています。同時に、システムは、その操作、新しいノードまたはモジュールの開発、およびそのアーキテクチャーの変更のために単純なままである必要があります。

DCSアーキテクチャの概要

DCSアーキテクチャのレビューでは、Siemens SIMATIC PCS 7 DCSが市場で最も需要の高いものの1つとして選択され、RTSS3がQNXRTOSに基づいて実装されたDCSとして選択されました。

シーメンスSIMATICPCS 7

システムアーキテクチャには、一般的なDCSアーキテクチャのすべてのプロパティがあります。オペレーターステーションは、WindowsOSとHMIを提供するSiemensWinCCパッケージを備えたx86プロセッサアーキテクチャに基づくコンピュータです。データベースを備えたサーバーがあります。オペレーターステーション、エンジニアリングステーション、およびサーバーは、イーサネットベースのローカルエリアネットワークによってリンクされています。オペレータレベルは、冗長産業用イーサネットネットワークのコントロールプレーンにリンクされています。制御レベルには、機能の重複による冗長性の可能性があるプログラマブルロジックコントローラー（PLC）があります。外部システムやネットワークに接続して、システムへのリモートアクセスを整理することができます。

RTSS3

このアーキテクチャも同様に、DCSの一般化された構造のレイヤーで構成されています。オペレーターステーションは、SIMATIC DCSと同じハードウェアプラットフォームに基づいていますが、WindowsとLinuxの両方のオペレーティングシステムで操作できます。エンジニアリングステーションは、オペレーターステーションと組み合わされています。このシステムは、統合されたアプリケーション開発環境を提供します。イーサネットは、TCP / IPプロトコルスタックを使用して、キャリア層内のノードとオペレータレベル自体をコントロールプレーンに接続します。制御レベルでは、独自のデータベースを備えたQNX OSを実行している産業用コンピューターがあり、ノードの機能を複製することで冗長性を実現できます。

説明されているシステムのデメリット

上記のシステムは、オペレーターレベルとコントロールプレーンに異なるハードウェア/ソフトウェアプラットフォームを使用します。オペレーターレベル内では、1つのプロセッサアーキテクチャのみを使用でき、制御レベルを構成および開発するには、特別なエンジニアリングステーションが必要です。これらのDCSは、冗長ハードウェアの不合理な使用であるフォールトトレランスを向上させる方法として、冗長ノードの機能を複製したハードウェア冗長性のみを提供します。

L-Netシステムの特徴と機能

L-Netシステムを開発するときのタスクは、次の特性を持つ制御システムを作成することでした。

ホスト障害またはネットワークトポロジの中断が発生した場合に最小限の損失で完全に回復する動的再構成。
利用可能な効率的なネットワークノード間でのタスクの効率的な分散。
データ伝送ストリームの動的再構成によるノード間の通信チャネルの複製。
システムの使いやすさとスケーラビリティ。
制御システムおよび組み込みシステムを構築するために設計された任意のハードウェアプラットフォームでのシステムの移植性とパフォーマンス。

上記の特性を備えたシステムを構築するには、主に制御システムと組み込みシステムの作成を目的としたオペレーティングシステムが必要です。既存のオペレーティングシステムを分析したところ、最適なオペレーティングシステムはQNX 6（Neutrino）であり、非常に効率的なリソース割り当てとネットワーク機能を備えています。幅広いネットワーク機能は、Qnetネットワークプロトコルによって提供されます。通信チャネルの信頼性と動的負荷分散の問題は解決しますが、システム全体のフォールトトレランスの問題は解決しません。その結果、分散型の再構成可能なマルチパイプラインコンピューティング環境に基づいた革新的な制御システムが開発されました。開発したシステムは、入出力ブロック、汎用スイッチブロック、再構成可能コンピューティング環境（RCS）ブロックの3つの論理ブロックを含むピアツーピアアーキテクチャを備えています（図2を参照）。

このアーキテクチャの主な利点は次のとおりです。

ピアツーピアタイプ
地方分権化
スケーラビリティ
空間分布

このアーキテクチャの機能機能：

パイプラインデータ処理
ハードウェアの冗長性
負荷分散
オンザフライの再構成

アーキテクチャの最初のレベルには、入出力（I / O）ユニットがあります。これには、入出力ノード、入出力ノードのスイッチ、入出力インターフェイス、センサー、およびアクチュエーターが含まれます。ユニットは、ローカルセンサーからのデータと制御システムの他のレベルから受信したデータに基づいて制御アクションを生成するための基本的なメカニズムを担当します。割り当てられたタスクは、現在の相対的なパフォーマンスに基づいて、またはオペレーターが手動で、正常なI / Oノードに分散されます。センサーとアクチュエーターは、バスを介してブロック内のすべてのI / Oノードに接続されます。これにより、任意のノードが任意のセンサーに問い合わせたり、任意のアクチュエーターに効果を生成したりできます。 I / Oノードスイッチは、すべてのI / Oノード間の通信を提供して、ノードとシステムアーキテクチャの他のレベルとの間でデータを交換し、制御および情報データを取得します。適切なハードウェア機能を使用すると、ノードは相互に直接通信し、システムの他のレベルのノードやスイッチと通信します。これにより、ネットワークの応答時間が短縮されます。 I / Oブロックの現在の動作モードでのノードとノードの特定の負荷との間の直接通信により、制御システム（DCS）の外部計算能力に頼ることなく、このブロックの動作に必要なブロックでパイプライン計算を整理できます。これにより、障害時にI / Oユニットの冗長ノードに提供されている空きリソースを有効に活用できます。

アーキテクチャの第2レベルにある汎用スイッチのブロックは、入出力ブロックとDCSおよび外部システムとの間の通信回線を編成します。各スイッチは、制御システム全体でさまざまなボンドとスイッチを相互接続できます。通信回線の数は、ブロックに含まれるノードとスイッチのハードウェア機能によって決まります。 Qnetネットワークではデータフローを動的に分散できるため、このブロックのスケーリングは新しいデバイスを接続するだけで実行され、構成は不要です。スイッチの1つに障害が発生しても、ノード間のデータ転送は中断されません。もう一方のスイッチは、ノード間で同様の接続を提供するか、ノードが直接関連しています。同時に、障害が発生したスイッチをバックアップするために必要な十分なネットワーク帯域幅に注意する必要があります。

アーキテクチャの第3レベルにある再構成可能なコンピュータネットワーク（RCN）ブロックは、情報処理、意思決定、認識などの複雑な問題を解決するためのハイコンピューティングパワー管理システムを提供します。このブロックは、制御システム全体の初期化を担当します。スイッチとノードの操作性のチェック、ネットワークの整合性、システム全体のネットワークグラフの作成、入出力ブロックの操作の開始パラメーターの設定です。このブロックのノードは、独自のデータとI / Oブロックからのデータの両方をアーカイブするために提供されます。このブロックの各ノードは、システムの動作を監視し、このノードとシステムのすべてのノードの両方の作業プログラムを調整し、オンデマンドで再構成を実行するように設計されたオペレーターのマシンの役割を果たすことができます。

負荷分散

L-Netシステムの主なタスクの1つは、ネットワークノードでの計算負荷の分散です。この問題の解決策は、計算パイプラインの構築に基づいています。計算パイプラインを構築するために、タスクグラフが事前に構築されます。これは、ソースから宛先にデータストリームを交換するためのスキームです。センサーはソースとして機能し、アクチュエーターは受信者として機能します。計算パイプライン自体は、システムの計算リソースとその現在の状態に対する問題の要件を考慮に入れて、タスクグラフ（図3を参照）をコンピューターネットワークグラフ（図4を参照）にマッピングしたものです。

解決策は、現在のハードウェア、その状態、および利用可能なデータソースに関する包括的な情報を受信者に提供するサービスを使用することです。このサービスは、ネットワークグラフとタスクを処理します。その結果、計算のパイプライン化によりパフォーマンスが向上し、システムで使用可能なすべての計算リソースの合理的な使用が整理されます。

フォールトトレランス

このようなシステムの機能の主な問題は、このコンベヤーのいずれかのノードに障害が発生した場合、またはノード間のデータ転送に違反した場合に、計算パイプラインが完全に中断することです。 Qnetプロトコルの基本的な手段は、アーキテクチャによって提供されるバックアップ回線が原因でノードが部分的に違反した場合に、ノード間の接続を復元することを実現します。 L-Netシステムは、コンピューティングパイプラインを動的に再構成することにより、コンピューティングシステムのホストに完全な障害が発生した場合に、操作性を復元するという問題を解決します。作業リソースを使用して不良ブロックを置き換えます。システムは、障害の事実に対する応答時間、回復時間、および使用済みハードウェアリソースが異なる、回復（再構成）の3つのシナリオを提供します。障害時、パッシブレディネス、アクティブレディネスです。

失敗時の再構成-障害が検出された後、使用可能なハードウェアの検索が実行され、タスクグラフに含まれます。
パッシブレディネスによる再構成-冗長ハードウェアが事前に決定され、ノードでのタスクグラフの頂点の実装を保証するプロセスが開始され、接続が確立されますが、メインノードに障害が発生しない限り、プロセスはデータを処理しません。
アクティブな準備ができた再構成-タスクグラフの上部は複数のノードに実装されており、これらのノードは並行してデータ処理を実行し、結果を送信します。

その結果、システムは、ソフトウェアレベルとハードウェアレベルの両方で障害に柔軟に対応し、ネットワーク、計算パイプライン、およびノードの実装に関係なく、作業を中断したりパフォーマンスを低下させたりすることなくノードの構成を変更する機能を提供します。

結論

開発されたL-Netシステムは、既存のアナログとは対照的に、DCSノードの幅広いハードウェア特性と完全なソフトウェア互換性の使用を前提としています。ノードが1つのオペレーティングシステム（QNX Neutrino）の制御下で動作する場合、さまざまなインターフェイスと周辺機器を備えたさまざまなプロセッサアーキテクチャ（x86、ARM、MIPSなど）でノードを構築できます。ノードの実装は、デスクトップ、産業用PC、ウェアラブルPC、およびシングルボードコンピューターの形で可能です。開発されたDCSのソフトウェアコンプレックスのすべてのコンポーネントは、QNX OSを備えたノードのいずれかで起動できますが、異なるオペレーティングシステムのノードを使用することは引き続き可能です。このアプローチにより、各ノードを使用して、オペレーターレベルとコントロールレベルの両方のタスクを解決できます。その結果、一般化されたDCSアーキテクチャと、このアーキテクチャをベースとして使用するシステムに固有のレベルの厳密な階層がなくても、ピア間の相互作用の柔軟なシステムがあります。ピアツーピアネットワーキングは、展開、運用、スケーリング、およびシステムデバッグを簡素化します。

開発したシステムの冗長ハードウェアの計算能力を実現するために、QnetネットワークプロトコルとL-Netネットワークソフトウェアに基づいた動的構成および再構成アルゴリズムが提案されています。動的構成アルゴリズムは、タスクをパイプライン化して並列化し、ノード間のデータ伝送チャネルの負荷を動的に分散することにより、すべてのノードに計算負荷を分散することに基づいています。システム再構成アルゴリズムは、システムに割り当てられた使用可能なハードウェア、優先順位、およびタスクに応じて、障害が発生した場合に操作性を復元するための3つのシナリオの存在を前提としています。障害時、パッシブ準備（リソース割り当て）、アクティブ準備（リソース使用）です。。動的構成および再構成アルゴリズムは、システムのハードウェア予約を使用してパフォーマンスと信頼性を向上させます。

システムの重要な利点は、システムで使用されるハードウェアとソフトウェアの両方のテクノロジーの最大の透過性です。これにより、システムの技術サポートとシステムの新しいモジュールの開発を大幅に簡素化できます。

出力

開発されたアーキテクチャソリューションは、幅広いハードウェアの使用の可能性、動的構成アルゴリズムの実装、およびシステムリソースの合理的な使用により、信頼性、パフォーマンス、コスト、スケーラビリティ、シンプルさなどの分散制御システムの指標を改善することを可能にします。

http://kazanets.narod.ru/DCSIntro.htm。
http://kazanets.narod.ru/PCS7Overview.htm。
http://www.rts.ua/rus/news/678/0/409。
Zyl S. QNX Momentics：アプリケーションの基本。 -SPb：BHV-ピーターズバーグ、2005年。
Krten R. QNXNeutrinoの紹介。リアルタイムアプリケーションを開発するためのガイド。 -SPb：BHV-ピーターズバーグ、2011年。

キーワード：分散制御システム、制御システムの情報サポート、分散再構成可能システム。

再構成可能なマルチパイプラインコンピューティング環境に基づく分散制御システムのアーキテクチャL-Net

セルゲイ・ユウ。国立研究大学「高等経済学部」の助教授、ポトムスキー。

ニキータ・A・ポロイコ、国立研究大学「高等経済学部」の5年生。研究助手。プログラマー。トレーニングの分野：「技術システムの制御と情報学」。

概要。この記事は、再構成可能なマルチパイプラインコンピューティング環境に基づく分散制御システムに焦点を当てています。システムのアーキテクチャが示されています。また、システムの基本的な特性と機能特性も示されています。この記事では、オペレーティングシステムを選択する理由を説明しています。既存の同様の開発と比較したシステムの基本的な利点は、記事に示されています。

キーワード：分散制御システム、システムソフトウェアサポート、分散再構成可能。

と接触している

有名なコンピューター科学者であるE.タネンバウムによれば、一般的に受け入れられていると同時に、分散システムの厳密な定義はありません。一部のウィットは、分散型はそのようなものであると主張していますコンピューティングシステム、ユーザーがこれまで疑うことさえなかったコンピューターの故障が、すべての作業の終了につながる。残念ながら、分散コンピューティングシステムの大部分はこの定義を満たしていますが、正式には、固有の脆弱性のあるシステムのみを指します（ 単一障害点).

多くの場合、分散システムを定義するときは、その機能を複数のコンピューターに分割することに重点が置かれます。このアプローチでは、すべてが配布されますコンピューティングシステムデータ処理が2台以上のコンピューターに分割されている場合。 E. Tanenbaumの定義に基づいて、やや狭く分散されたシステムは、通信チャネルによって接続された独立したコンピューターのセットとして定義できます。これは、一部のソフトウェアのユーザーの観点からは、単一の全体のように見えます。

分散システムを定義するこのアプローチには、欠点があります。たとえば、そのような分散システムで使用されるすべてのものソフトウェア単一のコンピューターで動作する可能性がありますが、上記の定義の観点から、そのようなシステムは配布されなくなります。したがって、分散システムの概念は、おそらくそのようなシステムを構成するソフトウェアの分析に基づいている必要があります。

2つのエンティティの相互作用を説明するための基礎として、一方の当事者（クライアント）が他方の当事者（サーバー）に要求を送信することによってデータの交換を開始する、クライアント/サーバー相互作用の一般的なモデルを検討します。サーバーは要求を処理し、必要に応じてクライアントに応答を送信します（図1.1）。

図。 1.1。

クライアント/サーバーモデルのフレームワーク内の相互作用は、クライアントがサーバーが要求を処理するのを待っているときの同期、またはクライアントがサーバーに要求を送信してサーバーの要求を待たずに実行を継続する非同期のいずれかです。応答。クライアントとサーバーのモデルは、さまざまな相互作用を説明するための基礎として使用できます。このコースでは、分散システムを形成するソフトウェアの構成要素の相互作用が重要です。

図。 1.2。

現代の概念に従って、次の論理レベルに分割できる特定の典型的なアプリケーションを考えてみましょう（図1.2）。ユーザーインターフェース（PI）、アプリケーションロジック（LP）、およびデータアクセス（DD）、データベース（DB）との連携。システムユーザーはユーザーインターフェイスを介してシステムユーザーと対話し、データベースはアプリケーションドメインを説明するデータを格納し、アプリケーションロジックレイヤーはに関連するすべてのアルゴリズムを実装します。サブジェクトエリア.

実際には、システムのさまざまなユーザーが通常同じデータにアクセスすることに関心があるため、このようなシステムの機能を複数のコンピューター間で最も簡単に分離するのは、アプリケーションの1つのサーバー部分間でアプリケーションの論理層を分離することです。複数のコンピューターにあるデータとクライアントパーツへのアクセスを担当します。ユーザーインターフェイスを実装します。アプリケーションロジックは、サーバー、クライアントに割り当てることも、それらの間で共有することもできます（図1.3）。

図。 1.3。

この原則に基づいて構築されたアプリケーションのアーキテクチャは、クライアントサーバーまたは2層と呼ばれます。実際には、このようなシステムは分散システムとして分類されないことがよくありますが、正式には分散システムの最も単純な代表と見なすことができます。

クライアント/サーバーアーキテクチャの開発は3層アーキテクチャであり、ユーザーインターフェイス、アプリケーションロジック、およびデータアクセスは、独立したコンピューターで動作できるシステムの独立したコンポーネントに分離されています（図1.4）。

図。 1.4。

このようなシステムでのユーザーの要求は、システムのクライアント部分、アプリケーションロジックサーバー、およびデータベースサーバーによって順番に処理されます。ただし、分散システムは通常、3層システムよりも複雑なアーキテクチャを備えたシステムとして理解されます。

分散型AISは日常の現実となっています。多くの企業AISは分散データベースを使用しています。データ分散と分散データの管理の方法、システムのスケーラビリティを保証するアーキテクチャアプローチ、多層クライアントサーバーアーキテクチャの原則の実装、および中間層のアーキテクチャが検討されています。

モバイルアーキテクチャは実際に適用され始めています。これは、データベースシステムとWebアプリケーションの両方に当てはまります。

ピアツーピアアーキテクチャに基づいて分散システムを構築するアプローチが復活しています。分散システムで現在支配的なクライアントサーバーアーキテクチャとは異なり、ネットワーク内の相互作用するパーティの役割は固定されていません。これらは、ネットワークの状況、ノードのワークロードに応じて割り当てられます。

通信技術の集中的な開発に関連して、モバイルAISは活発に開発されています。それらを作成するための技術的手段とソフトウェアが開発されました。これは、モバイルデータベースシステムの開発につながりました。多くの研究チームは、そのようなシステムの特定の機能について研究を行い、さまざまなプロトタイプを作成しています。 Javaテクノロジは、モバイルソフトウェア開発の重要なツールになっています。

ワイヤレスアプリケーションプロトコル（WAP）標準が作成され、一部の携帯電話モデルですでにサポートされています。 WAPとXMLに基づいて、W3Cはワイヤレス通信用のマークアップ言語であるWML（Wireless Markup Language）を開発しました。

AISの開発では、メタデータにより多くの注意が払われ始めています。ここでは、メタデータの表示を標準化することと、システムでのサポートを確保することの2つの方向で手順を実行します。

AISは、メタデータ（さまざまな種類のメタデータリポジトリ）を表示するためのさまざまな方法と手段を使用します。この分野での統合の欠如は、アプリケーションのモビリティ、情報リソースと情報技術の再利用と統合、およびAISリエンジニアリングの問題の解決を大幅に複雑にします。

これらの困難を克服するために、さまざまな情報技術に焦点を当てたメタデータ標準の開発が積極的に進められています。この分野では、AISでのメタデータの表示とメタデータの交換を定義する、国際、国内、および業界の標準がすでに多数あります。それらのいくつかはすでに事実上の標準のステータスを取得しています。ここでは、それらの中で最も重要なものだけに言及することに限定します。

おそらく、このカテゴリの最初の事実上の標準は、ネットワークデータベース用のCODASYLデータ記述言語でした。次の標準に名前を付ける必要があります。いわゆる情報スキーマの定義を含む、リレーショナルデータベースのSQLクエリ言語の標準-リレーショナルデータベーススキーマの表現のセット。オブジェクトスキーマリポジトリインターフェイスを記述するODMGオブジェクトデータベースの標準コンポーネント。組織の情報リソースのディレクトリを作成および維持するためのシステムを説明する国際標準IRDS（情報リソース辞書システム）。

次に、MDC（Meta Data Coalition）コンソーシアムによって以前に作成されたOIM（Open Information Model）標準に基づいて、OMGコンソーシアムによって開発されたデータウェアハウスメタデータを表すためのCWM（Common Warehouse Metamodel）標準について言及する必要があります。

Webテクノロジープラットフォーム用の新しいXMLには、メタデータ表示標準も含まれています。メタデータのサポートは、Webの最も重要な革新の1つであり、情報リソースを管理するためのテクノロジーを根本的に変えています。データベーステクノロジでは当初メタデータのサポートが必要でしたが、第1世代のWebではメタデータはサポートされていませんでした。

Webメタデータ標準には、あるタイプのXMLドキュメントの論理構造を記述するために使用されるXML言語のサブセットが含まれています。この記述はDTD（文書型定義）と呼ばれます。さらに、XMLプラットフォームには、XMLドキュメントを記述するためのより高度な機能を提供するXMLスキーマ標準が含まれています。 Resource Definition Framework（RDF）標準は、XMLドキュメントのコンテンツを記述するための単純な知識表現言語を定義します。最後に、新しいOWL（Ontology Web Language）標準は、セマンティックWebの正式なオントロジー記述言語を定義します。

CASEビジュアルオブジェクト分析および設計ツールのメタデータ表現を提供する統一モデリング言語（UML）標準は、OMGコンソーシアムによって開発されました。この言語は、多くのCASEソフトウェア製品でサポートされています。 OMGは、UMLを使用してCASEツール間でメタデータを交換するためのXMLメタデータ交換（XMI）標準も作成しました。

ここでは、さまざまな性質のドキュメントのコンテンツを記述するためのメタデータ要素のセットであるダブリンコア（DC）標準についても言及する必要があります。この標準はすぐに人気を博し、特にWeb環境で広く使用されています（セクション3.3を参照）。

AISのメタデータを表示するための既存の標準の開発と新しい標準の作成に関する作業は継続されています。問題の規格に関するより詳細な情報は、百科事典にあります。

AggreGateは、分散アーキテクチャを真にサポートする世界でも数少ないIoTプラットフォームの1つです。これにより、さまざまな層ですべてのAggreGateサーバー操作のバランスを取り分離するための無制限のスケーラビリティが提供されます。このアーキテクチャは、現在の課題と将来のニーズの両方の基礎となる可能性があります。

フェールオーバークラスターとは異なり、分散アーキテクチャのAggreGateサーバーは完全に独立しています。各サーバーには、独自のデータベース、ローカルユーザーアカウント、および関連する権限があります。

AggreGateの分散アーキテクチャは非常に柔軟性があります。技術的には、サーバー間のピアツーピア接続の形成と、一部のサーバー（「サプライヤー」）の単一データモデルの一部を他のサーバー（「コンシューマー」）に接続することに基づいています。

分散運用の目標

分散アーキテクチャの主な目標は次のとおりです。

スケーラビリティ..。ダウンレベルのサーバーは大量にロードされ、データを収集し、ほぼリアルタイムで多数のデバイスを管理できます。ただし、実際には、1台のサーバーでサービスできるデバイスの数は数千に制限されています。多数のデバイスを管理するためにシステムを拡張する場合は、複数のサーバーをセットアップし、それらを分散インストールに組み合わせるのが賢明です。
負荷分散..。分散インストールの各サーバーは、異なる問題を解決します。ネットワーク管理サーバーはネットワークインフラストラクチャの可用性とパフォーマンスをチェックし、アクセス制御サーバーはドアコントローラーと回転式改札口からの要求を処理します。レポートの生成やメールでの配布などの制御操作は、中央サーバーで実行できます。
侵入防止..。セカンダリプローブサーバーは、離れた場所に設置して中央サーバーに接続できます。システムオペレータは中央サーバーにのみ接続するため、これらのサーバーへのVPNおよびポート転送を構成する必要がありません。
中央集権化..。セカンダリサーバーは完全自動モードで動作できますが、その構成と監視は中央制御室に設置されたメインサーバーを介して実行されます。

サーバーの役割の分散

この単純なシナリオでは、2台のサーバーが統合されて分散インフラストラクチャになります。システムオペレータは常に監視サーバーに接続され、日常業務を実行します。会社の経営陣は、データのスライスを取得する必要があるときに、レポートおよび分析サーバーに接続します。データ量やサーバーの負荷に関係なく、この操作はオペレーターの作業に影響を与えません。

大規模クラウドIoTプラットフォーム

テレコムおよびクラウドサービスプロバイダーは、IaaS / PaaS / SaaSモデルでIoTサービスを提供します。このような場合、数千人のユーザーが所有する数百万台のデバイスについて話します。このような巨大なインフラストラクチャを維持するには、何百ものAggreGateサーバーが必要であり、そのほとんどは2つのグループにグループ化できます。

ユーザーとそのデバイスの登録を保存し、オペレーターとデバイスの接続を下位レベルのサーバーにリダイレクトし、下位レベルのサーバーの参加を得て情報を後で分析するためにデータを集約するサーバー
デバイスを監視および管理し、データを受信、保存、処理するサーバー

ユーザーおよびデバイス管理サーバーは、新しいストレージおよび分析サーバーの展開と監視を担当するクラウド管理システムとの対話も担当します。

データストレージおよび処理サーバーは、テンプレートサーバーから受信したリソース（アラーム、モデル、ワークフロー、ダッシュボードなど）を使用し、テンプレートサーバーはこれらのリソースのマスターコピーを保存します。

階層化されたIoTインフラストラクチャ

AggreGateの分散インフラストラクチャのおかげで、どのソリューションにもさまざまなレベルの多くのサーバーを含めることができます。それらのいくつかはIoTゲートウェイで動作し、データを収集し、その他は情報を保存および処理するために、残りは高レベルの集約と分散コンピューティングを実行するために機能します。

センサーやアクチュエーターなどのフィールド機器は、サーバーに直接、エージェントを介して、ゲートウェイを介して、またはその2つの組み合わせで接続できます。

スマートシティ管理

これは、建物の大規模なグループの複雑な自動化のためのAggreGateベースの階層化アーキテクチャの例です。

レベル1：物理機器（ネットワークルーター、コントローラー、産業機器など）
レベル2：管理サーバー（ネットワーク監視サーバー、アクセス制御サーバー、ビルディングオートメーションサーバーなど）
レベル3：サーバーコントロールセンターの構築（すべての第2層サーバーから情報を収集する建物ごとに1つのサーバー）
レベル4：市区町村サーバー（低レベルのアラートをエスカレートするための最終的な宛先、リアルタイムの監視、サービスデスクシステムとの統合）
レベル5：本社のサーバー（地区サーバーの管理、レポートの収集と統合、通知）

上記のサーバーはいずれも、マルチノードフェールオーバークラスターにすることができます。

マルチセグメントネットワーク管理

AggreGate Network ManagerはAggreGateプラットフォーム上に構築されており、分散アーキテクチャの典型的なユースケースです。ルーティングの制限、セキュリティポリシー、またはリモートネットワークセグメントとの通信リンクの帯域幅の制限により、企業や通信事業者の大規模なセグメント化されたネットワークを単一のセンターから監視することはできません。

したがって、分散監視システムは通常、次のコンポーネントで構成されます。

プライマリまたは中央すべてのネットワークセグメントから情報を収集するサーバー
二次サーバーまたは プローブサーバー分離されたセグメントのポーリングデバイス
専門 1日に数十億のNetFlowイベントを処理するトラフィック分析サーバーなどのサーバー

セカンダリサーバーと専用サーバーは、プライマリサーバーの情報のプロバイダーであり、データモデルの一部をコントロールセンターに公開します。これは次のようになります。

プローブサーバーのコンテキストツリーのすべてのコンテンツ。これにより、中央サーバーから構成を完全に制御できます。この場合、プローブサーバーは、ネットワークセグメンテーションの問題を克服するためのプロキシとして使用されます。
プローブサーバーによって生成されたアラート。この場合、職場の99％がリモートである可能性があり、中央サーバーのオペレーターはすぐに2次サーバーから通知を受け取ります。
重要なデバイスのリアルタイムステータス情報や要約レポートなど、プローブサーバーからのカスタムデータセット。関連するすべての作業はセカンダリサーバーで実行され、負荷分散が可能になります。

高性能イベント管理

一元化されたインシデント管理など、AggreGateプラットフォームの特定のユースケースでは、かなりの数のイベントを受信、処理し、構造化された形式で永続的に保存する必要があります。ストリームは、1秒あたり数百万のイベントに到達し、さまざまなソースから受信される場合があります。

このような場合、1つのAggreGateサーバーがイベントのフロー全体を処理することはできません。分散アーキテクチャは、イベント処理を整理するのに役立ちます。

イベントを生成するオブジェクトには、これらのイベントを処理するいくつかのローカルサーバーがインストールされています。複数のソース（プローブ）が1つの処理サーバーに接続できます。
専用ストレージサーバーまたはマルチサーバービッグデータストレージクラスターは、各ローカル処理サーバーにバインドされます。クラスターノードの数は、イベントが生成される速度によって異なります。
すべてのオンプレミスストレージサーバーは、事前フィルタリング、重複排除、相関（ローカルに接続されたプローブに適用可能なルールを使用）、エンリッチメント、およびイベントストレージを実行します。
ローカルストレージサーバーは中央集約サーバーに接続します。アグリゲーションサーバーは、システム全体の重要なイベントを相互に関連付ける役割を果たします。
中央サーバーのオペレーターはイベントデータベース全体を閲覧でき、ライブデータを見つけるタスクはストレージサーバーに分散されます。したがって、すべてのイベントのデータベースに基づいて、一元化されたレポートとアラートを作成することができます。

デジタルエンタープライズ

AggreGateは、デジタル企業の調整プラットフォームとして機能できます。各AggreGateサーバーは、リモートオブジェクトの監視と管理から、ビジネスインテリジェンスやインシデント管理などの高レベルのサービスに至るまで、さまざまな機能を実行できます。

デジタル企業のすべてのサーバーは、分散インフラストラクチャを介して相互に接続されています。下位レベルのサーバーは、単一のデータモデルのコンテキストの一部へのアクセスを上位レベルのサーバーに提供し、企業全体の状況センターを作成できるようにします。

現在、商用目的で開発されたISはすべて分散アーキテクチャを備えています。これは、グローバルおよび/またはローカルエリアネットワークの使用を意味します。

歴史的に、ファイルサーバーアーキテクチャは、そのロジックが単純であり、ISがすでに運用されているアーキテクチャに転送するのが最も簡単であるため、最初に普及しました。次に、サーバークライアントアーキテクチャに変換されました。これは、論理的な継続として解釈できます。グローバルネットワークインターネットで使用されている最新のシステムは、主に分散オブジェクトのアーキテクチャに関連しています（図を参照）。 III‑15 )

ISは、次のコンポーネントで構成されていると想像できます（図III-16）。

III.03.2。ファイルサーバーアプリケーション。

これは歴史的に最初の分散アーキテクチャです（図III-17）。それは非常に単純に構成されています。サーバー上にはデータのみがあり、それ以外はすべてクライアントマシンに属しています。ローカルネットワークは非常に安価であり、このようなアーキテクチャではアプリケーションソフトウェアが自律的であるため、今日ではこのようなアーキテクチャがよく使用されています。これは、データファイルのみがサーバー上に配置されるクライアントサーバーアーキテクチャの変形であると言えます。異なるパーソナルコンピュータは、共通のデータストアを介してのみ相互作用するため、1台のコンピュータ用に作成されたプログラムは、このようなアーキテクチャに最も簡単に適応できます。

長所：

ファイルサーバーアーキテクチャの長所：

整理のしやすさ;

整合性と信頼性を維持するためにデータベースに必要な要件と矛盾しません。

ネットワークの混雑;

リクエストに対する予測できない応答。

これらの欠点は、データベースへの要求がネットワークを介した大量の情報の転送につながるという事実によって説明されます。たとえば、テーブルから1つまたは複数の行を選択するには、テーブル全体がクライアントマシンにダウンロードされ、DBMSはすでにそこで選択しています。重要なネットワークトラフィックは、データベースへのリモートアクセスの編成に特に関係しています。

III.03.2。 bクライアントサーバーアプリケーション。

この場合、サーバーとクライアントの間で責任が分散されます。それらがどのように分離されているかに応じて区別します太いそして シン・クライアント.

シンクライアントモデルでは、すべてのアプリケーション作業とデータ管理はサーバー上で行われます。これらのシステムのユーザーインターフェイスはパーソナルコンピュータに「移行」し、ソフトウェアアプリケーション自体がサーバーの機能を実行します。すべてのアプリケーションプロセスを実行し、データを管理します。シンクライアントモデルは、クライアントがコンピューターまたはワークステーションである場合にも実装できます。ネットワークデバイスは、インターネットブラウザとシステム内に実装されたユーザーインターフェイスを実行します。

メイン 不利益シンクライアントモデル-サーバーとネットワークの負荷が高い。すべての計算はサーバー上で実行されるため、クライアントとサーバー間に大量のネットワークトラフィックが発生する可能性があります。現代のコンピューターでは、十分な計算能力がありますが、銀行のモデル/シンクライアントでは実際には使用されていません

対照的に、シッククライアントモデルはローカルマシンの処理能力を使用します。アプリケーション自体はクライアントコンピューターに配置されます。このタイプのアーキテクチャの例はATMシステムであり、ATMがクライアントであり、サーバーが顧客アカウントデータベースにサービスを提供する中央コンピューターです。

III.03.2。 c2層および3層のクライアントサーバーアーキテクチャ。

上記で説明したアーキテクチャはすべて2層です。これらは、クライアントレベルとサーバーレベルを区別します。厳密に言えば、ICは3つの論理レベルで構成されています。

・ユーザーレベル。

アプリケーションレベル：

・データ層。

したがって、2層のみが関与する2層モデルでは、シンクライアントモデルを選択した場合はスケーラビリティとパフォーマンスの問題が発生し、シッククライアントモデルを選択した場合はシステム管理の問題が発生します。これらの問題は、2つのレベルがサーバーである3つのレベルで構成されるモデルを適用することで回避できます（図III-21）。

データサーバー

実際、アプリケーションサーバーとデータサーバーは同じマシン上に配置できますが、相互に機能を実行することはできません。 3層モデルの良いところは、アプリケーションの実行とデータ管理を論理的に分離していることです。

表III-5さまざまなタイプのアーキテクチャの適用

建築	応用
2層シンクライアント	1アプリケーションの実行とデータ管理を分離することが推奨されないレガシーシステム。 2データ管理をほとんど行わずに集中的なアプリケーションを計算します。 3大量のデータがあるが、計算が少ないアプリケーション。
2層シッククライアント	1ユーザーが集中的なデータ処理、つまりデータの視覚化を必要とするアプリケーション。 2適切に管理されたシステム環境に適用される、比較的一定のユーザー機能のセットを持つアプリケーション。
3層サーバークライアント	1セルと数千のクライアントを備えた大規模なアプリケーション2データと処理方法の両方が頻繁に変更されるアプリケーション。 3複数のソースからのデータを統合するアプリケーション。

このモデルは多くの種類のアプリケーションに適していますが、サービスを提供する場所を決定し、スケーラビリティのサポートを提供し、新しい顧客を接続するためのツールを開発する必要があるIS開発者を制限します。

III.03.2。 d分散オブジェクトアーキテクチャ。

より一般的なアプローチは、オブジェクトが主要なコンポーネントである分散オブジェクトアーキテクチャによって提供されます。それらは、インターフェースを介して一連のサービスを提供します。他のオブジェクトは、クライアントとサーバーを区別せずにリクエストを送信します。オブジェクトは、ネットワーク内のさまざまなコンピューターに配置でき、システムバスと同様にミドルウェアを介して対話できます。これにより、さまざまなデバイスを接続し、ハードウェアデバイス間の通信を維持できます。

…

ODBCドライバーマネージャー

ドライバー1

ドライバーK

DB 1

DB K

SQLの操作

…

ODBCアーキテクチャには次のコンポーネントが含まれます。

1.アプリケーション（例：IS）。タスクを実行します。データソースへの接続を要求し、SQLクエリをデータソースに送信し、SQLクエリのストレージ領域と形式を記述し、エラーを処理してユーザーに通知し、トランザクションをコミットまたはロールバックし、への接続を要求します。情報元。

2.デバイスマネージャー。アプリケーションの要求に応じてドライバーをロードし、すべてのアプリケーションに単一のインターフェイスを提供します。ODBC管理者インターフェイスは同じであり、アプリケーションが対話するDBMSに関係ありません。 Microsoftが提供するDriverManagerは、動的にロード可能なDLLです。

3.ドライバーはDBMSに依存します。 ODBCドライバーは、ODBC関数を実装し、データソースと対話するダイナミックリンクライブラリ（DLL）です。ドライバーは、DBMSに固有の関数（DBMSに従って要求を変更できます）の要求を処理し、その結果をアプリケーションに返すプログラムです。 ODBCテクノロジーをサポートするすべてのDBMSは、アプリケーション開発者にそのDBMSのドライバーを提供する必要があります。

4.データソースには、ユーザーが指定した制御情報、データソースに関する情報が含まれており、特定のDBMSにアクセスするために使用されます。この場合、OSとネットワークプラットフォームの手段が使用されます。

動的モデル

このモデルは、少なくとも5つの図を使用してUML言語で表される多くの側面を想定しています。ppを参照してください。 2.04.2-2.04.5。

管理の側面を考えてみましょう。ガバナンスモデルは、構造モデルを補完します。

システムの構造がどのように記述されていても、それは一連の構造単位（関数またはオブジェクト）で構成されます。それらが全体として機能するためには、それらを制御する必要があり、静的ダイアグラムには制御情報がありません。制御モデルは、システム間の制御フローを設計します。

ソフトウェアシステムには、主に2つのタイプの制御があります。

1.集中管理。

2.イベントベースの管理。

一元管理には次のようなものがあります。

· 階層-「コールリターン」の原則に基づいて（これが教育プログラムが最も頻繁に機能する方法です）

· ディスパッチャモデルこれは並列システムに使用されます。

に ディスパッチャモデルシステムのコンポーネントの1つがディスパッチャであると想定されています。システムの起動とシャットダウン、およびシステムの他の部分の調整の両方を管理します。プロセスは互いに並行して実行できます。プロセスとは、現在実行中のプログラム、サブシステム、またはプロシージャを指します。このモデルは、制御プログラムがいくつかの状態変数に応じて（オペレーターを介して）個々のサブシステムを呼び出すシーケンシャルシステムにも適用できます。場合).

イベント管理管理を担当するサブルーチンがないことを前提としています。制御は、マウスボタンを押す、キーボードを押す、センサーの読み取り値を変更する、タイマーの読み取り値を変更するなどの外部イベントによって実行されます。各外部イベントはエンコードされ、イベントキューに配置されます。キュー内のイベントに対するリアクションが提供されると、プロシージャ（サブルーチン）が呼び出され、このイベントに対するリアクションが実行されます。システムが反応するイベントは、他のサブシステムまたはシステムの外部環境のいずれかで発生する可能性があります。

このような管理の例は、Windowsでのアプリケーションの編成です。

前述のすべての構造モデルは、集中管理またはイベントベースの管理を使用して実装できます。

ユーザーインターフェース

インターフェースモデルを開発するときは、設計されたソフトウェアのタスクだけでなく、情報の知覚に関連する脳の機能も考慮に入れる必要があります。

III.03.4。情報の知覚と処理に関連する人の精神物理学的特性。

従来は知覚プロセッサと呼ばれていた脳の部分は、意識の関与なしに常に、入ってくる情報を処理し、過去の経験と比較して保存します。

視覚的なイメージが私たちの注意を引くとき、私たちが興味を持っている情報は短期記憶に到着します。私たちの注意が引き付けられなかった場合、ストレージ内の情報は消え、次の部分に置き換えられます。

いつでも注意の焦点を一点に固定できるので、複数の状況を同時に追跡する必要が生じた場合、焦点は追跡されたオブジェクトから別のオブジェクトに移動します。同時に、注意が散らばり、細部が見落とされる可能性があります。知覚が主に動機に基づいていることも重要です。

フレームが変わると、脳はしばらくの間ブロックされます。それは新しい画像をマスターし、最も重要な詳細を強調します。つまり、ユーザーからの迅速な対応が必要な場合は、写真を急に変更しないでください。

短期記憶は、人の情報処理システムのボトルネックです。その容量は7±2の接続されていないオブジェクトです。未請求の情報は30秒以内に保存されます。私たちにとって重要な情報を忘れないようにするために、私たちは通常、それを自分自身に繰り返し、短期記憶の情報を更新します。したがって、インターフェースを設計する際には、圧倒的多数が、たとえば、別の画面で5桁を超える数字を覚えて入力することが難しいと感じることに留意する必要があります。

長期記憶の容量と保存時間は無制限ですが、情報へのアクセスは簡単ではありません。長期記憶から情報を抽出するためのメカニズムは、本質的に連想的です。情報の記憶を改善するために、それはメモリがすでに保存しているデータに結び付けられており、簡単に取得できます。長期記憶へのアクセスは難しいので、ユーザーが情報を覚えているという事実ではなく、ユーザーがそれを認識しているという事実に頼ることをお勧めします。

III.03.4。 bインターフェースを評価するための基本的な基準

多数の調査および主要なソフトウェア開発会社による調査は、ユーザーがインターフェースを重視していることを示しています。

1）習得と記憶のしやすさ-具体的には、習得の時間と情報と記憶の保存期間を見積もります。

2）システムを使用したときに結果を達成する速度。これは、マウスによって入力または選択されたコマンドと設定の数によって決まります。

3）システムの操作に対する主観的な満足度（使いやすさ、疲労感など）。

さらに、常に同じパッケージを使用するプロのユーザーの場合、2番目と3番目の基準がすぐに最初になります。また、ソフトウェアを定期的に使用し、比較的単純なタスク（1番目と3番目）を実行する非プロのユーザーの場合も同様です。

この観点から、無料ナビゲーションを備えたインターフェースは、今日のプロのユーザーにとって最高の特性を備えており、プロ以外のユーザーにとってはダイレクトマニピュレーションインターフェースを備えています。ファイルをコピーするとき、他のすべてが同じである場合、ほとんどの専門家はFarのようなシェルを使用し、非専門家はWindowsの「ドラッグアンドドロップ」を使用することに長い間注目されてきました。

III.03.4。 cユーザーインターフェイスの種類

次のタイプのユーザーインターフェイスが区別されます。

プリミティブ

無料ナビゲーション

直接操作。

インターフェースは原始的です

プリミティブこれは、ユーザーとの対話を整理するインターフェイスと呼ばれ、コンソールモードで使用されます。データが提供するシーケンシャルプロセスからの唯一の逸脱は、複数のデータセットをループすることです。

メニューインターフェイス。

プリミティブインターフェイスとは異なり、ユーザーはプログラムによって表示される特別なリストから操作を選択できます。これらのインターフェースには、ユーザーが決定する一連のアクションである、多くの作業シナリオの実装が含まれます。メニューのツリーのような構成は、2つ以上のレベルのメニューでアイテムを見つけるのが難しいことを示唆しています。

印刷