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

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

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

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

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

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

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

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

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

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

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-50-13 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

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

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

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

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

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-50-13 directives on usage of subaddresses by not ‘occupying’ sub-addresses allocated for other services CCSDS Meetings – Spring 2009

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-50-13 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

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-50-13 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

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

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

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

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

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

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

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

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-50-13 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

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-50-13 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

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

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

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

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

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

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

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

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

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

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

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

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-50-13 compliant systems, the EDS will be read using the ‘Data Acquisition’ service but a controlling sub-address is still needed CCSDS Meetings – Spring 2009

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

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