space plug-and-play architecture standard logical interface

BSR/ AIAA S-133-3-201X

Space Plug-and-Play Architecture Standard

Logical Interface

DRAFT August 2011

Sponsored by

American Institute of Aeronautics and Astronautics

Approved XX Month 200X

Abstract

The logical interface of SPA is the boundary through which components participate in a SPA system. This document describes the messages that pass across the SPA interface, the circumstances under which those messages flow, and the protocols for sequencing those messages.

This document does not attempt to describe how the messages are transported from one component to the other. This document and its messages are agnostic to message routing, message delivery, or the network topology.

Furthermore, this document does not attempt to describe the details on how these messages are implemented for a mission. The use of these messages can seem vague without a complete implementation or mission-specific example. The SPA Guidebook gives examples and principles on how these messages are used to achieve the capabilities of a fully functional plug-and-play architecture.

BSR/AIAA S-133-3-201X

ii

Published by American Institute of Aeronautics and Astronautics 1801 Alexander Bell Drive, Reston, VA 20191

Copyright © 201X American Institute of Aeronautics and Astronautics All rights reserved No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America


iii

Contents

Figures ......................................................................................................................................................................... iv

Tables ......................................................................................................................................................................... iv

Foreword ....................................................................................................................................................................... vi

Introduction .................................................................................................................................................................. viii

1 Scope............................................................................................................................................................... 1

2 Tailoring ........................................................................................................................................................... 1

3 Applicable Documents ..................................................................................................................................... 1

4 Vocabulary ....................................................................................................................................................... 2

4.1 Acronyms and Abbreviated Terms ................................................................................................................... 2

4.2 Terms and Definitions ...................................................................................................................................... 2

5 SPA Interface ................................................................................................................................................... 3

5.1 SPA Header ..................................................................................................................................................... 3

5.1.1 Standard SPA Header ..................................................................................................................................... 3

5.1.2 Extended SPA Header ..................................................................................................................................... 5

5.1.3 Guaranteed Delivery Extended Header ........................................................................................................... 7

5.1.4 Message Sequencing Extended Header.......................................................................................................... 8

5.1.5 Quality of Service Header ................................................................................................................................ 9

5.1.6 Security Header ............................................................................................................................................... 9

5.1.7 SPA Message Footer ....................................................................................................................................... 9

5.2 Component Data Capabilities ........................................................................................................................ 10

5.2.1 Discovery ....................................................................................................................................................... 10

5.2.2 Registration .................................................................................................................................................... 14

5.2.3 Querying for Data .......................................................................................................................................... 19

5.2.4 Subscriptions to Data ..................................................................................................................................... 28

5.2.5 Intercomponent Data Exchange .................................................................................................................... 37

5.3 Component Network Capabilities ................................................................................................................... 45

5.3.2 SPA Request SPA Lookup Service Probe Message ..................................................................................... 47

5.3.3 SPA Network Status Request Message......................................................................................................... 47

5.3.4 SPA Network Status Reply Message ............................................................................................................. 48

5.3.5 Health and Status .......................................................................................................................................... 51

5.3.6 Time Synchronization .................................................................................................................................... 51

5.3.7 Quality of Service ........................................................................................................................................... 53

5.3.8 Security .......................................................................................................................................................... 59

5.4 Component Identification ............................................................................................................................... 59

5.4.1 Universally Unique Identification .................................................................................................................... 60


iv

5.4.2 xTEDS Identification ...................................................................................................................................... 60

Figures

Figure 1 – SPA probe request sequence diagram .............................................................................................. 12

Figure 2 – SPA xTEDS request sequence diagram ............................................................................................ 15

Figure 3 – SPA registration info request sequence diagram ................................................................................ 19

Figure 4 – SPA subscription request sequence diagram 1 .................................................................................. 29




Figure 8 – SPA data request sequence diagram ................................................................................................ 37

Figure 9 – SPA command sequence diagram ................................................................................................... 39

Figure 10 – SPA service reply sequence diagram .............................................................................................. 41

Figure 11 – Notification of components to SPA lookup service sequencing diagram .............................................. 46

Figure 12 – Error reporting sequencing diagram ................................................................................................ 46

Figure 13 – Guaranteed delivery request sequence diagram .............................................................................. 54

Figure 14 – Guaranteed delivery acknowledge sequence diagram ...................................................................... 55

Figure 15 – Guaranteed delivery message resend upon failure sequence diagram ............................................... 56

Figure 16 – Guaranteed delivery acknowledgement resend upon failure sequence diagram .................................. 56

Figure 17 – Restart of failed receiver sequence diagram .................................................................................... 57

Tables

Table 1 – SPA standard message header ........................................................................................................... 3

Table 2 – SPA extended message header .......................................................................................................... 6

Table 3 – SPA guaranteed delivery extended header .......................................................................................... 7

Table 4 – SPA message sequencing .................................................................................................................. 8

Table 5 – SPA footer ...................................................................................................................................... 10

Table 6 – SPA probe request message ............................................................................................................ 11

Table 7 – SPA probe reply .............................................................................................................................. 12

Table 8 – SPA xTEDS request ........................................................................................................................ 15

Table 9 – SPA xTEDS reply ............................................................................................................................ 17

Table 10 – SPA registration info request message ............................................................................................ 20

Table 11 – SPA registration info reply .............................................................................................................. 22

Table 12 – SPA variable info request ............................................................................................................... 25

Table 13 – SPA variable info request ............................................................................................................... 27

Table 14 – SPA subscription request ................................................................................................................ 32

Table 15 – SPA subscription reply ................................................................................................................... 36


v

Table 16 – SPA data message ........................................................................................................................ 38

Table 17 – SPA data request message ............................................................................................................ 40

Table 18 – SPA service request ....................................................................................................................... 42

Table 19 – SPA service reply message ............................................................................................................ 43

Table 20 – SPA request SPA lookup service probe message format ................................................................... 47

Table 21 – SPA network status request message format .................................................................................... 47

Table 22 – SPA network status reply message format ....................................................................................... 49

Table 23 – SPA time-at-tone message format ................................................................................................... 52

Table 24 – SPA guaranteed delivery extended header message format .............................................................. 58

Table 25 – SPA transport message format ........................................................................................................ 59


vi

Foreword

This document was developed by the Space Plug-and-Play Architecture (SPA) Standards Working Group as one of a series describing the various components of the standard. The SPA standards were recorded in earlier documentation. This document set separates content along logical boundaries to better organize the volumes (so that developers or domain experts need only reference the documents applicable to their needs) and to avoid duplication of content between documents in the standard series. This 201X AIAA standard supersedes all previous documentation of the SPA standards.

This particular volume of the SPA Logical Interface Standard contains information not recorded in previous documentation. It is part of a set of 10 volumes describing other components of the standard:

• SPA Guidebook

• SPA Networking Standard

• SPA Physical Interface Standard Ontology Standard

• SPA 28V Power Service Standard

• SPA System Timing Standard

• SPA Ontology Standard

• SPA Test Bypass Extension Standard

• SPA SpaceWire (SPA-S) Subnet Adaptation Standard

• SPA System Capability Standard

At the time of approval, the members of the AIAA SPA Standards Committee were: Fred Slane, Chair Space Infrastructure Foundation

Jeanette Arrigo Sierra Nevada Corporation

Scott Cannon Utah State University

Ken Center PnP Innovations

Don Fronterhouse* PnP Innovations

Rod Green Design Group

Jane Hansen HRP Systems

Doug Harris Operationally Responsive Space Office

Paul Jaffe Naval Research Laboratory

Stanley Kennedy* Comtech Aero-Astro

Ronald Kohl R.J. Kohl & Associates

Bill Kramer Independent

Ramon Krosley Independent

Denise Lanza SAIC

James Lyke Air Force Research Laboratory


vii

Joseph Marshall BAE Systems

Gerald Murphy* Design Group

Gary Rodriguez sysRand

Steven Schenk Comtech Aero-Astro

Robert Vick* SAIC

The above consensus body approved this document in Month 201X.

The AIAA Standards Executive Council (VP-Standards Name, Chairman) accepted the document for publication in Month 201X.

The AIAA Standards Procedures dictates that all approved Standards, Recommended Practices, and Guides are advisory only. Their use by anyone engaged in industry or trade is entirely voluntary. There is no agreement to adhere to any AIAA standards publication and no commitment to conform to or be guided by standards reports. In formulating, revising, and approving standards publications, the committees on standards will not consider patents that may apply to the subject matter. Prospective users of the publications are responsible for protecting themselves against liability for infringement of patents or copyright or both.

__________ *Alternate CoS participant.


viii

Introduction SPA embraces and implements a collection of standards designed to facilitate rapid construction of spacecraft systems using modular components. The SPA Logical Interface Specification describes the messages, protocols, and interactions a standard SPA component will use to participate in the network. The message definition defines the exact format of the entire message and its fields, and describes how the fields are used.


1

1 Scope The SPA logical interface is the conceptual boundary through which components are able to participate in a SPA system. Unlike a physical interface which defines connectors, pin-outs, and signaling levels, the logical interface consists primarily of messages. This document describes the messages that are passed through a SPA system, the circumstances under which those messages flow, and the protocols for sequencing those messages.

This document does not attempt to describe how the messages are transported from one component to the other. This document and its messages are agnostic to the message routing, message delivery, or topology of the physical layer of the network. These details are documented in the SPA Networking Standard and its associated documents.

Furthermore, this document does not attempt to describe the details on how these messages are implemented for a mission. The use of these messages can seem vague without a complete implementation or mission-specific example. The SPA Guidebook gives examples and principles on how these messages are used to achieve the capabilities of fully functional plug and play architecture.

2 Tailoring When viewed from the perspective of a specific program or project context, the requirements defined in this standard may be tailored to match the actual requirements of the particular program or project. Tailoring of requirements shall be undertaken in consultation with the procuring authority where applicable.

NOTE Tailoring is a process by which individual requirements or specifications, standards, and related documents are evaluated and made applicable to a specific program or project by selection, and in some exceptional cases, modification and addition of requirements in the standards.

3 Applicable Documents The following documents contain provisions which, through reference in this text, constitute provisions of this standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.

AIAA S-133-2-201X SPA Networking Standard

AIAA S-133-7-201X SPA Ontology Standard

