限定なし

JERG-2-700-TP002-NOTICE1

宇宙機監視制御プロトコル(Spacecraft Monitor and Control Protocol (SMCP))

2019年12月10日 制定

宇宙航空研究開発機構

免責条項
ここに含まれる情報は、一般的な情報提供のみを目的としています。JAXA は、かかる情報の正確性、有用性又は適時性を含め、明示又は黙示に何ら保証するものではありません。また、
JAXA は、かかる情報の利用に関連する損害について、何ら責任を負いません。
Disclaimer
The information contained herein is for general informational purposes only. JAXA makes nowarranty, express or implied, including as to the accuracy, usefulness or timeliness of any
information herein. JAXA will not be liable for any losses relating to the use of the information.

発行〒305-8505 茨城県つくば市千現 2-1-1
宇宙航空研究開発機構 安全・信頼性推進部
JAXA（Japan Aerospace Exploration Agency）

JERG-2-700-TP002-NOTICE1
本書は英語で書かれた草案を日本語に翻訳し、日本の宇宙機関 JAXA により制定された。
本標準は日本語を正とする。ただし、図表の一部で英語表記しかないものについては、それらが正本となる。文章の内容に疑問点がある場合は，日本語及び英語の双方を参照の上，JAXA 安全・信頼性推進部まで連絡をすること。
This document was originally drafted in English, then subsequently translated into Japanese and authorized by theJapanese space agency, JAXA.
The English translation is for reference purposes only, except for some tables and figures that contain English only,in which case they are the original. If there is anything ambiguous about the content of the text, please refer toboth the Japanese version and the English version and contact JAXA Safety and Mission Assurance Department.

JERG-2-700-TP002-NOTICE1Spacecraft Monitor and Control
Protocol (SMCP)

GSTOS 200-1.1
Issue 1.1
31 March 2023

Japan Aerospace Exploration Agency (JAXA)JERG-2-700-TP002-NOTICE1

CONTENTSSPACECRAFT MONITOR AND CONTROL PROTOCOL (SMCP) ........................................................... 10
SPACECRAFT MONITOR AND CONTROL PROTOCOL (SMCP) ............................................................. 2
1.

INTRODUCTION // はじめに.................................................................................................................... 1
1.1. Purpose // 目的....................................................................................................................................... 1
1.2. Scope // 範囲 .......................................................................................................................................... 2
1.3. Applicability // 適用先 .......................................................................................................................... 2
1.4. References // 関連文書 .......................................................................................................................... 3
1.4.1.
Normative References // 引用文書 ................................................................................................ 3
1.4.2.
Informative References // 参考文書 .............................................................................................. 3
1.5. Structure of this document // 本書の構成 ............................................................................................. 4
1.6. Definitions and Notations // 定義及び表記法....................................................................................... 5
1.6.1.
Terms defined in the Open Systems Interconnection (OSI) Basic Reference
Open
Systems Interconnection (OSI) Basic Reference で定義される用語 ............................................................ 5
1.6.2.
Terms defined in the Functional Model of Spacecrafts
Functional Model of Spacecrafts
で定義される用語 ......................................................................................................................................... 5
1.6.3.
Terms defined in this document // 本書で定義される用語.......................................................... 6
1.6.4.
Notations // 表記 ............................................................................................................................ 7
1.7. Verbal forms // 表現形式 ....................................................................................................................... 8
1.8. Conventions // 規則 ............................................................................................................................. 10

2.

OVERVIEW // 概要 ....................................................................................................................................112.1. General // 一般 ..................................................................................................................................... 112.2. Layered Structure // 階層構造 ............................................................................................................. 11
2.3. Overview of the SMCP Functions // SMCP の機能の概要 ................................................................. 122.4. Functional Objects ................................................................................................................................ 13
2.5. Implementation of SMCP Telecommands/Telemetries
SMCP Telecommands/Telemetries の具
現化 14

3.

GENERAL // 一般 ...................................................................................................................................... 16
3.1. Monitor and Control Model // 監視制御モデル ................................................................................. 16
3.2. SMCP Messages .................................................................................................................................... 19
3.3. Common INFORMATION ITEMS // 共通情報項目.......................................................................... 21
3.3.1.
Message Format Version ............................................................................................................... 21
3.3.2.
Functional Object Identifier (FOID) ............................................................................................. 21
3.3.3.
Functional Object Route Group, Upper FOID .............................................................................. 22
3.3.4.
Route (ID) ..................................................................................................................................... 22
3.3.5.
UFORID and Upper FOID mask................................................................................................... 23
3.3.6.
Lower FOID .................................................................................................................................. 25
3.3.7.
Attribute ID ................................................................................................................................... 25
3.3.8.
Telecommand Message ID ............................................................................................................ 26

4.

SMCP TELECOMMAND .......................................................................................................................... 27
4.1. General // 一般 ..................................................................................................................................... 27
4.2. COMMON INFORMATION ITEMS // 共通情報項目 ...................................................................... 28
4.2.1.
General // 一般 ............................................................................................................................. 28
4.2.2.
ACK Request (field)...................................................................................................................... 29
4.2.3.
Message Format Version (field) .................................................................................................... 29ii

JERG-2-700-TP002-NOTICE1
Telecommand Type ID (field) ....................................................................................................... 30
4.2.4.
4.2.5.
Lower FOID field .......................................................................................................................... 30
4.3. ACTION Telecommand ........................................................................................................................ 31
4.3.1.
General // 一般 ............................................................................................................................. 31
4.3.2.
Telecommand Message Header ..................................................................................................... 32
4.3.3.
Operation ID (field)....................................................................................................................... 32
4.3.4.
Parameters and Value Setting Attributes (Parameters and Attribute Values field)......................... 33
4.4. GET Telecommand................................................................................................................................ 34
4.4.4.
General // 一般 ............................................................................................................................. 34
4.4.5.
Telecommand Message Header ..................................................................................................... 35
4.4.6.
Attribute ID (field) ........................................................................................................................ 35
4.5. SET Telecommand ................................................................................................................................ 36
4.5.4.
General // 一般 ............................................................................................................................. 36
4.5.5.
Telecommand Message Header ..................................................................................................... 38
4.5.6.
Attribute ID (field) ........................................................................................................................ 38
4.5.7.
Attribute Values field .................................................................................................................... 39
4.6. MEMORY LOAD Telecommand.......................................................................................................... 40
4.6.4.
General // 一般 ............................................................................................................................. 40
4.6.5.
Telecommand Message Header ..................................................................................................... 41
4.6.6.
StartAddress, Start Address field................................................................................................... 41
4.6.7.
MemoryData, Load Data field....................................................................................................... 42
4.7. MEMORY DUMP Telecommand ......................................................................................................... 43
4.7.4.
General // 一般 ............................................................................................................................. 43
4.7.5.
Telecommand Message Header ..................................................................................................... 44
4.7.6.
NoOfDumps, Number of Additional Dumps field ........................................................................ 45
4.7.7.
StartAddress, Start Address field................................................................................................... 46
4.7.8.
DataLength, Data Length field ...................................................................................................... 47
5.

SMCP TELEMETRY ................................................................................................................................. 48
5.1. General // 一般 ..................................................................................................................................... 48
5.2. COMMON INFORMATION ITEMS // 共通情報項目 ...................................................................... 49
5.2.1.
General // 一般 ............................................................................................................................. 49
5.2.2.
Message Format Version (field) .................................................................................................... 51
5.2.3.
Telemetry Type ID (field).............................................................................................................. 51
5.2.4.
Message Length (field).................................................................................................................. 52
5.2.5.
Lower FOID field .......................................................................................................................... 52
5.2.6.
Variable Part Length Field Flag (field).......................................................................................... 53
5.2.7.
Lower FOID Field Flag (field) ...................................................................................................... 54
5.2.8.
‘Attribute or Alert ID Field Flag’ (field) ....................................................................................... 55
5.2.9.
Variable Part Length (field) ........................................................................................................... 56
5.2.10. Examples / 例 ............................................................................................................................... 57
5.3. VALUE Telemetry ................................................................................................................................. 60
5.3.1.
General // 一般 ............................................................................................................................. 60
5.3.2.
Telemetry Message Header ........................................................................................................... 61
5.3.3.
Attribute ID (field) ........................................................................................................................ 62
5.3.4.
Message Time (field)..................................................................................................................... 63
5.3.5.
Attribute Values field .................................................................................................................... 64
5.3.6.
Attachment field ............................................................................................................................ 65
5.4. NOTIFICATION Telemetry .................................................................................................................. 66
5.4.1.
General // 一般 ............................................................................................................................. 66

iii

JERG-2-700-TP002-NOTICE1
Telemetry Message Header ........................................................................................................... 67
5.4.2.
5.4.3.
Alert ID (field) .............................................................................................................................. 67
5.4.4.
(reserved) ...................................................................................................................................... 68
5.4.5.
Parameters and Value Notifing Attributes (Parameters and Attribute Values field) ...................... 69
5.5. ACK Telemetry ..................................................................................................................................... 70
5.5.1.
General // 一般 ............................................................................................................................. 70
5.5.2.
Telemetry Message Header ........................................................................................................... 71
5.5.3.
Telecommand Message ID field .................................................................................................... 71
5.6. MEMORY DUMP Telemetry ................................................................................................................ 72
5.6.1.
General // 一般 ............................................................................................................................. 72
5.6.2.
Telemetry Message Header ........................................................................................................... 73
5.6.3.
Memory Segment Flags (field)...................................................................................................... 74
5.6.4.
Additional Dump Count (field) ..................................................................................................... 75
5.6.5.
Start Address (field) ...................................................................................................................... 76
5.6.6.
Dump Data field ............................................................................................................................ 76
APPENDIX A.

ACRONYMS // 略語 .......................................................................................................... 77

APPENDIX B.
TELECOMMAND-TELEMETRY
INTERACTIONS(SUPPLEMENT)//TELECOMMAND 対 TELEMETRY 相互作用（参考情報） ...................................................................... 78
B.1. General // 一般 ..................................................................................................................................... 78
B.2. Acknowledgement................................................................................................................................. 78
B.3. ACTION Telecommand ........................................................................................................................ 78
B.3.1.
General // 一般 ............................................................................................................................. 78
B.3.2.
Response with Periodic VALUE Telemetry // Periodic VALUE Telemetry による応答 ............. 78
B.3.3.
Response with VALUE Change Telemetry // VALUE Change Telemetry による応答 ............... 79
B.4. GET Telecommand................................................................................................................................ 80
B.4.1.
General // 一般 ............................................................................................................................. 80
B.4.2.
Response with Response VALUE Telemetry // Response VALUE Telemetry による応答 ......... 80
B.5. SET Telecommand ................................................................................................................................ 80
APPENDIX C.

MANAGED PARAMETERS ............................................................................................. 81

APPENDIX D.

HISTORY OF TERMINOLOGY CHANGES

iv

用語の変更の履歴 ........................ 82

JERG-2-700-TP002-NOTICE1

1.

INTRODUCTION // はじめに

1.1.

PURPOSE // 目的

The purpose of establishing the Spacecraft Monitor
and Control Protocol (SMCP) is to enhance theefficiency for projects to develop (1) artificial
satellites and space probes onboard software, (2)software used on the ground for testing and operationsof spacecrafts and their onboard instruments, and (3)databases that store information on spacecrafts andtheir onboard instruments, in an efficient manner bystandardizing the construction rules for data units andtheir transmission sequences across all the spacecrafts.

Spacecraft Monitor and Control Protocol (SMCP)を制定する目的は、データ単位の構成方法や送信並びを、全ての宇宙機（つまり、人工衛星や宇宙探査機）とその搭載機器で統一する事で、(1) 搭載ソフトウェア、(2) 宇宙機やその搭載機器の地上で試験や運用に用いるソフトウェア、(3) 宇宙機やその搭載機器の情報を格納するデータベース、の開発を projects が効率的に行えるようにする事である。

This protocol assumes that the functions of aspacecraft and its onboard instruments are specified
according to the Functional Model of Spacecrafts(FMS) [A1]. This protocol specifies the method toconstruct data units referred to as SMCP
Telecommands/Telemetries to monitor and control
Functional Objects specified in the FMS by entities
from outside (that is, other Functional Objects and/or
entities outside the spacecraft) using communicationslines.

本プロトコルは、宇宙機やその搭載機器の機能を、Functional Model of Spacecrafts (FMS) [A1] に従って定める事を前提としている。本プロトコル
は、FMS が定める Functional Objects を、外部の構成要素（他の Functional Objects, その宇宙機の外部の構成要素の一方か双方）により通信回線を用 い 監 視 制 御 す る た め に 、 SMCP
Telecommands/Telemetries と称するデータ単位の構成方法を定める。

The layer with which this protocol is concerned islocated above the layer for transferring telemetries andtelecommands over communications lines (e.g. theSpace Packet Protocol [R5]). The protocol data units[A3] defined in this protocol are transferred between aspacecraft and the ground, within a spacecraft, andwithin a ground system, using lower-layertransmission protocols.

本プロトコルの層は、通信回線上でテレメトリとテレコマンドとを伝送するためのプロトコル（Space Packet Protocol [R5] 等）の層の上位に位置する。本プロトコルが定義する protocol data
units [A3] は、下位の伝送プロトコルを用い宇宙
機内、宇宙機－地上間、及び地上システム内で伝送される。

[Note 1] This protocol assumes that typical radio
frequency links used between a spacecraft and theground (that is, those with low data-rates andintermittent connectivity) are used as communicationslines. A variation of this protocol might be developedin future if this protocol is to be used overcommunications media with significantly different
characteristics (e.g. high-speed data buses or sharedmemories).

[注 1] 本プロトコルは、通信回線として宇宙機－地上間で用いる典型的な無線回線（すなわち、データレートが低く、断続的にしか接続されない回線）の使用を前提としている。それ以外の大きく異なる特性（高速データバスや共有メモリ等）を有する通信媒体が用いる場合、本プロトコルの変化形が将来開発されるかもしれない。

1

JERG-2-700-TP002-NOTICE1[Note 2] This protocol can be used on top of any
transport protocols in general. In the cases where theStandard of Communications and Data-HandlingArchitecture (SCDHA) [R1] is used, this protocol isused as the end-to-end protocol on top of the otherstandard protocols as specified in [R1] and [R2].

[注 2] 本プロトコルは、一般的にはさまざまな伝
送 プ ロ ト コ ル の 上 で 使 用 で き る 。 Standard ofCommunications and Data-Handling Architecture（SCDHA）[R1] を用いる場合、本プロトコルは、[R1] と [R2] が定める他の標準プロトコルの上
位のエンドツーエンドプロトコルとして用いる。

The Generic Spacecraft Test and Operations Software(GSTOS) specified in [R3] assumes that the spacecraft
and its onboard instruments follow the FMS and thisprotocol. The formats of individual SMCP
Telecommands/Telemetries which are specified
according to the specifications of this document aresupposed to be stored and managed by the Spacecraft
Information Base 2 (SIB2) [R4].

[R3] が 定 め る Generic Spacecraft Test andOperations Software (GSTOS) は、宇宙機やその搭
載機器が FMS と本プロトコルに従っている事を前提としている。また、本書の仕様に従い定められた個々の SMCP Telecommands/Telemetries のフォーマットは、Spacecraft Information Base 2 (SIB2)[R4] により蓄積、管理する事が想定される。

1.2.

SCOPE // 範囲

This document specifies the SMCP version 2, which
specifies the interface for message exchanges between
a Functional Object and an entity that monitors and/or
controls it.

本書は、Functional Object とこれを監視及び/または制御する構成要素との間のメッセージ交換のイ ン タ フ ェ ー ス を 定 め る も の で あ る SMCP
version 2 を定める。

This document does not specify how these requiremtns
are implemented with hardware or software.

本書は、ハードウェアやソフトウェアによるこれらの要求の具現化は定めない。

1.3.

APPLICABILITY // 適用先

The specifications described in this document apply to
the GSTOS and the software which implements theSIB2.

本書の仕様は、GSTOS と SIB2 を実装するソフト
ウェアとに適用する。

The specifications described in this document apply
also to the spacecrafts and their ground systems for the
projects that adopt the GSTOS and the SIB2.

本書の仕様は、GSTOS と SIB2 の規定を採用した
projects の宇宙機とその地上システムにも適用する。

2

JERG-2-700-TP002-NOTICE1

1.4.

REFERENCES // 関連文書

1.4.1.

Normative References // 引用文書

[A1] JAXA, “Functional Model of Spacecrafts (FMS)”, GSTOS 201-1.1, JERG-2-700-TP001 (NOTICE-1),
March 2020 (March 2023).
[A2] CCSDS, “Time Code Formats”, CCSDS 301.0-B-4, November 2010
[A3] ISO, Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic Model.
International Standard, ISO/IEC 7498-1. 2nd ed., 1994.
1.4.2.

Informative References // 参考文書

[R1] JAXA, “Standard of Communications and Data-Handling Architecture, Part 1: General, Part 5: Onboard
Subnetwork Protocol Architecture, Part 6: Ground Subnetwork Protocol Architecture (SCHDA156)”,SCHDA 110-1.1, JERG-2-400-TP101 (NOTICE-1), May 2019 (November 2019).
[R2] JAXA, “Standard of Communications and Data-Handling Architecture, Part 2: End-to-End Protocol
Architecture (SCHDA2)”, SCHDA 120-1.0, JERG-2-400-TP102, November 2019.
[R3] ISAS/JAXA, “Generic Spacecraft Test and Operations Software (GSTOS), Requirement Specification”,
GSTOS 400, JERG-2-700-TP003, latest issue.
[R4] JAXA, “Definition of Spacecraft Information Base 2 (DSIB2)”, GSTOS 300-1.0, JERG-2-700-TP004,
March 2023.
[R5] CCSDS, “Space Packet Protocol”, CCSDS 133.0, latest issue.
[R6] 通信設計標準, JERG-2-400A, 29 March 2013.
[R7] JAXA, スペースコミュニケーション・エンドツーエンドプロトコル設計標準, JERG-2-403, May
2019.

3

JERG-2-700-TP002-NOTICE1

1.5.

STRUCTURE OF THIS DOCUMENT // 本書の構成

This document is organized as follows.

本書の構成は、以下のようになっている。

Chapter 1 (this chapter) states the purpose, scope,and applicability of the document, and lists thereferences, definitions and notations usedthroughout the document.
Chapter 2 presents an overview of the SMCP.

1 章（本章）は、本書の目的、範囲及び適用先を述べると共に、本書で用いる関連文書、定義、及び表記法を示す。

Chapter 3 specifies the concepts and rules that
apply to both SMCP Telecommand and SMCP
Telemetry.
Chapter 4 specifies the functions and information
items of SMCP Telecommand.

3 章は、SMCP Telecommand と SMCP Telemetry の双方に適用する概念や規則を定める。

Chapter 5 specifies the functions and information
items of SMCP Telemetry.

5 章は、SMCP Telemetry の機能と情報項目とを定める。

Appendix A lists the acronyms used in thisdocument.
Appendix B summarizes information on theinteractions between SMCP Telecommand and
SMCP Telemetry.
Appendix C shows the managed parametes of the
SMCP.

Appendix A は、本書で用いる略語を示す。

Appendix D shows the history of terminology
changes.

2 章は、SMCP を概説する。

4 章は、SMCP Telecommand の機能と情報項目とを定める。

Appendix B は 、 SMCP Telecommand と SMCP
Telemetry の間の相互作用に関する情報を要約する。
Appendix C は、SMCP の managed parametes を示す。
Appendix D は、用語の変更の履歴を示す。

4

JERG-2-700-TP002-NOTICE1

1.6.

DEFINITIONS AND NOTATIONS // 定義及び表記法

1.6.1.

Terms defined in the Open Systems Interconnection (OSI) Basic Reference
Open Systems Interconnection (OSI) Basic Reference で定義される用語
本書は、Open Systems Interconnection（OSI）Basic
Reference [A3] で定義される次の用語を採用する。

This document adopts the following terms defined in
the “Open Systems Interconnection (OSI) Basic
Reference” [A3]:blocking,

blocking

protocol control information (PCI),

protocol control information (PCI)

protocol data unit, andprotocol data unit

segmenting.

segmenting[注] PCI は、データ構造に含まれる通常はヘッダと呼ばれるもので、プロトコル制御情報である。

[Note] PCI is information to control a protocol, and isusually called “header” in the data structure.

1.6.2.

Terms defined in the Functional Model of Spacecrafts
Functional Model of Spacecrafts で定義される用語
本書は、Functional Model of Spacecrafts [A1] で定義される次の用語を採用する。

This document adopts the following terms defined in
the “Functional Model of Spacecrafts” [A1]:alert,

alert

Alert class,

Alert class

Attribute,

Attribute

event,

event

Event class,

Event class

Functional Object,

Functional Object

MemoryDump Operation,

MemoryDump Operation

Memory Functional Object,

Memory Functional Object

MemoryLoad Operation,

MemoryLoad Operation

No Operation (NOP),No Operation (NOP)

Operation,

Operation

Parameter,

Parameter

State Attribute, andState AttributeState Machine.

State Machine

5

JERG-2-700-TP002-NOTICE1
1.6.3.

Terms defined in this document // 本書で定義される用語

The following definitions are used throughout thisdocument.

本書は、次の定義を用いる。

Controller: (see Section 3.1)
An entity that monitors and controls other entities.

Controller: (3.1 項参照)
他の構成要素を監視及び制御する構成要素。

Functional Object Route Group: (see Section 3.3.3)
A group of Functional Objects which share data pathin lower layer protocol (e.g. the logical data path
specified by an APID of the Space Packet Protocol).

Functional Object Route Group: (3.3.3 項参照)
下位層プロトコルのデータパス（例えば、APIDにより指定される Space Packet Protocol の logical
data path）を共有する Functional Objects のグループ。
Functional Object Identifier (FOID): (3.3.2 項参照)
Functional Object の識別子。

Functional Object Identifier (FOID): (see Section
3.3.2)The identifier of a Functional Object.
Lower Functional Object Identifier (Lower FOID):(see Section 3.3.6)
The identifier of a Functional Object within the
Functional Object Route Group which contains the
Functional Object.

