1. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Device and Service Discovery An example of an adaptation model for MILBUS (On ECSS-E Compliant System)
Massimiliano Ciccone
ESA/ESTEC
20-April-2009
CCSDS Meetings – Spring 2009

2. SOIS PnP Service Architecture
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Service Architecture
CCSDS Meetings – Spring 2009

3. SOIS PnP Service Architecture
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Service Architecture
1) Device becomes operational and is discovered by DDS
2) Relevant services informed of new device (Subnetwork address) and DES assigns a SOIS global address
4) Device data sheet (EDS) is read via DAS and new SOIS Address-EDS entry stored within Dev. Enum. Table
Device Enum.
Table
Virtual Drivers
Table
5) DES informs DVS of new device type-model and its provided services
6) DVS loads ‘generic’ communication profile of new device (e.g. from Virtual Drivers lookup table)
7) Users Application can now access the new ‘GENERIC’ device from the DVS
CCSDS Meetings – Spring 2009

4. SOIS PnP Functions Device Discovery:
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Functions
Device Discovery:
DDS discovers added/removed devices (subsystems)
DDS informs relevant services (DES and NMS) on added or removed devices (Subnetwork Address)
Service Discovery:
Discovers and enables use of capabilities of added devices and notifies it to relevant PnP services and higher layers. Associated Services are:
Device Enumeration Service (DES) manages the discovery of the capabilities of an added device and its insertion into the SOIS communications architecture. Moreover, it is responsible of the removal of communication profile for devices detaching from the PnP network.
DES uses DAS (MAS and PS) to gather service description “Value” (Device Electronic Data Sheet) of new elements on the bus
Device Adaptation:
DVS retrieves and allocates the proper generic communication profile to new device (i.e. Standard Driver)
Meet current needs
Be scalable
Adaptable to different missions
Be adaptive and evolutive to meet future needs
Modular
Simplifies integration and testing
An enabling technology for “advanced” software architectures
CCSDS Meetings – Spring 2009

5. Device Discovery Process
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Device Discovery Process
The method used by the DDS to discover new devices depends on the characteristics of the underlying bus:
- Bottom-up (event-driven)
- Top-down (Bus master polling devices)
In 1553 BC is the sole source of communication; therefore the DDS must adopt the top-down approach; The BC must poll for new devices attached on the bus
The new device(s) coming on-line might not be smart enough to run DDS (i.e. RT embedded in a dumb sensor).
Hence DDS P2P communication protocol (BC <---> RT) not possible:
SOIS-DDS shall run on BC side only (Asymmetric Communication Model), but it needs to be supported at RT side.
CCSDS Meetings – Spring 2009

6. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Use Case 1/2
Pre-condition: The DDS running at BC side periodically polls for new RTs attached on the MIL-1553 bus.
CCSDS Meetings – Spring 2009

7. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Use Case 2/2
EVENT: New RT becomes operational on the BUS
Post-condition If a DDS is running, this condition will trigger the following actions: 1)
The new RT responds to the DDS polling request by sending device descriptors 2)
The DDS discovers the new RT and all the device(s) attached to it
CCSDS Meetings – Spring 2009

8. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Mapping ASSUMPTIONS
No assumptions are made on the status of the bus nodes and possible upcoming events
Arbitrary network topology changes can occur at any time due to failures or user intervention
Devices or subnets can be plugged and unplugged to/from any RT of an existing network at any time
New devices plugged may not be in reset status.
Multiple devices with the same hardware configuration may be present on the same bus
CCSDS Meetings – Spring 2009

9. MIL-STD-1553B PnP Relevant Capabilities
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
MIL-STD-1553B PnP Relevant Capabilities
Each RT has 30 sub-addresses reserved for data transfers
The other two sub-addresses (0 and 31) are reserved for mode codes used for bus control functions
Each of the 30 sub-addresses has a receive and a transmit buffer of 32 words (16 bits)
There is no specific support for PnP in the MIL-STD-1553B standard. The physical and data link layers of the 1553 bus are well defined by the standard but there are several usage variants.
The MIL-STD-1553B standard provides no guidance on using sub addresses: assignment of sub addresses and their function (data content) is left to users
CCSDS Meetings – Spring 2009