RFC 4122 A Universally Unique Identifier (UUID) Uniform Resource Name (URN) Namespace (http://www.ietf.org/rfc/rfc4122.txt)

http://www.ietf.org/rfc/rfc4122.txt�


2

4 Vocabulary

4.1 Acronyms and Abbreviated Terms

AIAA

CAS

CUUID

ICD

IETF

RFC

American Institute of Aeronautics and Astronautics

Central Addressing Service

Component Universally Unique Identifier

Interface Control Document

Internet Engineering Task Force

Request For Comments

SM-x

SPA

URN

UUID

SPA Subnet Manger, where x represents a given technology protocol

Space Plug-and-Play Architecture

Uniform Resource Name

Universally Unique Identifier

xTEDS

XUUID

Extensible Transducer Electronic Data Sheet

xTEDS Universally Unique Identifier

4.2 Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

Central Addressing Service responsible for providing logical address blocks to be assigned to each hardware or software component registered with the system during component registration. It stores the logical address block, UUID, and physical address for each core component.

Component an endpoint whose interface conforms to the SPA Interface standard and does not connect to another SPA object via a different port. Note that a SPA hardware component is indistinguishable from a SPA software component for the purposes of this document.

Plug and play ability to connect a device to the larger system and have the two work together with little or no set-up required (e.g., automated system recognition and data exchange)

Router a device with multiple ports that may be attached to another SPA router, a SPA manager, gateway, or SPA component endpoint

SPA lookup service responsible for accepting component registration and providing data source route information for components requesting a particular type of service (or returning a negative acknowledgment if the service is not available)

3

SPA manager responsible for performing discovery for a particular subnet. It maps incoming packets to the correct SPA endpoint on the subnet, encapsulating the SPA packet with the correct protocol header. In the reverse direction it removes the protocol header and possibly adds a new header conforming to the subnet the packet is about to enter. It is also responsible for topology discovery and reporting within the subnet.

5 SPA Interface This section describes the SPA logical interface in four parts. The SPA Header (Section 5.1) defines those attributes that are common to all messages. Component Data Capabilities (Section 5.2) describes messages at the application layer and Component Network Capabilities (Section 5.3) describes messages at the transport layer. Finally, Component Identification (Section 5.4) outlines how every SPA component carries a unique identificiation used to facilitate the addressing of messages.

5.1 SPA Header

5.1.1 Standard SPA Header

All SPA messages shall have a standard header that contains information pertinent to and in common with all SPA messages.

The format for the SPA header is described below in Table 1.

Table 1 – SPA standard message header

Message Name SPA Standard Header Message Opcode SPA Version 1 (Note: “1” indicates the initial version) Summary Description standard header description

Field Name Size Offset Value Description

Version 1 0 1 SPA logical interface version number Priority 1 1 n/a Message priority Length 2 2 n/a Length of the payload of the message Destination 4 4 n/a Destination logical address Source 4 8 n/a Source logical address Flags 2 12 0 Special message flags Opcode 1 14 n/a Unique opcode of the message Ext. Header Length

1 15 0 Length of the extended headers in the message

Name Version Description SPA logical interface version number Full Description The version field is defined by the SPA standard for the evolution of the message format Size 1 Offset 0 DataType uint8 Units n/a DefaultValue 1 Range 0-255


4

Name Priority Description Message priority

Full Description Message priority is set by the originator of the message and can be used by the network to implement special handling. Lower priority value, indicates higher priority.

Size 1 Offset 1 DataType uint8 Units n/a DefaultValue n/a Range 0-255. 0 = highest priority, 255 = lowest priority

Name Length Description Length of the payload of the message Full Description The length in bytes of the message after the header and extended headers Size 2 Offset 2 DataType uint16 Units bytes DefaultValue n/a Range 1-1400

Name Destination

Description Destination logical address Full Description The SPA logical address that the message should be delivered to Size 4 Offset 4 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name Source Description Source logical address Full Description The SPA logical address that the message originated from Size 4 Offset 8 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name Flags Description Special message flags

Full Description This bitfield is used to describe extended features of the message. It also indicates the precense of some extended headers.

Size 2

5

Offset 12 DataType uint8 Units n/a DefaultValue 0

Range Bit 0: 1=unknown or invalid source address, 0=source address is valid Bit 1: 1=Qos Present, 0=Qos not Present bit 2-7: reserved

Name Opcode

Description Unique opcode of the message Full Description The opcode is a hardcoded unique identifier for every type of message Size 1 Offset 14 DataType uint8 Units n/a DefaultValue n/a Range 0-255

Name Ext. Header Length Description Length of the extended headers in the message Full Description The length in 32bit words of the extended headers Size 1 Offset 15 DataType uint8 Units 32bit words DefaultValue 0 Range 0-255

5.1.2 Extended SPA Header

Extended SPA headers are used to facilitate SPA message functionality that may not be required for every SPA message or may not have been fully defined when the standard SPA header was first conceived. For example, there may be an extended SPA header for guaranteed message delivery, quality of service, security, and so forth.

If at least one extended SPA header is used, then the “Extended Header Length” field in the standard SPA header shall be set to the total length of the extended header in 4-byte words. Each extended header shall be a minimum of 4 bytes. The “Flags” field in the standard SPA header shall indicate the presence of key extended headers.

The format for the SPA extended message header is described below in Table 2.


6

Table 2 – SPA extended message header

Message Name SPA Extended Header Message Opcode SPA Version 1 (Note: “1” indicates the initial version) Summary Description extended header description

Field Name Size Offset Value Description Extended Header Id 1 0 1 Enumerated id of the extended header

Extended Header Size 1 1 2 Number of data bytes in the extended header

Extended Header Data

2 - 254 2 n/a Extended header data

Name Extended Header Id Description Enumerated id of the extended header Full Description Unique numeric identifier of the extended header Size 1 Offset 0 DataType uint8 Units n/a DefaultValue 1 Range 0-255

Name Extended Header Size Description Number of data bytes in the extended header

Full Description The number of data bytes in the extended header. The extended header must be aligned on a 4 byte boundary so the minimum extended header data size is 2 bytes.

Size 1 Offset 1 DataType uint8 Units n/a DefaultValue 2 Range 2-254. 2 = minimum value, 254 = maximum value

Name Extended Header Data Description Extended header data

Full Description Extended header data. The extended header must be aligned on a 4 byte boundary so there must be at least 2 data bytes

Size 2 - 254 Offset 2 DataType uint16 Units bytes DefaultValue n/a Range n/a

7

5.1.3 Guaranteed Delivery Extended Header

The format for the SPA Guaranteed Delivery Extended Header is described below in Table 3.

Table 3 – SPA guaranteed delivery extended header

Message Name SPA Guaranteed Delivery Extended Header Message Opcode SPA Version 1 (Note: “1” indicates the initial version) Summary Description guaranteed delivery extended header description

Field Name Size Offset Value Description Header Id 1 0 1 Guaranteed delivery extended header Id Header Size 1 1 2 Guaranteed delivery extended header Size Flags 2 2 n/a Guaranteed delivery flags Sequence 2 4 n/a Guaranteed delivery sequence reserved 2 6 n/a reserved

Name Header Id Description Guaranteed delivery extended header Id Full Description Unique numeric identifier of the guaranteed delivery extended header Size 1 Offset 0 DataType uint8 Units n/a DefaultValue 1 Range 1. 1 = guaranteed delivery

Name Header Size Description Guaranteed delivery extended header Size Full Description The number of data bytes in the guaranteed delivery extended header Size 1 Offset 1 DataType uint8 Units n/a DefaultValue 2 Range 2. 2 = guaranteed delivery data size in 4 byte words

Name Flags Description Guaranteed delivery flags. Full Description Guaranteed delivery extended header flags Size 2 Offset 2 DataType uint16 Units n/a DefaultValue n/a Range n/a


8

Name Sequence Description Guaranteed delivery sequence Full Description Guaranteed delivery extended header sequence Size 2 Offset 4 DataType uint16 Units n/a DefaultValue n/a Range n/a

Name Reserved Description reserved Full Description reserved Size 2 Offset 6 DataType uint16 Units n/a DefaultValue n/a Range n/a

5.1.4 Message Sequencing Extended Header

The maximum SPA message cargo size shall be no greater than 1400 bytes. SPA message cargo larger than the allowed 1400 bytes shall be packetized at the SPA messaging level to be sent across the network. The Message Sequencing extended header shall provide a sequence ID and sequence count to allow cargo to be packetized.

The format for the SPA message sequencing header is described below in Table 4.

Table 4 – SPA message sequencing

Message Name SPA Message Sequencing Extended Header Message Opcode SPA Version 1 (Note: “1” indicates the initial version) Summary Description message sequencing extended header description

Field Name Size Offset Value Description Header Id 1 0 2 Message sequencing extended header Id Header Size 1 1 1 Message sequencing extended header Size sequence ID 1 2 n/a Message sequencing ID Sequence Count 1 3 n/a Message sequencing count

Name Header Id Description Message sequencing extended header Id Full Description Unique numeric identifier of the message sequencing extended header Size 1 Offset 0 DataType uint8

9

Units n/a DefaultValue 2 Range 2. 2 = message sequencing

Name Header Size

Description Message sequencing extended header Size Full Description The number of data bytes in the message sequencing extended header Size 1 Offset 1 DataType uint8 Units n/a DefaultValue 1 Range 1. 1 = guaranteed delivery data size in 4 byte words

Name Sequence ID Description Message sequencing ID Full Description Message sequencing extended header identifier Size 1 Offset 2 DataType uint8 Units n/a DefaultValue n/a Range 0-255

Name Sequence Count Description Message sequencing count Full Description Message sequencing extended header count Size 1 Offset 3 DataType uint8 Units n/a DefaultValue n/a Range 0-255

5.1.5 Quality of Service Header

The Quality of Service Header is not included in this current revision of the standard.

5.1.6 Security Header

The Security Header is not included in this current revision of the standard.

5.1.7 SPA Message Footer

All SPA messages shall include a standard footer consisting of a 16 bit checksum. The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the SPA headers and message payload. If a message payload contains an odd number of octets, the last octet shall be padded on the right with zeros to form a 16 bit word for checksum purposes. The pad shall not be


10

transmitted as part of the message payload. The checksum in the SPA Standard Footer shall not be included in the calculation of the checksum of a SPA message.

The SPA Footer message format is described below in Table 5.

Table 5 – SPA footer

Message Name SPA Standard Footer Message Opcode SPA Version 1 (Note: “1” indicates the initial version) Summary Description standard footer description

Field Name Size Offset Value Description Checksum 2 0 0 16 bit checksum

Name Checksum Description 16 bit checksum Full Description 16 bit checksum of the SPA Message content Size 2 Offset 0 DataType uint16 Units n/a DefaultValue 0 Range 0-65535

5.2 Component Data Capabilities

This section describes the messages and protocols that support the application layer of SPA architecture. SPA components interact with each other through these messages.

5.2.1 Discovery

The discovery process comprises the sensing and identification of individual components in the SPA network. This occurs after completion of the network topology discovery as described in Section 5.3.1. Upon completion of network topology discovery, the SPA Lookup Service shall probe the newly discovered component to complete the component registration process. A SPAProbeRequest message shall be sent to the logical address of the registering component, prompting the component to return a SPAProbeReply message. The SPAProbeReply contains the Component Universally Unique ID (CUUID) and xTEDS Universally Unique ID (XUUID) for the registering component. Receipt of these two identifiers at the SPA Lookup Service completes the discovery process. The SPA Lookup Service is a SPA application that maintains a catalog of data and services available on a spacecraft.

5.2.1.1 SPA Probe Request Message

This message is sent by a component (typically a high-level manager) to another component to request identification information. It is also used to monitor network health and status. The user can request multiple SPAProbeReply messages to verify that the component is still alive. The first SPAProbeReply message shall occur immediatly, and future ones shall be sent at the specified rate. If a component no longer wishes to receive future SPAProbeReply messages, then it shall send a SPAProbeRequest message with a count of 1.

The SPA Probe Request message format is described below in Table 6 and the SPA Probe Request Sequence Diagram is shown in Figure 1.

11

Table 6 – SPA probe request message

Message Name SPAProbeRequest Message Opcode 120 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Probe a SPA component for identification

Field Name Size Offset Value Description

DialogIdentifier 2 0 n/a Dialog identifier set by the requester ReplyCount 2 4 n/a Number of SPAProbeReply messages ReplyPeriod 2 6 n/a Period between SPAProbeReply messages

Name DialogIdentifier Description Dialog identifier set by the requester

Full Description Value used to pair SPAProbeRequest messages with corresponding SPAProbeReply messages. This field does not need to be the same as previous sequences when requesting new reply count or rate.

Size 2 Offset 0 DataType uint16 Units n/a DefaultValue n/a Range n/a

Name ReplyCount Description Number of SPAProbeReply messages

Full Description The requested number of future SPAProbeReply messages to be sent in response to this request. 0 for infinite.

Size 2 Offset 4 DataType uint16 Units count DefaultValue n/a Range n/a

Name ReplyPeriod

Description Period between SPAProbeReply messages

Full Description The period between multiple SPAProbeReply messages. Bandwidth and component limitations might limit the lower bounds on this number.

Size 2 Offset 6 DataType uint16 Units milliseconds DefaultValue n/a Range n/a


12

5.2.1.2 SPA Probe Request Sequence Diagram

1. The SPA Lookup Service is notified that a new member of the network is present. It sends a probe message to the new component to request data capabilities information from the new component.

2. The registering component receives the probe request and sends a probe reply message containing the requisite information.

Figure 1 – SPA probe request sequence diagram

5.2.1.3 SPA Probe Reply Message

The SPA Probe Reply message format is described below in Table 7.

Table 7– SPA probe reply

Message Name SPAProbeReply Message Opcode 121 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Probe response for a SPA component

Field Name Size Offset Value Description DialogIdentifier 2 0 n/a Dialog identifier set by the requester Uptime 4 4 n/a Seconds since power on CUUID 16 8 n/a Universally Unique Id of the SPA component XUUID 16 24 n/a Universally Unique Id of the xTEDS FaultIndicator 4 40 n/a Indicates presense of fault OperatingMode 1 44 n/a Enumeration of operating mode


Full Description Value used to pair SPAProbeRequest messages with corresponding SPAProbeReply messages

Size 2 Offset 0 DataType uint16

13

Units n/a DefaultValue n/a Range n/a

Name Uptime Description Seconds since power on

Full Description The number of seconds the component has been active on the SPA network. 0 if not implemented.

Size 4 Offset 4 DataType uint32 Units Seconds DefaultValue n/a Range n/a

Name CUUID Description Universally Unique Id of the SPA component

Full Description Universally Unique Id of the SPA component described in section 5.4.2 of the standard


Name XUUID Description Universally Unique Id of the xTEDS Full Description Value is the Universally Unique ID for the xTEDS of the sending component Size 16 Offset 24 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name FaultIndicator Description Indicates presense of fault.

Full Description A component can set this field to indicate the presense of a fault at any level of the component. The indicator will clear itself upon removal of the fault condition.

Size 4 Offset 40 DataType uint32 Units n/a DefaultValue n/a Range 0=no fault, else fault condition exists

Name OperatingMode


14

Description Enumeration of operating mode Full Description Enumeration of operating mode Size 1 Offset 44 DataType uint8 Units enumeration DefaultValue n/a

Range

Name Description Value

SPA_OPMODE_INITIALIZING component is still initializing 0

SPA_OPMODE_FULLY_OPERATIONAL no known problems exist in the component 5

SPA_OPMODE_DEPENDENCY_FAILURE unresolved, lost dependency 7

SPA_OPMODE_LINK_ANOMALY an error occurred on data link 11

SPA_OPMODE_PACKET_ANOMALY error in packet 13 SPA_OPMODE_DELIVERY_ANOMALY error sending packet 15

SPA_OPMODE_TEMPERATURE_ANOMALY temperature is outside safe range 21

SPA_OPMODE_VOLTAGE_ANOMALY voltage is outside safe range 23

SPA_OPMODE_CURRENT_ANOMALY current is outside safe range 27

SPA_OPMODE_PRESSURE_ANOMALY pressure is outside safe range 29

SPA_OPMODE_TIME_DISTRIBUTION_ANOMALY incorrect or missing time distribution 31

SPA_OPMODE_INTERNAL_SELFTEST_ANOMALY failed internal selftest 37 SPA_OPMODE_APPLICATION_LEVEL_ANOMALY application failed 39

SPA_OPMODE_USER_DEFINED_ANOMALY measurement is outside user specification

41

5.2.2 Registration

Component registration occurs after a component has completed network topology discovery and data discovery. Upon completion of data discovery (Section 5.2.1) the SPA Lookup Service shall use the xTEDS ID to complete the registration process. The SPA Lookup Service shall attempt to retrieve a cached xTEDS via the SPAxTEDSRequest message if possible and update the component registration table. If the SPA Lookup Service is unable to resolve the xTEDS ID, then it can query the component again to obtain the xTEDS. Upon receipt of the SPAxTEDSReply message, the SPA Lookup Service shall complete the component registration process and optionally cache the xTEDS to simplify future registrations of the same component.

15

5.2.2.1 SPA xTEDS Request Message

The SPA xTEDS Request message is sent by a component to any other component or the SPA Lookup Service in order to request an xTEDS. The Lookup Service shall search registered xTEDS for matching xTEDS. If there are no matches, the Lookup Service shall send one terminating SPAxTEDSReply message; otherwise, the Lookup Service shall send a SPAxTEDSReply message for each match and one terminating SPAxTEDSReply message. The SPA xTEDS Request Sequence Diagram is shown in Figure 2.

5.2.2.2 SPA xTEDS Request Sequence Diagram

Figure 2 – SPA xTEDS request sequence diagram

1. The device or application sends a SPAxTEDSRequest message to the component with the RequestType set to either device address or device name.

2. If there are no matches, the Lookup Service sends one terminating SPAxTEDSReply message; otherwise, the Lookup Service sends a SPAxTEDSReply message for each match and one terminating SPAxTEDSReply message.

The format for the SPA xTEDS Request message is shown below in Table 8.

Table 8 – SPA xTEDS request

Message Name SPAxTEDSRequest Message Opcode 66 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Request xTEDS of a component

Field Name Size Offset Value Description DialogIdentifier 0 2 n/a Dialog identifier set by the requester RequestType 2 2 n/a Identifier of field that identifies the component DeviceAddress 4 4 n/a Address of a device CUUID 16 8 n/a Universally Unique Id of the SPA component DeviceName n 24 n/a Name of a device


Full Description Value used to pair SPAxTEDSRequest messages with corresponding SPAxTEDSReply messages

Size 0 Offset 2


16

DataType uint16 Units n/a DefaultValue n/a Range n/a

Name RequestType Description Identifier of field that identifies the component

Full Description The identifier of the field in this message that identifies the component whose xTEDS is wanted

Size 2 Offset 2 DataType uint16 Units n/a DefaultValue n/a

Range


SPA_xTEDS_REQUEST_DEVICE_ADDRESS Request based upon the DeviceAddress field 0

SPA_xTEDS_REQUEST_DEVICENAME Request based upon the DeviceName 1

SPA_xTEDS_REQUEST_DEVICE_CUUID Request based upon the SPA Component ID 2

Name DeviceAddress Description Address of a device Full Description Address of a device to request the xTEDS Size 4 Offset 4 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name CUUID Description Universally Unique Id of the SPA component Full Description Universally Unique Id of the SPA component to request the xTEDS Size 16 Offset 8 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name DeviceName Description Name of a device Full Description Name of a device to request the xTEDS Size n Offset 24

17

DataType uint8 Units n/a DefaultValue n/a Range n/a 5.2.2.3 SPA xTEDS Reply Message

This message is sent by any component or by the SPA Lookup Service to a component in response to a SPAReqxTEDS message. The Lookup Service shall search registered xTEDS for matching xTEDS. If there are no matches, then the Lookup Service shall send one terminating SPAxTEDSReply message; otherwise, the Lookup Service shall send a SPAxTEDSReply message for each match and one terminating SPAxTEDSReply message.

5.2.2.4 SPA xTEDS Reply Sequence Diagram

The SPA xTEDS Reply Message format is shown below in Table 9.

Table 9 – SPA xTEDS reply

Message Name SPAxTEDSReply Message Opcode 66 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Response to an xTEDS request of a component

Field Name Size Offset Value Description DialogIdentifier 2 0 n/a Dialog identifier set by the requester ReplyStatus 2 2 n/a Status code of the message DeviceAddress 4 4 n/a Address of the device xTEDS n 8 n/a xTEDS of the requested device


Full Description Value used to pair SPAxTEDSRequest messages with corresponding SPAxTEDSReply messages


Name ReplyStatus Description Status code of the message Full Description Status code indicating the reply type to the request message Size 2 Offset 2 DataType uint16 Units n/a DefaultValue n/a


18

Range


REPLY_VALID Request was valid, and the xTEDS field is valid 0

xTEDS_CANCEL The previously transmited xTEDS is going offline or is no longer valid 1

ADDRESS_NOT_FOUND

When sending the message to a registration service, this response indicates the address has not been registered

2

ADDRESS_INVALID

When sending the message directly to a component, this response indicates that the request address does not match the component

3

CUUID_NOT_FOUND

When sending the message to a registration service, this response indicates the CUUID has not been registered

4

CUUID_INVALID

When sending the message directly to a component, this response indicates that the request CUUID does not match the component

5

DEVICENAME_NOT_FOUND

When sending the message to a registration service, this response indicates the devicename has not been registered

6

DEVICENAME_INVALID

When sending the message directly to a component, this response indicates that the request devicename does not match the component

7

Name DeviceAddress Description Address of the device Full Description Address of the device that this xTEDS applies to Size 4 Offset 4 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name xTEDS Description xTEDS of the requested device Full Description xTEDS of the requested device Size n Offset 8 DataType uint8 Units n/a DefaultValue n/a Range n/a

19

5.2.3 Querying for Data

This message family (messages that support the application layer of SPA) supports the ability for a SPA component to query for desired data, command providers, and service providers. The responses indicate matching providers. SPA provides three key query capabilities. The first is the ability to query for an item based on its name or qualifiers. Second is the ability to request metadata on a specific variable. The third is the ability to retrieve an entire xTEDS, which is described in Section 5.2.2.

5.2.3.1 SPA Registration Info Request Message

The SPA Regristration Info Request message is sent by a component to the SPA Lookup Service in order to request information about currently registered providers (see Figure 3).

Writers of applications should be aware that less specific queries can return more information. For example, a query that specifies only a particular kind of device will return responses for all messages of all such devices on board. Similarly, a query that makes no specifications (all specifications are optional) will return responses for all messages in the spacecraft. Sometimes such a prolific response is useful; for example, a telemetry application may query for all messages with a qualifier that indicates housekeeping data. If multiple Lookup Service’s are present on a spacecraft, they may exchange catalogs by issuing more or less specific queries to each other. When multiple specifications are present in a query, they combine conjunctively, so the result is the intersection of the results that would be returned if each specification were present individually.

5.2.3.2 SPA Registration Info Request Sequence Diagram

Figure 3 – SPA registration info request sequence diagram

1. The device or application shall send a SPARegistrationInfoRequest message to the Lookup Service with the reply type field set to current, current/future, or current/future/cancel.

2. If there are no matches, then the Lookup Service shall send one terminating SPARegistrationInfoReply message; otherwise, the Lookup Service shall send a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message.


20

3. If the reply type field in the original SPARegistrationInfoRequest message was set to current/future and in the future if a match becomes available, then the SPA Lookup Service shall send a SPARegistrationInfoReply message for the match and one terminating SPARegistrationInfoReply message. If the reply type field in the original SPARegistrationInfoRequest was set to current/future/cancel and a match becomes unavailable, then the Lookup Service shall send a SPARegistrationInfoReply message indicating that the match is no longer available.

4. To cancel a subscription generated by a previous SPARegistrationInfoRequest message the device or application shall send a SPARegistrationInfoRequest message identical to the original SPARegistrationInfoRequest message but with the reply type field set to cancel. The format for the SPA Registration Info Request message is shown below in Table 10.

Table 10 – SPA registration info request message

Message Name SPARegistrationInfoRequest Message Opcode n SPA Version 1 (Note: “1” indicates the initial version) Summary Description Request information about currently registered providers

Field Name Size Offset Value Description Source 4 0 n/a Source address of provider Reply 1 4 n/a Enumeration of request type DialogIdentifier 2 5 n/a Dialog identifier set by the requester Device n1 7 n/a Name of device to search (optional) Interface n2 7 + n1 n/a Name of interface to search (optional) ItemName n3 7 + n1 + n2 n/a Name of an item to search for (optional) QualiferList n3 7 + n1 + n2 + n3 n/a List of qualifiers to search for (optional)

Name Source Description Source address of provider Full Description Source address of provider (Optional; 0 if not used) Size 4 Offset 0 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name Reply Description Enumeration of request type Full Description Enumeration of request type Size 1 Offset 4 DataType uint8 Units enumeration DefaultValue n/a

Range Name Description Value SPA_REQREG_CURRENT Request 0

21

current matches only

SPA_REQREG_CURRENT_AND_FUTURE

Request current and future matches

5

SPA_REQREG_CURRENT_FUTURE_AND_CANCELLATIONS

Request current and future matches, plus cancellations

7

SPA_REQREG_CANCEL Cancel previous request

11


Full Description Value used to pair SPARegistrationInfoRequest messages with corresponding SPARegistrationInfoReply messages


Name Device Description Name of device to seek Full Description Name of a device or application for which an xTEDS is requested (optional) Size n1 Offset 7 DataType uint8 Units n/a DefaultValue n/a Range n/a

Name Interface Description Name of interface to seek Full Description Name of the interface in which the variable information resides (optional) Size n2 Offset 7 + n1 DataType uint8 Units n/a DefaultValue n/a Range n/a

Name ItemName Description Name of an item to search for


22

Full Description Name of an item to seek, which may be a regular expression. This field will search interface, variable, and message names (optional). A variable name shall have the form “<message name>.<variable name>”.

Size n3 Offset 7 + n1 + n2 DataType uint8 Units n/a DefaultValue n/a Range n/a

Name QualiferList Description List of qualifiers to search for (optional)

Full Description

List of qualifiers to search for (optional). The attributes of variables, messages, interfaces, devices, and applications shall be treated as qualifiers, such that the name of the attribute corresponds to the name of the qualifier, and the value of the attribute corresponds to the value of the qualifier. The format of this list shall be a sequence of items separated by commas. Each item shall be a pair in the form “(<qualifier name>,<qualifier value regular expression>)”.

Size n3 Offset 7 + n1 + n2 + n3 DataType uint8 Units n/a DefaultValue n/a Range n/a

5.2.3.3 SPA Registration Info Reply Message

This message is sent by the SPA Lookup Service to a component in response to a SPARegistrationInfoRequest message. The Lookup Service shall search registered xTEDS for providers that match the request. If there are no matches, then the Lookup Service shall send one terminating SPARegistrationInfoReply message; otherwise, the Lookup Service shall send a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message.

5.2.3.4 SPA Registration Info Reply Sequence Diagram

See Figure 3.

The format for the SPA Registration Info Reply message is shown below in Table 11.

Table 11 – SPA registration info reply

Message Name SPARegistrationInfoReply Message Opcode 0 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Response message to SPARegistrationInfoRequest message

Field Name Size Offset Value Description Source 4 0 n/a Source address of provider ProviderInterfaceID 1 1 n/a xTEDS interface identifier ProviderMessageID 1 2 n/a xTEDS message identifier

23

DialogIdentifier 2 3 n/a Dialog identifier set by the requester Type 1 5 n/a Indicates registration or cancellation MessageDefinition n1 6 n/a Annotated summary of the xTEDS that matched a query xTEDS_section n2 6 + n1 n/a Section of the full data message definition in the xTEDS


Name ProviderInterfaceID Description xTEDS interface identifier

Full Description Number uniquely identifying the interface within the target component xTEDS. See the SPA Ontology Standard for the definition of this number.


Name ProviderMessageID Description xTEDS message identifier

Full Description Number uniquely identifying the message within indicated interface within the target component xTEDS. See the SPA Ontology Standard for the definition of this number.



Full Description Value used to pair SPARegistrationInfoRequest messages with corresponding SPARegistrationInfoReply messages



24

Range n/a Name Type

Description Indicates registration or cancellation

Full Description Enumeration indicating if this is a notification of a registration event or a cancellation event


Range Name Description Value

REGISTRATION Indicates registration event 0 CANCELLATION Indicates cancellation event 1

Name MessageDefinition Description Annotated summary of the xTEDS that matched a query

Full Description

Annotated summary of the xTEDS that matched a query. The annotated summary shall be a list of objects in the xTEDS that satisfy the query, and that apply to the xTEDS message defined in this message. Each item in the list shall consist of an element name, the name attribute of the element, and a list of qualifier specifications that it matches. If the query specified no qualifiers, then this string shall be empty. The elements may be devices, interfaces, messages, or variables.

Size n1 Offset 6 DataType string Units n/a DefaultValue n/a Range n/a

Name xTEDS_section Description Section of the full data message definition in the xTEDS

Full Description Section of the full data message definition in the xTEDS. If the xTEDS message contains variable references, then those shall be replaced with the definitions of the variables to which they refer.

Size n2 Offset 6 + n1 DataType string Units n/a DefaultValue n/a Range n/a 5.2.3.5 SPA Variable Info Request Message

This message is sent by a component to the SPA Lookup Service in order to request the xTEDS segment defining a variable in a data providers xTEDS. The Lookup Service shall search registered xTEDS for matching variable definitions and qualifiers. If there are no matches, then the Lookup Service shall send one terminating SPAVariableInfoRequest message; otherwise, the Lookup Service shall send a

25

SPAVariableInfoRequest message for each match and one terminating SPAVariableInfoRequest message.

5.2.3.6 SPA Variable Info Request Sequence Diagram

The sequence for command is exactly the same as the SPARegistrationInfoRequest command (Figure 3). The only exeception is that the reply command is the SPAVariableInfoReply.

The format for the SPA Variable Info Request message is shown below in Table 12.

Table 12 – SPA variable info request

Message Name SPAVariableInfoRequest Message Opcode 78 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Request xTEDS variable information

Field Name Size Offset Value Description Source 4 0 n/a Source address of provider Reply 1 4 n/a Enumeration of request type DialogIdentifier 2 5 n/a Dialog identifier set by the requester ProviderInterfaceID 1 7 n/a xTEDS interface identifier ProviderMessageID 1 8 n/a xTEDS message identifier VariableName n 9 n/a Name of the variable


Name Reply Description Enumeration of request type Full Description Enumeration of request type Size 1 Offset 4 DataType uint8 Units enumeration DefaultValue n/a

Range


SPA_REQREG_CURRENT

Request current matches only

0

SPA_REQREG_CURRENT_AND_FUTURE Request 5


26

current and future matches

SPA_REQREG_CURRENT_FUTURE_AND_CANCELLATIONS

Request current and future matches, plus cancellations

7

SPA_REQREG_CANCEL Cancel previous request

11


Full Description Value used to pair SPAVariableInfoRequest messages with corresponding SPAVariableInfoReply messages


Name ProviderInterfaceID Description xTEDS interface identifier

Full Description Number uniquely identifying the interface within the target component xTEDS. See the SPA Ontology document for the definition of this number.


Name ProviderMessageID Description xTEDS message identifier

Full Description Number uniquely identifying the message within indicated interface within the target component xTEDS. See the SPA Ontology document for the definition of this number.


Name VariableName Description Name of the variable

27

Full Description Null-terminated string that matches the name of a variable in the provider's xTEDS Size n Offset 9 DataType uint8 Units n/a DefaultValue n/a Range n/a 5.2.3.7 SPA Variable Info Reply Message

This message is sent by the SPA Lookup Service to a component in response to a SPAVariableInfoRequest subscription message. The Lookup Service shall search registered xTEDS for matching variable definitions and qualifiers. If there are no matches, then the Lookup Service shall send one terminating SPAVariableInfoReply message; otherwise, the Lookup Service shall send a SPAVariableInfoReply message for each match and one terminating SPAVariableInfoReply message.

5.2.3.8 SPA Variable Info Reply Sequence Diagram

The sequence for command is exactly the same as the SPARegistrationInfoRequest command (Figure 3). The only exeception is that the initial command is the SPAVariableInfoRequest message.

The format for the SPA Variable Info Reply Message is shown in Table 13 below.

Table 13 – SPA variable info request

Message Name SPAVariableInfoReply Message Opcode 79 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Reply to SPAVariableInfoRequest

Field Name Size Offset Value Description Source 4 0 n/a Source address of provider DialogIdentifier 2 4 n/a Dialog identifier set by the requester ProviderInterface n1 6 n/a xTEDS interface name VariablexTEDS n2 n1+6 n/a Full xTEDS definition of the variable


Name DialogIdentifier Description Dialog identifier set by the requester Full Description Value used to pair SPAVariableInfoRequest messages with corresponding


28

SPAVariableInfoReply messages Size 2 Offset 4 DataType uint16 Units n/a DefaultValue n/a Range n/a

Name ProviderInterface Description xTEDS interface name Full Description Name of the interface in which the variable information resides. Null terminated. Size n1 Offset 6 DataType uint8 Units n/a DefaultValue n/a Range n/a

Name VariablexTEDS Description Full xTEDS definition of the variable Full Description Full xTEDS definition of the variable Size n2 Offset n1+6 DataType uint8 Units n/a DefaultValue n/a Range n/a 5.2.4 Subscriptions to Data

This family of messages (messages that support the application layer of SPA) supports connection to system data sources. Once a query has revealed a suitable source, it is up to the consumer component to establish a subscription with a provider. This can be brokered by the SPA Lookup Service, which tracks all subscriptions so that it can notify all consumers if a provider is cancelled (intentionally or due to unresponsiveness). Alternatively, the consumer can send a subscription request directly to the producer component.

5.2.4.1 SPA Subscription Request Message

The SPA Subscription Request Message is sent by a component to the SPA Lookup Service in order to request subscription services that will retrieve system data including but not limited to delivery rate, lease period, priority, and so forth. Figures 4, 5, 6, and 7 give examples of SPA Subscription Request Sequences occurrences.

29

5.2.4.2 SPA Subscription Request Sequence Diagram

Figure 4 – SPA subscription request sequence diagram 1

1. The device or application shall send a SPARegistrationInfoRequest message to the Lookup Service.

2. The SPA Lookup Service shall generate a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message.

3. The device or application shall send a SPASubscriptionRequest message to the Lookup Service to request that a notification be sent from a data provider.

4. The Lookup Service shall send a SPASubscriptionRequest message to the data provider to subscribe to a notification message with the SubscriptionManager field set to its address.

5. The data provider shall send a SPASubscriptionReply to the Lookup Service indicating that the subscription was accepted.

6. The Lookup Service shall send the SPASubscriptionReply received from the data provider to the device or application indicating that the subscription was accepted.

7. The data provider sends SPAData message(s) directly to the device or application that requested the data notification.

In the following scenario, the consumer does not use a lookup service but rather subscribes to the data directly.


30

Figure 5 – SPA subscription request sequence diagram 2

1. The consumer component shall send a SPASubscriptionRequest message to the producer component.

2. The producer component shall send a SPASubscriptionReply to the consumer component indicating that the subscription was accepted.

3. The producer component shall send SPAData message(s) directly to the device or application that requested the data notification.

In this next example, the producer component cancels the subscription due to limited resources. This scenario would work in the same way with the SPA Lookup Service, except messages would go directly to the SPA Lookup Service.

31

Figure 6– SPA subscription request sequence diagram 3

1. The consumer component shall send a SPASubscriptionRequest message to the producer component.



4. When another consumer component subscribes to a notification and the producer component can no longer fulfill the original consumer, it shall send a SPASubscriptionReply command to cancel the subscription and no longer send notifications to that original consumer.

This next example demonstrates how the lease capability functions.


32

Figure 7– SPA subscription request sequence diagram 4

1. The consumer component shall send a SPASubscriptionRequest message to the producer component with the lease period set to a specified time.



4. The consumer component shall send the exact same SPASubscriptionRequest message from step 1, and thereby renew the subscription.

5. The producer component shall send a SPASubscriptionReply to the consumer component indicating that the lease extension was accepted.

The format for the SPA Subscription Request message is shown below in Table 14.

Table 14 – SPA subscription request

Message Name SPASubscriptionRequest Message Opcode 108 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Request subscription services to retrieve system data

33

Field Name Size Offset Value Description SubscriptionProducer 4 0 n/a Address of producer component SubscriptionConsumer 4 4 n/a Address of consumer component SubscriptionManager 4 8 n/a Address of the Subscription Manager ProducerInterfaceID 1 12 n/a xTEDS interface identifier ProducerInterfaceMessageID 1 13 n/a xTEDS message identifier DialogIdentifier 2 14 n/a Dialog identifier set by the requester DeliveryRateDivisor 2 16 1 Subscribe to every nth message SubscriptionPriority 1 18 n/a Requested priority of the subscription SubscriptionLeasePeriod 4 19 n/a Requested lease duration of the subscription SubscriptionType 1 23 n/a Indicates subscription request or cancellation

Name SubscriptionProducer Description Address of producer component Full Description Address of producer component that fullfills the scrubscription Size 4 Offset 0 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name SubscriptionConsumer Description Address of consumer component Full Description Address of consumer component that requires the scrubscription Size 4 Offset 4 DataType uint32 Units n/a DefaultValue n/a Range n/a

Name SubscriptionManager Description Address of the Subscription Manager

Full Description

Address of Subscription Manager. If this field is not the same as SubscriptionConsumer, then the producer will send the SPASubscriptionReply message to this address instead of the SubscriptionConsumer address.


Name ProducerInterfaceID Description xTEDS interface identifier


34

Full Description Number uniquely identifying the interface within the producer component xTEDS


Name ProducerInterfaceMessageID Description xTEDS message identifier

Full Description Number uniquely identifying the message within indicated interface within the producer component xTEDS



Full Description Value used to pair SPASubscriptionRequest messages with corresponding SPASubscriptionReply messages


Name DeliveryRateDivisor Description Subscribe to every nth message

Full Description

Reduces rate of delivery of periodic messages by reciprocal of this value. The producer skips sending messages to subscriber except every nth. Setting to 1 indicates to send all messages. Producer's xTEDS may contain qualifier MaximumDeliveryRateDivisor with value indicating what the producer will support; subscription requests in excess will receive SUBSCRIPTION_CANCELED_RESOURCES.

Size 2 Offset 16 DataType uint16 Units n/a DefaultValue 1 Range [1, 65535]

Name SubscriptionPriority Description Requested priority of the subscription

35

Full Description Requested priority of the subscription. This producer component may choose to ignore this field. It can use it to deny or accept the request. It also may use it to order the transmission multiple notification messages.

Size 1 Offset 18 DataType uint8 Units n/a DefaultValue n/a Range 0-255. 0 = highest priority, 255 = lowest priority

Name SubscriptionLeasePeriod Description Requested lease duration of the subscription

Full Description

Requested lease duration of the subscription. This field indicates the lifetime of the subscription. If the lease period expires, the producer will cancel the subscription and no longer send the notification message. Setting to 0 indicates infinite period.

Size 4 Offset 19 DataType uint32 Units seconds DefaultValue n/a Range n/a

Name SubscriptionType Description Indicates subscription request or cancellation



Range


SUBSCRIPTION_REQUEST Indicates the consumer components desire to subscribe to the producers notification message.

0

SUBSCRIPTION_CANCEL Indicates the consumer components desire to cancel future notification messages from the producer.

1

5.2.4.3 SPA Subscription Reply Message

This message is sent by the SPA Lookup Service to a component in response to a SPASubscriptionRequest subscription message. The Lookup Service shall search registered xTEDS for matching variable definitions and qualifiers. If there are no matches, then the Lookup Service shall send one terminating SPASubscriptionReply message; otherwise, the Lookup Service shall send a SPASubscriptionReply message for each match and one terminating SPASubscriptionReply message.


36

5.2.4.4 SPA Subscription Reply Sequence Diagram

See Figure 4.

The format for the SPA Subscription Reply message is shown below in Table 15.

Table 15 – SPA subscription reply

Message Name SPASubscriptionReply Message Opcode 109 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Reply to SPASubscriptionRequest

Field Name Size Offset Value Description DialogIdentifier 2 0 n/a Dialog identifier set by the requester SubscriptionType 1 2 n/a Indicates subscription acceptance, deny, or cancellation


Full Description Value used to pair SPASubscriptionRequest messages with corresponding SPASubscriptionReply messages


Name SubscriptionType Description Indicates subscription acceptance, deny, or cancellation



Range


SUBSCRIPTION_REQUEST_GRANTED Indicates the subscription request was granted 0

SUBSCRIPTION_CANCELED

Indicates the subscription was canceled. This reply could be a response to a request to a cancelation, or for some adhoc reason.

1

SUBSCRIPTION_CANCELED_PRIORITY Indicates the subscription was canceled due to priority 2

SUBSCRIPTION_CANCELED_RESOURCES Indicates the subscription was canceled due to limited producer resources

3

37

SUBSCRIPTION_CANCELED_SHUTDOWN Indicates the subscription was canceled due to producer going offline

4

SUBSCRIPTION_CANCELED_LEASEEXPIRED Indicates the subscription was canceled due to the lease term expired

5

5.2.5 Intercomponent Data Exchange

After components have discovered each other and or subscribed to data, they are ready to exchange application specific data between each other. This is accomplished by the use of the SPAData, SPACommand, SPAServiceRequest, and SPAServiceReply messages.

5.2.5.1 SPA Data Request Message

This message is sent by a SPA component to a device or application that has a subscribed notification with the component. The SPA component providing the requested information shall transfer the data in accordance with pre-determined subscription service agreements. Figure 8 gives an example of a SPA Data Request Sequence occurrence.

5.2.5.2 SPA Data Request Sequence Diagram

Figure 8 – SPA data request sequence diagram

1. The device or application shall send a SPARegistrationInfoRequest message to the Lookup Service.

2. The SPA Lookup Service shall generate a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message.

3. The device or application shall send a SPASubscriptionRequest to the Lookup Service to request that a notification be sent from a data provider.


38

4. The Lookup Service shall send a SPASubscriptionRequest message to the data provider to subscribe to a notification message.

5. The data provider shall send SPAData message(s) directly to the device or application that requested the data notification.

The format for the SPA Data message is shown below in Table 16.

Table 16 – SPA data message

Message Name SPAData Message Opcode 116 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Application Specific Data

Field Name Size Offset Value Description provider_interface 1 0 n/a xTEDS interface identifier provider_msg 1 1 n/a xTEDS message identifier payload_length 2 2 n/a length of the payload data payload payload_length 4 0 Message data payload

Name provider_interface Description xTEDS interface identifier Full Description Number uniquely identifying the interface within the providers xTEDS Size 1 Offset 0 DataType uint8 Units n/a DefaultValue n/a Range n/a

Name provider_msg Description xTEDS message identifier

Full Description Number uniquely identifying the message within indicated interface within the providers xTEDS


Name payload_length Description length of the payload data Full Description number of bytes in the payload field Size 2 Offset 2 DataType uint16 Units bytes

39

DefaultValue n/a Range 0-65536

Name payload Description Message data payload Full Description Contains the data indicated in the provider's xTEDS Size payload_length Offset 4 DataType uint8 Units n/a DefaultValue 0 Range n/a

5.2.5.3 SPA Command Message

This message is sent by a SPA component to another SPA component in order to have the component execute a command. The commanding SPA component shall transfer commands and the receiving SPA component shall execute commands. Figure 9 gives an example of a SPA Command Sequence occurrence.

5.2.5.4 SPA Command Sequence Diagram

Figure 9 – SPA command sequence diagram

1. The device or application sends a SPARegistrationInfoRequest message to the Lookup Service.

2. The SPA Lookup Service generates a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message.

3. The device or application sends a SPACommand message directly to the device or application it wishes to command.

4. The device or application that receives the SPACommand message executes the command.


40

The format for the SPA Command message is shown below in Table 17. Table 17 – SPA data request message

Message Name SPACommand Message Opcode 122 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Application specific command Message Description

Field Name Size Offset Value Description provider_interface 1 0 n/a xTEDS interface identifier provider_msg 1 1 n/a xTEDS message identifier payload_length 2 2 n/a length of the payload data payload payload_length 4 0 Message data payload

Name provider_interface Description xTEDS interface identifier Full Description Number uniquely identifying the interface within the target component xTEDS Size 1 Offset 0 DataType uint8 Units n/a DefaultValue n/a Range n/a


Full Description Number uniquely identifying the message within indicated interface within the target component xTEDS


Name payload_length Description length of the payload data Full Description number of bytes in the payload field Size 2 Offset 2 DataType uint16 Units bytes DefaultValue n/a Range 0-65536

41

Name payload Description Message data payload Full Description Contains the data indicated in the target component's xTEDS Size payload_length Offset 4 DataType uint8 Units n/a DefaultValue 0 Range n/a

5.2.5.5 SPA Service Request Message

The SPA Service Request message is sent by a SPA component to another SPA component to request the execution of a service. The requesting component shall transfer the request to the SPA component providing the service, and the providing service component will then send a reply back to the requesting component. Figure 10 gives an example of a SPA Service Request Sequence occurrence.

5.2.5.6 SPA Service Request Sequence Diagram

Figure 10 – SPA service reply sequence diagram

1. The device or application sends a SPARegistrationInfoRequest message to the Lookup Service.

2. The SPA Lookup Service generates a SPARegistrationInfoReply message for each match and one terminating SPARegistrationInfoReply message.

3. The device or application sends a SPAServiceRequest message to the service provider.

4. The service provider processes the request.

5. The service provider always sends a SPAServiceReply message to the device or application that initiated the request.

The format for the SPA Service Request Message is shown below in Table 18.


42

Table 18 – SPA service request

Message Name SPAServiceRequest Message Opcode 121 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Application specific service request

Field Name Size Offset Value Description provider_interface 1 0 n/a xTEDS interface identifier provider_msg 1 1 n/a xTEDS message identifier DialogIdentifier 2 2 n/a Dialog identifier set by the requester reserved 2 4 n/a reserved payload_length 2 6 n/a length of the payload data payload payload_length 8 0 Message data payload






Full Description Identifier of the request to provide a tracking capability. The target copies this number into the reply.


Name reserved

43

Description reserved Full Description reserved Size 2 Offset 4 DataType uint8 Units n/a DefaultValue n/a Range n/a


Name payload Description Message data payload Full Description Contains the data indicated in the target component's xTEDS Size payload_length Offset 8 DataType uint8 Units n/a DefaultValue 0 Range n/a 5.2.5.7 SPA Service Reply Message

The SPA Service Reply Message is sent by a SPA component to another SPA component in response to a SPAServiceRequest.

5.2.5.8 SPA Service Reply Sequence Diagram

See Figure 10.

The format for the SPA Service Reply message is shown below in Table 19.

Table 19 – SPA service reply message

Message Name SPAServiceReply Message Opcode 121 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Application specific service reply

Message Description

Sent by a SPA component to another SPA component to response to a SPAServiceRequest


44

Field Name Size Offset Value Description provider_interface 1 0 n/a xTEDS interface identifier provider_msg 1 1 n/a xTEDS message identifier DialogIdentifier 2 2 n/a Dialog identifier set by the requester reserved 2 4 n/a reserved payload_length 2 6 n/a length of the payload data payload payload_length 8 0 Message data payload






Full Description Identifier of the request to provide a tracking capability. This number comes from the request message.


Name reserved Description reserved Full Description reserved Size 2 Offset 4 DataType uint8

45

Units n/a DefaultValue n/a Range n/a


Name payload Description Message data payload Full Description Contains the data indicated in the target component's xTEDS Size payload_length Offset 8 DataType uint8 Units n/a DefaultValue 0 Range n/a

5.3 Component Network Capabilities

This section describes the messages and protocols that support the transport and network layers of SPA architecture. SPA components that manage the network use these messages. The detailed description of each of these related message formats is found in the AIAA S-133-2-201X SPA Networking Standard, Sections 4.2.1.2 through 4.2.1.6.

Different implementations of network configuration and routing are possible, but the algorithm described in the SPA Networking Standard is currently normative. In the future, alternative algorithms may be developed that replace the network and transport layers, along with the messages that flow only in those layers. In order to facilitate those developments, this section designates the interface between application and transport/network layers, so the replacement will not affect the application layer. The future algorithms will be extensions to the standard. Messages that require interaction with SPA components are marked ”app-net interface” in order to assure compatibility. Messages that remain within the transport/network layers are marked “net” to indicate that they could be replaced along with the entire transport/network layers in a future extension of the standard.

5.3.1.1 Discovery

A SPA network is flexible in terms of different topologies and may consist of a number of heterogeneous subnets. For example, a SPA network may consist of a SPA SpaceWire subnet, SPA USB subnet, SPA I2C subnet, and so forth. The discovery process shall occur in two steps. In the first step, the SPA network componments shall discover the SPA devices and applications in all subnetworks, as described in the SPA Networking Standard. In the second step, the network components shall notify the Lookup Service of the existence of components, and the Lookup Service then shall discover the data and


46

services that those components offer. The steps shall occur in this order for each SPA component, but the order of steps between different components shall not be constrained by this standard.

5.3.1.2 Notifying SPA Lookup Service of Components

Through the process of implementing network configuration and routing, each networking component shall notify the SPA Lookup Service of components on its subnetwork, which should be registered. For the SPA Networking Standard, a relevant networking component would be SM-x. (See Figure 11.)

5.3.1.3 SPA Request SPA Lookup Service Probe Message Sequencing Diagram

Figure 11 – Notification of components to SPA lookup service sequencing diagram

5.3.1.4 Interaction Description

Network components such as SM-x that discover SPA components shall send SPARqstLSProbe messages to the SPA Lookup Service with the address and CUUID of components, which should be registered for subscription.

5.3.1.5 Reporting Errors Occuring on the Network

In order to allow network components such as the SM-x to report errors occurring within a subnet, the messages SPANetworkStatusRequest and SPANetworkStatusReply allow a component to request status updates from a SPA component (see Figure 12).

5.3.1.6 Error Reporting Sequencing Diagram

Figure 12 – Error reporting sequencing diagram

5.3.1.7 Interaction Description

1. A component shall send a SPANetworkStatusRequest message to the network component, requesting a number and frequency of status updates

SPA Lookup Service SM-x

1. SPARqstLSProbe

47

2. The network component shall send a reply immediately, and then at the rate requested until the specified number of messages have been transmitted (may be infinite, or single response). The response may indicate no error, or link or subnet component error or failure.

5.3.2 SPA Request SPA Lookup Service Probe Message

A SPARqstLSProbe shall be sent by a network component such as a SM-x to the SPA Lookup Service after a component has received its logical address so that it may be probed for its xTEDS.

The format for the SPA Request SPA Lookup Service Probe message is shown below in Table 20.

Table 20 – SPA request SPA lookup service probe message format

Message Name SPARqstLSProbe (app-net interface) Message Opcode 0x69 SPA Version 1 (Note: “1” indicates the initial version) Summary Description SM-x request to SPA Lookup Service to perform component probe

Field Name Size Offset Value Description ComponentAddress 4 16 n/a Logical Address

Name ComponentAddress Description Logical Address Full Description The logical address of the SPA component to be registered Size 4 Offset 16 DataType uint32 Units n/a DefaultValue n/a Range n/a

5.3.3 SPA Network Status Request Message

This message shall be sent by a component (typically a high-level manager) to another component to monitor network health and status. The user can request multiple SPANetworkStatusReply messages to verify that the component is still alive. The first SPANetworkStatusReply message occurs immediately, and future ones are at the specified rate. If a component would no longer like to receive future SPANetworkStatusReply messages, then it can send a SPANetworkStatusRequest message with a count of 1.

The format for the SPA Network Status Request message is shown below in Table 21.

Table 21 – SPA network status request message format

Message Name SPANetworkStatusRequest (app-net interface) Message Opcode 112 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Sent to request staus updates from a SPA network component

Field Name Size Offset Value Description DialogIdentifier 2 0 n/a Dialog identifier set by the requester ReplyCount 2 4 n/a Number of SPANetworkStatusReply messages ReplyPeriod 2 6 n/a Period of SPANetworkStatusReply messages


48


Full Description Value used to pair SPANetworkStatusRequest messages with corresponding SPANetworkStatusReply messages. This field does not need to be the same as previous sequences when requesting new reply count or rate.


Name ReplyCount Description Number of SPANetworkStatusReply messages

Full Description The requested number of future SPANetworkStatusReply messages to be sent in response to this request. 0 for infinite.


Name ReplyPeriod Description Period of SPANetworkStatusReply messages

Full Description The period between sending multiple SPANetworkStatusReply messages. Bandwidth and component limitations might limit the lower bounds on this number.

Size 2 Offset 6 DataType uint16 Units milliseconds DefaultValue n/a Range n/a

5.3.4 SPA Network Status Reply Message

The SPA Network Status Reply Message shall be sent by a component to another component (typically a high-level manager) in response to a request for network health and status. The user can request multiple SPANetworkStatusReply messages to verify that the component is still alive. The first SPANetworkStatusReply message occurs immediatly, and future ones are at the specified rate. If a component would no longer like to receive future SPANetworkStatusReply messages, it can send a SPANetworkStatusRequest message with a count of 1.

The format for the SPA Network Status Request message is shown below in Table 22.

49

Table 22 – SPA network status reply message format

Message Name SPANetworkStatusReply (app-net interface) Message Opcode 113 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Network Status response for a SPA component

Field Name Size Offset Value Description DialogIdentifier 2 0 n/a Dialog identifier set by the requester RemainingReplyCount 2 2 n/a Number of SPANetworkStatusReply messages Uptime 4 4 n/a Seconds since power on

TargetUUID 16 8 n/a Universally Unique Id of the SPA component reply is sent to

SourceUUID 16 24 n/a Universally Unique Id of the SPA component constructing the response

FaultIndicator 4 40 n/a Indicates presense of fault PortNumber 2 44 n/a Port Number ComponentNumber 16 46 n/a Component Number FailureType 4 62 n/a Description of failure


Full Description Value used to pair SPANetworkStatusRequest messages with corresponding SPANetworkStatusReply messages


Name RemainingReplyCount Description Number of SPANetworkStatusReply messages

Full Description The remaining number of future SPANetworkStatusReply messages to be sent in response to the original request


Name Uptime Description Seconds since power on

Full Description The number of seconds the component has been active on the SPA network. 0 if not implemented.

Size 4 Offset 4


50

DataType uint32 Units Seconds DefaultValue n/a Range n/a

Name TargetUUID Description Universally Unique Id of the SPA component reply is sent to

Full Description Universally Unique Id of the SPA component as described in section 5.4.2 of the standards


Name SourceUUID Description Universally Unique Id of the SPA component constructing the response Full Description Value is the Universally Unique ID for the sending component Size 16 Offset 24 DataType uint128 Units n/a DefaultValue n/a Range n/a

Name FaultIndicator Description Indicates presense of fault

Full Description A component can set this field to indicate the presense of a fault at any level of the component. The indicator will clear itself upon removal of the fault condition.

Size 4 Offset 40 DataType uint32 Units n/a DefaultValue n/a Range 0=no fault, else fault condition exists

Name PortNumber Description Port Number

Full Description Port Number on which the network fault has occurred. 0x100 indicates a general fault (port number is meaningless)


51

Name ComponentNumber Description Component Number

Full Description Component descriptor for component where error occured. Allows a SPA component to make a report for another SPA or non SPA component. Descriptor may be a UUID, or a user defined identifier.


Name FailureType Description Description of failure Full Description FailureType encodes the type of failure encountered Size 4 Offset 62 DataType uint32 Units n/a DefaultValue n/a

Range

Name Description Value Link Error Indicates a network error received on the link 0 Link Failure Indicates a link is unusable 1 Component Failure

Indicates the failure on a non-SPA component on the network, such as a router 2

User User encoded error value 3 and up

5.3.5 Health and Status

The SPA network may need to be periodically monitored to ensure a healthy operational state. Different missions may choose to respond or detect faults in different ways. However, the SPA network itself must provide a mechanism to report issues or faults in the network.

There are two basic approaches to network monitoring. With active monitoring a master fault manager sends a message to each component that it is monitoring, and expects a reply within an allotted time. Passive monitoring requires a master to configure components to send a message to the master at a periodic rate.

SPA supports both methodologies for monitoring the network. This is achieved through the use of the SPAProbeRequest and SPAProbeReply messages. These messages have fields in them that not only aid in discovery, but also allow a fault manager to monitor the basic health of a component.

5.3.6 Time Synchronization

Timing synchronization for SPA systems is achieved through a time-at-tone message and a synchronization pulse. This is discussed in more detail in the SPA Timing Standard.


52

5.3.6.1 SPA Time-At-Tone-Message

This message shall be received before a Sync Pulse. It is sent to all components. The message contains two different clocks for use at the descrection of the component. The System Clock contains the system time in seconds and microseconds as dictated by the System Clock Epoch Type. The System Clock can make large jumps and even go in the reverse direction. The Monotonic Clock defines some arbitrary time that only increments by 1 for every sync pulse that is sent.

The SPA Time-at-Tone messge format is shown below in Table 23.

Table 23 – SPA time-at-tone message format

Message Name SPATimeAtTone Message Opcode 72 SPA Version 1 (Note: “1” indicates the initial version) Summary Description Time at the Tone Message Description

Field Name Size Offset Value Description SystemClockType 4 0 n/a System Clock time standard SystemSeconds 4 4 n/a Time in seconds SystemMicroseconds 4 8 n/a Additional microseconds of the time MonotonicClock 4 12 n/a Linearly increasing counter

Name SystemClockType Description System Clock time standard

Full Description The system defined time standard. This field indicates the time standard used in SystemSeconds and SystemMicroseconds.


Range

Name Description Value USER_DEFINED User defined time standard 0 UNIX_EPOCH Seconds since January 1, 1970 1 GPS_EPOCH Seconds since January 1, 1980 2

Name SystemSeconds Description Time in seconds Full Description The time in second when the Sync pulse is received Size 4 Offset 4 DataType uint32 Units seconds DefaultValue n/a Range n/a

Name SystemMicroseconds Description Additional microseconds of the time

53

Full Description The number of microseconds paste the time specified in the "seconds" field Size 4 Offset 8 DataType uint32 Units useconds DefaultValue n/a Range 0-999999

Name MonotonicClock Description Linearly increasing counter

Full Description Defines some arbitrary time that only increments by 1 for every sync pulse that is sent


5.3.7 Quality of Service

Some rudimentary quality of service functions have been incorporated into the SPA approach, but because quality of service is such a broad area and its application will vary so greatly, it is not fully addressed by the SPA standards but is left to the implementer to design. The measures taken to provide some quality of service for SPA systems and their associated messages and protocols are described in this section.

5.3.7.1 Guaranteed Delivery

This section will eventually be normative, but it has not been tested, so the information here is subject to change.

Delivery of a message can be guaranteed by including the SPA Guaranteed Delivery Extended (GDE) Header in the headers of a message before sending it. Both the sender and the receiver of a message carrying this header behave differently than they would for a message without this header. The special behavior with the header serves to notify the sender that the message has arrived intact, and it helps the receiver to ignore duplicates in case the sender resends and both the original and the resent messages arrive.

The option for reliably delivered SPA messages shall be available to consumers by the following means:

a) Subscriptions