Lower Functional Object Identifier (Lower FOID):(3.3.6 項参照)
ある Functional Object の、その Functional Object
を含む Functional Object Route Group 内での識別子。

Lower-Layer Protocol Dependent Scheme: (seeSection 3.1)
A scheme which depends on a lower-layer protocoland exchanges information outside of the SMCP.

Lower-Layer Protocol Dependent Scheme: (3.1 項参照)
下位層プロトコルに依存し、SMCP の外部で情報を交換するスキーム。

Managed Parameter:
A parameter that is required to configure a protocol, isdetermined prior to communications and is shared
between the sending and receiving ends (this term isused in the documents of the CCSDS protocols, e.g.
the Space Packet Protocol [R5]).

Managed Parameter:
プロトコルの構成に必要であり、通信に先立ち決め、送信元と受信元の間で共有されるパラメータ(この用語は Space Packet Protocol [R5] 等 CCSDS
プロトコルの文書で用いられている)。

Monitor: (see Section 3.1)
An entity that monitors other entities but does notcontrol them.

Monitor: (3.1 項参照)
他の構成要素を監視するが制御はしない構成要素。

Project:
A project (see ISO 9000 as an example) that develops
the systems for onboard and ground system forcommunications/data-handling for a spacecraft(s).

Project:
ある宇宙機の搭載及び地上の通信・データハンド
リングシステムを開発するプロジェクト（ISO9000 等参照）。

Route: (see Section 3.3.5)
A route to a Functional Object Route Group via which
SMCP Telecommands/Telemetries are delivered.

Route: (3.3.5 項参照)
SMCP Telecommands/Telemetries を 配 信 す る
Functional Object Route Group までの経路。

SMCP Message: (see Section 3.1)
A data unit transferred between a Controller and a
Target or between a Monitor and a Target.

SMCP Message: (3.1 項参照)
Controller と Target の間、または、Monitor と Targetの間で伝送するデータ単位。

6

JERG-2-700-TP002-NOTICE1
Target: (see Section 3.1)
An entity that is monitored.

Target: (3.1 項参照)
監視される構成要素。

Telecommand Message: (see Section 3.1)
A SMCP Message sent from a Controller to a Target tocontrol the Target.

Telecommand Message: (3.1 項参照)
Target を制御するために、Controller からそのTarget に送信する SMCP Message.

Telemetry Message: (see Section 3.1)
A SMCP Message which is sent from a Target to aControllers and/or Monitors and is used formonitoring.

Telemetry Message: (3.1 項参照)
Target から Controllers と Monitors の幾つかまたは全てに送信され、監視に用いられる SMCP
Message.

Upper Functional Object Identifier (Upper FOID):(see Section 3.3.3)
The identifier of a Functional Object Route Group.

Upper Functional Object Identifier (Upper FOID):(3.3.3 項参照)
Functional Object Route Group の識別子。

Upper Functional Object and Route Identifier(UFORID): / júːèfɚːrɪd / (see Section 3.3.5)

Upper Functional Object and Route Identifier(UFORID): 【ユーフォリッド】(3.3.5 項参照)
Functional Object Route Group とその Functional
Object Route Group への Route との組み合わせを表す識別子。

The identifier to express a combination of a Functional
Object Route Group and a Route to the Functional
Object Route Group.

1.6.4.

Notations // 表記

The following notations are used throughout thisdocument.

次の表記を本書において適用する。

A paragraph that begins with “[Example]” (or“[Example n]”, where n is a positive integer) presents
an example that is aimed to help readers to understandthe specification, and is not a part of the specification.

“[例]”（または“[例 n] ”、n は正の整数）で始まる
段落は、読者の仕様の理解を助けるための例であり、仕様の一部ではない。

A paragraph that begins with “[Rationale]” (or“[Rationale n]”, where n is a positive integer) contains
a rationale for the specification, but is not a part of thespecification.

“[根拠]”（または “[根拠 n]”、n は正の整数）で始まる段落は、仕様の根拠を記したものであり、仕様の一部でない。

A paragraph that begins with “[Note]” (or “[Note n]”,where n is a positive integer) contains an informativenote that is aimed to help readers to understand thespecification, and is not a part of the specification.

“[注]”（または“[注 n]”、n は正の整数）で始まる
段落は、読者の仕様の理解を助けるための付加情報を記したものであり、仕様の一部ではない。

7

JERG-2-700-TP002-NOTICE1

1.7.

VERBAL FORMS // 表現形式

The following conventions apply throughout thisdocument.

本書では以下の決まりに従い記述する。

a) the auxiliary verb ‘shall’ implies mandatory
conditions.

「…こと」「…なければならない」は、必須な仕様示す。

b) the auxiliary verb ‘should’ implies optional but
desirable conditions.

「…べき…」は、任意であるが推奨される仕様を示す。

c) the auxiliary verbs ‘may’ implies optional
conditions.

「…良い…」は、許容される仕様を示す。

d) the auxiliary verb ‘can’ implies capability or
ability to do something.

「…できる…」は、何かをする事が可能な事を示す。

e) the words ‘is’, ‘are’, and ‘will’ imply statements
of fact.

他のパターンの記述は、事実を示す文である。

The words ‘shall’, ‘should’, ‘may’ are highlighted
in red and bold font.

「…なければならない」「…べき…」「…こと」「…良い…」は、読者の仕様の理解の助けのため、赤字・太字で示す。
[注] 本書では、要求事項を電子的に検索しやす「こと」
いように、英文の ‘shall’ の訳語として、を使用している。逆に、‘shall’ の訳語以外では「こと」は使用せず、「事」を用いている。ま「良
た、英文の ‘may’ に対応する訳語として、
い」という当て字を使用している。逆に、‘may’の訳語以外で「良い」は使用していない。

「A, B, 及び C」という表記は、英文の ‘A, B,
and C’ に対応し、「A 及び B 及び C」であることを意味する。
「A, B, または C」という表記は、英文の ‘A,B, or C’ に対応し、「A または B または C」であることを意味する。

8

JERG-2-700-TP002-NOTICE1
When a translation into Japanese is provided, theoriginal English version and its Japanese translation
are given in the left and right sides, respectively, inprinciple, as in this paragraph. In some cases, e.g.
titles of sections and captions of figures/tables, theEnglish and Japanese versions are put in a single line
separated by “//” in this order (“English // Japanese”)
or in separate lines with no delimiter in between(“English [Line-Break] Japanese”).

日本語への翻訳が存在する場合、原則として、
この段落のように、英語を左側に示し、日本語を右側に示す。また、章や図表のタイトル等は、
英語、日本語の順に一行中に // で区切る（「英語 // 日本語」）か、二行に分けて区切り文字なし（「英語 [改行] 日本語」
）で、記述する場合もある。

In the most of cases, the technical terms are nottranslated into Japanese. The English words inalphabet remain as they are in their Japanesetranslation. The forms in alphabet in English, which
distinguish the singular and plural forms remain as
they are in the Japanese version to preserve theinformation of the quantity, although the Japanese
language does not inherently distinguish the singularand plural forms.

多くの場合、技術用語の翻訳は行わず、英単語を維持する。そこで、日本語にもアルファベッ
トが登場する。それらは正本である日本語文中においてもアルファベット表記される。日本語の名詞に単数形、複数形の区別はないが、単複の情報を保つため、日本語文中においても、英語の単数形、複数形の違いはアルファベットでそのまま表記する。

Technical terms are basically highlighted in green
and in some cases in blue. The latter consists ofnames of documents, protocols, widely usedtechnical terms, and those locally used in some
sections (e.g. field names). Note that the headcharacter of an English word in a technical term is
written in the capital letter excluding that in the
widely used technical terms.

技術用語は読者の便のため緑字、場合により青字で示す。後者は、文書名、プロトコル名、広く用いられている技術用語、及び、局所的にしか登場しないもの（フィールド名等）からなる。
ここで、技術用語は、広く用いられているもの
を除き、基本的に大文字始まりの英単語で表記する。

9

JERG-2-700-TP002-NOTICE1

1.8.

CONVENTIONS // 規則

In this document, the following conventions are used
to identify each bit in an N-bit field. The first bit in thefield to be transmitted (i.e., the leftmost part in theassociated diagram, if given) is defined as ‘Bit 0’, thenext bit is defined as ‘Bit 1’, and so on up to ‘Bit N-1’.

本書では、N-bit のフィールドの各ビットを識別するため、次の規則を用いる。フィールドの中で伝送する最初のビット（つまり、図示する場合、図中の最も左側）を‘Bit 0’と定義する。以下、次のビットを‘Bit 1’というように‘Bit N-1’まで定義する。

Figure 1-1: Bit Numbering Convention
Bit 番号付け規則

When a field is used to express a binary value (such asa counter), the Most Significant Bit (MSB) shall be thefirst transmitted bit of the field, i.e., ‘Bit 0’ (see Figure
1-1).

フィールドがバイナリ値（カウンタ等）を表わす
場合、最上位ビット (MSB) はフィールドの最初に伝送するビット、つまり、Figure 1-1 に示す‘Bit0’であること。

In accordance with the standard data-communications
practice, data fields are often grouped into a series ofeight-bit ‘words’. Throughout this document, this unitof an eight-bit word is referred to as an ‘octet’.

標準的なデータ通信の慣例に則り、データフィー
ルドは、しばしば、８ビットワードの連なりにまとめる。本書では、この８ビットワードの単位を‘octet’と称する。

Numbering for octets within a data structure starts with0.

Octets データ内の番号付けは 0 から開始する。

By the CCSDS convention, all ‘spare’ bits shall bealways set to ‘0’.

CCSDS の慣例により、全ての ‘spare’ ビットは、
常に ‘0’ にすること。

In this document, a hexadecimal number is expressedby hexadecimal characters (‘0’-‘9’, ‘A’-‘F’) followed
by a ‘h’ (e.g. 1ABh = 427 in decimal).

本書では、１６進数の数を１６進文字 (‘0’-‘9’,‘A’-‘F’) の後に ‘h’ を記す事で表す (例: 1ABh =427 (１０進数))。

In this document, a binary number is expressed by 本書では、２進数の数を文字 ‘0’ 及び ‘1’ の後characters ‘0’s and ‘1’s followed by a lower-case ‘b’ に ‘b’ (小文字)を記す事で表す (例: 101b = 5 (１０進数))。
(e.g. 101b = 5 in decimal).

10

JERG-2-700-TP002-NOTICE1

2.

OVERVIEW // 概要

2.1.

GENERAL // 一般This chapter provides an overview of the Spacecraft
Monitor and Control Protocol (SMCP) specified in thesubsequent chapters.

本章は、以降の章で定める Spacecraft Monitor andControl Protocol (SMCP) の概要を示す。

In this protocol, data units consisting of telecommandand telemetry are called SMCP Telecommand and
SMCP Telemetry, respectively (see Section 2.5 fordetail). Note that A Telecommand Message and a
Telemetry Message are both called SMCP
Telecommand/Telemetry.

本プロトコルでは、テレコマンド及びテレメトリの内容の構成するデータ単位は、それぞれ、
SMCP Telecommand 及び SMCP Telemetry と呼ばれる (詳細は 2.5 項参照)。ここで、Telecommand
SMCP
Message 及び Telemetry Message は、
何れも、
Telecommand/Telemetry と呼ばれる。

2.2.

LAYERED STRUCTURE // 階層構造

The layer with which this protocol is concerned islocated above the layer for transferring telemetries andtelecommands over communications lines. SMCP
Telecommands/Telemetries are transferred between aspacecraft and the ground, within a spacecraft, andwithin a ground system, using lower-layertransmission protocols.

本プロトコルの層は、通信回線上で、テレコマン
ドとテレメトリとを伝送するプロトコルの層の上位に位置する。SMCP Telecommands/Telemetries
は、下位の伝送プロトコルを用いて、宇宙機－地
上間、宇宙機内、及び地上システム内を伝送される。

Figure 2-1 shows an example of how SMCP
Telecommands/Telemetries handled with this protocol
are transferred, where lower-layer protocols are used.

本 プ ロ ト コ ル が 扱 う SMCP Telecommands/
Telemetries を下位のプロトコルを用い伝送する
例を Figure 2-1 に示す。

[Note] If the Standard of Communications and DataHandling Architecture (SCDHA) [R1] is used, thespecific protocol configuration described in [R1] andthe documents referred to therein are recommended tobe adopted.

[注] Standard of Communications and Data-HandlingArchitecture (SCDHA) [R1] を用いる場合、[R1]とその参照文書とが記すプロトコル構成の採用が推奨される。

11JERG-2-700-TP002-NOTICE1
Onboard Instrument

Onboard Data

Ground Station

Handling Processor

Spacecraft Control
Computer

SMCP

SMCP

Space

Space Packet Protocol

Space Packet Protocol

Space

Packet(Relay)(Relay)PacketSpace-Space-

Space

Space

Space

Space

Wire

Wire

Data

Data

Data

Data

ProtocolProtocol

Link

Link

Transfer

TransferProtocolProtocolProtocolProtocolFigure 2-1: An Example of an End-to-End Protocol Configuration
エンドツーエンドのプロトコル構成例

2.3.

OVERVIEW OF THE SMCP FUNCTIONS // SMCP の機能の概要

The SMCP specifies the communication standard tomonitor the execution status of functions of aspacecraft and its onboard instruments (i.e., the jobs
performed by a spacecraft and onboard instruments
in flight such as observations and experiments) andto control execution of these functions.

SMCP は、宇宙機やその搭載機器の機能（つまり、宇宙機やその搭載機器が軌道上で実施する観測や実験等）の実行状態の監視と、これらの機能の実行制御と、のための通信規約を定める。

This protocol assumes that the functions of aspacecraft and its onboard instruments are specified
according to the Functional Model of Spacecrafts(FMS) [A1], which is necessary for systematic
monitoring and controlling of the functions of aspacecraft and its onboard instruments. The core
concept of this model is a unit called Functional
Object (see Section 2.4). The functions of aspacecraft and its onboard instruments are specified
as a set of Functional Objects.

宇宙機やその搭載機器の機能の系統的な監視制御に必要なため、本プロトコルでは、宇宙機やその搭
載 機 器 の 機 能 を Functional Model of Spacecrafts(FMS) [A1] を用いて定めるものとする。本モデルにおける中心的な概念は、Functional Object (2.4 項参照) と呼ぶ単位である。宇宙機やその搭載機器の機能は、Functional Objects の組み合わせとして定める。

[Note] The definition of the Functional Objects isregistered in the Spacecraft Information Base 2(SIB2) [R4].

[ 注 ] Functional Objects の 定 義 は 、 Spacecraft
Information Base 2 (SIB2) [R4] に登録する。

12

JERG-2-700-TP002-NOTICE1
This protocol enables outside entities to monitor
and/or control Functional Objects. For the purpose,
this protocol specifies a data unit consisting of
telecommand or telemetry to control or monitor
spacecrafts and their onboard instruments (SMCP
Telecommand or SMCP Telemetry, respectively). It
also specifies the sequences of SMCP
Telecommand/Telemetry exchanges, with which thedelivery of SMCP Telecommands/Telemetries canbe verified.

2.4.

本プロトコルは、外部の構成要素による Functional
Objects の監視と制御の一方か双方を実現する。この目的のため、本プロトコルは、宇宙機やその搭載機器を制御や監視するためのテレコマンドまたは
テレメトリを構成するデータ単位（それぞれ、
SMCP Telecommand または SMCP Telemetry）を定める。さらに、SMCP Telecommands/Telemetries の配 信 を 検 証 で き る よ う に 、 SMCP
Telecommand/Telemetry の交換の並びも定める。

FUNCTIONAL OBJECTSThis sub-section provides an overview of the
FMS. For the exact definition of the FMS, refer to[A1].

本項では、FMS の概要を説明する。FMS の正確な定義については、[A1] を参照の事。

The functions that a spacecraft or onboard
instrument has are generally complex. Hence,
they are usually specified as groups of functions,each of which consists of functions closely related
to one another. An entity which has a group offunctions of this kind is called a Functional Object
in the FMS.

一般に宇宙機または搭載機器の機能は複雑である。
そこで、通常はお互いに密接に関連した機能からなる機能のグループを定める。このような一群の機能をもつ構成要素を、FMS では Functional Object と呼ぶ。

An entire spacecraft is a Functional Object. Anygroup of functions of arbitrary granularity such as
subsystems, onboard instruments, and onboard
software functions are regarded as Functional
Objects depending upon the design of thespacecraft.

宇宙機全体は、Functional Object である。また、宇宙機の設計に応じ、そのサブシステム、搭載
機器、搭載ソフトウェアの持つ機能など任意の粒度の機能の塊が Functional Object とみなされる。

The entities that constitute a Functional Object ismodeled with concepts, Attributes, Operations,
Event classes, Behaviors, and Diagnostic Rules,
and others. They are briefly explained as follows.

Functional Object は 、 Attributes, Operations, Eventclasses, Behaviors, 及び Diagnostic Rules という概念と、その他とによりモデル化される。以下に、これらを概説する。

An Attribute of a Functional Object is a parameter
representing a status of the Functional Object.
Outside entities (other Functional Objects
onboard the spacecraft and/or entities outside thespacecraft) can obtain the values of Attributes of
the Functional Object at a given time. The valuesof some Attributes can be set by an entity outside
by invoking (a series of) Operations (see below).

Functional Object の Attribute は、Functional Object の状態を表すパラメータである。ある時刻における
Functional Object の Attributes の値は、外部の構成要素（その宇宙機上の他の Functional Objects とその宇宙機の外部の構成要素のうち一方か双方）により取得できる。Attributes によっては、(一連の) Operations(以下参照) を呼び出す事で、外部の構成要素から、その値を設定できる。

An Operation of a Functional Object is an action
performed by the Functional Object and is
invoked from the outside.

Functional Object の Operation は、Functional Object が行う動作であり、外部より呼び出す。

13

JERG-2-700-TP002-NOTICE1
An event of a Functional Object is an occurrenceof a thing that has a particular significance. An
event is detected by the Functional Object itself.
An event that is important to outside entities andis classified as an Event class can be reported tothem, and a classification of the report is called an
Alert class.

Functional Object の event は、特定の意味を有する出来事の発生である。event は、Functional Object 自体が検出する。外部の構成要素にとり重要であり Eventclass に分類される event を、それらに通知する事ができる。この通知の分類を Alert class と呼ぶ。

A Behavior of a Functional Object describes rules
about correct actions taken by the Functional
Object, and is used to determine whether
sequences of Operations are correct or not andwhether Attributes are valid or not, etc. A
Behavior of a Functional Object can be specified
with a set of State Machines.

Functional Object の Behavior は、Functional Object の動作の規則を記すものであり、Operations の並びが正しいか否かや、Attributes の値が有効であるか否か等、を決めるのに用いる。Functional Object の Behavior
は、State Machines の組により定める事ができる。

A Diagnostic Rule of a Functional Object is a ruleused by outside entities to determine whether the
Functional Object is functioning correctly or not.

Functional Object の Diagnostic Rule は 、 Functional
Object が正しく機能しているか否かを判断するための規則であり、外部の構成要素が用いる。

Functional Objects communicate with entities
outside. The methods for the communications
between Functional Objects and entities outside
are not specified by the FMS.

Functional Objects は、外部の構成要素と通信する。しかし、Functional Objects と外部の構成要素との間の通信の仕方は、FMS では定めない。

The SMCP specifies the methods to monitor andto control Functional Objects, in which thefollowing items are repeated via communicationslines:

SMCP は、Functional Objects の監視の方法と制御の方法とを定める。SMCP では、以下の項目が、通信回線を通じ繰り返される。

a) to invoke an Operation of a Functional Object
from an entity outside,a) Functional Object の Operation の外部の構成要素よb) to report the values of Attributes of a
Functional Object to entities outside, andb) Functional Object の Attributes の値の外部の構成要c) to report an important event classified as an
Event class to entities outside.

c) Event class に分類される重要な event の外部の構成

2.5.

る呼び出し

素への通知

要素への通知IMPLEMENTATION OF SMCP TELECOMMANDS/TELEMETRIESSMCP TELECOMMANDS/TELEMETRIES の具現化

Most of the information items related to a SMCP
Telecommand and SMCP Telemetry are transferred ona protocol data unit [A3] called Telecommand
Message and Telemetry Message, respectively (seeSection 3.1). In the following, a Telecommand
Message and Telemetry Message are both called a
SMCP Message.

14

SMCP Telecommand 及び SMCP Telemetry に関連する情報項目の大部分は、それぞれ、
Telecommand Message 及び Telemetry Message と呼ばれる protocol data unit [A3] により伝送する(3.1 項参照)。以下では、Telecommand Message とTelemetry Message を、何れも、SMCP Message と呼ぶ。

JERG-2-700-TP002-NOTICE1
This document specifies the types of SMCP
Telecommands and SMCP Telemetries, and the typesof the SMCP Messages associated with them.

本 書 で は 、 SMCP Telecommands と SMCP
Telemetries の種類並びに、これら二つに対応する
SMCP Messages の種類を定める。

Not all of the information related to an SMCP
Telecommand/Telemetry is included in thecorresponding SMCP Message. The information
which is not included in SMCP Messages (seeSections 4.2.1 and 5.2.1) is transferred in a scheme
which depends on a lower-layer protocol outside of the
SMCP. Note that a scheme which depends on a lowerlayer protocol and exchanges information outside of
the SMCP is called a Lower-Layer Protocol
Dependent Scheme (see Section 3.1). Some LowerLayer Protocol Dependent Schemes use fields in the
protocol control information (PCI) [A3] of a protocol
data unit that transfers SMCP Messages. For example,
the Lower-Layer Protocol Dependent Scheme
described in [R2] uses fields in the Primary Header ofa Space Packet to transfer some of the information.

