1. 850x0g2 Green Book Integrating the New SOIS Summary Diagram
SOIS Storyboard
850x0g2
Green Book
Integrating the New SOIS Summary Diagram

2. Motivation
At the Spring meeting there was a remark that we’re working without a plan in SOIS.
Of course, we do have a plan because we talk about planning issues in our meetings.
We just need to make the plan visible via publication.
The revisions to the 850 green book proposed in these viewgraphs is part of a strategy of publishing the plan.

3. SOIS Summary
This diagram names everything described by SOIS. (one-stop shopping, as Glenn would say)
Each term used in this diagram deserves an explanation in the green book text.
We should identify terms in green book that should be added to this diagram or discarded.

4. SOIS Issues
Some issues identified in the Spring meeting and in , will be described in the 850 green book.
A common pattern in the current green and magenta books is for SOIS services to provide an abstract interface for an underlying device or service. EDS can improve interoperability across these interfaces. This is a position that Jonathan and Glenn have advocated for a number of years.
A selection of composable protocol stacks for communication with onboard devices or external entities carry the <<std>> stereotype.
The idea of “flows” is new.
How can we organize the terms “device”, “application”, “service”, and “component”?
There are some patterns possible in organization of protocol stacks for subnet.
Lesser issues:
<<ext>> Application block is missing, with relations to other layers.

5. Issue 1. The General SOIS Service Pattern
Objects in interface are abstractions.
Objects in interface are concrete.
This pattern appears implicitly in every SOIS magenta book.
This is the chief complaint that I hear about SOIS.
Many SOIS services provide a minimal interface, which is intended to enable interoperability for applications across all implementations of the service.
Does this form of abstraction really make applications interoperable across many implementations?
The subsequent viewgraphs for this issue each represent a topic to be inserted into the green book, explaining a pattern of usage of EDS and tool chain in SOIS. The next three viewgraphs are patterns for the rest.
<<ext>>
Application
<<sois>> magenta book description
Objects unspecified in magenta book may be present in interface. (e.g., length)
Implements,
approximately
<<ext>>
Implementation
Objects specified in magenta book may be absent in interface. (e.g., origin)

6. Issue 1. Topic A. A General SOIS Device Pattern
<<ext>> Device
<<ext>>
Application
<<ext>>
EDS instance
specifies
describes
External devices provide a concrete interface.
A tool chain generates a service for the device, which communicates through SOIS subnet layer.
The device service conforms to the platform interface implementation, such as API or message bus.
This is a simplification of Richard’s work.
This pattern can be used for remote services on platforms that use API and lack a message bus.
<<derived>>
Device Service
<<sois>>
Subnet

7. Issue 1. Topic B. A General SOIS Software Pattern
<<ext>>
Application
Software objects provide a concrete interface.
A tool chain generates a wrapper for the software object, which
may consist of a compiled instance of the software object (wrapper is integrated in object),
or may contain a call to a library, or a call to an interpreter (wrapper is distinguished from object),
or may use other means.
The wrapper conforms to
the platform interface implementation, such as API or message bus,
and platform word sizes,
and mission parameters, such as array sizes and address ranges.
This is a simplification of Joe’s work. The wrapper is integrated into the object by compilation.
<<ext>>
EDS instance
specifies
<<derived>>
Specific Wrapper
describes
<<ext>>
Software Object

8. Issue 1. Topic C. A General SOIS Service Pattern
<<ext>>
Application
<<ext>>
EDS instance
describes
requires
The objective here is to apply EDS and tool chain to improve interoperability of applications across SOIS service implementations.
SOIS provides a set of EDSs in its magenta books, which describe abstract interfaces.
An implementation of a SOIS service is constrained by the SOIS EDS interface that it implements.
An application is written to be able to use the SOIS service interface that it requires, possibly adding constraints in its EDS.
A tool chain generates
a platform-specific wrapper for a SOIS service,
and optionally wraps the application for the platform and required interfaces.
This has not been tested for SOIS EDS.
<<sois>>
EDS instance
implements
<<ext>>
EDS instance
specifies
<<derived>>
Specific Wrapper
describes
<<ext>>
Software Object

