より簡単にするために、標準のシステムの1つであるASUDD（自動交通制御システム）をより詳細に検討することを提案します。 さらに、これは現在、わが国では非常にファッショナブルなトピックであり、コンピューターは通常のアスファルトに取って代わることができ、おそらく道路がなくても大丈夫だという幻想がまだ残っています。
アーキテクチャの基本概念
必要条件
次の図は、アーキテクチャの基本要素とそれらの関係を示しています。 今日私たちが見ているエンティティは緑色になっています。
IT担当者にとっては、常に機能要件に合わせて踊る方が便利です。 前に書いたように、アメリカ人はITSの要素に対するすべての可能な要件を定式化し、それらに属性を提供し、それらをテーブルに持ち込みました。
1,400以上の固有の要件を数えました。 これらのうち、約120はASUDDに属し、そのうち60〜70のみがロシアの仮想システムに提示できます。 残りの要件は、完全なエキゾチック（たとえば、高速道路の自動車線や車内の交通標識の移動）に関連するか、私たちが実装するのは非現実的なアメリカの仕様に関連しています（交差点で交通渋滞が発生しないように、鉄道のスケジュールと交通信号調整計画の統合） 。
ここで、たとえば、トラフィック制御サブシステムの要件は何ですか：
- システムは、道路管理者のリモート制御を提供する必要があります
- システムは横断歩道のリクエストを受け入れる必要があります
- システムは、道路管理者の運用状況に関する情報の集中収集と検証を提供する必要があります
- システムは、道路管理者の障害に関する情報を提供する必要があります
- システムは、検出器からのデータ、交通流に関する情報、事故、特別車両の優先旅行の要求、過負荷の貨物車両のデータ、機器の故障に関する情報、通過の要求に基づいて、DAC職員の管理下にある信号交差点での信号調整計画の適用を許可する必要があります歩行者などから
すべてが非常に論理的であるように思われ、「等」の形の標準的な「カント」もあります。これは、プロジェクトを台無しにするか、請負業者からさらにお金を絞るために、この「等」にカバで象を押し込もうとする企業トロルのお気に入りの扱いです。 場合によっては、要件は生きている人々で構成されており、これらの要件は実際の参照条件から取られた「戦闘」要件に似ています。
サブシステム
オリジナルでは、アメリカ人は「機器パッケージ」という用語を使用します。これは、機能要件の対象となる機器アイテムのグループです。 私は、「サブシステム」の概念を使用することを提案します。これは、意味ができるだけ近いだけでなく、より身近で親しみやすいものです。
サブシステムは、ハードウェア、ソフトウェア、および通信チャネルを使用して、機能要件を物理的に実装します。 アーキテクチャには、これらすべての要素のレジスタと、すべてのサブシステムと機器/ソフトウェア/ネットワークの要素間の関係の表があります。 不必要に写真を乱雑にしないために、私はこの関係を描きませんでした。
以下は、私たちの国での実装に推奨するコメント付きの主なサブシステムです。 一般的な開発のために、「エキゾチック」なものを以下にリストします。
- バリア管理サブシステム。 障壁およびその他の遮断装置の遠隔制御を実行します
- 交通情報を収集するためのサブシステム。 監視カメラ、交通流検出器からの情報のリモート収集、この情報の処理と保存、および外部ソースから受信した交通情報を実行します。 また、外部システムおよび他のASUDDに情報の収集を提供します。
- 環境モニタリングのサブシステム。 ADMS、気象センター、近隣のASUDDからの情報を使用して気象条件を制御します。 他のサブシステムに情報を提供して、道路利用者に通知し、決定を下します。
- 高速道路管理サブシステム。 高速道路へのアクセスの規制、中間速度制御、ジャンクション、車線などの管理を含む、高速道路の集中監視と交通制御を提供します。
- ATOP用のレーン管理サブシステム。 （私はここで「公共交通機関」という用語を選びましたが、アメリカ人はHOV-High Occupancy Vehicleを使用しています。複数の人を乗せた乗用車はこの用語に該当します） 選択した車線の交通を管理し、交差点でのATOPの移動を優先し、割り当てられた車線の使用における違反を修正します。
- インシデント検出サブシステム。 インシデントの識別を実行し、MCC（トラフィックコントロールセンター）の担当者に通知します。 事故検知を提供する交通収集システムである道路検知器をリモートで監視します。 また、貨物積み替えポイント、国境通過ポイントなどでのインシデントに関する情報の受信と処理も提供します。
- 関連するASUDDとの統合のサブシステム。 これは、地域のASUDDと地域のASUDDの間の交通制御対策を統合および調整します。たとえば、都市の信号機と地域の高速道路の信号機の調整です。
- 後退車線の管理のサブシステム。 リバース信号、バリア、およびレーンへの進入を制限するその他の手段を制御することにより、リバースレーンのリモートモニタリングおよび管理を実行します。
- 信号制御サブシステム。 信号機のある交差点で交通流を監視および制御する機能を提供します。 この機能には、検出器データの分析と処理、同じ制御ドメイン内の複数の交差点での調整計画の開発と適用が含まれます。
- 速度制御のサブシステム。 リモート速度監視および速度超過警告システム制御を提供します。 車両の速度の測定と、この情報のMCCへの転送を実行します。 また、規制当局に大幅なスピード違反の事実に関する通知を提供します。
- 交通情報を広めるためのサブシステム。 交通、道路状況、天井、推奨される迂回ルートに関する情報の普及を提供します。 インシデント、アナウンスメント、その他の輸送情報に関する情報を他のサブシステム、センター、メディアなどに提供します。 TPI（可変情報ディスプレイ）での情報の表示、無線による情報の送信などを提供します。
- 意思決定支援サブシステム。 オペレーターに、現在および予測される道路状況と交通状況に基づいた一連のアクションを推奨します。 交通事故、特別なイベント、メンテナンス、輸送需要に影響するその他のイベントを監視します。 履歴データは、オペレーターのアクションの結果を評価し、推奨事項を作成するために使用されます。 推奨されるアクションには、インシデント対応計画の再定義、調整計画の再計算、さまざまな制御戦略の適用、高速道路への進入の制限、輸送交通のリダイレクト、および運転者への迂回ルートの推奨が含まれます。 オペレータが推奨事項に同意した後、システムはシナリオを適用し、MCCの機器が必要なアクションを実行します。
- 道路網のパフォーマンスを評価するためのサブシステム。 トランスポートネットワークのパフォーマンスを測定し、トランスポート需要の変化を予測して、トラフィックフローの最適化、トラフィック需要の管理、およびトラフィックインシデントを管理します。 交通検知器から情報を収集するほか、他のASUDDおよび関連システム、環境監視センター、物流センター、公共イベントの主催者からの情報を収集し、この情報を使用して交通流性能パラメーターを測定します。 サブシステムは、輸送状況の進展を予測するために、計画されたルートに関する情報も収集します。 計画戦略はユーザー情報サブシステムに転送でき、将来のルート計画にも使用できます。
- 道路網の状態に関する情報を収集するためのサブシステム。 地域全体のトランスポートネットワークの状態に関する情報のリアルタイム収集を提供します。 これには、通信およびLASUDDデータをリアルタイムで処理できるかどうかの決定が含まれます。 サブシステムは、ローカルDBMSへのクエリを使用してLASUDD情報を収集し、この情報を他のDACシステムと外部システム間で配布します。
- サブシステム管理の修復作業。 道路網の保守作業計画を調整して、輸送状況に対する修理および保守作業の影響を最小限に抑えます。 TPIにアナウンスを表示することにより、道路のユーザーに修理作業が行われていることを知らせます。
- 交通情報を収集および保存するためのサブシステム。 スタッフによるその後の使用および連邦レベルでのアーカイブのために、交通情報のストレージを提供します。
- 機器操作サポートサブシステムは、機器のヘルスモニタリングと障害検出を提供します。 運用担当者に通知し、情報を修理管理サブシステムに転送します。 設置された機器の全範囲のパフォーマンスが監視されます。
そして今、少しエキゾチックです。
TMC自動車両運用。 自動化された高速道路のリモートコントロールを実行します（それに沿って、自動化されたトランスポートが移動します。
そして、ここで翻訳に困難が生じました。 ロシア語には適切な用語がありません。
TMC 車両署名管理（ オンボード交通標識表示システムによるドライバー情報管理）。 運転者が標識の動作領域を横断するためのオンボード警告システムで標識を切り替えるための信号を送信する機器を監視および制御します。
TMCデマンド管理調整。 これらのサービスの価格を規制するために、駐車場およびその他の有料インフラストラクチャ要素の需要を制御します。
TMC避難サポート。 自然災害時の避難中の交通管理のシナリオと戦略の開発、調整、実装をサポートします。 この戦略は、可能な輸送需要のモデリングに基づいて開発されています。 サブシステムは、緊急センター（ASUDDに含まれていない別のサブシステム）と密接に連携して動作します
リストを継続することはできますが、すでにリストされているものは、最も熱心な読者でさえ居眠りさせるのに十分すぎると思います。 たぶん小さな慰めは、私が21個のサブシステムしかリストしておらず、合計219個のさまざまなサブシステムが ITS標準に含まれていることです！ これらのサブシステム間の情報フローの高レベルの説明のみが小さな活字で3つの厚いボリュームを占め、それらがアメリカ人によって発行された理由は不明です。 結局のところ、このシステムを理解するために、紙の上の絆の網を見るのは、原則として不可能です。 すべての通信は、この記事の準備で使用したAccess形式の標準に添付されたデータベース内にあります。
プロセス
実際、オリジナルではそれらはマーケットパッケージと呼ばれ、正しい翻訳を見つけようとして頭を痛めました。 その結果、これらのエンティティはITSの動的なコンポーネント、つまり目標を達成するために行うことをグループ化するため、「プロセス」という言葉にこだわることにしました。
ASUDDプロセスのリストについては説明しませんが、これは提示された資料に付加価値を加えるものではありませんが、誰も必要としないリストに追いつくだけです。 他のプロセスがどのように見えるか想像できるように、いくつかのプロセスの例を挙げましょう。
高速道路の管理。 高速道路の交通制御を提供します。 高速道路へのアクセスの制限、流量の制御、車線、出入口の管理など、さまざまな管理戦略が含まれます。 必要なすべての機器とソフトウェアが含まれています。
ATOP専用レーンの管理。 ATOPトラフィックの車線管理を提供します。 これには、信号機の設備と、予定より遅れている車両の優先移動を保証する車両が含まれます。 オンボードシステムには、GPS機器、ドア開閉装置、トリップコンピューターが含まれます。
プロセス仕様は、プロセスに直接関連しています。ソフトウェアに関する声明をさらに展開したり、サプライヤーの要件を策定したりするのに十分な詳細を各プロセスに正式に記述した文書です。
プロセス仕様は、ターミネーターに関連付けられています。 ターミネーターは、プロセスが対話するエンドユーザーまたは他の（外部）システムです。 簡単にするために、この用語を「ASUDDユーザー」と訳しました。これは、システムのパラメーターまたは部分を担当する人々が果たすビジネス上の役割を意味します。
まとめ
したがって、ASUDDのアーキテクチャは次のことを完全に説明しています。
- システム機能要件
- 使用機器
- サブシステム
- プロセス
- プロセスの役割
- 内部および外部の情報フロー
結論として、システムの全体または一部を実装するための完全なデータセットと、既存または将来のシステム、たとえば物流輸送センターとの統合のための戦略的予備があります。
私の意見では、非常に美しい。