The GDE Header extends the SPASubscriptionRequest message to enable a consumer component to request guaranteed delivery of data. The GDE Header contains flags named “GDE_GUARANTEE_NOTIFICATION” to request guaranteed delivery of subscribed messages and “GDE_GUARANTEE_REPLY” to request guaranteed delivery of the SPASubscriptionReply message; these flags may be present without requesting guaranteed delivery of the message that carries them. If the provider can do so, it will send messages with guaranteed delivery. After issuing a SPASubscriptionRequest, the consumer can examine the GDE_GUARANTEE_NOTIFICATION flag in the header in the SPASubscriptionReply message, which reports whether the provider supports guaranteed delivery.


54

Guaranteed delivery may be requested for a SPASubscriptionRequest message, but the SPASubscriptionReply message informs the application that the request was delivered, so the extra overhead of guaranteed delivery is probably wasted on a SPASubscriptionRequest. If guaranteed delivery were requested for a SPASubscriptionRequest message, the acknowledgement would flow back in a SPATransport message, because the acknowledgement flows between the transport layers of the sender and receiver, while the SPASubscriptionReply message flows between the application layers.

b) Commands

When a GDE Header appears in a SPACommand message, the acknowledgement flows back in a SPATransport message. The header indicates whether the command was received, but it does not indicate whether the command was executed successfully.