9. Issue 1. Topic D. “Clock” of Summary Diagram
“Clock” corresponds to “3.3 Time Access Service” in green book.
Time Access Service will be explained in the context of externally provided functions using the “device” pattern.
This is the protocol diagram in the current green book, which is partially isomorphic with the RASDS function diagram in Issue 1 Topic A above.
The revised topic will include a similar (or identical) protocol diagram.

10. Issue 1. Topic F. “Subscription” of Summary Diagram
“Subscription” corresponds to “3.4 Message Transfer Service” in green book.
Message Transfer Service will be explained in the context of externally provided functions using the “SOIS Service” pattern.
There is no diagram for MTS in the current green book, but the AMS book provides the diagram shown here.
The revised topic will include a protocol diagram, which is comparable with the RASDS function diagram in Issue 1 Topic C.

11. Issue 1. Topic E. “File Storage” of Summary Diagram
“File Storage” corresponds to “3.5 File and Packet Store Services” in green book.
File and Packet Store Services will be explained in the context of externally provided functions using the “device” pattern.
This is the protocol diagram in the current green book, which is approximately isomorphic with the RASDS function diagram in Issue 1 Topic A above.
The revised topic will include similar (or identical) protocol diagrams.

12. Issue 1. Topic G. “Communications Services” of Summary Diagram
“Communications Services” corresponds to “4.2 SOIS Subnetwork Service Descriptions” in green book.
Packet Service, Memory Access Service, and Test Service will be explained in the context of externally provided functions using the “SOIS Service” pattern.

13. Issue 1. Topic H. “Management Services” of Summary Diagram
“Management Services” corresponds to “2.3 Management Concepts” in green book.
The “Management”, “Statistics”, “Discovery”, and “Test” of the Summary diagram are conflated in this topic in the green book.
Management Information Base (MIB) Service will be explained in the context of externally provided functions using the “SOIS Service” pattern.
There is no diagram for MIB in the current green book.

14. Issue 2. “Protocols” Blocks in Summary Diagram
“Convergence Protocols” and “External Protocols” in the Summary Diagram correspond approximately to “2.9.5 Subnet Services” in green book. The use of these concepts appears in other parts of the book.
The “Deployment Description” in the Summary diagram can describe composition of protocol stacks, using both <<std>> and <<ext>> layers.
Convergence and External Protocols will be explained in the context of externally provided functions using the “software” pattern, and the ISO OSI layer-N diagram shown here at top.
The diagram for composition of protocols in the current green book appears here at bottom.
The revised topic will use a similar protocol diagram.

15. Issue 2. Convergence Protocols for TTE Subnet
SOIS Convergence
Protocols for TTE
SOIS Convergence
Protocols
Issue 2. Convergence Protocols for TTE Subnet
Protocol Multiplexing
Protocol Multiplexing
Sequence Preservation
Sequence Preservation
Prioritisation
Prioritisation
TTE puts UDP/IP into subnetwork chips in order to fragment and reassemble packets in hardware
TTE layers appear in standard protocol box of new SOIS diagram.
SOIS convergence protocols are selected to complete the stack for standard expectations of application designers from SOIS.
Where low latency is wanted, SOIS convergence protocols can be bypassed.
Address translation by SOIS is between spacecraft network addresses and IP; address translation by TTE is between IP and MAC.
Elevation of SOIS Retry above segmentation results in full-packet retries instead of segment retries.
Address Translation
Address Translation
Resource Allocation
Retry
Segmentation
Integrity
Retry
Redundancy
Integrity
Address Translation
Redundancy
Provided
by TTE
Resource Allocation
Segmentation