SMCP Telecommand/Telemetry に関連する情報は、対応する SMCP Message に全ては含まれてはいない。SMCP Messages に含まれていない情報（4.2.1 項及び 5.2.1 項参照）は、SMCP の外部で、下位層プロトコルに依存した方法で伝送する。ここで、下位層プロトコルに依存し、SMCP の外部で 情 報 を 交 換 す る ス キ ー ム を Lower-Layer
Protocol Dependent Scheme と呼ばれる（3.1 項参照）。Lower-Layer Protocol Dependent Scheme の中には、SMCP Messages を送る protocol data unit のprotocol control information (PCI) [A3] のフィールドを用いるものがある。例えば、[R2] が記す
Lower-Layer Protocol Dependent Scheme は、一部の情報の伝送に、Space Packet の Primary Headerのフィールドを用いる。

[Note 1] The formats of individual SMCP Messages
are registered in the SIB2.

[注 1] 個々の SMCP Messages のフォーマットは、
SIB2 に登録する。

[Note 2] If a communications protocol (such as theSpace Packet Protocol [R5]) is used to transfer SMCP
Messages, the SMCP Messages are contained in theuser data area of the packets.

[注 2] SMCP Messages の伝送に通信プロトコル（Space Packet protocol [R5] 等）を用いる場合、
SMCP Messages はパケットのユーザデータ領域に格納する。

[Note 3] If a shared memory is used to transfer SMCP
Messages, different SMCP Messages are written intoand read from separate memory addresses. The
memory addresses used to deliver SMCP Messages
are again registered in the SIB2 in this case.

[注 3] 共有メモリを用い SMCP Messages を伝送する場合、異なる SMCP Messages を異なるメモ
リアドレスに書き込み、異なるメモリアドレスから読み込む。この場合、SMCP Messages の配信に用いるメモリアドレスは SIB2 に登録する。

[Note 4] The current version of the SIB2 does notsupport use of a shared memory to transfer SMCP
Messages.

[注 4] 現バージョンの SIB2 は、SMCP Messagesの伝送において共有メモリの使用はサポートし
ていない。

15

JERG-2-700-TP002-NOTICE1

3.

GENERAL // 一般

3.1.

MONITOR AND CONTROL MODEL // 監視制御モデル

In the Spacecraft Monitor and Control Protocol(SMCP), an entity that controls and monitors otherentities is referred to as a Controller and that monitors
other entities but does not control them is referred toas a Monitor. An entity that is monitored is referred toas a Target.

Spacecraft Monitor and Control Protocol (SMCP)
では、他の構成要素を制御及び監視する構成要素
を Controller と称し、他の構成要素は監視するが制御はしない構成要素を Monitor と称する。
また、監視される構成要素を Target と称する。

The SMCP is used by a Controller to monitor andcontrol a Target and by a Monitor to monitor a Target(see Figure 3-1). The SMCP assumes that a Target ismodeled as a Functional Object specified by the
Functional Model of Spacecrafts (FMS) [A1].

SMCP は、Controller が Target を監視制御するのに用いると共に、Monitor が Target を監視するのに使う（Figure 3-1 参照）。SMCP は、Target を、
Functional Model of Spacecrafts (FMS) [A1] が定めた Functional Object としてモデル化する事を前提とする。

Telecommand
Telemetry

Controller

Target(Functional
Object)Telemetry

MonitorFigure 3-1: Monitor and Control Model
監視制御モデルA Controller sends data units referred to as SMCP
Telecommands to a Target to control it. The Target
sends data units referred to as SMCP Telemetries backto the Controller so that the Controller can monitor theTarget. A Target also sends SMCP Telemetries to
Monitors so that Monitors can monitor the Target. In
the following, a SMCP Telecommand and SMCP
Telemetry are both referred to as a SMCP
Telecommand/Telemetry.

16

Controller は、Target に SMCP Telecommands と称するデータ単位を送り、制御する。Target は、Controller がその Target を監視できるように、
SMCP Telemetries と 称 す る デ ー タ 単 位 を そ のController に返送する。また Target は、Monitors がTarget を監視できるように、SMCP Telemetries を、
Monitors にも送る。以下では、SMCP Telecommand
及 び
SMCP Telemetry
を 、 SMCP
Telecommand/Telemetry と総称する。

JERG-2-700-TP002-NOTICE1[Note 1] Typical Controllers include spacecraft control(or test) systems on the ground, onboard telecommandand data handling computers, onboard attitude control
computers, and onboard payload (or mission) dataprocessors.

[注 1] 典型的な Controllers には、地上の宇宙機制御（または試験）システム、宇宙機搭載のテレコ
マンド・データハンドリングコンピュータ、宇宙機搭載の姿勢制御コンピュータ、及び宇宙機搭載のペイロード（またはミッション）データプロセッサなどがある。

[Note 2] Although this protocol assumes that Targets
are instruments or sub-systems onboard a spacecraft,
it is not a universal assumption. In general, anything(e.g. ground support equipment, ground stationequipment) can be a Target, as long as it is modeled asa Functional Object.

[注 2] 本プロトコルは、Targets が宇宙機に搭載された機器かサブシステムかである事を前提としているが、これは普遍的な前提ではない。より一般的には、Functional Object としてモデル化されている限り何でも（地上支援装置、地上局装置
等）Target と見なす事ができる。

If both the sender and receiver of a SMCP
Telecommand/Telemetry are instruments or subsystems onboard a spacecraft, it is not clear which side
is a Controller, nor whether the SMCP
Telecommand/Telemetry is a SMCP Telemetry or
SMCP Telecommand by definition. However, even inthat case, if SMCP Telecommands/Telemetries aretransferred regularly in a fixed direction (e.g. timecode or ancillary data), they should be recognized as
SMCP Telemetries. If not, the criteria whether a SMCP
Telecommand/Telemetry is a SMCP Telemetry or
SMCP Telecommand shall be determined in eachproject (see Section 1.6.3).

SMCP Telecommand/Telemetry の送信側と受信側の双方が宇宙機に搭載された機器かサブシステ
ムの場合、その何れが Controller であるか、また、そ の SMCP Telecommand/Telemetry が SMCP
Telemetry か SMCP Telecommand の何れなのか、
定義上、明確でない。しかし、その場合でも、固定されたある一方向で繰り返し伝送する SMCP
Telecommands/Telemetries（タイムコードや補助データ等）は、SMCP Telemetries として認識すべきで あ る 。 そ う で な い 場 合 は 、 あ る SMCP
Telecommand/Telemetry が 、 SMCP Telemetry か
SMCP Telecommand かの基準は、project (1.6.3 項参照) 毎に決めること。

[Note 3] The specification in the previous paragraph iscompatible with the recommendation in Section
4.3.2.1.1 of [R7].

[注 3] 前段落の仕様は、[R7] の 4.3.2.1.1 項の推奨と互換性がある。

Most of the information items related to a SMCP
Telecommand and SMCP Telemetry are transferred ona protocol data unit [A3] referred to as Telecommand
Message and Telemetry Message, respectively. In thefollowing, a Telecommand Message and Telemetry
Message is generally referred to as a SMCP message.

SMCP Telecommand 及び SMCP Telemetry に関連する情報項目の大部分は、それぞれ、
Telecommand Message 及び Telemetry Message と称する protocol data unit [A3] により伝送する。以下 で は 、 Telecommand Message 及 び Telemetry
Message を SMCP Message と総称する。

The other information items related to SMCP
Telecommands/Telemetries (see Sections 4.2.1 and5.2.1) are transferred in a scheme which depends on alower-layer protocol outside of the SMCP. Note that ascheme which depends on a lower-layer protocol andexchanges information outside of the SMCP isreferred to as a Lower-Layer Protocol Dependent
Scheme. Some Lower-Layer Protocol Dependent
Schemes define the method to transfer it using fields
in the protocol control information (PCI) [A3] of a
protocol data unit which contains the SMCP Message(e.g. Space Packet [R5]).

SMCP Telecommands/Telemetries に関連する他の情報項目（4.2.1 項及び 5.2.1 項参照）は、SMCPの外部で、下位層プロトコルに依存した方法で伝送する。ここで、下位層プロトコルに依存し、SMCP の 外 部 で 情 報 を 交 換 す る ス キ ー ム をLower-Layer Protocol Dependent Scheme と称する。
Lower-Layer Protocol Dependent Scheme の中には、これを送る方法を、SMCP Message を含む protocol
data unit（Space Packet [R5] 等）の protocol control
information (PCI) [A3] のフィールドを用いて定義するものがある。

17

JERG-2-700-TP002-NOTICE1
A Controller monitors and controls one or more
Targets. Targets are identified with Functional Object
Identifiers (FOIDs) (see Section 3.3.2).

Controller は、一つ以上の Targets を監視及び制御
す る 。 Targets は 、 Functional Object Identifiers(FOIDs) (3.3.2 項参照) で識別する。

In general, multiple Controllers monitor and control
multiple Targets and multiple Monitors monitor
multiple Targets. Controllers shall be identified withthe functions of the lower-layer protocol. If multiple
Controllers are used to control a Target, the control bythese Controllers shall be coordinated in a LowerLayer Protocol Dependent Scheme. This protocol does
not specify the method to do it. If multiple Controllers
and Monitors are used to monitor a Target
simultaneously, SMCP Telemetries shall be delivered
to all the relevant Controllers and Monitors. Functionsof the lower-layer protocol are usually used to specify
the destination of the delivery.

一般的には、複数の Controllers が複数の Targetsを監視及び制御し、複数の Monitors が複数のTargets を監視する。Controllers は、下位層のプロ
トコルの機能で識別すること。一つの Target を制御するのに複数の Controllers を用いる場合、これら の Controllers に よ る 制 御 は Lower-Layer
Protocol Dependent Scheme により調整すること。
その方法は、本プロトコルでは定めない。同時に複数の Controllers と Monitors を用い一つの Target
を監視する場合、関係する全ての Controllers とMonitors に、SMCP Telemetries を配信すること。
この配信先の指定には、通常、下位層プロトコルの機能を用いる。

18

JERG-2-700-TP002-NOTICE1

3.2.

SMCP MESSAGESSMCP message は、Message Header 及び Message
Body と称する二つの部分で構成すること（Figure
3-2 のフォーマットを参照）。

A SMCP Message shall consist of two parts referred
to as a Message Header and a Message Body (see theformat in Figure 3-2).

Message Header

Message Body

Figure 3-2: Basic format of a SMCP Message
SMCP Messages の基本フォーマット
[Note 1] The two different formats are defined for the
Message Header: Telecommand Message Header(used for Telecommand Messages) and Telemetry
Message Header (used for Telemetry Messages). Their
formats are specified in Sections 4.2 and 5.2,
respectively.

[注 1] Message Header には、Telecommand Message
Header（Telecommand Messages 用）と Telemetry
Message Header（Telemetry Messages 用）の二つの異なるフォーマットが定義されている。これらのフォーマットは、それぞれ、4.2 項及び 5.2 項で定める。

[Note 2] The formats of the Message Body depend on
types of SMCP Messages and are specified in
Chapters 4 and 5.

[注 2] Message Body のフォーマットは、SMCP
Messages のタイプに依存し、4 章及び 5 章で定める。

Telecommand Messages and Telemetry Messages
shall be distinguished in a Lower-Layer Protocol
Dependent Scheme.

Telecommand Messages と Telemetry Messages は、
Lower-Layer Protocol Dependent Scheme により区別すること。

[Example] [R2] specifies that the Packet Type field in
the Primary Header of a Space Packet which contains
a SMCP Message is used for the distinguishment if thelower-layer protocol is the Space Packet Protocol.

[例] [R2] は、下位層プロトコルが Space Packet
Protocol の場合、その区別に、SMCP Message を含む Space Packet の Primary Header の Packet Type
フィールドを用いる事を定めている。

There are two format versions for Telemetry Messages
referred to as Msg-Format Versions. The originalformats of Telemetry Messages (Msg-Format Ver.1)
are specified in the SMCP version 1. In addition, ashortened format (Msg-Format Ver.2) is introduced in
the SMCP version 2. Under the SMCP version 2, MsgFormat Ver.1 remains still valid.

Telemetry Messages には、Msg-Format Versions と称する二つのフォーマットバージョンがある。
Telemetry Messages の当初のフォーマット (MsgFormat Ver.1) は、
SMCP version 1 にて定められた。
これに加え、短縮された フォーマット (MsgFormat Ver.2) が、
SMCP version 2 にて導入された。
SMCP version 2 では、Msg-Format Ver.1 が依然有効である。

Msg-Format Ver.2 is recommended to use because it
minimizes overhead by the telemetry header, which is
not negligible if the telemetry band width is limited.

帯域が細い場合、テレメトリヘッダによるオーバ
ヘッドが無視できない。これを最小化するため、
Msg-Format Ver.2 の使用が推奨される。

19

JERG-2-700-TP002-NOTICE1
Msg-Format Ver.2 can describe most of theinformation that can be described with Msg-Format
Ver.1. However, Msg-Format Ver.2 cannot describe
the length of a Telemetry Message if it is longer thanroughly 8000h octets, whereas Msg-Format Ver.1 can.

Msg-Format Ver.2 を用いると、Msg-Format Ver.1 で記述できる情報のほとんどを記述できる。ただし
Msg-Format Ver.2 では、(Msg-Format Ver.1 では可能な) 約 8000h octets を超える Telemetry Messageの長さを記述できない。

Each project (see Section 1.6.3) shall determine thepolicy of the method to select the Msg-Format Version
for Telemetry Messages.

各 project (1.6.3 項参照) は、Telemetry Messages に対して、Msg-Format Version の選び方の方針を決めること。

The convention specified in Section 1.8 shall beapplied to the fields in not only the Message Header
but also the Message Body.

1.8 項で定めた規則は、Message Header に加え、Message Body 内のフィールドにも適用すること。

[Note 3] The encoding rules for the fields in the
Message Body are registered in the Spacecraft
Information Base 2 (SIB2) [R4], as described in
Chapters 4 and 5.

[注 3] Message Body のフィールドのエンコーディ
ング規則は、4 章及び 5 章に記すように、Spacecraft
Information Base 2 (SIB2) [R4] に登録する。

20

JERG-2-700-TP002-NOTICE1

3.3.

COMMON INFORMATION ITEMS // 共通情報項目
以下の情報項目は、SMCP Telecommand と SMCP
Telemetry の双方に関連する。

The following information items are related to both the
SMCP Telecommand and SMCP Telemetry.
a)
b)
c)
d)
e)
f)
g)
h)

3.3.1.

Message Format Version,
Functional Object Identifier (FOID),
Functional Object Route Group, Upper FOID,
Route Identifier (Route ID),
Upper Functional Object and Route Identifier (UFORID) and Upper FOID mask,
Lower FOID,
Attribute Identifier (Attribute ID), andTelecommand Message Identifier (Telecommand Message ID).

Message Format Version

The value of a Message Format Version shall be theidentifier of the Msg-Format Version of the SMCP
Message. In this version of the SMCP, the value of a
Message Format Version shall be either 1 (MsgFormat Ver.1) or 2 (Msg-Format Ver.2).

Message Format Version の値は、SMCP Message のMsg-Format Version の識別子であること。本書のSMCP のバージョンでは、Message Format Versionの値は、1 (Msg-Format Ver.1) か 2 (Msg-Format
Ver.2) かの何れかであること。

[Note] Msg-Format Ver.2 is only defined for SMCP
Telemetry.

[注] Msg-Format Ver.2 は、SMCP Telemetry にのみ定義される。

3.3.2.

Functional Object Identifier (FOID)

A Functional Objects that receive SMCP
Telecommands or generate SMCP Telemetries shallhave an identifier which is referred to as a Functional
Object Identifier (FOID).

SMCP Telecommands を受信か SMCP Telemetries
を生成かをする Functional Objects は、Functional
Object Identifier (FOID) と称する識別子を持つこと。

The FOIDs shall be unique within the entire
spacecraft.

FOIDs は、その宇宙機全体内で一意に決まること。

A FOID shall be a 16-bit integer.

FOID は、16-bit の整数であること。

21

JERG-2-700-TP002-NOTICE1
3.3.3.

Functional Object Route Group, Upper FOID

A group of Functional Objects which share data pathin lower layer protocol (e.g. the logical data path
specified by an APID of the Space Packet Protocol[R5]) is referred to as a Functional Object RouteGroup.

下位層プロトコルのデータパス（例えば、APIDにより指定される Space Packet Protocol の logical
data path [R5]）を共有する Functional Objects のグ
ループを、Functional Object Route Group と称する。

A Functional Object Route Group shall be hosted in
one onboard Node. For example, the Functional
Object Route Group can consist of a parent Functional
Object and its child Functional Objects.

Functional Object Route Group は、一つの宇宙機搭
載 Node でホストすること。例えば、Functional
Object Route Group は、親 Functional Object とその子 Functional Objects とから構成する事ができる。

The upper 8-bit part of a FOID is referred to as an
Upper Functional Object Identifier (Upper FOID).

FOID の上位 8-bit 部分を、Upper Functional Object
Identifier (Upper FOID) と称する。

The Upper FOID shall be the identifier assigned to a
Functional Object Route Group for an entire
spacecraft (i.e., global identifier).

Upper FOID は、Functional Object Route Group に割り当てられた宇宙機全体での識別子（つまり、グローバル識別子）であること。

3.3.4.

Route (ID)A route to/from a Functional Object Route Group via
which SMCP Telecommands/Telemetries aretransferred is referred to as a Route.

SMCP Telecommands/Telemetries を 伝 送 す る
Functional Object Route Group まで・からの経路をRoute と称する。

A Route to/from a Functional Object Route Groupshall have an identifier which is referred to as a Route
Identifier (Route ID).

ある Functional Object Route Group まで・からのRoute は、Route Identifier (Route ID) と称する識別
子を持つこと。

The Route IDs shall be unique within the Functional
Object Route Group.

Route IDs は、その Functional Object Route Group内で一意に決まること。

The number of bits for the Route ID (referred to as nin this section) shall be determined for one or more
Functional Object Route Groups and shall be in therange of 0-4 bits.

Route ID のビット数 (本項では n と表記する)は、一つか複数の Functional Object Route Groups
に対して決めること。また、0-4 bits の範囲内にすること。

The number of Routes between a Controller and a
Functional Object Route Group shall not be greaterthan 2n.

ある Controller と Functional Object Route Group の間の Routes の数は、2n 個を超えないこと。

For a Functional Object Route Group with theparameter n greater than 1, the least significant n bitsof the Upper FOID shall be 0 (accordingly, theallowed value for the Upper FOID is given by 2n×i,
where an integer i is in the range between 0 and 2(16-n)1).

1 より大きいパラメータ n を有する Functional
Object Route Group については、Upper FOID の最Upper FOID
下位 n bits は 0 とすること (すなわち、(16-n)-1 の範囲の整数 i をに許される値は 0 から 2
用いて、2n×i と表される)。

22

JERG-2-700-TP002-NOTICE1
3.3.5.

UFORID and Upper FOID mask

The sum of an Upper FOID and Route ID is referred
to as an UFORID (Upper Functional Object and Route
Identifier). Here, the UFORID is an 8-bit integer. The
Upper FOID and the Route ID can be extracted fromthe UFORID.

Upper FOID と Route ID の合計を、UFORID (Upper
Functional Object and Route Identifier) と称する。
ここで、UFORID は、8-bit の整数である。Upper
FOID と Route ID は、UFORID から抽出する事ができる。

In order to extract the Upper FOID from an UFORID,
the integer referred to as an Upper FOID mask is
specified for each Upper FOID. The Upper FOID
mask shall be an 8-bit integer and all of the binary bits
shall be 1 except for the least significant n bits, all ofwhich are 0.

UFORID から Upper FOID を抽出するため、Upper
FOID mask と称する整数を各 Upper FOID に対し定める。Upper FOID mask は、8-bit の整数であり、0 である最下位 n bits を除き、全ビット 1 である
こと。

8bits
UFORID=
Upper FOIDxxxx
all bits 0+
Route ID
xxxx

UFORID =Upper FOID + Route ID

Upper FOID =UFORID & Upper FOID mask

0-4 bits
Upper FOID mask
all bits 1
all bits 0

Figure 3-3: UFORID, Upper FOID, Route ID, Upper FOID mask
[Note] Whereas the value of a Lower FOID is held ina field of a Message Header (see Sections 4.2.1 and5.2.1), neither Upper FOID nor Route ID is containedin the data structure defined by the SMCP. The valueof an UFORID is transferred in a Lower-Layer
Protocol Dependent Scheme, where a lower-layer
protocol is used (see Sections 4.2.1 and 5.2.1).

[注] Lower FOID の値は、Message Header のフィールド（4.2.1 項及び 5.2.1 項参照）に保持される
一方、Upper FOID も Route ID の何れも SMCP により定義されたデータ構造に含まれない。
UFORID の値は、下位層プロトコルを用いてLower-Layer Protocol Dependent Scheme により伝送する (4.2.1 項及び 5.2.1 項参照)。

[Example][例]

Suppose a Functional Object has

Functional Object において-

the number of bits for the Route ID: 3 bits (000bto 111b), and- Route ID のビット数：3 bits（000b〜111b）-

Upper FOID: 1010 1000b.

- Upper FOID: 1010 1000bの場合、Upper FOID mask は 1111 1000b であり、1010 1001b と 1010 1111b の間の Upper FOID 値は禁止である。

The Upper FOID mask is 1111 1000b and the Upper
FOID values between 1010 1001b and 1010 1111b are
not allowed.

23

JERG-2-700-TP002-NOTICE1
この Functional Object に対し Route ID が 010b の
場合、UFORID は、次の式により得られる。

For the Route ID of 010b for the Functional Object,
the UFORID is obtained by the following equation:

UFORID = Upper FOID + Route ID
1010 1010b = 1010 1000b + 010b.
逆に、Upper FOID は、以下の式により UFORIDから得られる。

Conversely, the Upper FOID is obtained from theUFORID by the following equation:

Upper FOID = UFORID & Upper FOID mask
1010 1000b = 1010 1010b & 1111 1000b,
where ‘&’ denotes the binary multiplication operator.

ここで、‘&’ はビット論理積演算子を示す。

24

JERG-2-700-TP002-NOTICE1
3.3.6.