c) Service Requests

A SPAServiceRequest message may contain a GDE Header with the GDE_GUARANTEE_REPLY flag set. This has the effect of requesting guaranteed delivery for the response to that request. The situation is analogous to the SPASubscriptionRequest message except that the GDE_GUARANTEE_NOTIFICATION flag is not used.

5.3.7.2 Guaranteed Delivery Sequence Diagrams

The implementation of guaranteed delivery is a function of the SPA transport layer, as constrained by requirements in the SPA Networking specification. The GDE Header contains fields that can be used to implement a protocol similar to Reliable Data Delivery Protocol of SpaceWire.

The components involved in guaranteed delivery of a message play the roles of sender and receiver, so there is a virtual channel between them that flows in one direction. For bidirectional guaranteed delivery, the components play both roles, and two channels flowing in opposite directions run between the components. The remainder of this discussion focuses on a single virtual channel. The sender first recognizes the need to send a message with guaranteed delivery and initiates the virtual channel to the receiver by means of the exchange in the sequence diagram shown in Figure 13 below.

Figure 13 – Guaranteed delivery request sequence diagram

1. When a component first decides to send a message with guaranteed delivery to another component, it starts a sequence number for communication with the receiver’s logical address. It sends a SPATransport message with a GDE Header in which the message type is GDE_RESET and the sequence number in the header is the sender’s initial value.

