NanoSat MO Framework: Achieving On-board Software Portability

Transcription

1 SpaceOps Conferences May 2016, Daejeon, Korea SpaceOps 2016 Conference / NanoSat MO Framework: Achieving On-board Software Portability César Coelho 1, Dr. Mario Merri 2, Dr. Mehran Sarkarati 3 European Space Agency, ESA/ESOC, Robert Bosch Strasse 5, Darmstadt, Germany Prof. Otto Koudelka 4 Graz University of Technology - Institute of Communication Networks and Satellite Communications, Inffeldgasse 12, 8010 Graz, Austria AGSA API ARM CAN CCSDS CFDP cfs COM COTS DLR EGOS ESA ESOC The recent miniaturization of space components and electronics has allowed the design of smaller satellites which are considerably cheaper to build and launch than conventional satellites. This decrease in the total cost of a space mission has boosted a new growing market for small satellites and, as the number of small satellites keeps increasing, there is a raising demand for reusable software across nanosatellites. The NanoSat MO Framework provides a standard on-board software framework for nanosatellites based on the CCSDS MO framework, that facilitates not only the monitoring and control of the nanosatellite software applications, but also the interaction 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 which shall also follow the MO services framework architecture. The paper describes the NanoSat MO Framework, the associated set of high-level components and possible end-to-end deployment scenarios including the reference implementation in ESA s OPS-SAT mission. Moreover, defines an app in the context of the NanoSat MO Framework, as well as, how they can become portable software entities and be distributed among different platforms. The framework opens up many possibilities for future work and extensions due to its modular and flexible design approach which is not limited to the space segment but extends down to ground by providing all the building blocks for a complete and free end-to-end solution. Nomenclature = Advanced Ground Software Applications = Application Programming Interface = Advanced RISC Machine = Controller Area Network = Consultative Committee for Space Data Systems = CCSDS File Delivery Protocol = core Flight System = Common Object Model = Commercial Of-The-Shelf = Deutsches Zentrum für Luft- und Raumfahrt (German Aerospace Center) = ESA Ground Operation System = European Space Agency = European Space Operations Centre 1 PhD Researcher, Graz University of Technology/ESA OPS-GDA, CCSDS SM&C Working Group Member, Cesar.Coelho@esa.int 2 Head of Mission Data Systems Division, ESA OPS-GD, CCSDS MOIMS Area Director, Mario.Merri@esa.int 3 Head of Applications and Special Projects Data Systems Section, ESA OPS-GDA, CCSDS MP Working Group Chair, Mehran.Sarkarati@esa.int 4 Head of the Institute of Communication Networks and Satellite Communications, Graz University of Technology, Koudelka@tugraz.at 1 Copyright 2016 by European Space Agency. Published by the, Inc., with permission.

2 EUD = EGOS User Desktop FTP = File Transfer Protocol HTTP = Hypertext Transfer Protocol M&C = Monitor and Control MAL = [MO CCSDS] Message Abstraction Layer MCS = Mission Control System MO = [CCSDS] Mission Operations MMI = Man-Machine Interface NASA = National Aeronautics and Space Administration OBSW = On-Board Software OPS-SAT = ESA OPS-SAT mission RISC = Reduced Instruction Set Computing RMI = Remote Method Invocation SPP = Space Packet Protocol URI = Uniform Resource Identifier I. Introduction raditional on-board software (OBSW) is seen as an almost immutable software which is developed for a Tparticular use where future updates imply the patching of specific memory areas. Moreover, many times the OBSW is written for embedded devices which will never be updated again. The sudden increase of commercial of-the-shelf (COTS) hardware for nanosatellites with great amounts of processing power are allowing space community to think and move towards spacecraft with system environments capable of running full Operating Systems. OPS-SAT is a good example of that, as it 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. 1 The raising market of smartphones and tablets brought new ideas into software by providing quick development of software using well defined libraries from Android and ios. Additionally, Android apps gave the community an extra degree of freedom by making the mobile apps portable entities of software, where the same app can run on the hardware of different vendors as long as the devices have the same underlying Android framework. The NanoSat MO Framework intends to change the current view on OBSW by turning it into apps that can be easily developed, tested, deployed and updated at any time without causing any major problem to the spacecraft. Furthermore, it will be possible to use the same app on different spacecraft platforms as long as the NanoSat MO Framework components are used. This means that an app developed using the NanoSat MO Framework will be able to, for example, publish telemetry, receive telecommands or access the GPS device on OPS-SAT and on other nanosatellites without any change in the code. 2 A. CCSDS Mission Operations services Framework CCSDS Mission Operations is a set of standard end-to-end services based on a service-oriented architecture which are currently being defined by the Consultative Committee for Space Data Systems (CCSDS) and it is intended to be used for mission operations of future space missions. The layered MO service framework allows mission operation services to be specified in an implementation and communication agnostic manner. The core of the MO service framework is its Message Abstraction Layer (MAL) which ensures interoperability between mission operation services deployed on different framework implementations. The MO services are specified in compliance to a reference service model, using an abstract service description language, the MAL. This is similar to how Web Services are specified in terms of Web Services description language WSDL. For each Figure 1. CCSDS MO Framework. The framework is stratified in 4 layers: Transport Layer, Message Abstraction Layer, MO Services Layer and Application Layer. 2

