& Mapping of the Device Discovery service onto the MIL-STD-1553 SOIS P&P Concepts & Mapping of the Device Discovery service onto the MIL-STD-1553 Massimiliano Ciccone ESA/ESTEC 02-Oct-2007 (CCSDS-Darmstadt)

Summary Why PnP ? Use cases Identified issues for mapping the Device Discovery Service (DDS) over the 1553B bus Recap of main PnP architecture, mechanisms and requirements Planned prototyping activities at ESA

Why PnP ? A spacecraft could be built using ready-to-integrate components that can be assembled together with minimal human intervention Higher reliability of Spacecraft by eliminating SW/HW configuration error Increased robustness due to hot-swappable components to be used in case of failure of nominal ones. Easier and more flexible AIT process thanks to self-configuring flight systems

SOIS PnP Use Case Before: After: - New data system is added or existing ones relocated - Some data system that are only used during AIT are removed before launch BC periodically polls For new RTs on the bus New RT (embedded or stand alone) OBC (BC) Before: DDS RT Spacecraft bus MIL-1553 RT RT Subsystem with Embedded RT capability RT Subsystem Subsystem(s) After: The OBC discovers the new device. Device is catalogued and relevant services are updated OBC (BC) RT RT RT RT

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

PnP Prerequisites The method used by the DDS to discover new devices/subsystems depends on the characteristics of the underlying bus Two methods: Bottom-up (event-driven) Top-down (Bus master polling devices) It shall be possible to distinguish when the bus node is on/off line AND when subsystem(s) attached to node are on/off line

DDS Issues The new device coming on-line might not be smart enough to run DDS (RT embedded in a dumb sensor): DDS P2P communication not possible Where do we store device ID info ? 1553 RTs can store only minimum amount of info on attached subsystems: What if multiple subsystems are interfaced to a single RT ?

RT Interfacing multiple Subsystems

Mapping DDS onto 1553 In 1553 BC is the sole source of communication (cmd/response method); therefore the DDS must adopt the top-down approach On the 1553 bus the device discovery mechanism has to be centralized; that is the BC must poll for new devices attached on the bus The BC sends messages to a RT by mean of a command word The receiving terminal validates error free msg reception by transmitting a status word with info on its health

Mapping DDS onto 1553

Mapping DDS onto 1553 For a terminal to be considered operational, it has to: Be powered up Start and complete its internal self-test (Standalone RT only) The system attached to the RT needs to be initialized by the BC with aperiodic operations. Then, if necessary, the BC can begin periodic message communication with the new RT in the loop

Mapping DDS onto 1553 Sequence of mode codes cmds: Transmit Status Word (Discovers the new RT) Initiate Self Test : initiates built-in-test (BIT) circuitry within a remote terminal (Completed within 100 milliseconds) Transmit BIT Word: yields the results of the BIT

Mapping DDS onto 1553 The BC shall poll the all RT address range (0-30) with a ‘Transmit Status’ mode cmd This cmd shall cause the RT to transmit the status word associated with the last valid cmd A new RT coming on-line is detected by receipt of status word from the polled terminal The failure or off-line status of a RT is detected by the lack of status word transmission from the terminal upon polling But this only discovers new nodes on the bus, does not discover the attached subsystem(s)…

Mapping DDS onto 1553 A unique standard transmit terminal sub-address must be selected to provide profile of attached subsystem(s) (Electronic Data Sheet) Some kind of intelligence needed at RT side to update info on attached subsytem(s)

SOIS PnP Service Architecture 1) Device discovered and operational 2) Network Manager assigns a SOIS address to new device 3) Relevant services informed of new device (SOIS address-physical address) 4) New 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 (SOIS address, class-subclass, Vendor ID) 6) DVS loads communication profile of new device (from Virtual Drivers lookup table) 7) Users Application can now access the new device from the DVS

SOIS PnP Mechanisms Discovery: DDS discovers new devices (subsystems) when they come on-line or go off-line DDS tests correct device operation and informs relevant services (DES and NMS) Enumeration: DES uses DAS to gather description (Device Data Sheet) of new elements on the bus Cataloguing: Device Virtualisation Service retrieves and stores the proper Communication profile of new device 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

Device Electronic Data Sheet Shall contain: Device Class Device Subclass Vendor ID Device communication type (R-W-RW) ? This information is read and stored by the DES (Device Enumeration Table) and used by the DVS to retrieve complete communication interface data for each device in the SOIS domain from a lookup table (Virtual Drivers Table)

SOIS PnP Lookup Tables Device Enumeration Table: Virtual Drivers Table: Class, Subclass, Vendor ID SOIS Address Class, Subclass, Vendor ID Virtual Driver ID

Identified issues The PnP-1553B polling process should not be invasive. That is it shall not affect the real-time constraints of the OBSW The DDS user must have a mean to start/stop the polling of devices and to set up polling frequency (MIB values or primitives ?) The DAS shall have a Read_EDS primitive request Agree on standard 1553 RT sub-address for reading device profile Agree on standard set of 1553 mode codes for device discovery Define a common SOIS format for device EDS

ESA Prototyping Activities SOIS PnP will be prototyped at ESTEC over the RASTA reference facility with DDS adaptation over 1553B and Spacewire busses

Backup

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)

SOIS PnP 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

SOIS PnP Use Case 3: In Flight Prior to landing: After landing: 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

What is SOIS? A spacecraft construction kit The Software World SOIS Attitude Control Health Monitoring Autonomy Thermal Control SOIS Providing Standardized On-board Services and Interfaces Dwell on this: Emphasise the split between the two worlds of hardware and software Hardware world is fairly static – evolutive change severely constrained by the environment and technologies available Software world is capable of providing solutions and is raring to go but meets behavioural resistance – conservatism SOIS bridges the gap and encapsulates the hardware/software interfacing specialisation Software guys can go on and do software Anecdote: SDSS meeting split The Hardware World Processors Buses & Links Transducers Memories