2. If the receiver does not support guaranteed delivery, then it replies with a SPATransport message with a GDE Header in which the message type is GDE_NEGATIVE. Otherwise, the receiver resets its expected next sequence number of the virtual channel to the value in the GDE Header

Sender Receiver

1. Reset

2. Acknowledge or Negative

55

from the sender. It notifies the sender that this has been done by sending a message with a GDE Header in which the message type is GDE_ACKNOWLEDGE. The acknowledgement header contains the size of the receiver’s queue for out-of-order messages, which is described below.

After establishing the virtual channel, the sender may send any number of messages to the receiver with guaranteed delivery. The sequence number increases with each such message and wraps to zero after the maximum value of the unsigned integer. The sequence diagram shown in Figure 14 below shows the nominal case of a message delivered successfully on the first try.

Figure 14 – Guaranteed delivery acknowledge sequence diagram

1. When a component sends a message with guaranteed delivery to another component, it inserts into the message a GDE Header in which the message type is GDE_DATA, and the sequence number in the header is the current value of the sender’s sequence number. Then it increments its sequence number for communication with the receiver’s logical address. The sender maintains a queue of messages that it has sent, but for which it has not yet received acknowledgement. The maximum size of this queue is called the sender’s window, and the span of sequence numbers in this window is no larger than the receiver’s window. When the sender’s queue reaches maximum size, the sender refuses to send any more messages with guaranteed delivery until the queue shrinks. The queue will shrink when the receiver acknowledges one of the messages in the queue.

