/

ISO 15396:2007 宇宙データおよび情報転送システム—クロスサポート参照モデル—宇宙リンク拡張サービス | ページ 5

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

1 はじめに

1.1 この推奨規格の目的

1.1.1 SLE サービス仕様のベースラインとリファレンス

この推奨標準は、スペース リンク拡張 (SLE) サービス仕様の CCSDS 推奨標準の開発を調整するための共通の基盤を提供し、これらの推奨標準の一貫性を維持するための参照として機能するクロス サポート参照モデルを定義します。

1.1.2 スペースリンク推奨規格との関係

CCSDS Space Link 推奨規格 (Advanced Orbiting Syste, Packet Telemetry, および Telecommand, 参考文献 [2]-[7]) は、宇宙船に搭載されたデータ ソースとシンク、およびデータ シンクとの間でデータを転送するためのフォーマットとプロトコルを定義します。図 1-1 に示すように、地上のソース。これらの Space Link プロトコルは、宇宙/地上無線リンクのノイズの多い高遅延環境で効率的に動作するように設計されています。そのため、多数の地上局を地上シンクおよびデータ ソースにリンクする地上システムを構成および運用するために必要な情報を伝送しません。

図 1-1 — CCSDS 宇宙ミッション データ システム

SLE 推奨基準は、地上データ システムの構成、運用、および監視に必要な一連のサービスで、CCSDS スペース リンク推奨基準を補完します。

SLE 推奨規格は、1) スペース リンクを介して宇宙船から CCSDS スペース リンク データ構造を受信する、または 2) スペース リンクを介して CCSDS スペース リンク データ構造を宇宙船に送信する、または 3) できるデータ システムに適用されます。そのような CCSDS Space Link データ構造を地上のエンティティ間で転送します。

SLE サービスと CCSDS スペース リンク プロトコルの関係は、 Cross Support Concept — Part 1: Space Link Extension Services, リファレンス [10] で説明されています。

1.1.3 SLE サービス

SLE サービスには以下が含まれます。

  • a) 1.1.2 で説明されているデータ転送の地上部分に関係する SLE 転送サービス。この転送は、地上データ システム内で行われるか、地上データ システムと地上データ ソース/シンクの間で行われます。
  • b)地上システムによる SLE 転送サービスのスケジューリングと提供を制御する SLE 管理サービス。

1.1.4 SLE システム

SLE サービス仕様の CCSDS 推奨基準に準拠したサービスを提供する地上システムは、SLE システムと呼ばれます。

1.1.5 SLE サービスのフレームワーク

この推奨規格は、宇宙ミッションのサポートに使用される SLE サービス仕様を定義するためのフレームワークを提供します。このフレームワークは次のもので構成されます。

  • a) SLE システムとその環境の識別。
  • b)以下を含む SLE システムのアーキテクチャモデル:
    • 1)機能ビュー;
    • 2)管理ビュー。

  • c) SLE サービスの共通特性と SLE サービス仕様のテンプレート:

    • 1)個々の SLE サービス仕様は、それぞれのサービス品質条項で通信サービスのサポートに関する要件を表します。
    • 2)与えられた SLE サービスの提供者と利用者は、適切な電気通信設備が整っていることを保証するものと想定されています。

  • d) SLE転送サービスの識別。

注 —項目 d) では、SLE 転送サービスが識別されます。ただし、完全なサービス仕様は別の推奨規格で提供されます。

1.2 範囲

この推奨規格の範囲は、SLE サービス仕様の CCSDS 推奨規格の開発を調整するための共通の基礎を確立するすべての概念と用語の定義です。これらの概念と用語を定義する際には、次の仮定が行われます。

  • a)コンテキストが単一の宇宙ミッションのコンテキストである。
  • b)この宇宙ミッションでは、単一の宇宙船が考慮されます。
  • c)この宇宙船のテレメトリとテレコマンドは、CCSDS スペース リンク推奨基準に準拠しています。
  • d)すべての地上エンドユーザー (つまり、データ シンクまたはソース) は、単一のミッション管理エンティティと提携しています。

