Project Overview

CubedOS was developed with the purpose of providing a robust software platform for CubeSat missions and of easing the development of CubeSat flight software. In many respects the goals of CubedOS are similar to those of the Core Flight System (cFE/CFS) written by NASA Goddard Space Flight Center. 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 provide some other correctness properties in certain cases.

CubedOS is being used at Vermont Technical College in the Lunar IceCube mission, a collaborative effort between Morehead State University, NASA, Busek Inc., and Vermont Technical College. However, the intent is for CubedOS to be general enough and modular enough for other groups to profitably 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 also allows modules, or parts of modules, to be written in full Ada or C if appropriate. This allows CubedOS to take advantage of third party C libraries or to integrate with an existing C code base.

CubedOS can run directly on top of the hardware, or on top of an operating system such as Linux or VxWorks, with the assistance of the Ada runtime system. 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. Although these modules would not be widely portable, they could, in some cases, be written to provide a kind of low level abstraction layer (LLAL) with a portable interface. Because our current work is focused on one specific mission and its needs, we have not yet attempted to standardize the LLAL interface. However, we see that as an area for future work.

The architecture of CubedOS is a collection of active and passive modules, where each active module contains one or more Ada tasks. Although CubedOS is written in SPARK there need not be a one-to-one correspondence between CubedOS modules and SPARK packages. In fact, modules are routinely written as a collection of Ada packages in a package hierarchy.

Critical to the plug-and-play nature of CubedOS, each active module is self-contained and does not make direct use of any code in any other active module, although passive modules serving as library components can be used. All inter-module communication is done through the CubedOS infrastructure with no direct sharing of data or executable content. In this respect CubedOS modules are similar to processes in a conventional operating system. One consequence of this policy is that a library used by several modules must be either duplicated in each module or provided as an independent, passive module of its own. In this respect passive modules 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 or navigation algorithms, 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 (even encouraged). Having a standard interface allows other components of CubedOS to be programmed against that interface without concern about the underlying implementation.

  • 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 real time clock module.
  • A file system interface.
  • A radio communications interface.
  • Modules providing support for CCSDS protocols.

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 busses as well as higher level drivers for sending/receiving commands from subsystems such as the radio, the power system, the camera, etc. The low level drivers constitute the CubedOS LLAL.

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. For example, our implementation of the CCSDS File Delivery Protocol (CFDP) takes advantage of this.
  • 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 Ravenscar 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 special tool, XDR2OS3, (under development) that automatically generates fully typed message encoding/decoding subprograms.

CubedOS is currently a work in progress and is being developed in parallel with the Lunar IceCube flight software. The CubedOS architecture is evolving in response to the requirements of Lunar IceCube. However, we have been careful to factor IceCube-specific work into a separate code base from CubedOS. Thus Lunar IceCube can be regarded as the first (and currently only) CubedOS application. It is our intention to release CubedOS as open source once it has been further matured and refined. Specifically, we intend to release CubedOS after the code base has been reviewed to verify that it is free from International Traffic in Arms Regulations (ITAR) restrictions. We anticipate this to happen in late 2017.