2. The receiver maintains a queue of messages that it has received out of order. The maximum size of this queue is called the receiver’s window. The sequence numbers in the receiver’s window start at the receiver’s expected next sequence number. When a message arrives with a GDE Header, the receiver attempts to insert the message into its queue of messages, using as a key the sequence number in the GDE Header. If the key is already present, the message is a duplicate. If the key is not in the receiver’s window, then it is a duplicate. The receiver sends a SPATransport message with a GDE header in which the message type is GDE_ACKNOWLEDGE to the sender. The receiver discards duplicate messages. Otherwise, the receiver inserts the message into its queue, using the sequence number as key. Although the first message in the receiver’s queue has the expected next sequence number, the receiver removes the message from its queue, increments its expected next sequence number, and releases that message to the receiving application.

The comparisons of sequence numbers are done on a range of unsigned integers that wrap from highest value to zero; the comparison uses the fact that the receiver’s window is no more than half the highest value to distinguish messages that arrive late. In order to make this distinction, the maximum life of a message in the network between the sender and receiver must be significantly less than the ratio of the number of sequence numbers outside the receiver’s window divided by the maximum message rate.

The sequence diagram in Figure 15 below shows what happens when a message from the sender does not reach the receiver.

Sender Receiver

1. Data

2. Acknowledge


