• Add intro to concept of electronic data sheets

• PnP based on use of this

• Can describe s/w as well as h/w

Broad Plug-and-PlayUse Cases/Scenarios

• Range of scenarios considered affecting spacecraft and monitoring of spacecraft– Fault Detection Isolation Recovery (FDIR)

• Decouple FDIR mechanism from FDIR policy– Spacecraft development

• commonality/reuse (built to standard specifications)– Stock parks and one-off parts from a common standard

• incremental qualification (composability)– Spacecraft integration

• off the shelf components– Spacecraft test automation

• hardware in the loop• automatic test generation• automatic generation or configuration of standard EGSE (simulator or tester)

– Dynamic reconfiguration of software tasks• software maintenance• spacecraft mission phase driven dynamic reconfiguration

– Automation generation of ground/crew command/telemetry descriptions from spacecraft data sheets

• In general, plug-and-play of monitoring and control interfaces, a.k.a. command and data acquisition, of components

• Plug-and-play components encompasses software as well as hardware devices

Benefits of Plug-and-Play

• Accelerated development process• Reuse of software and hardware (flight and EGSE)• Interoperability

– Between agencies e.g. Agency A payload hosted on Agency B spacecraft

– Spacecraft manufacturers and equipment vendors• Maintenance reduction

– E.g. software update• Schedule risk reduction

– develop elements (hardware or software) to standards that can be tested independently

• Composability– bring in elements (software/hardware/simulators/test equipment)

at any point into schedule with minimal impact into schedule flow

Spacecraft Plug-and-Play Architecture

Application Application

Software Bus(e.g. messaging)

DES

DVS

DAS

Subnetwork Packet Protocol

Subnetwork Packet Service

Hardware

EDS

EDS

NM Including Policy

Subnetwork PnP Protocol

Subnet DDS

Class-based I/F

Raw parameter I/F

SOIS

Non-SOIS

Agency Interest in Spacecraft Plug-and-Play Architecture

• NASA-GSFC and AFRL constructing frameworks that consider all of the above

• ESA not yet considering standardisation of this larger spacecraft plug-and-play framework

Scope of SOIS Plug-and-Play• Software components out of scope of SOIS, belongs in MOIMS,

probably SM&C– Believed that such a PnP aspect of SM&C onboard a spacecraft is in

MOIMS scope but hasn’t been explicitly addressed yet– Recommend: MoU between SOIS and MOIMS be re-visited to address

Plug-and-Play

• Recommend: SOIS concentrate on that part related to interfacing to devices across a subnetwork– Get benefits now, ensure enabler not obstacle to larger framework

• Provision of Subnetwork Plug-and-Play Protocols and Network Management are out of scope as responsibilities of other standards bodies

Work Items• Device Virtualisation Service

– Provision of class-based interface is required regardless of PnP but isn’t standardised yet (Issue 0.1 only)

– Config I/f for adding new device types to be done – this is PnP

– Refine device classes and service interface

• Electronic Data Sheet format– 1451 TEDS, xTEDS convergence– Inputs from ESA AOCS group on their

standardisation of AOCS transducers– Define format / ontology– Minimal content for class data sheets

• Device Enumeration Service– Extend to optionally access Electronic

Data Sheet from device– Refine service interface– [Investigate need for Modifiable EDS –

no use case identified so far]

• Not under SOIS but necessary:– Subnetwork Plug-and-Play Protocols

• SpaceWire, MIL-STD-1553B, CAN– Subnetwork Device Discovery Service

and Network Management• Not explicitly in SOIS but needs to be

provided to deliver SOIS PnP over a subnetwork

• EDS access (read only)• Refine service interface

• Prototyping– SW bus-based middleware– Dynamic virtualisation using EDS– Subnetwork Network Manager policies– Interoperability tests

Work Package Flow• EDS Study

– 1451– xTEDS

• SOIS Stds. Studies in view of 1451 architecture study

– Device Virtualization– Device Enumeration– Device Discovery

• Support Stds– SpW PnP– 1553 PnP– CAN PnP

• Prototyping– S/W bus– Dynamic Virtualization– Sub-network Manager– Interoperability Testing

• SOIS /EDS Refinement

Concurrent(1)

(2)

(3)

(4)

Charter• Non-PnP work items of SOIS Application Support Services WG

are approaching completion

• Remaining work items are related to PnP– Device Virtualisation Service already in charter– Device Enumeration Service already in charter– Electronic Data Sheet standard is NOT already in charter

• To cover Electronic Data Sheet standard, 2 choices:1. Create Plug-and-Play WG and move Device Enumeration Service into it2. Add Electronic Data Sheet standard to existing charter. Will be some

overlap of resources between the two while the existing work is completed

• Which is easier for the funding sources?– Securing funding (additional vs. new) vs. logical lifespan of working

groups

• Backup Slides

Detailed Use Case/Scenario – Spacecraft Development/Integration

• Vendor builds hardware component (star tracker) to the PnP standard– Delivers data sheet (xml) on media

• Automatic tools use media to generate driver software– Maps device specific data sheet to user interface (device virtualization) data

sheet (e.g. thermistor curve)– Maps user interface (device virtualization) data sheet to c header structures

using software auto-code • Policy is defined to be within constraints of data sheet• Auto generate EGSE test code for device tester

– Test device • Auto generate EGSE device simulation

– Verify simulator using device tester that was validated on real hardware– Start testing with simulators – then plug-n-play devices as they become available

• Automation tools takes vendor data sheet (defined in standard) and generates command & telemetry data base

• Data base used

Possible Mechanism & Scope• Plug in device (whether powered or not out of scope - *.x spec)• Either polling or asynchronous notification – mechanism defined in *.x spec)• Use routing information to query device for pertinent information• Policy – done by Network Management Function (NMF)- sub-network specific – is

used for network management configuration – sets upper bounds on current and future changes to network

– NMF does not currently exist (where does it exist)– End of Device Discovery Service (DDS)– Indication may be provided – to Device Enumeration Service (DES)

• DES associates pertinent information with device driver (instantiation)– Device Driver provides the device specific functions for not sub-network packet service;

Device Access Service (DAS) and the Device Virtualization Service (DVS) – knows position of device, parameters know a priori

– DES indicates to application of device availability– Abstract Device name; Unique Identification; Classification; Versioning information– End of SOIS scope (Device has exposed DAS & DVS and applications can now use the

device)• Application starts using device via DVS

SOIS Plug-and-Play• Range of scenarios considered affecting spacecraft and monitoring of spacecraft

– [list of scenarios]– Monitoring and control, command and data acquisition of both– Plug-and-play of software components as well as devices

• [list of Benefits]

• [architecture, spacecraft&component development process]– Electronic data sheets defining interfacing to devices across a subnetwork and user (software) interfaces to generic

devices– Overlap in Device Virtualisation Service between the two aspects – DVS provides the mapping from the user interface of

a generic device to the actual interface of a specific device

• NASA GSFC/ARFL considering framework that considers all of the above– ESA not yet considering standardisation of this larger framework (onboard a spacecraft)

• Software components out of scope of SOIS, belongs in MOIMS, probably SM&C– Believed that such an SM&C onboard a spacecraft is in MOIMS scope but hasn’t been explicitly addressed yet– Recommend: MoU between SOIS and MOIMS be re-visited to address Plug-and-Play

• Recommend: SOIS concentrate on that part related to interfacing to devices across a subnetwork– Get benefits now, ensure enabler not obstacle to larger framework

• NASA GSFC recommends IEEE 1451 be considered as the Plug-and-Play technology– Will need extending to support particular Spacecraft subnetworks, e.g. SpaceWire