Professional Articles

One of the most important standards within the ECSS framework is ECSS-E-ST-40C, a software engineering standard for software being designed for space projects. It covers all aspects of space software engineering including requirements definition, design, production, verification and validation, transfer, operations and maintenance. ECSS-E-ST-40C is applicable to all the elements of a space system, including the space, the launch service and the ground segment.

When it comes to certification, another important standard is ECSS-Q-ST-80C, which defines a set of software product assurance requirements to be used for the development and maintenance of software for space systems, including manned and unmanned spacecraft, launchers, payloads, experiments and their associated ground equipment and facilities.

In their essence, the ECSS standards highly resemble the DO-178 standard known from the avionics industry, and thus a lot of certification artifacts from avionics systems can be reused, when it comes to ECSS certification. In particular, ESA has adopted the IMA concept (Integrated Modular Avionics), a concept developed for the aeronautics industry to manage the growth in functionality and efficiency. The purpose of IMA is to define an integrated system architecture to preserve the advantages of the most-used architectures, namely fault containment and multi-vendor issues, for example safety or parallel development and validation. IMA also includes a technology called time and space partitioning (TSP) to separate applications from each other and avoid interconnections unless specifically intended by the developers. Integrated Modular Avionics for Space (IMA-SP) is a spin-in of the corresponding concept for spacecraft avionics. It aims to manage the increasing amount of mission functions embedded in the onboard software while saving on mass, volume and power through a higher level of integration and sharing of computing resources. IMA-SP also allows the combination of different software criticality on a single shared hardware, which reduces the computing power needed as well as the complexity of software and prevents the misbehavior of one application affecting others running.

Selective Recertification after Software Upgrade

With PikeOS, SYSGO has developed a separation kernel-based real-time operating system (RTOS), which is already being heavily used in the aviation industry with certifications up to the highest level (DAL-A) of the DO-178C standard. PikeOS also supports the majority of concepts of IMA-SP. Designs based on a separation kernel not only enable a very high level of safety and security, but can also significantly simplify certification and thus save considerable costs. Changing certain properties of a system carries the risk that safety or security assumptions are overridden and the system becomes insecure or wull loose the already achieved certification status. Thus, in the case of updates, the entire device must be recertified, including the parts that have not changed. This fact makes it difficult to develop flexible devices that can be economically adapted to new missions or environments.

Partitioning the device software under the rule of a certified separation kernel allows selective re-certification of only the partition that was affected by the update. The other partitions remain unchanged, and the strict separation ensures that their safety and security assumptions remain the same. In addition, the separation kernel can provide a secure upgrade mechanism with cryptographic signature, transport encryption and other features.

Space and Ground Applications

One of the space missions relying on PikeOS is the ANGELS project, a European initiative to develop extremely compact satellites. The first prototype was launched at the end of 2020 and proved to be fully operational. ANGELS stands for Argos NEO Generic Economic Light Satellites, with Argos being the only global satellite-based system for location and data collection designed specifically to study and protect the planet´s environment. ANGELS is a nanosatellite demonstrator program with the objective to develop satellites with a 12U form-factor and weighs between 10 and 50 kg. The development of the miniaturized satellite and instrument follows the European New Space approach, comprising miniaturized commercial-off-the-shelf (COTS) components and an efficient way of designing, developing and testing. Development of the payload, the Argos instrument Argos NEO, is carried out by Thales Alenia Space (TAS), who chose PikeOS as the technical basis.

This RTOS is the foundation for time and space separated applications, which fulfill, among other tasks, command and control operations as well as decoding beacons in ANGELS. Here, PikeOS supports different applications which are category B and D qualified based on the ECSS standard. Thanks to its separation kernel architecture, partitions can also be updated without impacting the others already in operation. This allows ANGELS to add or optimize functions, and to improve its security robustness over time.

In a ground application, PikeOS is part of the Korea Augmentation Satellite System (KASS) which was designed to deliver accurate real-time localization in transportation and aviation. Its purpose is to correct satellite data for moving objects in real time and free them from interfering factors as far as possible. By improving accuracy to as low as 1 meter, KASS will not only make aviation safer, but also support autonomous mobility to a great extent.

KASS combines a Global Navigation System (GNSS) based on the European EGNOS System with data from multiple base stations which are distributed across the entire peninsula. The base stations' known and unchanging position will be used to determine the exact distance between the station and the satellite in real-time by matching the uncorrected GNSS signal with the actual location. The corrected data will then be sent back to the satellites via the base stations.