Lower FOID

The lower 8-bit part of a FOID is referred to as a
Lower Functional Object Identifier (Lower FOID).

FOID の下位 8-bit 部分を、Lower Functional Object
Identifier (Lower FOID) と称する。

The Lower FOID shall be the identifier assigned toeach of the Functional Objects within a Functional
Object Route Group (i.e. local identifier).

Lower FOID は、Functional Object Route Group 内
での Functional Objects の識別子（つまり、ローカ
ル識別子）であること。

[Rationale] With the aim to encourage re-use of
Functional Objects from one spacecraft to another,
SMCP messages do not contain global identifiers,
which are often different from those for the otherspacecrafts, but local identifiers only.

[根拠] ある宇宙機から他の宇宙機への Functional
Objects の再使用を促すため、宇宙機によりしば
しば異なるグローバル識別子ではなく、ローカルな識別子のみを SMCP Messages に含める。

3.3.7.

Attribute ID

An Attribute of a Functional Object is a parameter
representing a status of the Functional Object [A1].

Functional Object の Attribute は、Functional Objectの状態を表すパラメータである [A1]。

An Attribute Sequence shall be a sequence ofAttributes of one or more Functional Objects.

Attribute Sequence は 、 一 つ 以 上 の Functional
Objects の Attributes の並びであること。

[Note 1] The definition of each Attribute Sequence(e.g. the Attributes whose values of which the
Attribute Sequence consists) is registered in the SIB2.

[注 1] 各 Attribute Sequence の定義（例えば、そのAttribute Sequence を構成する Attributes）は、SIB2に登録する。

An Attribute and Attribute Sequence are both referred
to as an Attribute Set.

Attribute 及び Attribute Sequence を Attribute Set と総称する。

In the case the Attribute Values field of a SET
Telecommand or a VALUE Telemetry contains thevalue of an Attribute Set (i.e. either an Attribute or an
Attribute Sequence) (see Sections 4.5.7 and 5.3.5), theAttribute Set shall have an identifier which is referred
to as an Attribute Identifier (Attribute ID).

SET Telecommand ま た は VALUE Telemetry のAttribute Values フィールドが、Attribute Set (つまり Attribute または Attribute Sequence の何れか)の値を保持する (4.5.7 項及び 5.3.5 項参照) 場合、その Attribute Set は、Attribute Identifier (AttributeID) と称する識別子を持つこと。

The Attribute IDs shall be unique within the
Functional Object.

Attribute IDs は、その Functional Object 内で一意に決まること。

An Attribute ID shall be a 16-bit integer.

Attribute ID は、16-bit の整数であること。

[Note 2] Attributes and Attribute Sequences share acommon identifier space.

[注 2] Attributes と Attribute Sequences は、同じ識別子空間を共有する。

25

JERG-2-700-TP002-NOTICE1
3.3.8.

Telecommand Message ID

Every SMCP Telecommand shall have an identifier
which is referred to as a Telecommand Message
Identifier (Telecommand Message ID).

全 て の SMCP Telecommand は 、 Telecommand
Message Identifier (Telecommand Message ID) と称する識別子を持つこと。

A Telecommand Message ID shall be a 16-bit integer.

Telecommand Message ID は、16-bit の整数である
こと。

26

JERG-2-700-TP002-NOTICE1

4.

SMCP TELECOMMAND

4.1.

GENERAL // 一般

SMCP Telecommands are categorized into thefollowing five types (hereafter referred to as
Telecommand Types).

SMCP Telecommands を、以下の五つのタイプ (以降 Telecommand Types と称する) に分類する。

a) ACTION Telecommand (see Section 4.3)b) GET Telecommand (see Section 4.4)c) SET Telecommand (see Section 4.5)d) MEMORY LOAD Telecommand (see Section 4.6)e) MEMORY DUMP Telecommand (see Section 4.7)a) ACTION Telecommand (4.3 項参照)b) GET Telecommand (4.4 項参照)
c) SET Telecommand (4.5 項参照)
d) MEMORY LOAD Telecommand (4.6 項参照)e) MEMORY DUMP Telecommand (4.7 項参照)

Most of the information items related to SMCP
Telecommands are transferred on Telecommand
Messages, and a part of them are transferred in a
Lower-Layer Protocol Dependent Scheme. Some
Lower-Layer Protocol Dependent Schemes use fields
in the PCI of a protocol data unit that transfers the
Telecommand Messages.

SMCP Telecommands に関連する情報項目のほとんどは、Telecommand Messages により伝送する。
一部の情報項目は Lower-Layer Protocol Dependent
Scheme により伝送する。Lower-Layer Protocol
Dependent Scheme の 中 に は 、 Telecommand
Messages の伝送に使う protocol data unit の PCI のフィールドを用いるものがある。

A Telecommand Message consists of a Message
Header and a Message Body (see Section 3.2). The
format of the Message Header of a Telecommand
Message is specified in Section 4.2. The format of the
Message Body varies, depending on the Telecommand
Type, and is specified in Sections 4.3- 4.7.

Telecommand Message は 、 Message Header とMessage Body と か ら な る （ 3.2 項 参 照 ）。
Telecommand Message の Message Header のフォー
マットは、4.2 項で定める。 Message Body のフォーマットは、Telecommand Type によって異なり、
4.3 項〜4.7 項に定める。

27

JERG-2-700-TP002-NOTICE1

4.2.

COMMON INFORMATION ITEMS // 共通情報項目

4.2.1.

General // 一般

A SMCP Telecommand shall contain the following
information items:

SMCP Telecommand は、以下の情報項目をそれぞれ一つずつ含むこと。

a)
b)
c)
d)

a)
b)
c)
d)

One Acknowledgement Request (ACK Request),
One Lower FOID,
One UFORID, and
One Telecommand Message ID.

Acknowledgement Request (ACK Request)
Lower FOIDUFORID
Telecommand Message ID

The Message Header of a Telecommand Message isreferred to as a Telecommand Message Header.

Telecommand Message の Message Header を 、
Telecommand Message Header と称する。

For any Telecommand Types, the Telecommand
Message Header shall follow the format shown in
Figure 4-1.

ど の Telecommand Types に お い て も 、Telecommand Message Header は、Figure 4-1 に示すフォーマットに従うこと。

ACK Request(2 bits)(2 octets)
Message Format Version
Telecommand Type ID(2 bits)(4 bits)(a) Msg-Format Ver.1

Lower FOID
(1 octet)Figure 4-1: Telecommand Message Header format
The Telecommand Message Header does not containthe UFORID (see Section 3.3.5) and Telecommand
Message ID (see Section 3.3.8). The values of the
UFORID and the Telecommand Message ID shall betransferred in a Lower-Layer Protocol Dependent
Scheme.

UFORID（3.3.5 項参照）と Telecommand Message
ID（3.3.8 項参照）は、Telecommand Message Headerに は 含 ま れ な い 。 UFORID と Telecommand
Message ID の 値 は 、 Lower-Layer Protocol
Dependent Scheme にしたがって伝送すること。

[Example] [R2] specifies that the value of the Packet
Sequence Control field and the value of the Lower 8
bits of the Application Process Identifier (APID) fieldof the Space Packet that contains the Telecommand
Message be used for the Telecommand Message ID
and UFORID, respectively, if the lower-layer protocol
is the Space Packet Protocol.

[例] [R2] は、下位層プロトコルが Space Packet
Protocol の場合、Telecommand Message を含む
Space Packet の Packet Sequence Control フィール
ドの値及び Application Process Identifier (APID)フィ ー ル ド の 下 位 8 bits. の 値 を 、 そ れ ぞ れ 、Telecommand Message ID 及び UFORID として用いる事を定めている。

28

JERG-2-700-TP002-NOTICE1
4.2.2.

ACK Request (field)

The value of an Acknowledgement Request (ACK
Request) shall indicate whether an ACK Telemetry(see Section 5.5 for the definition of the term) isrequested to generate or not upon reception of a SMCP
Telecommand.

Acknowledgement Request (ACK) の値は、SMCP
Telecommand の受信時に、ACK Telemetry（用語定義は 5.5 項参照）の生成を要求するか否かを示すこと。

An ACK Request shall be one of the values listed inTable 4-1

ACK Request は、Table 4-1 に示す値の何れかとすること。

Table 4-1: Allowed values for the ACK Request
ACK Request に許容される値
Value

Meaning0

An ACK Telemetry is not requested to generate.

1

An ACK Telemetry is requested to generate.

[Note] Whether a Functional Object has the capability
to generate ACK Telemetries or not is determined foreach Functional Object as specified in Section 5.5.1.
An ACK Request has effect only for the case where aFunctional Object has the capability.

[注] Functional Object に ACK Telemetries を生成する能力があるか否かは、各 Functional Object に対し、5.5.1 項が定める様式にしたがって決める。
ACK Request は、Functional Object にその能力がある場合にのみ有効である。

A Telecommand Message Header shall contain a fieldreferred to as an ACK Request field which holds thevalue of the ACK Request.

Telecommand Message Header は、ACK Request の値を保持するフィールド (ACK Request フィールドと称する) を含むこと。

4.2.3.

Message Format Version (field)

The Message Format Version (see Section 3.3.1) for
Command Messages shall be 1.

Command Messages の Message Format Version(3.3.1 項参照) は、1 であること。

A Telecommand Message Header shall contain a fieldreferred to as a Message Format Version field whichholds the value of the Message Format Version.

Telecommand Message Header は、Message Format
Version の 値 を 保 持 す る フ ィ ー ル ド (Message
Format Version フィールドと称する) を含むこと。

29

JERG-2-700-TP002-NOTICE1
4.2.4.

Telecommand Type ID (field)

The Telecommand Type Identifier (Telecommand
Type ID) shall specify the Telecommand Type of the
SMCP Telecommand.

Telecommand Type Identifier (Telecommand TypeID) は、SMCP Telecommand の Telecommand Typeを指定すること。

A Telecommand Type ID shall be one of the values
listed in Table 4-2.

Telecommand Type ID は、Table 4-2 に示す値の何れかとすること。

Table 4-2: Allowed values for the Telecommand Type ID
Telecommand Type ID に許容される値
Value

Meaning0

ACTION Telecommand

1

GET Telecommand

2

SET Telecommand

4

MEMORY LOAD Telecommand

5

MEMORY DUMP Telecommand

Telecommand Message Header は 、 Telecommand
Type ID の 値 を 保 持 す る フ ィ ー ル ド(Telecommand Type ID フィールドと称する) を含
むこと。

A Telecommand Message Header shall contain a fieldreferred to as a Telecommand Type ID field whichholds the value of the Telecommand Type ID.

4.2.5.

Lower FOID field
Telecommand Message Header は 、 Lower FOID
(3.3.2 項 参 照 ) の 値 を 保 持 す る フ ィ ー ル ド(Lower FOID フィールドと称する) を含むこと。

A Telecommand Message Header shall contain a fieldreferred to as a Lower FOID field which holds thevalue of the Lower FOID (see Section 3.3.2).

30

JERG-2-700-TP002-NOTICE1

4.3.

ACTION TELECOMMAND

4.3.1.

General // 一般

An Operation of a Functional Object is an action
performed by the Functional Object and is invokedfrom the outside (see Section 4.1 in [A1]).

Functional Object の Operation は、Functional Object
が行う動作であり、外部より呼び出す ([A1] 4.1
項参照)。

Memory Functional Objects is a kind of Functional
Objects (see Section 4.1 in [A1]).

Memory Functional Objects は、Functional Objectsの一種である ([A1] 4.1 項参照)。

An ACTION Telecommand shall be used to invoke an
Operation of a Functional Object, except for two kinds
of Operations of Memory Functional Object,
MemoryLoad Operations and MemoryDump
Operations, which are invoked by a Memory Load
MEMORY
DUMP
Telecommand
anda
Telecommand, respectively (see Sections 4.6 and 4.7).

ACTION Telecommand を、Functional Object のOperation の呼び出しに用いること（ただし、Memory Functional Objects の Operations のうちの二種類、すなわち Memory Load Telecommand で呼び出すものである MemoryLoad Operation、並びに MEMORY DUMP Telecommand で呼び出すものである Memory Dump Operation を除く (4.6
項及び 4.7 項参照) ）。

Upon receiving an ACTION Telecommand, theFunctional Object shall execute the specified
Operation.

Functional Object は、ACTION Telecommand を受信すると、指定された Operation を行うこと。

[Note 1] Only one Operation can be invoked by an
ACTION Telecommand.

[注 1] 一つの ACTION Telecommand は、一つのOperation のみを呼び出す事ができる。

[Note 2] An execution of an Operation usually resultsin change in the values of some Attributes. In somecases, a state transition occurs as a result of executing
an Operation and the values of the State Attributes(defined in [A1], a kind of Attributes) associated with
State Machines [A1] change. Whether the specified
Operation has been successfully executed or not in
response to a received ACTION Telecommand can beverified by a Controller by checking the values of the
Attributes that are supposed to change as a result of the
Operation.

[注 2] Operation を実行した結果として、通常、幾つかの Attributes の値が変化する。場合によっては、Operation を実行した結果として状態遷移が発生し、State Machines [A1] に関連した State
Attributes ([A1] で定義、Attributes の一種) の値が変化する。 受信した ACTION Telecommand への応答として、指定された Operation が正常に実行されたか否かは、Controller が、Operation の結果変化するであろう Attributes の値をチェックする
事で検証できる。

The SMCP Message which contains information of an
ACTION Telecommand is referred to as an ACTION
Telecommand Message.

ACTION Telecommand の 情 報 を 含 む SMCP
Message を、ACTION Telecommand Message と称する。

An ACTION Telecommand Message shall follow theformat shown in Figure 4-2.

ACTION Telecommand Message は、Figure 4-2 に示すフォーマットに従うこと。

31

JERG-2-700-TP002-NOTICE1(Length depends on the Operation)
Message Body

Telecommand Message
HeaderOperation ID(2 octets)(2 octets)

Parameters and Attribute Values (optional)(Length depends on the Operation)

Figure 4-2: ACTION Telecommand Message format
4.3.2.

Telecommand Message Header
4.2 項参照。

See Section 4.2.

4.3.3.

Operation ID (field)

An Operation which is invoked by an Action
Telecommand shall have an identifier which isreferred to as an Operation Identifier (Operation ID).

Action Telecommand が呼び出す Operation は、Operation Identifier (Operation ID) と称する識別子を持つこと。

The Operation IDs shall be unique within the
Functional Object.

Operation IDs は、その Functional Object 内で一意に決まること。

An Operation ID shall be a 16-bit integer.

Operation ID は、16-bit の整数であること。

For Operation IDs, the value 0 shall be reserved andindicate No Operation (NOP) (defined in [A1], a kindof Operation), except for the Functional Objects thathave been already designed before this specification isadopted.

Operation IDs の値のうち 0 は、この仕様を採用する以前に既に設計されていた Functional Objects
を 除 き 、 No Operation (NOP) ([A1] で 定 義 、Operation の一種) のため予約されていること。

The Message Body of an ACTION Telecommand
Message shall contain a field referred to as an
Operation ID field which holds the value of the
Operation ID.

ACTION Telecommand Message の Message Body
は 、 Operation ID の 値 を 保 持 す る フ ィ ー ル ド(Operation ID フィールドと称する) を含むこと。

32

JERG-2-700-TP002-NOTICE1
4.3.4.

Parameters and Value Setting Attributes (Parameters and Attribute Values field)

If an Operation has Parameters and/or Value Setting
Attributes (defined in [A1], parameters), their values
shall be delivered to the Functional Object with the
ACTION Telecommand used to invoke the Operation.

Operation が Parameters 及び・または Value Setting
Attributes ([A1]で定義、パラメータ) を持つ場合、これらの値はその Operation を呼び出すのに用いる ACTION Telecommand にて Functional Object に配信すること。

[Note 1] If an Operation sets values to the Value
Setting Attributes, the values to be set to the Attributes
are delivered to the Functional Object as parameter ofan ACTION Telecommand.

[注 1] Operation が Value Setting Attributes に値を設 定 す る 場 合 、 Attributes に 設 定 す る 値 は 、
ACTION Telecommand の パ ラ メ ー タ と し てFunctional Object に配信する。

If an Operation accepts one or more Parameters and/or
Value Setting Attributes associated with it, theMessage Body of the ACTION Telecommand
Message that invokes the Operation shall contain afield referred to as a Parameters and Attribute Values
field and the Parameters and Attribute Values fieldshall consist of the sub-fields which hold the values of
all the Parameters and/or Value Setting Attributes.

Operation に関連する Parameters 及び・またはValue Setting Attributes が一つ以上ある場合、そのOperation を 呼 び 出 す ACTION Telecommand
Message の Message Body は 、 Parameters andAttribute Values フィールドと称するフィールドを含むこと。また、全ての Parameters 及び・または Value Setting Attributes の値を保持するサブフ
ィールドにより Parameters and Attribute Values フィールドを構成すること。

Otherwise, the Parameters and Attribute Values fieldshall be omitted.

さもなければ、Parameters and Attribute Values フィールドは省略すること。

The sub-fields of the Parameters and/or Value Setting
Attributes whose values are held in a Parameters andAttribute Values field shall be specified for each
Operation. The bit length and encoding rule shall be
specified for each Parameter.

Parameters and Attribute Values フィールドにて値を保持する Parameters 及び・または Value Setting
Attributes のサブフィールドは、Operation 毎に定めること。また、Parameter 毎にビット長と符号化規則を定めること。

[Note 2] The definitions for the sub-fields of theParameters whose values are contained in an ACTION
Telecommand Message (e.g. their bit lengths and theirencoding rules) are registered in the definition part foreach Operation in the SIB2.

[注 2] ACTION Telecommand Message に値を含める Parameters のサブフィールドの定義（例えば、ビット長や符号化規則）は、SIB2 の各 Operationの定義部に登録する。

[Note 3] The Attributes whose values are contained ina ACTION Telecommand Message are registered in
the definition part for each Opeartion in the SIB2.

[ 注 3] ACTION Telecommand に 値 を 含 め る
Attributes は、SIB2 の各 Opeartion の定義部に登録する。

The bit length and encoding rule of the sub-fields of
the Value Setting Attributes shall be specified for each
Attribute.

Value Setting Attributes のサブフィールドのビッ
ト長と符号化規則は、Attribute 毎に定めること。

33

JERG-2-700-TP002-NOTICE1

4.4.

GET TELECOMMAND

4.4.4.

General // 一般A GET Telecommand shall be used to generate a(Response) VALUE Telemetry (see Section 5.3.1).

GET Telecommand は、(Response) VALUE Telemetry（5.3.1 項参照）の生成に用いること。

Upon receiving a GET Telecommand, a Functional
Object shall generate the specified VALUE Telemetry.

Functional Object は、GET Telecommand を受信す
ると、指定された VALUE Telemetry を生成すること。

[Note] There is no independent way for a Controller toknow whether the expected VALUE Telemetry has
been successfully generated or not in response to a
GET Telecommand that the Controller had sent to a
Functional Object, before the Controller actually
receives an expected VALUE Telemetry from the
Functional Object.

[注] ある Controller が、Functional Object に対して送った GET Telecommand に応答して、期待される VALUE Telemetry が正常に生成されたか否か は 、 そ の Functional Object か ら の VALUE
Telemetry を、Controller が実際に受信する以外に、Controller が知る方法は存在しない。

The SMCP Message which contains information of a
GET Telecommand is referred to as a GET
Telecommand Message.

GET Telecommand の情報を含む SMCP Message
を、GET Telecommand Message と称する。

A GET Telecommand Message shall follow the format
shown in Figure 4-3.

GET Telecommand Message は、Figure 4-3 に示す
フォーマットに従うこと。

(4 octets)
Message Body

Telecommand Message
HeaderAttribute ID(2 octets)(2 octets)

Figure 4-3: GET Telecommand Message format

34

JERG-2-700-TP002-NOTICE1
4.4.5.

Telecommand Message Header
4.2 項参照。

See Section 4.2.

4.4.6.

Attribute ID (field)

In this section, the Attribute ID of an Attribute Set (i.e.
either an Attribute or an Attribute Sequence) whose
value is to be returned with the Response VALUE
Telemetry is referred to simply as the Attribute ID.

本項では、Response VALUE Telemetry で値を返す
Attribute Set ( つまり Attribute または Attribute
Sequence の 何 れ か ) の Attribute ID を 、 単 にAttribute ID と称する。

[Note] The values of some Attributes or Attribute
Sequences cannot be retrieved with any GET
Telecommands. The information whether the values
can be retrieved with a GET Telecommand or not isregistered in the definition part for each Attribute andAttribute Sequence in the SIB2.

[注] 何れの GET Telecommands でも値を取り出す事ができない Attributes や Attribute Sequencesもある。GET Telecommand で値を取り出す事がで
き る か 否 か の 情 報 は 、 SIB2 の 各 Attribute やAttribute Sequence の定義部に登録する。

The Message Body of a GET Telecommand Message
shall contain a field referred to as an Attribute ID field
which holds the value of the Attribute ID.

GET Telecommand Message の Message Body は、Attribute ID の値を保持するフィールド (Attribute
ID フィールドと称する) を含むこと。

35

JERG-2-700-TP002-NOTICE1

4.5.

SET TELECOMMAND

4.5.4.

General // 一般

A SET Telecommand shall be used to set values to an
Attribute Set (i.e. either an Attribute or an Attribute
Sequence, see Section 3.3.7). A SET Telecommandalso invokes an Operation, which may be a NOP.

SET Telecommand は、
Attribute Set (つまり Attribute
または Attribute Sequence の何れか、3.3.7 項参照)
への値の設定に用いること。 SET Telecommand
は、また、Operation（NOP であっても良い）も呼び出す。

Upon receiving a SET Telecommand, a Functional
Object shall execute the specified Operation and set
values to the specified Attribute Set.

Functional Object は、SET Telecommand を受信す
ると、指定に従い Operation を行い、Attribute Setに値を設定すること。

