Discovery Systems Where Standards are Needed

Agenda Self-Organization Efficient Discovery Discovering Data Semantics Self-organizing Network Topology Reusable Software Components Autonomous Mission Management

The Fiddler on this Roof Traditionally, we have provided general-purpose services by providing vessels for application data that are blind to semantics. This approach places the following limitations on applications. – We limit the interoperability of flight software components by failing to offer a standard extensible formulation of application semantics. – We burden application developers continually to reinvent the design patterns for gluing components together into a whole system that can perform a mission. The objective of this presentation is to urge extension of discovery to all organizational levels of space missions.

Self-Organization Use CaseWhy it Works A simple case: Plugging a storage medium into a USB port of a personal computer extends the storage capacity of the computer. Simple Case: The integration occurs at a low level of organization, in the file system. Higher organizational units, like applications, continue to use the same interfaces. A complex case: PnPSat is a collection of components which, when connected to one another, organizes itself into a spacecraft with a mission. Complex Case: A number of controlling features ensure the success of integration at all levels of organization. See next slide for a sample.

Organization Among Peers A Sample of Potential Problems at Various Levels of Organization Mechanisms for Avoidance Components: The collection of components might lack something vital, like an electrical power supply, or a sun sensor on one side of the spacecraft. An automated configuration solver computes a complete set of components and arranges them, given mission requirements. This could be done by a team of engineers, for non-routine missions. Subsystems: The components could be so mismatched that its control loops don’t work. On PnPSat, the ADCS uses a Kalman filter to estimate the bias of the IRU. More generally, we could use a standard calibration interface in xTEDS. Spacecraft: The result of self-organization could be incapable of goal-directed action. One of the components is a mission manager, which brings the capability to manage a schedule of activities requested by software agents also present among the components.

Where Standards Are Needed for Self-Organization Extensions to standards are needed where implicit information transfer occurs through human intervention. Automated Configuration Planning: Standard metadata that is a superset of xTEDS or XTCE is needed. (more about this later) Components Assembling into Subsystems: Standard syntax for calibration data could be added to xTEDS. Subsystems Assembling into Spacecraft: SPA works because standard interfaces in xTEDS carry implicit semantics. These interfaces could be placed into a public repository. Higher Levels of Organization: XTCE could be used with a protocol for large-scale networks, or SPA could be extended across spacecraft. Components Subsystems Spacecraft SPA Constellation XTCE with discovery SPA

Efficient Discovery Discovery gets in the way of operations: – Operations cannot proceed until their components have formed relationships. – The knowledge needed for discovery occupies space in memory and adds complexity to components. Discovery offers benefits: – Commoditization of components (AKA reusability, interoperability) – Automated configuration for well-understood missions – Rapid integration – Adaptation aging of components during operation docking and undocking new components (usually software) How can we manage the costs in order to achieve the benefits of discovery?

Managing the Cost of Discovery Issues Delay of operations Complexity of components Remedies Use faster processors with more memory Partition discovery in time: – Establish initial relations at configuration time. – Continue to support adaptive discovery in flight. Move discovery algorithms to a dynamic proxy.

Where Standards Are Needed for Efficient Discovery To partition discovery in time, develop syntax and ontology for standard metadata that is a superset of xTEDS and XTCE. The extension to metadata describes the consumer side of applications, to complement the provider side described by xTEDS and XTCE. The same metadata can be used to move discovery algorithms to dynamic proxy. The same metadata can be used to model application components in configuring spacecraft. xTEDS or XTCE Extended Application Metadata Interpreter Consumer Model Provider Model Time- Partitioned Discovery Discovery in dynamic proxy Automatic Mission Configuration Today’s Discovery

How Algorithms Discover Data Standard Ontology A Human Designing an Interface A Human Writing an Algorithm Metadata that Describes the Interface The Algorithm A Message in the Interface Semantics Data Type, Message, Semantics Semantics, Treatment of Variable Discovery Data Type, Message, Semantics Semantics Subscription Content of Variable Traffic Subscribe Development time Execution time

Where Standards Are Needed for Discovered Data Use CaseStandard Needed An array of temperatures as measurements with estimated variances Recursive syntax description in xTEDS CCSDS Space Packet headersBit-level syntax description in xTEDS The distinction between temperature as a measurement and temperature as a prediction, which can be applied algorithmically. An institution to maintain a standard ontology for space system semantics

Where Standards Are Needed for Self-Organizing Network Topology SpaceWire offers mechanisms to manage quality of service across an arbitrary network. The issue here is to arrange application software components to minimize the path between them. This can be done by extending the consumer model in the extended application metadata to describe quality of service required. The configuration solver can use this information to constrain the placement of some software components.

Where Standards Are Needed for Reusable Components Plug-and-play hardware components can be used on a variety of platforms. We should expect the same reusability for flight software components. To achieve software reusability in self- organizing systems, we need standard interfaces at all levels of organization in which the software interacts.

A Potential Extension to How SOIS Treats Discovery Data Discovery Service

SOIS Data Discovery Service Data Discovery Service (DDS) Metadata for A describes variable X, and how A uses X Application A get_X set_X PublisherThread: If X is published, call A.get_X periodically, and publish X ConsumerThread: If X is consumed, receive messages periodically and call A.set_X DDS(application, metadata){ generate xTEDS from metadata; register xTEDS at data manager; if (X is consumed){ request publishers of X; Choose which to subscribe; } start PublisherThread; start ConsumerThread; DDS d = new DDS(this, metadata) for (;;){ use variable X; sleep briefly; }

Where Standards Are Needed for Autonomous Mission Management Use CaseProtocol Adjust torque in a control loop.Command without response Subscribe to computed sun vector.Periodic telemetry messages Request state of device.Query, followed by response Ask a subsystem to plan to perform a task, receive response whether it can do it, and then tell it to do it. Request, followed by response, followed by command: An extension to xTEDS is needed to describe this exchange. Activity manager and activity agent interfaces Treat xTEDS Interfaces as immutable, extensible classes.