Acta Astronautica 63 (2008) 1299–1304www.elsevier.com/locate/actaastro

An extensible on-board data handling software platform forpico satellites

Marco Schmidt∗, Klaus SchillingUniversity of Wuerzburg, Würzburg, Germany

Received 5 December 2007; received in revised form 20 March 2008; accepted 6 May 2008Available online 9 July 2008

Abstract

Miniaturization techniques enable the realization of very small satellites with interesting capabilities in space science. TheUniversity of Würzburg contributed in the scope of the cubesat program with its own pico satellite UWE-1, which is in orbitsince October 2005. Despite reliable and stable operation of the on-board data handling (OBDH) system during the UWE-1mission, the successor UWE-2 will be equipped with a more sophisticated, modular and extensible OBDH system, which wasdesigned to facilitate the further development of the UWE satellite platform. The OBDH system was designed for high reliabilityand stability, but with an easier extension capability. The modular structure of the new system thus supports potential transferto other satellite platforms.© 2008 Elsevier Ltd. All rights reserved.

1. Introduction

Modern miniaturization techniques enable the real-ization of extremely small satellites, often referred aspico and nano satellites. Reducing the size of modernsatellites results in cost savings due to lower weightat launch. Furthermore, it is possible to develop andlaunch such small satellites in very short time frames ofabout 1–2 years. These small satellites can be used indifferent application fields like component testing underspace conditions, technology demonstrations, earth ob-servation and other applications in space science. There-fore, many institutions are currently developing theirpico and nano satellite platforms. One of the centralsubsystems is the on-board data handling (OBDH) sys-tem, which is responsible for data processing and data

∗Corresponding author.E-mail addresses: schmidt.marco@informatik.uni-wuerzburg.de

(M. Schmidt), schi@informatik.uni-wuerzburg.de (K. Schilling).

0094-5765/$ - see front matter © 2008 Elsevier Ltd. All rights reserved.doi:10.1016/j.actaastro.2008.05.017

transfer between the various electronic units of the satel-lite. As most of the pico and nano satellites use mi-crocontrollers for data processing, the OBDH is oftendeveloped only for these specific satellite platform. Atypical example of a satellite with microcontroller andspecifically developed OBDH is the AAUSAT [1] of theAalborg University or the cubesat XI from the Univer-sity of Tokyo [2]. A more sophisticated OBDH is pos-sible for satellites equipped with a microprocessor torun a complete operating system (OS), which enablesthe OBDH to rely on the basic implemented function-alites of the OS. The BEESAT pico satellite is such asatellite, using the BIRD OS (BOSS) [3] for access tothe hardware.

The University of Würzburg contributed in the scopeof the cubesat program with its own pico satellite UWE-1 [4,5]. UWE-1 is a satellite with a total mass less then1kg and was already launched in 2005. The pico satel-lite UWE-1 completed its mission successful after thefirst few weeks. The OBDH of UWE-1 consists of aLinux OS with an application for data management on

1300 M. Schmidt, K. Schilling / Acta Astronautica 63 (2008) 1299–1304

top. The OBDH of UWE-1 proved to be very reliableand stable. As the UWE project evolved from an educa-tional project in the curriculum of students, the workingstaff of the UWE team changed after time. Therefore,the next generation of software developers working onthe second satellite UWE-2 is in most cases not famil-iar with the previous developers work. Furthermore, theextension of an existing software system is very com-plicated, if the implemented system was not intended tobe extended with new functions and therefore providesno suitable interfaces. With the development of new fea-tures for UWE-2 it was recognized that the extensioncapability of the existing OBDH system of UWE-1 isrestricted. The software developers faced problems likeunsatisfied synchronization and not supported devices.As a result it was decided to implement a new OBDHsystem for UWE-2, which is much more flexible andenables a simpler extension of the OBDH system withnew features. Of course it has to provide the same func-tionalities as the UWE-1 OBDH, additionally a highdegree of stability is required from the new system. Theresult, the new developed OBDH system ULF (UWELinux based software Framework), is described in thispaper. Section 2 describes the old OBDH system withits advantages and disadvantages and the requirementsfor the new software system of UWE-2. Section 3 de-scribes the design of the new OBDH system. Section 4deals with the implementation details of the new systemand added features.

2. The OBDH of UWE-1 and requirements forUWE-2

The pico satellite UWE-1 (University of Wuerzburg’sExperimental Satellite 1) was launched in October 2005,its mission objectives comprised testing of new tech-nologies under space environment (e.g. high efficientGaAs solar cells) and performing experiments relatedto IP in space [6]. The OBDH system is a very simpleprogram performing only a few important tasks. Themain tasks of the UWE-1 OBDH system were:

• sending beacons,• reading and transmitting sensor data,• receiving commands,• charging batteries.

