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

- New data system is added or existing ones relocated - Some data system that are only used during AIT are removed before launch Before: After:

RT DDS OBC (BC) RT Subsystem Subsystem(s) BC periodically polls For new RTs on the bus Spacecraft bus MIL-1553 New RT (embedded or stand alone) RT Subsystem with Embedded RT capability RT OBC (BC) The OBC discovers the new device. Device is catalogued and relevant services are updated 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 Initiate Self Test

: ( Discovers the new RT 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)

Device Enum.

Table Virtual Drivers Table

4) New device data sheet (EDS) is read via DAS and new SOIS Address-EDS entry stored within Dev. Enum. 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

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:

SOIS Address Class, Subclass, Vendor ID

Virtual Drivers Table:

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 Prior to launch:

EGSE processor (BC) EGSE (BC) periodically polls RTs Using broadcast Service (Addr 31) Launcher OBC (RT) Spacecraft bus MIL-1553 RT RT RT

Few secs before launch:

EGSE processor (RT) When EGSE detaches the Launcher’s OBC becomes the MIL bus BC Launcher OBC (BC) Spacecraft bus MIL-1553 RT RT RT

Identified issues: Safety; Robustness; Reliability; Repeatability

SOIS PnP

Use Case 3:

In Flight

Lander and Rover attached during cruise phase and detached after landing using Lander OBC only prior to landing Prior to landing:

Lander OBC (BC) BC periodically polls RTs Using broadcast Service (Addr 31) Rover OBC (RT) RT RT Spacecraft bus MIL-1553 RT RT RT RT

After landing:

Lander OBC (BC) When Rover detaches its OBC becomes BC for the rover bus Rover OBC (BC) RT RT RT Spacecraft bus MIL-1553

Identified issues: Robustness; Reliability

RT RT RT

What is SOIS?

A spacecraft construction kit Attitude Control The Software World Health Monitoring Thermal Control Autonomy SOIS

Providing Standardized On-board Services and Interfaces

The Hardware World Processors Transducers Memories Buses & Links