10. The ECSS Extension to the MIL-STD-1553B Standard 1/2
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
The ECSS Extension to the MIL-STD-1553B Standard 1/2
So far, the common practice has been to develop, for each new spacecraft, a different set of services and communication protocols on top of the MIL-STD-1553B standard to perform common tasks.
Since December 2005, the European Cooperation for Space Standardisation (ECSS) MIL-STD-1553B Extensions working group (ECSS-E-50) task has been to identify best practices for harmonization of the 1553 bus use, in order to capitalize the acquired experience on the usage 1553-based spacecraft systems
CCSDS Meetings – Spring 2009

11. The ECSS Extension to the MIL-STD-1553B Standard 2/2
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
The ECSS Extension to the MIL-STD-1553B Standard 2/2
The working group goal was therefore to define a standard set of services and protocols based on the existing MIL-STD-1553B standard by:
Adapting requirements from existing space projects and taking into account existing 1553-based communication devices
Providing for the sub-network services defined by CCSDS/SOIS
In November 2008, the first version of the ECSS standard was issued: ECSS-E-ST Draft C
This standard defines specific details for the Data Link layer of the MIL-STD-1553B that are relevant to SOIS-PnP
CCSDS Meetings – Spring 2009

12. Example of an ECSS-E-ST-50-13 Based System
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Example of an ECSS-E-ST Based System
CCSDS Meetings – Spring 2009

13. ECSS Allocation of RT Subaddresses
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
ECSS Allocation of RT Subaddresses
SA 0;8 are not used
SA 1;30;31 are allocated to mandatory ECSS services
SA 11 to 28 are allocated to optional ECSS “Data Transfer” services
SA 29 is allocated to optional ECSS “Time” service
CCSDS Meetings – Spring 2009

14. Proposed 1553-DDS Adaptation Model
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Proposed 1553-DDS Adaptation Model
The BC sends a ‘transmit’ command word message to the entire RT address range (0-30) for transmitting PnP Descriptors of attached devices
The receiving terminal validates error free cmd msg reception by transmitting a status word with info on its health
The failure (or off-line status) of a RT is detected, upon polling, by the lack of status word response transmission (i.e. validation of transmit command issued by BC)
CCSDS Meetings – Spring 2009

15. DDS Model Sequence Diagram
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
DDS Model Sequence Diagram
CCSDS Meetings – Spring 2009

16. PnP Subaddress Usage for ECSS Compliant Systems
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
PnP Subaddress Usage for ECSS Compliant Systems
The implementation of the ECSS RT Health Monitoring service requires at least two words of the Transmit buffer of SA 1 memory area
Hence, using the remaining 30 words of SA 1T for storing RT’s PnP descriptors appears to be the best choice.
This choice will be in line with ECSS-E directives on usage of subaddresses by not ‘occupying’ sub-addresses allocated for other services
CCSDS Meetings – Spring 2009

17. Use of SA 1T for DDS (Example)
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Use of SA 1T for DDS (Example)
Taking into account the 2 data words reserved for ECSS-E Services (N. 0 and 1), there are 30 data word available in SA 1T for storing PnP-DDS information
Fixing the size of each PnP Device descriptor to one word (16 bits) will allow storing a maximum of 30 different PnP descriptors in the RT SA 1T memory, by using 30 data words (word = 16 bits ) from word 2 to word 31
CCSDS Meetings – Spring 2009

18. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Proposed DDS Protocol
The DDS at BC side periodically polls all the Terminals issuing a ‘Transmit’ command word for SA 1T. This command will ask the polled RT to transmit the entire block of 32 Data Words from SA 1T, which is the subaddress, identified in this example model, to be used for exchanging DDS protocol elements.
Upon reception of the BC command, all the operational RTs will then transmit back a status word response followed by 32 data words containing basic information on the RT itself and on all devices attached to it:
Word 0 and 1 will contain Health Monitoring data as described in the ECSS-E standard
The remaining 30 data words of SA 1T will contain PnP descriptors for each attached device according to the DDS protocol
CCSDS Meetings – Spring 2009