3 concrete deployment, the abstract service interface must be bound to the selected software implementation and communication technology. Standardization of a Mission Operations Service Framework offers a number of potential benefits for the development, deployment and maintenance of mission operations infrastructure: 4 - Increased interoperability between agencies; - Re-usage between missions; - Reduced costs; - Greater flexibility in deployment boundaries; - Increased competition and vendor independence; - Improved long-term maintainability; The deployment of standardized interoperable interfaces between operating Agencies, the spacecraft and internally on-board, would in itself bring a number of benefits. Each organization would be able to develop or integrate their own multi-mission systems that can then be rapidly made compliant with the spacecraft. It does not preclude the re-use of legacy spacecraft, an adaptation layer on the ground is required to support it, rather than many mission-specific bespoke interfaces. In the on-board environment, where software development costs are considerably higher due to platform constraints and reliability requirements, software reuse can bring immense savings. 14 B. OPS-SAT The recent miniaturization of space components and electronics has allowed the design of smaller satellites which are considerably cheaper to build and launch than conventional satellites. This decrease in the total cost of a space mission has boosted a new growing market for small satellites and, as the number of small satellites keeps increasing, there is a raising demand for reusable software across nanosatellites. ESA and its European industry partners generate many new and innovative ideas for advancing European space technology regarding mission operations every year but the majority of these innovations never make it to orbit. OPS-SAT emerged, providing a low cost in-orbit laboratory available for authorized experimenters to test, demonstrate and validate their developed software experiments. OPS-SAT is the first CubeSat designed by ESA and is a safe experimental platform which shall fly in a LEO dawn-dusk orbit. OPS-SAT makes available a reconfigurable platform, at every layer from channel coding upwards, and it will be available for experimenters wishing to test and demonstrate new software and mission operation concepts. 3 II. NanoSat MO Framework The NanoSat MO Framework provides a standard on-board software framework for nanosatellites that facilitates not only the monitoring and control of the nanosatellite software applications, but also the interaction with the platform. This is achieved by using the Mission Operations Monitor and Control services included in the MO service suite and by defining a set of new Platform services which shall also follow the MO services framework architecture. Furthermore, a new set of services will be defined for software management. In the context of the NanoSat MO Framework, an app is defined as an on-board software application that can access the platform peripherals via the Platform services and additionally can be started, monitored, stopped, killed, installed, uninstalled and updated from ground. Optionally, it can expose M&C services to ground and to other apps running on-board. By having a central Directory service were all the apps register their services URIs, it is possible to discover them both from space and ground. This allows the development of apps that use services made available by other apps on-board. One promising envisaged use case is having an app providing file transfer capabilities to other apps. Furthermore, apps are allowed to have their own MO services API implementation that is independent of the underlying transport technology. This opens the possibility of easily embedding new future standard APIs into an app for testing purposes, for example, the CCSDS MO Planning and Scheduling services could be developed and tested in an app. There are a set of high-level components that allow the establishment of complete end-to-end deployment scenarios. Each high-level component must choose which services and transport layers shall be used depending on the functionalities and deployment location of that component. Additionally, some of the them might need to be 3