[Note 1] As a result of execution of an Operation
invoked by a SET Telecommand, the values of some
Attributes usually change unless all the Attributes
have already had the same values as the specified
before the Operation. The change can be verified by aController by checking the values of the Attributes thatare supposed to change.

[注 1] SET Telecommand に呼び出された Operationの実行の結果、全ての Attributes の値が Operation
以前から指定と同じ値だった場合を除き、通常、幾つかの Attributes の値が変化する。この変化は、変化が期待される Attributes の値をチェックする事で、Controller により検証できる。

[Note 2] In some cases, once an Operation invoked bysome specific ACTION Telecommands or SET
Telecommands is executed, the values of some
Attributes are expected to be set to certain values,
according to the specification of the Functional
Object. In the former case, the Attributes whose values
are to be set are registered in the definition part foreach Operation in the SIB2. In the latter case, theinformation whether the values can be set with a SET
Telecommand or not is registered in the definition partfor each Attribute or Attribute Sequence in the SIB2.

[注 2] 幾つかの ACTION Telecommands またはSET Telecommands では、呼び出された Operationの 実 行 の 結 果 、 設 定 さ れ る Attributes の 値 がFunctional Object の仕様から決まるという事があり得る。前者の場合、値を設定する Attributes を、
SIB2 の各 Operation の定義部に登録する。後者の場合、SET Telecommand で値を設定する事ができるか否かの情報を、SIB2 の各 Attribute や Attribute
Sequence の定義部に登録する。

The roles of the SET Telecommand and ACTION
Telecommand have some overlap. During the designphase of each Functional Object, policy for the
distinction in usage of the SET Telecommand and
ACTION Telecommand should be decided in eachproject.

SET Telecommand と ACTION Telecommand の役
割は重複している。各 Project は、各 Functional
Object の 設 計 段 階 で 、 SET Telecommand と
ACTION Telecommand を使い分ける方針を決めるべきである。

[Note 3] A major difference between the SET
Telecommand and ACTION Telecommand is thenaming rule (see [R4]). The name of a SET
Telecommand includes the name of the Attribute Set
whose values are held by the Attribute Values field,
whereas that of an ACTION Telecommand includes
the name of the Operation.

[注 3] SET Telecommand と ACTION Telecommandの主な違いは、命名規則である ([R4] 参照)。SET
Telecommand の名前は、Attribute Values フィール
ドにより値が保持される Attribute Set の名前を含む 。 一 方 、 ACTION Telecommand の 名 前 は 、Operation の名前を含む。

36

JERG-2-700-TP002-NOTICE1The SMCP Message which contains information of a
SET Telecommand is referred to as a SET
Telecommand Message.

SET Telecommand の情報を含む SMCP Message
を、SET Telecommand Message と称する。

A SET Telecommand Message shall follow the format
shown in Figure 4-4.

SET Telecommand Message は、Figure 4-4 に示す
フォーマットに従うこと。

Telecommand Message
Header(2 octets)(Length depends on the Attribute Set)
Message Body
Attribute ID(2 octets)

Attribute Values(Length depends on the Attribute Set)

Figure 4-4: SET Telecommand Message format

37

JERG-2-700-TP002-NOTICE1
4.5.5.

Telecommand Message Header
4.2 項参照。

See Section 4.2

4.5.6.

Attribute ID (field)

In this section, the Attribute ID of the Attribute Set
whose value is held in the Attribute Values field (seeSection 4.5.7) is referred to simply as the Attribute ID.

本項では、Attribute Values フィールド (4.5.7 項参照) が値を保持する Attribute Set の Attribute ID
を、単に Attribute ID と称する。

[Note] The values of some Attributes and Attribute
Sequences cannot be set with any SET Telecommands.
The information whether the values can be set with a
SET Telecommand or not is registered in the definition
part for each Attribute and Attribute Sequence in the
SIB2.

[注] 何れの SET Telecommands でも値を設定できない Attributes や Attribute Sequences がある。SET
Telecommand で値を設定できるか否かの情報は、
SIB2 の各 Attribute や Attribute Sequence の定義部に登録する。

The Message Body of a SET Telecommand Message
shall contain a field referred to as an Attribute ID field
which holds the value of the Attribute ID.

SET Telecommand Message の Message Body は、Attribute ID の値を保持するフィールド (Attribute
ID フィールドと称する) を含むこと。

38

JERG-2-700-TP002-NOTICE1
4.5.7.

Attribute Values field

The Message Body of a SET Telecommand Message
shall contain a field referred to as an Attribute Values
field which holds the value of the Attribute Set (i.e.
either an Attribute or an Attribute Sequence).

SET Telecommand Message の Message Body は、Attribute Set ( つまり Attribute または Attribute
Sequence の何れか) の値を保持するフィールド(Attribute Values フィールドと称する) を含むこと。

The bit length and encoding rule shall be specified foreach Attribute.

ビット長と符号化規則は、各 Attribute に対して定めること。

[Note] The bit length and encoding rule are registeredin the definition part for each Attribute in the SIB2.

[ 注 ] ビ ッ ト 長 と 符 号 化 規 則 は 、 SIB2 の 各
Attribute の定義部に登録する。

The maximum octet length of the Attribute Values
field shall be determined in each project (see Table C1).

Attribute Values フィールドの最大 octet 長は、。
project 毎に決めること（Table C-1 参照）

39

JERG-2-700-TP002-NOTICE1

4.6.

MEMORY LOAD TELECOMMAND

4.6.4.

General // 一般

A MEMORY LOAD Telecommand shall be used to
invoke the MemoryLoad Operation (defined in [A1],a kind of Operation) performed by a Memory
Functional Object.

MEMORY LOAD Telecommand は 、 Memory
Functional Object が 実 行 す る MemoryLoad
Operation ([A1] で定義、Operation の一種) の呼び出しに用いること。

A MemoryLoad Operation has two Parameters:
MemoryData and StartAddress (see Section 4.2 in[A1]). A MEMORY LOAD Telecommand contains
the values of the MemoryData and StartAddress.

MemoryLoad Operation は、二つの Parameters, す
なわち MemoryData と StartAddress を持つ ([A1]4.2 項参照)。MEMORY LOAD Telecommand は、MemoryData と StartAddress の値を含む。

[Note 1] MemoryData is a set of data to be written ina memory area.

[注 1] MemoryData は、メモリ領域に書きこまれるひとかたまりのデータである。

Upon receiving a MEMORY LOAD Telecommand, aMemory Functional Object shall store theMemoryData into the memory area specified with thevalue of the StartAddress.

Memory Functional Object は、MEMORY LOAD
Telecommand を受信すると、MemoryData を、
Start
Address の値で指定されたメモリ領域に格納すること。

[Note 2] Whether the MemoryData has beensuccessfully stored in the specified memory area or not
in response to a received MEMORY LOAD
Telecommand can be verified by a Controller bysending a MEMORY DUMP Telecommand (seeSection 4.7) and then receiving MEMORY DUMP
Telemetries (see Section 5.6). Additionally, it isrecommended that some check bits (such as CRC) be
embedded in the data and that a Controller verify if theTarget has received all the MemoryData correctly by
performing a check using the check bits.

[注 2] 受信した MEMORY LOAD Telecommand に応答して MemoryData が指定されたメモリ領域に正常に格納されたか否かは、Controller が、MEMORY DUMP Telecommand（4.7 項参照）を送り、MEMORY DUMP Telemetries（5.6 項参照）を受信する事で検証できる。これに加え、幾つかのチェックビット（CRC 等）をデータに埋め込み、
チェックビットを用いチェックする事で、Target
が全ての MemoryData を正しく受信したか否かを、Controller が検証する事も推奨する。

MemoryData of some Memory Functional Objects
may have restriction on allowed combination of theStartAddress and octet length. The possible patterns
for the restrictions are specified in [A1].

Memory Functional Objects の中には、MemoryDataの StartAddress と octet 長に許される組み合わせに制約があるものがあっても良い。あり得る制約のパターンは [A1] で定めている。

[Note 3] The Pattern of the restrictions for each
Memory Functional Object is registered in the SIB2.

[注 3] 各 Memory Functional Object に対する制約のパターンは SIB2 に登録する。

The SMCP Message which contains information of a
MEMORY LOAD Telecommand is referred to as a
MEMORY LOAD Telecommand Message.

MEMORY LOAD Telecommand の 情 報 を 含 む
SMCP Message を、MEMORY LOAD Telecommand
Message と称する。

A MEMORY LOAD Telecommand Message shallfollow the format shown in Figure 4-5.

MEMORY LOAD Telecommand Message は、Figure
4-5 に示すフォーマットに従うこと。

40

JERG-2-700-TP002-NOTICE1
Telecommand Message
Header(2 octets)(Length depends on the Message)
Message Body
Start Address(4 octets)

Load Data(Length depends on the Message)

Figure 4-5: MEMORY LOAD Telecommand Message format
4.6.5.

Telecommand Message Header
4.2 項参照。

See Section 4.2.

4.6.6.

StartAddress, Start Address field

A MEMORY LOAD Telecommand contains the valueof the StartAddress.

MEMORY LOAD Telecommand は、StartAddress の値を含む。

The StartAddress shall specify the first address of thememory area into which the MemoryData is to be
written.

StartAddress は、MemoryData を書き込むメモリ領域の最初のアドレスを指定すること。

The method to map a StartAddress to a physicaladdress of the memory shall be determined for each
Memory Functional Object (identified by the FOID).

StartAddress をメモリの物理アドレスにマッピングする方法は、Memory Functional Object（FOID により識別する）毎に決めること。

The Message Body of a MEMORY LOAD
Telecommand Message shall contain a field referred
to as a Start Address field which holds the value of theStartAddress.

MEMORY LOAD Telecommand Message のMessage Body は、StartAddress の値を保持するフィールド (Start Address フィールドと称する) を
含むこと。

41

JERG-2-700-TP002-NOTICE1
4.6.7.

MemoryData, Load Data field

A MEMORY DUMP Telecommand contains theMemoryData.

MEMORY DUMP Telecommand は、MemoryData を含む。

The Message Body of a MEMORY LOAD
Telecommand Message shall contain a field referred
to as a Load Data field.

MEMORY LOAD Telecommand Message のMessage Body は、Load Data フィールドと称する
フィールドを含むこと。

A Load Data field shall consist of a MemoryData only.

Load Data フィールドは、MemoryData のみからなること。

The Memory Functional Object shall write all the datain the Load Data field into the contiguous memoryarea that starts at the StartAddress.

Memory Functional Object は、Load Data フィール
ドの全てのデータを、StartAddress で始まる連続するメモリ領域に書き込むこと。

The maximum octet length of the Load Data field shallbe determined in each project (see Table C-1).

Load Data フィールドの最大 octet 長は、project 毎。
に決めること（Table C-1 参照）

42

JERG-2-700-TP002-NOTICE1

4.7.

MEMORY DUMP TELECOMMAND

4.7.4.

General // 一般

A MEMORY DUMP Telecommand shall be used to
invoke the Memory Dump Operation (defined in [A1],a kind of Operation) performed by a Memory
Functional Object. A MemoryDump Operation has
three Parameters: NoOfDumps, StartAddress, and
DataLength (see Section 4.2 in [A1]).

MEMORY DUMP Telecommand は 、 Memory
Functional Object が 実 行 す る Memory Dump
Operation ([A1] で定義、Operation の一種) の呼び出しに用いること。MemoryDump Operation は、
三 つ の Parameters,
す な わ ち NoOfDumps,
StartAddress, 及び DataLength StartAddress を持つ([A1] 4.2 項参照)。

A MEMORY DUMP Telecommand contains thevalues of the NoOfDumps, StartAddress, and
DataLength.

MEMORY DUMP Telecommand は、NoOfDumps,
StartAddress, 及び DataLength の値を含む。

Upon receiving a MEMORY DUMP Telecommand, aMemory Functional Object shall read out therequested memory data of octet length of the
DataLength from the contiguous memory area,
starting at the address specified in the StartAddressand shall send back the memory data, using one ormore MEMORY DUMP Telemetries (see Section 5.6).

Memory Functional Object は、MEMORY DUMP
Telecommand を 受 信 す る と 、 要 求 さ れ た
StartAddress で指定されたアドレスから始まる連
続するメモリ領域から DataLength の octet 長のメ
モリデータを読み出すこと。また、一つ以上の
MEMORY DUMP Telemetries（5.6 項参照）を用いて、メモリデータを返送すること。

Some Memory Functional Objects may haverestriction on allowed combination of the StartAddress
and DataLength. The possible patterns for the
restrictions are specified in [A1].

Memory Functional Objects の中には、StartAddressと DataLength に許される組み合わせに制約があ
るものがあっても良い。あり得る制約のパターン
は [A1] で定めている。

[Note] The pattern of the restriction for each Memory
Functional Object is registered in the SIB2.

[注] 各 Memory Functional Object に対する制約のパターンは SIB2 に登録する。

The SMCP Message which contains information of a
MEMORY DUMP Telecommand is referred to as a
MEMORY DUMP Telecommand Message.

MEMORY DUMP Telecommand の 情 報 を 含 む
SMCP Message を、MEMORY DUMP Telecommand
Message と称する。

A MEMORY DUMP Telecommand Message shallfollow the format shown in Figure 4-6.

MEMORY DUMP Telecommand Message は、Figure
4-6 に示すフォーマットに従うこと。

43

JERG-2-700-TP002-NOTICE1(10 octets)
Telecommand
Message Header(2 octets)

Message Body
Reserved(6 bits)

Number of Additional Dumps(2 bits)

Start Address(4 octets)

Data Length(3 octets)

Figure 4-6: MEMORY DUMP Telecommand Message format
The field marked as “Reserved” shall not be used
and be filled with zeros.

4.7.5.

“Reserved”となっているフィールドは、使用を避け、ゼロで埋めること。

Telecommand Message Header
4.2 項参照。

See Section 4.2.

44

JERG-2-700-TP002-NOTICE1
4.7.6.

NoOfDumps, Number of Additional Dumps field

A MEMORY DUMP Telecommand contains the valueof the NoOfDumps. In this section, n denotes the valueof a NoOfDumps.

MEMORY DUMP Telecommand は、NoOfDumps の値を含む。本項では、n は NoOfDumps の値を意味する。

A Functional Object which received a MEMORYDUMP Telecommand shall send the same memory
data with MEMORY DUMP Telemetries n times.

MEMORY DUMP Telecommand を 受 け 取 っ た
Functional Object は 、 同 じ メ モ リ デ ー タ を
MEMORY DUMP Telemetries で n 回送ること。

[Note 1] In the situations where the condition of thecommunications link is poor, the same memory data
can be sent up to four times to enhance the reliabilityof the received memory data.

[注 1] 通信リンクの状態が悪く、メモリデータ受
信をより確実にするために、同じメモリデータを四回まで送る事ができる。

The Message Body of a MEMORY DUMP
Telecommand Message shall contain a field referred
to as a ‘Number of Additional Dumps’ field, of which
the value shall be n-1.

MEMORY DUMP Telecommand Message のMessage Body は、その値が n-1 である、‘Numberof Additional Dumps’フィールドと称するフィールドを含むこと。

[Note 2] The maximum allowed value of the ‘Numberof Additional Dumps’ field is 3.

[注 2] ‘Number of Additional Dumps’フィールドに許容される最大値は 3 である。

[Example] If the value of a ‘Number of Additional
Dumps’ field is 0, the memory data is required to besent once. If the value of a ‘Number of Additional
Dumps’ field is 1, then the memory data is required to
be sent twice.

[例] ‘Number of Additional Dumps’フィールドの値
が 0 の場合、メモリデータは一回送信する事が要求される。 ‘Number of Additional Dumps’フィール
ドの値が 1 の場合、メモリデータは二回送信する事が要求される。

45

JERG-2-700-TP002-NOTICE1
4.7.7.

StartAddress, Start Address field

A MEMORY DUMP Telecommand contains the valueof the StartAddress.

MEMORY DUMP Telecommand は、StartAddress の値を含む。

The StartAddress shall specify the first address of thememory area from which the data is to be read.

StartAddress は、MemoryData を読みだすメモリ領域の最初のアドレスを指定すること。

The Message Body of a MEMORY DUMP
Telecommand Message shall contain a field referred
to as a Start Address field which holds the value of theStartAddress.

MEMORY DUMP Telecommand Message のMessage Body は、StartAddress の値を保持するフィールド (Start Address フィールドと称する) を含むこと。

The method to map a StartAddress to a physicaladdress of the memory shall be determined for each
Memory Functional Object (identified by the FOID).

StartAddress をメモリの物理アドレスにマッピングする方法は、Memory Functional Object（FOID により識別する）毎に決めること。

46

JERG-2-700-TP002-NOTICE1
4.7.8.

DataLength, Data Length field

A MEMORY DUMP Telecommand contains the valueof the DataLength.

MEMORY DUMP Telecommand は、DataLength の値を含む。

The value of a DataLength shall specify the octet
length of the memory area from which the data is to beread.

DataLength の値は、MemoryData を読みだすメモ
リ領域の octet 長を指定すること。

The Message Body of a MEMORY DUMP
Telecommand Message shall contain a field referred
to as a Data Length field which holds the value of the
DataLength.

MEMORY DUMP Telecommand Message のMessage Body は、DataLength の値を保持するフィールド (Data Length フィールドと称する) を含むこと。

[Note] The Data Length (e.g. 512 octets or 128 octets)
is determined for each Memory Functional Object
according to the restriction for implementation of theonboard instrument in each project.

[注] Data Length（512 octets や 128 octets 等）は、
各 project の 搭 載 機 器 の 実 装 の 制 約 に 従 いMemory Functional Object 毎に決める。

The maximum value allowed for the Data Length fieldshall be determined in each project (see Table C-1).

Data Length フィールドに許容する最大値は、。
project 毎に決めること（Table C-1 参照）

47

JERG-2-700-TP002-NOTICE1

5.

SMCP TELEMETRY
5.1.

GENERAL // 一般

SMCP Telemetry is categorized into the following
four types (hereafter referred to as Telemetry Types).

SMCP Telemetry を、以下の四つのタイプ (以降Telemetry Types と称する) に分類する。

a) VALUE Telemetry (see Section 5.3)b) NOTIFICATION Telemetry (see Section 5.4)c) Acknowledgement Telemetry (ACK Telemetry)(see Section 5.5)d) MEMORY DUMP Telemetry (see Section 5.6)a) VALUE Telemetry (5.3 項参照)b) NOTIFICATION Telemetry (5.4 項参照)
c) Acknowledgement Telemetry (ACK Telemetry)(5.5 項参照)
d) MEMORY DUMP Telemetry (5.6 項参照)

Most of the information items related to SMCP
Telemetry are transferred on Telemetry Messages, anda part of them are transferred in a Lower-Layer
Protocol Dependent Scheme. Some Lower-Layer
Protocol Dependent Schemes use fields in the PCI ofa protocol data unit that transfers the Telemetry
Messages.

SMCP Telemetry に関連する情報のほとんどは、Telemetry Messages により伝送する。一部の情報
は Lower-Layer Protocol Dependent Scheme により伝送する。Lower-Layer Protocol Dependent Schemeの 中 に は 、 Telemetry Messages の 伝 送 に 使 う
protocol data unit の PCI のフィールドを用いるものがある。

A Telemetry Message consists of a Message Header
and a Message Body (see Section 3.2). The format of
the Message Header of a Telemetry Message is
specified in Section 5.2. The format of the Message
Body varies, depending on the Telemetry Type, and isspecified in Sections 5.3-5.6.

Telemetry Message は、Message Header と Message
Body とからなる（3.2 項参照）
。Telemetry Messageの Message Header のフォーマットは、5.2 項で定める。Message Body のフォーマットは、
Telemetry
Type によって異なり、5.3〜5.6 項に定める。

48

JERG-2-700-TP002-NOTICE1

5.2.

COMMON INFORMATION ITEMS // 共通情報項目
5.2.1.

General // 一般

A SMCP Telemetry shall contain the following
information items:

SMCP Telemetry は、以下の情報項目をそれぞれ一つ含むこと。

a) One Message Length (optional),b) One Lower FOID, andc) One UFORID.

a) Message Length (オプション)b) Lower FOIDc) UFORID

The Message Header of a Telemetry Message isreferred to as a Telemetry Message Header.

Telemetry Message の Message Header を 、
Telemetry Message Header と称する。

For any Telemetry Types, the Telemetry Message
Header shall follow the format shown in Figure 5-1.

ど の Telemetry Types に お い て も 、 Telemetry
Message Header は、Figure 5-1 に示すフォーマッ
トに従うこと。

(5octets)
Reserved

Message
FormatVersion(2bits)(2bits)Telemetry Type ID

Message Length

Lower FOID

(4bits)(a) Msg-Format Ver.1(24bits)(8 bits)

Variable Part Length(optional)

Lower FOID
(optional)(0, 8 or 16bits)(0 or 8 bits)(1~4octets)
VariablePart Length
Field Flag
(1bit)

Lower
FOID
Field
Flag
(1bit)

Message
FormatVersion

Attr. /
Alert ID
Flag

(2bits)(1bit)(3bits)(b) Msg-Format Ver.2

Telemetry
Type ID

Figure 5-1: Telemetry Message Header format
The field marked as “Reserved” shall not be used
and be filled with zeros.

49“Reserved”となっているフィールドは、使用を避け、ゼロで埋めること。

JERG-2-700-TP002-NOTICE1
Telemetry Message Header does not contain the
UFORID (see Section 3.3.5). The value of the
UFORID shall be transferred in a Lower-Layer
Protocol Dependent Scheme.

UFORID（3.3.5 項参照）は、Telemetry Message
Header には含まれない。UFORID の値は、LowerLayer Protocol Dependent Scheme にしたがって伝送すること。

[Example] [R2] specifies that the value of the Lower
8 bits of the Application Process Identifier (APID)
field of the Space Packet that contains the
Telecommand Message be used for the UFORID if thelower-layer protocol is the Space Packet Protocol.

[例] [R2] は、下位層プロトコルが Space Packet
Protocol の場合、Telecommand Message を含む
Space Packet の Application Process Identifier (APID)
フィールドの下位 8 bits.の値を、UFORID として用いる事を定めている。

