A Second Core, a Planned 2027 Campaign: ESA Opens Hera to External Software

ESA announced on 5 August that researchers and companies from its Member States can propose software to run aboard Hera, its asteroid mission. ESA describes Hera as operating around 150 million km from Earth during the planned 2027 campaign when this software window opens — the spacecraft is not there now.

The window is not immediate, and it follows rather than overlaps with Hera's primary asteroid-investigation phase. Hera is still in cruise: ESA is targeting arrival at the Didymos and Dimorphos system in November 2026, a month earlier than originally planned, and expects the mission's primary objectives there to be complete by mid-2027. The software would then run during a one-month period planned for August 2027, at which point ESA describes the spacecraft as around 150 million km from Earth.

The announcement reads as an opportunity notice. For Space Insights, the more interesting content is architectural, and it sits underneath the invitation.

What is actually on offer

Proposals enter through ESA's Open Space Innovation Platform, open to ideas from across ESA Member States. According to ESA's 5 August announcement, outline ideas are submitted first for initial evaluation, with selection expected in mid-October 2026; the live OSIP campaign page, however, currently shows evaluation starting on 15 October 2026, so the exact date should be read as unsettled rather than fixed. Teams taken forward would then submit full implementation packages and source code by 31 May 2027, for a one-month operating period ESA plans for August 2027. Each of these dates is ESA's plan as set out in the announcement or the live call, not an event that has occurred. ESA's news release highlights onboard intelligence, image processing, and AI-based operations and autonomy as target areas, with the stated aim of reducing reliance on ground control and increasing mission resilience; the live OSIP call itself lists a wider set of categories, including guidance/navigation/control, data compression and security, anomaly detection and science classification, and new operational concepts.

The hosting arrangement is specific. Hera's onboard computer runs on a European-developed dual-core LEON3 processor. One core operates the spacecraft; the other carries a sandbox environment ESA describes as optimised to host guest software. Individual experiments would typically run for two to three hours per day, within a total environment ESA expects to make available for up to ten hours a day, and would be shut off immediately if any problem is identified. ESA's news release describes access to spacecraft instruments and subsystems as fully facilitated; the OSIP technical description is more specific still, stating that experimental software cannot access spacecraft hardware directly — all data and function access runs through platform-provided services and interfaces.

Three ESA figures are named in the announcement. Dietmar Pilz, ESA's Director of Technology, Engineering and Quality, said ESA is "looking for targeted, innovative experiments that push onboard intelligence beyond today's procedural boundaries, while running safely alongside Hera's flight-critical systems in a protected 'sandbox' environment". Ian Carnelli, Hera mission manager, said that "by this time next year, Hera's asteroid investigation phase should be over, but the spacecraft still holds extraordinary promise". Jorge Lopez Trescastro, ESA's Hera software engineer, set out the containment rationale: the priority is "to perform these experiments in an entirely safe way", which is what the dual-core processor allows. All three are quoted in the ESA release of 5 August 2026.

Why the isolation is the read

Flying third-party code on an operational spacecraft in deep space is not a routine offer, and Space Insights reads the constraint as an engineering one rather than a policy one: flight software is qualified as a whole, so anything sharing a core with the systems that manage attitude, power and communications carries the consequences of its own faults into them, and those consequences are not recoverable at a light-time delay measured in minutes. That qualification argument is this article's own engineering reading of why such offers are rare; ESA's announcement does not set it out in those terms.

The second core changes the risk calculation rather than the ambition. On the architecture ESA describes, an experiment that hangs, overruns or fails outright would take down an experiment rather than the core that is flying Hera. The bounded execution window and the stated immediate shut-off do similar work from the other direction: they cap how long anything unqualified is running.

Isolation starts with the separation between the two processor cores, but it does not end there. Guest software runs in a memory-protected environment on the second core, and it accesses spacecraft data and functions only through platform-provided interfaces — not by reaching directly into Core 0's memory or the spacecraft's hardware registers. ESA's own framing of "facilitated" instrument access sits alongside that harder technical constraint from the OSIP call, and both matter: the facilitation is what makes the offer worth taking up, since an experiment that could see nothing would demonstrate nothing, while the interface-mediated access is what keeps that visibility from becoming a route into flight-critical systems.