16. Issue 2. Protocol Multiplexing
PDU
N+1
PDU
Protocol
Multiplexing
MIB SC Address/ Subnet Table N
PCI N
SDU N
PCI N
SDU
PCI is subnetwork protocol identifier.
Outbound:
PCI is calculated from MIB table that associates Spacecraft Network Address with subnetwork protocol identifier.
Spacecraft Network Address is destination address in N+1 PDU.
Layer sends N-1 PDU to top of stack for appropriate subnetwork, with protocol identifier if subnet needs it.
Inbound:
Layer receives N-1 PDU from top of stack for a subnetwork.
PCI is fixed for subnet, or subnet provides it in N-1 PDU.
Layer sends SDU as N+1 PDU to appropriate higher-level protocol layer.
This layer forks the protocol stack for a subnetwork upward. N
PDU N
PDU
N-1
PDU
N-1
PDU

17. Issue 2. Sequence Preservation
PDU
N+1
PDU
Sequence
Preservation
MIB out-of-sequence buffer size N
PCI N
SDU N
PCI N
SDU
PCI is sequence number.
Outbound:
Layer sends N-1 PDU containing sequence number.
Inbound:
Layer receives N-1 PDU containing sequence number.
Layer optionally buffers until gap in sequence numbers is filled or timeout or overflow.
Layer discards out-of-sequence PDU’s.
MIB:
To avoid variable delays, specify zero buffer size. N
PDU N
PDU
N-1
PDU
N-1
PDU

18. Issue 2. Prioritisation N+1 PDU N+1 PDU Prioritisation N SDU N SDU
PCI is null.
Priority is in all PDU’s.
Outbound:
Layer receives N+1 PDU into priority queue.
When more than one item is in queue, layer sends highest priority first, otherwise maintaining order of arrival in queue.
Inbound:
Layer receives N-1 PDU into priority queue.
Priority Queue
Priority Queue N
PDU N
PDU
N-1
PDU
N-1
PDU

19. Issue 2. Address Translation
PDU
N+1
PDU
Address
Translation
MIB SC Address/ Subnet Address Table N
PCI N
SDU N
PCI N
SDU
PCI is subnetwork address of destination.
Outbound:
PCI is calculated from MIB table that associates Spacecraft Network Address with subnetwork address.
Spacecraft Network Address is destination address in N+1 PDU.
Layer sends N-1 PDU to top of stack for appropriate subnetwork, with subnetwork address of destination.
Inbound:
Layer receives N-1 PDU with subnetwork address of source.
Layer computes Spacecraft Network Address from source subnetwork address and MIB table.
Layer sends SDU as N+1 PDU with spacecraft network address of source. N
PDU N
PDU
N-1
PDU
N-1
PDU

20. Issue 2. Resource Allocation
PDU
N+1
PDU
Resource
Allocation
MIB Subnet Address / Subnet Channel Table N
PCI N
SDU N
SDU
PCI is subnet channel identifier.
Outbound:
PCI is calculated from MIB table that associates Subnet Address with subnetwork channel identifier.
Subnet Address is destination address in N+1 PDU.
Layer sends N-1 PDU with information to put it in the correct queue for its channel.
Inbound:
Layer receives N-1 PDU.
PCI is null for inbound.
Layer sends SDU as N+1 PDU. N
PDU N
PDU
N-1
PDU
N-1
PDU

21. Issue 2. Segmentation N+1 PDU N+1 PDU Segmentation
MIB Subnet Maximum PDU N
PCI N
SDU N
PCI N
SDU
PCI is segmentation header.
Outbound:
Layer divides N+1 PDU into segments that fit in maximum PDU for subnet.
Layer sends segments as N-1 PDUs.
Inbound:
Layer receives segments as N-1 PDUs.
Layer collects segments in assembly buffer until N SDU is complete or timeout.
Layer sends complete SDU as N+1 PDU.
This can reorder the N+1 PDUs.
Layer discards incomplete SDU, and might notify an adjacent layer.
MIB:
Maximum PDU could be chosen to minimize the scheduling effect of unusually large PDU’s, which could otherwise be transmitted by the subnet. N
PDU
Assembly Buffer N
PDU
N-1
PDU
N-1
PDU

