SOIS at Design Net Approaching Reusability in Flight Software

Content The SOIS Implementation for NRL Supporting Reusability in SOIS Acknowledgements

SOIS Implementation for NRL Flight Software Standards Testbed Platform TAS FAS Issues Discovered in Implementation

SOIS Implementation Platform FunctionTechnology Transfer and Subnetwork Layers, approximately Satellite Data Model Flight Network HardwareSpacewire Simulation of Flight and OperationsSpacecraft Dynamic Tool Flight Operating SystemuClinux Flight ProcessorMicroblaze in Xilinx FPGA Programming LanguageC++ Preliminary Development EnvironmentWindows, POSIX

Time Access Service We implemented the following capabilities. Wall Clock Alarm Clock Metronome

File Access Service We implemented the following capabilities. Open File Close File Read From File Write To File We expect to implement others as needed.

Issues Discovered in Implementation These issues may have already been discussed and resolved in this community; if so, we can move through these slides quickly. Blocking Management of lifetime of indication objects Management of lifetime of data buffers

Blocking We assumed that the standard SOIS FAS interface should block. We added a non-blocking alternative to the standard SOIS FAS interface.

Lifetime of FAS Indication Objects The indication objects returned by FAS might have one of the following lifetimes: – Owned by FAS, and overwritten sometime – Created by FAS, and deleted by application – Created by application and deleted by application We implemented the third option above by adding a parameter to every FAS method, in which the application provides an indication object.

Lifetime of Data Buffers The data buffers returned by the standard interface might have one of the following lifetimes: – Owned by FAS, and overwritten sometime – Created by FAS, and deleted by application – Created by application and deleted by application – Imbedded in indication object We added a method for applications to specify a read- buffer, implementing the third lifetime above. If an application does not supply a read-buffer, the second lifetime above applies.

What is Reusability? When a reusable component joins an assembly, it is able to exchange services with the other components in the assembly. Modification of a reusable component is unnecessary when adding it to an assembly.

Benefits of Reusability Reduce time to launch. Reduce cost to launch. Improve reliability in routine missions. This is a principle to guide the implementation of plug-and-play discovery in SOIS.

Obstacles to Reusability Differences in content of similar data messages among different devices and diachronically – such as the number and locations of thermistors reporting housekeeping data in a device Reorganization of device boundaries – such as the development of star trackers that produce angular rates, while some star trackers only provide direction Differences in implementation of protocols – such as a device that receives a mode byte that includes “on” and “off” states, compared to a device that responds to an “on” command and an “off” command. Difficulty of adapting to differing qualities of service – Timing of delivery of data – Accuracy and precision of measurements Implementation of system-level concepts – Mission operations – Restrictions on spacecraft attitude (keep-out zones) Inadequate coordination among designers – This issue appears as a longing for logical design and concise documentation; each designer seems to have a different language. – We agree with the SOIS principle, that a standard interface will provide a common language for coordination of designers. Add to this list any of the reasons why we must call on the services of engineers to rework components before they can interoperate.

Strategy to Implement Reusability Abstraction: Design both devices and software applications as peer endpoints of data transfer in a self-assembling distributable processing network*. Metadata: Associated with each endpoint are metadata that describe the semantics of the data that the endpoint can publish, and of the data that the endpoint can usefully consume. Quality of Service: Endpoints establish mutual sessions for the exchange of data in a spacecraft, using mutually compatible protocols. Consumers of data choose providers based on quality of service. Standard Semantics: Definitions of data semantics and protocols reside in a public repository, where they may be used by developers of new endpoints that can communicate with any old endpoints. * See next slide for a definition of this expression.

Self-Assembling Distributable Network The term “self-assembling” refers to the formation of a system through autonomous session building among endpoints. The principle that guides the assembly is the data that ultimately will flow between endpoints. The term “distributable” refers to an architecture in which a collection of endpoints adapts dynamically to distribute work across the suite of processors available on a spacecraft, including the processors that represent hardware devices. Build on the present SOIS architecture, which abstracts the complexities of data transfer mechanisms. Use virtualized devices to make both devices and software applications peer endpoints of data transfer.

Metadata Discovery: A consuming endpoint identifies endpoints that publish the data variables that it uses on board a particular spacecraft. Selection: A consuming endpoint chooses one or more publishers. Message Building: The publisher endpoints define messages to package variables with similar schedules. Session Protocols: The session protocols coordinate delivery of variables.

Session Building: Flight Segment During flight, endpoints communicate through a data virtualization wrapper. Inside the wrapper, the endpoint logic reads and writes variables from and to local memory, receiving notification events when variables change value. The wrapper satisfies the endpoint’s need to receive data and its responsibility to publish data, as described in its metadata. The data virtualization wrappers of consuming endpoints retrieve from a “dance card” file their matching publisher endpoints. The consuming endpoint wrappers may form a session with the publisher endpoint wrappers of their choice, using mutually supported protocols. A network application answers the question of quality of service that is available between two endpoints, so consuming endpoint wrappers may select a publisher according to quality of service. The “dance card” file may be extended during flight, if reconfiguration of the spacecraft is needed on the launch pad or in flight. (software upload, docking, or spacewalk upgrade)

Session Building: Ground Segment A ground-resident database stores a collection of metadata describing spacecraft endpoints and their semantics. On the ground before a mission, a design tool plans the connection of mission devices (payload and other special sensors) to a spacecraft bus. The design tool assures that for each item of data used by a consumer endpoint on a spacecraft there is a producer endpoint for that data. The design tool generates a file of pairs of potential producer and consumer endpoints, to be loaded into the spacecraft along with flight software. Call this the “dance card” file.

Session Building Diagram Endpoint Data Suppliers Endpoint Data Suppliers Endpoint Data Sheet Endpoint Data Sheet Ground Repository of Endpoints Flight Endpoints Endpoint Designer Endpoint Data Sheet Flight Preprocessor Endpoint Data Suppliers Endpoint (payload) Endpoint (subsystem) Flight Ground Session

How Endpoints Find Data 20 Consumer/ Publisher Matching Algorithm SOIS Application Support Layer Repository Endpoint Interface Designer Forms in Endpoint Data Sheet Endpoint Data Suppliers Endpoint Algorithm Endpoint Algorithm Designer Consumer/ Publisher Matching Algorithm Form Kind, Form Name Form Name, Variable Form Form, Variable Publisher, Message, Variable Publisher, Message, Variable Treatment of Variable Variable Command & Data Acquisition Service Content of Variable Flight Ground

Acknowledgements Much of the technology in this presentation is based on prior work of the PnPSat development team, under the direction of Don Fronterhouse, toward the development of reusable subsystems and components for PnPSat. The SOIS application programming interface is based on the recent standards documents.

TANGENTIAL TOPICS

Class Structure Diagnosable Executable Endpoint SOIS TASSOIS FAS litexml Payload Agent Metadata classes

Data Virtualization Wrapper Execution Pattern Event Handlers Interpretation of Endpoint Metadata Access to Application Support Layer

Execution Pattern Variables in Memory Event-Driven Behaviors Before Cycles After Cycles Analysis Publication

Asynchronous SOIS Situation: SOIS FAS operations fit into sequential program logic. Challenge: Events in distributed processing may occur in a variety of sequences. Adaptation: Separate the events from the program sequence. Represent program sequence declaratively in a state machine. Implement sequential logic by reading state machine. Start Operation 1 Start Operation 2 Operation 1 Operation 2 Store results. Operation 1 Done What is next?