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
1
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Service Architecture
CCSDS Meetings – Spring 2009
2
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
SOIS PnP Service Architecture
Device Enum.
Table
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
Virtual Drivers
Table
within Dev. Enum. 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)
CCSDS Meetings – Spring 2009
7) Users Application can now
access the new ‘GENERIC’
device from the DVS 3
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)
CCSDS Meetings – Spring 2009
4
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
5
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
6
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
7
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
8
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
9
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
10
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
11
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Example of an ECSS-E-ST-50-13 Based System
CCSDS Meetings – Spring 2009
12
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
13
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
14
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
DDS Model Sequence Diagram
CCSDS Meetings – Spring 2009
15
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
16
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 PnPDDS 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
17
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
18
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
19
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
20
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
21
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
22
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Proposed 1553 Service Discovery Adaptation Model
1. 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-5013C 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
CCSDS Meetings – Spring 2009
23
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
EDS Acquisition Model Sequence Diagram
CCSDS Meetings – Spring 2009
24
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 EST-50-13C subaddresses. Table below shows the format of subaddress 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
…
…
14
Command Extension
15
…
…
31
RT Configuration Parameters
CCSDS Meetings – Spring 2009
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
25
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-STD1553B would benefit from the allocation of a standard RT subaddress 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 subaddress 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 subaddresses allocation of ECSS-E-ST-50-13
CCSDS Meetings – Spring 2009
26
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
27
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
END
CCSDS Meetings – Spring 2009
28
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
BACKUP
CCSDS Meetings – Spring 2009
29
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
30
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
31
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Mapping DDS onto 1553
CCSDS Meetings – Spring 2009
32
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
33
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
34
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
Embedded RT
CCSDS Meetings – Spring 2009
35
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
36
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
37
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
CCSDS Meetings – Spring
2009
38
2. Standardisation
of a
number of device classes (with room for
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
• The same way as for DDS, Service discovery for MILSTD-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
39
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
Prior to launch:
EGSE processor
(BC)
EGSE (BC) periodically polls
RTs Using broadcast
Service (Addr 31)
Spacecraft bus
MIL-1553
RT
Launcher OBC
(RT)
RT
RT
Few secs before launch:
EGSE processor
(RT)
When EGSE detaches
the Launcher’s OBC
becomes the MIL bus BC
Spacecraft bus
MIL-1553
Identified issues: Safety; Robustness; Reliability; Repeatability
CCSDS Meetings – Spring 2009
RT
Launcher OBC
(BC)
RT
RT
40
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
Lander OBC
(BC)
Prior to landing:
RT
RT
RT
BC periodically polls
RTs Using broadcast
Service (Addr 31)
Spacecraft bus
MIL-1553
Rover OBC
(RT)
RT
RT
RT
After landing:
When Rover detaches its OBC
Lander OBC becomes BC for the rover bus
(BC)
RT
Identified issues: Robustness; Reliability
CCSDS Meetings – Spring 2009
RT
RT
Spacecraft bus
MIL-1553
RT
Rover OBC
(BC)
RT
RT
41