この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
序章
TCCS の一般要件
タイム クリティカルな通信システム (TCCS) は、ネットワーク システム全体でシーケンスとトラフィック パターンが動的に変化する通信用に最適化された通信ネットワーク システムの一種ですが、このような通信ネットワーク システムは、事前にスケジュールされた静的シーケンスもサポートする必要があります。通信の。
タイム クリティカルな通信は、1 つまたは複数の指定されたアクションが定義されたレベルの確実性で完了する必要がある、特定の制限された時間枠がある通信です。 TCCS は、タイム クリティカルなメッセージとタイム クリティカルでないメッセージの両方を共存させる機能を提供します。タイム クリティカルな分散アプリケーションでは、アルゴリズム、データ、および制御構造がネットワークの周囲にあります。このような配信は、通信システムが特定のサービス品質、特に時間の制約、一貫性などを提供する場合にのみ可能です。
すべての TCC システムは、レジリエンスの要件において他のネットワークとは異なることが認識されています。時間の制約が厳しくなればなるほど、レジリエンスの戦略がより重要になります。これは、データ フローが小さな障害によって乱されない場合、厳しい時間の制約を満たすことができるネットワークは、優れたレジリエンスを示す必要があるためです。
TCC アーキテクチャは、必要に応じて OSI 基本参照モデルに準拠し、条項 4 で特定されたユーザー要件を満たします。現在の OSI 標準は、一般的なデータ トラフィックの転送を保証すること、またはメッセージの配信。したがって、TCC をサポートするには、現在の OSI モデルとアーキテクチャを強化する必要があります。
TCCS のユーザー要件
自動化された工場は、分散制御アプリケーションにネットワークを使用します。これらのアプリケーションには、平均的なパフォーマンスではなく、最悪の場合のパフォーマンスに対応するように設計された通信システムが必要です。このようなシステムでは、適時性が最も重要です。ネットワークは、大量のデータ転送とタイム クリティカルなメッセージの両方に対応できる必要があり、回復力を実現する方法をサポートする必要があります。
必要に応じて、TCCS を主要な工場データ通信ネットワークと接続することは、リンク デバイスを使用して簡単な手順で行う必要があります。非常に過酷な環境で動作する必要があるため、非常に低いビット エラー レートを実現し、必要な再送信回数を最小限に抑えるには、信頼性の高いメディアと信号方式が必要です。ユーザーは、通信の優先順位を定義し、エラー回復メカニズムを制御できる必要があります。ネットワーク管理機能は、リソースの割り当て、TCC グループへのアクセスの制御、潜在的な障害と実際の障害の検出などに必要です。
識別されたユーザー要件により、タイム ウィンドウの概念を OSI で実現できます。 TCC アーキテクチャ、特性または属性、タイム ウィンドウ、およびタイム クリティカルな通信を必要とするアプリケーションの間の相互関係を図 2 に示します。
図 2 — TCC アーキテクチャ、特性、タイム ウィンドウ、およびタイム クリティカルな通信を必要とするアプリケーション間の相互関係
TCCA でのネットワーク管理
ネットワーク管理に関する要件は、タイム クリティカルな通信ネットワーク システムの動作が制限される状況下で、ユーザーによって指定された時間的制約を満たすために不可欠なサービスの提供という観点から、TCCS のユーザー要件から抽出および翻訳されます。動的に変化します。
QoS 基本フレームワークの意味では、QoS 要件は、ネットワーク管理要件の一部またはすべてを表現するための情報であり、QoS 要件がエンティティ間で伝達されるときのメカニズムの一部として QoS パラメータの観点から表現されます。この情報は、タイム クリティカルな通信ネットワーク システムの運用に適用されるポリシーに密接に関係しています。
一部のタイム クリティカルなアプリケーションでは、すべてのユーザー要件が常に満たされる必要はありません。したがって、TCCA または TCCA 内のネットワーク管理が、特定されたすべてのネットワーク管理要件を満たすことは必須ではありません。これは、これらの要件の特定のサブセットを満たす許容可能なクラスがあることを意味します。これらのクラスは、このテクニカル レポートでは扱いません。
Introduction
General requirements for TCCS
A time-critical communications system (TCCS) is a type of communications network system which is optimized for communications where sequences and traffic patterns vary dynamically over a whole network system. However, such a communications network system also has to support pre-scheduled static sequences of communications.
Time-critical communications are communications in which there is a specific bounded time window within which one or more specified actions must be completed with some defined level of certainly. A TCCS provides the capability for both time-critical messages and non-time-critical messages to coexist. In a distributed time-critical application, algorithms, data and control structures are around networks. Such a distribution is only possible if the communication systems provide a certain quality of service, particularly regarding time constraints, coherence, etc.
It is recognized that all TCC systems differ from other networks in their requirement for resilience. The tighter the time constraints are, the more important strategies for resilience become, since networks capable of meeting tight time constraints need to exhibit great resilience if the data flow is not to be perturbed by minor faults.
A TCC architecture complies with the OSI Basic Reference Model whenever appropriate, meeting the user requirements identified in clause 4. Current OSI standards cannot readily accommodate time-critical communications because their primary objectives are to ensure the transfer of general data traffic or to satisfy intercommunication between delivery of messages. Therefore, the current OSI model and architecture needs to be enhanced to support TCC.
User requirements for TCCS
Automated factories use networks for distributed control applications. These applications require communications systems which are designed to accommodate worst-case performance as opposed to average performance; in such systems timeliness is of paramount importance. The network should be able to cope with both bulk data transfers and time-critical messages and should support methods for achieving resilience.
If necessary, interfacing the TCCS with the main factory data communication network should be a simple procedure, using a linking device. Because of the requirement to operate in very harsh environments, highly reliable media and signaling methods are necessary so that a very low bit error rate results and a minimum number of retransmissions is necessary. The user needs to be able to define communications priorities and control error recovery mechanisms. Network management functions are necessary to allocate resources, control access to TCC groups, detect latent failures and actual failures, etc.
The user requirements that are identified allow the concept of time windows to be realized in OSI. The inter-relationship between TCC architecture, characteristics or attributes, time windows and applications requiring time-critical communications are set out in Figure 2.
Figure 2—Inter-relationship between TCC architecture, characteristics, time windows and applications requiring time-critical communications
Network management in TCCA
The requirements on network management are extracted and translated from the user requirements in TCCS in terms of the provision of services which is essential in order to meet the time constraints specified by users under the circumstances in which the behaviour of the time-critical communications network system varies dynamically.
In the sense of the QoS Basic Framework, the QoS requirements are information to express part or all of the network management requirements, and are expressed in terms of QoS parameters as part of a mechanism when a QoS requirement is conveyed between entities. This information closely concerns a policy that is to apply to the operation of a time-critical communications network system.
In some time-critical applications all user requirements need not always be satisfied. It is therefore not essential for a TCCA or the network management in a TCCA to meet all the network management requirements identified herein. This means that there will be allowable classes which meet specific subsets of these requirements. These classes are not addressed in this Technical Report.