JERG-2-432
限定なしSpaceWire オンボードサブネットワーク
設計標準

平成 28 年 5 月 20 日制定

宇宙航空研究開発機構

免責条項
ここに含まれる情報は、一般的な情報提供のみを目的としています。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-432

本文書における ECSS からの引用については、ECSS 事務局との取り決めにより以下のとおりとなっている。
"This JAXA standard contains in whole or in part a quotation of ECSS standard no. ECSSE-ST-50-52C: SpaceWire-Remote memory access protocol (5 February 2010) with special
permission of ECSS and ESA. The original English version of the ECSS standard isavailable from:
ECSS Secretariat
P.O. Box 299
2200 AG Noordwijk
77le Netherlands
Tel.: +31-71-5655748
F a x: +31-71-5656839
E-mail: ECSS-Secretariat@esa.int
Website: http://www.ecss.nl
The content of this JAXA standard including any quotations of ECSS documents in thisstandard is the sole responsibility of JAXA.
A list of the quotations from ECSS standards is attached to this JAXA standard.
ECSS does not provide any warranty whatsoever, whether express, implied, or statutory,
including, but not limited to, any warranty of merchantability or fitness for aparticular purpose or any warranty that the contents of its standards and its quotations
are error-free.
In no respect shall ECSS incur any liability for any damages resulting from applicationof ECSS standards or JAXA standards containing quotations in whole or in part from ECSS
standards".
この JAXA 標準は、ECSS 及び ESA の特別な了解を得た上で､ECSS-E-ST-50-52C の全体又は部分を引用している。ECSS 標準のオリジナル英語版は､以下から入手可能である。
P.O. Box 299
2200 AG Noordwijk
77le Netherlands
Tel.: +31-71-5655748
F a x: +31-71-5656839
E-mail: ECSS·Secretariat@esa.int
Website: http://www.ecss.nl
この標準への ECSS 文書の引用を含めた JAXA 標準の内容についての責任は JAXA のみにある。
ECSS 標準からの引用箇所のﾘｽﾄはこの JAXA 標準に添付される。
ECSS は､市販性(販売可能性)､特定目的への適合性､又は ECSS 標準やそれを引用した内容に間違いがない点を含む(ただし必ずしもこれらに限定されない)明示または黙示のあるいは法的な保証はいかなる場合であっても提供しない。
ECSS は､ECSS 標準又は ECSS 標準の全体又は部分の引用を取り込んだ JAXA 標準の適用により生じた損害に関し､いかなる責任も負わない。

JERG-2-432

目次
第 1 章 概要 .................................................................................................................................... 1
1.1 適用範囲............................................................................................................................... 1
1.2 本設計標準の構成 ................................................................................................................ 1
1.3 適用文書............................................................................................................................... 1
1.4 関連文書............................................................................................................................... 2
1.5 用語 ...................................................................................................................................... 2
第 2 章 SpaceWire オンボードサブネットワークの概要 ............................................................... 4
2.1 本設計標準の規定の目的 ..................................................................................................... 4
2.2 プロトコルスタック ............................................................................................................ 4
第 3 章 SpaceWire ........................................................................................................................... 6
3.1 物理層 .................................................................................................................................. 6
3.1.1 ケーブル ....................................................................................................................... 6
3.1.2 ケーブルアッセンブリ ................................................................................................. 6
3.1.3 コネクタ ....................................................................................................................... 6
3.1.4 信号レベル.................................................................................................................... 6
3.1.5 リンクスピード ............................................................................................................ 7
3.1.6 Flow Control ................................................................................................................ 7
3.2

TimeCode............................................................................................................................... 7

3.2.1 Timecode の喪失 ........................................................................................................... 7
3.3

SpaceWire に関する留意点 .................................................................................................. 8

3.3.1 SpaceWire Node に関する留意点 .................................................................................. 8
3.3.2 SpaceWire Router に関する留意点 .............................................................................. 8
3.4 ネットワーク設計に関する規定 .......................................................................................... 8
3.4.1 Network topology ......................................................................................................... 8
第 4 章 TimeCode を用いた時分割制御 ......................................................................................... 10
第 5 章 SpaceWire-RMAP ................................................................................................................ 11
5.1 プロトコルの概要 .............................................................................................................. 11
5.1.1 パケットフォーマット ............................................................................................... 11
5.1.2 通信トランザクション ............................................................................................... 11
5.1.3 エラーステータス ....................................................................................................... 11
5.2 全体的な規定 ..................................................................................................................... 17
5.3 イニシエータに対する留意点 ............................................................................................ 17ii

JERG-2-432

5.4 ターゲットに対する留意点 ............................................................................................... 17
5.5 インストラクション .......................................................................................................... 17
5.6 アドレッシング.................................................................................................................. 18
第 6 章 SpaceWire-PTP.................................................................................................................. 19
6.1 プロトコルの概要 .............................................................................................................. 19
6.1.1 パケットフォーマット ............................................................................................... 19
6.1.2 SpaceWire-PTP の動作 ................................................................................................ 19
6.2 全体的な規定 ..................................................................................................................... 19
第 7 章 SpaceWire-R ..................................................................................................................... 21
7.1

SpaceWire-R の概要 ........................................................................................................... 21

7.2

SpaceWire-R を使う場合のプロトコル構成 ....................................................................... 21

7.3

SpaceWire-R の用途 ........................................................................................................... 22

7.4

SpaceWire-R の機能 ........................................................................................................... 23

7.4.1 多重化 ......................................................................................................................... 23
7.4.2 データ分割.................................................................................................................. 23
7.4.3 信頼性 ......................................................................................................................... 23
7.4.4 フロー制御(オプション) ............................................................................................ 24
7.4.5 ハートビート(オプション) ........................................................................................ 24
7.5

SpaceWire-R のサービス .................................................................................................... 24

7.5.1 チャネル制御サービス(Channel control service) .................................................. 24
7.5.2 データ転送サービス(Data transfer service) ......................................................... 24
7.6 パケット種別とパケットフォーマット ............................................................................. 25
7.7SpaceWire-R を使う場合の注意点 ..................................................................................... 26

7.8 全体的な規定 ..................................................................................................................... 26
第 8 章 SpaceWire-RMAP による Subnetwork Service .................................................................. 27
8.1 概要 .................................................................................................................................... 27
8.1.1 全体的な規定 .............................................................................................................. 27
8.1.2 提供される Subnetwork service ................................................................................ 28
8.1.3 RMAP Reply を用いた再送制御.................................................................................... 30
8.2

Packet Service.................................................................................................................. 32

8.2.1 マスタトリガ Write サービス .................................................................................... 33
8.2.2 マスタトリガ Read サービス ...................................................................................... 38
8.2.3 Assured 型ユーザトリガ Read 通信サービス .............................................................. 43
8.2.4 Best Effort 型ユーザトリガ Read 通信サービス ...................................................... 52
8.3

Memory Access Service ..................................................................................................... 59

8.3.1 RMAP Read/Write による Memory Access Service ..................................................... 59
8.4

Synchronization Service での時刻情報の配信 ............................................................... 60
iii

JERG-2-432

8.4.1 マスタトリガ時刻 Write サービス ............................................................................. 60
8.5 ASTRO-H/Hisaki の通信サービス定義との対応(参考) ........................................................ 62
第 9 章 SpaceWire-PTP による Subnetwork service .................................................................... 63
9.1 概要 .................................................................................................................................... 63
9.2

Packet Service.................................................................................................................. 63

9.2.1 Packet Service の規定 .............................................................................................. 63
9.2.2 Packet Service のパラメタ ....................................................................................... 64
9.3

Synchronization Service での時刻情報の配信 ............................................................... 64

9.3.1 時刻情報配信の規定 ................................................................................................... 64
9.3.2 時刻情報配信のパラメタ ............................................................................................ 64
第 10 章SpaceWire-R による Subnetwork service ...................................................................... 65

10.1 概要 ..................................................................................................................................... 65
10.2 Packet Service ................................................................................................................ 65
10.2.1 Packet Service の規定............................................................................................. 65
10.2.2 Packet Service のパラメタ ..................................................................................... 66
10.3 Synchronization Service での時刻情報の配信 .............................................................. 66
10.3.1 時刻配信の規定 ........................................................................................................ 66
10.3.2 時刻配信のパラメタ ................................................................................................. 67iv

JERG-2-432
NOTICE-2

第1章
概要
1.1

概要

適用範囲

1. 本設計標準は、宇宙機の搭載系データ通信インタフェースのうち、SpaceWire を用いて
CCSDS SOIS の Subnetwork Service を実装する部分について適用する。
2. 本設計標準で規定される Subnetwork service を利用して制御コマンドや HK データ、観測
データを伝送する具体的な方法は、SM&C 層として、本設計標準より上位の層で規定すること。

1.2

本設計標準の構成

本文書の章立ては以下の通り。
・ §2 において、本設計標準で規定するプロトコルスタックの全体像を示す。
・ §3、§4、§5、§6、§7 において、各仕様の概要を説明するとともに、個々の層で検討すべき事項を規定する。
・ §8 において SpaceWire-RMAP により Subnetwork service を実現するための具体的な規定を示す。
・ §9 において SpaceWire-PTP により Subnetwork service を実現するための具体的な規定を示す。
・ §10 において SpaceWire-R により Subnetwork service を実現するための具体的な規定を
示す。

1.3

適用文書

1. SpaceWire, ECSS-E-ST-50-12C
2. Protocol ID, ECSS-E-ST-50-51C
3. SpaceWire-RMAP, ECSS-E-ST-50-52C
4. SpaceWire-PTP, ECSS-E-ST-50-53C
5. SpaceWire-R, JERG-2-432-TP101,
Exploration Agency, March 2023

SCDHA

151.1.0,

Issue

0.4,

Japan

Aerospace

6. SpaceWire リアルタイム性保証手法ガイドライン, NCES-SPWRT-1-101, Japan Aerospace
Exploration Agency & 名古屋大学

1

JERG-2-432
7. Spacecraft Onboard Interface Services, CCSDS 850.0-G-2, December 2013
8. Spacecraft Onboard Interface Services – Subnetwork Packet Service, CCSDS 851.0-M1, December 2009
9. Space Packet Protocol, CCSDS 133.0-B-1, September 2003
10. Cable, ESCC Detail Specification No. 3902/003
11. Connector, ESCC Detail Specification No. 3401/029, ESCC Detail Specification No.
3401/071

1.4

関連文書

1. SpaceWire オンボードサブネットワーク設計標準補足説明資料「SpaceWire-R プロトコルの性能評価結果」CPA-114021
2. Sandia National Laboratories, “Joint Architecture Standard (JAS) Reliable Data
Delivery Protocol (RDDP) Specification,” Sandia Report SAND2011-3500, May 2011
3. Goddard Space Flight Center, “GOES-R Reliable Data Delivery Protocol (GRDDP),”417-R-RPT-0050, January 2008

1.5

用語

本設計標準内で使用する用語とその意味を以下にまとめる。
RMAP Initiator RMAP Command Packet を送信し、Read/Write により RMAP Target 機器から(に)データを送受信する機器もしくは機能。ECSS 仕様書を参照。
RMAP Target RMAP Command Packet を受信して、Instruction フィールドに指定された Read/Write
動作を実施する機器もしくは機能。詳細は ECSS 仕様書を参照。
通信サービス Subnetwork service を実現するために必要な、具体的な RMAP Write/Read の手順に対する呼称。
「通信サービス」として規定された個々の手順で RMAP 通信を行なうことで、ノード間でデータを伝送し、Subnetwork service に相当する機能を提供する。一つのSubnetwork service を実現するために、複数の「通信サービス」が利用可能な場合がある。
機器・システム設計者は利用可能な「通信サービス」の中から、実際に使用するものを選択して実装する。
マスタ機器 ネットワーク内の通信を管理し、自ら RMAP Initiator となって SpaceWire-RMAP の通信を開始するノード。たとえば DHU (Data Handling Unit) などの衛星制御計算機が該当。
ユーザ機器 ネットワークに接続され、マスタ機器からの通信によって制御されるノード。たとえば、
SMU や OBC から制御されるミッション機器が該当。
SpaceWire-RMAP を用いた Subnetwork
service を使用する場合、ユーザ機器は「RMAP Target」となる。あるユーザ機器は、機能によってはマスタ機器の立場とユーザ機器の立場の両方を有することがある。たとえば、マスメモリが「観測装置のデータを SpaceWire-RMAP の通信サービスで収集する(マスタ機器の立場)とともに、SMU から制御コマンドを受け取る(ユーザ機器の立場)」という場合が想定される。
Service Data Unit(SDU) CCSDS SOIS における定義 = “A unit of data passed into or outof a service interface.”。本設計標準では、CCSDS Space Packet や Transfer Frame、
2