56

Figure 15 – Guaranteed delivery message resend upon failure sequence diagram

1. When a component sends a message with guaranteed delivery to another component, and that message does not arrive at the receiver within a certain amount of time, then the receiver cannot acknowledge it.

2. If an acknowledgement does not return to the sender in a certain amount of time for each message, the sender resends the message.

3. When a resent message eventually arrives at the receiver, the receiver acknowledges it. The receiver may have already received other messages from the sender that were sent after the missing message, so its queue of out-of-order messages would have those messages in it. The resent message could have the expected next sequence number, in which case the receiver would release it to the application. The receiver would also release messages with adjacent sequence numbers. If the missing message were to arrive later, the receiver would recognize that it is a duplicate.

The sequence diagram in Figure 16 below shows what happens when an acknowledgement from the receiver does not reach the sender.

Figure 16 – Guaranteed delivery acknowledgement resend upon failure sequence diagram

1. A component sends a message with guaranteed delivery to another component, and that message arrives at the receiver within a certain amount of time.

Sender Receiver

1. Data

2. Acknowledge

3. Resend

4. Acknowledge

Sender Receiver

1. Data

3. Acknowledge

2. Resend

57

2. The receiver acknowledges the message, but the acknowledgement gets lost or delayed.

3. If an acknowledgement does not return to the sender in a certain amount of time for each message, the sender resends the message.

