A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions

: Nanosatellite missions are becoming increasingly popular nowadays, especially because of their reduced cost. Therefore, many organizations are entering the space sector due to the paradigm shift caused by nanosatellites. Despite the reduced size of these spacecrafts, their Flight Software (FSW) complexity is not proportional to the satellite volume, thus creating a great barrier for the entrance of new players on the nanosatellite market. On the other side, there are some available frameworks that can provide mature FSW design approaches, implying in considerable reduction in software project timeframe and cost. This paper presents a comparative survey between six relevant fl ight software frameworks, compared according to commonly required ‘New Space’ criteria, and fi nally points out the most suitable one to the VCUB1 reference nanosatellite mission.


INTRODUCTION
Flight Soft ware (FSW) is soft ware that runs on a processor embedded in a spacecraft 's avionics.It is responsible for managing on-board activities, data processing and spacecraft health and safety.
Th e name "fl ight soft ware" refl ects the location where it executes, i.e. in the spacecraft , to diff erentiate from "ground soft ware", which runs in the ground segment.It is considered a high-risk system because it interacts directly with spacecraft hardware, controlling virtually all of the onboard systems in real time at various levels of automation (Dvorak 2009).In such a domain, the level of failure protection and recovery is generally higher than in usual computer systems as a result of the lack of accessibility to the hardware aft er launch, as well as the space environment intrinsic characteristics.
In a space mission, the responsibility for the tasks realization is shared between the ground and the space segment.Th e fi rst space missions allocated almost all tasks to the ground segment.In such missions, the space segment was a mere executor of the commands sent from the ground.By adding computers to the space segment, the operators were allowed to start delegating tasks to on-board execution (Kucinskis and Ferreira 2013).With the evolution of spacecraft on-board computer and electronics, as well xx/xx 02/13 missions are increasingly demanding more powerful, autonomous, robust and flexible flight software to meet complex mission requirements.
Despite that fact, Eickhoff (2012) states that the on-board computer, flight software and the operations design are normally a challenge for new entrants in the space field, especially due to the lack of specialized literature.
On the other side, there are some open-source frameworks devoted to space projects.They were created by space agencies, universities, or space companies to serve as reference designs and promote code reuse in their future projects.Being a relatively new option for FSW development, these frameworks have not so far achieved a significant adoption outside their host organizations.
The start of a FSW project from scratch, especially for new organizations, can be a very expensive endeavor.Usual software systems development normally profits from existing Software Development Kits (SDK), frameworks, design patterns and different tools to support the developer's work.In spacecraft projects, code reuse and framework usage are not wide spread concepts.Schmidt et al. (2004) state that the use of a well-established software framework leads to a shorter development program, with reduced costs and improved quality.These consequences are beneficial for space organizations, which is what motivated the current survey.
Six relevant FSW frameworks were analyzed according to the nanosatellite reference mission software selection criteria.This project being typical of what is called 'New Space' .
The reference mission, named VCUB1, is an in-orbit demonstration 6U CubeSat under development at the Brazilian space company Visiona Space Technology S.A.This CubeSat project is a typical New Space one: small team, short schedule, reduced budget, piggyback launch, best-effort reliability paradigm (almost no equipment redundancy on-board, no rad-hard protection in most equipment), simplified verification and validation (V&V) cycle on a single spacecraft protoflight unit.
Regarding the FSW, starting the design from scratch was not a feasible option due to the project tight schedule and limited resources.It was decided to benefit from an existing flight-proven FSW framework to serve as design paradigm.

RELATED WORK
There are few comparisons of frameworks for spacecraft use.One of them was presented by Rexroat (2014).He compares several candidate middleware, aiming at his target distributed embedded systems, which were Unmanned Air Vehicles (UAV) and CubeSats.Nevertheless, the author considered not only service-level middleware, but also lower level middleware at Network (e.g.SpaceWire) and Distribution Layer (e.g.MIL-STD-1553) levels.
Some of Rexroat's selection criteria were: • Network communication -node-oriented versus message-oriented systems

•
Reliability -in terms of message delivering: at-most-once, at-least-once, exactly-once

•
Scalability -abstraction in the following aspects: access, location, migration and replication

•
Heterogeneity -portability and interoperability with different hardware, network or software MAVLink, which was originally developed for the UAV world, was his middleware solution of choice for UAVs and CubeSats, NASA core Flight System (cFS) being second in the rank.
The present work focuses, differently from Rexroat, on software design aspects for a nanosatellite mission rather than in network aspects.

