この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
3 用語と定義
この文書の目的上、次の用語と定義が適用されます。
3.1 一般用語
3.1.1
指揮能力
名目上のミッションの実行、障害の特定と回復、性能評価、および性能変化やシステム劣化後のシステム保守に必要な、宇宙船に搭載されたすべての機器とソフトウェアを安全に制御および設定する地上の能力
3.1.2
互換性
宇宙セグメントの設計が既存の地上セグメントのインフラストラクチャー（存在する場合）および既存の運用慣行にどの程度準拠しているか
3.1.3
効率
コスト、複雑さ、技術、信頼性を考慮した地上セグメントと宇宙セグメント間のタスクの最適な分散
3.1.4
柔軟性
- 既存のオンボード機能、
- 宇宙と地球の通信リンク、
- 信頼性の目標を達成するために設計に組み込まれた冗長性、
3.1.5
可観測性
宇宙船上の物理的および論理的パラメータに関する運用上重要な情報を取得する機能
注記 1:この情報は、遠隔測定チャネルを通じて地上に配信され、および/または搭載プロセッサーで利用可能になります。
注記 2:観測可能なパラメータの定義は、宇宙船の操作、すべての搭載システムの動作の監視、異常の診断の実行、および地上モデルへのフィードバックに十分な情報の収集にとって重要な要件です。
3.1.6
手術
ミッションコントロールセンターから実行されるアクティビティ
注記 1:宇宙船の運用を定義する詳細については、序文 0.1 を参照してください。
3.1.7
操作性
宇宙船のミッション期間全体にわたって、指定された地上セグメントが宇宙セグメントを運用できるようにする宇宙船自体の機能
注記 1:宇宙船の操作性を定義する詳細については、序文 0.2 を参照。
3.1.8
安全性
故障に対するオンボード保護の範囲とフェールセーフ動作モードの提供
3.1.9
安全
オンボードテレコマンド機能への不正アクセス、テレコマンドチャネルの妨害、またはテレコマンドデータの破損、テレメトリデータへの不正アクセス、またはこれらのデータの破損に対するオンボード保護の範囲
3.1.10
テスト容易性
宇宙船とそのインターフェースの機能、および地上システムとの互換性を検証および検証できる能力と容易さ
注記 1:特に、これは、現在の運用チェーンの一部を形成しない機能 (つまり、冗長機能) に関連します。
3.2 その他の用語
3.2.1
アプリケーションプロセス
テレメトリソースデータの生成とテレコマンドデータの受信が可能なオンボード要素
注記 1:アプリケーション・プロセスは、ソフトウェア、ファームウェア、またはハードウェアで実装できます。アプリケーションプロセス間のマッピングと、宇宙船のサブシステムとペイロードへの通常の機能分割には制限はありません。比較的単純な宇宙船では、多数の「ダム」プラットフォーム サブシステムとペイロードにハウスキーピング データの収集、デバイス コマンドの配布、オンボード スケジューリング、オンボード モニタリングなどを提供する集中アプリケーション プロセスが存在する場合があります。より複雑な宇宙船では、各サブシステムとペイロードが独自の独立したアプリケーション プロセスによって提供される場合があります。特定のプロセッサは、1 つまたは複数のアプリケーション プロセスをホストできます。ただし、特定のアプリケーション プロセスが 2 つ以上のプロセッサに分散される可能性もあります。
3.2.2
自律性
宇宙船が地上介入なしで通常の運用および/または緊急時の運用を処理できる程度
3.2.3
鎖
所定の機能を達成するために一緒に動作するハードウェアおよび/またはソフトウェアユニットのセット
例：
姿勢軌道制御サブシステム (AOCS) プロセッサーとそのソフトウェア、および AOCS センサーとアクチュエーターのセットは、一緒になって AOCS チェーンを構成します。
3.2.4
制御ループ
パラメータまたはパラメータのセットを規定の制限内に維持するためのメカニズム
注記 1:制御ループは通常、関数、アルゴリズム、または一連のルールに従って関連付けられた一連の測定値と応答 (コマンド) で構成されます。
3.2.5
デバイステレコマンド
オンボードハードウェアにルーティングされ、オンボードハードウェアによって実行されるテレコマンド
例：
リレー切り替えテレコマンドまたはオンボードレジスタをロードするテレコマンド。
3.2.6
地上セグメント
ミッション作戦の準備および/または実行に関与するすべての地上施設および人員
3.2.7
高レベルのテレメトリ
オンボードアプリケーションプロセスによって低レベルテレメトリから処理されたテレメトリ
3.2.8
低レベルのテレメトリー
基本的な読み取り可能なオンボード情報
例：
レジスタ読み出しまたはリレーステータス。
3.2.9
メモリー
メイン メモリまたはストレージ メモリ (ディスク、テープ、バブル メモリなど) に関係なく、任意のオンボード メモリ領域
3.2.10
ミッション管理
最小限の地上介入でミッションが高度に自律的に日常業務を遂行できるようにする搭載機能
3.2.11
ミッションマネージャー
システムレベルのミッション管理活動を監督（または実行）する搭載機能
注記 1:将来の自律性の概念では、システム レベルとサブシステム レベルの両方で機能を管理できる分散型オンボード「制御権限」が予見されます。
注記 2:この概念の中で、ミッション管理者は、ミッション目標として表現された地上からの高レベルの指示の実行を監督する。
注記 3:ミッション・マネージャーはすべてのシステム・レベルの機能を実行し、サブシステム (およびペイロード) マネージャーはサブシステム・レベルの機能を実行します。
3.2.12
地面との接触がない
ミッション中にテレコマンド/テレメトリリンクが利用できないために地上連絡が不可能な時間帯
- a)次のような予測可能なイベント:
- 1)テレメトリおよびテレコマンドリンクの無線周波数カバレージと組み合わせた宇宙船の軌道特性による非永続的な可視性。
- 2)宇宙船への時分割アクセス。
b)次のような予測不可能なイベント:
- 1)宇宙船の姿勢のデポインティング。
- 2)テレメトリおよびテレコマンド リンクのオンボード障害。
- 3)地上局の障害/利用不能。
- 4)リンクバジェットの低下。
3.2.13
オンボード障害管理
地上介入なしで車載障害の検出と管理を可能にする車載機能
注記 1: 搭載障害管理の主な目的は、宇宙船の存続を保証することです。
注記 2: 可能であれば、宇宙船に危険を及ぼさず、ミッションの制約内で、搭載された障害管理がペイロードの動作を維持するものとする。
注記 3:さらに、オンボード障害管理は、迅速な診断とその後の最適な動作状態への再構成を支援する必要があります。
3.2.14
オンボードモニタリング
一連のオンボードパラメータに適用される一連の処理関数
注1: これらの関数には、制限/ステータス/デルタのチェック、時間間隔にわたる最小値と最大値を含む統計の評価などが含まれる場合があります。
注記 2:検出されたイベントまたは評価結果は地上に遠隔測定されます。
注記 3:機能の範囲はさらに広くなり、たとえば、検出されたイベントに応答してオンボードアクションをトリガーすることができます。
3.2.15
船上での運行スケジュール
地上から事前にロードされたコマンドを制御および実行する機能
注1:最も単純な形式では、オンボード操作スケジュールは地上からロードされた時間タグ付きコマンドを保存し、オンボード時間に達すると宛先アプリケーション・プロセスにそれらを解放しますが、宛先アプリケーション・プロセスによってフィードバックは生成されません。
3.2.16
船内での操作手順
地上から制御できる簡単な操作手順 (ロード、編集、開始、停止など)、または事前定義されたオンボード イベントの発生によって呼び出すことができます。
注1:最も単純な実装では、操作手順は、歴史的にマクロコマンドと呼ばれる一連の低レベルコマンドで構成されます。
3.2.17
パラメータ
ボード上の基本データ項目
注記 1: パラメータには独自の解釈があります。
3.2.18
パラメータの有効性
特定のテレメトリ パラメータの解釈が意味があるかどうかを決定する条件
例：
ジャイロの角度出力は、ジャイロの電源が「オン」の場合にのみ有効な工学的意味を持ちますが、それ以外の場合、出力はランダムであるか、せいぜい信頼すべきではありません。
注記 1:このようなパラメータは条件付きで有効とみなされ、その有効性は電源ステータスから決定されます。
3.2.19
保護システム
- 機器またはシステムレベルで障害の伝播を防止します。また
- 宇宙船システムまたはサブシステムを「安全な」構成に再構成する
グレード 1 からエントリーまで:その後の分析と復旧作業は通常、地上で実行されます。
3.2.20
スペースセグメント
宇宙空間で運用されるミッションシステム全体の要素
3.2.21
宇宙船
すべてのサブシステム (プラットフォーム、サービス モジュール、またはバスと呼ばれることもあります) と任意の実験要素またはペイロード要素 (ペイロード モジュールと呼ばれることもあります)
3.2.22
宇宙船のステータス
特定の時点での宇宙船の運用状態を評価するために必要なすべての情報
例：
運用上の意思決定を推進するすべての基準を決定するために必要なすべての情報。
3.2.23
サブシステム
明確に定義された、通常は自己完結型の搭載機能セットを満たす、宇宙船プラットフォーム内のユニットの任意の組み合わせ
3.2.24
サバイバルモード
不測の事態（壊滅的または重大な故障、攻撃的な環境など）の場合に宇宙船の損失を回避するために定義された、宇宙船の非運用、一時的および安全寿命モード。
3.2.25
テレコマンドの重要性
オンボード効果の性質と重要性に関するテレコマンドの重要性
注記 1:テレコマンドの重要度レベルは、3.2.25.1 から 3.2.25.4 に定義されているように、レベル A から D に分類されます。
3.2.25.1
レベルA
禁止されたテレコマンド
名目上または予見可能な不測の事態に使用されることが想定されていないテレコマンド。予期せぬ不測の事態に備えて組み込まれており、誤ったタイミングまたは誤った構成で実行された場合に取り返しのつかない損害を引き起こす可能性があるもの
3.2.25.2
レベルB
重要なテレコマンド
誤ったタイミングまたは誤った構成で実行された場合、ミッションに取り返しのつかない損失または損害を引き起こす可能性がある（つまり、ミッションの主な目的の達成が危険にさらされる）テレコマンド。
3.2.25.3
レベルC
重要なテレコマンド
重要な通信コマンドではないが、ミッションの成功には不可欠であり、間違ったタイミングで送信されると、ミッションの一時的な損失を引き起こす可能性がある通信コマンド
3.2.25.4
レベルD
残りのすべてのコマンド
3.2.26
テレコマンド機能
1 つまたは複数の下位レベルの制御アクションを構成または呼び出すことができる、運用上自己完結型の制御アクション
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 General terms
3.1.1
commandability
ability of the ground to safely control and configure all the equipment and software on-board the spacecraft as required for the execution of the nominal mission, for failure identification and recovery, for performance assessment and for system maintenance subsequent to performance change and system degradation
3.1.2
compatibility
extent to which the design of the space segment conforms with the existing ground segment infrastructure (if any) and with existing operational practices
3.1.3
efficiency
optimum distribution of tasks between the ground and space segments taking into account cost, complexity, technology and reliability
3.1.4
flexibility
- existing on-board functions,
- space-Earth communications links,
- any redundancy built into the design in order to meet reliability targets,
3.1.5
observability
ability to acquire operationally significant information for physical and logical parameters on-board the spacecraft
Note 1 to entry: This information is delivered to the ground through the telemetry channel and/or made available to on-board processors.
Note 2 to entry: The definition of observable parameters is a key requirement for operating spacecraft, monitoring the behaviour of all on-board systems, performing diagnosis of anomalies, and collecting sufficient information for feedback into ground-based models.
3.1.6
operation
activity performed from a mission control centre
Note 1 to entry: See the Introduction, 0.1, for further details defining spacecraft operation.
3.1.7
operability
feature of the spacecraft itself that enables a specified ground segment to operate the space segment during the complete mission lifetime of the spacecraft
Note 1 to entry: See the Introduction, 0.2, for further details defining spacecraft operability.
3.1.8
safety
extent of on-board protection against failure and the provision of fail-safe modes of operation
3.1.9
security
extent of on-board protection against unauthorized access to on-board telecommand functions, jamming of the telecommand channel, or corruption of the telecommand data, unauthorized access to telemetry data, or the corruption of these data
3.1.10
testability
capability and ease with which the functions of the spacecraft and its interfaces and compatibility with ground systems can be verified and validated
Note 1 to entry: In particular, this relates to functions that do not form part of the current operational chains (i.e. redundant functions).
3.2 Other terms
3.2.1
application process
on-board element capable of generating telemetry source data and receiving telecommand data
Note 1 to entry: An application process can be implemented in software, firmware, or hardware. There are no restrictions on the mapping between application processes and the usual functional subdivision of a spacecraft into subsystems and payloads. In a relatively simple spacecraft, there can be a centralized application process that provides a number of “dumb” platform subsystems and payloads with collection of housekeeping data, the distribution of device commands, on-board scheduling, on-board monitoring, etc. In a more complex spacecraft, each subsystem and payload might be served by its own independent application process. A given processor can host one or several application processes. However, it is also possible that a given application process could be distributed across two or more processors.
3.2.2
autonomy
extent to which a spacecraft can handle nominal and/or contingency operations without ground intervention
3.2.3
chain
set of hardware and/or software units that operate together to achieve a given function
EXAMPLE:
An attitude and orbit-control-subsystem (AOCS) processor and its software and a set of AOCS sensors and actuators together constitute an AOCS chain.
3.2.4
control loop
mechanisms to maintain a parameter or a set of parameters within prescribed limits
Note 1 to entry: A control loop normally consists of a set of measurements and responses (commands) related according to a function, algorithm, or set of rules.
3.2.5
device telecommand
telecommand that is routed to and executed by on-board hardware
EXAMPLE:
A relay switching telecommand or a telecommand to load an on-board register.
3.2.6
ground segment
all ground facilities and personnel involved in the preparation and/or execution of mission operations
3.2.7
high level telemetry
telemetry processed from the low level telemetry by an on-board application process
3.2.8
low level telemetry
elementary readable on-board information
EXAMPLE:
Register readout or relay status.
3.2.9
memory
any on-board memory area, whether main memory or storage memory, such as disk, tape, or bubble-memory
3.2.10
mission management
on-board functionality that allows a mission to undertake routine operations highly autonomously with the minimum of ground intervention
3.2.11
mission manager
on-board function that supervises (or performs) the system-level mission management activities
Note 1 to entry: Future autonomy concepts foresee a distributed on-board “control authority” that is able to manage functions at both system-level and subsystem-level.
Note 2 to entry: Within this concept, the mission manager supervises the execution of high-level instructions from the ground expressed as mission goals.
Note 3 to entry: The mission manager performs all the system-level functions, while subsystem (and payload) managers perform the subsystem-level functions.
3.2.12
no ground contact
period of time during a mission when ground contact is not possible due to the unavailability of the telecommand/telemetry links
- a) predictable events such as:
- 1) non-permanent visibility due to spacecraft orbit characteristics combined with radio frequency coverage of telemetry and telecommand links;
- 2) time-shared access to the spacecraft;
b) unpredictable events such as:
- 1) spacecraft attitude depointing;
- 2) on-board failure of the telemetry and telecommand links;
- 3) ground station failure/unavailability;
- 4) link budget degradation.
3.2.13
on-board fault management
on-board functionality that allows the detection and management of on-board failures without ground intervention
Note 1 to entry: The primary objective of on-board fault management is to ensure the survival of the spacecraft.
Note 2 to entry: Where possible without hazard to the spacecraft, and within the mission constraints, on-board fault management shall maintain payload operations.
Note 3 to entry: In addition, on-board fault management should assist in rapid diagnosis and subsequent reconfiguration back to an optimal operational status.
3.2.14
on-board monitoring
set of processing functions that is applied to a set of on-board parameters
Note 1 to entry: These functions can include limit/status/delta checking, the evaluation of statistics, including minimum and maximum values over a time interval, etc.
Note 2 to entry: Detected events or evaluation results are telemetred to ground.
Note 3 to entry: The scope of the function can be even wider, e.g. to include the triggering of on-board actions in response to detected events.
3.2.15
on-board operations scheduling
capability for controlling and executing commands that were loaded in advance from the ground
Note 1 to entry: In its simplest form, the on-board operations schedule stores time-tagged commands loaded from the ground and releases them to the destination application process when their on-board time is reached, but with no feedback being generated by the destination application process.
3.2.16
on-board operations procedure
simple operations procedure that can be controlled from the ground (loaded, edited, started, stopped, etc.) or can be invoked by the occurrence of a predefined on-board event
Note 1 to entry: In its simplest implementation, an operations procedure can consist of a sequence of low-level commands, historically referred to as a macrocommand.
3.2.17
parameter
elementary data item on-board
Note 1 to entry: A parameter has a unique interpretation.
3.2.18
parameter validity
conditions that determine whether the interpretation of a given telemetry parameter is meaningful
EXAMPLE:
The angular output of a gyro may only have a valid engineering meaning if the power to the gyro is “on” while at other times, the output may be random, or at best should not be relied upon.
Note 1 to entry: Such a parameter is deemed conditionally valid, with its validity determined from the power status.
3.2.19
protection system
- prevent the propagation of the failure at equipment or system level; or
- reconfigure the spacecraft system or subsystem into a “safe” configuration
Note 1 to entry: Subsequent analysis and recovery action will normally be performed by the ground.
3.2.20
space segment
those elements of the overall mission system that are operated in outer space
3.2.21
spacecraft
all subsystems (sometimes called the platform, the service module or the bus) plus any experiment or payload elements (sometimes called the payload module)
3.2.22
spacecraft status
all the information necessary to assess the operational status of the spacecraft at a given time
EXAMPLE:
All the information needed to determine all the criteria driving operational decisions.
3.2.23
subsystem
any combination of units within the spacecraft platform that fulfils a well-defined and usually self-contained set of on-board functions
3.2.24
survival mode
non-operational, temporary and safe-life mode of a spacecraft, defined to avoid its loss in case of contingency (catastrophic or critical failure, aggressive environment, etc.)
3.2.25
telecommand criticality
importance of a telecommand in terms of the nature and significance of its on-board effect
Note 1 to entry: Telecommand criticality levels are categorized as Levels A to D as defined in 3.2.25.1 to 3.2.25.4.
3.2.25.1
Level A
forbidden telecommand
telecommand that is not expected to be used for nominal or foreseeable contingency operations, that is included for unforeseen contingency operations, and that could cause irreversible damage if executed at the wrong time or in the wrong configuration
3.2.25.2
Level B
critical telecommand
telecommand that, if executed at the wrong time or in the wrong configuration, could cause irreversible loss or damage for the mission (i.e. endanger the achievement of the primary mission objectives)
3.2.25.3
Level C
vital telecommand
telecommand that is not a critical telecommand but is essential to the success of the mission and, if sent at the wrong time, could cause momentary loss of the mission
3.2.25.4
Level D
all the remaining commands
3.2.26
telecommand function
operationally self-contained control action that can comprise or invoke one or more lower level control actions