A Telemetry Message in Msg-Format Ver.2 consists of
one or two parts: a Fixed Part and an optional Variable
Part (see Figures 5-4 to 5-7).

Msg-Format Ver.2 の Telemetry Message は、一つまた は 二 つ の 部 分 、 Fixed Part と オ プ シ ョ ン の
Variable Part からなる (Figures 5-4 ~ 5-7 参照)。

Whereas the length of a Fixed Part is specified to be a
fixed value for each Telemetry Type, that of a Variable
Part varies from a Telemetry Message to another.

Fixed Part の長さは Telemetry Type が決まればある固定値に一意に定まる一方、Variable Part の長さは Telemetry Message により異なる。

50

JERG-2-700-TP002-NOTICE1
5.2.2.

Message Format Version (field)

The Message Format Version (see Section 3.3.1) for
Telemetry Messages shall be either 1 or 2.

Telemetry Messages の Message Format Version(3.3.1 項参照) は、1 か 2 の何れかであること。

A Telemetry Message Header shall contain a fieldreferred to as a Message Format Version field whichholds the value of the Message Format Version.

Telemetry Message Header は 、 Message Format
Version の 値 を 保 持 す る フ ィ ー ル ド (Message
Format Version フィールドと称する) を含むこと。

5.2.3.

Telemetry Type ID (field)

The Telemetry Type Identifier (Telemetry Type ID)
shall specify the Telemetry Type of the SMCP
Telemetry.

Telemetry Type Identifier (Telemetry Type ID) は、
SMCP Telemetry の Telemetry Type を指定すること。

The Telemetry Type ID shall be one of the values
listed in Table 5-1.

Telemetry Type ID は、Table 5-1 に示す値の何れかにすること。

Table 5-1: Allowed values for the Telemetry Type ID
Telemetry Type ID に許容される値
Value

Meaning0

VALUE Telemetry

1

NOTIFICATION Telemetry

2

ACK Telemetry

5

MEMORY DUMP Telemetry

Telemetry Message Header は、Telemetry Type IDの値を保持するフィールド (Telemetry Type ID フ
ィールドと称する) を含むこと。

A Telemetry Message Header shall contain a fieldreferred to as a Telemetry Type ID field which holds
the value of the Telemetry Type ID.

51

JERG-2-700-TP002-NOTICE1
5.2.4.

Message Length (field)

The Message Length shall specify the octet length ofthe entire Telemetry Message (including the Telemetry
Message Header).

Message Length は 、 Telemetry Message 全 体（Telemetry Message Header を含む）の octet 長を指定すること。

A Telemetry Message Header in Msg-Format Ver.1
shall contain a field referred to as a Message Length
field which holds the value of the Message Length.

Msg-Format Ver.1 の Telemetry Message Header は、Message Length の 値 を 保 持 す る フ ィ ー ル ド(Message Length フィールドと称する) を含むこと。

[Rationale] The Message Length field enables simple
implementation of blocking and segmenting.

[根拠] Message Length フィールドは、blocking とsegmenting を簡単に実装する事を可能にする。

5.2.5.

Lower FOID field

A Telemetry Message Header shall contain a fieldreferred to as a Lower FOID field which holds thevalue of the Lower FOID (see Section 3.3.2). The
exception is the case where the Telemetry Message
whose Lower FOID is 0. In this case, the Lower FOID
field is not mandatory in Msg-Format Ver.2.

Telemetry Message Header は、Lower FOID (3.3.2
項 参 照 ) の 値 を 保 持 す る フ ィ ー ル ド (Lower
FOID フィールドと称する) を含むこと。ただし、Telemetry Message において Lower FOID が 0 の場合は例外である。この場合、Msg-Format Ver.2 では Lower FOID フィールドは必須ではない。

The value of a Lower FOID Field Flag field, which
exists in Msg-Format Ver.2, shall be either 0 or 1 (seeTable 5-2 and Section 5.2.7) if the value of the Lower
FOID is 0 and shall be 1 otherwise.

Msg-Format Ver.2 に存在するものである Lower
FOID Field Flag フィールドの値は、Lower FOID
が 0 の場合 0 か 1 の何れかであること (Table 5-2
及び 5.2.7 項参照)。それ以外の場合、1 であること。

If the Lower FOID Field Flag (see Section 5.2.7) is 0,
the Telemetry Message Header shall not contain a
Lower FOID field. In this case, the Lower FOID of the
SMCP Telemetry is 0.

Lower FOID Field Flag (5.2.7 項参照) が 0 の場合、
Telemetry Message Header は Lower FOID フィールドを含まないこと。この場合、SMCP Telemetry のLower FOID は 0 である。

If the Lower FOID Field Flag is 1, the Telemetry
Message Header shall contain a Lower FOID field. In
this case, the allowed range of the Lower FOID is 00hFFh (see Table 5-2).

Lower FOID Field Flag が 1 の場合、Telemetry
Message Header は Lower FOID フィールドを含むこと。この場合、Lower FOID の取り得る範囲は00h-FFh となる (Table 5-2 参照)。

52

JERG-2-700-TP002-NOTICE1
Table 5-2: Encoding of a Lower FOID field
Lower FOID フィールドのエンコード
Lower FOID Field Flag field:
Lower FOID field0:
1: xxxxxxxx

5.2.6.

Field Length

Valid Data Bits

Value Range of Lower
FOID

1bit

0 bits0

1bit + 8bits

8 bits00h – FFh

Variable Part Length Field Flag (field)

The Variable Part Length Field Flag, which exists in
Msg-Format Ver.2, shall specify whether a Variable
Part Length field (see Section 5.2.9) exists in the
Telemetry Message Header or not.

Msg-Format Ver.2 に存在するものである Variable
Part Length Field Flag は、Telemetry Message Headerに Variable Part Length フィールド (5.2.9 項参照)
が存在するか否か指定すること。

The Variable Part Length Field Flag shall be one of thevalues listed in Table 5-3.

Variable Part Length Field Flag は、Table 5-3 に示す値の何れかにすること。

For each Telemetry Type, whether Variable Part
Length Field Flag is fixed at, or can be, either 0 or 1 is
specified (see Sections 5.3-5.6).

各 Telemetry Type に対し、
Variable Part Length Field
Flag が、0 か 1 の何れかであるか、または何れをも取り得るか、を定める (5.3〜5.6 項参照)。

Table 5-3: Allowed values for the Variable Part Length Field Flag
Variable Part Length Field Flag に許容される値
Value

Meaning0

A Variable Part Length field does not exist in the Telemetry Message
Header

1

A Variable Part Length field exists in the Telemetry Message Header

Msg-Format Ver.2 の Telemetry Message Header は、Variable Part Length Field Flag の値を保持するフィールド (Variable Part Length Field Flag フィールドと称する) を含むこと。

A Telemetry Message Header in Msg-Format Ver.2
shall contain a field referred to as a Variable Part
Length Field Flag field which holds the value of the
Variable Part Length Field Flag.

53

JERG-2-700-TP002-NOTICE1
5.2.7.

Lower FOID Field Flag (field)

The Lower FOID Field Flag, which exists in MsgFormat Ver.2, shall specify whether a Lower FOID
field exists in the Telemetry Message Header or not.

Msg-Format Ver.2 に存在するものである Lower
FOID Field Flag は、Telemetry Message Header に
Lower FOID フィールドが存在するか否かを指定すること。

A Lower FOID Field Flag shall be one of the values
listed in Table 5-4.

Lower FOID Field Flag は、Table 5-4 に示す値の何れかにすること。

Table 5-4: Allowed values for the Lower FOID Field Flag
Lower FOID Field Flag に許容される値
Value

Meaning0

A Lower FOID field does not exist in the Telemetry Message Header

1

A Lower FOID field exists in the Telemetry Message Header

Msg-Format Ver.2 の Telemetry Message Header は、
Lower FOID Field Flag の値を保持するフィール
ド (Lower FOID Field Flag フィールドと称する)を含むこと。

A Telemetry Message Header in Msg-Format Ver.2
shall contain a field referred to as a Lower FOID Field
Flag field which holds the value of the Lower FOID
Field Flag.

54

JERG-2-700-TP002-NOTICE1
5.2.8.

‘Attribute or Alert ID Field Flag’ (field)

The ‘Attribute or Alert ID Field Flag’ , which exists in
Msg-Format Ver.2, shall specify whether either of an
Attribute ID field (see Section 5.3.3) or Alert ID field(see Section 5.4.3) exists in a Message Body or not.

Msg-Format Ver.2 に 存 在 す る も の で あ る‘Attribute or Alert ID Field Flag’ は、Message Bodyに Attribute ID フィールド (5.3.3 項参照) か Alert
ID フィールド (5.4.3 項参照) かの何れかが存在するか否か指定すること。

An ‘Attribute or Alert ID Field Flag’ shall be one ofthe values listed in Table 5-5.

‘Attribute or Alert ID Field Flag’ は、Table 5-5 に示
す値の何れかにすること。

For each Telemetry Type, whether ‘Attribute or Alert
ID Field Flag’ is fixed at, or can be, either 0 or 1 is
specified (see Sections 5.3-5.6).

各 Telemetry Type に対し、‘Attribute or Alert ID
Field Flag’ が、0 か 1 の何れかであるか、または何れをも取り得るか、を定める (5.3〜5.6 項参照)。

Table 5-5: Allowed values for the ‘Attribute or Alert ID Field Flag’‘Attribute or Alert ID Field Flag’ に許容される値
Value

Meaning0

Neither an Attribute ID field nor Alert ID field exists in the Message
Body

1

Either of an Attribute ID field or Alert ID field exists in the Message
Body

Msg-Format Ver.2 の Telemetry Message Header は、‘Attribute or Alert ID Field Flag’ の値を保持するフィールド ( ‘Attribute or Alert ID Field Flag’ フィー
ルドと称する) を含むこと。

The Telemetry Message Header in Msg-Format Ver.2
shall contain a field referred to as an ‘Attribute or
Alert ID Field Flag’ field which holds the value of the‘Attribute or Alert ID Field Flag’.

55

JERG-2-700-TP002-NOTICE1
5.2.9.

Variable Part Length (field)

The Variable Part Length, which exists in Msg-Format
Ver.2, shall specify the octet length of the Variable Partof a Telemetry Message.

Msg-Format Ver.2 に存在するものである Variable
Part Length は、Telemetry Message の Variable Partの octet 長を指定すること。

[Rationale] The octet length of a Telemetry Message
in Msg-Format Ver.2 is, unlike in Msg-Format Ver.1,
expressed not by the octet length of the whole portionof the Telemetry Message but by that of the Variable
Part in the Telemetry Message. The octet length of the
Fixed Part is excluded from the value of the length
field in order to save the amount of the bits to express
the octet length.

[根拠] Msg-Format Ver.1 と違い、Msg-Format Ver.2の Telemetry Message の長さは Telemetry Message
全体の octet 長ではなく、Telemetry Message のVariable Part の octet 長で表現される。octet 長を表現するビット数を節約するために Fixed Part のoctet 長は長さフィールドの値から除外される。

A Telemetry Message Header in Msg-Format Ver.2
contains optionally a field referred to as a Variable Part
Length field. Note that the omission of the Variable
Part Length field shall be in the case where the
Variable Part Length is specified with a Lower-Layer
Protocol Dependent Scheme.

Msg-Format Ver.2 の Telemetry Message Header は、Variable Part Length フィールドと称するオプショ
ンのフィールドを含む。ここで、Variable Part
Length フィールドの省略は、Lower-Layer Protocol
Dependent Scheme により Variable Part Length が指定される場合に限ること。

[Example] In the cases [R2] is applied and theTelemetry Messages are embedded in Space Packets,
the Variable Part Length field can be omitted in 1)
Telemetry Messages with neither blocking nor
segmentation, 2) Telemetry Messages withsegmentation, and 3) the last Telemetry Message
contained in a Space Packet with blocking (see Section
3.4.2 in [R2]).

[例] [R2] を適用し、Telemetry Messages を Space
Packets に 収 納 す る 場 合 、 1) blocking もsegmentation の 何 れ も さ れ 無 い Telemetry
Messages, 2) segmentation さ れ る Telemetry
Messages, 及び 3) Space Packet に含まれる最後の blocking された Telemetry Message では、
VariablePart Length フィールドを省略してもできると定めている（[R2] 3.4.2 項参照）。

If the Variable Part Length Field Flag is 0, theTelemetry Message Header shall not contain a
Variable Part Length field. In this case, the octet lengthof the Telemetry Message shall be specified by afunction of lower-layer protocols.

Variable Part Length Field Flag が 0 の 場 合 、Telemetry Message Header は、Variable Part Length
フィールドを含まないこと。この場合、Telemetry
Message の octet 長は下位層プロトコルの機能で指定すること。

If the Variable Part Length Field Flag is 1, theTelemetry Message Header shall contain a Variable
Part Length field.

Variable Part Length Field Flag が 1 の 場 合 、Telemetry Message Header は Variable Part Length フィールドを含むこと。

The Variable Part Length field consists of the MSB
and the bit field excluding the MSB (see Table 5-6).
The value of the latter shall be the Variable Part
Length of the Telemetry Message.

Variable Part Length フィールドは、MSB と MSB
以外のビットフィールドとからなる (Table 5-6
参照)。後者の値は、Telemetry Message の Variable
Part Length であること。

56

JERG-2-700-TP002-NOTICE1
If the MSB of the Variable Part Length field is 0, thelength of the Variable Part Length field shall be 1
octet. In this case, the allowed range of the Variable
Part Length is 0-7Fh.

Variable Part Length フィールドの MSB が 0 の場
合、Variable Part Length フィールドの長さは 1octet であること。この場合、Variable Part Lengthの取り得る値は 0-7Fh となる。

If the MSB of the Variable Part Length field is 1, thelength of the Variable Part Length field shall be 2
octets. In this case, the allowed range of the Variable
Part Length is 0000h-7FFFh.

Variable Part Length フィールドの MSB が 1 の場
合、Variable Part Length フィールドの長さは 2octets であること。この場合、Variable Part Lengthの取り得る値は 0000h-7FFFh となる。

Table 5-6: Encoding of the Variable Part Length field
Variable Part Length フィールドのエンコード
Variable Part Length Field Flag
field: Variable Part Length field

Field Length

Valid Data Bits

Value Range of
Variable Part Length

1bit

0 bits0 (Ack.), depends onlower layer (Others)

1: 0xxxxxxx (*1)

1bit + 8bits

7 bits00h – 7Fh

1: 1xxxxxxx yyyyyyyy (*1)

1bit + 16bits

15 bits

0000h – 7FFFh

0:*1: Only for VALUE Telemetry, NOTIFICATION
Telemetry, and MEMERY DUMP Telemetry.

5.2.10.

*1: VALUE Telemetry, NOTIFICATION Telemetry,
及び MEMERY DUMP Telemetry についてに限る。

Examples / 例

Figure 5-2 gives a couple of examples of VALUE
Telemetry Messages (see Section 5.3.1) in MsgFormat Ver.2. For simplicity, none of the Telemetry
Message Headers shown in the figure contains a
Lower FOID field, which implies that their Lower
FOIDs are 0.

Figure 5-2 に 、 Msg-Format Ver.2 の VALUE
Telemetry Message (5.3.1 項参照) の例を幾つか示
す 。 単 純 化 の た め 、 こ の 図 で 示 す Telemetry
Message Headers は、何れも、Lower FOID フィー
ルドを含まない。この事は Lower FOID が 0 である事を意味する。

Among the Messages in the figure, case (1) is thesimplest one. This Message is designed to be stored ina single Space Packet with neither blocking nor
segmenting (see Figure 5-3 (1)) and does not containa Variable Part Length field. The Message Body does
not contain an Attribute ID field, and hence the octet
length of the Message is smaller than otherwise.
Accordingly, the Attribute ID of the Message is the
special value: 0.

図中の Messages のうち、ケース (1) が最もシンプ ル で あ る 。 こ の Message は 、 blocking もsegmenting の何れも無しに単一の Space Packet に格納する(Figure 5-3 (1) 参照)ために設計されたものであり、Variable Part Length フィールドは含
まない。Message Body は Attribute ID フィールドを含まず、その分 Message の octet 長は小さい。
そのために、Message の Attribute ID は、特別な値 0 である。

The Messages of cases (2) (3) are designed so that two
different Messages are stored in one Space Packet withblocking (see Figure 5-3 (2)). For example, the first
Message (case (2)) is for House Keeping Status for

ケース (2) (3) の Messages は、
一つの Space Packetに二種類の異なる Message を blocking し、収納するために設計されたものである(Figure 5-3 (2) 参照)。例えば、一つ目の Message（ケース (2) ）57

JERG-2-700-TP002-NOTICE1
は 毎 秒 の HK ス テ ー タ ス で あ り 、 二 つ 目 の
Message（ケース (3) ）は 16 秒毎にサブコミされた 16 個の異なる HK ステータスである。

every second and the second Message (case (3)) is for
sub-commuted 16 different House Keeping Status forevery 16 seconds.

Figure 5-2: Examples of VALUE Telemetry Messages in Msg-Format Ver.2
Msg-Format Ver.2 における VALUE Telemetry Messages の例

58

JERG-2-700-TP002-NOTICE1

Figure 5-3: Examples of Usage of Space Packets
Space Packets の使用例

The first Message (case (2)) contains a Variable Part
Length field in order to encode the position of the
Message that follows. In this example, 17 different
values of the Attribute IDs are used. In Msg-Format
Ver.2, the octet length of a Message can be shortened
if the value of an Attribute ID is 0. In this example, theallocated value of the Attribute ID of the first Message
is 0. This Message appears most frequently, and hence
the sum of the octet lengths of all Messages isminimized.

一つ目の Message（ケース (2) ）は、引き続く
Message の位置を示すために、Variable Part Length
フィールドを含んでいる。この例では 17 の異なる Attribute IDs の値が用いられている。MsgFormat Ver.2 では、Attribute ID の値が 0 の場合、Message の octet 長を短縮できる。この例では、一つ目の Message の Attribute ID の値が 0 である。
この Message は、最も頻度が高く登場するので、
全 Messages 合計での octet 長が最短となる。

The second Message (case (3)) does not contain
information of the octet length because the Message isthe last Message in the Space Packet. Non-zero
Attribute ID is encoded in order to hold information of
the phase of 16-second interval data.

二つ目の Message（ケース (3) ）は、一つの Space
Packet に含まれる最後の Message であるため、octet 長に関する情報を保持しない。ゼロでない
Attribute ID がエンコードされているため、16 秒
周期のデータの位相情報を保持するようになっている。

Even in the cases where only one Message is stored in
one Space Packet with neither blocking nor
segmenting, the format of case (3) is applied if the
Attribute ID is not 0 (see Figure 5-3 (3)).

単一の Space Packet に blocking も segmenting の何れも無しに一つの Message を収納する場合でも、Attribute ID が 0 以外であればケース (3) の形式を適用する (Figure 5-3 (3) 参照)。

59

JERG-2-700-TP002-NOTICE1

5.3.

VALUE TELEMETRY

5.3.1.

General // 一般
VALUE Telemetry は、Attribute Set (つまり Attribute
または Attribute Sequence の何れか、3.3.7 項参照)の値の伝送に用いること。

A VALUE Telemetry shall be used for transfer of thevalues of an Attribute Set (i.e. either an Attribute or an
Attribute Sequence, see Section 3.3.7).
VALUE

Functional Object は、VALUE Telemetries を生成すること。

Three kinds of VALUE Telemetry with regard to how
VALUE Telemetry are generated are defined:

VALUE Telemetry をどのように生成するかに関し、三種類の VALUE Telemetry が定義される。

a) Periodic VALUE Telemetry: Generated periodicallyat a pre-specified interval,a) Periodic VALUE Telemetry：予め定めた間隔で周期的に生成する。

b) Response VALUE Telemetry: Generated in
response to a received GET Telecommand, andb) Response VALUE Telemetry ： 受 信 し た GET
Telecommand に応答し生成する。

c) VALUE Change Telemetry: Generated when thevalue of an Attribute has changed.

c) VALUE Change Telemetry：Attribute の値が変更されたときに生成する。

The interval at which Periodic VALUE Telemetry is
generated may change, depending on the operation
mode of the Functional Object.

VALUE Telemetry の生成間隔は、Functional Objectの動作モードにより変わっても良い。

In a VALUE Change Telemetry, the term “Changenotify” refers to a status where change in the value ofan Attribute in the VALUE Change Telemetry ismonitored by the Functional Object.

VALUE Change Telemetry に お い て 、 “Changenotify” とは、その VALUE Change Telemetry に含
まれる Attribute の値の変化が、Functional Object
によりモニタされる事を指す。

When the value of an Attribute marked as “changenotify” has changed, a VALUE Telemetry containing
either the new value of the Attribute or the values of
the Attribute Sequence that contains the Attribute shallbe generated.

“Change-notify” と識別される Attribute の値が変更された場合、その Attribute の新しい値か、そのAttribute を含む Attribute Sequence の値かの何れかを含む VALUE Telemetry を生成すること。

[Note] The information of whether an Attribute ismarked as “change-notify” or not should be registeredin the SIB2. However, the specification about themethod for it has not been defined yet.

[注] 各 Attributes を“change-notify” と識別するか否かの情報は SIB2 に登録すべきだが、その方法の仕様はまだ定義されていない。

The SMCP Message which contains information of a
VALUE Telemetry is referred to as a VALUE
Telemetry Message.

VALUE Telemetry の情報を含む SMCP Message
を、VALUE Telemetry Message と称する。

A VALUE Telemetry Message shall follow the format
shown in Figure 5-4.

VALUE Telemetry Message は、Figure 5-4 に示すフォーマットに従うこと。

A Functional
Telemetries.

Objectshall

generate

60

JERG-2-700-TP002-NOTICE1
Msg-Format Ver.2 では、Message Time フィールド、
Attribute Values フィールド、及び Attachment フィールドのうち一つ以上存在する場合、それらフィー ル ド を も っ て VALUE Telemetry Message のVariable Part を構成すること。