4 further whittled depending on the chosen platform. With this in mind, a modular and flexible approach was taken for the design and development in order to maximize reuse and customizations between different missions and user needs. A software bundle is being assembled with all the NanoSat MO Framework related software. It comes with a collection of services sets, many transport layers, generic and specific implementations of the high-level components, a set of apps, ground demos, a Configuration Manager tool to configure apps and an OPS-SAT Software Simulator. The software bundle will be available online for free under ESA s open-source license. A. Monolithic vs. Apps For some deployments, the concept of running multiple apps might not be necessary and therefore a simpler Monolithic Architecture can be deployed where the app is directly plugged on top of it. This is especially easier for debugging an app during its development phase. For running multiple apps, using the monolithic architecture would imply that each app would load the full stack of services, using resources that could be shared between apps. In order to allow the use of the same platform peripheral by different apps, the introduction of two new components is necessary. First, the NanoSat MO Supervisor, responsible for managing the apps (start/stop) and providing Platform services that can be utilized by different apps. And second, the, the component responsible for connecting to the Platform services, exposing them to the business logic of the app and additionally exposing interfaces to monitor and control the app from ground or from other apps. Figure 2. NanoSat MO Monolithic Architecture. The app business logic is connected to the via defined interfaces. As a result, it will be possible to share hardware resources by different software entities, for example, the same GPS unit can be accessed by 2 different apps running simultaneously. However, it is important to mention that this might not be possible for every single platform peripheral, for example, an ADCS unit should not be controlled by two different apps simultaneously. The High-level components section explains in more detail both the NanoSat MO Supervisor and the NanoSat MO Connector. App A App B App C NanoSat MO Supervisor Figure 3. Apps sharing the NanoSat MO Supervisor 4

5 After developing and debugging an app with the Monolithic Architecture, swapping it to use the apps architecture with the won t take much effort because the exposed interface towards the app developer remains the exact same. B. Portability The idea of creating portable on-board software has been introduced by A. A. Koltashev in A Practical Approach to Software Portability and their approach relies on the strong typing and separate compilation of Modula-2 programming language. 5 Another existing onboard software framework is core Flight System (cfs), a product line that uses a layered architecture and compile-time configuration parameters which make it portable and scalable for a wide range of platforms. The software layers that defined the application run-time environment are now under a NASA-wide configuration control board with the goal of sustaining an open-source application ecosystem. 6 Even though cfs follows the concepts of stratification, portability and code reuse, it is developed with a focus on embedded software systems while the NanoSat MO Framework is developed for systems that are not scarce in resources but are capable of running complete Operating Systems. The CCSDS MO Framework is composed of 4 different layers: Transport Layer, Message Abstraction Layer (MAL), MO Services Layer and Application Layer. By inheriting the existing stratification in the CCSDS MO Framework, the software business logic can be separated from the transport underneath. Java was chosen as programming language because it facilitates the deployment of the compiled code since Java follows the WORA ideology ( write once, run anywhere ) which will allow the compiled apps to be easily deployed between different platforms independently of the underlying processor architecture. It is possible to develop apps that can then be used on different platforms. For example, an experiment for OPS- SAT could be developed and tested on the developer s local machine and could then be transferred to ESA for a trial on a flatsat before running on the actual mission. In order to allow consistent distribution of apps between different nanosatellite platforms a package file format will be defined. This package file format can be inspired by the current packages used by popular package managers. By combining Java development, the stratification of the CCSDS MO Framework and by introducing the concept of portable apps that can be distributed through packages and deployed on different nanosatellite platforms, portability is guaranteed. C. MO services Layer The NanoSat MO Framework comes bundled with a set of services implementations that are the building blocks of the high-level components and that can be reused in any other future project. The sets of services available in the software bundle are the following: 1) CCSDS COM services 2) CCSDS M&C services 3) CCSDS Common services (Directory service and Configuration service) 4) Platform services 5) Software Management services All the services include a ready to be used consumer and provider implementation. The first 3 sets are CCSDS services defined by the SM&C working group and are/will be international standards. The CCSDS COM services implementation provide support services to other services. The Archive service implementation has a Derby and/or SQLite database backend in order to store its COM objects. The CCSDS M&C services implementation expose an API towards the upper layer (Application Layer) to set/get parameters and execute actions. Regarding the CCSDS Common services, only the Directory service was implemented, moreover the Configuration service s COM object data model is used to hold the configurations of the services in order to restore their state upon a restart. 7 The Platform services were defined in a generic way in order to cover all the common peripherals on-board of a nanosatellites and their respective functionalities. For example, getting the current position is a functionality common to all GPS units just as taking a picture is common to all cameras. 5