JERG-2-432
Virtual Channel Data Unit (VCDU) 等を想定している。
Raw Data 標準化されたパケットフォーマットによらないバイト列。計測データの生値や、時刻の整数表現等。
時刻マスタ機器 時刻情報を配信する機器。制御コマンドを配信するマスタ機器と同じ装置であっても、独立の装置であってもよい。

3

JERG-2-432

第 2 章 SpaceWire オンボードサブネットワークの概要
SpaceWire オンボードサブネットワークの概要
2.1

本設計標準の規定の目的

本設計標準では、搭載機器間の SpaceWire による相互接続性や再利用性を高めることを目的として、図 2.1 に示す CCSDS SOIS のレイヤー構造のうち、Subnetwork Layer の Subnetwork Serviceに相当する部分を SpaceWire および上位プロトコルにより実現する方法を規定する。
Packet Service については、CCSDS SOIS 上位層からの要求に応じて、Service Data Unit をSpaceWire 経由で伝送する機能を規定する。
Memory Access Service については、CCSDS SOIS 上位層からの要求に応じて、機器のメモリにアクセスする機能を提供する。
Synchronization Service については、時刻マスタ機器から SpaceWire ネットワーク内の時
刻ユーザ機器に対して、時刻情報を配信する方法を規定し、時刻ユーザ機器側で、Synchronization
Service の TIME.request および TIME.indication を実装可能にする。

2.2

プロトコルスタック

SpaceWire には、複数の上位プロトコルが規定されており、用途に応じて使いわけることが期
待されている。本設計標準では、上位の通信プロトコルとして・ SpaceWire-RMAP・ SpaceWire-PTP
・ SpaceWire-R
を用いて Subnetwork Service を実現する方法を規定する。
SpaceWire 物理層や SpaceWire ネットワークの Quality of Service(QoS)のために、必要に応じて TimeCode を用いた時分割通信制御を利用できる。
上記の通信プロトコルのうち、プロトコル自体でデータのセグメンテーション・ブロッキングを実装しているのは SpaceWire-R のみである。それ以外のプロトコルにおいてセグメンテーショ
ン・ブロッキングが必要な場合は、上位プロトコルにおいて規定すること。
図 2.2 に、本設計標準におけるプロトコルスタックを示す。

4

JERG-2-432

図 2.1: CCSDS SOIS の参照アーキテクチャ。本設計標準がカバーする部分を赤線で示した。適用
文書 7 から引用。

図 2.2: SpaceWire 設計標準で規定するプロトコルスタックの全体像。

5

JERG-2-432

第 3 章 SpaceWire
SpaceWire
SpaceWire は ECSS-E-ST-50-12C(replaces ECSS-E50-12A)(適用文書 1)によって規定されている。SpaceWire 層はこの規格に従った設計が求められる。本文書では規格を拡張して適用する場
合、制限を加えて適用する場合、誤解が生じる可能性のある場合についてのみ記述する。

3.1

物理層

3.1.1

ケーブル

SpaceWire ではケーブルは ESCC 3902/003(適用文書 10)によって規定されている。ミッションの要求によっては ESCC 3902/003 に定められたケーブルでは引き回しが困難な場合がある。その場合、電気的に同等なケーブルを用いる事が許される。

3.1.2

ケーブルアッセンブリ

ESCC 3902/003 に定められたケーブルは Inner shield と Outer shield を持つ。ECSS-E-ST50-12C(適用文書 1)では、Outer shield は Frame ground に、Inner shield は LVDS driver 側のpin-3 を通し LVDS driver 側の Ground のみに接地され、LVDS receiver 側は open となる(TypeAL)。これに加え、Inner shield も Frame ground に接地する Cable assembly も可能である(TypeA)。この場合、pin-3 には何も接続されない。
Type AL では信号の方向の異なる Inner shield は電気的には独立である。このためケーブル
をコネクタで延長する場合は各々別々に中継する必要がある。このため延長の為には 9 ピンのコ
ネクタで行う事はできず、ピン数の多いコネクタを使用する必要がある。その場合の例を図 3.1
に示す。

3.1.3

コネクタ

コネクタは ESCC 3401/029 と ESCC 3401/071 で規定されている(適用文書 11)。コネクタと基板はツイストしたリード線で接続する。標準タイプではないコネクタの使用は可能であるが、適合性を別途示す必要がある。また、試験装置と変換ケーブルで接続する必要があるなどの理由により、筐体内などの限られた場合のみに使用を制限すべきである。

3.1.4

信号レベル

ECSS-E-ST-50-12C(適用文書 1)では SpaceWire の電気的な信号レベルとして LVDS を採用することが規定されている。SpaceWire で接続される機器間の LVDS の common mode voltage は、機器内部で使用されている LVDS レシーバのコモンモード許容範囲内である事が求められる。LVDS お
よび電子回路設計に関連する事項は、電気設計標準の規定に従うこと。
また、基板内や筐体内では SpaceWire の信号レベルとして LVDS 以外の信号を用いる事ができる。その場合、信号のスキューやジッターが「6.6.4 Effects of skew and jitter」で規定され
6

JERG-2-432
る範囲でなければならない。

3.1.5

リンクスピードSpaceWire ではパケットを転送中に他のパケットが入る事はないので、パケットの転送を始めると EOP(End-of-packet)までそのパケットが経路を占有する。経路の占有により生じる転送の遅延を防ぐためには占有をできるだけ少なくするようにしなければならない。SpaceWire はビットレートを自由に選ぶ事ができ、経路上でビットレートが異なる場合がある。その場合、低速のリンクにデータを送り始めてから転送を終えるまで経路を占有する事になるため、たとえ高速のリンクがあっても低速のリンクが律速する事となる。このため、パケットの経路は同じビットレートのリンクを用いる事が望ましい。
SpaceWire 規格ではデータ転送の途中に NULL を入れる事が許されているので、データが間欠的に送られることもある。このため、データ転送においては、ビットレートだけでなく転送時間についても定義する必要がある。
SpaceWire ではビットレートは、リンクが確立した後、途中で変わることが許される。また、ビットごとに長さ(duty ratio)が異なることもあり得る。SpaceWire 信号のデコーダは一定のビットレートを仮定した設計を行ってはいけない。

3.1.6

Flow Control