'NEW SPACE' AND THE VCUB1 MISSION
The changes caused by the greater involvement of the private sector in the global space activity in the past several years is called 'New Space' (Paikowsky 2017).This term is used as the opposite for 'Old Space' , i.e. the existing ecosystem since the beginning of space activities, characterized by being mainly controlled by national activity and mostly a State-only business.

xx/xx 03/13
In New Space context, the technological miniaturization of satellites enabled a decrease in the costs of developing and launching satellites.The fact that clients and investors are private actors causes a shift in the financial models from cost plus to fixed price.This change requires different methods of management and demands shorter durations of time devoted to Research and Development (R&D).Satellites, systems, and components can now be purchased off the shelf and satellites spend relatively less time in orbit.As a result, project management is more inclined to take risks, to perform technological demonstrations while in service and generally does not aim for 100% success in orbit, as was the case for satellite development under the 'Old Space' ecosystem (Paikowsky 2017).
Among of the most successful results of New Space are the CubeSats.The CubeSat concept was publicly proposed in 2000, with the first CubeSats launched in 2003 (Swartwout 2013).CubeSats are small cuboid-shaped satellites developed around multiples of the basic volume unit of 10 cm × 10cm × 10cm, defined as 1U.
CubeSats opened quicker and cheaper mission opportunities due to the standardization effort done specially with the CubeSat dispenser or deployer, which was gradually being accepted as secondary payload by multiple launch agencies (Chin et al. 2008).
VCUB1 reference mission is a 6U demonstration CubeSat under development at the Brazilian space company Visiona Space Technology S.A.The target launch date is foreseen for 2020.
The spacecraft contains two payloads.One is a multispectral optical camera, devoted to remote sensing.The second is a data collection radio based on FPGA, allowing two-way narrow-band data communication.The satellite will be placed in a LEO Sun-Synchronous orbit with an average of 3 daily passes over Brazil (Conto et al. 2018).
This mission was targeted for being low-cost, fixed price, using mainly Commercial Off-The-Shelf (COTS) parts.It was conceived as an R&D project to validate in-orbit some company's software technologies.Therefore the project management philosophy is willing to accept some risk.The satellite will be launched as secondary payload, susceptible to the CubeSat launch opportunities available.Consequently, it is a typical New Space mission following the CubeSat standard.
With respect to the mission FSW, the low-cost and short-schedule premises and the best-effort reliability paradigm led the team to look for a well-established open-source FSW framework compatible with CubeSat COTS On-Board Computers (OBC).

REFERENCE MISSION SOFTWARE SELECTION CRITERIA
The criteria for the flight software framework selection are summarized in Table 1, being: 1. Software code and documentation, 2. Flight heritage, 3. Small footprint 4. Quality attributes 5. Long-term support 6. User-community collaboration and 7.The consultative committee for space data systems (CCSDS) standardization.Criteria 1 to 3 came from the reference mission high-level requirements.Nevertheless, these are typical requirements from space missions, especially under the New Space paradigm.
Quality attributes (criteria 4) were inspired from Wilmot et al. (2016).Not all fourteen quality attributes identified by NASA's Software Architecture Review Board were taken, only those more closely related to software implementation.To those quality attributes, it was added Formal Specification and Well-Defined Semantics, inspired in some framework's documentation.
Criteria 5 to 7 purpose is to assess the frameworks capability to evolve and improve based on a variety of missions (Usercommunity collaboration), and possibility of standardization (CCSDS), all that performed by their sponsoring/maintaining institutions (Long-term support).
xx/xx 04/13  The framework has been recognized as expressive by a competent authority (in this case, CCSDS) and is being standardized as a reference flight software architecture

FLIGHT SOFTWARE FRAMEWORKS
There are some software frameworks that have the goal of standardizing, modularizing and decoupling the application layer from the lower layers in space projects.A review on the literature was performed to find a representative set of these architectures and their characteristics.Six state-of-the-art frameworks will be analyzed to choose which one to adopt in the nanosatellite reference mission.

GERICOS
The GEneRIC Onboard Software (GERICOS) framework was developed and qualified by LESIA (Laboratoire d'Études Spatiales et d'Instrumentation en Astrophysique), a French laboratory for space research, for the rapid development of payload flight software.

