Issue #2(4) 2015 Astronautics

European lab in the sky: OP-SAT and new potential for ESA spacecraft

David Evans Mission Concept Engineer and Programme Manager for OPS-SAT, European Space Agency. Credit: ESA/D. Scuka CC BYSA IGO 3.0

In 1994, a top-of-the-range consumer PC had a piddling 33-MHz processor and a tiny 250-MByte hard drive, the first Sony PlayStation was launched and Tom Hanks starred in Forrest Gump. 1994 was also the year that European spacecraft designers adopted the ‘Packet Utilisation Standard’, a technical specification that described how ESA spacecraft communicate with Earth, using then-current software and hardware technology.

In 2015, our Android and iOS phones have themselves become pocket computers, you can use a cluster of the latest PlayStation devices as a supercomputer, and Tom Hanks is 21 years older.

But European spacecraft still communicate using the venerable Packet Utilisation Standard, highlighting a major problem faced by space industry: project managers and bill-paying satellite operators are loath to let anything fly that might introduce even the tiniest risk, especially untested mission-critical flight control software.

Thanks to popular sci-fi movies like Gravity and Interstellar, we tend to associate space with the latest and greatest technology. This is sometimes true, because operating a complex robotic mission in a very challenging environment millions of kilometres away is not easy. However, these challenges also produce a paradox: because it is so hard, the latest technology in some critical mission areas is almost never used. You would be surprised at just how old some of the technology flying today actually is, and this is especially true in the area of mission operations.

With mission-critical software, there are always strong barriers to flying something new and unproven in space. Chalk it up to a mix of risk aversion, the difficulty of testing software on the ground under the same conditions experienced in orbit, and a deep reluctance by any satellite owner to allow tinkering with new code on an actual mission, which might detract from the satellite’s prime scientific or data-gathering mission.

Also, you have to reckon with people’s ‘comfort zones’. The profession – and craft – of spacecraft operations requires perfect execution every time. No one wants to risk a mission due to buggy software.


Space travel is a complex, unforgiving activity. The stresses of launch simply to get into orbit, wild temperature variations once there, delays and breaks in communication opportunities with ground and exposure to solar wind and cosmic radiation are just some of the factors that combine to stress a satellite’s on board control systems in ways that can’t be simply replicated on Earth.

Microprocessors for space use – the computer brains that control every aspect of a spacecraft’s minute-to-minute functioning – are typically 20 years behind those used on Earth in terms of performance, due to the need to ensure hardened protection against solar and cosmic radiation. ESA’s CryoSat-2 satellite uses an Agency-standard ERC32 computer. Writing code that runs on this microprocessor today is equivalent to programming for a mass-market PC circa 1990.

On top of the hardware restrictions, there is another factor: reliability. The software running on a spacecraft control computer is expected to keep running for years problem-free and without a reboot. This is achieved by following strict rules when drafting the code. While this certainly results in very reliable software, it also makes reuse of terrestrial software virtually impossible.

With mission-critical software, there are always strong barriers to flying something new and unproven in space

Hence, older but rock-solid reliable technology that has already been flown is always chosen in preference to something new. This leads to the ‘has not flown, will not fly’ vicious circle and means that in some areas, the space industry is stuck in a time warp; using hardware and software that is more representative of the early 1990s than the present day.

And opportunities for forward-thinking space software developers – whether an agile, innovative start-up or an established enterprise – to get new systems and techniques into orbit are extremely limited. That’s where ESA’s new Operations Satellite mission – dubbed OPS-SAT – is set to make a major positive contribution.

Small, neat and very, very functional. OPS-SAT will be operated by ESA’s European Space Operations Centre as a test and validation resource for over 100 European industrial partners from 17 countries.

Breaking the vicious circle

In 2012, ESA came up with the idea to fly a mission specifically to break the ‘has not/will not’ vicious circle in mission operations. Such a satellite need not be massive, or furnished with high-cost professional instruments, but it would need to have a control processor powerful enough to run classic terrestrial software yet be safe enough that occasional restarts due to faulty software or radiation effects would be acceptable.