6 The software bundle includes concrete implementations of the Platform services: - OPS-SAT implementation: The Platform services connect to the real OPS-SAT on-board peripherals. - OPS-SAT Software Simulator implementation: A software simulation of all OPS-SAT peripherals. The main objective of this implementation is to provide an environment for OPS-SAT Experimenters to develop and debug their apps. - AGSA FlatSat implementation: The AGSA Lab at ESOC is developing a generic flatsat for testing and validation of the ground segment and also parts of the space segment. It is composed of some OPS-SAT peripherals however it does not contain the full set and therefore this implementation shall use the simulator of the OPS-SAT Software Simulator for the missing peripherals: FineADCS, Optical Receiver and Software-defined Radio. The Software Management services were defined in order to allow the management of apps by the framework. They provide capabilities such as installing/uninstalling/updating and starting/stopping apps. The produced set of services can be provided to the SM&C working group as input for the future development of the CCSDS On-board Software Management services. D. Transport Layer The transport layer is responsible for exchanging MAL messages between a service consumer and a service provider. There will exist a set of transport layers in the software bundle where some are being reused from previous ESA open-source projects, others are from DLR and some are custom-made to accommodate the needs of OPS- SAT: - ESA RMI - ESA TCP/IP - ESA HTTP - ESA SPP - DLR SPP over TCP/IP - DLR SPP over CAN It is important to mention that future transport layers can be easily integrated and the selection of the transport layer is afterwards done by means of a configuration file. The selection of the transport layer must be done depending on the platform being used, for example, on OPS- SAT the CAN bus will be used as the nominal bus for the exchange of data that will go to ground and therefore a dedicated implementation of SPP over CAN needs to be put in place. III. High-level components The NanoSat MO Framework is composed of high-level components that are able to provide concrete deployments: Generic NanoSat MO Monolithic, Generic NanoSat MO Supervisor,, Ground MO Adapter and Ground MO Proxy. The Ground MO Adapter and Ground MO Proxy are components which are intended to be deployed on ground. When combined with the space segment part, they are capable of providing end-to-end deployment solutions. The design and development of the high-level components are done in a modular and flexible manner which is aimed at having a family of software systems where the building blocks can be reconfigured or adapted depending on their role in the overall design. This is similar to a Lego -type approach inspired by ESOC s data systems infrastructure. 15 A. Generic NanoSat MO Monolithic The Generic NanoSat MO Monolithic consists of a set of services providers that facilitates not only the monitoring and control of the app, but also the interaction with the platform peripherals. The app is plugged into the NanoSat MO Monolithic through a defined interface and additionally it can implement the backend interface of the M&C services to allow the monitor and control of the app from ground and space. The generic NanoSat MO Monolithic must be extended to a specific platform. There are two main things to be defined, first, the transport layer for the communication with ground, and second, the Platform services 6