xx/xx 05/13
The GERICOS studies started in 2007.At the time there was no off-the-shelf software solution available.At the end of 2015 the Radio Plasma Wave instrument flight software was delivered, built and qualified using GERICOS framework (Plasson et al. 2016).This instrument will fly on ESA's Solar Orbiter mission, expected to be launched at 2020.GERICOS framework offers a set of reusable and customizable flight software components, written in C ++ .It is composed of 3 layers, as shown in Fig. 1: • GERICOS::CORE: Lightweight, optimized implementation of the active object paradigm on top of a real-time kernel.It includes the concepts related to real-time and embedded systems, such as interrupts, synchronized objects, shared resources and circular buffers.This layer allows a developer to quickly build a real-time application using the objectoriented approach while being independent from a specific real-time operating system and from a specific hardware target.Each active object has its own message queue and computational thread.
• GERICOS::BLOCKS: offers a set of reusable software components for building flight software based on generic solutions to recurrent functionalities: telecommand management, telemetry management, some of the European Coordination for Space Standardization (ECSS) Packet Utilization Standard (PUS) services, mode management, time management, CCSDS protocol management, etc.
• GERICOS::DRIVERS: implements software drivers corresponding to COTS IP cores used in the chip.LESIA is working to make possible the use of GERICOS framework by other organizations.One evolution already done for GERICOS::CORE is its port to ARM processors, that allowed GERICOS use in the context of CubeSats, as made on the PicSat mission launched in January 2018 (Lapeyrere et al. 2017).The code nevertheless is not yet open-sourced, preventing a more detailed analysis of the framework architecture.

GERICOS::BLOCKS
Building blocks for space so ware GERICOS::CORE Active object layer for embedded so ware

NASA CFS
The core Flight System (cFS) platform is a 3-layered flight software architecture developed by NASA Goddard Space Flight Center (GSFC).It provides an application runtime environment independent from both operating system and hardware.cFS was originally developed as NASA Class B software for GSFC science missions, based on the heritage of successful missions.It is composed of three layers, as shown in Fig. 2, from bottom to top:   The CCSDS application support services working group is currently in charge of conducting a project called "NASA cFS as a CCSDS Onboard Reference Architecture".This initiative highlights the importance of cFS.The project code and documentation is available at NASA's GitHub page (https://github.com/nasa/cFE)and there is also a community page (http://coreflightsystem.org/) for getting help about cFS and questions and answers.

SAVOIR/CORDET
xx/xx 07/13 The European Space Agency (ESA) launched a space standardization initiative called Space AVionics Open Interface aRchitecture, a.k.a.SAVOIR, which formally started in November 2008, as an outcome of ESA's yearly workshop called ADCSS (Avionics Data, Control and Software Systems) (SAVOIR 2018).
One of SAVOIR goals is to identify the main avionics functions and to standardize the interfaces between them, in a way that allows building blocks to be developed and reused across projects (Terraillon 2012).Among the several working groups of ESA's SAVOIR initiative, there was the SAVOIR-FAIRE group, which is in charge of the on-board software reference architecture.As part of this effort, an architecture was proposed (named Component Oriented Development Techniques -COrDeT) based on the segregation of the application software and the execution platform (Terraillon 2012).Figure 3 shows a static representation of the COrDeT reference architecture.
COrDeT output from SAVOIR group was a reference architecture with no particular implementation and API rules.Nevertheless, P&P software, one of the companies of the consortium funded by ESA to specify COrDeT, has provided a formal specification of the framework and a C-language implementation of COrDeT called C2, which is publicly available at the company's webpage (P&P software 2018).
C2 implementation of COrDeT is a service-oriented application with strong correspondence to ECSS PUS defined services.C2 implementation is being used in ESA's CHEOPS satellite payload software, which will be flying in 2019 (P&P software 2018).
The CCSDS application support services working group is in charge of conducting a project called "SAVOIR as a CCSDS Onboard Reference Architecture", expected to finish by July 2020.

KUBOS
Kubos is a space software start-up company located in Texas, USA, founded in 2014.The company developed the KubOS flight software framework, which has BSP for 3 major CubeSat OBC's.Its full package is open-source.Users can pay for additional features, like support services and software updates (kubos 2018).
KubOS stack is shown in Fig. 4. Its layers are: • Kubos Linux: a custom Linux distribution designed with embedded devices in mind.It focuses on including only drivers that are useful for space applications (eg.I2C and SPI, rather than display drivers), multi-layer system validation and recovery logic.Kubos Linux projects are built into binaries, which will run as Linux user space applications

