ESA Will Let Outside Software Run in Deep Space on Its Hera Probe
but Only European Labs, and Only Three Hours at a Time
The European Space Agency wants other people's software running on a spacecraft that is most of the way to an asteroid. The call it published on 5 August is headlined "your chance to run software in deep space," and that phrase is doing a lot of work. The chance is genuine, and it is unusual — outside code is not something a live interplanetary mission normally carries. It is also much narrower than the headline suggests, in four specific ways worth pulling apart before anyone starts writing a proposal.
The code runs on a spare core, not the spacecraft
The first distinction is where the software actually runs. Hera's onboard computer uses a European-developed dual-core LEON3 processor. One core operates the actual spacecraft. The other has been set up as a "safe sandbox environment" optimised to host guest software. So running software in deep space here does not mean taking the controls of the probe; it means running your code on a walled-off second core while the flight-critical core carries on untouched. The guest software cannot reach past its sandbox to fly the spacecraft — that is the whole point of splitting the job across two cores.
The supervision is just as tight. ESA says a hosted experiment runs for only two to three hours at a time and is shut off immediately if any problem is identified. Access to the spacecraft's instruments and subsystems will be provided, but on a short leash. This is not an open terminal 150 million km away. It is a brief, monitored window on a spare processor, with a hand on the switch — and the kinds of experiment ESA says it wants are narrow too: onboard intelligence, image processing, and AI-based approaches to operations and autonomy, rather than anything a team simply finds interesting.
Who the invitation is actually for
The second distinction is eligibility, and it is the one most likely to be misread. ESA is offering the opportunity to "European researchers and companies" — not to individuals, students, hobbyists, or applicants outside Europe. Ideas go in through ESA's Open Space Innovation Platform, the agency's standing route for outside proposals, rather than through any open sign-up form. If you are not a European research group or firm, the honest answer to "is this my chance" is no, however much the headline sounds like an invitation to everyone.
That gap between a headline's verb and its fine print is a pattern worth recognising. It is the same one we flagged in a NASA lunar-navigation announcement last week, where "delivers navigation system" described a single receiver handed to a contractor for a satellite that has not launched. Here the software offer is real and the sandbox is real; what the headline stretches is who gets to use it, and when.
The asteroid Hera is actually going to see
To understand the "when," it helps to know what Hera is doing out there in the first place, because the software call is a side-quest bolted onto a mission with a serious day job. Hera is the follow-up to one of the more remarkable space experiments of the decade. On 26 September 2022, NASA's DART spacecraft deliberately crashed into Dimorphos, a small moonlet about 160 metres across that orbits a larger asteroid, the roughly 780-metre Didymos. It was, in NASA's words, the world's first demonstration of asteroid deflection technology — a test of whether humanity could shift a space rock's path by hitting it.
It worked, and by more than expected. NASA later confirmed that the impact "altered Dimorphos' orbit around Didymos by 32 minutes, shortening the 11 hour and 55-minute orbit to 11 hours and 23 minutes." What DART could not do was linger to measure the crater it left, the asteroid's exact mass, or how efficiently the collision transferred its energy — the numbers that decide whether the technique could ever be aimed at a real threat. That is Hera's job. Launched on a SpaceX Falcon 9 from Cape Canaveral on 7 October 2024, the probe is on course to reach Dimorphos this autumn for what ESA calls a close-up "crash scene investigation." The guest-software programme only begins once that investigation is done.
ESA has already been rehearsing careful software at this distance
The sandbox offer did not come out of nowhere. In July, ESA uploaded a software upgrade to Hera while the spacecraft was roughly 140 million kilometres from Earth — and the way it did so shows how much caution the agency brings to changing code on a probe it cannot physically reach. The new software was first run on a functional replica of Hera, nicknamed "the Bench," at prime contractor OHB in Bremen, flown against simulated models of the asteroids and made to talk to stand-in copies of Hera's CubeSats over the same inter-satellite links it will use in flight. Only after the replica behaved was the upgrade sent to the real spacecraft.
The distance is the reason for all that rehearsal. At around 140 million kilometres, as Universe Today put it, "even moving at the speed of light, that signal takes nearly eight minutes just to arrive, then another eight minutes for a reply to come back." A controller who sees something going wrong cannot react in real time; by the time a warning reaches the ground and a command returns, a quarter of an hour has passed. That lag is exactly why the guest-software design leans on a sandboxed core, short run windows and an automatic cut-off rather than on a human watching live. The safeguards are not bureaucratic caution — they are the only kind of oversight that physics allows at that range.
Why letting outside code aboard is a real departure
Set against that backdrop, the offer is more interesting than its slogan. Deep- space missions are normally run on procedures validated to exhaustion, precisely because a mistake cannot be walked back once a spacecraft is this far away. Inviting experimental, not-fully-validated code aboard cuts against that entire culture — which is why the sandbox core, the short run windows and the instant shut-off exist. They are the price of doing something a flight-operations team would otherwise refuse outright. The story here is not the novelty of "software in space"; it is that ESA has engineered a way to say yes to outside code without putting its flagship planetary-defence mission at risk.
Dietmar Pilz, ESA's Director of Technology, Engineering and Quality, framed the programme in terms of what it is meant to seed. "This is an exceptional opportunity that will help accelerate European innovation, enabling researchers and industry to push the boundaries of onboard intelligence and autonomy," he said in the announcement. "We invite Europe's innovators to shape the next generation of intelligent, robust and autonomous space missions." Stripped of the framing, the target is software that lets a spacecraft judge more for itself and lean less on a ground team it can only reach on a sixteen-minute round trip.
The timeline runs after the science, not before it
The fourth thing the headline hides is when any of this happens — which is not soon. By ESA's own schedule, guest experiments do not run until the probe has finished its asteroid survey, at which point it becomes what the agency calls a "unique flying software laboratory 150 million km from Earth." The application clock is staged to match. ESA plans to select the winning ideas in mid-October 2026, sets a deadline of 31 May 2027 for submitting the full implementation, and pencils in operation for a single one-month window in August 2027.
A team that answers the call this autumn would therefore be writing code now for a machine that will not be free to run it for the better part of a year — and only once Hera has finished the mission it was actually built for. That is not a reason to ignore the offer. It is a reason to read it for what it is: a rare, tightly bounded chance for European labs to fly experimental autonomy software on a real deep-space probe, not the open door to deep space that the words "your chance to run software" first suggest.
Sources and verification
The offer, eligibility, OSIP submission route, the dual-core LEON3 sandbox, the two-to-three-hour run limit, the mid-October 2026 selection, the 31 May 2027 deadline, the August 2027 operating window, the 150-million-km figure, the launch and arrival timing, and the intended focus on onboard intelligence and autonomy all come from ESA's 5 August announcement, "Your chance to run software in deep space on ESA's asteroid mission." The Dietmar Pilz quotation was confirmed word-for-word against a raw reproduction of the release after two rendered reads of the ESA page disagreed on its wording. The DART figures — the 26 September 2022 impact, the asteroid sizes, and the 32-minute orbit change — come from NASA's DART mission page and its confirmation release. The account of the July in-flight software upgrade and the "Bench" replica at OHB is from ESA's earlier release, and the eight-minute one-way signal time at 140 million km is quoted from Universe Today's report on that upgrade.
What the sources do not give, and what this article therefore does not state: an exact arrival date beyond "this autumn," a precise completion date for the asteroid science, any prize or payment for selected teams, or the number of experiments ESA will choose. Two other ESA staff are quoted in the announcement, but their wording could not be independently confirmed against a raw source, so no quotation from them is used here. The ESA pages return an automated-access error to link checkers and were read through a rendering fetch and cross-checked against the mirrored copies linked above.