TEC-EDD (CCSDS-SOIS PnP on MILBUS)

CCSDS Meetings – Spring 2009

TEC-EDD (CCSDS-SOIS PnP on MILBUS)

1

SOIS PnP Device and Service Discovery

An example of an adaptation model for MILBUS(On ECSS-E-50-13 Compliant System)

Massimiliano CicconeESA/ESTEC

20-April-2009



2

SOIS PnP Service Architecture



3

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

5) DES informs DVS of new device type-model and its provided services

7) Users Application can now access the new ‘GENERIC’ device from the DVS

Device Enum.Table

6) DVS loads ‘generic’ communication profile of new device (e.g. from Virtual Drivers lookup table)

Virtual DriversTable



4

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



5

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)

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.

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



6

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.



7

SOIS PnP Use Case 2/2

The new RT responds to the DDS polling request by sending device descriptors

The DDS discovers the new RT and all the device(s) attached to it

1)

2)

Post-condition If a DDS is running, this condition will trigger the following actions:

EVENT: New RT becomes operational on the BUS



8

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



9

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



10

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



11

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



12

Example of an ECSS-E-ST-50-13 Based System



13

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



14

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)



15

DDS Model Sequence Diagram



16

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



17

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



18

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



19

DDS PnP Device Descriptor Data Format

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.

The PnP descriptor of each device needs to specify “at least” Class, Model and unique Device ID within the RT.



20

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



21

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)



22

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’



23

Proposed 1553 Service Discovery Adaptation Model1. 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

1. 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

2. 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)

3. DAS Assembles the EDS and hands it to complementary SOIS PnP Services



24

EDS Acquisition Model Sequence Diagram



25

Use of RT SA 1R for Service Discovery (Example)

Word No Data

0 Reset RT_Health command

1 Reset Services command

2……14

Command Extension

15……31

RT Configuration Parameters

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

0 Reset RT_Health command

1 Reset Services command

2-3 Device Access Service

4……14

Command Extension

15……31

RT Configuration Parameters



26

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



27

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



28

END



29

BACKUP



30

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



31

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)



32

Mapping DDS onto 1553



33

Retrieving Attached Device(s) Info

• 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

Case 1:



34

Retrieving Attached Device(s) Info

• 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

Case 2:



35

Embedded RT



36

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



37

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



38

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

devices2. Standardisation of a number of device classes (with room for extensions,

additions etc)



39

• 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



40

SOIS PnP

Use Case 2: Just before launchLauncher OBC is attached to a EGSE system prior to lift-off.Few seconds before launch EGSE is detached and

EGSE processor(BC)

RT

Spacecraft busMIL-1553

Prior to launch:

Few secs before launch:

EGSE (BC) periodically polls RTs Using broadcast Service (Addr 31)

RT RT

Launcher OBC (RT)


When EGSE detaches the Launcher’s OBC becomes the MIL bus BC

RT RT RT

Launcher OBC(BC)

Identified issues: Safety; Robustness; Reliability; Repeatability

EGSE processor(RT)



41

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

Lander OBC(BC)

RT


Prior to landing:

After landing:

BC periodically polls RTs Using broadcast Service (Addr 31)

RT RT RT RT RT

Rover OBC(RT)

Lander OBC(BC)

RT Spacecraft busMIL-1553

When Rover detaches its OBC becomes BC for the rover bus

RT RT RT RT RT

Rover OBC(BC)

Identified issues: Robustness; Reliability

TEC-EDD (CCSDS-SOIS PnP on MILBUS)

Documents

Transcript of TEC-EDD (CCSDS-SOIS PnP on MILBUS)