次の点は、この推奨規格ではカバーされていません。

  • a)複数の宇宙ミッション間または同じ宇宙ミッションの複数の宇宙船間で地上システムを共有することは明示的にモデル化されていませんが、この推奨規格は決して地上システムの共有を排除するものではありません。
  • b) CCSDS Space Link Recommended Standards に準拠したデータの転送に直接関与しない地上システムおよび/またはサービスは記述されていません。 CCSDS パケット テレメトリ、テレコマンド、および AOS 推奨標準 (参照 [2]-[7]) で説明されているソース パケット プロトコル データ ユニット (PDU) のデータ フィールド内に保持されるデータの処理は、この推奨標準の範囲外です。
  • c)この参照モデルは、地上通信サービスが宇宙ミッションをサポートするために SLE サービスと組み合わせて使用​​されることを前提としていますが、これらの通信サービスを明示的にモデル化していません。

1.3 適用性

1.3.1 この推奨規格の適用性

この推奨規格は、SLE システムの互換性のあるエージェンシー規格を開発するためのガイドラインとして役立ちます。この推奨規格に含まれるシステムには、有人および無人の自由飛行宇宙船および宇宙輸送システムが含まれます。この推奨規格は、クロス サポートに関与する SLE システムに特に関連しています。

1.3.2 適用範囲の制限

この推奨規格は、既存または将来のミッションの制御および監視のために実装される可能性のある実際の SLE システムの仕様でも設計でもありません。

1.4 合理的

CCSDS の主な目標は、機関間の相互運用性のレベルを高めることです。この推奨規格は、ほとんどの相互支援活動が行われる地域で使用される一連の SLE サービスの基礎を確立することにより、その目標を推進します。さまざまな機関の追跡ステーションまたは地上データ処理システムとミッション グラウンドのミッション固有のコンポーネントとの間です。参照 [10], クロス サポート コンセプト — Part 1: スペース リンク エクステンション サービスは、この推奨規格の理論的根拠の詳細な議論を提供します。

1.5 ドキュメント構造

この推奨規格は次のように構成されています。

  • a)セクション 1 は、この推奨規格の目的、範囲、適用可能性、および理論的根拠を提供し、文書全体で使用される定義、規則、および参照を一覧表示します。
  • b)セクション 2 は、クロス サポートのコンテキストを提供し、クロス サポートのドキュメント構造を提示し、この推奨規格がそのフレームワークにどのように適合するかを示します。概要を提供するために、このドキュメントの範囲を拡張します。
  • c)セクション 3 では、SLE システム環境、SLE システムによって処理されるデータを定義し、SLE サービスを紹介します。
  • d)セクション 4 は、SLE システムのアーキテクチャ モデルを定義します. このアーキテクチャ モデルは、次の 2 つのビューで構成されます。
    • 1) SLE サービスの派生元である、機能およびデータを含むシステムの概念を定義する機能ビュー。この機能ビューでは、SLE システムは SLE 機能グループ (SLE-FG) に分解され、CCSDS パケット テレメトリ、テレコマンド、および AOS 推奨標準 (参照 [2]- [7]）。
    • 2)クロス サポート管理ビュー。SLE サービスの提供に関与するエンティティ間の管理相互作用を定義し、SLE サービス管理仕様のベースラインを提供します。この管理ビューでは、SLE システムが SLE コンプレックスに分解され、SLE サービス パッケージの概念が導入されます。

  • e)セクション 5 では、SLE サービスの共通の特性を定義し、SLE 転送サービス仕様のテンプレートを提供し、対応するポートでの操作とパラメータを含む各 SLE サービスの最初の説明を提供します。

  • f)附属書 A は、SLE システムで処理されるデータのセクション 3 の説明を拡張します。

1.6 定義