No idea, no matter how outside-thebox, will be rejected a priori.

The OPS-SAT objective is to offer a low-cost laboratory flying in a low-Earth orbit that will be made available for authorised experimenters to demonstrate new, innovative mission operation concepts in a representative space environment.

To allow as many experiments as possible, OPS-SAT is fully reconfigurable in every possible way, from the firmware – the code embedded into microprocessor chips – upwards, and packed with powerful miniature electronic hardware and instruments for the experimenters to use (See box).

To reduce cost, OPS-SAT will fly as a hightech nanosat, measuring just 10 X 10 X 30 cm in size. The radiation environment of space means that the OPS-SAT electronics will face problems. Therefore a lot of effort has been put into making the satellite as robust as possible. Even though it is so small, the spacecraft actually comprises two, separate satellites, more or less bolted together.

As well as the one described above with the latest electronics, there is another one built from commercial off-the-shelf parts (most of which already have flight heritage). The expected performance of the second set of cubesat subsystems are way below that of the experimenter’s part of the satellite, but this can be relied upon to monitor the experiments and to hit the ‘Abort’ switch when anything goes wrong, allowing the craft to gracefully switch into safe mode.

Launched in 2010, ESA’s CryoSat-2 uses an Agency-standard ERC32 computer, with the equivalent processing power of a mass-market PC circa 1990.

The cubesat part of the satellite only has one task in this mode – to establish communication with the ground so that engineers can analyse the problem, reboot the processor and resume experiments.

This approach means that the risk barrier has been removed, allowing experimenters to load new software both on the ground and onto the spacecraft with limited testing beforehand.

Readying for flight

The mission is now at the Phase B stage of ESA’s internal project management process and is fully funded at an estimated cost of 2.4 Million Euros. The industrial team is led by the Technical University of Graz, Austria. The project team at ESA hope to finalise the design this year and start integration and testing in 2016 followed by a launch in 2017. The plan is to have OPS-SAT in a circular orbit over the poles at an altitude of about 620 km – an orbit that meets all technical and debris mitigation guidelines yet presents an actual and typical ‘in-space’ scenario.

Already over 100 different experimenters from across Europe have applied to run experiments on OPS-SAT once it has launched. These tests cover every aspect of mission control and every type of company and institution are represented, from one-person start-ups to major industrial concerns.

One interesting aspect of this will be to see how the experimenters work together because there is a lot of synergy between them; for example, one group drafting code to acquire images might benefit from another working on data compression or another that wants to implement artificial-intelligence algorithms to decide if the pictures are obscured by clouds and should be discarded before they are even downloaded.

There are still opportunities to submit proposals for experiments. No idea, no matter how outsidethe- box, will be rejected a priori.

Unique chance for Europe

During the expected 12- to 24-month mission, we hope to provide experimental time to anyone who presents a well-thought-out proposal. As we are not worried about risk due to the design, we can provide this opportunity with a minimum of bureaucracy so that experimenters can code instead of writing documentation.

Mission operations are often regarded as a static endeavour, where risk and change are anathema. Yet OPS-SAT is an opportunity to make a technological jump with minimal risk, and represents a major boost for European industry. We hope everyone will step up to take advantage of this chance to fly their ideas into orbit.

David Evans, a mission concept engineer at the European Space Agency, manages ESA’s OPSSAT project. Dave is originally from the UK and was previously the satellite control centre manager at EUTELSAT, the world’s third-largest telecommunications satellite operator. He holds several patents on spacecraft housekeeping telemetry compression.

Operating a spacecraft running with processors that became outdated in the 1990s is not an easy task for the ground.

More information: Innovative nanosat will test space software: OPS-SAT:

Popular articles

See also


Time to discuss regulations for future interplanetary trade


The multidisciplinary world of space habitation design


Space wars - how they start and how to end them

Popular articles

Hazel Fellows, one of the seamstresses who sewed and assembled the first American spacesuits produced by the International Latex Corporation – a company better known for making Playtex girdles and bras. Environment

Out of this world – NASA’s textile technicians and innovations for space voyages


Beyond Earth’s magnetic field