•
Kubos services: a Kubos service is defined as any persistent process used to interact with the satellite.Services rarely make decisions but will allow the user to accomplish typical flight software tasks such as telemetry storage, file management, shell access, and hardware interaction xx/xx 08/13 • Mission applications: mission applications compose the upper layer and are virtually anything that governs the satellite's behavior.For example, they govern state management, accomplish scripted tasks and monitor onboard behavior.Each application is typically dedicated to a certain mode or isolated task the satellite is supposed to accomplish to keep them lightweight and portable.They can be simple, such as a telemetry beacon application, or complex, such as a payload operations application (Kubos 2018).KubOS is open-sourced in a GitHub repository.First time users can create its own KubOS project using a SDK provided by the company.It was noticed that KubOS is light-weighted and provides the basis for writing mission applications using Rust or Python languages.C and Lua are also claimed to be supported (Kubos 2018).

CAST SOFTWARE REFERENCE ARCHITECTURE
China Academy of Space Technology (CAST) is the main spacecraft development and production facility in China.Xiongwen et al. (2015) pointed out that the problem of spacecraft avionics software reuse in space projects is an important issue to be solved in Chinese programs.
A spacecraft avionics software architecture has been designed and implemented by CAST technicians.It is based on Spacecraft Onboard Interface Services (SOIS) recommended by CCSDS and Packet Utilization Standard (PUS) recommended by European Cooperation for Space Standardization (ECSS) standards.
According to Xiongwen et al. (2015), the results of the test and validation demonstrate that the software architecture has great positive effects on software reuse.Under Chinese National Space Agency (CNSA) lead, this effort is gaining CCSDS standardization status through a dedicated working group, which also happened with NASA cFS and ESA SAVOIR.
Figure 5 shows CAST software reference architecture.This reference architecture is composed of:

•
Operating system layer: the interface of operating system is encapsulated and a uniform Application Program Interface (API) is provided by the operating system layer.Any operating system that supports this interface can be used in the avionics system

•
Middleware: common service platform between the operating system layer and application layer.It has standard program interface and protocols, and can realize the data exchange and cross support among different hardware and operating system

•
Application layer: contains most of the common functions of avionics system.The implementation of this layer may be different for different projects.Nonetheless, CAST source-code architecture is not available as open-source.No mention was found regarding any flight heritage.

NANOSAT MO FRAMEWORK (NMF)
The NanoSat Mission Operations service Framework (NMF) is a flight software project that will be flying on an experimental ESA sponsored nanosatellite called OPS-SAT (target launch date in mid-2019).This mission is intended to demonstrate the improvements in mission control capabilities that will arise when satellites can fly with more powerful on-board computers.
NMF provides a standard on-board software framework for nanosatellites based on the CCSDS MO framework (CCSDS 520.0-G-3).It facilitates not only the monitoring and control of the nanosatellite software applications, but also the interaction xx/xx 09/13 with the platform peripherals.This is achieved by using the CCSDS mission operations monitor and control services included in the MO service suite and by defining a set of new platform services (Coelho et al. 2016).
OPS-SAT spacecraft provides an experimental platform composed of a MityARM device with 1 GB of RAM, an ARM processor with 925 MHz and a lightweight version of Linux (Coelho 2016).The increase of computing power, a trend for CubeSat projects, allowed the NMF framework to shift from usual embedded C or C++ lightweight software to Java multi-platform agnostic applications.Figure 6 presents NMF architecture with one application only.For deploying multiple applications that can be concurrent in the use of peripherals, NMF proposed the use of two new components.One of them is the NanoSat MO Supervisor, responsible for managing the applications and providing platform services that can be used by different applications.The other is the NanoSat MO connector, responsible for connecting to the platform services, exposing them to the logic of the applications and interfaces to monitor and control the application from ground or from other applications.Coelho et al. (2016) mentioned that the main difference between NMF and classical FSW frameworks is that NMF is developed for systems that are not scarce in resources but can run complete operating systems.NMF framework is open-sourced in a GitHub public repository and comes along with an SDK, OPS-SAT satellite simulator, and technical documentation for running the software.

