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-Play Use 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 Software Bus (e.g. messaging) DES DVS DAS Subnetwork Packet Protocol Subnetwork Packet Service Hardware ED S 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 it 2.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