4. When a resent message eventually arrives at the receiver, the receiver recognizes it as a duplicate and acknowledges it. The acknowledgement enables the sender to remove the message from its queue.

If the sender fails and restarts without memory of a virtual channel, then it will send a reset message to the receiver. The receiver will discard the messages in its queue, reset its expected next sequence number, and send an acknowledging message to the sender. The sequence diagram for this situation is the same as for initializing a virtual channel.

The sequence diagram in Figure 17 below shows what happens if a receiver fails and restarts.

Figure 17 – Restart of failed receiver sequence diagram

1. A component sends a message with guaranteed delivery to another component, and that message arrives at the receiver.

2. The receiver has no virtual channel set up with the sender, so it sends a SPATransport message to the sender with a GDE Header in which the message type is GDE_NEGATIVE.

3. The sender sends a SPATransport message with a GDE Header in which the message type is GDE_RESET, and the sequence number in the header is the sender’s oldest sequence number in its queue of unacknowledged messages.

4. The receiver resets its expected next sequence number of the virtual channel to the value in the GDE Header from the sender. It notifies the sender that this has been done by sending a message with a GDE Header in which the message type is GDE_ACKNOWLEDGE. The acknowledgement header contains the size of the receiver’s queue for out-of-order messages.

5. The sender changes the sequence numbers of the messages in its queue after the oldest one, so they are sequential. The sender changes its sequence number to follow the last message in its queue. The sender then resends each of the messages in its queue.

Sender Receiver

1. Data

2. Negative

3. Reset

4. Acknowledge

5. Resend queued messages


58

5.3.7.3 Guaranteed Delivery Message

All SPA components shall be able to use the guaranteed delivery header, at least to say that they do not support the guaranteed delivery function.

The format for the Guaranteed Delivery message is shown below in Table 24.

Table 24 – SPA guaranteed delivery dxtended header message format

Message Name SPA Guaranteed Delivery Extended Header Message Opcode SPA Version 1 (Note: “1” indicates the initial version) Summary Description Indicates support to the Guaranteed Delivery Extended Header function

Field Name Size Offset Value Description Header Id 1 0 1 Guaranteed delivery extended header Id Header Size 1 1 2 Guaranteed delivery extended header Size Flags 2 2 n/a Guaranteed delivery flags Sequence 2 4 n/a Guaranteed delivery sequence reserved 2 6 n/a reserved

Name Header Id Description Guaranteed delivery extended header Id Full Description Unique numeric identifier of the guaranteed delivery extended header Size 1 Offset 0 DataType uint8 Units n/a DefaultValue 1 Range 1. 1 = guaranteed delivery

Name Header Size Description Guaranteed delivery extended header Size Full Description The number of data bytes in the guaranteed delivery extended header Size 1 Offset 1 DataType uint8 Units n/a DefaultValue 2 Range 2. 2 = guaranteed delivery data size in 4 byte words

Name Flags Description Guaranteed delivery flags Full Description Guaranteed delivery extended header flags Size 2 Offset 2 DataType uint16 Units n/a DefaultValue n/a

59

Range n/a Name Sequence

Description Guaranteed delivery sequence Full Description Guaranteed delivery extended header sequence Size 2 Offset 4 DataType uint16 Units n/a DefaultValue n/a Range n/a

Name reserved Description reserved Full Description reserved Size 2 Offset 6 DataType uint16 Units n/a DefaultValue n/a Range n/a

5.3.7.4 SPA Transport Message

The SPA Transport message is empty of application data, but it does contain headers, so it is useful for information that is only relevant to the transport layer. For example, the protocol for guaranteed delivery uses this message.

The format for the SPA Transport message is shown below in Table 25.

Table 25 – SPA transport message format

Message Name SPATransport Message Opcode 65 SPA Version 1 (Note: “1” indicates the initial version) Summary Description An empty message consisting only of headers

Field Name Size Offset Value Description n/a n/a n/a n/a

5.3.8 Security

This section describes the messages and protocols related to managing security. This information is not provided in this version of the SPA Logical Interface Standard.

5.4 Component Identification

This section describes methodology for identifying components.


60

5.4.1 Universally Unique Identification

Each component shall have a universally unique identifier called the SPA Identifier or CUUID. No two components in any SPA system, whether they are connected or not, shall share the same CUUID. The CUUID shall be used by the SPA services, and by application or mission-specific software to determine specific device type, manufacture date, component position, component calibration data, as well as other items. Its small fixed size of 128 bits makes it ideal for quick comparison and identification in a database.

To facilitate the rapid development of SPA components and promote interoperability, an algorithm exists such that two component vendors can independently generate the CUUID with an extremely low probability of them being the same.

SPA uses the industry standard for generation of universally unique identifiers that is documented in Request for Comment (RFC) document #4122, as well as an ITU-T recommendation and ISO/IEC Standard. These standards are technically equivalent with each other. RFC is an online repository of documents relating to internet protocols and standards maintained by the Internet Engineering Task Force (IETF). A sample implementation for the algorithm is included in RFC 4122.

Each software component shall also have a CUUID. In SPA, it is possible to take the same binary software executeable and run it on multiple machines, or multiple instances on the same machine. If the CUUID is embedded in the binary, then a CUUID conflict could arise. However, the benefits of having a persistent CUUID are plentiful. It is ultimately left up to the mission and or software application to determine how the CUUID is assigned. Some potential techniques to mitigate these issues are outlined below:

a) CUUID generated at compile time and stored inside the software executeable.

b) CUUID Type 3 or 5 generated at runtime based on application name, and processor CUUID

c) CUUID Type 3 or 5 generated at runtime based on application name and mission name

d) CUUID specified as an argument to application during startup.

5.4.2 xTEDS Identification

The xTEDS of a component specifies the interface of that component. During development, integration, and test the component xTEDS might change significantly. However, once on orbit, the xTEDS will more than likely not change. Components exchanging their xTEDS during startup or during ongoing negotiation can provides an important dynamic capability, but comes at a price. To optimize the exchange of xTEDS for configurations that are semistatic or have been locked down, there will be a unique identifier for each xTEDS.

The xTEDS Identifier (XUUID) shall be used to uniquely identify the entire xTEDS stream using a hash. If the xTEDS changes in even the slightest way, the identifier will change dramatically. This will allow the use of the XUUID to cache xTEDS and prevent the full exchange of them at startup or discovery.

The XUUID shall be generated following the same guidelines as the CUUID type 5. The algorithm is essentially to do a SHA-1 hash of the xTEDS, and use that to generate the CUUID as defined in IETF’s RFC 4122. This algorithm allows components to summarize their xTEDS, and allows other components to verify their cache xTEDS.