19. DDS PnP Device Descriptor Data Format
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
DDS PnP Device Descriptor Data Format
The PnP descriptor of each device needs to specify “at least” Class, Model and unique Device ID within the RT.
The Device SA flag field acts as a presence flag; if set to 1, indicates that a device with ID equal to the position of the SA 1T data word being parsed is attached and operational.
CCSDS Meetings – Spring 2009

20. DDS Mapping Prerequisites
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
DDS Mapping Prerequisites
All the PnP-enabled RTs on the S/C (opeational and non operational) must have a unique pre-assigned address to avoid conflicts.
As an alternative, all non operational RTs can have a standard PnP RT address assigned. This address will then be dynamically programmed by DDS when the new RT comes on line.
A logic at the RT side shall be in charge of surveying the attached device(s) and update the RT memory on their type and status. The way the RT controller performs this operation is outside the scope of the SOIS-PnP standards
The DDS running at the BC side shall keep an up to date list of all the devices discovered on the bus. By comparing the latest list of devices retrieved with the one resulting from the previous polling loop, the DDS will then be able to understand if a new device has been added or if an existing one has been removed
CCSDS Meetings – Spring 2009

21. What After Discovering a Device ?
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
What After Discovering a Device ?
DDS passes Class and Type of the discovered device to the Device Enumeration Service, to be used as a key for retrieving (together with complementary SOIS PnP services) info on the service provided by that particular device and loading its complete communication profile.
Two options are being evaluated to implement the service discovery capability:
Maintain a Device Database and use device class and type as lookup keys
Use Electronic Data Sheets (EDS) embedded in the device and acquired using DES
The EDS solution has been selected for this mapping example
The device EDS can be stored either within the device itself and dynamically read when required, or within the DES (e.g. in a Device Enumeration Table).
An EDS contains both generic information about the type of component and the services it provides, but also can include calibration, maintenance history, technical orders, and other useful information (i.e. Communication Profile)
CCSDS Meetings – Spring 2009

22. SERVICE DISCOVERY PROCESS
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SERVICE DISCOVERY PROCESS
The main purpose of the Service Discovery is to manage the discovery of the capabilities of an added device and its insertion/removal into/from the SOIS communication architecture
The associated service is Device Enumeration Service (DES)
For this example it is assumed that:
EDS device information may be stored in either in the RT or in the device memory and it is possible to map that information onto the MIL-STD-1553B terminal buffers.
SOIS DAS service uses SOIS PS to retrieve the EDS data (e.g. xTEDS). Using PS (instead of MAS) there is no need to know the address where the EDS data is stored in the RT
SOIS Subnetwork Packet Service is mapped onto the ECSS E-ST-50-13C ‘Data Block Transfer Service’
CCSDS Meetings – Spring 2009

23. Proposed 1553 Service Discovery Adaptation Model
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Proposed 1553 Service Discovery Adaptation Model
DAS send an Acquire_From_Device.request (device_id and value_id) to the RT by means of MAS (writing in words 2-3 of the RT SA1 Receive buffer memory)
The device id identifies the device for which we want to read the EDS file and the value id identifying EDS
The PnP RT understands the request and prepares the EDS data to be transmitted to BC using the ECSS E-ST-50-13C Data Block Transfer service
DAS service will then receive the EDS file data units from the Packet Service (mapped to ECSS E-ST-50-13C Data Block Transfer service)
DAS Assembles the EDS and hands it to complementary SOIS PnP Services
CCSDS Meetings – Spring 2009

24. EDS Acquisition Model Sequence Diagram
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
EDS Acquisition Model Sequence Diagram
CCSDS Meetings – Spring 2009

