Use Case Refresher 1

Different Views on PnP Notes from previous discussions ARFL’s Space Plug-n-play Avionics ( SPA) is aimed at describing complete spacecraft. ESA seems more focussed on looking on the AOCS subsystem and transducers, with a data link layer PnP protocol to retrieve identification of devices on a single subnetwork (multiplexing units with attached devices should also be catered for) and to recognise their capabilities. The capabilities may be pulled from the device itself or local storage. NASA GSFC has an interest (beyond ESA’s interests) in self forming AOCS that discovers and uses devices, redundancy and failure/recovery mechanisms. NASA GSFC interest in reducing schedule and risk for system integration. 2

Different Views on PnP Notes from previous discussions Ray Krosley (DesignNet/AFRL) is looking at “recognisable devices”, not software components. Software components are important to NASA GSFC as an extension; “recognisable devices” should be a subset of what comes out for software components. They agree that piecing together messages at run time is very complex, especially semantics and units used for values. NASA Constellation Program in crew interfaces. Display and control systems should support the dynamic integration of new systems. From IEEE spec. From IEEE spec Should we be looking at compile time or run time for device capabilities? ESA’s view is that only routing to devices (i.e. setting up subnetwork addresses etc) should be done at run time. The data content etc should be done at compile time. 3

Use Cases In conjunction with defining the term “plug-and-play”, the use cases to be solved by PnP within the SOIS domain need to be captured. The following is a summary list of those use cases identified to date: Rapid Spacecraft Assembly of Devices – to reduce/eliminate the need for aspects of Spacecraft database for configuring onboard software (OBSW); Spacecraft Integration & Test – Electrical Ground Support Equipment (EGSE) connection to Spacecraft under test using wireless technologies; Dynamic Fault Recovery and Subnetwork Reconfiguration – activation of redundant devices upon a flying spacecraft in response to faults. A Fault Detection, Isolation and Recovery (FDIR) system application simply powers up replacement. Reconfiguration happens automatically (bottom-up), rather than hierarchical (top-down); 4

Use Cases Dynamic Device Migration and Subnetwork Reconfiguration – characterised as facilitating the incorporation of mobile heterogeneous sensing and control devices in a wireless, heterogeneous communications network. Onboard Software Upgrade or Reconfiguration – covering mode changes or software updates. This is purely a software change with no new data systems introduced, so there is no reconfiguration of the SOIS communication services required, and so out of scope of PnP. Rapid Spacecraft Assembly of Subsystems – while PnP will simplify at the subnetwork layer the integration of subsystems with other subsystems and/or complex instruments, integration also requires a complex exchange of information using perhaps a software framework or middleware that is beyond the present scope of SOIS. However, such a software framework would exchange messages using the SOIS Message Transfer Service. Therefore PnP greatly aids but itself does not fully solve this use case. 5

Use Cases from Ramon 0.1. Finding Providers to Span a Space Situation: An application that distributes torque over a collection of reaction wheels needs to find at least enough wheels to span the domain of the torque vector. The application lacks algorithms to control devices of other technology, such as control moment gyros or thrusters. Behavior: The application requests all reaction wheels. The enumeration service sends to the application a list of all such devices. The application gets the intrinsic properties of the devices, such as their momentum capacity. The application gets the assembly properties of the devices, such as the orientation of their torque axes in spacecraft coordinates; there are enough devices when these axes span space. The application gets the dynamic properties of the devices, such as their current angular momentum. The application uses all these properties to command each device individually. The application may manage the devices by keeping one or more as spares. The application maintains a session with the devices through most of the duration of the mission. Issue 1: How do we deliver the assembly properties? In PnPSat, this was done through a manifest delivered to a server application before launch. Alternatively, the information could be merged into the metadata for the devices. Issue 2: The application must be able to address the devices in the spanning set individually. Something like a network address would serve this purpose, delivered as a property of the providers from the enumeration service. 6

Use Cases 0.1. Finding A Good Provider Situation: An image handling application in a satellite needs to photograph a region on the ground. Behavior: The application requests all providers of the imaging interface. The enumeration service sends to the application a list of all such providers. The application scans the list, culling by quality-of-service issues, such as time to readiness, pixel density, wavelength, aperture size, and others. The application selects a provider and establishes a control session with the provider. When the application is finished using the device, it ends the session. Issue 1: Does the enumeration service keep track of the session boundaries? An intelligent device might be able to manage its own sessions. Issue 2: The pixel density is probably a static property of the provider, so it could be delivered in the metadata that describes the provider when it registers with the enumeration service. Is that the best method of delivery? The time to readiness could be a dynamic property of the provider, which an application can query through the imaging interface. Can the application query without establishing a session? 7

Use Cases 0.1. Finding All Devices Situation: A power management application needs to know what devices are present and how to prioritize shutting them down in a power drought. Behavior: The application requests all devices that use power. The enumeration service sends to the application a list of all such devices. The application gets information about the power control for each device. The application gets information about the load-shedding priority of each device. Issue 1: What is a good way to control power to the devices? Should each device present a power-control interface, as in PnPSat? Should there be switches for each device on a power distribution system, also as in PnPSat? How does the power management application associate a power switch with each device? In PnPSat, the association was done through the manifest loaded before launch. The power-control interface was capable of shutting down all but essential power to the device, while the power switch removed all power from the device. Issue 2: Is the load-shedding priority in the scope of this project? 8