ESA describes the second core as carrying a sandbox environment that has been optimised to host guest software. What the sources reviewed here do not establish is when that hosting environment was configured for this specific opportunity — Hera's dual-core processor has been part of the spacecraft since before launch, but that is a different claim from the sandbox having been built and tuned in advance specifically to host outside proposers. Space Insights does not extend the "optimised to host guest software" description into a claim that the capability sat designed-in and waiting since launch; that would go beyond what ESA has published. ESA states that the sandbox was optimised to host guest software; a stronger designed-in-before-launch framing is not supported by the sources reviewed and is not used here.

How this compares with ESA's own in-orbit demonstration lineage

ESA's own announcement draws the comparison worth making, rather than leaving it to inference: the release places Hera's opportunity in the same spirit as earlier ESA in-orbit software demonstrations, naming Proba and OPS-SAT specifically. What is different about Hera is the setting rather than the concept. Proba and OPS-SAT are dedicated, Earth-orbiting technology-demonstration platforms built for exactly this kind of external experimentation. Hera is not: it is a planetary-defence mission built to investigate an asteroid, already flying in deep space, and the software opportunity is a secondary use of capacity ESA carried alongside that primary mission, opened only after the primary science phase.

Space Insights cross-file editorial read

Read that way, the announcement is a small instance of a larger question European space has not settled: what happens to the capability aboard missions that remain healthy once their primary objectives are complete. Hera is not a dedicated technology-demonstration mission — it was built to investigate an asteroid, and that comes first. Space Insights reads the opportunity as extending ESA's own Proba/OPS-SAT lineage into deep space and into an operational mission, rather than as a stand-alone case. What is unusual, against the European in-orbit demonstration work Space Insights tracks, is not that a European mission carries a sandbox for guest software — ESA has done that before, on its own dedicated platforms. It is that the sandbox here sits on a deep-space planetary-defence mission already in flight, opened to outside proposers only after its primary science phase, rather than on a platform built for that purpose from the outset.

This is a Space Insights editorial reading, not an ESA statement. The primary source path for the Hera facts runs to ESA's announcement of 5 August 2026, its Hera arrival update of 7 October 2025, and the live OSIP campaign page. The wider question about designed-in capability aboard missions that remain healthy once their primary objectives are complete is Space Insights' own cross-file framing, built from its continuing coverage of European in-orbit demonstration and mission-extension practice, and is not a question ESA poses in any of the documents cited here.

The announcement does not address whether this becomes a repeatable pattern across ESA missions or stays specific to Hera's architecture and phase; it is scoped to Hera. It makes no claim of precedent and none should be read into it.

For research groups and companies deciding where to seek flight heritage over the next two years, the operative read is procedural: the entry point is an outline idea through ESA's Open Space Innovation Platform, open to ideas from across ESA Member States, with evaluation ESA's announcement places in mid-October 2026 and the live campaign page currently shows starting 15 October 2026; what is on offer is a bounded execution window with interface-mediated instrument access on a platform already in deep space. Whether a comparable window follows on another European mission is the thing to watch.

What we are not saying

We are not saying Hera has completed its primary objectives. The spacecraft is still in cruise and has not yet arrived at the asteroids; arrival is targeted for November 2026 and ESA expects the primary objectives to be complete in mid-2027.

We are not saying that any experiment has been selected, or that any has flown. Selection/evaluation is planned for mid-October 2026 per ESA's announcement (the live OSIP page shows 15 October 2026) and operation for August 2027; all of these are ESA's stated plan rather than events.

We are not saying ESA has committed to opening other missions on the same terms. Nothing in the announcement supports that.

We are not saying the containment on Hera is simply a line drawn between two processor cores. ESA's own technical description of the call states that guest software cannot access spacecraft hardware directly and reaches data and functions only through platform-provided interfaces — a stronger and more specific claim than core separation alone, and the one this article relies on.

We are not saying the sandbox was purpose-built and waiting, unused, since before Hera's launch specifically to host outside proposers. ESA describes the sandbox as optimised to host guest software; when that optimisation was carried out for this opportunity is not established in the sources reviewed, and this article does not claim it predates the OSIP call.

We are not saying the sandbox constitutes a formal safety certification for third-party code. ESA describes a memory-protected sandbox on the second core of a dual-core processor, with a bounded execution window and immediate shut-off on anomaly, which is a containment measure, and the distinction is worth keeping.