22. Issue 2. Retry N+1 PDU N+1 PDU Retry
MIB QoS for destination; UnAck Buffer Size N
PCI N
SDU N
PCI N
SDU
PCI is retry header and QoS.
Outbound:
For best effort QoS, the N SDU passes through to N-1 PDU.
Otherwise, layer keeps segment in buffer until acknowledged.
Layer may receive N+1 PDU which is notification from segmentation layer that an SDU will time out, identifying missing segments, in which case layer sends N-1 PDUs with retry header identifying segments to be resent.
Inbound:
Layer may receive N-1 PDU with retry header identifying segment to be resent, in which case layer finds segment in unacknowledged buffer and sends it outbound.
Layer may receive N-1 PDU from integrity layer indicating segment received in error, in which case the layer sends request to resent outbound.
Layer may receive N-1 PDU with acknowledgement, in which case it removes the segment from the buffer.
Layer may receive normal N-1 PDU without retry header, in which case it sends SDU as N+1 PDU. N
PDU
Unacknowledged Buffer N
PDU
N-1
PDU
N-1
PDU

23. Issue 2. Integrity N+1 PDU N+1 PDU Integrity N PCI N SDU N PCI N SDU N
PCI is some kind of redundancy check.
Outbound:
PCI is calculated from N SDU.
Layer sends N-1 PDU with redundancy check.
Inbound:
Layer receives N-1 PDU with redundancy check.
Layer computes PCI and compares with redundancy check.
Layer sends SDU as N+1 PDU if it’s OK; otherwise, it sends a request for resend to retry layer. N
PDU N
PDU
N-1
PDU
N-1
PDU

24. MIB network topology, schedule, and policy.
Issue 2. Redundancy
N+1
PDU
N+1
PDU
Redundancy
MIB network topology, schedule, and policy. N
PCI N
SDU N
PCI N
SDU
PCI is alternate paths header.
Outbound:
If there is only one path, layer sends N PDU straight through.
Otherwise, if policy is to send on all paths, layer sends N PDU on all paths.
Otherwise, if policy is to use alternate path to resend, layer uses alternate path only if retry header indicates resending.
Inbound:
If policy is to send on all paths, layer discards messages arriving on alternate paths after the first to arrive.
Layer uses sequence buffer to record what sequence numbers to discard, and lower bound on sequence numbers to keep.
Layer may receive normal N-1 PDU without alternate paths header, in which case it sends SDU as N+1 PDU. N
PDU
Sequence Buffer N
PDU
N-1
PDU
N-1
PDU

25. Issue 3. Topic A. “flows” in Summary Diagram (Addressing)
“Flows” in the Summary Diagram corresponds approximately to “2.8 Naming and Addressing” in green book. The idea of flow ids is new to the green book, and replaces the abstract entity identifiers and spacecraft network addresses.
The addressing by flow id may be one-way, source to destinations (is it so?):
Flows from an application may go to multiple subnetwork addresses, subnetwork multicasts, and applications,
while flows from a device or application may go to multiple processors and application entities.
Flows to and from a single device pass through the device service.
Can a flow have an unspecified source?
This is a diagram that summarizes addressing in the current green book. The revised topic will
replace DVS and DAS with a device identifier that maps to a device access service,
and include subnetwork multicast in subnetwork addresses,
and replace spacecraft network address with flow id,
and allow applications to address applications.

26. Issue 3. Topic B. “flows” in Summary Diagram (Implementation)
The “Deployment Description” in the Summary diagram can provide a table that maps flow ids to sets of subnetwork addresses, sets of subnetwork multicasts, and sets of application entities.
Part of the addressing table for flow id may be engineered into the multicast model provided by a subnetwork, or into the addressing table where there is no messaging service.
Part of the addressing table for flow id may be dynamically implicit in the publish-subscribe state of the optional messaging service. Should flow-id’s be used in pub/sub message bus?
The diagram shown here summarizes how the transport layer participates in addressing in the current green book. The revised topic will
rename “Transport Layer” to “Transfer Service”,
and Transfer Service will call packet service, memory access service, and test service.
The subnet layer works in a way that uses subnetwork multicast capabilities to implement flows with the minimal number of calls to the subnetwork.

