CII Data and Software Interface Guidelines
CII Data and Software Interface Guidelines Ben Bornstein NASA CII Team
General Background Surveyed existing spacecraft data interfaces:
MIL-STD-1553 RS-232, RS-422 Compact PCI SpaceWire CCSDS, CADU, ISS EXPRESS, TCP/UDP, and various other (packet) data formats
Met with spacecraft providers to determine capability:
Ball Air Force Space Test Program Lockheed Martin Orbital Surrey 2
General Background Reviewed common interface practice:
GSFC GIRD Decadal Survey Common Spacecraft Bus Study JWST SpaceWire ICD Glory APS, Cloud Camera, TIM ICDs ICESat2 ICD SIM Combiner Space Test Program – Standard Interface Vehicle
Conducted frequent CII Data Guidelines peer reviews:
CII Workshop I Josep Rosello, Wahida Ghasti, David Jemeux (ESA) Glenn Rakow (GSFC) Mike Marlow (Kirtland, AFB; DoD Space Test Program) 3
Data Interface Goals
Low-power data transmission High data rate transmission with scalable capacity Lightweight protocol Leverage existing standards and practices as much as practical Minimally intrusive to spacecraft provider and instrument designer
4
Data Interface Assumptions The instrument is autonomous, in particular the instrument includes:
an onboard processor packet processing telemetry monitoring command and data handling stored command sequences (science) data storage, compression, and playback
The spacecraft acts largely as a passive relay of instrument commands and engineering and science data Autonomous instruments and passive relay spacecraft require far fewer changes to spacecraft flight software, ground software, and mission operating systems. 5
Data Interface Drivers SpaceWire systems have achieved industry acceptance for LEO spacecraft. SpaceWire achieves a low-power consumption, high data rate interface with a scalable capacity in the range of 2–400 Mbps. CCSDS packet format is common practice across aerospace flight and ground data systems. CII Data messages communicate standard information about spacecraft and instrument status, time, telemetry, and science data in a well-accepted fashion CRCs for error detection, command acknowledgements to assist in fault detection, SAFE mode for contingency situations
6
Summary of Guidelines
5.2
5.3
5.4 5.5
5.1.1 Goals 5.1.2 Assumptions 5.1.3 Drivers 5.1.4 Nomenclature 5.1.5 Conventions Applicable Documents 5.1.6 SpaceWire SpaceWire Clock and Data Rate 5.2.2 SpaceWire Time Codes 5.2.3 5.2.4 SpaceWire Redundancy (optional) CII Messages, Packet Formats, and Protocol CII Messages 5.3.1 5.3.2 CII Basic Packet Format 5.3.3 Spacecraft Status Message 5.3.4 Instrument Command 5.3.5 Instrument Command Acknowledgement 5.3.6 Instrument Telemetry 5.3.7 Instrument Science Data Data Management Software
7
Instrument Modes
Preferred path to OFF
OFF / SURVIVAL
SAFE
INITIALIZATION
OPERATION
Within the OPERATION mode, instruments may define additional sub-modes specific to their operation (e.g. STANDBY, DIAGNOSTIC, MEASUREMENT, etc.). 8
Key LEO Guidelines ID
Function
5.2.1.1 Data SpaceWire
5.2.1.2 Data SpaceWire
Guidelines
Rationale/Co mment
The instrument should process and receive all commands and time messages exclusively using SpaceWire (ECSS‐E‐ ST‐50‐12C)
Low Power, High Data Rate
The instrument should send all telemetry and science data exclusively using SpaceWire (ECSS‐E‐ ST‐50‐12C)
Low Power, High Data Rate
9
Key LEO Guidelines ID
Function
5.2.2.1 Data SpaceWire
Guidelines
Rationale/Co mment
The SpaceWire link between the instrument and spacecraft should be clocked at 10 MHz in both directions*.
Default 10 Mbps requires no data rate handshake; offers margin
CII Workshop I Feedback Led to significantly increased data rate *
This provides a total data rate of 10 Mbps and, accounting for SpaceWire overhead, a useable data rate of 8 Mbps. 10
Key LEO Guidelines ID
Function
5.3.1.1 Data Protocol
Guidelines
Rationale/Co mment
Each CII message type should flow only in the single direction indicated in Table 5‐1.
Defined data paths and messages
11
Key LEO Guidelines ID
Function Guidelines
5.3.2.1 Data Protocol
The structure of a complete CII SpaceWire packet should conform to that depicted in Figure 5‐1.
Rationale/Co mment CCSDS Header for packet control; CRC for reliability
CII Workshop I Feedback Uncovered packet specification issue 12
Key LEO Guidelines ID
Function Guidelines
5.3.3.1 Data
The instrument should Time and receive and process CII Ephemeris Spacecraft Status Messages containing the current spacecraft time and position.
Rationale/Co mment Time via CCSDS Secondary Header and SpaceWire time codes
5.3.3.3 Data
The spacecraft should send High Time and status messages at one resolution Ephemeris second intervals. position information
13
Key LEO Guidelines ID
Function Guidelines
5.3.4.1 Data Command
5.3.4.3 Data Command
Rationale/Co mment
The instrument should receive and process CII Command Messages from the spacecraft.
Spacecraft can SAFE instrument
The instrument should receive and process no more than 10 spacecraft or ground commands per second.
Based on survey of instrument clock rates
14
Key LEO Guidelines ID
Function Guidelines
5.3.4.4 Data Command
*
With the exception of the Enter SAFE Mode command message, the instrument should process all CII Command Messages in the order received*.
Rationale/Co mment Deterministic commanding; Instrument SAFE is highest priority
Implies instrument should support some command buffering capability. 15
Key LEO Guidelines ID
Function Guidelines
5.3.4.8 Data Command
Rationale/Co mment
Instruments providers should define and furnish spacecraft providers with a complete Command Dictionary.
Command Id
Best practice; Facilitates spacecraft operations
Command Message
0x0000 No Operation (no-op) 0x0011 Start Sending Telemetry 0x00FF Stop Sending (Telemetry or Science) Data 0x5AFE Enter
SAFE
mode
0x00FF–0xFFFF Instrument specific commands
CII Workshop I Feedback Led to Data Flow‐Control
16
Key LEO Guidelines ID
Function Guidelines
5.3.5.1 Data Command
The instrument should reply to every command received with a CII Command Acknowledgment Message.
Rationale/Co mment Best practice; Reliable commanding and fault detection
17
Key LEO Guidelines ID
Function Guidelines
5.3.6.1 Data Telemetry
5.3.6.8 Data Telemetry
Rationale/Co mment
The instrument should transmit engineering, health, and accountability (EHA) telemetry data at a rate of up to 10 Hz.
Based on survey of instrument clock rates
Instruments providers should define and furnish spacecraft providers with a complete Telemetry Dictionary.
Facilitates instrument monitoring of critical values by spacecraft provider 18
Key LEO Guidelines ID
Function Guidelines
5.3.7.1 Data Science
Rationale/Co mment
The instrument should limit Based on data its maximum number of rate analysis science data packets to match the SpaceWire data rate specified in Section 5.2.2.
10 Mbps total 8. 00 Mbps usable (in each direction) – 7% packet overhead 0.60 Mbps – 10 Hz telemetry 0.02 Mbps Useable Science Data Rate: 7.38 Mbps 19
Key LEO Guidelines ID
Function Guidelines
Rationale/Co mment
5.4.1.1 Data The instrument should be Management responsible for its own – 5.4.1.3 science data onboard storage, compression, and playback capabilities 5.4.1.4 Data Management
Instrument buffering reduces spacecraft burden, Science data playback maximizes should be coordinated with rideshare the spacecraft operations opportunities team.
20
Key LEO Guidelines ID
Function Guidelines
5.5.1.1 Software Instrument control flight software should be developed according to NASA Class C software development requirements.
Rationale/Co mment CII Level 1 Guidelines: Class C Instrument; see NASA NPR 7150.2A for details
21
Key LEO Guidelines ID
Function Guidelines
Rationale/Co mment
5.5.2.1 Software Instrument control flight software should be updatable on orbit through ground command.
Best practice; Facilitates updates and workarounds
5.5.2.2 Software Individual memory addresses of instrument control software should be updatable on orbit through ground command.
Best practice; Facilitates updates and workarounds
22
GEO Considerations CII Data and Software Interface Guidelines are expected to remain largely invariant for both LEO and GEO spacecraft. To GEO Spacecraft Providers: How well is SpaceWire supported both now and in the future?
23
CII Workshop 1 Feedback The following changes were made to the CII Data Interface Guidelines based upon the feedback received from the CII Workshop I: Maximum data rate was increased from 1.5 Mbps to 10 Mbps Instrument data flow-control commands were defined to assist in fault detection, isolation, and recovery (FDIR) scenarios A CII data packet specification issue was addressed Minor inconsistencies in terminology and other errata have been addressed Rationale/Comments were added for all CII Guidelines considered to be “Key”
We hear you and appreciate your input Please keep it coming 24
Reference Protocol (Backup)
25
5.3.2.1 CII Packet Format
*
CII builds upon several SpaceWire and packet data standards. 256 byte packet size by Northrup Grumman / JWST recommendation. CRC provides reliable data transport for instruments that may require it; adds verification to commanding.
GOES‐R CRC is the standard CRC8, ATM (HEC): x8 + x2 + x + 1, with an initial value of all bits set to 1.
26
5.3.2.11 CII CCSDS Headers (1/3)
CCSDS Primary Header Packet Identification Packet Sequence Control Packet Version Number
Type
3 bits
1 bit
Secondary Header Flag 1 bit 2 bytes
ApID
Sequence Flags
Sequence Count
Packet Length
11 bits
2 bits
14 bits
16 bits 2 bytes
2 bytes
CCSDS Secondary Header CCSDS Unsegmented Time Code (CUC) Field P-Field T-Field Default Extended Coarse Time Fine Time 1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
CII utilizes standardized CCSDS header format for information common to all packetized telemetry (e.g. type, length, counters, and time). 27
5.3.2.11 CII CCSDS Headers (2/3) Primary Header
CCSDS Packet Data Secondary Header (Time)
6 bytes
9 bytes
Data 0–236 bytes (TBR)
CCSDS Primary Header Packet Identification Packet Sequence Control Packet Version Number
Type
3 bits
1 bit
Secondary Header Flag 1 bit 2 bytes Field
Packet Version Number Packet Type Secondary Header Flag
ApID
Sequence Flags
Sequence Count
Packet Length
11 bits
2 bits
14 bits
16 bits 2 bytes
2 bytes Length (bits) 3 1 1
Application Process Identifier Sequence Flags Sequence Count
11 2 14
Packet Length
16
Value
Comments
0b001 CII Packet Version 1 0b CII SpaceWire-CCSDS packet 0b1 Indicates the CII-CCSDS secondary header is present 0–2048 Reserved for instrument use 0b11 Indicates packet is unsegmented 0–16383 Specifies the packet sequence count. The packet count begins at zero and resumes at zero after 16384 packets have been sent. 0–236 Specifies the length of the packet data field in bytes. 28
5.3.2.11 CII CCSDS Headers (3/3) Primary Header
CCSDS Packet Data Secondary Header (Time)
6 bytes
9 bytes
Data 0–236 bytes (TBR)
CCSDS Secondary Header CCSDS Unsegmented Time Code (CUC) Field P-Field T-Field Default Extended Coarse Time Fine Time 1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
Contains elapsed time (ET) in coarse (seconds) and fine (subsecond) units since the default CCSDS epoch of January 1, 1958 Example:
From 1/1/58 to 2/7/11 is 1,675,728,000s
Coarse: 0x63 0xE1 0x94 0x80
125ms clock tick is 224 ÷ 8 = 2,097,152 sub-s
Fine:
0x02 0x00 0x00
SpaceWire 6-bit time code embedded in the CUC Extended time P-Field1 1Defined in the SpaceWire
– CCSDS Unsegmented Code Transfer Protocol (proposed)
29
5.3.3 CII Spacecraft Status Message
Spacecraft time is contained in CCSDS Secondary Header 80 bytes of data: 4-element, double-precision, non-dimensional quaternion 3-element, double-precision, position vector (X) 3-element, double-precision, inertial velocity vector (V)
Follows STP–SIV ephemeris message format 30
5.3.4 CII Instrument Command
31
5.3.5 CII Command Acknowledgement
• Instrument Mode field: – First two bits denote the instrument major mode: INITIALIZATION (0b00), OPERATION (0b01), or SAFE (0b10) – Remaining bits may be used at the instrument’s discretion
• Command Source, Command ID, and CCSDS Primary Header Sequence Count fields are echoed from the command packet being acknowledged 32
5.3.6 CII Instrument Telemetry
• Instrument Mode field: – First two bits denote the instrument major mode: INITIALIZATION (0b00), OPERATION (0b01), or SAFE (0b10) – Remaining bits may be used at the instrument’s discretion • 58 telemetry values per packet / telemetry bank • To facilitate spacecraft monitoring, each instrument telemetry value should be encoded as either: – a standard two’s complement 32‐bit signed integer, – a 32‐bit unsigned integer, or – a IEEE‐754 floating‐point values 33
5.3.7 CII Instrument Science Data
• All science data is opaque to the spacecraft. • The instrument should be responsible for its own: – science data compression, – onboard storage, and – playback
• Data playback should be coordinated with the spacecraft operations team. 34
General Background Surveyed existing spacecraft data interfaces:
MIL-STD-1553 RS-232, RS-422 Compact PCI SpaceWire CCSDS, CADU, ISS EXPRESS, TCP/UDP, and various other (packet) data formats
Met with spacecraft providers to determine capability:
Ball Air Force Space Test Program Lockheed Martin Orbital Surrey 2
General Background Reviewed common interface practice:
GSFC GIRD Decadal Survey Common Spacecraft Bus Study JWST SpaceWire ICD Glory APS, Cloud Camera, TIM ICDs ICESat2 ICD SIM Combiner Space Test Program – Standard Interface Vehicle
Conducted frequent CII Data Guidelines peer reviews:
CII Workshop I Josep Rosello, Wahida Ghasti, David Jemeux (ESA) Glenn Rakow (GSFC) Mike Marlow (Kirtland, AFB; DoD Space Test Program) 3
Data Interface Goals
Low-power data transmission High data rate transmission with scalable capacity Lightweight protocol Leverage existing standards and practices as much as practical Minimally intrusive to spacecraft provider and instrument designer
4
Data Interface Assumptions The instrument is autonomous, in particular the instrument includes:
an onboard processor packet processing telemetry monitoring command and data handling stored command sequences (science) data storage, compression, and playback
The spacecraft acts largely as a passive relay of instrument commands and engineering and science data Autonomous instruments and passive relay spacecraft require far fewer changes to spacecraft flight software, ground software, and mission operating systems. 5
Data Interface Drivers SpaceWire systems have achieved industry acceptance for LEO spacecraft. SpaceWire achieves a low-power consumption, high data rate interface with a scalable capacity in the range of 2–400 Mbps. CCSDS packet format is common practice across aerospace flight and ground data systems. CII Data messages communicate standard information about spacecraft and instrument status, time, telemetry, and science data in a well-accepted fashion CRCs for error detection, command acknowledgements to assist in fault detection, SAFE mode for contingency situations
6
Summary of Guidelines
5.2
5.3
5.4 5.5
5.1.1 Goals 5.1.2 Assumptions 5.1.3 Drivers 5.1.4 Nomenclature 5.1.5 Conventions Applicable Documents 5.1.6 SpaceWire SpaceWire Clock and Data Rate 5.2.2 SpaceWire Time Codes 5.2.3 5.2.4 SpaceWire Redundancy (optional) CII Messages, Packet Formats, and Protocol CII Messages 5.3.1 5.3.2 CII Basic Packet Format 5.3.3 Spacecraft Status Message 5.3.4 Instrument Command 5.3.5 Instrument Command Acknowledgement 5.3.6 Instrument Telemetry 5.3.7 Instrument Science Data Data Management Software
7
Instrument Modes
Preferred path to OFF
OFF / SURVIVAL
SAFE
INITIALIZATION
OPERATION
Within the OPERATION mode, instruments may define additional sub-modes specific to their operation (e.g. STANDBY, DIAGNOSTIC, MEASUREMENT, etc.). 8
Key LEO Guidelines ID
Function
5.2.1.1 Data SpaceWire
5.2.1.2 Data SpaceWire
Guidelines
Rationale/Co mment
The instrument should process and receive all commands and time messages exclusively using SpaceWire (ECSS‐E‐ ST‐50‐12C)
Low Power, High Data Rate
The instrument should send all telemetry and science data exclusively using SpaceWire (ECSS‐E‐ ST‐50‐12C)
Low Power, High Data Rate
9
Key LEO Guidelines ID
Function
5.2.2.1 Data SpaceWire
Guidelines
Rationale/Co mment
The SpaceWire link between the instrument and spacecraft should be clocked at 10 MHz in both directions*.
Default 10 Mbps requires no data rate handshake; offers margin
CII Workshop I Feedback Led to significantly increased data rate *
This provides a total data rate of 10 Mbps and, accounting for SpaceWire overhead, a useable data rate of 8 Mbps. 10
Key LEO Guidelines ID
Function
5.3.1.1 Data Protocol
Guidelines
Rationale/Co mment
Each CII message type should flow only in the single direction indicated in Table 5‐1.
Defined data paths and messages
11
Key LEO Guidelines ID
Function Guidelines
5.3.2.1 Data Protocol
The structure of a complete CII SpaceWire packet should conform to that depicted in Figure 5‐1.
Rationale/Co mment CCSDS Header for packet control; CRC for reliability
CII Workshop I Feedback Uncovered packet specification issue 12
Key LEO Guidelines ID
Function Guidelines
5.3.3.1 Data
The instrument should Time and receive and process CII Ephemeris Spacecraft Status Messages containing the current spacecraft time and position.
Rationale/Co mment Time via CCSDS Secondary Header and SpaceWire time codes
5.3.3.3 Data
The spacecraft should send High Time and status messages at one resolution Ephemeris second intervals. position information
13
Key LEO Guidelines ID
Function Guidelines
5.3.4.1 Data Command
5.3.4.3 Data Command
Rationale/Co mment
The instrument should receive and process CII Command Messages from the spacecraft.
Spacecraft can SAFE instrument
The instrument should receive and process no more than 10 spacecraft or ground commands per second.
Based on survey of instrument clock rates
14
Key LEO Guidelines ID
Function Guidelines
5.3.4.4 Data Command
*
With the exception of the Enter SAFE Mode command message, the instrument should process all CII Command Messages in the order received*.
Rationale/Co mment Deterministic commanding; Instrument SAFE is highest priority
Implies instrument should support some command buffering capability. 15
Key LEO Guidelines ID
Function Guidelines
5.3.4.8 Data Command
Rationale/Co mment
Instruments providers should define and furnish spacecraft providers with a complete Command Dictionary.
Command Id
Best practice; Facilitates spacecraft operations
Command Message
0x0000 No Operation (no-op) 0x0011 Start Sending Telemetry 0x00FF Stop Sending (Telemetry or Science) Data 0x5AFE Enter
SAFE
mode
0x00FF–0xFFFF Instrument specific commands
CII Workshop I Feedback Led to Data Flow‐Control
16
Key LEO Guidelines ID
Function Guidelines
5.3.5.1 Data Command
The instrument should reply to every command received with a CII Command Acknowledgment Message.
Rationale/Co mment Best practice; Reliable commanding and fault detection
17
Key LEO Guidelines ID
Function Guidelines
5.3.6.1 Data Telemetry
5.3.6.8 Data Telemetry
Rationale/Co mment
The instrument should transmit engineering, health, and accountability (EHA) telemetry data at a rate of up to 10 Hz.
Based on survey of instrument clock rates
Instruments providers should define and furnish spacecraft providers with a complete Telemetry Dictionary.
Facilitates instrument monitoring of critical values by spacecraft provider 18
Key LEO Guidelines ID
Function Guidelines
5.3.7.1 Data Science
Rationale/Co mment
The instrument should limit Based on data its maximum number of rate analysis science data packets to match the SpaceWire data rate specified in Section 5.2.2.
10 Mbps total 8. 00 Mbps usable (in each direction) – 7% packet overhead 0.60 Mbps – 10 Hz telemetry 0.02 Mbps Useable Science Data Rate: 7.38 Mbps 19
Key LEO Guidelines ID
Function Guidelines
Rationale/Co mment
5.4.1.1 Data The instrument should be Management responsible for its own – 5.4.1.3 science data onboard storage, compression, and playback capabilities 5.4.1.4 Data Management
Instrument buffering reduces spacecraft burden, Science data playback maximizes should be coordinated with rideshare the spacecraft operations opportunities team.
20
Key LEO Guidelines ID
Function Guidelines
5.5.1.1 Software Instrument control flight software should be developed according to NASA Class C software development requirements.
Rationale/Co mment CII Level 1 Guidelines: Class C Instrument; see NASA NPR 7150.2A for details
21
Key LEO Guidelines ID
Function Guidelines
Rationale/Co mment
5.5.2.1 Software Instrument control flight software should be updatable on orbit through ground command.
Best practice; Facilitates updates and workarounds
5.5.2.2 Software Individual memory addresses of instrument control software should be updatable on orbit through ground command.
Best practice; Facilitates updates and workarounds
22
GEO Considerations CII Data and Software Interface Guidelines are expected to remain largely invariant for both LEO and GEO spacecraft. To GEO Spacecraft Providers: How well is SpaceWire supported both now and in the future?
23
CII Workshop 1 Feedback The following changes were made to the CII Data Interface Guidelines based upon the feedback received from the CII Workshop I: Maximum data rate was increased from 1.5 Mbps to 10 Mbps Instrument data flow-control commands were defined to assist in fault detection, isolation, and recovery (FDIR) scenarios A CII data packet specification issue was addressed Minor inconsistencies in terminology and other errata have been addressed Rationale/Comments were added for all CII Guidelines considered to be “Key”
We hear you and appreciate your input Please keep it coming 24
Reference Protocol (Backup)
25
5.3.2.1 CII Packet Format
*
CII builds upon several SpaceWire and packet data standards. 256 byte packet size by Northrup Grumman / JWST recommendation. CRC provides reliable data transport for instruments that may require it; adds verification to commanding.
GOES‐R CRC is the standard CRC8, ATM (HEC): x8 + x2 + x + 1, with an initial value of all bits set to 1.
26
5.3.2.11 CII CCSDS Headers (1/3)
CCSDS Primary Header Packet Identification Packet Sequence Control Packet Version Number
Type
3 bits
1 bit
Secondary Header Flag 1 bit 2 bytes
ApID
Sequence Flags
Sequence Count
Packet Length
11 bits
2 bits
14 bits
16 bits 2 bytes
2 bytes
CCSDS Secondary Header CCSDS Unsegmented Time Code (CUC) Field P-Field T-Field Default Extended Coarse Time Fine Time 1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
CII utilizes standardized CCSDS header format for information common to all packetized telemetry (e.g. type, length, counters, and time). 27
5.3.2.11 CII CCSDS Headers (2/3) Primary Header
CCSDS Packet Data Secondary Header (Time)
6 bytes
9 bytes
Data 0–236 bytes (TBR)
CCSDS Primary Header Packet Identification Packet Sequence Control Packet Version Number
Type
3 bits
1 bit
Secondary Header Flag 1 bit 2 bytes Field
Packet Version Number Packet Type Secondary Header Flag
ApID
Sequence Flags
Sequence Count
Packet Length
11 bits
2 bits
14 bits
16 bits 2 bytes
2 bytes Length (bits) 3 1 1
Application Process Identifier Sequence Flags Sequence Count
11 2 14
Packet Length
16
Value
Comments
0b001 CII Packet Version 1 0b CII SpaceWire-CCSDS packet 0b1 Indicates the CII-CCSDS secondary header is present 0–2048 Reserved for instrument use 0b11 Indicates packet is unsegmented 0–16383 Specifies the packet sequence count. The packet count begins at zero and resumes at zero after 16384 packets have been sent. 0–236 Specifies the length of the packet data field in bytes. 28
5.3.2.11 CII CCSDS Headers (3/3) Primary Header
CCSDS Packet Data Secondary Header (Time)
6 bytes
9 bytes
Data 0–236 bytes (TBR)
CCSDS Secondary Header CCSDS Unsegmented Time Code (CUC) Field P-Field T-Field Default Extended Coarse Time Fine Time 1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
Contains elapsed time (ET) in coarse (seconds) and fine (subsecond) units since the default CCSDS epoch of January 1, 1958 Example:
From 1/1/58 to 2/7/11 is 1,675,728,000s
Coarse: 0x63 0xE1 0x94 0x80
125ms clock tick is 224 ÷ 8 = 2,097,152 sub-s
Fine:
0x02 0x00 0x00
SpaceWire 6-bit time code embedded in the CUC Extended time P-Field1 1Defined in the SpaceWire
– CCSDS Unsegmented Code Transfer Protocol (proposed)
29
5.3.3 CII Spacecraft Status Message
Spacecraft time is contained in CCSDS Secondary Header 80 bytes of data: 4-element, double-precision, non-dimensional quaternion 3-element, double-precision, position vector (X) 3-element, double-precision, inertial velocity vector (V)
Follows STP–SIV ephemeris message format 30
5.3.4 CII Instrument Command
31
5.3.5 CII Command Acknowledgement
• Instrument Mode field: – First two bits denote the instrument major mode: INITIALIZATION (0b00), OPERATION (0b01), or SAFE (0b10) – Remaining bits may be used at the instrument’s discretion
• Command Source, Command ID, and CCSDS Primary Header Sequence Count fields are echoed from the command packet being acknowledged 32
5.3.6 CII Instrument Telemetry
• Instrument Mode field: – First two bits denote the instrument major mode: INITIALIZATION (0b00), OPERATION (0b01), or SAFE (0b10) – Remaining bits may be used at the instrument’s discretion • 58 telemetry values per packet / telemetry bank • To facilitate spacecraft monitoring, each instrument telemetry value should be encoded as either: – a standard two’s complement 32‐bit signed integer, – a 32‐bit unsigned integer, or – a IEEE‐754 floating‐point values 33
5.3.7 CII Instrument Science Data
• All science data is opaque to the spacecraft. • The instrument should be responsible for its own: – science data compression, – onboard storage, and – playback
• Data playback should be coordinated with the spacecraft operations team. 34