The OBDH software of UWE-1 proved to be veryreliable and stable, it was mainly constructed of asimple loop, which iteratively asked for new sensordata, sent this data encoded in a beacon to the radioequipment and checked in the last step for any receivedcommands. The flow diagram of this program is

Fig. 1. OBDH of UWE-1.

depicted in Fig. 1. On the next pico satellite fromWuerzburg, this software was supposed to do the samebasic tasks again. The difficulties occurred when theUWE-2 software developers tried to extend the systemwith new functions (like an attitude determination algo-rithm and new IP related experiments) into the existingOBDH system. As the developers tried to integratetheir new functions into the software of UWE-1, thecoordination of the different tasks grew very sophisti-cated and the extension affected the execution of theOBDH in an unforeseeable way, resulting for examplein delays. So the UWE-2 developers attempted to runtheir code in separated applications, which resulted insynchronization problems, due to the use of the samedata sources.

To overcome this problems, a new OBDH systemwas developed. The name of this system is ULF, indi-cating the modularity and Linux as basis. Neverthelessthe ULF system has to fulfill several requirements. Ofcourse it has to provide the same degree of stability asthe OBDH of UWE-1, which was defined as the high-est priority requirement. This includes stable operation,reliability and failsafe operation. The second importantrequirement was the development of a flexible system,which is easy to extend with new functionalities. As thedevelopment of the new system was motivated from therestricted flexibility of the UWE-1 software, the aim forULF was generally formulated as a high degree of ex-tensibility and modularity. The last important propertyof the system was defined as efficiency. As the UWEsatellite platform has restricted hardware resources (forexample memory and processing power), it is neces-sary to run the software system with a minimum of re-sources. These three requirements (stability, modularity

M. Schmidt, K. Schilling / Acta Astronautica 63 (2008) 1299–1304 1301

and efficiency) had to be fulfilled from the new softwaresystem of UWE-2.

3. Design of the ULF software system

3.1. General software design

The new OBDH system for the UWE pico satel-lite platform was developed to enable a simple wayto integrate new software components. Therefore, itwas decided to implement a system based on differentmodules, each performing its own task, e.g. datatransmission, sensor reading, battery charging, etc. Themodules are not a simple representation of a piece ofhardware, they can represent a broad variety of enti-ties. The idea behind the modular architecture is that acubesat developer who wants to implement a new ex-periment or functionality on the satellite, only has to in-tegrate a new module in the system to perform the newtask. The newly added module can then communicatewith the other modules to gather necessary informationfor its own execution. For example should a modulefor attitude determination request sensor data from thecorresponding sensor module. All modules can com-municate with each other over a central entity, whichis needed to coordinate the whole system. The mod-ules itself are intended to be independent of each otherto avoid problems due to inter-module dependencies.This means that each new module is only in connectionwith the main module and is therefore independent ofother modules. As already mentioned, all communi-cation between the modules is handled from the mainmodule, which is the intelligent entity in this system.This central entity has several tasks, like inter-modulecommunication, system initialization, error handlingand communication with the OS to exchange data withthe hardware. A picture of the modular architecture ofthe ULF software system is depicted in Fig. 2.

This means that the main part of the OBDH systemis executed in user mode (Linux divides processes inkernel and user mode. Processes in user mode have onlyrestricted access to resources. Refer to Section 4 for thespecial case of uClinux). This property was intended tohide the critical functions of the OS from the modules.This is very important, as also students work in theirmaster thesis on the software system and create theirown modules, therefore it has to be guaranteed that amodule cannot trouble the whole system. Of course itis not possible to execute all tasks only in user mode,thus they were concentrated in the main module. Alsoa couple of drivers have to be integrated directly in thekernel.

BatteryControl

House-keeping

ULF RadioControl

Logger

UWE

uClinux

Sensors Watchdog

Batteries / solar cells

TransceiverTNC

Fig. 2. UWE-2 software design.

3.2. The main module

As mentioned in the previous section, the main mod-ule has to perform important tasks like inter-modulecommunication, initialization and error handling.Therefore, it is very critical that the main module runsextremely stable. To handle this tasks, the main mod-ule has to keep track of all other modules running onthe satellite. As a result, all modules have to registerat the main module in the initialization phase. In theinitialization phase the main module starts each singlemodule by executing the corresponding module code,the first action of the module is then the registration atthe main module. This registration process is extremelyimportant, as the resource management is completelyhandled from the main module in negotiation with theOS. This means that a module can only request re-sources (for example the grant for sending informationto the transceiver), if it has registered in the initializa-tion phase. This procedure guarantees that the mainmodule can keep track over all actions running on thesatellite. Another important task of the main module ischecking for occurring problems or errors at runtime.If any error is detected, the system has to be recoveredas soon as possible. This failsafe operability was re-alized in UWE-1 with a watchdog timer, which resetsthe whole system if any error is detected. Additionallyto this watchdog timer the ULF software system hasrecovery functions integrated. The main module checksall running modules in fixed time intervals, if prob-lems are detected, the ULF system can restart affectedmodules.

