Skip navigation

Project Overview

CubedOS is intended to provide a robust software platform for CubeSat missions and to ease the development of CubeSat flight software. In many respects the goals of CubedOS are similar to those of NASA Goddard's Core Flight System (cFE/CFS). However, unlike cFE, CubedOS is written in SPARK with critical sections verified to be free of the possibility of runtime error. SPARK has also been used to prove other correctness properties in certain cases.

CubedOS is intended to be general enough and modular enough for many different groups to employ the system. Since every mission uses different hardware and has different software requirements, CubedOS is designed as a framework into which modules can be plugged to implement whatever mission functionality is required. CubedOS provides inter-module communication and other common services required by many missions. CubedOS thus serves both as a kind of operating environment and as a library of useful tools and functions.

It is our intention that all CubedOS modules also be written in SPARK and at least proved free of runtime error. However, CubedOS allows modules, or parts of modules, to be written in full Ada, or even C, if appropriate. This lets CubedOS take advantage of third party C libraries or integrate with an existing C code base.

CubedOS can run directly on top of the hardware with the assistance of a suitable Ada runtime system, or on top of an operating system such as Linux or VxWorks. For example, CubedOS makes use of Ada tasking without directly invoking the underlying system's support for threads. This simplifies the implementation of CubedOS while improving its portability. However, it does require that an Ada runtime system be available for all envisioned targets.

For resources that are not accessible through the Ada runtime system, CubedOS driver modules can be written that interact with the underlying operating system or hardware more directly, even though such modules would not be widely portable.

The architecture of CubedOS is a collection of passive library packages and of active modules, each being implemented as a hierarchy of packages. Each module contains one or more Ada tasks. Thus, CubedOS applications are highly concurrent with multiple modules often active simultaneously.

Critical to the plug-and-play nature of CubedOS, each module is self-contained and does not make direct use of code in any other module, although library components can be shared. All inter-module communication is done via message passing through the CubedOS infrastructure, with no direct sharing of data. In this respect, CubedOS modules are similar to processes in a conventional operating system. In contrast, library packages resemble shared libraries in a conventional operating system and have similar concerns regarding task safety and global data management.

In the language of operating systems, CubedOS can be said to have a microkernel architecture where task management is provided by the Ada runtime system. Both low-level facilities, such as device drivers, and high level facilities, such as communication protocol handlers, are all implemented as CubedOS modules. All modules are treated equally by CubedOS; any layered structuring of the modules is imposed by programmer convention.

In addition to inter-module communication, CubedOS provides several general purpose facilities. In some cases, only the interface to the facility is described and different implementations are possible, depending on individual mission needs. Having a standard interface allows other components of CubedOS to be programmed against that interface without concern about the underlying implementation.

The core modules of CubedOS include the following:

  • An asynchronous message passing system with mailboxes. This, together with the underlying Ada runtime system constitutes the "kernel" of CubedOS.
  • A runtime library of useful packages, all verified with SPARK.
  • A log server module for gathering and managing system logs.
  • A time server module providing low-resolution timing services.
  • A file system interface module.
  • A publish/subscribe server that can be used to decouple data producers from data consumers.
  • A command interpreter module for processing "scripts" of commands sent by mission planners.

A CubedOS system also requires drivers for the various hardware components in the system. Although the specific drivers required will vary from mission to mission, CubedOS does provide a general driver model that allows components to communicate with drivers fairly generically. In a typical system there will be low level drivers for accessing hardware buses as well as higher level drivers for sending/receiving commands from subsystems such as the radio, the power system, the camera, etc.

CubedOS provides several advantages over "home grown" frameworks:

  • The message passing architecture is highly concurrent and allows many overlapping activities to be programmed in a natural way.
  • The architecture provides a lot of runtime flexibility; programs can adapt their communication patterns at runtime.
  • The architecture is consistent with the restrictions of Ada's Jorvik profile.

CubedOS also has some significant disadvantages over more customized solutions:

  • Because CubedOS messages are just octet sequences, there is runtime overhead associated with encoding and decoding them.
  • CubedOS sacrifices some static type safety; decoded messages must be validated at runtime with type errors being handled during the validation process. This is particularly worrisome in light of CubedOS's goal of providing robust assurances of correctness. We mitigate this problem somewhat with the use of a companion tool, Mercury, that automatically generates fully typed message encoding/decoding subprograms.

CubedOS is currently a work in progress. It has not yet flown in space, but we are anxious to exercise it in a realistic setting. Although developed primarily for CubeSat missions, it can also serve as a general embedded systems framework. This makes ground testing easier and expands the scope of possible use-cases for CubedOS. The system has been designed with this more general vision in mind.