7 implementation for that specific platform must be selected. Additionally, special logic could be added for unique features that might make sense only on the targeted platform. The software bundle already includes the following implementations: - OPS-SAT: It is composed of the implementation of the OPS-SAT Platform services for the real OPS-SAT mission. The exchange of messages with ground will be done via the spacecraft s CAN bus and therefore the Transport Layer requires a special implementation for SPP together with the dedicated protocol defined over CAN. The Platform services will be connected to the real on-board peripherals. - OPS-SAT Software Simulator: It is composed of the implementation of the OPS-SAT Software Simulator Platform services. The selected transport layer is ESA RMI. This implementation is intended to be used by OPS-SAT experimenters as a starting point in order to quickly debug their app. - AGSA FlatSat: is composed of the implementation of the AGSA FlatSat implementation Platform services. The selected transport layer is the same as in the real OPS-SAT mission, SPP over CAN. For a monolithic deployment where there is only one app running, the simplistic approach is possible, however this component needs to be split in two in order to have multiple apps running on the same machine. This can be done by creating two additional components: the NanoSat MO Supervisor and the. These will be described on the next sub-sections. B. Generic NanoSat MO Supervisor The NanoSat MO Supervisor allows having multiple apps sharing the same Platform services for the interaction with the peripherals on-board. Additionally, it brings software management capabilities such as: starting, stopping, installing, updating and uninstalling apps on-board of the spacecraft. Most of the existing logic of the NanoSat MO Monolithic can be shared as the main difference to the monolithic implementation is that the app runs on a different process. This allows having multiple and separate apps sharing the same Platform services. It contains a central Directory service that holds the information about all the providers running on-board, more specifically, the NanoSat MO Supervisor provider and the set of running apps with their respective services. It already includes generic functionality common to all Platform services, for example, the functionality of generating events based on a nearby position for the GPS service. A generic implementation of this component is provided in the software bundle however it must be extended for the specific platform of the mission because the peripherals available on the platform will be different between spacecraft and therefore the NanoSat MO Supervisor will have different implementations of the Platform services and different transport layers for the communication with ground. The generic nature of the design is flexible enough to accommodate this need. C. The provides towards the app developer the possibility to execute actions, set/retrieve parameter values, and additionally, common interfaces to access the satellite s platform peripherals. This interface is the exact same interface as the one used on the monolithic architecture and therefore it is possible to do a change of the underlying architectures without any major changes on the business logic of the app. Upon startup, this component shall create the M&C services connections to ground and then connects to the NanoSat MO Supervisor services and register the exposed services on the central Directory service in order to give them visibility. App An implementation of this component shall be provided in Java on the software bundle. This brings some advantages, for example, the component is the exact same for every app and therefore it doesn t need to be integrated within the jar file of the compiled app. This is important because it minimizes the content that needs to be transferred to the spacecraft, to the business logic of the app. The CCSDS MO Framework is technology-independent and therefore the doesn t necessarily need to be developed in Java. However, if other languages are to be supported, then the logic of this component would need to be translated on the new target programming language. A MAL implementation in C was made available online by CNES recently and this could potentially be reused to 7 Figure 4: The NanoSat MO Connector plugged into an app

8 build part of the MO stack that needs to be in place for the in a different programming language. 12 D. Ground MO Adapter The Ground MO Adapter allows a ground system to interact with any app that uses the NanoSat MO Framework by exposing all the service interfaces for interaction with the provider and by handling all the services connections. This component is foreseen to be used for the development of Monitor and Control Systems (MCS) or ground applications capable of interfacing with an app however it is not limited to apps based on the NanoSat MO Framework. This means that a ground consumer using this component shall be able to connect to other different providers, such as a simple provider with only a Parameter service. Generic MCS Ground MO Adapter Figure 5: Generic MCS plugged together with the Ground MO Adapter In order to facilitate the configuration and testing during development, there is a Configuration Manager tool which provides a user-friendly interface to allow the configuration of an app developed with the NanoSat MO Framework. For every service implementation, there s a consumer GUI panel that provides a visual interface to configure and interact with those services. The Configuration Manager tool is a consumer application and it uses the Ground MO Adapter for the connection to the apps. The tool shall be provided to OPS-SAT experimenters to test their code during the development phase and to configure their app. Figure 6: Configuration Manager tool connected to one of the app demos displaying the Parameter service tab In the software bundle there are ground demos exemplifying how to use the Ground MO Adapter. ESA s EGOS User Desktop (EUD) provides a framework for M&C User Interfaces for all types of ground segment systems, including ground station backend systems and mission control systems. This not only allows exploiting synergies in the UI development but also facilitates a common look and feel across all ground segment systems. 8 Web-EUD is an ongoing project to use EUD through a web browser. EUD uses the Eclipse RAP framework which makes it possible to run EUD as web application as is, with only minor adjustments to the code base. 9 8

