Main mission of Rosetta's Philae lander accomplished

Today (15 November 2014), Rosetta's Philae lander went into sleep, its batteries depleted but still it could upload the last set of measurements. The lander might wake up again if it can catch enough sunlight to recharge the batteries. Rosetta itself will continue its mission.

To follow the saga, watch the ESA website. We can only be very proud that our Virtuoso RTOS on the parallel DSP boards (developed by EADS) has survived a journey of 10 years and 500 million km in space sending us the first close look at a comet. And maybe its chemical analysis can tell us a bit more of how life originated on our planet.

We take the opportunity to share some thoughts on the long road towards trustworthy systems and software engineering that we were involved in by having the Virtuoso RTOS being used on board Rosetta.*

The Rosetta mission was a remarkable piece of engineering. Not everything went as planned, but there was enough margin build in to still reach the main objectives. The project could become a classical textbook case for engineering students. We believe that one of the reasons that it worked was the KISS principle: Keep It Simple but Smart. It has been a guiding principle that we still apply today.

This principle is at the heart of the Virtuoso RTOS that Eonic at the time ported to the multi-DSP boards used in several Rosetta instruments. It has it roots in the concepts of CSP (Communicating Sequential Processes), Hoare's process algebra that was also used as the guiding principle to develop the ex-INMOS transputer, a nickname for a parallel processor with process switching and communication support in the hardware. Even if it failed in the market in the long term for mainly non-technical reasons, the chip was a milestone, used as well for very compact control applications as well as for large parallel supercomputers. It was also used in many low orbit space missions because a single chip would replace much larger and power hungry processing boards. 

With the transputer came also the occam language. Occam-1 was a very simple language with parallelism build in and as such, while very elegant, it lacked the more sophisticated semantics that were needed for complex real-world application development. Nevertheless, it was a hallmark. Once exposed to it, parallel programming and thinking became simple, actually much simpler than dealing with the complexity of shared memory state machines that are still the norm today. The CSP approach works because it splits up the global state machine in smaller ones and makes their interactions explicit. The language was also very strict, but often a compiled program would also immediately run whereas with many other languages compiling mainly means finding syntax errors, not correctness.

Then two decisions were taken.  Following an experiment to develop a fault tolerant OS with transputers in occam (it actually worked but was very slow), we decided to switch from occam to C. Occam was nice but it lacked support for real-world datastructures (which was later on added to occam-2). In addition, the transputer could perform very fast context switches (about 1 microsecond at 25 MHz) but it had only 2 priorities. The latter makes it problematic to achieve hard real-time performance (an essential property for runtime fault tolerance) when multiple events can occur. Hence, we developed a preemptive priority based RTOS for the transputer. This worked well, except that building systems with multiple transputers was still quite painful, especially when Tasks were remapped or the network topology was changed. Hence, a routing and communication layer was added below the RTOS so that programming large networked systems became transparent.  The Virtuoso RTOS with its Virtual Single Processor programming model was born and later on this was used on parallel systems with 1000’s of processors (most of the time high-end DSPs).

Over the years, it became clear that the pragmatic implementation we had in the RTOS was more than a programming model. It was a modelling approach as well. Today we call it “Interacting Entities” as this simple yet powerful concept can be used to describe almost any real system, be it a social system, a mechanical system, an embedded system (combining multiple domains) and last but not least a software system.  It also became clear that Interactions should be treated as first class citizens. This was reflected in the Packet switching mechanism used in Virtuoso and more explicitly formalised in the Hub concept of OpenComRTOS. That latter can be seen as a fourth generation Virtuoso whereby the interaction semantics received a detailed analysis using Leslie Lamport's TLA+/TLC formal language and model checker.  One of the big surprises was that it resulted in a much better scalability for the RTOS but also in a much smaller code size (5 to 10 times). Size still matters when low energy use and safety are required properties of a system.

The work done with the formal modelling reinforced another principle we had learned from the CSP/occam/transputer days: the importance of clean, orthogonal semantics.  Today we call this “Unified Semantics” and we believe it is a core principle behind successful engineering in general. Some 10 years ago, we took a bold decision to propose a unified systems engineering based on this principle. Systems engineering suffers from the abundance of many heuristic models and tools that are often not compatible or only superficially. When analysed in depth, they have hidden side-effects or unclear specifications and using them together results in complexity and uncertainty, not to speak of the impact of constant changes that these tools characterise. The tower of Babel comes to mind.

Unified Semantics was the guiding principle behind the development of the meta-model that we use in the GoedelWorks environment. It defines a System as the result of a Project executed following a predefined Process flow. As such, it reflects what most engineering and safety standards put forward, except that the meta-model fits on a single page. Used internally to develop the OpenComRTOS Qualification Package and a scalable e-mobility vehicle it connects the domain of Requirements Engineering, Modeling, Project Management with the runtime layer and the application software. This was an effort over many years, because the KISS principle also reflects that a simple solution requires hard thinking, the other side of the coin being that a complex solution is a problem that was not well understood. The Rosetta mission after all is such an example. From a physical point of view, it is a constant application of Newton’s elegant laws (F=ma being the best well known).

PS.

1. Many people were involved and made their contribution.  As such, it was a team effort. I thank them all.

2. For those interested to learn more, Altreonic is starting with a series of workshops whereby the approach of Unified Semantics and Interacting Entities is explained in more details and illustrated by using GoedelWorks and OpenComRTOS Designer.

3. Stay tuned: whereas Virtuoso and OpenComRTOS are inherently quite safe because the code and datastructures are statically generated, VirtuosoNext is underway whereby fine grain Time and Space Partitioning will enhance the protection against involuntary or maliciously injected faults. After all, only software can be error free. 

*: Johan Zandin (RUAG Space AB) informed us that Virtuoso was also used in the Mass Memory (see attached image) of the Rosetta orbiter.

The Mass Memory developed by RUAG Space in Sweden features 2 processor boards (one active and one as backup), each with 1 MiByte RAM and a 14 MHz 21020 DSP running Virtuoso. The Mass Memory is used to store all images and other scientific data before it's downlinked to Earth.