In Msg-Format Ver.2, the Message Time field, theAttribute Values field, and the Attachment field shallconstitute the Variable Part of a VALUE Telemetry
Message if one or more of these fields exist.

Telemetry
Message Header

Attribute ID(5 octets)(2 octets)

Telemetry
Message Header(1~4 octets)

Attribute ID(optional)(0~2 octets)

Fixed Part

(Length depends on the Attribute Set)
Message Body
Message Time
Attribute Values(optional)(Length depends on(Length depends on
the Attribute Set)
the Attribute Set)(a) Msg-Format Ver.1(Length depends on the Attribute Set)
Message Body
Message Time
Attribute Values(optional)(Length depends on(Length depends on
the Attribute Set)
the Attribute Set)
Variable Part(b) Msg-Format Ver.2

Attachment(optional)(Length depends on
the Attribute Set)

Attachment(optional)(Length depends on
the Attribute Set)

Figure 5-4: VALUE Telemetry Message format
5.3.2.

Telemetry Message Header

See Section 5.2.

5.2 項参照。

The ‘Attribute or Alert ID Field Flag’, which exists in
Msg-Format Ver.2, in the VALUE Telemetry Message
is either 0 or 1 (see Table 5-5).

VALUE Telemetry Message では、Msg-Format Ver.2に存在するものである ‘Attribute or Alert ID Field
Flag’ は、0 か 1 の何れか (Table 5-5 参照) である。

The ‘Attribute or Alert ID Field Flag’ shall be either 0
or 1 (see Section 5.2.8) if the value of the Attribute ID
is 0 and shall be 1 otherwise.

‘Attribute or Alert ID Field Flag’ は、Attribute ID が0 の場合、 0 か 1 の何れかであること (5.2.8 項
参照)。それ以外の場合、1 であること。

The Variable Part Length Field Flag, which exists in
Msg-Format Ver.2, in the VALUE Telemetry Message
shall be either 0 or 1.

VALUE Telemetry Message では、Msg-Format Ver.2に存在するものである Variable Part Length Field
Flag は、0 か 1 の何れかであること。

61

JERG-2-700-TP002-NOTICE1
5.3.3.

Attribute ID (field)

In this section, the Attribute ID of the Attribute Set
whose value is held in the Attribute Values field (seeSection 5.3.5) is referred to simply as the Attribute ID.

本項では、Attribute Values フィールド (5.3.5 項参照) に値を保持する Attribute Set の Attribute ID
を、単に Attribute ID と称する。

The Message Body of a VALUE Telemetry Message
contains a field referred to as an Attribute ID field
which holds the value of the Attribute ID. The
exception is the case the Telemetry Message whose
Attribute ID is 0. In this case, the Attribute ID field is
not mandatory in Msg-Format Ver.2.

VALUE Telemetry Message の Message Body は、Attribute ID の値を保持するフィールド (Attribute
ID フ ィ ー ル ド と 称 す る ) を 含 む 。 た だ し 、Telemetry Message において Attribute ID が 0 の場合は例外である。この場合、Msg-Format Ver.2 では Attribute ID フィールドは必須ではない。

If the ‘Attribute or Alert ID Field Flag’ is 0, the
VALUE Telemetry Message shall not contain an
Attribute ID field. In this case, the Attribute ID is 0.

‘Attribute or Alert ID Field Flag’ が 0 の場合、
VALUE Telemetry Message は Attribute ID フィールドを含まないこと。この場合、Attribute ID は 0 である。

If the ‘Attribute or Alert ID Field Flag’ is 1, the
VALUE Telemetry Message shall contain an Attribute
ID field.

‘Attribute or Alert ID Field Flag’ が 1 の場合、
VALUE Telemetry Message は Attribute ID フィールドを含むこと。

If the MSB of the Attribute ID field in Msg-Format
Ver.2 is 0, the length of the Attribute ID field shall be
1 octet. In this case the allowed range of the Attribute
ID is 0-7Fh (see Table 5-7).

Msg-Format Ver.2 の Attribute ID フィールドのMSB が 0 の場合、Attribute ID フィールドの長さ
は 1 octet であること。この場合、Attribute ID の取り得る値は 0-7Fh となる (Table 5-7 参照)。

If the MSB of the Attribute ID field in Msg-Format
Ver.2 is 1, the length of the Attribute ID field shall be
2 octets. In this case the allowed range of the Attribute
ID is 8000h-FFFFh (see Table 5-7).

Msg-Format Ver.2 の Attribute ID フィールドのMSB が 1 の場合、Attribute ID フィールドの長さ
は 2 octets であること。この場合、Attribute ID の取り得る値は 8000h-FFFFh となる (Table 5-7 参
照)。

62

JERG-2-700-TP002-NOTICE1
Table 5-7: Encoding of the Attribute ID field
Attribute ID フィールドのエンコード
Attribute ID Flag field: Attribute
ID field

Field Length

Valid Data Bits

Value Range of Attribute
ID

1bit

0 bits0

1: 0xxxxxxx

1bit + 8bits

8 bits00h – 7Fh

1: 1xxxxxxx yyyyyyyy

1bit + 16bits

16 bits

8000h – FFFFh

0:

5.3.4.

Message Time (field)

A time specified for each VALUE Telemetry isreferred to as a Message Time.

VALUE Telemetry 毎 に 定 め る 時 刻 を Messages
Time と称する。

The time at which each value of the Attributes
contained in a VALUE Telemetry Message ismeasured shall be associated with the Message Time.

VALUE Telemetry Message に含まれたそれぞれのAttributes の値を測定した時刻を、Messages Timeに関連付けること。

The time difference between the measurement time ofeach value and the Message Time shall be determinedfor each Attribute ID.

それぞれの値の測定時刻と Message Time との時間差は、各 Attribute ID に対し決めること。

[Note 1] The value of a Message Time can be
described with the fields in a lower-layer protocol
and/or the optional Message Time field in the VALUE
Telemetry Message.

[注 1] Message Time の値は、下位層プロトコルのフィールドと VALUE Telemetry Message 内でオプションの Message Time フィールドの一方か双方により記術できる。

The Message Body of a VALUE Telemetry Message
may contain optionally a field referred to as a Message
Time field which holds the values of the Message
Time in the format, CCSDS Unsegmented Time Code(CUC), defined in [A2] if it exists.

VALUE Telemetry Message の Message Body は、[A2] が定義する CCSDS Unsegmented Time Code（CUC）のフォーマットによる Message Time の値を保持するオプションのフィールド (Message
Time フィールドと称する) を含んで良い。

[Note 2] If the Standard of Communications and DataHandling Architecture (SCDHA) [R1] is adopted, themethod to transfer Message Times with a lower-layer
protocol is specified in [R2].

[ 注 2] Standard of Communications and DataHandling Architecture（SCDHA）[R1] を採用する
場合、下位層プロトコルで Message Times を伝送する方法は [R2] が定める。

63

JERG-2-700-TP002-NOTICE1
5.3.5.

Attribute Values field

The Message Body of a VALUE Telemetry Message
shall contain a field referred to as an Attribute Values
field which holds the value of the Attribute Set (i.e.
either an Attribute or an Attribute Sequence; see
Section 3.3.7).

VALUE Telemetry Message の Message Body は、Attribute Set （ つ ま り 、 Attribute か Attribute
Sequence の何れか、3.3.7 項参照）の値を保持す
るフィールド (Attribute Values フィールドと称する) を含むこと。

The Attribute or Attribute Sequence whose values arecontained in the Attribute Values field shall be
specified for each Attribute ID.

Attribute Values フ ィ ー ル ド に 値 を 含 め る
Attributes または Attribute Sequence は、Attribute
ID 毎に定めること。

If the value of an Attribute Values field is the value
either of an Attribute or of an Attribute Sequence, thevalue of the Attribute ID is the identifier of the
Attribute or of the Attribute Sequence, respectively(see Section 5.3.3).

Attribute Values フィールドの値が、Attribute または Attribute Sequence の値の場合、Attribute ID の値は、それぞれ、その Attribute または Attribute
Sequence の識別子である (5.3.3 項参照)。

[Note 1] If the Attribute Values field is an Attribute
Sequence, (1) the Attribute ID of the Attribute
Sequence and (2) the Attributes whose values arecontained in the Attribute Sequence, are registered in
the definition part of the Attribute Sequence in the
SIB2.

[ 注 1] Attribute Values フ ィ ー ル ド が 一 つ の
Attribute Sequence である場合、(1) その Attribute
Sequence の Attribute ID, (2) そ の Attribute
Sequence に値を含める Attributes, を、SIB2 のその Attribute Sequence の定義部に登録する。

[Note 2] If the Attribute Values field is an Attribute,
the Attribute ID of the Attribute is registered in thedefinition part of the Attribute in the SIB2.

[ 注 2] Attribute Values フ ィ ー ル ド が 一 つ の
Attribute である場合、その Attribute に対する
Attribute ID を、SIB2 のその Attribute の定義部に登録する。

The bit length and encoding rule shall be specified foreach Attribute.

ビット長と符号化規則は、Attribute 毎に定めること。

[Note 3] The bit length and encoding rule areregistered in the definition part for each Attribute in
the SIB2.

[ 注 3] ビ ッ ト 長 と 符 号 化 規 則 は 、 SIB2 の 各
Attribute の定義部に登録する。

The maximum octet length of the Attribute Values
field shall be determined in each project (see Table C1).

Attribute Values フィールドの最大 octet 長は、。
project 毎に決めること（Table C-1 参照）

64

JERG-2-700-TP002-NOTICE1
5.3.6.

Attachment field

The Message Body of a VALUE Telemetry Message
may contain optionally a field referred to as an
Attachment field.

VALUE Telemetry Message の Message Body は、Attachment フィールドと称するオプションのフィールドを含んで良い。

An optional Attachment field, if the field exists, canconsists of any data (e.g. observation results) in any
formats related to one or more Attributes contained inthe VALUE Telemetry Message.

オプションの Attachment フィールドは、フィールドが存在する場合、VALUE Telemetry Messageに含まれた一つ以上の Attributes に関連する（観測結果等の）任意のフォーマットの任意のデータからなる事ができる。

The information of whether an Attachment field exists
or not, and, if it exists, its format shall be determinedfor each Attribute ID.

Attachment フィールドが存在するか否か、及び存在する場合はそれらのフォーマットは、Attribute
ID 毎に決めること。

The maximum octet length of the Attachment fieldshall be determined in each project (see Table C-1).

Attachment フィールドの最大 octet 長は、project毎に決めること（Table C-1 参照）。

[Note] Neither format nor encoding rule of
Attachment fields is registered in the SIB2.

[注] Attachment フィールドのフォーマットも符号化規則の何れも、SIB2 に登録しない。

65

JERG-2-700-TP002-NOTICE1

5.4.

NOTIFICATION TELEMETRY

5.4.1.

General // 一般

A classification of an event (an occurrence of athing that has a particular significance) that occurs
in a Functional Object is called an Event class ofthe Functional Object. Eevents of some Eventclasses are detected by a Functional Object. A
Functional Object has zero or more Event classes.
(see Section 3.5.1.1 in [A1])ある Functional Object で発生する event (特定の意味を有する出来事の発生) の分類を、その Functional
Object の Event class と呼ぶ。一部 Event classes のevents は、Functional Object で検出する。Functional
Object は、ゼロ個以上の Event classes を持つ。([A1]3.5.1.1 項参照)

Functional Objects can report to other entities anevent of an Event class that is important to them.
The report is called an alert and its classification iscalled an Alert class. If a Functional Object has afunction to notify an event as an alert, an Eventclass to which the notified event belongs and an
Alert class to which the corresponding alert
belongs are specified. A Functional Object has zeroor more Alert classes. (see Section 3.5.2.1 in [A1])

Functional Objects は、他の構成要素にとり重要な
Event class の event をそれらに通知できる。この通知を alert と呼び、その分類を Alert class と呼ぶ。ある Functional Object に event を alert として通知する機能を持たせる場合、通知する event が属する Eventclass と対応する alert が属する Alert class を定める。
Functional Object は、ゼロ個以上の Alert classes を持つ。 ([A1] 3.5.2.1 項参照)

A NOTIFICATION Telemetry shall be used totransfer an alert.

NOTIFICATION Telemetry は、alert の伝送に用いること。

A Functional Object shall generate a
NOTIFICATION Telemetry each time it detects anevent of an Event class that it has decided to notify
as an Alert.

Functional Object は、Alert として通知すると決めた
Event class の event を 検 出 す る た び に 、NOTIFICATION Telemetry を生成すること。

The SMCP Message which contains information ofa NOTIFICATION Telemetry is referred to as a
NOTIFICATION Telemetry Message.

NOTIFICATION Telemetry の 情 報 を 含 む SMCP
Message を、NOTIFICATION Telemetry Message と称する。

A NOTIFICATION Telemetry Message shallfollow the format shown in Figure 5-5.

NOTIFICATION Telemetry Message は、Figure 5-5 に示すフォーマットに従うこと。

In Msg-Format Ver.2, the Parameters and Attribute
Values field shall constitute the Variable Part of the
NOTIFICATION Telemetry Message if the field
exists.

Msg-Format Ver.2 においては、Parameters and Attribute
Values フィールドが存在する場合、そのフィールドを も っ て NOTIFICATION Telemetry Message のVariable Part を構成すること。

66

JERG-2-700-TP002-NOTICE1

Telemetry Message Header(5 octets)

