We’re flying to Jupiter
If it were actually possible for humans to fly to Jupiter, some of us would probably jump at the opportunity right away. So far, alas, this privilege is limited to unmanned space travel. One reason is that it takes about 8 years to get to the largest planet in our solar system.
But bevuta is flying to Jupiter anyway. That’s because our software is scheduled to head there in April 2023. And in our hearts, that software is part of us.
What’s it like to be a part of such a space flight project? What does our software do there, and what have we learned? We talked to our colleague Felix Winkelmann, who worked on the software for this ambitious undertaking together with the Max Planck Institute for Solar System Research (MPS).
But first we’ll tell you the goal of the mission we have been collaborating on with the MPS.
Is Europa hiding water?
The question sounds less confusing if you know that Europa only sounds like the Earth continent but is actually one of the moons of Jupiter. Together with Ganymede, Callisto and 89 other moons, Europa circles the largest planet in our solar system. One of the questions keeping scientists up at night is a simple one: Is there liquid water inside one of the moons? That would be the prerequisite for the existence of life as we know it.
Ice cold – and still alive?
It’s cold in the Jovian system. The average surface temperature of the moon Europa, for example, is about -171°C. But there is also evidence that there might be subsurface oceans under the moons’ outer ice layers. Particles from the inside of the ice moons could escape into the atmosphere through nooks and crannies in the ice. And that’s where JUICE plans to measure them.
The European Space Agency’s (ESA) JUICE spacecraft (Jupiter Icy Moon Explorer) is scheduled to leave for the Jovian system on 13 April 2023. Once arrived, it is expected to answer a plethora of questions, including the one about underground water. For this, it will need various scientific instruments, for instance to measure the composition of the atmosphere. The Max Planck Institute for Solar System Research is contributing two of the instruments. The measuring instruments need software to communicate with the satellite bus and transmit the collected data. We were involved in developing that software for the integration of the Submillimeter Wave Instrument (SWI). Felix Winkelmann, founder of the Chicken scheme project and software developer at bevuta since 2012, spent several years at the Max Planck Institute for Solar System Research in Göttingen working on it.
Felix, from 2014 to 2022, you collaborated with the MPS on the software for the Submillimeter Wave Instrument. Can you tell us what the software does?
Sure. The SWI is designed to track chemical compounds in the Jovian system, that means in the atmosphere of Jupiter and of the three icy moons Ganymede, Callisto and Europa. It does this by analysing the infrared radiation sent into space from the Jovian system (from layers of rock, ice crusts and atmospheres). Water, oxygen, carbon dioxide, methane and other hydrocarbons show up as absorption lines in the infrared spectrum – and we hope to measure these with the SWI.
And your software connects the SWI to the satellite bus, right?
Exactly. We were involved in the design of the flight software, the software that is actually flying on board the spacecraft, as well as in the EGSE (Electronic Ground Support Environment), which is the software counterpart that’s staying on Earth. And, on top of that, the software for testing and for connecting the flight software and the EGSE.
Is developing for a space flight project different from other software projects?
Yes, in some respects. For instance, the ESA mandates strict guidelines for software development. These requirements concern project organisation just as much as the quality of the components and processes and their functionality. In many aspects, you’re more restricted than in other projects.
Could you give us an example?
From a technical standpoint, the hardware’s limited computing power is a challenge. As its hardware basis, the SWI software runs on a SPARC LEON Board made by Gaisler and operates at a frequency of 20 MHz with a 2 MB memory – about as much as typical computers on Earth at the end of the 80s. A lot is governed by the principle that the energy consumption of the entire system including all subsystems has to be as low as possible.
Where does the energy come from?
In contrast to US spacecraft, which mostly run on radioisotope power systems (RPS) – often referred to as nuclear batteries –, JUICE runs its systems purely on energy from solar panels. They have a total surface of 85 square metres – the largest that have ever been built for an interplanetary space mission. And that they have to be, as the mission operates so far from the sun that there’s not a lot to be harvested. As a worst case, a solar flux of only 46 W/m².
Doesn’t JUICE actually travel closer to the sun at first?
That’s right. To get enough momentum for the long haul to Jupiter, the spacecraft will initially use the gravity of the Earth’s moon, Earth itself and Venus. It will get so close to the sun that it could be exposed to temperatures of +110 °C. Once it arrives at its destination, which is five times as far from the sun as Earth, temperatures will have plummeted to -230 °C. That means that the entire system, including the extremely sensitive mechanics and electronics, have to be able to handle massive temperature shifts. Not to mention the extreme electromagnetic radiation that is thousands of times higher on Jupiter than on Earth and that the instruments on the spacecraft need to be shielded against.
What effect does the immense distance have on communication between Earth and the spacecraft?
A direct impact of the large distance lies in the long signal travel times and resulting latencies: We wait for 33 to 53 minutes for data transmitted from the spacecraft. For a reaction to a command sent to the spacecraft to arrive (round trip time) it can take up to 1 hour and 46 minutes.
Add to that the network of tracking stations here on Earth that receive data from various satellites and space probes and only offer limited data reception hours for each sender. There is a clearly defined schedule for receiving data: When is which ground station available for which mission? Plans are for JUICE to have an average communication window of 8 hours per day.
Because of the limited window, for one, everything needs to be planned down to the tiniest detail, which means restrictions in the permissible data volume for measurement data being transmitted. Above all, nothing happens spontaneously on this mission. All telecommands (operations performed by the instrument computer) are planned down to the millisecond weeks in advance and executed precisely.
Sounds strenuous and time-consuming.
Yep, it is. Every single step has to go through several testing, validation and approval processes before it can be executed, and it has to be known far in advance.
It’s vital for planning the power supply, for example. None of the devices may just turn on or change modes, like going from waiting in idle mode to the energy-intense science mode. The control centre needs to always know how much electricity the instruments are consuming. It’s the only way to distribute the scarce energy in a targeted way.
So, there’s not a lot of wiggle room for spontaneous reactions?
Pretty much none. Even short-term changes are set at least 24 hours in advance (if not more). The device itself reacts spontaneously only in emergencies. In the case of an unexpected event, it powers off. But that needs to happen in a clean, controlled wy. Otherwise, the hardware could take damage. Apart from that, software autonomy is also multiple times lower than in other projects.
What does that mean specifically?
The software has to be able, for example, to receive commands from the board computer at all times, no matter how hard it’s working or the mode it’s in – whether it’s in the middle of taking measurements or executing commands.
Even though the software must be tested and validated very exactingly, it also must be flexible regarding scientific requirements. It could happen that measurements over time provide insights that make adjustments necessary. That’s why there’s a limited scripting option for measurement scenarios to allow measurement plans to be modified. That said: As little change as possible is the rule because all changes have to go through extensive validation. It’s always a tightrope walk between flexibility and safety.
Were you able to build on existing components, or is everything new about the software?
The software is 100% mission specific. Every component was newly developed. It was a whole new experience for me because we usually extensively use open-source libraries and our own code makes up only part of the software.
Sounds like a challenge.
Yes, it is, definitely. But that’s what makes it interesting! Honestly, the organisational challenges were more daunting than the technical ones for me. You can always surmount technical challenges one way or another. As long as you have sufficient resources.
It’s less easy when it comes to the organisational side of things. The instrument’s many externally set up subsystems cause attrition during information exchanges. Scientists also have other requirements than engineers. This leads to misunderstandings. For example, because of different approaches to or terminology for one and the same concept.
So, working with machines is easier than working with people?
You could say that. (laughs)
But it’s less the people that are the problem than the structures. The ESA mandates a lot of red tape that is hard to handle in a situation where two developers share a single position and the available resources are barely enough to accomplish the engineering part of the project.
There was also a lot of fluctuation among scientists, engineers and managers in the project team. As a result, requirements changed several times and personal contacts were no longer available.
If you were training a successor, what would your recommendation for them be?
Go for direct communication! Direct contact with other departments and companies always brought us to the finish line the fastest. For instance, we talked directly with CBK in Poland, who were developing the DPU (Data Processing Unit) and the Interface FPGA (Field Programmable Gate Array).
We also got together with developers for another instrument on the MPS to get over initial barriers to understanding. The jargon and mindsets prevalent in developing instrument software were uncharted territory for us. Had we tried to solve everything in writing, it would have taken much longer.
So, we’re back to working with people.
Absolutely. Collaboration in our small team was excellent – we benefitted and learned a lot. Particularly about the unique requirements for space flight projects, which face limitations that are vastly different from those of a conventional software project.
Where does the project go from here?
The instrument has been built into the spacecraft and was extensively tested by Airbus Defence and Space. We’re talking about 11 different instruments from all over the world: each one with specific problems and challenges to tackle, with consortia consisting of several companies and institutions that had to coordinate with one another. All in all, we’re happy with the SWI software. Its architecture is solid, and the system is efficient. It will only prove its mettle in a few years, though, when first measurements are conducted. At the moment, the SWI development is moving on to questions of data archiving and evaluation as well as scientific planning.
So, all systems are go?
Yes, pretty much. In the meantime, the spacecraft has arrived at the Spaceport in Kourou in French Guiana. Within the planned launch window in April 2023, April 13 is the scheduled date at the moment. Things are getting real. :)
I’m sure it’s going to be a great feeling when your software’s actually on its way to Jupiter, won’t it?
Yes, it’s a childhood dream come true! Becoming an astronaut isn’t that easy, after all. 😄. Everybody’s personal contribution is obviously limited because a project like this is the result of many, who (due to the long duration of the project) have been coming and going. Still, even trivial details are crucial and this provides a brand-new perspective on your daily work. Being involved with this project was exciting, but it also makes you humble: So many things can go wrong, and the technical conditions are really extreme. Space technology is not about magic. It’s the result of a lot of work, planning and resources. Should everything go well and the software (along with my small part in it) do its job, it would be a fantastic outcome. I’m excited to see how everything goes!
Image credits
Header image: Family Portrait of Jupiter's Great Red Spot and the Galilean Satellites, © NASA/JPL/DLR
Jupiter’s moon Europa, taken during the NASA mission “Juno” on 29. September 2022 | © Image data: NASA/JPL-Caltech/SwRI/MSSS | Image processing: Kevin M. Gill CC BY 3.0
Operating in an extreme environment (© acknowledgement: work performed by ATG under contract to ESA, CC BY-SA 3.0 IGO
Instrument cleaning and functional tests of JUICE spacecraft at Guiana Space Centre. © Lars Naber, Auf Distanz