Running in the central data center on Kontron hardware, PikeOS serves as the host system with both a POSIX and an ELinOS embedded Linux guest system. The POSIX partition acts as a gateway and uses SYSGO's certifiable IP stack (CIP), which can meet various safety standards and provides POSIX with a socket interface for communication. POSIX is also used for the calculation of correction data and is certified to the DO-178B DAL C avionics safety standard, while the ELinOS partition performs less critical monitoring tasks. The system offers high availability and is suitable for mixed criticality applications.

Use Case: Redundant Configuration

Apart from these specific projects, the space industry offers a vast array of use cases for separation kernel-based operating systems like PikeOS. One of the key elements of the Space segment is the capability to pursue the mission objectives under all conditions, even when parts of the satellite or probe are no longer working due to a malfunction of any kind. The ECSS explicitly mandates this: “Provision of adequate control functions to configure the on-board systems for the execution of nominal mission operations, failure detection, identification, isolation, diagnosis and recovery and maintenance operations.”

Such control functions (telecommands) provided at each level of the system hierarchy shall be capable of achieving the mission objectives under all specified circumstances. This can include the use of redundant equipment to meet the overall system reliability requirements. It usually involves an active and a backup subsystem. A key factor for this is the capability of PikeOS to evaluate the status of the partition via its internal monitoring facility which allows to obtain information of the partition status via OS monitoring.

Figure 1: PikeOS Monitor & Control Architecture

A redundant configuration usually consists of an active hardware system and a cold backup hardware which do continuously handshake to test availability. Should the active system fail, the failover takes place when no handshake occurs anymore. Cold backup management can be achieved in several ways; for example the main application may request the monitor to deactivate the driver for the primary hardware and activate the one for the backup. Yet the application can still receive the same input from the same channel, but only from the backup and no longer from the primary hardware. Another possibility would be a hot backup, running in parallel with the primary hardware. In this case, the failure detection is the same as in the previous one, however, as the hot backup is already running, there is no need to start it, as it is already generating output data. When primary and backup systems are implemented by means of PikeOS partitions, the error in the primary system can be detected by the instrumentation subsystem and given to a Monitor Application in a service partition, which can specify to the output part from which subsystem the valid data will arrive (red command line in figure 1).

Use Case: Mission-critical Data Storage

One of the major objectives during space missions consists of data acquisition. On the technical side, this involves storage and transfer to the ground station. In the past, packet-oriented data structures have widely been used. As a consequence, recorded data had been sent to the ground station in a sequential and inflexible way.

Future missions with a huge demand on data transfer may significantly benefit from prioritization based on meta data information. This is where file-based systems come into play, as those also provide better visibility on the data stored by using folders to group the information. The meta data assigned to a file or folder may involve the date of creation and modification, data type and access policies.

Also, most recent space missions are using platform storage not only for scientific data but also to hold mission-critical items like telecommand timelines, application software (ASW) images as well as additional system configuration files.

Figure 2: PikeOS FTS, FMS, CFS Architecture

Figure 2 shows the proposal of a state-of-the-art approach for implementing a platform storage system. The core of the system is the file management service (FMS), which provides its services to several clients, such as scientific applications or the file transfer service (FTS). The latter might exemplarily base on the file delivery protocol (CFDP) as specified by the consultative committee for space data systems (CCSDS) and is not in the scope of the FMS itself. In the present use case, the file management service is linked against the PikeOS certifiable file system (CFS). The certifiable file system (CFS) is a PikeOS component that provides a failsafe file system with more functionality than the PikeOS native file system. In addition to the basic file operations implemented by the internal PikeOS file providers (open, close, read, write, map, ioctl, lseek, stat), the CFS can also handle directories and file manipulations (create, delete, rename, truncate, chmod). It is still a simplified file system compared to standard Linux file systems. The CFS supports metadata for files and folders.

The CFS can be mounted and unmounted at runtime. CFS is designed to run on block devices with a configurable block size. The block access service (BAS) is implemented in the PikeOS kernel space. Permanent as well as volatile memory block drivers are available. Memory is usually protected by additional Cyclic Redundancy Check (CRC) bits in order to correct Single Event Upsets (SEU).

More information at www.sysgo.com/pikeos