Telemetry Message Header(1~4 octets)(Length depends on the Alert
Message Body
Alert ID
Parameters and Attribute Values (optional)(2 octets)(Length depends on the Alert)(a) Msg-Format Ver.1(Length depends on the Alert
Message Body
Alert ID (optional)(0~2 octets)

Fixed Part

Parameters and Attribute Values (optional)(Length depends on the Alert)
Variable Part(b) Msg-Format Ver.2

Figure 5-5: NOTIFICATION Telemetry Message format
5.4.2.

Telemetry Message Header

See Section 5.2.

5.2 項参照。

The ‘Attribute or Alert ID Field Flag’, which exists in
Msg-Format Ver.2, in the NOTIFICATION Telemetry
Message is either 0 or 1 (see Table 5-5).

NOTIFICATION Telemetry Message で は 、 MsgFormat Ver.2 に存在するものである‘Attribute or
Alert ID Field Flag’ は、0 か 1 の何れか (Table 5-5参照) である。

The ‘Attribute or Alert ID Field Flag’ shall be either 0
or 1 (see Section 5.2.8) if the value of the Alert ID is 0
and shall be 1 otherwise.

‘Attribute or Alert ID Field Flag’ は、Alert ID が 0の場合 0 か 1 の何れかであること (5.2.8 項参照)。それ以外の場合、1 であること。

The Variable Part Length Field Flag which exists in
Msg-Format Ver.2 in the NOTIFICATION Telemetry
Message, shall be either 0 or 1 (see Table 5-3).

NOTIFICATION Telemetry Message で は 、 MsgFormat Ver.2 に存在するものである Variable Part
Length Field Flag は、0 か 1 の何れか (Table 5-3 参照) であること。

5.4.3.

Alert ID (field)

An alert which is transferred by a Notification
Telemetry shall have an identifier referred to as Alert
Identifier (Alert ID), which identifies the Alert class of
the alert.

Notification Telemetry が伝送する alert は、そのalert が属する Alert class を識別するものである
Alert Identifier (Alert ID) と称する識別子を持つこと。

The Alert IDs shall be unique within the Functional
Object.

Alert IDs は、その Functional Object 内で一意に決まること。

An Alert ID shall be a 16-bit integer.

Alert ID は、16-bit の整数であること。

67

JERG-2-700-TP002-NOTICE1
The Message Body of a NOTIFICATION Telemetry
Message contains a field referred to as an Alert ID
field which holds the value of the Alert ID. The
exception is the case the Telemetry Message whose
Alert ID is 0. In this case, the Alert ID field is notmandatory in Msg-Format Ver.2.

NOTIFICATION Telemetry Message の Message
Body は、Alert ID の値を保持するフィールド(Alert ID フィールドと称する) を含む。ただし、Telemetry Message において Alert ID が 0 の場合は例外である。この場合、Msg-Format Ver.2 では、Alert ID フィールドは必須ではない。

[Note] A NOTIFICATION Telemetry cannot containmore than one Alert (see Section 5.4.1).

[注] 一つの NOTIFICATION Telemetry は、一つを超える Alert を含む事はできない (5.4.1 項参照)。

If the ‘Attribute or Alert ID Field Flag’ is 0, theNOTIFICATION Telemetry Message shall notcontain an Alert ID field. In this case, the value of theAlert ID is 0.

‘Attribute or Alert ID Field Flag’ が 0 の場合、
NOTIFICATION Telemetry Message は Alert ID フ
ィールドを含まないこと。この場合、Alert ID の値は 0 である。

If the ‘Attribute or Alert ID Field Flag’ is 1, theNOTIFICATION Telemetry Message shall contain an
Alert ID field.

‘Attribute or Alert ID Field Flag’ が 1 の場合、
NOTIFICATION Telemetry Message は Alert ID フ
ィールドを含むこと。

If the MSB of the Alert ID field in Msg-Format Ver.2
is 0, the length of the Alert ID field shall be 1 octet. In
this case, the allowed range of the Alert ID is 0-7Fh(see Table 5-8).

Msg-Format Ver.2 の Alert ID フィールドの MSB
が 0 の場合、Alert ID フィールドの長さは 1 octet
であること。この場合、Alert ID の取り得る値は0-7Fh となる (Table 5-8 参照)。

If the MSB of the Alert ID field in Msg-Format Ver.2
is 1, the length of the Alert ID field shall be 2 octets.
In this case, the allowed range of the Alert ID is 8000h-FFFFh (see Table 5-8).

Msg-Format Ver.2 の Alert ID フィールドの MSB
が 1 の場合、Alert ID フィールドの長さは 2 octets
であること。この場合、Alert ID の取り得る値は8000h -FFFFh となる (Table 5-8 参照)。

Table 5-8: Encoding of the Alert ID field
Alert ID フィールドのエンコード
Alert ID Flag field: Alert ID field

Field Length

Valid Data Bits

Value Range of Alert ID

1bit

0 bits0

1: 0xxxxxxx

1bit + 8bits

8 bits00h – 7Fh

1: 1xxxxxxx yyyyyyyy

1bit + 16bits

16 bits

8000h – FFFFh

0:

5.4.4.

(reserved)

68

JERG-2-700-TP002-NOTICE1
5.4.5.

Parameters and Value Notifing Attributes (Parameters and Attribute Values field)

If an alert has Parameters and/or Value Notifing
Attributes associated with it (defined in [A1],parameters), the values of the Parameters and/or Value
Notifing Attributes shall be transferred on the
NOTIFICATION Telemetry which reports the alert.

alert が関連する Parameters 及び・または Value
Notifing Attributes ([A1] で定義、パラメータ) を持つ場合、その Parameters 及び・または Value
Notifing Attributes の値を、その alert を通知する
NOTIFICATION Telemetry にて伝送すること。

If an alert has one or more Parameters and/or Value
Notifing Attributes associated with it, the Message
Body of a NOTIFICATION Telemetry Message which
reports the alert shall contain a field referred to as aParameters and Attribute Values field and theParameters and Attribute Values field shall consist of
the sub-fields which hold the values of all the
Parameters and/or Value Notifing Attributes.

alert が関連する Parameters 及び・または Value
Notifing Attributes を一つ以上持つ場合、その alertを通知する NOTIFICATION Telemetry Message のMessage Body は、Parameters and Attribute Values フィールドと称するフィールドを含むこと。また、全ての Parameters 及び・または Value Notifing
Attributes の値を保持するサブフィールドによりParameters and Attribute Values フィールドを構成すること。

Otherwise, the Parameters and Attribute Values fieldshall be omitted.

さもなければ、Parameters and Attribute Values フィールドは省略すること。

The sub-fields of the Parameters and/or Value Notifing
Attributes whose values are contained in a Parametersand Attribute Values field shall be specified for each
Alert class. The bit length and encoding rule shall be
specified for each Parameter.

Parameters and Attribute Values フィールドに含まれ る Parameters 及 び ・ ま た は Value Notifing
Attributes のサブフィールドは、Alert class 毎に定めること。また、Parameter 毎にビット長と符号化規則を定めること。

[Note 1] The definitions for the sub-fields of theParameters whose values are contained in a
NOTIFICATION Telemetry Message (e.g. their bit
lengths and encoding rules) are registered in thedefinition part for each Alert class in the SIB2.

[注 1] NOTIFICATION Telemetry Message に値を含める Parameters のサブフィールドの定義（例えば、ビット長や符号化規則）は、SIB2 の各 Alertclass の定義部に登録する。

[Note 2] The Attributes whose values are contained ina NOTIFICATION Telemetry Message are registeredin the definition part for each Alert class in the SIB2.

[注 2] NOTIFICATION Telemetry Message に値を含める Attributes は、SIB2 の各 Alert class の定義
部に登録する。

The bit length and encoding rule of the sub-fields of
the Value Notifing Attributes shall be specified foreach Attribute.

Value Notifing Attributes のサブフィールドビット
長と符号化規則は、Attribute 毎に定めること。

The maximum octet length of the Parameters andAttribute Values field shall be determined in eachproject (see Table C-1).

Parameters and Attribute Values フィールドの最大
octet 長は project 毎に決めること（Table C-1 参
照）
。

69

JERG-2-700-TP002-NOTICE1

5.5.

ACK TELEMETRY

5.5.1.

General // 一般

An Acknowledgement Telemetry (ACK Telemetry)shall be used for notifying (i.e. acknowledging) aController that a SMCP Telecommand which theController sent has been received.

Acknowledgement Telemetry (ACK Telemetry) は、Controller が送信した SMCP Telecommand を受信した事を、その Controller に通知（つまり、アクノリッジ）するのに用いること。

[Note 1] Whether a SMCP Telecommand has beencorrectly executed or not can be verified with theprocedures described in Notes in the sub-sections inwhich the corresponding Telecommand Type isdefined.

[注 1] SMCP Telecommand が正しく実行されたか否かは、該当する Telecommand Type を定義する
項の「注」に記す手順で検証できる。

Whether a Functional Object has the capability togenerate ACK Telemetries or not shall be determinedfor each Functional Object.

Functional Object に ACK Telemetries を生成する能力があるか否かは、Functional Object 毎に決めること。

[Note 2] Whether a Functional Object has thecapability to generate ACK Telemetries or not isregistered in the definition part for each Functional
Object in the SIB2.

[注 2] Functional Object に ACK Telemetries を生成する能力があるか否かは、SIB2 の各 Functional
Object の定義部に登録する。

If a Functional Object does not have the capability togenerate ACK Telemetries, the Functional Object
shall ignore the ACK Request of the received SMCP
Telecommand (see Section 4.2.2).

ある Functional Object に ACK Telemetries を生成する能力がない場合、その Functional Object は、受信した SMCP Telecommand (4.2.2 項参照）のACK Request を無視すること。

The value of the ACK Request is either 1 (meaning
requested) or 0 (meaning not requested) (see Section
4.2.2). If the value is 1, and if a Functional Object has
the capability to generate ACK Telemetries, theFunctional Object shall generate an ACK Telemetry
for the SMCP Telecommand. If not, no ACK
Telemetry shall be generated.

ACK Request の値は、1 (要求する) か 0 (要求しない) かの何れかである (4.2.2 項参照）
。値が 1であり、Functional Object に ACK Telemetries を生成する能力がある場合、
その Functional Object は、
その SMCP Telecommand に対し ACK Telemetry を生成すること。さもなければ、ACK Telemetry を生成しないこと。

The SMCP Message which contains information of an
ACK Telemetry is referred to as ACK Telemetry
Message.

ACK Telemetry の情報を含む SMCP Message を、
ACK Telemetry Message と称する。

An ACK Telemetry Message shall follow the format
shown in Figure 5-6.

ACK Telemetry Message は、Figure 5-6 に示すフォーマットに従うこと。

In Msg-Format Ver.2, the Variable Part of an ACK
Telemetry Message shall be absent.

Msg-Format Ver.2 では、ACK Telemetry Message のVariable Part は、存在しないこと。

70

JERG-2-700-TP002-NOTICE1(7 octets)
Message Body
Telemetry Message Header

Telecommand
Message ID(5 octets)(2 octets)(a) Msg-Format Ver.1(3 or 4 octets)

Telemetry Message Header(1~2 octets)

Message Body
Telecommand
Message ID(2 octets)

Fixed Part(b) Msg-Format Ver.2

Figure 5-6: ACK Telemetry Message format
5.5.2.

Telemetry Message Header

See Section 5.2.

5.2 項参照。

The ‘Attribute or Alert ID Field Flag’, which exists in
Msg-Format Ver.2, in the ACK Telemetry Messages
shall be 0 (see Table 5-5).

ACK Telemetry Message では、Msg-Format Ver.2 に存在 する もの で ある‘Attribute or Alert ID Field
Flag’ は、0 (Table 5-5 参照) であること。

The Variable Part Length Field Flag, which exists in
Msg-Format Ver.2, in the ACK Telemetry Messages
shall be 0 (see Table 5-3).

ACK Telemetry Message では、Msg-Format Ver.2 に存在するものである Variable Part Length Field Flag
は、0 (Table 5-3 参照) であること。

5.5.3.

Telecommand Message ID field

The Message Body of an ACK Telemetry Message
shall contain a field referred to as a Telecommand
Message ID field.

ACK Telemetry Message の Message Body は 、Telecommand Message ID フィールドと称するフィールドを含むこと。

The value of a Telecommand Message ID field shallbe the value of the Telecommand Message ID of the
SMCP Telecommand (see Section 4.2.1) that has been
received.

Telecommand Message ID フィールドの値は、受信した SMCP Telecommand の Telecommand Message
ID の値 (4.2.1 項参照) であること。

71

JERG-2-700-TP002-NOTICE1

5.6.

MEMORY DUMP TELEMETRY

5.6.1.

General // 一般

The MEMORY DUMP Telemetry shall be used forsending memory data in response to a received
MEMORY DUMP Telecommand.

MEMORY DUMP Telemetry は 、 受 信 し た
MEMORY DUMP Telecommand に応答してメモリ
データの送付に用いること。

Upon receiving a MEMORY DUMP Telecommand, aMemory Functional Object shall send back therequested memory data, using one or more MEMORYDUMP Telemetries (see Section 4.7.4).

Memory Functional Object は、MEMORY DUMP
Telecommand を 受 信 す る と 、 一 つ 以 上 のMEMORY DUMP Telemetries を用い、要求された（4.7.4 項参照）
メモリデータを返送すること。

The data shall be read out from the contiguous
memory area and be sent with one or more MEMORYDUMP Telemetries. The octet length and the first
address of the memory area shall be the values
specified in the received MEMORY DUMP
Telecommand. If not all of the data can be sent with
one MEMORY DUMP Telemetry, the data shall be
split into multiple MEMORY DUMP Telemetries,
each of which contains non-overlapping data, and besent.

データは、連続したメモリ領域から読み出し、一つ以上の MEMORY DUMP Telemetries にて送信すること。メモリ領域の octet 長と最初のアドレ
スは、受信した MEMORY DUMP Telecommand で
指 定 さ れ た 値 で あ る こ と 。 一 つ の MEMORYDUMP Telemetry で全てのデータを送信できない
場合は、データを、それぞれが重複しないデータ
を含む複数の MEMORY DUMP Telemetries に分割し、送ること。

The requested data shall be sent the number of times
specified in the MEMORY DUMP Telecommand (seeSection 4.7.6).

要 求 さ れ た デ ー タ は 、 MEMORY DUMP
Telecommand で指定された回数送ること。（4.7.6
項参照）

The SMCP Message which contains information of a
MEMORY DUMP Telemetry is referred to as a
MEMORY DUMP Telemetry Message.

MEMORY DUMP Telemetry の情報を含む SMCP
Message を、MEMORY DUMP Telemetry Messageと称する。

A MEMORY DUMP Telemetry Message shall follow
the format shown in Figure 5-7.

MEMORY DUMP Telemetry Message は、Figure 5-7に示すフォーマットに従うこと。

In Msg-Format Ver.2, the Dump Data field shallconstitute the Variable Part of a MEMORY DUMP
Message.

Msg-Format Ver.2 では、Dump Data フィールドが、MEMORY DUMP Message の Variable Part を構成
すること。

72

JERG-2-700-TP002-NOTICE1

Telemetry
Message Header(5 octets)

MemorySegment Flags(2 bits)(Length depends on the Message)
Message Body
Additional Dump
Reserved
Start AddressCount(4 bits)(2 bits)

Dump Data(4 octets)(Length depends on
the Message)

Dump Data(a) Msg-Format Ver.1

Telemetry
Message Header(1~4 octets)(Length depends on the Message)
Message Body
MemorySegment Flags

Reserved

Additional Dump
Count

Start Address(2 bits)(4 bits)(2 bits)(4 octets)

Fixed Part(b) Msg-Format Ver.2(Length depends on
the Message)
Variable Part

Figure 5-7: MEMORY DUMP Telemetry Message format
The field marked as “Reserved” shall not be used
and be filled with zeros.

5.6.2.

“Reserved”となっているフィールドは、使用を避け、ゼロで埋めること。

Telemetry Message Header

See Section 5.2.

5.2 項参照。

The ‘Attribute or Alert ID Field Flag’, which exists in
Msg-Format Ver.2, in the MEMORY DUMP
Telemetry Message shall be 0 (see Table 5-5).

MEMORY DUMP Telemetry Message では、MsgFormat Ver.2 に存在するものである‘Attribute or
Alert ID Field Flag’ は、0 (Table 5-5 参照) であること。

The Variable Part Length Field Flag, which exists in
Msg-Format Ver.2, in the MEMORY DUMP
Telemetry Message shall be either 0 or 1 (see Table
5-3).

MEMORY DUMP Telemetry Message では、MsgFormat Ver.2 に存在するものである Variable Part
Length Field Flag は、0 か 1 の何れか (Table 5-3 参照) であること。

73

JERG-2-700-TP002-NOTICE1
5.6.3.

Memory Segment Flags (field)

The Memory Segment Flags shall indicate whether
the memory data specified in a received MEMORYDUMP Telecommand are sent in a single MEMORYDUMP Telemetry or are split and sent in multiple
MEMORY DUMP Telemetries. Furthermore, in thecase of the latter, the Memory Segment Flags shallindicate whether the data contained in this MEMORYDUMP Telemetry Message is locating at either the
first segment, an intermediate segment, or the last
segment of the entire memory data to be sent.

Memory Segment Flags は、受信した MEMORYDUMP Telecommand が指定したメモリデータを
単一の MEMORY DUMP Telemetry で送信するか、分割して複数の MEMORY DUMP Telemetries で送信するかを示すこと。さらに、後者の場合、Memory Segment Flags は、本 MEMORY DUMP
Telemetry Message に含めるデータが、送信する全
データのうちで、最初のセグメントか 、中間セグメントか、最後のセグメントかの何れに位置するかも示すこと。

Memory Segment Flags shall be one of the values
listed in Table 5-9.

Memory Segment Flags は、Table 5-9 に示す値の何れかであること。

Table 5-9: Allowed values for the Memory Segment Flags
Memory Segment Flags に許容される値
Value

Meaning

0

DUMP Data field consists of an intermediate segment of the memory
data only.

1

DUMP Data field consists of the first segment of the memory data
only.

2

DUMP Data field consists of the last segment of the memory data
only.

3

DUMP Data field consists of the entire data only (i.e., the data are notsplit into multiple MEMORY DUMP Messages).

MEMORY DUMP Telemetry Message の Message
Body は、Memory Segment Flags の値を保持する
フィールド (Memory Segment Flags フィールドと称する) を含むこと。

The Message Body of a MEMORY DUMP Telemetry
Message shall contain a field referred to as a Memory
Segment Flags field which holds the value of theMemory Segment Flags.

74

JERG-2-700-TP002-NOTICE1
5.6.4.

Additional Dump Count (field)

The Additional Dump Count shall be an integer n-1
when this is the n-th transmission of the identical data.

Additional Dump Count は、同一データの n 回目の送信の場合、整数 n-1 であること。

[Note] As specified in Section 4.7.6, the same data canbe sent multiple times. If the value of the Additional
Dump Count is 0, this is the first transmission of thedata. If the value of the Additional Dump Count is 1,
this is the second transmission of the same data. If thedata are sent only once, the value of the Additional
Dump Count is 0.

[注] 4.7.6 項が定めるように、同じデータを複数回送る事ができる。Additional Dump Count の値が0 の場合、データの最初の送信である。Additional
Dump Count の値が 1 の場合、同じデータの 2 回目の送信である。データを一度だけ送信する場
合、Additional Dump Count の値は 0 である。

The Message Body of a MEMORY DUMP Telemetry
Message shall contain a field referred to as an
Additional Dump Count field which holds the value ofthe Additional Dump Count.

MEMORY DUMP Telemetry Message の Message
Body は、Additional Dump Count の値を保持する
フィールド (Additional Dump Count フィールドと称する) を含むこと。

75

JERG-2-700-TP002-NOTICE1
5.6.5.

Start Address (field)

The Start Address shall specify the first address of thedata contained in a Dump Data field.

Start Address は、Dump Data フィールドに入れる
データの最初のアドレスを指定すること。

The method to map a Start Address to a physicaladdress of a memory shall be determined for each
Memory Functional Object (identified by the FOID).

Start Address をメモリの物理アドレスにマッピングする方法は、Memory Functional Object（FOID により識別する）毎に決めること。

[Note] The StartAddress of a MEMORY DUMP
Telemetry specifies the first address of the memory
data contained in the MEMORY DUMP Telemetry.
Accordingly, in the cases where the memory data
requested by a MEMORY DUMP Telecommand are
split and sent in multiple MEMORY DUMP
Telemetries, the value of the StartAddress of any but
the first one of the generated MEMORY DUMP
Telemetry does not coincide with that of theStartAddress in the received MEMORY DUMP
Telecommand.

[注] MEMORY DUMP Telemetry の StartAddress には、その MEMORY DUMP Telemetry に入るメモ
リデータの最初のアドレスを指定する。したがって、MEMORY DUMP Telecommand により要求されたメモリデータが分割され複数の MEMORYDUMP Telemetries にて送信された場合、最初に生成された MEMORY DUMP Telemetry を除き、StartAddress の値は、受信した MEMORY DUMP
Telecommand の StartAddress の値と一致しない。

The Message Body of a MEMORY DUMP Telemetry
Message shall contain a field referred to as a Start
Address field which holds the value of the Start
Address.

MEMORY DUMP Telemetry Message の Message
Body は、Start Address の値を保持するフィールド
(Start Address フィールドと称するフィールド)を含むこと。

5.6.6.

Dump Data field

The Message Body of a MEMORY DUMP Telemetry
Message shall contain a field referred to as a Dump
Data field.

MEMORY DUMP Telemetry Message の Message
Body は、Dump Data フィールドと称するフィールドを含むこと。

A Dump Data field shall consist only of the memory
data to transfer.

Dump Data フィールドには、伝送するメモリデー
タのみからなること。

The maximum octet length of the Dump Data fieldshall be determined in each project (see Table C-1).

Dump Data フィールドの最大 octet 長は、project毎に決めること（Table C-1 参照）。

76

JERG-2-700-TP002-NOTICE1

APPENDIX A. ACRONYMS // 略語
This chapter lists the acronyms used in thisdocument.
ACK
APID
CRC
FOID
GSTOS
ID
PCI
SIB
SCDHA
SMCP
UFORID

本章では、本書が用いる略語一覧を示す。

Acknowledgement
Application Process Identifier
Cyclic Redundancy Check
Functional Object Identifier
Generic Spacecraft Test and Operations Software
Identifier
Protocol Control Information
Spacecraft Information BaseStandard of Communications and Data-Handling ArchitectureSpacecraft Monitor and Control Protocol
Upper Functional Object and Route Identifier

77

JERG-2-700-TP002-NOTICE1

APPENDIX B. TELECOMMAND-TELEMETRY INTERACTIONS(SUPPLEMENT) // TELECOMMAND 対 TELEMETRY 相互作用（参考
情報）
B.1.

GENERAL // 一般This informative annex summarizes the interactions
between SMCP Telecommands and SMCP
Telemetries.

B.2.

ACKNOWLEDGEMENT
SMCP Telecommand と ACK Telemetries の間の相互作用は 5.5.1 項に定める。

The interactions between SMCP Telecommand and
ACK Telemetries are specified in Section 5.5.1.

B.3.
B.3.1.

ACTION TELECOMMAND
General // 一般
Functional Object は、ACTION Telecommand を受信したときに、B.3.2 項及び/または B.3.3 項に記すアクションを行うこと。

A Functional Object shall perform actions describedin Sections B.3.2 and/or B.3.3 when it receives an
ACTION Telecommand.

B.3.2.

本 付 録 で は 、 SMCP Telecommands と SMCP
Telemetries の間の相互作用を要約する。

Response with Periodic VALUE Telemetry // Periodic VALUE Telemetry による応答

A Functional Object does not generate any special
SMCP Telemetry in executing an ACTION
Telecommand. It generates VALUE Telemetries
periodically (Periodic VALUE Telemetry, see Section
5.3.1) whether it has received an ACTION
Telecommand or not.

Functional Object は、ACTION Telecommand の実
行時に特別な SMCP Telemetry を生成しない。
ACTION Telecommand を受信したか否かにかか
わらず、VALUE Telemetries を周期的に生成する（Periodic VALUE Telemetry、5.3.1 項参照）。

A Controller can verify whether the ACTION
Telecommand that it sent has been executed or not byreceiving Periodic VALUE Telemetries and thenchecking changes in the values of the Attributes thatare supposed to change as a result of the executed
Operation specified by the ACTION Telecommand(see Figure B-1).

Controller は、Periodic VALUE Telemetries を受信し、ACTION Telecommand が指定した Operationの実行の結果変化するであろう Attributes の値の変化をチェックする事で、送信された ACTION
Telecommand が実行されたか否かを検証できる（Figure B-1 参照）。

78

JERG-2-700-TP002-NOTICE1
TargetController
ACTION Telecommand(Functional Object)

Figure B-1: Response with Periodic VALUE Telemetry
Periodic VALUE Telemetry による応答

B.3.3.

Response with VALUE Change Telemetry // VALUE Change Telemetry による応答

Once a Functional Object has executed the Operation
specified by an ACTION Telecommand from aController, the Functional Object notifies theController of the execution result by sending VALUE
Change Telemetries (see Section 5.3.1) containing thevalues of the Attributes that have changed as a resultof the Operation (see Figure B-2).

Functional Object は、Controller からの ACTION
Telecommand が指定した Operation を実行すると、Operation の結果として変化した Attributes 値を含
む VALUE Change Telemetries（5.3.1 項参照）を送る事で、実行結果をその Controller に通知する（Figure B-2 参照）。

The Functional Object may send multiple VALUE
Change Telemetries if the values of multiple Attributeschange as a result of the Operation. It may send
multiple VALUE Change Telemetries all of whichhave an identical Attribute ID, if the values ofAttributes change multiple times in the course of
executing the Operation.

Functional Object は、Operation の結果として、複数の Attributes 値が変化した場合、複数の VALUE
Change Telemetries を送っても良い。Operation の実行中に Attributes 値が複数回変化した場合、全てが同一の Attribute ID を持つ複数の VALUE
Change Telemetries を送っても良い。

A Controller can verify whether the ACTION
Telecommand that it sent has been executed or not, if
it has received VALUE Change Telemetries, bychecking whether the values of the Attributes that aresupposed to change have changed expectedly or not(see Figure B-2).

Controller は、VALUE Change Telemetries を受信した場合、変化が予想される Attributes の値が期待通りに変化したか否かをチェックする事で、送信した ACTION Telecommand が実行されたか否かを検証できる（Figure B-2 参照）。

Controller

ACTION
Telecommand

Target(Functional Object)

Figure B-2: Response with VALUE Change Telemetry
VALUE Change Telemetry による応答

79

JERG-2-700-TP002-NOTICE1

B.4.

GET TELECOMMAND

B.4.1.

General // 一般
Functional Object は、GET Telecommand を受信したときに、B.4.2 項に記すアクションを行うこと。

A Functional Object shall perform the action
described in Section B.4.2 when it receives a GET
Telecommand.

B.4.2.

Response with Response VALUE Telemetry // Response VALUE Telemetry による応答
Functional Object は、GET Telecommand により要求された一つの Attribute Set (つまり Attribute ま
たは Attribute Sequence の何れか、
3.3.7 項参照) の値を含む一つの Response VALUE Telemetry（5.3.1
項参照）を生成すること（Figure B-3 参照）。

A Functional Object shall generate a Response
VALUE Telemetry (see Section 5.3.1) containing thevalue of the Attribute Set (i.e. either an Attribute or an
Attribute Sequence, see Section 3.3.7) requested by
the GET Telecommand (see Figure B-3).

TargetController

GET Telecommand (Functional Object)

Figure B-3: Response with Response VALUE Telemetry
Response VALUE Telemetry による応答

B.5.

SET TELECOMMAND

In the sense of the interactions between SMCP
Telecommands and SMCP Telemetries, the SET
Telecommand is the same as the ACTION
Telecommand.

80

SMCP Telecommands と SMCP Telemetries の間の相互作用の意味において、SET Telecommand は
ACTION Telecommand と同じである。

JERG-2-700-TP002-NOTICE1

APPENDIX C. MANAGED PARAMETERS
The values of the managed parameters are listed inTable C-1.

managed parameters の値を Table C-1 に示す。

[Note] The allowed values listed in the table reflect thelimit set by the SMCP only. In practice, restriction is
imposed due to the specifications of lower-layer
protocols (e.g. see [R2]).

[注] 本表の許容値は SMCP のみの限界によるものである。実際の許容値は、下位層プロトコルの仕様により制約される ([R2] 等参照）。

Table C-1: List of the Managed Parameters
Managed Parameters の表Managed Parameters

Section inThis
Document

Allowed Values

Unit

Maximum octet length of the Parameters andAttribute Values field of an ACTION
Telecommand Message

4.3.4

Integer

Octet

Maximum octet length of the Attribute Values
field of a SET Telecommand Message

4.5.7

Integer

Octet

Maximum octet length of the Load Data field of a
MEMORY LOAD Telecommand Message

4.6.7

Integer

Octet

Maximum value allowed for the Data Length fieldof a MEMORY DUMP Telecommand Message

4.7.8

Integer(up toFFFFFFh)

Octet

Maximum value for the sum of the bit lengths ofthe ‘Attribute Values and Attachment’ fields of a
VALUE Telemetry Message

5.3.5 and
5.3.6

Integer(up to FFFFF8h)

Octet

Maximum value for the sum of the bit lengths of
the Parameters and Attribute Values field of a
NOTIFICATION Telemetry Message

5.4.5

Integer (*1)

Octet

Maximum octet length of the Dump Data field ofa MEMORY DUMP Telemetry Message

5.6.6

Integer (*1)Octet(*1) Msg-Format Ver.2 を用いる場合、無制限。.
Msg-Format Ver.1 のみを用いる場合、「Message
Length フィールドの限界により決まる最大長」: FFFFF8h よりも小さな値。

(*1) Unlimited if Msg-Format Ver.2 is used. Valuesmaller than the ‘Maximum Length determined by
the limit of Message Length fields’: FFFFF8h if
only Msg-Format Ver.1 is used.

81

JERG-2-700-TP002-NOTICE1

APPENDIX D. HISTORY OF TERMINOLOGY CHANGES
用語の変更の履歴
NOTICE-1:
Action Telecommand
Renamed a field // フィールドの名前を変更した• From: Parameters field• To: Parameters and Attribute Values field
Notification Telemetry
Merged two fields into one field // 二つのフィールドを一つのフィールドにマージした• From Parameters field and Attribute Values field• To: Parameters and Attribute Values field82