1302 M. Schmidt, K. Schilling / Acta Astronautica 63 (2008) 1299–1304

3.3. Basic modules

The new software system was developed to guaran-tee a high degree of flexibility, especially to easy theintegration of new modules. Nevertheless a basic set ofmodules was designed to provide a basic functionalityto the UWE satellite developers. These basic modulesare:

• radio control module,• battery control module,• housekeeping module,• logger module,• sensor module.

With these modules the basic required functionalities ofan OBDH system should be provided. The sensor datahas to be read (sensor module), processed and eval-uated (housekeeping module) and afterwards sent tothe ground station (radio control module). The batterycontrol module handles charging of the power sys-tem, command handling is also performed from thehousekeeping module. These basic modules enablesthe UWE-2 team to simply integrate their specific ex-periments related to IP in space as an own module tothe system.

3.4. Usage of ULF on other cubesat platforms

One of the big advantage of the ULF software systemis that it is not only applicable on the UWE platform, itcan be used from a broad variety of cubesat satellites.As it can be seen in Fig. 2, the ULF software systemworks on top of the OS, this means that all tasks ofthe system (i.e. all modules) are running in user space.So the system can be used from every developers teamusing a system with a Linux OS. To use the ULF soft-ware system, only the satellite specific hardware drivershave to be exchanged and the modules according to thischanges modified. This results in time savings due toreduced implementation effort for a developers team,furthermore additional modules for not yet supportedtasks for the satellite can be easily implemented andintegrated.

4. Implementation

4.1. General implementation details

Before details of the implementation are handled, theunderlying hardware system and its OS should be men-tioned. The UWE platform is a pico satellite platform

Fig. 3. UWE electronics.

based on a H8 microprocessor from Hitachi. The on-board computer has 8MB of RAM and a flash memoryof 4MB for permanent storage. A picture of the UWEelectronics can be seen in Fig. 3. The UWE platformuses a Linux OS for operation, but as the H8 proces-sor has no memory management unit (MMU), a specialLinux version especially developed for processors with-out MMU is used. This Linux version is called uClinux,a very small Linux distribution that provides all basicfunctionalities of a normal Linux OS. The uClinux sys-tem is used for many different applications in the areaof embedded Linux and shows advantages because offaster IPC execution and shorter context switching times[7]. The underlying architecture drove the decision touse C as programming language, because it is commonin Linux systems to write applications in C, further-more cross-compiler toolchain for the H8 processor isavailable.

The implementation of the different system moduleswas realized in simple UNIX tasks, this means eachof the above mentioned modules (main module, sen-sor module, etc.) is represented by one UNIX task. AsLinux is (as well as uClinux) a multitasking system, sev-eral tasks can be executed “in parallel” emulated withtime slices of processor time. The implementation of themodules as single tasks guarantees the “independence”of the modules to each other, as each of them can bestarted and stopped individually. Nevertheless all themodules have to communicate with each other to per-form their tasks, for example the sensor modules, whichwants to transmit gathered data to the radio controlmodule. Therefore, a communication mechanism had tobe provided, realized with the implementation of inter-process communication (IPC).

IPC are mechanisms for communication betweendifferent processes. Unix based systems, e.g. Linux,provide several tools for communication between

M. Schmidt, K. Schilling / Acta Astronautica 63 (2008) 1299–1304 1303

processes, for example pipes, named pipes, socketsand so on. The ULF software system uses only thefollowing tools for inter module communication:

• message queues,• shared memory,• semaphores.

The tools are part of the standard Unix IPC featuresoffered from the uClinux OS. All these mechanismsare used from the developed application programminginterface (API) to handle inter-module communicationand resource allocation over the main module.

To ease the implementation of new modules and tohide the whole complexity of the system to developersof single modules, an API was implemented. This APIprovides different functions for communication with themainmodule, dealing on the one hand with inter-modulecommunication, handled over message queues. Thus amodule which wants to communicate with any othermodule has to send a message over the main module.The main module keeps track over all modules regis-tered at initialization. On the other hand the API func-tions are related to resource allocation of the single mod-ules. The API functions enable a new developer in thesoftware team a simple start in developing modules. Sosoftware developer have only to deal with a few simplesituations, these are:

• handle incoming messages from the main module,• sending messages to other modules over the mainmodule,

• register procedure at initialization,• resource allocation at the main module.

