Upload
howard-douglas
View
220
Download
0
Embed Size (px)
DESCRIPTION
SOIS PnP Service Architecture TEC-EDD (CCSDS-SOIS PnP on MILBUS) SOIS PnP Service Architecture CCSDS Meetings – Spring 2009
Citation preview
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
2
SOIS PnP Service Architecture
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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)
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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.
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
12
Example of an ECSS-E-ST-50-13 Based System
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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)
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
15
DDS Model Sequence Diagram
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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.
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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)
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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’
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
24
EDS Acquisition Model Sequence Diagram
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
28
END
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
29
BACKUP
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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)
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
32
Mapping DDS onto 1553
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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:
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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:
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
35
Embedded RT
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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)
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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)
Spacecraft busMIL-1553
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)
CCSDS Meetings – Spring 2009
TEC-EDD (CCSDS-SOIS PnP on MILBUS)
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
Spacecraft busMIL-1553
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