On-Board Operations Support Software (OBOSS) encompasses satellite on-board software for cost-efficient on-board data processing. The software architecture supports the ESA Packet Utilisation Standard including mission-specific software, standard application software, and operating system plus basic services.
The OBOSS software implementation is derived from the Ørsted data handling software that has performed well in orbit since early 1999. OBOSS has also been used on the Danish parts of the Argentinean SAC-C mission.
The standardized ECSS Packet Utilization Services have later been integrated into the complete Attitude and Orbit Control software for the Herschel and Planck satellites.
The OBOSS software implementation is derived from the Ørsted mission (image courtesy: DTU Space)
OBOSS has been defined through analyses of a range of ESA science and Earth observation missions.
High reliability has been ensured by a rigorous domain analysis resulting in a detailed layered decomposition of the software. Subsequent comprehensive design techniques, including Hard Real-Time HOOD, have confirmed performance and logical correctness.
OBOSS is platform independent and has been adapted to Intel 80186, 1750A, TSC21020, and ERC32 processors.
The system is being maintained under contract with ESA's technical center, ESTEC.
On-Board Operations Support Software addresses the standard application software and implements those Packet Utilisation Standard (PUS) services that have a high degree of commonality across missions and spacecraft.
The PUS services are composed of sub-services addressing specific functions and activities that lend themselves to a standardized implementation.
The software reflects the logical model of the Packet Utilisation Standard. Each on-board subsystem has one associated application process responsible for managing the PUS services for that specific subsystem.
The OBOSS software has been designed for high reliability and efficient re-use. Adaptation of source code is automated, based on a feature-rich model of the mission-specific characteristics.
Layering - The architecture is partitioned into a layered structure within which the various software components have clearly defined interfaces.
Low Coupling - Application processes do not communicate with one another directly, since all communication takes place through the packet router.
Adaptability - Modifying one application process - for example a payload interface - will have no impact on other application processes.
Scalability - New application processes may easily be added, as the packet router and a few configuration modules are the only components to be interfaced. Similarly, application processes that are not needed can easily be removed.