このアーキテクチャ モデルは、他のオブジェクトにサービスを提供するポートを介してオブジェクトで構成されます。

  • a) ポートの種類。 さまざまなサービスの提供に関与するポートは、さまざまなタイプであると言われています。
  • b) 対称/非対称ポート。 サービスの提供に関係する (2 つのオブジェクトの) 2 つのポートは、対称ポートまたは非対称ポートのいずれかです。各ポートがサービスに関連付けられたすべての操作を提供する場合、ポートは対称的です。それぞれが異なる操作を提供する場合、ポートは非​​対称です。この場合、1 つのポートはコンシューマと呼ばれ、もう 1 つのポートはサプライヤと呼ばれます。
  • c) サービスのユーザー/プロバイダー。 1 つ以上のポートを使用して別のエンティティにサービスを提供するエンティティは、サービス プロバイダー (プロバイダー) と呼ばれます。もう一方のエンティティは、サービス ユーザー (ユーザー) と呼ばれます。エンティティは、一部のサービスのプロバイダーであり、他のサービスのユーザーである場合があります。

    注 — 「提供する」は、「使用できるようにする」という意味で使用され、必ずしもサービスが使用されていることを意味するものではありません。

  • d) 拘束力。 サービスを提供できるように、同じタイプの 2 つのポート間でアソシエーションが確立されている場合、2 つのポートはバインドされていると言われます。このような関連付けを確立する行為をバインディングと呼びます。
  • e) イニシエーター。 イニシエーターは、別のオブジェクト (レスポンダー) にバインドする要求を発行するオブジェクトです。
  • f) 応答者。 レスポンダは、2 つのオブジェクト間にサービス アソシエーションが存在するように、バインド要求を受信し、(可能であれば) イニシエータとのバインドを完了するオブジェクトです。
  • g) 手術。 操作とは、契約条件内でバインドされたポート ペアを介して、1 つのエンティティ (実行者) が別のエンティティ (実行者) に要求できる手順です。

    ノート

    • 1ユーザー/プロバイダー、サプライヤー/消費者、インボーカー/パフォーマーという用語の関係は、参考文献 [10] で説明されています。
    • 2ユーザーとプロバイダーという用語は、相互作用する 2 つのオブジェクトの役割を区別します。通常、これらの用語は、どのオブジェクト (プロバイダー) が他のオブジェクト (ユーザー) に代わって機能を実行しているかを示すために適用されます。この推奨基準では、2 つのオブジェクトがサービスの提供に関与する場合、スペース リンクに近いオブジェクトがサービスの提供者と見なされ、スペース リンクから遠いオブジェクトがユーザーと見なされます。データフローの方向。
    • 3コンシューマとサプライヤという用語は、それぞれがバインドされた 2 つのオブジェクトの 1 つに接続されている 2 つのポートの役割を区別するために使用されます。この推奨規格では、これらの用語はデータの転送方向を示します。つまり、供給元ポートから消費者ポートへです。
    • 4インボーカーとパフォーマーという用語は、サービスを構成する操作が発生する際の 2 つのオブジェクト間の相互作用を説明するために使用されます。 1 つのオブジェクトが操作を呼び出し、それが別のオブジェクトによって実行されます。ほとんどのサービスでは、コンシューマまたはサプライヤに関係なく、各オブジェクトがいくつかの操作を呼び出し、他の操作を実行します。

  • h) データを返す。 この推奨規格の目的上、リターン データは、宇宙要素から地上要素に送信されるすべてのデータです (テレメトリなど)

  • i) 転送データ。 この推奨規格の目的上、転送データは、地上要素から宇宙要素に送信されるすべてのデータです (例: テレコマンド)

  • j) ユーザーデータ。 この推奨規格の目的上、ユーザー データは、ヘッダーでもトレーラーでもないフィールドに含まれるデータです。

    • 1.7 規約

    1.7.1 スタイル

    この推奨規格内では、各公式ステートメントはそれ自体で段落にあり、サブセクション番号またはサブセクション番号とリスト項目番号の組み合わせによって一意に識別されます。

    1.7.2 注意事項

    注記は、この推奨基準の正式な一部ではありません。それらは正式なステートメントから分離されており、NOTE という言葉で紹介されています。

    注 —これはメモの一例です。

    1.7.3 大文字の使用

    システム コンポーネント、データ ユニット、および参照モデルのその他の要素の名前は、各単語の最初の文字を大文字にして表示されます。

    1.7.4 描画規則

    この参照モデルを示す図では、次の規則が使用されています。

    • a) (抽象的な) オブジェクトのタイプは、角の丸いボックスとして表示されます。タイプ名はボックスの下部に表示され、「タイプ」という単語とコロンが前に付いています。図 1 ～ 2 を参照してください。型名の頭文字は常に大文字です。オブジェクト タイプに関連付けられたポートとサービスもタイプです。図 1-2 —オブジェクト タイプの描画規則
    • b)オブジェクトのインスタンスは、角の丸いボックスとして表示されます。タイプ名は再びボックスの下部に表示されますが、「タイプ」という単語とコロンが前に付いていません。図 1 ～ 3 を参照してください。オブジェクト タイプのインスタンスに関連付けられたポートとサービスもインスタンスです。図 1-3 —オブジェクト インスタンスの描画規則
    • c)図に同じタイプのオブジェクトの 2 つ以上のインスタンスが示されている場合は、タイプ名の後にコロンとインスタンスの名前を付けて、それぞれに名前を付けます。インスタンス名の頭文字は常に小文字です。図 1 ～ 4 を参照してください。
    • d)ポート タイプのインスタンスは、ポートで提供されるサービス インスタンスの名前によって区別されます. 単一のサービスの複数のインスタンスが許可されます.図 1-4 のサービス D のインスタンス 1 と 2 の例を参照してください。図 1-4 —複数のオブジェクト インスタンスの描画規則

    1.8 参考文献

    以下の文書は、この推奨規格のテキストで参照されています。発行の時点で、示されている版は有効でした。すべてのドキュメントは改訂される可能性があり、この推奨標準のユーザーは、以下に示すドキュメントの最新版を適用する可能性を調査することをお勧めします。 CCSDS 事務局は、現在有効な CCSDS 推奨基準の登録簿を維持しています。

    • TM スペース データ リンク プロトコル。宇宙データ システム標準の勧告、CCSDS 132.0-B青い本。第 1 号。ワシントン DC: CCSDS, 2003 年 9 月。
    • TM 同期とチャネル コーディング。宇宙データ システム標準の勧告、CCSDS 131.0-B青い本。第 1 号。ワシントン DC: CCSDS, 2003 年 9 月。
    • AOS スペース データ リンク プロトコル。宇宙データ システム標準の勧告、CCSDS 732.0-B青い本。第 1 号。ワシントン DC: CCSDS, 2003 年 9 月。
    • TC 同期とチャネル コーディング。宇宙データ システム標準の勧告、CCSDS 231.0-B青い本。第 1 号。ワシントン DC: CCSDS, 2003 年 9 月。
    • TC スペース データ リンク プロトコル。宇宙データ システム標準の勧告、CCSDS 232.0-B青い本。第 1 号。ワシントン DC: CCSDS, 2003 年 9 月。
    • スペース パケット プロトコル。宇宙データ システム標準の勧告、CCSDS 133.0-B青い本。第 1 号。ワシントン DC: CCSDS, 2003 年 9 月。
    • CCSDS グローバル宇宙船識別フィールド コード割り当て制御手順。スペース データ システム標準の推奨標準、CCSDS 320.0-B-青い本。第 3 号。ワシントン DC: CCSDS, 2003 年 4 月。
    • CCSDS 出版物マニュアル。 CCSDS レコード、CCSDS A20.0-Y-イエローブック。第 2 号。ワシントン DC: CCSDS, 2005 年 6 月。
    • クロス サポート コンセプト — Part 1: スペース リンク拡張サービス.宇宙データ システム標準、CCSDS 910.3-G-2 に関するレポート。グリーンブック。第 2 号。ワシントン D.C.: CCSDS, 2002 年 4 月。
    • 情報技術 — Open Systems Interconnection — Abstract Syntax Notation One (ASN.l) の仕様。 ISO 8824. 第 2 版. ジュネーブ: ISO, 1990.

    1 INTRODUCTION

    1.1 PURPOSE OF THIS RECOMMENDED STANDARD

    1.1.1 BASELINE AND REFERENCE FOR SLE SERVICE SPECIFICATIONS

    This Recommended Standard defines a Cross Support reference model which provides a common basis for coordinating the development of CCSDS Recommended Standards for Space Link Extension (SLE) service specifications and serves as a reference to maintain the consistency of these Recommended Standards.

    1.1.2 RELATIONSHIP TO SPACE LINK RECOMMENDED STANDARDS

    CCSDS Space Link Recommended Standards (Advanced Orbiting System (AOS), Packet Telemetry, and Telecommand, references [2]-[7]) define formats and protocols for the transfer of data between data sources and sinks on board a space vehicle and data sinks and sources on the ground as shown in figure 1-1. These Space Link protocols are designed to work efficiently in the noisy, high-delay environment of space/ground radio links; so they do not carry information needed to configure and operate the ground systems that link numerous ground stations with the ground sinks and sources of data.

    Figure 1-1—CCSDS Space Mission Data System

    The SLE Recommended Standards complement the CCSDS Space Link Recommended Standards with a range of services that are required to configure, operate, and supervise the ground data systems.

    The SLE Recommended Standards apply to data systems that are able 1) to receive CCSDS Space Link data structures from a spacecraft via a Space Link, or 2) to send CCSDS Space Link data structures to a spacecraft via a Space Link, or 3) to transfer such CCSDS Space Link data structures between ground-based entities.

    The relationship between SLE services and CCSDS Space Link protocols is described in Cross Support Concept — Part 1: Space Link Extension Services, reference [10],

    1.1.3 SLE SERVICES

    SLE services comprise:

    • a) SLE transfer services, which are concerned with the ground part of the data transfer described in 1.1.2. This transfer is either within the ground data system or between the ground data system and the ground data sources/sinks.
    • b) SLE management services, which control the scheduling and provision of SLE transfer services by ground systems.

    1.1.4 SLE SYSTEMS

    Ground systems providing services that comply with the CCSDS Recommended Standards for SLE service specifications are called SLE systems.

    1.1.5 FRAMEWORK FOR SLE SERVICES

    This Recommended Standard provides the framework for definition of SLE service specifications to be used in support of space missions. This framework comprises:

    • a) the identification of an SLE system and of its environment;
    • b) an architectural model of an SLE system including:
      • 1) a functional view;
      • 2) a management view;

    • c) the common characteristics of SLE services and the template for SLE service specifications:

      • 1) each individual SLE service specification expresses its requirement on supporting telecommunication services in a respective quality-of-service clause;
      • 2) it is assumed that the provider and user of a given SLE service ensure that appropriate telecommunication facilities are in place;

    • d) the identification of the SLE transfer services.

    NOTE — In item d), SLE transfer services are identified; however, the complete service specification will be provided in a separate Recommended Standard.

    1.2 SCOPE

    The scope of this Recommended Standard is the definition of all concepts and terms that establish a common basis for coordinating the development of CCSDS Recommended Standards for SLE services specifications. In defining these concepts and terms the following assumptions are made:

    • a) the context is that of a single space mission;
    • b) within this space mission a single spacecraft is considered;
    • c) this spacecraft's telemetry and telecommand are compliant with CCSDS Space Link Recommended Standards;
    • d) all ground end-users (i.e., data sinks or sources) are affiliated with a single mission management entity.

    The following points are not covered by this Recommended Standard:

    • a) Although sharing ground systems between multiple space missions or between multiple spacecraft of the same space mission is not explicitly modeled, this Recommended Standard does not in any way preclude sharing ground systems.
    • b) Ground systems and/or services that are not directly concerned with the transport of data compliant to CCSDS Space Link Recommended Standards are not described. Processing data held within the data fields of Source Packet Protocol Data Units (PDUs) described in CCSDS Packet Telemetry, Telecommand, and AOS Recommended Standards (references [2]-[7]) is outside the scope of this Recommended Standard.
    • c) This reference model assumes that ground communications services are used in conjunction with the SLE services to support a space mission, but does not explicitly model these communications services.

    1.3 APPLICABILITY

    1.3.1 APPLICABILITY OF THIS RECOMMENDED STANDARD

    This Recommended Standard serves as a guideline for the development of compatible Agency standards for SLE systems. Systems embraced by this Recommended Standard include manned and unmanned free-flying spacecraft and space transportation systems. This Recommended Standard is particularly relevant to the SLE systems that are involved in cross support.

    1.3.2 LIMIT OF APPLICABILITY

    This Recommended Standard is neither a specification of, nor a design for, real SLE systems that may be implemented for the control and monitoring of existing or future missions.

    1.4 RATIONALE

    The primary goal of CCSDS is to increase the level of interoperability among Agencies. This Recommended Standard furthers that goal by establishing the basis for a set of SLE services to be used in the area where most cross support activity occurs: between the tracking stations or ground data handling systems of various Agencies and the mission specific components of a mission ground system. Reference [10], Cross Support Concept — Part 1: Space Link Extension Services, provides further discussion of the rationale for this Recommended Standard.

    1.5 DOCUMENT STRUCTURE

    This Recommended Standard is organized as follows:

    • a) Section 1 provides purpose, scope, applicability and rationale of this Recommended Standard and lists the definitions, conventions, and references used throughout the document.
    • b) Section 2 provides the context of cross support, presents the cross support documentation structure, and shows how this Recommended Standard fits into that framework. It expands on the scope of this document to provide an overview.
    • c) Section 3 defines the SLE system environment, data handled by an SLE system, and introduces SLE services.
    • d) Section 4 defines an architectural model for the SLE system. This architectural model comprises two views:
      • 1) A functional view which defines the system concepts, including functions and data, from which the SLE services are derived. In this functional view, the SLE system is decomposed into SLE Functional Groups (SLE-FGs), which implement and augment the ground side of the Space Link protocols described in CCSDS Packet Telemetry, Telecommand, and AOS Recommended Standards (references [2]-[7]).
      • 2) A cross support management view, which defines the management interactions between the entities involved in the provision of SLE services and provides the baseline for the SLE Service Management Specification. In this management view, the SLE system is decomposed into SLE Complexes and the notion of SLE Service Package is introduced.

    • e) Section 5 defines the common characteristics of SLE services, provides the template for SLE transfer services specifications, and provides an initial description of each SLE service including operations and parameters at the corresponding ports.

    • f) Annex A expands upon the description, in section 3, of the data handled in SLE systems.

    1.6 DEFINITIONS

    This Architecture Model is composed of objects with ports, through which they provide services to other objects.

    • a) Port Types. Ports that are involved in providing different services are said to be of different types.
    • b) Symmetric/Asymmetric Ports. Two ports (of two objects) involved in the provision of a service may be either symmetric ports or asymmetric ports. The ports are symmetric if each offers all of the operations associated with the service. The ports are asymmetric if each offers different operations; in this case, one port is called a consumer, and the other is called a supplier.
    • c) Service User/Provider. An entity that offers a service to another by means of one or more of its ports is called a service provider (provider). The other entity is called a service user (user). An entity may be a provider of some services and a user of others.

      NOTE — 'Provide' is used in the sense of 'make available to be used' and does not necessarily imply that the service is being used.

    • d) Binding. When two ports of the same type have an association established between them such that a service can be provided, the two ports are said to be bound. The act of establishing such an association is called binding.
    • e) Initiator. The initiator is the object that issues the request to bind to another object (the responder).
    • f) Responder. The responder is the object that receives a request to bind and completes the binding (if possible) with the initiator in order for a service association to exist between the two objects.
    • g) Operation. An operation is a procedure that one entity (the invoker) can request of another (the performer) through a port pair bound within the terms of an agreement.

      NOTES

      • 1 The relationships among the terms user/provider, supplier/consumer, and invoker/performer are explained in reference [10],
      • 2 The terms user and provider distinguish the roles of two interacting objects. Usually these terms are applied to indicate which object (the provider) is performing a function on behalf of the other object (the user). In this Recommended Standard, when two objects are involved in provision of a service, the object closer to the Space Link is considered to be the provider of the service, and the object further from the Space Link is considered to be the user, regardless of the direction of data flow.
      • 3 The terms consumer and supplier are used to distinguish the roles of two ports, each attached to one of two objects, that are bound. In this Recommended Standard, these terms indicate direction of transfer of data: from the supplier port to the consumer port.
      • 4 The terms invoker and performer are used to describe the interaction between two objects, as the operations that constitute the service occur. One object invokes an operation, which is performed by the other. For most services, each object, whether consumer or supplier, invokes some operations and performs others.

    • h) Return Data. For the purposes of this Recommended Standard, Return Data is all data that is sent from the space element to the ground element (e.g., telemetry).

    • i) Forward Data. For the purposes of this Recommended Standard, Forward Data is all data that is sent from the ground element to the space element (e.g., telecommand).

    • j) User Data. For the purposes of this Recommended Standard, User Data is data contained in a field that is neither a header nor a trailer.

      • 1.7 CONVENTIONS

      1.7.1 STYLE

      Within this Recommended Standard, each formal statement stands in a paragraph by itself and is identified uniquely by a subsection number or by a combination of subsection number and list item number.

      1.7.2 NOTES

      Notes are not formally part of this Recommended Standard. They are isolated from the formal statements and are introduced by the word NOTE.

      NOTE — This is an example of a note.

      1.7.3 USE OF CAPITAL LETTERS

      Names of system components, data units, and other elements of the reference model are shown with the first letter of each word capitalized.

      1.7.4 DRAWING CONVENTIONS

      In figures illustrating this reference model, the following conventions are used.

      • a) A type of (abstract) object is shown as a round-cornered box. The type-name is shown at the bottom of the box, preceded by the word 'Type' and a colon; see figure 1-2. The initial letter of the type-name is always upper case. The ports and services associated with an object type are also types.Figure 1-2—Drawing Conventions for an Object-Type
      • b) An instance of an object is shown as a round-cornered box. The type-name is again shown at the bottom of the box, but is not preceded by the word 'Type' and a colon; see figure 1-3. The ports and services associated with an instance of an object type are also instances.Figure 1-3—Drawing Conventions for an Object-Instance
      • c) If a figure shows two or more instances of the same type of object, each is given a name by showing the type-name followed by a colon and the name of the instance. The initial letter of the instance-name is always lower case. See figure 1-4.
      • d) Instances of a port type are distinguished by the names of the service instances that are provided at the port. Multiple instances of a single service are permitted. See example instances 1 and 2 of service D in figure 1-4.Figure 1-4—Drawing Conventions for Multiple Object-Instances

      1.8 REFERENCES

      The following documents are referenced in the text of this Recommended Standard. At the time of publication, the editions indicated were valid. All documents are subject to revision, and users of this Recommended Standard are encouraged to investigate the possibility of applying the most recent editions of the documents indicated below. The CCSDS Secretariat maintains a register of currently valid CCSDS Recommended Standards.

      • TM Space Data Link Protocol. Recommendation for Space Data System Standards, CCSDS 132.0-B-l. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
      • TM Synchronization and Channel Coding. Recommendation for Space Data System Standards, CCSDS 131.0-B-l. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
      • AOS Space Data Link Protocol. Recommendation for Space Data System Standards, CCSDS 732.0-B-l. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
      • TC Synchronization and Channel Coding. Recommendation for Space Data System Standards, CCSDS 231.0-B-l. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
      • TC Space Data Link Protocol. Recommendation for Space Data System Standards, CCSDS 232.0-B-l. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
      • Space Packet Protocol. Recommendation for Space Data System Standards, CCSDS 133.0-B-l. Blue Book. Issue 1. Washington, D.C.: CCSDS, September 2003.
      • CCSDS Global Spacecraft Identification Field Code Assignment Control Procedures. Recommended Standard for Space Data Systems Standards, CCSDS 320.0-B-3. Blue Book. Issue 3. Washington, D.C.: CCSDS, April 2003.
      • CCSDS Publications Manual. CCSDS Record, CCSDS A20.0-Y-2. Yellow Book. Issue 2. Washington, D.C.: CCSDS, June 2005.
      • Cross Support Concept — Part 1: Space Link Extension Services. Report Concerning Space Data Systems Standards, CCSDS 910.3-G-2. Green Book. Issue 2. Washington, D C.: CCSDS, April 2002.
      • Information technology — Open Systems Interconnection — Specification of Abstract Syntax Notation One (ASN.l). ISO 8824. 2nd ed. Geneva: ISO, 1990.

    ISO PDF プレビュー