SpaceWire では FCT でリンクのフローを制御している。FCT を送るタイミングは実装によっていろいろな場合がある。一度に複数の FCT が送られてくる場合も含めて実装する必要がある。
FCT が何らかの理由で失われてしまうとデータ転送が止まってしまう。診断のためには FCTの状態(先送りされている FCT の数や受け取っている FCT の数などをモニターする機能がある事が望ましい。

3.2

TimeCode

TimeCode はシステム全体に分配され、マイクロ秒程度の精度で同期をとることができる。
TimeCode を用いることで、システム全体の動作の同期をとることができる。TimeCode の遅延及びjitter は通過するルーターの数に依存する。一つのルーターを通過するたびに 1 character を転送する時間に相当する一様な jitter が加わる。あらかじめ計算や測定を行っておくことが望ましい。
TimeCode は 6bit の時刻情報しか表現できないため、TimeCode で表現される時刻よりも上位の桁の時刻情報は、時刻配信元機器から配信先機器への SpaceWire-RMAP Write による書き込みなど、通常の SpaceWire パケットを用いて行う必要がある。

3.2.1

Timecode の喪失

コンポーネント内部のクロックやタイマーを、SpaceWire インタフェースで受信されるTimecode に同期させている場合、Timecode が喪失した時とそれが短時間・長時間で復帰した場合の動作をシステムレベルで規定しておくこと。

7

JERG-2-432

3.3

SpaceWire に関する留意点

3.3.1

SpaceWire Node に関する留意点

3.3.1.1 バッファリング
SpaceWire の Flow control にはリンクを通して情報をやりとりする必要がある。このため、反応時間に相当したバッファが必要となる。例えば、FCT によるフロー制御を効率的に行うには１
つの FCT ではなく、数個の FCT を用いて行う必要がある。そのため同時に扱う FCT の数に応じて32～64 character のバッファが必要となる。性能を出すためには、CODEC と同じチップ内にこのバッファを用意する必要がある。また、CPU によるパケットの受信では CPU の割り込み時間に相当する数 100 バイトから数 k バイトのバッファがハードウェアとして必要である。これを複数用意して CPU の応答時間中にもデータを受付られるようにする必要がある。SpaceWIre ではパケッ
トサイズには制限が無い。大きなパケットは複数のバッファを用いてデータを受ける必要がある。
高い性能を得るためには、これらのデータ転送は CPU を介在させずに行う必要がある。

3.3.2

SpaceWire Router に関する留意点

3.3.2.1 ウォッチドッグタイマー
SpaceWire 機器がパケット転送中に不具合を起こした場合、そのパケットの転送は終了できず、途中経路はそのパケットに占有されてしまう。この状態を終わらせるためにルーティングス
イッチにはウォッチドッグタイマーをもうける必要がある。
タイムアウト時には EOP ではなく EEPを送りエラーパケットとする。タイムアウトの時間はシステムによって異なる。タイムアウトは
ポートごとにカウントすることが望ましい。また、必要ない場合は disable できるようにする必
要がある。

3.4

ネットワーク設計に関する規定

3.4.1

Network topology

トポロジーとしては
1. Point to point
2. Star
3. Tree
4. Daisy chain / Ring
を考えることができる。小規模なシステムの場合、一つのルーターにすべてを接続した場合(Star)は Node における競合がなければ point to point と同等となる。また、シングルマスターの場合はネットワークトポロジーによらず、動作は point to point と同等となる。マルチマスタ
ーの場合、それぞれのマスターからのトラフィックをお互いにできるだけ隔離したトポロジーである方が良い。
冗長系は Star や Tree ではシンプルに実装できる。Ring の場合、one link failure は自然に
8

JERG-2-432実現できる。

図 3.1: SpaceWire 中継コネクタ

図 3.1: SpaceWire 中継コネクタ

9JERG-2-432

第 4 章 TimeCode を用いた時分割制御
TimeCode を用いた時分割制御
SpaceWire ネットワークにおいて、パケット伝送のリアルタイム性・決定論的性質を保証するための設計手法の代表的なものとして、TimeCode を用いたネットワークの時間分割共有があげられる。
2015 年現在、ESA と SpaceWire Working Group は SpaceWire-D(Deterministic)規格の議論を進めており、数年以内に ECSS 文書化される予定となっている。
また、JAXA の科学衛星プロジェクトにおいては、JAXA と NEC が制定した時分割通信方式が、SPRINT-A 衛星やはやぶさ 2 探査機、ASTRO-H 衛星で利用された。その時分割通信方式の考え方や設計手法は、JAXA と名古屋大学の共同研究における整理をへて、「SpaceWire リアルタイム性保証
手法ガイドライン」(適用文書 6)として公開されている。
リアルタイム性を必要とする宇宙機プロジェクトにおいては、SpaceWire ネットワークを採用する際に、プロジェクトに固有のリアルタイム性に関する要求をふまえて、SpaceWire-D 規格や「SpaceWire リアルタイム性保証手法ガイドライン」で規定された時分割通信方式の採用を検討
すること。

10

JERG-2-432

第 5 章 SpaceWire-RMAP
SpaceWire-RMAP
本章では、SpaceWire-RMAP のプロトコルの概要を説明するとともに、SpaceWire-RMAP プロト
コル自体に関連する規定・留意点を列挙する。これらは、§8 で説明する SpaceWire-RMAP を用いた Subnetwork Service を実現するための規定の基礎となる事項であるため、別建ての章としている。

5.1

プロトコルの概要

SpaceWire-RMAP は、コマンド-レスポンスによってデータをやり取りするトランザクション型の通信プロトコルである。
以下に示すパケットフォーマットおよび通信トランザクションを採用している。

5.1.1

パケットフォーマット

図 5.1～図 5.4 に、RMAP で使用するパケットフォーマットを示す。

5.1.2

通信トランザクション

RMAP Write および RMAP Read の典型的な手順(トランザクション)を図 5.5 と図 5.6 に示す。

5.1.3

エラーステータス

RMAP トランザクションでエラーが発生した場合、その理由により図 5.7 で示すようなエラー
番号が Reply Status として戻る。
たとえば、RMAP Write トランザクションで、RMAP Initiator に Error Reply が戻る場合のトラ
ンザクションの例を図 5.8 に示す。

11

JERG-2-432

図 5.1: RMAP Write Command のパケットフォーマット。適用文書 3 から引用。

図 5.2: RMAP Write Reply のパケットフォーマット。適用文書 3 から引用。

12

JERG-2-432

図 5.3: RMAP Read Command のパケットフォーマット。適用文書 3 から引用。

5.4: RMAP Read Reply のパケットフォーマット。適用文書 3 から引用。

13

JERG-2-432

図 5.5: RMAP Write トランザクション。適用文書 3 から引用。

図 5.6: RMAP Read トランザクション。適用文書 3 から引用。

14

JERG-2-432

図 5.7: RMAP Status values defined in the protocol specification. 適用文書 3 から引用。

15

JERG-2-432

図 5.8: エラーが発生した際の RMAP Write トランザクションの例。適用文書 3 から引用。

16

JERG-2-432

5.2

全体的な規定本設計標準に準拠した SpaceWire-RMAP の実装においては、
適用文書 3 の内容を適用すること。
任意に選択可能なオプションのうち、下記を採用すること。
1. Extended Address は使用せず、0x00 固定とすること。
2. Read-Modify-Write は使用しない。
以下のセクションに示す留意点を考慮した設計とすること。

5.3

イニシエータに対する留意点

1. あるイニシエータが、複数の RMAP トランザクションを並行して実行する場合、トランザク
ション ID をキーとして個々のトランザクションを識別すること。現在実行中として管理されているトランザクション ID 以外の、不正なトランザクション ID をもつリプライパケッ
トが受信された場合は、そのリプライパケットの処理(Read リプライデータのメモリへのコピーなど)をせずに上位アプリケーションにエラーを報告するように設計することが望
ましい。

5.4

ターゲットに対する留意点

設計の簡易化と、検証作業の効率化のため、以下を適用すること。
1. ひとつの RMAP Target 機能において、メモリ領域ごとに Key を変更しないこと。
2. 全てのエラーステータスを実装すること。
3. RMAP でアクセスされるメモリ領域のワード幅は原則として 32bits とすること。
(a) 32bits 以外のワード幅を使用する機器がある場合は、システム設計の段階で詳細を文書化すること。
(b) 文書には当該機器に 32-bit ワード幅以外でアクセスする場合の RMAP コマンドパケ
ットと RMAP リプライパケットのテキストダンプを含め、齟齬が生じないよう配慮すること。
4. RMAP でアクセスされるデータの byte alignment は、ビッグエンディアンとすること(RMAP
パケットとして構築する際にビッグエンディアンになっていればよく、CPU メモリや FPGA
内のメモリ/レジスタにおけるデータの byte alignment を指定しているわけではない)。

5.5

インストラクション

1. Read-modify-write 以外のインストラクションについて、以下の組み合わせのうち、実装したインストラクションを ICD 等の文書により提示すること。
・ Non-verify Write (with reply)
・ Non-verify Write (without reply)
17

JERG-2-432
・ Verify Write
・ Read
2. RMAP でアクセス可能な各メモリ領域について、どのインストラクションによるアクセスが許可されているか ICD 等の文書により提示すること。

5.6

アドレッシング

1. RMAP でアクセスされるメモリ空間のアドレッシングはバイトアドレッシングとすること。
(ワードアドレッシングとしないこと)
例 32bits で 1 ワードの場合で、1 ワード目が 0x0000_0000 からはじまるとき、2 ワード目
は 0x0000_0004 から始まる。

18

JERG-2-432

第 6 章 SpaceWire-PTP
SpaceWire-PTP
本章では、SpaceWire-PTP のプロトコルの概要を説明するとともに、SpaceWire-PTP プロトコ
ル自体に関連する規定・留意点を列挙する。これらは、§9 で説明する SpaceWire-PTP を用いた
Subnetwork Service を実現するための規定の基礎となる事項であるため、別建ての章としている。

6.1

プロトコルの概要

適用文書 4 で規定される SpaceWire-PTP は、SpaceWire に接続されたノード間で、CCSDS Space
Packet を単一方向(unidirectional)に伝送するためのプロトコルである。SpaceWire パケットのカーゴ部に CCSDS Space Packet を格納し、SpaceWire パケットとして相手先ノードに送信する。
SpaceWire-PTP のパケット伝送では、送達確認や再送制御、レイテンシ保証などの QoS は提供されない。これらが必要な場合は上位層での対応が必要となる(もしくは、SpaceWire-R プロト
コルを用いることでも対応できる場合がある)。

6.1.1

パケットフォーマット

図 6.1 に、SpaceWire-PTP のパケットフォーマットを示す。
1. SpaceWire-PTP の Protocol ID は 0x02 である(適用文書 2)。
2. SpaceWire-PTP で伝送する CCSDS Space Packet のサイズは 7 バイト(octet)以上、65542 バ
イト(octet)以下でなければならない。
3. Status code は以下の値と意味をとりうる。
0x00
0x01
0x02

6.1.2

SpaceWire-PTP パケット中の CCSDS Space Packet パケットは正常SpaceWire-PTP パケットが EEP 終端で受信された
SpaceWire-PTP パケット内の reserved field が non-zero である

SpaceWire-PTP の動作

図 6.2 に、SpaceWire-PTP におけるパケット送受信の動作を示す。

6.2

全体的な規定1. 本設計標準に準拠した SpaceWire-PTP の実装においては、適用文書 4 の内容を適用すること。
2. 適用文書 4 の TableA-1 で示された管理パラメタを ICD 等の文書で提示すること。

19

JERG-2-432

図 6.1: SpaceWire-PTP のパケットフォーマット。適用文書 4 から引用。

図 6.2: SpaceWire-PTP の送受信動作。適用文書 4 から引用。

20

JERG-2-432

第 7 章 SpaceWire-R
SpaceWire-R
本章では、SpaceWire-R のプロトコルの概要を説明するとともに、SpaceWire-R プロトコル自体に関連する規定・留意点を列挙する。これらは、§10 で説明する SpaceWire-R を用いた
Subnetwork Service を実現するための規定の基礎となる事項であるため、別建ての章としている。

7.1

SpaceWire-R の概要

SpaceWire-R は、人工衛星に搭載されるアプリケーション間で信頼性のある高速データ伝送を可能にするためのプロトコルであり、適用文書 5 で規定されている。この場合の信頼性とは、送信側アプリケーションが送信したデータが確実に受信側アプリケーションで受信されることを保証することを意味するが、「受信側が生きていることを送信側で確認できること」および「送信側が生きていることを受信側で確認できること」という意味も含んでいる。
SpaceWire-R は、米国サンディア国立研究所が開発した Joint Architecture Standard
Reliable Data Delivery Protocol (JAS RDDP; 関連文書 2)にいくつかの機能を付加したものである。SpaceWire-R と JAS RDDP との差異は適用文書 5 に詳細に記述されているが、SpaceWire-R
で新たに付加した機能を使用しなければ、SpaceWire-R と JAS RDDP とは互換性がある(すなわち、相互に接続可能である)。
JAS RDDP は、NASA ゴダード宇宙飛行センターが開発した GOES-R Reliable
Data Delivery Protocol (GRDDP; 関連文書 3)の機能を拡張したものである。しかし、JAS RDDPと GRDDP とでは、ヘッダのフォーマットが異なっているために、フォーマット変換を行わない限り相互接続は行えない。SpaceWire-R と GRDDP も、同様な理由により、フォーマット変換を行わな
い限り相互接続は行えない。
SpaceWire-R を使う場合の全体としてのプロトコル構成については、7.2 節で説明する。
SpaceWire-R の代表的な使用例を 7.3 節で紹介する。SpaceWire-R は、信頼性以外にもいくつかの機能を提供するが、各機能の概要は 7.4 節で述べる。SpaceWire-R は、その機能を標準的なサービスとしてアプリケーションに提供するが、サービスの概要は 7.5 節で述べる。7.6 節にはSpaceWire-R プロトコルで使用されるパケットの種類とそのフォーマットを示す。SpaceWire-R を使う場合の注意点を 7.7 節にて説明する。7.8 節で SpaceWire-R を使用する際の全体的な規定を
まとめる。

7.2

SpaceWire-R を使う場合のプロトコル構成

SpaceWire-R は、搭載アプリケーション間に仮想的な伝送路(トランスポートチャネルと呼ばれる)を設定し、その伝送路上で送信側アプリケーションから与えられたデータの塊り(典型的には CCSDS の Space Packet 等)を受信側のアプリケーションに順次転送する。
SpaceWire-R を使う場合の全体としての基本的なプロトコル構成は、図 7.1 のようになる。

21

JERG-2-432

図 7.1: SpaceWire-R プロトコルスタックのブロック図。左側、右側のノードがそれぞれ 2 個のTransmit TEP と Receive TEP を実装している例。

図 7.1 に示すように SpaceWire-R は SpaceWire(第 3 章参照)の上位プロトコルとして使用される。すなわち、SpaceWire-R が生成するデータ単位(SpaceWire-R パケットと呼ばれる)は、SpaceWire パケットのカーゴとして伝送され、その際には SpaceWire の規定が全て適用される。
SpaceWire-R パケットと SpaceWire パケットとの間の関係を図 7.2 に示す。

図 7.2: SpaceWire-R パケットと SpaceWire パケットとの間の関係

SpaceWire-R は、送信側アプリケーションが発生したデータを受信側アプリケーションが直接受信することを前提としており、伝送の過程でアプリケーションがデータを特定のメモリに書き込む必要はない。すなわち、SpaceWire-R を使う場合は Remote Memory Access Protocol (RMAP)(第 5 章参照)を使う必要はない。
上で述べたように、SpaceWire-R を使う場合は SpaceWire の規定が適用されるので、一つのSpaceWire ネットワーク上でルータと SpaceWire アドレスを使用することによって一対多あるい
は多対多の伝送を行うこともできる。この場合は、それぞれの送信－受信対ごとに異なるトラン
スポートチャネルを設定する。また、一つの送信－受信対で複数のトランスポートチャネルを設定しても良い。
ルータを使う場合は、ルータにおける輻輳を避けるために SpaceWire-D (SpaceWire 国際委員会で検討中のタイムスロットを利用した時分割多重化のためのプロトコル)を併用しても良い。その場合は、一つあるいは複数のトランスポートチャネルが SpaceWire-D 上の一つあるいは複数のタイムスロットに割り当てられることになる。

7.3

SpaceWire-R の用途

SpaceWire-R の代表的な使用例は以下のようなものである。

22

JERG-2-432

1. 搭載観測機器から観測データ処理用のプロセッサへの生観測データの転送。例えば、搭載カメラで撮像された画像を画像処理用のプロセッサに転送するような場合。このような場
合は、CCSDS の Space Packet 等は使用せずに、画像データを直接 SpaceWire-R で伝送することになる。
2. 観測データ処理用の計算機から大容量蓄積装置への処理済み観測データの転送。例えば、上記の画像処理用のプロセッサで処理された画像を地上に伝送する前に大容量蓄積装置(データレコーダなど)に転送し格納する場合。この場合は、処理済みの画像データを CCSDSの Space Packet の列として SpaceWire-R で伝送することになる。
3. 大容量蓄積装置から通信機器へのダウンリンクデータの転送。例えば、上述の大容量蓄積装置(データレコーダなど)に格納されているデータを地上に伝送するために通信機器に転送する場合。この場合も、大容量蓄積装置に格納されている CCSDS Space Packet をSpaceWire-R で伝送することになる。

7.4

SpaceWire-R の機能

SpaceWire-R の機能の概要を以下に述べる。

7.4.1

多重化

SpaceWire-R は、ある SpaceWire 論理アドレスから別の SpaceWire 論理アドレスへ送られる
複数の別々のデータの流れをひとまとめにして(すなわち多重化して)伝送する機能を有している。
それぞれのデータの流れは一つのトランスポートチャンネルに割り当てられる。各々のトランスポートチャンネルは独立に制御され、トランスポートチャンネルごとにデータ伝送の特性を設定できる。また、トランスポートチャンネルごとの優先度を設定することもできる。トランスポー
トチャンネルによる多重化の具体的な使用例については、7.6 に述べる。

7.4.2

データ分割

送信側のアプリケーション(図 7.1 参照)から SpaceWire-R に与えられたデータの塊がSpaceWire-R で使用するデータ単位(すなわち SpaceWire-R パケット)よりも大きい場合、SpaceWire-R は、与えられたデータの塊を SpaceWire-R パケットで伝送できるように複数のデー
タに分割する機能を有している。受信側では、分割されたデータを受信した場合、複数のSpaceWire-R パケットより元のデータを復元し、元データを受信側のアプリケーションに届ける。

7.4.3

信頼性

SpaceWire-R は、送信側アプリケーション(図 7.1 参照)より与えられたデータを「抜けがな
く、重複もなく、与えられた順序通りに」受信側のアプリケーションに届けることを保証している。これを実現するために、SpaceWire-R では、送信された SpaceWire-R パケットが正しく受信されたかどうかを確認し、受信されていない場合には同じ SpaceWire-R パケットを再送するための機能を有している。

23

JERG-2-432
7.4.4

フロー制御(オプション)

SpaceWire-R は、オプション機能として、受信側から送信側に「どれだけの SpaceWire-R パケ
ットをさらに受信可能であるか」を伝えることができる。これは、受信側で受信しきれないような数の SpaceWire-R パケットを送信側で送信してしまうことを避けるための機能である。

7.4.5

ハートビート(オプション)

SpaceWire-R は、オプション機能として、送受信すべきデータが何もない時でも、送信側ある
いは受信側が「回線と相手側(すなわち受信側あるいは送信側)がまだ生きているかどうか」を確認することができるようになっている。

7.5

SpaceWire-R のサービス

SpaceWire-R がアプリケーションに提供するサービスの概要を以下に述べる。ここでサービスとは、SpaceWire-R が API(Application Program Interface)を通じてアプリケーションに提供する機能のことである。
・ Channel control service: Transmit TEP や Receive TEP の状態を制御するためのサービス。
・ Data transfer service: TEP を通じてデータを送受信するサービス。

7.5.1

チャネル制御サービス(Channel control service)

これは、アプリケーションが SpaceWire-R プロトコルの状態を制御するためのサービスである。
具体的には、アプリケーションは、このサービスを使用して特定のトランスポートチャンネルをOpen あるいは Close することを SpaceWire-R プロトコルに指示できる(詳細は適用文書 5 参照のこと)。また、SpaceWire-R プロトコルからアプリケーションに現在の状態を通知する機能も有する。
チャネル制御サービスで定義されているプリミティブと概要は次の通り。
・ ChannelControl.request: 上位アプリケーションが、ある Transport Channel で使用される Transmit TEP もしくは Receive TEP の状態を変更するためにそれらの TEP に対してリクエストを渡すために使用される。
・ ChannelControl.indication: Transmit TEP や Receive TEP が上位アプリケーションに
TEP の状態変化を通知するために使用される。

7.5.2

データ転送サービス(Data transfer service)

このサービスは、アプリケーションが SpaceWire-R プロトコルを用いてデータを転送するためのサービスである。
送信側のアプリケーションは、このサービスを用いて送信すべきデータの塊を SpaceWire-R に渡す。SpaceWire-R からはアプリケーションにそれぞれのデータの塊についての転送結果(すなわ
ち、送信側で転送を正しく受け付けたかどうか、および、受信側で正しく受信されたかどうか)を通知する。
受信側のアプリケーションは、このサービスを用いて受信されたデータの塊を SpaceWire-R よ24

JERG-2-432
り受け取る。
データ転送サービスで定義されているプリミティブと概要は次の通り。
・ DataTransfer.request: データ送信アプリケーションが、Transmit TEP に対してデータ送信要求を通知するために使用される。
・ DataTransferNotify.indication: Transmit TEP がデータ送信アプリケーションに対して、
SDU の送信に関連するイベントを通知するために使用される。
・ DataTransfer.indication: Receive TEP が受信した SDU をデータ受信アプリケーションに通知するために使用される。

7.6

パケット種別とパケットフォーマット

SpaceWire-R プロトコルでは、表 7.1 のパケットを用いてデータ通信を実現する。個々のSpaceWire-R パケットは、SpaceWire パケットの Cargo 部分に図 7.3 のようなフォーマットで情報を格納することで表現される。
表 7.1: SpaceWire-R パケットの種類

図 7.3: SpaceWire-R パケットのフォーマット。適用文書 5 から引用

25

JERG-2-432

7.7

SpaceWire-R を使う場合の注意点

ここで、トランスポートチャネルの使い方を簡単に説明する。
例えば、衛星上で転送されるデータには、コマンドやハウスキーピングデータのように衛星のリアルタイム制御に用いられ、伝送遅延の影響を強く受けるデータもあれば、観測結果やメモリ
データのように「とにかく正しく転送されれば、遅延時間などは気にしない」というデータもある。このように、データの種類ごとに要求されるサービスの質(Quality of Service, QoS)が異なる場合があるが、トランスポートチャネルは、これらの異なるサービスの質を実現するために使用することができる。
上記の例の場合は、リアルタイム制御用のトランスポートチャネルと観測結果やメモリデータ
用のトランスポートチャンネルを設定する。この場合、前者のトランスポートチャネルは後者より優先度を高く設定し、両者のデータを同時に送る必要がある場合は、前者のデータが先に送られる。また、トランスポートチャネルごとに制御パラメータを独立に設定することができ、前者のトランスポートチャネルは後者よりもタイマの初期値を小さく設定する(詳細は適用文書 5 参
照のこと)。これにより、前者のトランスポートチャネルで伝送エラーが発生した場合は、短い間隔で再送されることになり、要求されるサービスの質に適合した制御がなされることになる。

7.8

全体的な規定1. 本設計標準に準拠した SpaceWire-R の実装においては、適用文書 5 の内容を適用すること。
2. 適用文書 5 内の 5 章にまとめられた、任意に選択可能なオプション項目について、選択した結果を ICD 等の文書で提示すること。
補足SpaceWire-R プロトコルを採用したさいの通信速度やレイテンシ等の性能評価結果については関連文書 1 を参照すること。

26

JERG-2-432

第 8 章 SpaceWire-RMAP による Subnetwork Service
SpaceWire-RMAP による Subnetwork Service
8.1

概要

SpaceWire-RMAP を用いた Subnetwork service の概要を以下に示す。
1. SpaceWire-RMAP を用いた Subnetwork service は、RMAP Read および RMAP Write を用いて上位レイヤのデータを伝送するため、CCSDS SOIS (適用文書 7)の Subnetwork 層の以下のサービスを提供可能である。
(a) Packet Service(b) Memory Access Service(c) Synchronization Service に必要な時刻情報の配信
2. RMAP パケットの伝送にリアルタイム性保証が必要な場合は、下位の層として SpaceWire-D を用いた時分割ネットワーク共有を採用する。
3. RMAP を用いた Subnetwork service は、リアルタイム性保証との相性やユーザ機器における実装のしやすさから、主に衛星バス系(機器の制御、Housekeeping データの収集等)での使用を想定している。システム設計の結果次第で、RMAP を用いた Subnetwork service で要求(通信速度等)が満たされる場合は、ミッションセンサの観測データ伝送に利用してもよい。
4. RMAP 自体に再送制御の仕組みがないため、CCSDS SOIS が規定する Resource Reservation
Function のうち、Assured (再送制御あり)もしくは Guaranteed (リアルタイム性かつ再送制御あり)の Subnetwork service を実現するため、RMAP Reply を用いた再送制御を規定する。(RMAP 層での再送制御を使用せず、上位の SM&C 層で再送制御を行なうこともできるた
め、RMAP 層での再送の使用・不使用はシステム設計のオプションである)

8.1.1

全体的な規定SpaceWire-RMAP による Subnetwork service における全体的な規定を以下に示す。
1. システム設計のバリエーションを低減し相互接続性を向上させるため、マスタ機器からユー
ザ機器に対し Pull 型のデータ通信のみで通信サービスを実現する。つまり、マスタ機器は
常に RMAP Initiator であり、ユーザ機器は常に RMAP Target として動作する。
2.ユーザ機器がマスタ機器に対し、データ伝送要求を通知する方法として、マスタ機器からのPolling を使用する。
3. 伝送するデータの形式は Service Data Unit もしくは Raw Data であること。通信サービスとデータ形式の対応は表 8.2 を参照。
4. ユーザ機器ごとに、各種データ(テレメトリ/コマンド)の伝送のために利用するサービスを、
27

JERG-2-432
関連するパラメタの値とともに選択・決定すること。
5. SpaceWire-D によるリアルタイム性保証の使用/不使用はシステム設計の段階で決定すること。
6. 再送制御の有無は、システム設計の中で上位の SM&C 層で必要となる通信種別(たとえば TC
Packet の書き込み、TM Packet 形式の HK データの読み出し、センサテレメトリを含む TM
Packet の読み出しなど)ごとに決定すること。
7. 通信サービスごとに、RMAP のメモリ空間内の異なるメモリ領域を割り当ててデータの受け渡しに使用すること。

8.1.2

提供される Subnetwork service

以下のサブセクションで
1. Packet Service
2. Memory Access Service
3. Synchronization Service に必要な時刻情報の配信の各 Subnetwork service の概要を説明する。
個々の Subnetwork service の詳細は§8.2、§8.3、§8.4 で規定する。
8.1.2.1 Packet Service
1. Service Data Unit をノード間で伝送する機能を提供する。
2. 通信方式に応じて、以下の通信サービスを規定する。
・ マスタトリガ伝送(Master-trigger Data Transfer)- マスタトリガ Write サービス(Master-trigger SpacePacket Write Service)(再送制御なし = Best effort 型、再送制御あり = Assured 型)- マスタトリガ Read サービス(Master-trigger SpacePacket Read Service)(再送制御なし = Best effort 型、再送制御あり = Assured 型)
・ ユーザトリガ伝送 (User-trigger Data Transfer)- Assured 型 ユ ー ザ ト リ ガ Read サ ー ビ ス (Assured-class user-trigger
SpacePacket Read Service)- BestEffort 型ユーザトリガ Read サービス(Best-effort-class user-trigger
SpacePacket Read Service)
補足 上記の Best effort 型・Assured 型の名称については、CCSDS SOIS の Resource
Reserved Function の traffic class(適用文書 7)と対応している。これらは、再送制御の有無、および、SpaceWire-D 層の使用の有無に応じて、表 8.1 のように呼び変えること。
3. 「マスタトリガ伝送」では、マスタ機器が必要なタイミングで RMAP Write もしくは RMAP
Read を実施してユーザ機器に(から)データを伝送する。

28

JERG-2-432
4. 「ユーザトリガ伝送」では、マスタ機器がユーザ機器の伝送リクエストフラグ(もしくは出
力要求パケット数)をポーリングし、伝送リクエストが発生したときに、マスタが所定の
RMAP アクセスを実行することでユーザ機器からマスタ機器にデータを伝送する。

表 8.1： Packet Service の種類。

8.1.2.2 Memory Access Service
1. 機器のステータス読み出しや生データ、センサーのレジスタ設定値の書き込みなど、ユー
ザ機器内のレジスタ、メモリ等にアクセスする機能を提供する。
2. 読み書きするデータは Raw Data 形式とする。
3. ユーザ機器側の実装を簡単化するため、送達確認・再送制御は提供しない。送達確認・再送制御が必要な場合は、Subnetwork 層よりも上位の層において、方法を規定すること。
8.1.2.3 Synchronization Service での時刻情報の配信
1. 時刻マスタからユーザ機器に対して時刻情報を書き込む機能を提供する。
2. 時刻情報は CCSDS Unsegmented Code (CUC) もしくは、ミッションごとに定義した Raw Data
形式の時刻情報とする。
補足

Raw Data 形式はプロジェクト依存である。例えば CUC の Time Field (T-Field)の形式を踏襲し、Coarse time および Fine time のビット幅は、プロジェクトの要求に従って決定することで、CUC を用いた場合と同等の時刻情報の処理が可能となり、設計の見通しが向上すると期待される。

3. CUC の場合も、Raw Data 形式の場合も、各フィールドのビット幅や意味、分解能等の詳細規定をプロジェクトごとに文書で規定し、機器設計者の間で共有すること。
表 8.2:Subnetworkservice とデータ形式

29

JERG-2-432

8.1.3

RMAP Reply を用いた再送制御

SpaceWire ネットワークにおいては、ビットエラーによるリンク切断が生じると、リンク切断、リンク初期化の手順によりリンクが不通となる時間帯が生じうる。RMAP Command パケットや
RMAP Reply パケットが伝送されている途中にリンクが切断されると、パケットが途中で分断され、EEP で終端された状態で宛先に届く場合がある。これらの場合、RMAP Target 側で RMAP Commandが正しく解釈されなかったり、RMAP Target が返送した RMAP Reply が RMAP Initiator 側に正常に届かず、RMAP トランザクションが完了しなくなる。
SpaceWire-RMAP による通信サービスのうち、データの確実な伝送を必要とする通信シーケン
スで RMAP トランザクションが失敗した場合、失敗したトランザクションの RMAP Command で使用していたトランザクション ID と同じトランザクション ID 値を設定してマスタ機器から RMAP
Command を再度送信し、トランザクションを再度実行する。ユーザ機器における再送時の RMAP ト
ランザクションの処理は、RMAP Write の場合と Read の場合で異なるため、以下では別々に規定する。
8.1.3.1 RMAP Write における再送制御
1. マスタ機器がユーザ機器に RMAP Write する再送制御つきトランザクションでは、Reply あ
り指定で RMAP Write コマンドパケットを送出すること。トランザクション ID は、宛先となるユーザ機器にその通信サービスで前回アクセスを実施したときと異なるトランザクシ
ョン ID を設定すること。
参考情報

これを実現するため、マスタ機器ではユーザ機器毎、通信サービス毎に最後のトランザクションで使用したトランザクション ID の情報を機器内部で記憶しておく必要がある。

2. マスタ機器が規定時間(タイムアウト時間)以内に RMAP Write Reply を受信できない場合、
RMAP Write を再試行するため、元の RMAP Write コマンドパケットと同じトランザクショ
ン ID を付与した RMAP Write コマンドを作成し送出すること。
3. ユーザ機器では、トランザクション ID の値に関わらず、届いた RMAP コマンドを実行すること。Key やメモリアドレス、データ長等に問題なければ、再送されてきた RMAP Write コ
マンド(つまり、前回同じメモリアドレスに同じトランザクション ID で届いた RMAP Write
コマンドと同じ内容のコマンドパケット)が届いた場合でも、書き込み動作を実行すること。
4. 再送により、同一のデータが複数回書き込まれることによる重複処理の排除が必要な場合
は、上位アプリケーションで対応すること。
例 たとえば、Assured 型マスタトリガ Write サービスで CCSDS SpacePacket の TC Packet
をユーザ機器に書き込む際、1 度目の RMAP Write はユーザ機器に到達し、受信したデータ(TC Packet)は書き込まれたとする。書き込まれたデータ(TC Packet)は上位アプ
リケーションで受信され、TC Packet 内の APID やシーケンスカウンタ等の妥当性をチェックしてから、妥当であれば対応するコマンドが実行される。この RMAP Write に対する RMAP Write Reply が通信エラーによってマスタ機器に戻らなかった場合、マスタ
機器は同じトランザクション ID を付与して同じ TC Packet を再度 RMAP Write する。
この RMAP Write コマンドを受信したユーザ機器では、書き込み動作を実施し、届いたデータ(TC Packet)を上位アプリケーションに通知する。データ(TC Packet)を受信した上位アプリケーションは、TC Packet 内のシーケンスカウンタが前回実行したコマ

30

JERG-2-432
ンドのシーケンスカウンタと同一であることから再送コマンドであることを識別し、実行しない。
RMAP Write の処理そのものは正常に実行されるため、ユーザ機器内の RMAP
Target 機能は RMAP Write Reply を(RMAP Initiator である)マスタ機器に返送する。
この Reply が正常にマスタ機器に戻れば、再送した RMAP Write コマンドが正常に処理されたことがマスタ機器で識別できる。
8.1.3.2 RMAP Read における再送制御
1. マスタ機器が規定時間(タイムアウト時間)以内に RMAP Read Reply を受信できない場合、
RMAP Read を再試行するため、元の RMAP Read コマンドパケットと同じトランザクション
ID を付与した RMAP Read コマンドを作成し送出すること。
2. ユーザ機器側では、Assured 型ユーザトリガ Read 通信サービスで利用するメモリ領域については、通信シーケンスでデータ収集が正常に完了した事をマスタ機器から通知されるまでは、再送制御が必要なメモリ領域のデータを更新しないこと。
(a) 通信手順異常により、マスタ機器から、データ収集が正常に完了した事が通知されない状態が継続した場合に対応するため、再送制御用にデータ保持を継続する状態のタイムアウト時間を規定するか、制御コマンドで通信シーケンス管理機能をリセットできるようにしておくこと。
(b) タイムアウト時間を設定する場合、ICD 等の文書により、メモリ領域ごとのタイム
アウト時間を提示すること。
(c) 制御コマンドによるリセットについては、詳細は SM&C 層での規定、機器のテレコマ設計および、システム設計に依存する。
3. ユーザ機器側では、RMAP Read に対して再送制御が必要な通信サービスで利用するメモリ領域について RMAP Read された場合は、トランザクション ID に関わらずそのとき保持しているメモリ領域のデータを RMAP Read Reply として返送すること。データ読み出しにおいてエラーが発生した場合は、適切なリプライステータスを設定した RMAP Reply を返送すること。
4. マスタ機器では、規定回数以上再送を試行しても RMAP Read が正常に完了しない場合、上位アプリケーションに通知すること。
補足

恒久的な不具合が発生したことに相当するため、この通知を受けて上位アプリケー
ションで冗長系ネットワークへの切替等の対処を実施する等の対応が必要である。
詳細はシステム設計依存となる。

8.1.3.3 トランザクション ID の使用方法
1. 16 ビットのトランザクション ID を、上位 N ビットと下位 16-N ビットの 2 つのフィールドに分割する。
2. 上位 N ビットは、マスタ機器においてトランザクションの種別(ターゲットとなるユーザ機
器、通信サービスの種別、マスタ機器内でのアプリケーション等)を識別するために用いる。

31

JERG-2-432
3. 下位 16-N ビットは、トランザクションのシーケンス番号を入れるなど同じトランザクショ
ン種別の中でのトランザクションの識別のために用いる。
4. N の具体的な値はプロジェクトごとに決定すること。

8.2

Packet Service

SpaceWire-RMAP による Packet Service は、Service Data Unit の伝送タイミングを決定する機器によって、マスタトリガ伝送(マスタ機器が所定のタイミングで伝送開始要求を出す)とユー
ザトリガ伝送(ユーザ機器が所定のタイミングで伝送開始要求を出す)に大別される。
マスタトリガ伝送は Service Data Unit の伝送方向により、以下の 2 つに大別される。それぞれにおいて、再送制御の有無は選択できる。再送制御を実施しない場合は CCSDS SOIS の Best
Effort class、再送制御を実施する場合は CCSDS SOIS の Assured class のサービスとなる。
SpaceWire-D を使用したリアルタイム性保証を採用する場合は、それぞれ Reserved class、
Guaranteed class に対応する。
1. マスタトリガ Write サービス(Master-trigger SpacePacket Write Service)(再送制御なし = Best effort 型、再送制御あり = Assured 型)
マスタ機器からユーザ機器への Service Data Unit の RMAP Write。
用途の例
・ TC Packet の書き込み
2. マスタトリガ Read サービス(Master-trigger SpacePacket Read Service)(再送制御なし = Best effort 型、再送制御あり = Assured 型)
マスタ機器によるユーザ機器からの Service Data Unit の RMAP Read。
用途の例
・ TM Packet 形式の HK データの読み出し
・ TM Packet 形式のセンサデータの読み出し
補足

上記の Best effort 型・Assured 型の名称については、CCSDS SOIS の Resource
Reserved Function の traffic class(適用文書 7)と対応している。これらは、再送制御の有無、および、SpaceWire-D 層の使用の有無に応じて、表 8.1 のように呼び変えること。

ユーザトリガ伝送は再送制御の有無により、以下の 2 つに大別される。
1. Assured 型ユーザトリガ Read サービス(Assured-class user-trigger SpacePacket Read
Service)
マスタ機器によるユーザ機器からの Service Data Unit の RMAP Read。 RMAP Read による伝送要求のポーリング、Service Data Unit の RMAP Read (1 回) 、 acknowledge の RMAP
Write の手順で double handshake の通信を行い、CCSDS SOIS Assured class のサービスを
提供する。
用途の例
・ TM Packet 形式の HK データの読み出し

32

JERG-2-432

2. BestEffort 型ユーザトリガ Read サービス(Best-effort-class user-trigger SpacePacket
Read Service)
マスタ機器によるユーザ機器からの Service Data Unit の RMAP Read。ポーリングによる出力パケット数の確認と、それに続く再送無しの Service Data Unit の RMAP Read(1 回～複数回)で CCSDS SOIS Best Effort class のサービスを提供する。「Assured 型ユーザト
リガ Read サービス」と比較して、高速な RMAP Read が可能。
用途の例
・ TM Packet 形式の HK データの読み出し
・ TM Packet 形式のセンサデータの読み出し
補足

上記の Best effort 型・Assured 型の名称については、CCSDS SOIS の Resource
Reserved Function の traffic class (適用文書 7)と対応している。これらは、再送制御の有無、および、SpaceWire-D 層の使用の有無に応じて、表 8.1 のように呼び変えること。

SpaceWire-D を使用したリアルタイム性保証を採用する場合は、1.と 2.がそれぞれ「Reserved
型ユーザトリガ Read サービス」、「Guaranteed 型ユーザトリガ Read サービス」となる。
以降の章で、個々の通信サービスの通信手順を規定する。

8.2.1

マスタトリガ Write サービス

マスタトリガ Write サービスでは、RMAP Write トランザクションによって、マスタ機器からユーザ機器へ TC Packet 等の Service Data Unit を伝送する。
1. ユーザ機器は、マスタトリガ Write サービス用メモリ領域を定義し、RMAP でアクセス可能にすること。
2. マスタ機器は上位アプリケーションからの要求にもとづいて Service Data Unit を RMAP
Write でユーザ機器のマスタトリガ Write サービス用メモリ領域に書き込む事。
3. ユーザ機器は、マスタトリガ Write サービス用メモリ領域に Service Data Unit が書き込まれたことを、上位アプリケーションに通知すること。
4. ユーザ機器内の RMAP Target 機能は、Service Data Unit のメモリへの書き込み処理が完了したら RMAP Reply を返送すること(RMAP Write コマンドパケットの Instruction フィー
ルドで Reply が要求されている場合)。
5. マスタトリガ Write サービスについて再送制御を利用するかどうかはシステム設計で規定すること。再送制御を行なう場合は、8.1.3 の規定に従うこと。
6. 再送制御を使用しない場合、RMAP Write トランザクションにおいて、RMAP Reply を要求するかどうか、システム設計で規定すること。
7. ユーザ機器内での RMAP Target 機能と上位アプリケーションの間の Service Data Unit の受け渡しは Service Data Unit の単位で atomic であること(e.g. RMAP Target 機能が内部バスアクセスで Service Data Unit を CPU のメインメモリに書き込んでいる途中に、その内容を CPU が読み出すことがないようにすること)。

33

JERG-2-432

図 8.1: 再送制御が発生しない場合のマスタトリガ Write サービスの RMAP トランザクション。再送制御を使用しない場合でも、Instruction フィールドで Reply が要求されていれば、RMAP Target
側は RMAP Write Reply を返送する。

8.2.1.1 マスタトリガ Write サービスのトランザクションの流れ
図 8.1 に、再送制御無しのマスタトリガ Write サービスの RMAP トランザクションの流れを示す。
図 8.2 に、再送制御有りのマスタトリガ Write サービスで、再送が発生しない場合の RMAP ト
ランザクションの流れを示す。
図 8.3 に、再送制御有りのマスタトリガ Write サービスで再送が発生し、1 度目の再送でトラ
ンザクションが成功した場合の RMAP トランザクションの流れを示す。
図 8.4 に、再送制御有りのマスタトリガ Write サービスで再送が発生し、規定回数(n)の上限まで再送を実施してもトランザクションが完了しなかった場合の流れを示す。
8.2.1.2 マスタトリガ Write サービスについてのパラメタ
タイムスロット
マスタ機器が RMAP Write を行うタイムスロット(SpaceWire-D を使用する場合)。
メモリ領域
マスタトリガ Write サービスで Service Data Unit を書き込むメモリアドレス。
再送の有無
再送制御を実施するかどうか。
再送までのタイムアウト時間
Reply パケットの受信待ちタイムアウトまでの時間。
再送試行回数
何度まで再送制御を試行するか。

34

JERG-2-432

図 8.2: 再送制御ありの場合のマスタトリガ Write サービスの RMAP トランザクション(再送が発生しない場合)。

35JERG-2-432

図 8.3: 再送制御ありの場合のマスタトリガ Write サービスの RMAP トランザクション(1 度目の書き込みのリプライが喪失した結果再送が発生し、1 度目の再送でトランザクションが成功した
場合)。

36

JERG-2-432

図 8.4: 再送制御ありの場合のマスタトリガ Write サービスの RMAP トランザクション(規定回数(n)の上限まで再送を実施してもトランザクションが完了しなかった場合)。

37

JERG-2-432
8.2.2

マスタトリガ Read サービス

マスタトリガ Read サービスでは、RMAP Read トランザクションによって、マスタ機器からユー
ザ機器へ TM Packet 等の Service Data Unit を伝送する。
1. ユーザ機器は、マスタトリガ Read サービス用メモリ領域を定義し、RMAP でアクセス可能にすること。
2. マスタ機器は上位アプリケーションからの要求にもとづいてあらかじめ決められたマスタ
トリガ Read サービス用メモリ領域に RMAP Read を実行し、ユーザ機器から Service Data
Unit を読み出す。
3. ユーザ機器の上位アプリケーションは、マスタトリガ Read サービス用メモリ領域に所定のタイミングで Service Data Unit を準備し、マスタ機器による RMAP Read に備える。
4. マスタトリガ Read サービスについて再送制御を利用するかどうかはシステム設計で規定すること。再送制御を行なう場合は、8.1.3 の規定に従うこと。
5. SpaceWire-D を用いる場合、リプライパケットを返送するまでの遅延時間が規定される。
RMAP Read で返送する Service Data Unit の生成に処理時間を要する場合、ユーザ機器は
遅延時間の規定を守るため、マスタ機器からのアクセスがあるよりも前に、Service Data
Unit を生成しておくこと。
6. ユーザ機器内での RMAP Target 機能と上位アプリケーションの間の Service Data Unit の受け渡しは、Service Data Unit の単位で atomic であること(e.g. RMAP Target 機能が内部バスアクセスで Service Data Unit を CPU のメインメモリから読み出している途中に、その内容が CPU によって変更されないようにすること)。
8.2.2.1 マスタトリガ Read サービスのトランザクションの流れ
図 8.5 に、再送制御無しのマスタトリガ Read サービスの RMAP トランザクションの流れを示す。
図 8.6 に、再送制御有りのマスタトリガ Read サービスで、再送が発生しない場合の RMAP トラ
ンザクションの流れを示す。
図 8.7 に、再送制御有りのマスタトリガ Read サービスで再送が発生し、1 度目の再送でトランザクションが成功した場合の RMAP トランザクションの流れを示す。
図 8.8 に、再送制御有りのマスタトリガ Read サービスで再送が発生し、規定回数(n)の上限まで再送を実施してもトランザクションが完了しなかった場合の流れを示す。
8.2.2.2 マスタトリガ Read サービスのパラメタ
タイムスロット
マスタ機器が RMAP Read を行うタイムスロット(SpaceWire-D を使用する場合)。
メモリ領域
マスタトリガ Read サービスで Service Data Unit を読み出すメモリアドレス。
再送の有無
再送制御を実施するかどうか。
再送までのタイムアウト時間
Reply パケットの受信待ちタイムアウトまでの時間。

38

JERG-2-432

図 8.5: 再送制御なしの場合のマスタトリガ Read サービスの RMAP トランザクション。

再送試行回数
何度まで再送制御を試行するか。

39

JERG-2-432

図 8.6: 再送制御ありの場合のマスタトリガ Read サービスの RMAP トランザクション(再送が発生
しない場合)。

40

JERG-2-432

図 8.7: 再送制御ありの場合のマスタトリガ Read サービスの RMAP トランザクション(1 度目の書
き込みのリプライが喪失した結果再送が発生し、1 度目の再送でトランザクションが成功した場
合)。

41

JERG-2-432

図 8.8: 再送制御ありの場合のマスタトリガ Read サービスの RMAP トランザクション(規定回数(n)の上限まで再送を実施してもトランザクションが完了しなかった場合)。

42

JERG-2-432
8.2.3

Assured 型ユーザトリガ Read 通信サービス

Assured 型ユーザトリガ Read 通信サービスは、ユーザ機器からのオンデマンドリクエストに応じてマスタ機器がデータ収集を行なう。マスタ機器とユーザ機器の間の通信シーケンスとして以下のようなハンドシェイクを行なう形式を規定することで、マスタ機器・ユーザ機器間のSpaceWire ネットワークに恒常的な不具合が発生しない限り、データを確実に伝送することができる。それぞれのシーケンスにおいて、ポーリング以外の RMAP アクセスは「リプライ有り」指定で実行され、リプライパケットが規定時間以内に戻らないもしくはリプライパケットに RMAP エラ
ーステータスがセットされている場合は、規定された回数まで再送が試行される。通信シーケン
スが完了した場合、もしくは規定回数まで再送を試行してもシーケンスが完了しない場合、結果が上位アプリケーションに通知される。
1. マスタ機器で Assured 型ユーザトリガ Read 通信サービスが有効化されると、マスタ機器はAssured 型ユーザトリガ Read 通信サービスを使用するユーザ機器に対して、定期的にAssured 型ユーザトリガ Read 通信サービス関連のフラグを含むレジスタ領域を RMAP Read
で読み出す(リクエストポーリング)。マスタ機器は、読み出されたフラグにもとづいて、内部の通信シーケンス管理用ステートマシンを遷移させる
2. ユーザ機器が伝送開始要求を示すリクエストフラグを設定する
3. リクエストフラグがセットされている場合、マスタ機器が RMAP Read を用いてユーザ機器
からデータ収集する
4. データ収集が完了すると、マスタ機器がユーザ機器に対して収集処理完了を示すアクノレ
ッジフラグを RMAP Write でセットする
5. ユーザ機器はアクノレッジの通知を検知すると、リクエストフラグをクリアし、アクノレ
ッジフラグをセットする
6. マスタ機器は RMAP Read を用いたポーリングによりユーザ機器側のリクエストフラグがクリアされていること、アクノレッジフラグがセットされていることを検知する
7. マスタ機器はユーザ機器に対して RMAP Write によりアクノレッジフラグをクリアする
8. ユーザ機器はアクノレッジフラグのクリアによって、Assured 型ユーザトリガ Read 通信サービスのシーケンスを完了する
9. マスタ機器は RMAP Read を用いたポーリングによりユーザ機器側のアクノレッジフラグがクリアされていることを検知する
10. マスタ機器は Assured 型ユーザトリガ Read 通信サービスのシーケンスを完了する
8.2.3.1 Assured 型ユーザトリガ Read 通信サービスで使用するメモリ領域
Assured 型ユーザトリガ Read 通信サービスは、表 8.3 のようなメモリ領域を使用する。Assured
型ユーザトリガ Read 通信サービスを使用するユーザ機器はこれらのメモリ領域を RMAP アクセス
可能なように実装すること。
また、各メモリ領域の値については、以下の規定を満たすこと。

43

JERG-2-432

1. リクエストフラグ領域、データサイズ領域、アクノレッジフラグ領域はそれぞれ 4 バイト。
2. リクエストフラグとアクノレッジフラグは、4 バイトを 1 ワードとして取り扱う。
3. リクエストフラグとアクノレッジフラグは、big endian で 10 進数表記したときの値が 1/0の場合、フラグがセット/クリアされていると定義する。
4. データ領域は、使用する最大パケット長を考慮し、それよりも大きいサイズとすること。
補足SpaceWire-D を使用する場合、通信レイテンシを考慮しても規定したタイムスロット
内にトランザクションが完了するように、最大パケット長を規定すること。

表 8.4 にメモリマップの例を示す。
表 8.3: Assured 型ユーザトリガ Read 通信サービスで使用するメモリ領域。

表 8.4： Assured 型ユーザトリガ Read 通信サービス用メモリマップの例。

44

JERG-2-432

8.2.3.2 Assured 型ユーザトリガ Read 通信サービスの規定
1. ユーザ機器は Assured 型ユーザトリガ Read 通信サービスで使用するメモリ領域(8.2.3.1
章参照)を RMAP でアクセス可能にしておくこと。
2. 「リクエストフラグ領域」、「データサイズ領域」、「アクノレッジフラグ領域」については、マスタ側からの RMAP Read によるポーリングが一度で済むように、連続したメモリ空間に配置し、一度の RMAP Read で読み出されるように配置する。
3. マスタ機器は、Assured 型ユーザトリガ Read 通信サービスの処理ステータスを管理するためのステートマシンを保持すること。複数の機器について Assured 型ユーザトリガ Read 通信サービスを同時に処理する機能を提供する場合、それぞれの処理に必要なステートマシ
ンを独立して管理できること。
4. ユーザ機器は、Assured 型ユーザトリガ Read 通信サービスで出力したいデータ(Service
Data Unit)が発生した場合、データをデータ用のメモリ領域に配置してから、リクエスト
フラグをセットすることでマスタ側にリクエストを通知すること。
5. マスタ機器は規定時間ごとにユーザ機器のリクエスト状態(リクエストフラグ領域、データ
サイズ領域、アクノレッジフラグ領域)をまとめて一度に RMAP Read によって読み出す(リクエストポーリング)。読み出されたリクエストフラグおよびアクノレッジフラグの値は、マスタ機器の内部に保持する。ポーリングの RMAP Read トランザクションがネットワークの一時的な不具合によりタイムアウトした場合は、再送(再度の RMAP Read)は行なわず、リクエストフラグの更新を行なわない。
6. マスタ機器はリクエストフラグがセットさたユーザ機器について Assured 型ユーザトリガ
Read 通信サービスの収集シーケンスを開始し、データ収集を実施すること。
7. マスタ機器は Assured 型ユーザトリガ Read 通信サービスによるデータ収集のステートマ
シンとは独立に、規定周期ごとにポーリングを実施しつづけること。ステートマシンの状態遷移は、ポーリングの結果(リクエストフラグ、アクノレッジフラグの値の変化)を用いるため、ステートマシン側からポーリング結果が逐次参照可能である事。
8. アクノレッジフラグのセット/クリアのために用いる RMAP Write は、システム設計で規定されたスロットで実施すること。
9. マスタ機器は、RMAP Read によるユーザ機器からのデータ収集が完了した後、ユーザ機器のリクエストに対するアクノレッジを通知すること。
10. ユーザ機器はアクノレッジが書き込まれたことを検出してリクエストフラグをクリアすること。
11. データ収集およびアクノレッジの通信シーケンスの途中でタイムアウト、RMAP Status エ
ラー等が発生した場合、規定される上限回数まで再送制御を試行すること。上限回数まで試行してもユーザ機器からのデータ収集が完了しない場合、上位アプリケーションにエラ
ー情報を通知すること。(ポーリングについては定期的に実施することが規定されているため、再送は実施しない)

45

JERG-2-432
12. システム設計において、「ポーリングが実施される可能性のあるタイムスロット」、「デー
タ領域の読み出しが実施される可能性のあるタイムスロット」、「アクノレッジ領域に完了通知を書き込むタイムスロット」を規定すること。
13. マスタ機器は、Assured 型ユーザトリガ Read 通信サービスを使用するあるユーザ機器について少なくとも一つ、もしくはそれ以上の Assured 型ユーザトリガ Read 通信サービス用メ
モリ領域を管理できること。
推奨

上記 13 については、ユーザ機器一つについて一つの Assured 型ユーザトリガ Read 通信
サービスのメモリ領域を定義し、複数のデータ種別で同じ領域を使用することを推奨する。背景：これによりマスタ機器の設計が簡単化される。とくに、一つのユーザ機器について複数の Assured 型ユーザトリガ Read 通信サービスのメモリ領域を定義すると、定期的にリクエスト状態をポーリングする RMAP Read だけでも処理負荷が線形で増加してしまう。

8.2.3.3 Assured 型ユーザトリガ Read 通信サービスのトランザクション
図 8.9、図 8.10 に、Assured 型ユーザトリガ Read 通信サービスの通信シーケンスを示す。

図 8.9: Assured 型ユーザトリガ Read 通信サービスの通信シーケンス(ユーザ機器のデータ出力
リクエスト無し時)。
図 8.12、図 8.13、図 8.14 に Assured 型ユーザトリガ Read 通信サービスにおけるマスタ機器とユーザ機器の状態遷移図をしめす。
46

JERG-2-432

図 8.10: Assured 型ユーザトリガ Read 通信サービスの通信シーケンス。図 8.11 へ続く。

47

JERG-2-432

図 8.11: (図 8.10 から継続)Assured 型ユーザトリガ Read 通信サービスの通信シーケンス。

48

JERG-2-432

図 8.12: Assured 型ユーザトリガ Read 通信サービスにおけるマスタ機器のリクエストポーリン
グに関する状態遷移図。

8.2.3.4 Assured 型ユーザトリガ Read 通信サービスのパラメタ
メモリ領域
Assured 型ユーザトリガ Read 通信サービスで必要なメモリ領域のアドレス。
ポーリングのタイミング
リクエストフラグ領域を RMAP Read でポーリングするタイムスロットと周期。
アクノレッジフラグの RMAP Write のタイミング
Assured 型ユーザトリガ Read 通信サービスのシーケンス内で、マスタ機器がアクノレッジ
フラグ領域を RMAP Write でセット/クリアするタイムスロットと周期。
再送試行回数再送制御を試行する上限回数。メモリ領域ごとに異なる場合は領域ごとに指定。
タイムアウト時間
マスタ機器でタイムアウトを検知するまでの時間。

49

JERG-2-432

図 8.13: Assured 型ユーザトリガ Read 通信サービスにおけるマスタ機器の状態遷移図。

50

JERG-2-432

図 8.14: Assured 型ユーザトリガ Read 通信サービスにおけるユーザ機器の状態遷移図。

51

JERG-2-432
8.2.4

Best Effort 型ユーザトリガ Read 通信サービス

Best Effort 型ユーザトリガ Read 通信サービスは、Assured 型ユーザトリガ Read 通信サービ
スと比較して、通信シーケンスを簡略化することで高速なデータ伝送レートを提供する。ミッションセンサの観測データの TM Packet や、TC Packet を受けて生成される TM Packet 形式のメモ
リダンプデータの出力に使用することができる。通信シーケンスの単純化のため、マスタ機器がユーザ機器のデータ領域をアクセスする際のデータサイズはシステム設計で規定した固定値とする。最大値を超えない範囲で可変長のデータを出力する場合は、Idle パケットを定義して末尾をパディングしてマスタ機器からのデータ収集に対して固定サイズで返答する、もしくは、RMAP
Read Reply のデータサイズを、RMAP Read Command で指定されたものよりも短くして、データをパディングせずに返送することができる。
単純化された通信シーケンスを採用することにより、Assured 型ユーザトリガ Read 通信サー
ビスよりもマスタ機器、ユーザ機器の上位アプリケーションをハードウエアのみで実装することが容易であるため、ソフトウエアを用いた通信シーケンスと比較してもデータ伝送速度を向上させられる。
Best Effort 型ユーザトリガ Read 通信サービスの通信手順の概要は以下の通り。
1. ユーザ機器が Best Effort 型ユーザトリガ Read 通信サービスで出力したい Service Data
Unit 数を「出力要求パケット数メモリ領域」に設定する。あるユーザ機器のテレメトリ出
力レートが固定の場合は、システム設計で規定された固定値を設定する。
2. マスタ機器が RMAP Read を用いたポーリングによりユーザ機器から「出力要求パケット数
メモリ領域」を読み出す。
3. 「出力要求パケット数メモリ領域」が 0 でない場合、マスタ機器が RMAP Read を用いてユーザ機器から Service Data Unit を RMAP Read で読み出す(規定されているサイズを一括して読み込む)。1 パケット読み出すごとに、マスタ機器内部でユーザ機器毎に管理する出力要求パケット数カウンタを 1 減少させる。規定時間内に一つのユーザ機器から収集されるデータ数(パケット数)は、システム設計で規定される。
4. Best Effort 型ユーザトリガ Read 通信サービスのデータ領域にアクセスがあるたびに、ユーザ機器は内部で保持している出力要求パケット数カウンタを 1 ずつ減少させる。システ
ム設計で割り当てられた規定時間内のユーザ機器の収集数とマスタ機器の都合によっては、ユーザ機器が出力要求した全てのパケットが規定時間内に収集されないこともありえる。
5. マスタ機器がデータ収集する RMAP Read トランザクションで、タイムアウトや RMAP Replyのステータスエラーが発生しても、再送は実施しない(タイムアウトやステータスエラーの場合でも、
マスタ機器側で管理している出力要求パケット数カウンタは 1 減少させる)。
6. マスタ機器が管理する出力要求パケット数カウンタが 0 になったら、マスタ機器は保証型
データ収集サービスのシーケンスを完了する。規定時間内に 0 にならなかった場合でも、次のポーリングによって得られた出力要求パケット数カウンタの値でマスタ機器内部のカウンタを更新する。

52

JERG-2-432
8.2.4.1 Best Effort 型ユーザトリガ Read 通信サービスで使用するメモリ領域
Best Effort 型ユーザトリガ Read 通信サービスでは、表 8.5 のようなメモリ領域を使用する。
Best Effort 型ユーザトリガ Read 通信サービスを使用するユーザ機器はこれらのメモリ領域を
RMAP アクセス可能なように実装すること。表 8.6 に Best Effort 型ユーザトリガ Read 通信サー
ビスのメモリマップの例を示す。

表 8.5: Best Effort 型ユーザトリガ Read 通信サービスで使用するメモリ領域。

表 8.6： Best Effort 型ユーザトリガ Read 通信サービスのメモリマップの例。

8.2.4.2 Best Effort 型ユーザトリガ Read 通信サービスの規定
1. ユーザ機器は Best Effort 型ユーザトリガ Read 通信サービスで使用するメモリ領域(8.2.4.1 章参照)を RMAP でアクセス可能にしておくこと。
2. マスタ機器は、Best Effort 型ユーザトリガ Read 通信サービスの処理ステータスを管理するため、出力要求パケット数カウンタを Best Effort 型ユーザトリガ Read 通信サービスを使用するユーザ機器毎に保持すること。
3. ユーザ機器は、Best Effort 型ユーザトリガ Read 通信サービスで出力したいデータが発生した場合、データをデータ領域に配置してから、出力要求パケット数領域に値をセットすることでマスタ側にデータ出力リクエストを通知すること。
4. マスタ機器は規定時間ごとにユーザ機器の出力要求パケット数領域を RMAP Read によるポ53

JERG-2-432
ーリングを実施し、0 でない値がセットされていたら Best Effort 型ユーザトリガ Read
通信サービスの収集シーケンスを開始すること。ポーリングの RMAP Read トランザクショ
ンがネットワークの一時的な不具合によりタイムアウトした場合は、再送(再度の RMAP
Read)は行なわず出力要求パケット数カウンタの更新をしない。
5. 出力要求パケット数カウンタが 0 でない機器について、規定されたタイムスロットでマス
タ機器が RMAP Read を用いてユーザ機器からデータ収集すること(規定されているサイズを一括して読み込む)。1 パケット読み出すごとに、マスタ機器内部でユーザ機器毎に管理する出力要求パケット数カウンタを 1 減少させること。
6. Best Effort 型ユーザトリガ Read 通信サービスのデータ領域にアクセスがあるたびに、ユーザ機器はデータを返送するとともに、次の RMAP Read に備えてデータをメモリ領域にセットし、マスタ機器からの次の RMAP Read に対してデータを返せるようにすること。また、内部で保持している出力要求パケット数カウンタを 1 ずつ減少させること。
7. マスタ機器がデータ収集する RMAP Read トランザクションで、タイムアウトや RMAP Replyのステータスエラーが発生しても、再送は実施しない(タイムアウトやステータスエラーの場合でも、マスタ機器側で管理している出力要求パケット数カウンタは 1 減少させる)。
8. マスタ機器が管理する出力要求パケット数カウンタが 0 になったら、マスタ機器は保証型
データ収集サービスのシーケンスを完了すること。規定時間内に 0 にならなかった場合でも、次のポーリングによって得られた出力要求パケット数カウンタの値でマスタ機器内部のカウンタを更新すること。
9. マスタ機器は Best Effort 型ユーザトリガ Read 通信サービスによるデータ収集とは独立に、規定周期ごとに出力要求パケット数領域のポーリング(RMAP Read)を実施しつづけ、マ
スタ機器内部の出力要求パケット数カウンタを更新すること。
10. システム設計において、「出力要求パケット数カウンタ領域のポーリングが実施される可能性のあるタイムスロット」、「データ領域の読み出しが実施される可能性のあるタイムス
ロット」を規定すること。
11. システム設計において、Best Effort 型ユーザトリガ Read 通信サービスにおけるデータ
収集の RMAP Read サイズ(1 回の RMAP Read で読み出される TM Packet の最大サイズ)を規定すること。
12. システム設計において、規定時間内に個々のユーザ機器が出力できるパケット数とパケッ
トサイズを規定すること。また、とくにデータ伝送レートの計算においては、システム設
計で割り当てられた規定時間内のユーザ機器の収集数とマスタ機器の都合によっては、ユーザ機器が出力要求した全てのパケットが規定時間内に収集されないこともありえることに留意すること。
13. Best Effort 型ユーザトリガ Read 通信サービスでは、データ領域の RMAP Read について
タイムアウトやリプライステータスエラーによる再送を実施しないことに留意すること(一度ユーザ機器が RMAP Read Reply として返送したデータは、ユーザ機器側で上書きされるため、本サービス内では再送はできない)。
14. ユーザ機器は、出力したい Service Data Unit がデータ領域の 1 回の RMAP Read のサイズに対して短い場合、RMAP Read コマンドパケットで要求されるよりも短いバイト数のデー
54

JERG-2-432
タを返してもよい(この場合、RMAP Reply のデータ長フィールドを適切に設定すること)。
15. マスタ機器は、RMAP Read で要求したよりも短いデータ長の RMAP Reply パケットでも、格納された Service Data Unit を取り出すことが出来ること。
16. データ領域は、使用する最大パケット長を考慮し、それよりも大きいサイズとすること。
補足SpaceWire-D を使用する場合、通信レイテンシを考慮しても規定したタイムスロッ
ト内にトランザクションが完了するように、最大パケット長を規定すること。

55

JERG-2-432
8.2.4.3 Best Effort 型ユーザトリガ Read 通信サービスのトランザクション
図 8.15 と図 8.16 に、Best Effort 型ユーザトリガ Read 通信サービスの通信シーケンスを示す。

図 8.15: Best Effort 型ユーザトリガ Read 通信サービスの通信シーケンス(出力要求パケット数
領域のポーリング)。
8.2.4.4 Best Effort 型ユーザトリガ Read 通信サービスのパラメタ
メモリ領域
Best Effort 型ユーザトリガ Read 通信サービスで必要なメモリ領域のアドレス。
ポーリングのタイミング
出力要求パケット数領域を RMAP Read でポーリングするタイムスロットと周期。
データ収集のタイミング
データ領域を RMAP Read で読み出す可能性のあるタイムスロットと 1 タイムスロット内での

56

JERG-2-432
トランザクション数、連続する RMAP Read コマンドの最短の時間間隔。(ユーザ機器の RMAP
Target 機能が処理できる時間間隔、もしくは、シーケンシャルに処理が実行されてもタイム
アウト時間に影響しない時間間隔とすること)
タイムアウト時間
マスタ機器でタイムアウトを検知するまでの時間。

57

JERG-2-432

図 8.16: Best Effort 型ユーザトリガ Read 通信サービスの通信シーケンス(データ収集)。

58

JERG-2-432

8.3

Memory Access Service

Memory Access Service は、SpaceWire-RMAP では標準的に提供されるため、通信手順について特別な規定は設けない。

8.3.1

RMAP Read/Write による Memory Access Service

RMAP Read/Write でメモリアクセスする際の一般的な事項として以下の点を考慮すること。
1. 再送が必要な場合は上位層(SM&C 層等)で対応すること。
2. Memory Access Service で取り扱うデータは原則 Raw Data とすること。
3. 取り扱うデータが CCSDS Space Packet や Transfer Frame、Virtual Channel Data Unit 等の形式が規定された Service Data Unit の場合は、8.2 で規定する Packet Service のいず
れかの通信サービスを利用すること。
4. ユーザ機器が統一して具備すべきメモリマップおよび、ユーザ機器が RMAP Initiator 機器に対して RMAP のメモリ空間上で公開するメモリ領域は、システム設計の段階でマスタ機器とユーザ機器の間で ICD 等で共有すること。
5. 本サービスで扱うデータ形式は Raw Data であり、CCSDS Space Packet や Transfer Frame、
Virtual Channel Data Unit 等のように明示的なフォーマット規定が適用されないため、データの意味の理解に齟齬が生じないよう、各メモリ領域で読み書きされるデータのフォーマットおよび取りうる値の定義を、ICD 等で具体的に示すこと。
8.3.1.1 RMAP Read/Write による Memory Access Service のパラメタ
メモリ領域とアクセス方向
マスタ機器から RMAP アクセスされるメモリ領域のアドレスマップと、それぞれのメモリ領域の読み込み可能/書き込み可能属性。
アクセスのタイミング
RMAP Read/Write のタイミング(SpaceWire-D を採用する場合はタイムスロット指定)。
タイムアウト時間
マスタ機器でタイムアウトを検知するまでの時間。

59

JERG-2-432

8.4

Synchronization Service での時刻情報の配信

SpaceWire-RMAP による Synchronization Service として、SpaceWire Timecode では同期できない時刻の上位桁の情報を規定時間ごとにマスタ機器(時刻マスタ機器)からユーザ機器に RMAP
Write により配信する「マスタトリガ時刻 Write サービス」を提供する。

8.4.1

マスタトリガ時刻 Write サービス

8.4.1.1 マスタトリガ時刻 Write サービスの規定
1. マスタ機器は規定時間ごとにユーザ機器の時刻情報配信メモリ領域に RMAP Write で時刻情報を書き込むこと。
2. 書き込む時刻情報は、次の Timecode=0 の時点での時刻情報であること。
3. 時刻情報のフォーマットは、CCSDS Unsegmented Code (CUC)もしくは Raw Data とし、シス
テム設計の際に調整して規定すること。
4. システム設計上、時刻同期に再送制御が必要な場合は、エラーを含む Reply パケットの受信、もしくは Reply パケットの受信待ちタイムアウトをうけて、マスタ側で規定回数以内の再送を試行すること。再送制御については 8.1.3 章を適用すること。
5. ユーザ機器側では、書き込まれた時刻情報を、次の Timecode=0 の時刻として、内部の時刻情報を更新すること。
推奨事項 本設計標準では、マスタトリガ時刻 Write サービスについては再送制御を推奨しない。
理由：本設計標準における再送制御はトランジェント的な通信エラーを対象としているが、トランジェント的に時刻配信が失敗しても、ユーザ機器側で、ローカルクロックを用いて時刻の外挿が可能である。
注意事項 時刻配信で再送制御を用いる場合は、以下に注意すること。一般に、Reply 付きの RMAP
Write は Reply なしの場合にくらべてネットワークの帯域占有率やマスタ機器の処理負荷が高くなる(Reply 無しの場合と比べてトランザクションの状態管理、Reply パケットの解釈等の処理が追加されるため)。時刻配信は出来る限り同時に(たとえば同じ
タイムスロットで)複数機器に配信したいという要求がある場合が多く、時刻配信のユーザ機器が多数存在するとリアルタイム性能の低下が問題となりうるためシステム設計において十分な検討が必要である。
8.4.1.2 マスタトリガ時刻 Write サービスのトランザクション
図 8.17 に、再送制御無しのマスタトリガ時刻 Write サービスの RMAP トランザクションの流れを示す。
8.4.1.3 マスタトリガ時刻 Write サービスのパラメタ
配信周期
時刻配信を行なう周期。
時刻データの形式

60

JERG-2-432
時刻の上位桁を CCSDS Unsegmented Code (CUC)もしくは Raw Data 形式でどのように表現するか。

図 8.17: Reply なしでの時刻配信のトランザクション

メモリ領域
時刻上位桁を書き込むメモリアドレス。
再送の有無
再送制御を実施するかどうか。
再送までのタイムアウト時間
Reply パケットの受信待ちタイムアウトまでの時間。
再送試行回数再送制御を行なう場合、何度まで再送制御を試行するか。

61

JERG-2-432

8.5 ASTRO-H/Hisaki の通信サービス定義との対応(参考)本設計標準の SpaceWire-RMAP を用いた通信サービス定義のベースとなった科学衛星(ASTROH/Hisaki)での通信サービスとの対応を表 8.7 に示す。
表 8.7: ASTRO-H/Hisaki での通信サービスとの対応関係

62

JERG-2-432

第 9 章 SpaceWire-PTP による Subnetwork service
SpaceWire-PTP による Subnetwork service
9.1

概要

1. SpaceWire-PTP を用いた Subnetwork service は、以下のサービスを提供可能である。
(a) Packet Service(b) Synchronization Service に必要な時刻情報の配信
2. SpaceWire-PTP を用いた Subnetwork service では送達確認、再送制御、セグメンテーショ
ンは実施しない。これらの機能が必要な場合は、SpaceWire-R による Subnetwork service を採用するか、上位層(SM&C 層等)で別途規定すること。
3. データ伝送のリアルタイム性保証、パケット転送の遅延時間の最悪値保証が必要な場合は、TimeCode を用いた時分割制御(§4)を下位の層として利用すること。
4. Memory Access Service は提供しない。Memory Access Service が必要な場合は、SpaceWireRMAP を用いた Subnetwork service を利用するか、上位層で通信手順を規定すること。
5. SpaceWire ネットワークのトポロジとリンクレートを設計する際は、各機器から送出される CCSDS Space Packet のデータ量を十分に伝送可能な通信経路と帯域を確保すること。

9.2

Packet Service

SpaceWire-PTP を用いた Packet Service では、SpaceWire-PTP の規定に基づいて CCSDS Space
Packet を SpaceWire パケットにカプセル化し、ノード間で SpaceWire パケットとして伝送する。

9.2.1

Packet Service の規定

1. 伝送するデータ形式は CCSDS Space Packet とすること。
2. CCSDS Space Packet を送出する機器は、上位アプリケーションからの要求に基づいて CCSDSSpace Packet を、指定された宛先情報(SpaceWire パスアドレスとロジカルアドレス)を付与
して SpaceWire パケット化し、送出すること。
補足

名称が似ているが、「SpaceWire-PTP で規定される CCSDS Packet Transfer Service(適用文書 4 の§5.2)」を利用して、「CCSDS SOIS Subnetwork service の Packet Serviceを実現する」ということに対応する。

3. CCSDS Space Packet を受信した機器では、上位層で規定された動作を実行すること。
例 衛星制御装置からの TC Packet を受信した機器は、その TC Packet を実行する。
63

JERG-2-432
例 センサ機器からの TM Packet を受信したマスメモリは、その TM Packet を記録領域に書
き込む。

9.2.2

Packet Service のパラメタ

データ生成量と宛先
各機器において生成/送出される CCSDS Space Packet のパケット長、頻度、宛先。
CCSDS Space Packet の最大長
機器間を伝送される CCSDS Space Packet の最大長。
CCSDS Space Packet 送出のタイミング(TimeCode を用いた時分割制御(§4)を採用する場合)各機器がどのタイムスロットでどの宛先へのパケットを送出するか。

9.3

Synchronization Service での時刻情報の配信

SpaceWire-PTP を用いた Synchronization Service では、SpaceWire Timecode では同期できない時刻情報を、時刻マスタ機器から各機器に配信する機能を提供する。

9.3.1

時刻情報配信の規定

1. 時刻情報は CCSDS Unsegmented Code (CUC)形式とすること。
2. 伝送される CCSDS Unsegmented Code (CUC)は、次の SpaceWire Timecode=0 のタイミング
での時刻情報とすること。
3. CCSDS Unsegmented Code (CUC)を受信したノードでは、受信した時刻情報をもとに、SpaceWire Timecode=0 のタイミング、もしくは機器内部で規定したタイミングで内部の時
刻情報を更新すること。
4. SpaceWire の仕様上、複数機器への同時配信はできない。時刻マスタ機器は時刻配信対象となる機器ごとに独立の SpaceWire パケットを生成し、SpaceWire-PTP で送付すること。

9.3.2

時刻情報配信のパラメタ

時刻情報を送信する対象機器
SpaceWire ネットワークに接続される機器のうち、どの機器に時刻情報の配信を行なうか。
各機器への時刻情報送信のタイミング(TimeCode を用いた時分割制御(§4)を採用する場合)各対象機器宛に CCSDS Unsegmented
Code (CUC)を送信する周期と位相(タイムスロット)。

64

JERG-2-432

第 10 章 SpaceWire-R による Subnetwork service
SpaceWire-R による Subnetwork service
10.1 概要
1. SpaceWire-R を用いた Subnetwork service は以下のサービスを提供可能である。
(a) Packet Service(b) Synchronization Service に必要な時刻情報の配信
2. SpaceWire-R を用いた Subnetwork service では、SpaceWire-R プロトコルが提供する機能
により送達確認、再送制御、セグメンテーションが自動的に実施される。
3. データ伝送のリアルタイム性保証、パケット転送の遅延時間の最悪値保証が必要な場合は、TimeCode を用いた時分割制御(§4)を下位の層として利用すること。
4. Memory Access Service は提供しない。Memory Access Service が必要な場合は、SpaceWireRMAP を用いた Subnetwork service を利用するか、上位層で通信手順を規定すること。
5. SpaceWire-R による通信では、SpaceWire-RMAP/SpaceWire-PTP よりも設定すべきパラメタが多く存在する。設計・検証・運用の信頼性を高めつつ工数を削減するため、システム設計の段階で§10.2.2 や§10.3.2 で提示された事項を考慮し、ICD 等で共有して理解の齟齬が発生しないよう注意すること。
推奨SpaceWire-R プロトコルを用いた通信は、センサ機器とマスメモリの間や、マスメモリとダウンリンク装置の間等、peer-to-peer 接続に近いトポロジにおいて適用することを推奨する。これは、SpaceWire-R プロトコルによる通信では、セグメンテーションや Acknowledge、再送制御により SpaceWire 層での帯域使用効率や再送発生時のパケット伝送の遅延時間増
大の計算が複雑化するためである。多数の SpaceWire ルータで構成される大規模なSpaceWire ネットワーク全体で SpaceWire-R プロトコルを使用して設計検証を実施することは多数の工数がかかると予想される。peer-to-peer に近いトポロジでは、性能の見積もりは比較的容易であり、本設計標準でもハンドブックとして具体的な性能パラメタを提示する(関連文書)。

10.2

Packet Service

SpaceWire-R を用いた Packet Service では、SpaceWire-R の規定に基づいて Service Data
Unit をノード間で SpaceWire パケットとして伝送する。

10.2.1

Packet Service の規定

1. 伝送するデータ形式は Service Data Unit である。

65

JERG-2-432
2. 送出側では、上位アプリケーションの Space Packet 送信要求をうけて、指定されたSpacePacket を送出すること。
例 衛星制御装置からの TC Packet を受信した機器は、その TC Packet を実行する。
例 センサ機器からの TM Packet を受信したマスメモリは、その TM Packet を記録領域に書き込む。
10.2.1.1 Packet Service の通信手順
図 10.1 に SpaceWire-R による Packet Service の通信手順を示す。

10.2.2

Packet Service のパラメタ

SpaceWire-R の設計パラメタ
適用文書 5 で示される設計パラメタ群。
データ生成量と宛先
各機器において生成/送出される Service Data Unit のパケット長、頻度、宛先。
通信チャネルの OPEN/CLOSE のタイミング
各通信チャネルを OPEN/CLOSE する際のタイミング。
例

電源投入後、自動的に Transmit TEP のステートマシンを Closed ステートから Enabled
ステートに状態遷移し、常時 OPEN コマンド送出。
例
SpaceWire-RMAP や SpaceWire-PTP による Packet Service(もしくは Memory Access
Service)で、Transmit TEP を管理する上位アプリケーションを制御して、Transmit TEPのステートマシンを Closed ステートから Enabled ステートに状態遷移させる。
Transmit TEP/Receive TEP のパラメタ設定方法
各 Transmit TEP に、Receive TEP の SpaceWire アドレス/チャネル番号を設定する方法。各
Receive TEP に、OPEN コマンドを受け付ける Transmit TEP の情報(チャネル番号、SpaceWire
ロジカルアドレス等)を設定する方法。
Service Data Unit の最大長
機器間を伝送される Service Data Unit の最大長。
Service Data Unit 送出のタイミング(TimeCode を用いた時分割制御(§4)を採用する場合)各機器がどのタイムスロットでどの宛先へのパケットを送出するか。

10.3

Synchronization Service での時刻情報の配信

SpaceWire-R を用いた Synchronization Service では、SpaceWire Timecode では同期できな
い時刻情報を、時刻マスタ機器から各機器に配信する機能を提供する。

10.3.1

時刻配信の規定

1. 時刻情報は CCSDS Unsegmented Code (CUC)形式とすること。
2. 伝送される CCSDS Unsegmented Code (CUC)は、次の SpaceWire Timecode=0 のタイミング
での時刻情報とすること。
66

JERG-2-432

3. CCSDS Unsegmented Code (CUC)を受信したノードでは、受信した時刻情報をもとに、SpaceWire Timecode=0 のタイミング、もしくは機器内部で規定したタイミングで内部の時
刻情報を更新すること。
補足SpaceWire-R では、再送を伴う可能性がある。CUC の送信は TimeCode=0 のタイミングに対して最大再送回数分のマージンを持った設計とすること。

4. SpaceWire の仕様上、複数機器への同時配信はできない。時刻マスタ機器は時刻配信対象となる機器ごとに独立の SpaceWire パケットを生成し、SpaceWire-R で送付すること。
5. Synchronization Service を利用する場合は、SpaceWire-R のセグメントサイズは CCSDS
Unsegmented Code (CUC)を 1 セグメントとして伝送できるサイズ以上にすること。
10.3.1.1 時刻配信の通信手順
SpaceWire-R を用いた時刻配信の通信手順は、図 10.1 と同様。受信側では、CCSDS Unsegmented
Code (CUC)を受信したあとで時刻情報の更新処理が追加される。

10.3.2

時刻配信のパラメタ

SpaceWire-R の設計パラメタ
適用文書 5 で示される設計パラメタ群。
通信チャネルの OPEN/CLOSE のタイミング
各通信チャネルを OPEN/CLOSE する際のタイミング。
例

電源投入後、自動的に Transmit TEP のステートマシンを Closed ステートから Enabled
ステートに状態遷移し、常時 OPEN コマンド送出。
例
SpaceWire-RMAP や SpaceWire-PTP による Packet Service(もしくは Memory Access
Service)で、Transmit TEP を管理する上位アプリケーションを制御して、Transmit TEPのステートマシンを Closed ステートから Enabled ステートに状態遷移させる。
Transmit TEP/Receive TEP のパラメタ設定方法
各 Transmit TEP に、Receive TEP の SpaceWire アドレス/チャネル番号を設定する方法。各
Receive TEP に、OPEN コマンドを受け付ける Transmit TEP の情報(チャネル番号、SpaceWire
ロジカルアドレス等)を設定する方法。
時刻情報を送信する対象機器
SpaceWire ネットワークに接続される機器のうち、どの機器に時刻情報の配信を行なうか。
各機器への時刻情報送信のタイミング(TimeCode を用いた時分割制御(§4)を採用する場合)各対象機器宛に CCSDS Unsegmented
Code (CUC)を送信する周期と位相(タイムスロット)。

67

JERG-2-432

図 10.1: SpaceWire-R による Packet Service の通信手順。

68