This architecture highlights the requirement of ex-tensibility. A new module can be created by simplywriting the module source code and using the func-tions of the defined API to communicate with the mainmodule.

A special property of uClinux is that it does not dis-tinguish between kernel and user mode, even file per-missions are not used. Nevertheless is the resource al-location over requests to the main module reasonable,as the ULF system is intended to run on other Linuxdistributions too, where a file access might need suit-able access permissions. Furthermore, synchronizationis almost impossible, if all tasks are able to modify im-portant data by themselves. With the introduction of re-source allocation and management in the main module,a clear logical separation between kernel and user modeis emulated.

4.2. Implementation of basic modules

Beside the development of an API, the aim wasalso to provide the same functionalities as the UWE-1OBDH. This functionalities were grouped in a fewbasic modules, consisting of the main module and inaddition modules for the tasks mentioned in Section3. The main module is the central component of theULF software system and acts as intelligent unit ofthe system. In the final implementation the main mod-ule enables a simple integration of new modules byperforming all necessary actions for setting up the soft-ware system. The main module runs as the main taskand searches by itself for new modules in a predefinedfolder. The software developers do not have to changeanything on the main module, all necessary changesshould only affect the “side”-modules. The intelligenceof the main module is expressed in the permission con-trol and failsafe operability functions. The permissioncontrol was implemented to restrict a module in itsexecution. In this way the main module can control theregistered modules by blocking their messages to othermodules. The permission grants of the ULF subsys-tem are fixed and cannot be changed during runtime,satellite orbit operation, respectively. This was decidedto avoid critical situations (like misconfiguration inthe module setup) during orbit operations. The failsafeoperability functions handle occurring errors duringruntime. If any module does not answer requests ofanother module, the main module has to check thismodule for correct operation. A polling function isused to request an “alive” signal from the misbehavingmodule, if this cannot be retrieved, the module hasto be restarted. In critical situations where this proce-dure cannot recover the module, all modules will bereinitialized.

Additionally to the main module basic moduleswere implemented. These modules provide the basicfunctionality of the satellite and are needed for basicoperation of the satellite and performing experiments.The radio control module is responsible for sendingdata from other modules to the transceiver. If the ULFsoftware system should be used on an other satel-lite platform, this module has to be replaced with amodule to control the radio equipment. The sensormodule stores the data gathered from the hardwaresensors and provides this data for other modules. Thebattery module implements the charging algorithmfor the batteries and the logger module logs impor-tant events at runtime. A picture of the ULF softwarecommand line reply after initialization phase is shownin Fig. 4.

1304 M. Schmidt, K. Schilling / Acta Astronautica 63 (2008) 1299–1304

Fig. 4. Command line view of the ULF software system.

5. Conclusion

In this paper the modular end expendable ULFsatellite software system was described. The need forthis new system was motivated from the first cubesatmission of the University of Würzburg. The describedULF software system fulfills the requirements in flexi-bility and extendibility for the UWE project. Anotheradvantage of the new system is the simple architecture,which enables the usage on a very simple satellite as theUWE satellite platform. The modular implementationenables different software developer groups to work onthe pico satellite at the same time. The flexible systemis not only a huge improvement for the UWE project,it is additionally a great opportunity for other OBDH

software developers to have a access to an on-boarddata handling system, as ULF can be used on top ofevery Linux based operating system. Therefore, ULF isa suitable housekeeping software for a broad spectrumof satellites.

References

[1] L. Alminde, M. Bisgaard, D. Vinther, T. Viscor, K.Z.]stergaard, The aau-cubesat student satellite project:architectural overview and lessons learned, in: 16th IFACSymposium on Automatic Control in Aerospace, 2004.

[2] R. Funase, et al., University of Tokyo’s student nano-satelliteproject cubeat-xi and its on-orbit experiment results, in: 16thIFAC Symposium on Automatic Control in Aerospace, 2004.

[3] S. Montenegro, K. Briess, H. Kayal. Dependable software(boss) for the beesat pico satellite, in: DASIA, 2006.

[4] M. Schmidt, R. Shankar, K. Schilling, The picosatellite uwe-1and ip based telecommunication experiments, in: ACA, 2007.

[5] R. Barza, Y. Aoki, K. Schilling. CubeSat UWE-1—technologytests and in orbit results, in: 57th Astronautical CongressValencia, 2006, IAC-06-B5.3.07.

[6] M. Schmidt, F. Zeiger, Design and Implementation of in-orbitexperiments for the pico satellite UWE-1, in: 57th InternationalAstronautical Congress, 2006, IAC-06-E2.1.07.

[7] H.-S. Choi, H.-C. Yun, Context switching and ipc performancecomparison between uclinux and linux on the arm9 basedprocess, in: Samsung Technical Conference, 2003.