Use Cases 0.1. Update Discovery Situation: An application has requested devices, and the enumeration service has answered. Another device that matches the query becomes active; this can happen when starting the system. A previously discovered device becomes inactive; this can happen when a device fails. Behavior: As a part of its query, the application has asked to be notified of future changes in the set of matching devices. The enumeration service notifies the application of a new suitable device that is available. The enumeration service notifies the application when a matching device becomes inactive. Issue 1: If an application has chosen a good provider, and a better provider appears, the application may end its session with the former and begin a session with the latter. This means that the application would need access to the properties of its present provider and the properties of the new provider. Issue 2: If an application has chosen a good provider, and the provider fails, the application may be best served to repeat its query to get the properties of the providers at that time. This means that notification of failed devices need not carry much more information than the identity of the device. 9

Use Cases 1. Providing Data and Services The use cases in this section represent applications receiving data from virtualized devices, or requesting services from virtualized devices Periodic Notification Situation: An application requires continually refreshed knowledge of the value of a variable. Behavior: The application identifies the variables for which to receive periodic notifications when it forms a session with a provider. The provider sends those notifications throughout the session. Issue 1: The provider might have a physical upper bound on the frequency of notifications. The provider might limit the choices available to applications for notification schedules in other ways 10

Use Cases 0.1. Event Notification Situation: An application requires notification as soon as possible after the value of a variable changes. Behavior: The application identifies the variables for which to receive event notifications when it forms a session with a provider. The provider sends those notifications when the values of the variables change throughout the session. Issue 1: The application might need to specify a dead zone, in order to ignore noise. Issue 2: The application will not be able to distinguish a dead device from an unchanging variable in this mode, so some kind of additional mechanism is needed to notify the application when it has lost its provider. 11

Use Cases 0.1. Polling Situation: An application needs to control the rate at which it receives data from devices. An example of this is data that changes infrequently. Behavior: The application sends a request for particular data to its provider during a session. The provider sends a response back to the application. Issue 1: Is it necessary to be in a session to perform this action? 12

Use Cases 0.1. Using a Subset of the Data of a Provider Situation: An application does not need to see all the data that a device provides. For example, the device might be a reaction wheel that reports its speed and its temperature. Behavior: The application requests the variables that it needs. The device sends at least those variables to the application. Issue 1: In xTEDS this issue is managed by grouping the variables into messages that represent the likely combinations that will be requested. 13

Use Cases 0.1. The Meaning of Data Grouped in a Message Situation: An application needs to receive not only the value of a variable, but also the time at which that value was measured. Behavior: The application groups variables into messages for delivery to the application. The meaning is that the data values are contemporaneous within some interval of measurement error. 14

Use Cases 0.1. Commanding Situation: An application needs to command an actuator. Behavior: The application discovers a provider of the actuator’s interface, such as the reaction wheel interface. The application forms a session with the device. During the session, the application sends commands to the device. The application ends the session when it is finished with the device. 15

Use Cases 0.1. Telemetry Situation: An application that collects housekeeping data for telemetry needs to obtain that data from all the devices that provide interesting data. Behavior: The application requests all interfaces that contain messages flagged for telemetry. The application forms sessions and subscribes to those messages. As it receives the messages, the application builds telemetry packets and stages them for delivery to the ground. 16

Use Cases 0.1. Multiple Interfaces of a Provider Situation: A provider offers more than one interface, and an application might need to know that its use of the interfaces applies to the same device. For example, a reaction wheel might have an interface for controlling its power state (which is the same across a variety of different devices), and it would also have an interface for commanding its torque. An application might need to disable power in certain failure modes. Behavior: The application uses the network address of the provider to determine whether two interfaces apply to the same or different devices. 17

Use Cases 0.1. Multi-Headed Devices Situation: A device collects the data from a number of sensors and packages the data into a single message for delivery. An application monitoring the device must interpret each of the elements in the array separately. For example, the temperature sensors that monitor the health of a device may vary in number and location across a variety of manufacturer’s models. Behavior: The interface for the device indicates that a certain variable has a number of instances, distinguished by annotations in the metadata, such as the locations of thermistors in device coordinates. The application uses the metadata description of the interface to interpret each of the instances of temperature readings in a message. More specifically, the instances of temperature readings appear in an array, and the application associates a location in device coordinates with each element of the array. Issue 1: This strategy works for multi-headed devices whose heads are fixed in device coordinates. It doesn’t work so well for octopus sensors whose heads are distributed in the space of a spacecraft. In the latter case, the association of location or orientation information with each head would have to appear in the assembly data for the spacecraft. 18

IEEE1451 It should be apparent that a generic software tool could be developed to display the set of commands implemented and to prompt the operator for a selection. Based on the command selected, the tool could prompt the operator for each argument. With the accumulated information, the tool could construct a properly structured command string, issue the command to the device, and read and properly display the result(s). 19 Return