27. Issue 4. Terminology of Endpoints in Communication
I use “endpoint” in descriptions of participants in communications.
Issue 4. Terminology of Endpoints in Communication
During the spring meeting, it was proposed that “application”, “device”, and “service” are all derivatives of “component”.
Later in the meeting, “device” was made a peer of “component” in order that “component” corresponds to the concept of the same name in EDS.
In subsequent s, this diagram was proposed, and then “entity” was retracted.
In writing about this topic, it is useful to have a collective term that represents any endpoint of communication, like “entity” in the diagram. I have been using “endpoint” as this term, because it corresponds to similar usage in terrestrial communication networks.
The term “application” seems not necessarily to differ from “service”; I’m using it as a synonym for “service” in contexts where I want to emphasize the OSI protocol layer in which it operates.
I use “application” as a synonym of “service”.

28. Issue 5. Patterns for Protocol Stacks in Subnet
An external protocol may be implemented in a device, using simpler onboard protocols to communicate with the device. See upper diagram, but delete the “Space Network Protocols (e.g., Space Packet)” box.
An external protocol may be imbedded in the SOIS subnet protocol stacks, if it is not provided by the device nor by the subnetwork that attaches the device. See lower diagram.

29. Classes of SOIS Services
The following viewgraphs identify classes of services, which enumerate some features planned for SOIS implementations.
The classes are not new concepts, they are just a restatement of old concepts in the present green book.
The restatement emphasizes the possibility that EDS definitions of individuals in these classes can provide a few different versions of the same class of interface which are repeatable targets of agency designs.
The EDS definitions fall into one of the three patterns for EDS usage outlined in topics A, B, and C of Issue 1 at the beginning of this deck of viewgraphs.

30. SOIS Class: Application Support Service
Services not associated with an onboard device
Examples:
Data Pooling Service
Publish/Subscribe Message Bus

31. SOIS Class: Device Service
Service directly related to an onboard device
Examples:
Device Access Service
Device Virtualization Service
Time Access Service
File and Packet Store Service

32. SOIS Class: Communications Service
Services that represent a flow of communications with a device
Examples:
Packet Service
Memory Access Service
Synchronization Service
Test Service

33. SOIS Class: Management Service
Services that manage and monitor communication flows with onboard devices
Examples:
Management Information Block
Statistics
Device Discovery Service

34. SOIS Class: Convergence Protocol
Standardized interfaces that can be layered on top of other protocols
Examples:
TCP IP
UDP
RMAP
ECSS.1553

35. SOIS Class: External Protocol
Lowest level standard interfaces to a device
Examples:
Wireless
SRIO
CAN
SpaceWire
Milbus
SpaceFibre
TTP
ARINC 653
TTE
Ethernet

36. SOIS Class: Device Datasheet
Model of a data interface of a device or service
Contents:
Commands
Parameters
Types
Encodings
Behavioral mappings
Calibrations
Derivations
limits

37. SOIS Class: Deployment Description
Model of the onboard platform
Contents:
Networks
Links
Flows
Routing
Nodes
Addresses
Schedules
Configuration
partitions

38. SOIS Class: Dictionary of Terms
Terms used by datasheets and deployments
Contents:
Semantics
Units
Reference frames
Timings
Quality of Service

39. SOIS Class: Device External entity accessed via subnetwork layer
Examples:
Hardware
Emulated hardware
External software

40. SOIS Class: Onboard Platform
One or more processors that execute the logic for a mission, using one or more paradigms for local communication between endpoints:
API
Message Bus