9 In ESOC there is an activity for the integration of the Ground MO Adapter with Web-EUD in order to provide an easy web interface to access apps that are running on-board. OPS-SAT experimenters shall be able to directly use this web interface, as they would have to plug the Ground MO Adapter into their own MCS otherwise. E. Ground MO Proxy The Ground MO Proxy is a high-level component that allows multiple consumers to share the same connection to the spacecraft, it acts as a protocol bridge, extends the functionality of the services and is able to connect to multiple apps simultaneously. Acting as a protocol bridge, it shall connect to the spacecraft via SPP and expose all the services to ground consumers. Examples of suitable protocol transports that can be exposed on ground are HTTP, TCP/IP and/or RMI. The Ground MO Proxy follows the concept of proxy service extension defined in the MO Reference Model book. 10 This allows, for example, queuing actions, exposing a Directory service with re-routed URIs to the correct location, having an Archive service replica on ground in order to minimize the access to the on-board Archive services of each app and activity tracking for the forwarding of actions. Figure 7: Proxy Service Extension Figure 7 shows the Proxy component acting as a consumer of Service A from the Provider component and as a provider of Service C to the Consumer component. A proxy provides a way of exposing a service to external consumers where direct visibility would not be desirable (for example for security reasons). In the example the Proxy component is also acting as a protocol bridge; however, this is not required. 10 IV. End-to-end deployment scenarios Different end-to-end deployment scenarios based on the NanoSat MO Framework are possible. The high-level components can facilitate the setup of these scenarios due to their modular nature that can be easily integrated into other components. The most important and common setups will be covered and additionally, the foreseen OPS-SAT deployment scenario will be described. A. Development & Testing deployment scenario During development and testing phases, the Configuration Manager tool provides all the necessary functionality to test and debug the developed app. The Configuration Manager tool uses the Ground MO Adapter component in order to connect to the developed app. The App block does not specify if it is using the NanoSat MO Monolithic or the because it be using either one. 9

10 Configuration Manager Ground MO Adapter App Figure 8: Configuration Manager connected to an app B. Simple generic deployment scenario The simple generic deployment consists of a simple consumer that can be any MCS connected to the services provider of an app. Figure 9: A Generic MCS connected to an app C. Advanced generic deployment scenario The advanced generic deployment scenario provides an end-to-end solution using all the high-level components. The advantage of such a deployment is that each app has a single connection to ground, while ground can have multiple consumers connected to the proxy using the same or different apps. Generic MCS Ground MO Adapter Generic MCS Ground MO Adapter Ground MO Proxy Ground Space App NanoSat MO Supervisor App A App B Ground Space Figure 10: An advanced deployment with the concept of multiple apps and usage of the Ground MO Proxy D. Foreseen ESA s OPS-SAT-specific deployment scenario The foreseen ESA s OPS-SAT-specific deployment scenario provides an end-to-end solution from the app (OPS-SAT experiment) to the experimenter sitting externally to ESOC. Web-EUD is capable of providing a web browser interface to interact with the apps through the CCSDS M&C services and reduces the development effort of an experimenter to just the on-board part. Nevertheless, experimenters can still have their own MCS running externally and connect to the Ground MO Proxy to monitor and control their experiment. 10