25. Use of RT SA 1R for Service Discovery (Example)
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Use of RT SA 1R for Service Discovery (Example)
DAS needs to inform the RT (BC receive cmd) of which information wants to retrieve and map this service using the available ECSS E-ST-50-13C subaddresses. Table below shows the format of sub-address 1R according to ECSS E-ST-50-13C (Left) and the mapping of DAS onto it (Right).
Word No
Data
Reset RT_Health command 1
Reset Services command
2-3
Device Access Service 4 … 14
Command Extension 15 31
RT Configuration Parameters
Word No
Data
Reset RT_Health command 1
Reset Services command 2 … 14
Command Extension 15 31
RT Configuration Parameters
CCSDS Meetings – Spring 2009

26. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
IDENTIFIED ISSUES
SOIS DDS and DAS(PS)-Service Discovery define a generic service interface but do not define common data formats and protocols for specific bus adaptation (magenta book ?)
The same way as for DDS, Service discovery for MIL-STD-1553B would benefit from the allocation of a standard RT sub-address for conveying an EDS reading protocol, possibly trough the DAS (making use of the MAS or PS)
In ECSS-E-ST compliant systems, the EDS will be read using the ‘Data Acquisition’ service but a controlling RT sub-address would still be needed
Define a standard device memory location and a common SOIS format (e.g. xTEDS) for EDS ?
EDS value ID is a standard or managed parameter ?
For 1553-PnP systems, SOIS should take into account the sub-addresses allocation of ECSS-E-ST-50-13
CCSDS Meetings – Spring 2009

27. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
CONCLUSIONS
To achieve ‘real’, wide-common PnP for 1553 units, SOIS needs to define guidelines for the provision of the DDS and service discovery onto the MIL-STD-1553B bus
Not having CCSDS-SOIS defining guidelines (e.g. standard data formats and protocols) for Device and Service discovery could result in incompatibility of different PnP equipment and OBSW, which defeats the main purpose of PnP
The SOIS-PnP WG shall define a standard location within the RT memory where to store device(s) PnP info, together with a common protocol and data format for device and service discovery, possibly taking into account sub-addresses usage in ECSS-E standard
It is up to the SOIS-PnP WG (in coordination with ECSS) to devise the solution which is most flexible and that brings less overhead for the RT controller logic
CCSDS Meetings – Spring 2009

28. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
END
CCSDS Meetings – Spring 2009

29. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
BACKUP
CCSDS Meetings – Spring 2009

30. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
1553 Terminology
Subsystem: The device or functional unit receiving data transfer service from the data bus
Terminal: The electronic module interfacing the data bus with the subsystem and vice versa
The standalone RT is just the electronics necessary to transfer data between the data bus and one or more subsystem(s).
The embedded RT consists of interface circuitry located inside a sensor or subsystem directly connected to the data bus
CCSDS Meetings – Spring 2009

31. Example of DDS Scheduling on MILBUS
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Example of DDS Scheduling on MILBUS
A specific PnP minor frame has been defined for the BC containing all the 1553 transfers related to DDS
(i.e. transmit command for SA 1T for all addressable RTs)
CCSDS Meetings – Spring 2009

32. Mapping DDS onto 1553 TEC-EDD (CCSDS-SOIS PnP on MILBUS)
CCSDS Meetings – Spring 2009

33. Retrieving Attached Device(s) Info
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Retrieving Attached Device(s) Info
Case 1:
A specific standard RT sub address is used to convey PDUs of an higher level protocol between DDS at the BC side and the RT controller logic
Pro: Scalable. No limit on the number of attached devices
Cons: Overhead. Puts constraints on the RT controller logic
CCSDS Meetings – Spring 2009

34. Retrieving Attached Device(s) Info
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Retrieving Attached Device(s) Info
Case 2:
A specific standard RT sub address is used by BC to read number of attached devices and a set of subsequent sub addresses for directly storing info on device(s) type
Pro: Low overhead. Less constraints on the RT controller logic
Cons: Not scalable. The number of attached devices that can be discovered depends on the available sub addresses
CCSDS Meetings – Spring 2009