RESULTS
Table 2 presents the frameworks comparison study.The conformance to each selection criteria presented in previous section was individually assessed.Some of the frameworks (GERICOS and CAST) are not open-source yet, being available only to their developing organizations, making difficult further technical analysis over them.
Among the open-source frameworks (NASA cFS, COrDeT C2, NanoSat MO and KubOS), the amount of documentation each one provides is different.COrDeT, for example, traces individually each software requirement to the code and to verification evidence, while NanoSat MO relies mostly on the CCSDS 520.0-G-3 documentation that inspired the framework creation.
Regarding semantics, GERICOS and COrDeT are the only ones that created their own semantics, fully specifying their architecture behavior.The others have their syntax spread over the documentation and sometimes one has to look into the code to get the correct comprehension about the software architectures.
NASA cFS and GERICOS are the frameworks that currently have successfully flown on previous missions.The others will acquire flight heritage in the next few years.
A comparison on each software SDK reveals that cFS OpenSatKit is the most "turn-key" solution.It provides not only a running instance of cFS bundle but also an open-source ground control software tailored to interface with cFS and a CubeSat simulator example, providing great insights on the framework functionality.
The CCSDS application support services working group is currently conducting some projects called "CCSDS Onboard Reference Architecture" for three particular frameworks: SAVOIR, CAST and NASA cFS.This evidence shows that these architectures have gained particular recognition by CCSDS due to their technical quality and considerable utilization.This standardization effort will also contribute to their long-term perpetuation and to spread their concepts to other international organizations.
A comprehensive analysis on Table 2 leads to three frameworks that are compliant with most of the selection requirements: SAVOIR/COrDeT, KubOS and cFS.SAVOIR/COrDeT is the most complete one with respect to software documentation and syntax definition.But it has no flight heritage and depends on a non-defined message-passing middleware to run.Therefore, it could not be immediately used.
KubOS is an architecture conceived specifically for the CubeSat world, as its name suggests.In terms of code footprint and portability, it is a very suitable architecture with a turn-key software package.However, besides its absence of flight heritage, the reference mission is also looking for a framework with assured long-term support.Some ways to ensure that are by public-access standards (CCSDS is an accredited agency) and the existence of an established software control board committee.
Regarding software quality and long-term technical support, cFS is managed by a dedicated NASA configuration control board that controls and approves future changes to cFS core and main applications.Software core maintenance and evolution is then done by NASA, which is also the main user of cFS framework.The long-term support criterion is key for space organizations that want to rely on a third-party framework.
According to the results presented in the frameworks comparison (Table 2) and the criteria defined in previous section, NASA cFS was the most compliant framework to the nanosatellite reference mission needs and constraints.It was therefore adopted by VCUB1 mission as design baseline.

CONCLUSIONS AND FUTURE WORK
Six relevant FSW frameworks were analyzed with respect the nanosatellite reference mission selection criteria.The authors' CubeSat mission can be considered a typical New Space project due to low-cost, short-schedule, management and reliability philosophy and use of COTS parts characteristics.The solution adopted after careful compliance analysis was NASA cFS.
Many software architectures elaborated by the academia were found by the authors during the literature research.These solutions were often developed around a single nano or small satellite project in their respective universities.These architectures, for example Switerzland EPFL' BIP framework (Mavridou et al. 2016) and US Vermont' CubedOS (Vermont Technical College 2017), despite interesting, were not analyzed due to the decision to emphasize frameworks with potential reusability across several projects.These solutions can though be explored in a future work.
It is worth acknowledging that two frameworks were recommended to the authors consideration too late to be cogitated for the paper: RODOS and F Prime.The German "Realtime Object-Oriented Distributed Operating System" (RODOS) (Dannemann and Montenegro 2013) contains an object-oriented middleware that is an interesting open-source framework for space applications.NASA JPL "F Prime" framework was recently released.It states some differences compared to cFS.For example, F Prime architecture uses static topologies with typed connections, whereas cFS uses publish-subscribe over a software bus (Bocchino Jr. et al. 2018).RODOS and F Prime will be explored in a future work.
that emphasizes the separation of concerns by means of loosely coupled independent software components or applications.It favors software code implementation property of the architecture and applications supporting their use on systems other than the initial target system.It generally involves software isolation and abstraction techniques 5 Long-term support Framework software support guaranteed for long-term according to the sponsoring/maintaining institution strategic plan 6 User-community collaboration Users return of experience expressed in a centralized internet open code repository.Capacity of universally opening ticket issues, forking and uploading software code, all that controlled and moderated by the sponsoring institution 7 CCSDS standardization Application so ware (mission speci c)Hardware targetBoard support package libraries RTOS ( readX, RTEMS, FreeRTOS...) GERICOS::DRIVERS Grspw, AhbStat, Inqmp, Amba...

Table Services (
TBL): manages all cFS table images

•
Time Services (TIME): manages spacecraft internal time and distributes tone signal to querying applications