11 Web Browser Web-EUD Ground MO Adapter App A Ground MO Proxy NanoSat MO Supervisor App B External ESOC Ground Space Figure 11: Foreseen OPS-SAT deployment scenario E. Other possible deployment scenarios Other possible scenarios are envisaged: - In a multi-agency mission, the Ground MO Proxy could be deployed on the first ground infrastructure and expose the services to other agencies. If one of the agencies wants to expose the services to its own clients, it could deploy another instance of the Ground MO Proxy that is connected to the one on the first ground infrastructure. - The Ground MO Adapter could be plugged into a mini MCS for smartphones which would allow to have multiple clients receiving live data coming from the spacecraft directly into their smartphones. One possible candidate is Pocket Mission Control. 13 V. Future Work The NanoSat MO Framework was designed to be flexible and modular and therefore it opens many possible extensions and future implementations with other software projects and new technologies. Some concrete examples for future work and extensions has been identified: - Implement the NanoSat MO Framework in other nanosatellite missions; - Implement the Ground MO Adapter with other ground MMIs, for example, Pocket Mission Control for smartphones; 13 - Define other MO interfaces for common nanosatellite peripherals (example: Propulsion service); - Integrate the concept of file-based operations: CFDP and/or FTP for file transfer; 11 - An open repository of apps available on the internet can be create to increase collaboration; - The Ground MO Proxy can be more secure with an implementation of the Login service from the CCSDS Common services; - Clearly define a package file format to distribute and facilitate the installation of apps; - Apps can be deployed in isolate containers however this might make the framework platform-dependent depending on how the isolation is done and therefore it needs to be carefully assessed; - Develop a equivalent in C or other programming language in order to extend the possible technologies available for the development of apps. If C is used, the app will have to be compiled for the correct processor architecture of the platform and it breaks the portability advantage from using Java; - Assess the performance of the NanoSat MO Framework, especially on peripherals that need to be operated in real-time such as the FineADCS reaction wheels control (real-time computing). 11

12 VI. Conclusion The NanoSat MO Framework introduces the concept of portable apps to the space segment which brings many benefits: It allows an app developer to focus solely on the business logic of the software and overlook the layers underneath; the access to the peripherals is done via common interfaces between different nanosatellites and therefore changing between platforms does not involve changing the code of the app; It allows testing and debugging the app directly during development phase on a simple software simulator; Direct reusability of apps from previous missions becomes a possibility; Furthermore, it inherits the same benefits from the CCSDS MO Framework, the latest cutting-edge international space standard from the CCSDS for mission operations. A software bundle will include all the NanoSat MO Framework-related software and it will be available online for free under ESA s open-source license. The introduction of the concept of apps on-board combined with Java development, the stratification of the CCSDS MO Framework and with the introduction of on-board software entities that can be distributed through packages, make up the ingredients for on-board software portability in the NanoSat MO Framework. The NanoSat MO Framework will fly for the first time on OPS-SAT and it will provide a software development framework for all experimenters to write their apps in a simple manner where the underlying low-level details (for example: drivers) are hidden from the developer but available through the use of high-level Platform services. References 1 M. Merri, D. Evans, OPS-SAT: A ESA nanosatellite for accelerating innovation in satellite control, SpaceOps, C. Coelho, D. Evans, O. Koudelka, CCSDS Mission Operations Services on OPS-SAT, 10th IAA Symposium on Small Satellites for Earth Observation, O. Koudelka, M. Wittig, D. Evans, ESA's OPS-SAT Nanosatellite Mission - A Laboratory in the Sky", 10th IAA Symposium on Small Satellites and Earth Observation, CCSDS, Mission Operations Services Concept, Green Book. Issue 3. December Andrey Koltashev, A Practical Approach to Software Portability Based on Strong Typing and Architectural Stratification", Modular Programming Languages, Volume 2789 of the series Lecture Notes in Computer Science pp D. McComas, S. Strege, J. Wilmot, core Flight System (cfs): A Low Cost Solution for SmallSats, Goddard Space Flight Center, CCSDS, Mission Operations Common Object Model, Blue Book. Issue 1. February P. Steele, F. Flentge, J. Schütz, M. Pecchioli, ESOC New Generation M&C User Interfaces, SpaceOps, J. Schütz, EGOS User Desktop: A Generic User Interface Framework for Ground Segment Software, GSAW, CCSDS, Mission Operations Reference Model, Magenta Book. Issue 1. July CCSDS, CCSDS File Delivery Protocol (CFDP), Blue Book. Issue 4. January GitHub, CCSDS MO MAL C API, URL: [cited 21 March 2016] 13 N. Phillips, J. Savage, A. Whetter, Pocket Mission Control App, JA & University of Bristol, S. Cooper, CCSDS Mission Operations Services in Space, SpaceOps, N. Peccia, Can a LEGO Engineer work at ESA/ESOC as a Data System Software Engineer?, SpaceOps,