35. Embedded RT TEC-EDD (CCSDS-SOIS PnP on MILBUS)
CCSDS Meetings – Spring 2009

36. ECSS Mandatory Services
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
ECSS Mandatory Services
There are 5 subaddresses reserved or allocated for mandatory services:
SA 0, SA 8 are not used.
SA 1T reserved to Health Monitoring service and SA 1R to Terminal Configuration service.
SA 30 reserved for the Data Wrap Around service.
SA 31 reserved for Mode Code Commands
CCSDS Meetings – Spring 2009

37. Optional ECSS Services
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Optional ECSS Services
Not all the services defined by ECSS are mandatory. In fact, the ECSS standard also states that:
For a given RT, all unused subaddresses can be used for the Get Data and Set Data services if necessary
For units not following this standard concerning the Data Block Transfer service (i.e. from SA 11 to SA 28) the subaddress allocation can be different
For a specific RT supporting the Data Block Transfer service but not using all the reserved subaddresses for this service, the unused reserved subaddresses may be allocated to other purposes (e.g. PnP Device data transfer)
In case Time Distribution service is not used, SA 29 shall not be used
CCSDS Meetings – Spring 2009

38. Device Virtualization Service
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Device Virtualization Service
Provides standard interface to virtual, i.e. generic, image of a physical device
Service user interacts with virtual image of the physical device and service handles translation of commands to the virtual image into commands to the physical device, and vice versa for data
Allows for application to be implemented to interact with “standard” devices, with the service providing the translation into particular devices
Replacement of a particular device type only requires modification to the service and not the application
Class hierarchy of devices
Starting point for class hierarchy is the ETSI/ECSS SSDHI Standard
Open Issues:
Standardisation is still at an early stage
As you can see, I view it in two parts:
1. A generic mechanism/framework for defining a hierarchy of classes of devices
2. Standardisation of a number of device classes (with room for extensions, additions etc)
CCSDS Meetings – Spring 2009

39. TEC-EDD (CCSDS-SOIS PnP on MILBUS)
The same way as for DDS, Service discovery for MIL-STD-1553B would need the allocation of a standard RT sub-address for conveying an EDS reading protocol, possibly trough the DAS making use of the MAS.
In ECSS-E-ST compliant systems, the EDS will be read using the ‘Data Acquisition’ service but a controlling sub-address is still needed
CCSDS Meetings – Spring 2009

40. SOIS PnP TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Use Case 2: Just before launch
Launcher OBC is attached to a EGSE system prior to lift-off.
Few seconds before launch EGSE is detached and
EGSE (BC) periodically polls
RTs Using broadcast
Service (Addr 31)
EGSE processor
(BC)
Launcher OBC
(RT)
Prior to launch:
Spacecraft bus
MIL-1553 RT RT RT
Few secs before launch:
When EGSE detaches
the Launcher’s OBC
becomes the MIL bus BC
EGSE processor
(RT)
Launcher OBC
(BC)
Spacecraft bus
MIL-1553 RT RT RT
Identified issues: Safety; Robustness; Reliability; Repeatability
CCSDS Meetings – Spring 2009

41. SOIS PnP TEC-EDD (CCSDS-SOIS PnP on MILBUS) Use Case 3: In Flight
Lander and Rover attached during cruise phase and detached after landing using Lander OBC only prior to landing
BC periodically polls
RTs Using broadcast
Service (Addr 31)
Lander OBC
(BC)
Rover OBC
(RT)
Prior to landing:
Spacecraft bus
MIL-1553 RT RT RT RT RT RT
After landing:
When Rover detaches its OBC
becomes BC for the rover bus
Lander OBC
(BC)
Rover OBC
(BC) RT RT RT RT RT RT
Spacecraft bus
MIL-1553
Identified issues: Robustness; Reliability
CCSDS Meetings – Spring 2009