NASA’s Voyager Spacecraft Faces Software and Engineering Challenges

by priyanka.patel tech editor

Deep in the silence of interstellar space, two of humanity’s most ambitious emissaries, Voyager 1 and 2, continue to transmit data back to Earth. But the digital thread connecting these probes to the Jet Propulsion Laboratory (JPL) is increasingly fragile. For years, a popular narrative has circulated that these spacecraft are kept alive by a vanishing breed of engineers in their 80s, the only people left on Earth who can read the archaic code powering the mission.

While the sentiment captures a genuine anxiety about losing institutional knowledge, the reality of Voyager spacecraft code maintenance is more nuanced than a simple generational countdown. The challenge isn’t just that the engineers are aging; it is that the very nature of the software—and the fragmented records left behind—requires a specific, obsolete kind of expertise that is no longer taught in modern computer science curricula.

The Voyagers do not run on a single, mysterious language, nor are they managed by a handful of octogenarians. Instead, JPL is managing a complex intersection of 1970s assembly language, outdated ground-side tools, and a “digital archaeology” project to recover paper documentation that has vanished over decades of office moves.

The Architecture of a Bygone Era

To understand the difficulty of maintaining the Voyagers, one must first understand the extreme constraints of their hardware. The onboard computers run assembly language written for purpose-built General Electric interrupt-driven processors designed in the early 1970s. This represents low-level code that speaks directly to the hardware, far removed from the high-level languages like Python or Java used by today’s developers.

Each spacecraft utilizes three primary computer systems: the Computer Command Subsystem, the Attitude and Articulation Control Subsystem, and the Flight Data Subsystem (FDS). The FDS is the most critical for public visibility, as it packages the science and engineering data for transmission. It was also the subsystem at the heart of the Voyager 1 communications failure that lasted from late 2023 into early 2024.

There is a common misconception that the Voyagers “run on Fortran.” In reality, a distinction exists between the flight software and the ground-side tools. While Fortran was used for ground systems and older mission tooling, the actual flight operations depend on assembly. The scale of these resources is almost incomprehensible by modern standards; the total memory across the Voyager systems is roughly 64 to 70 kilobytes—smaller than a single low-resolution JPEG image today.

Institutional Memory and Digital Archaeology

The primary risk to the mission is not the language itself, but the loss of the context surrounding it. For nearly five decades, the mission has evolved, with significant software updates occurring around 1989 after Voyager 2’s encounter with Neptune to make the probes more autonomous for their interstellar journey.

However, the documentation for these systems was largely created on paper. As the project moved offices and teams shifted over 49 years, these records became fragmented. Suzy Dodd, the current project manager, has described the process of recovering this information as an “archaeology dig.” While the team possesses a reasonably good set of records, the search for specific logic often requires hunting through physical papers from the 1970s.

This loss of documentation creates a dependency on “institutional memory”—the unwritten knowledge held by the people who built the systems. This is where the generational story originates. Larry Zottarelli, one of the last original engineers who had been with the mission since the 1977 launch, retired in 2016 at the age of 80. His departure was framed by many as a critical tipping point, but the mission did not collapse.

The Succession Gap: Capability vs. Inclination

The current flight team at JPL is not comprised solely of engineers in their 80s. Suzy Dodd, for instance, began her work on the spacecraft in 1984 as a sequence designer for the Uranus encounter and returned as project manager in 2010. The engineering work has been successfully handed over to newer generations multiple times.

The Succession Gap: Capability vs. Inclination
Suzy Dodd

The real problem is a shortage of engineers who possess both the fluency in assembly language for custom, obsolete hardware and the patience to navigate the documentation gaps. In a modern industry focused on rapid deployment and high-level abstraction, the inclination to spend months deciphering 50-year-old assembly code for a mission with a definitive end date is rare.

Challenge Popular Narrative Technical Reality
Language Unreadable/Fortran Custom Assembly / Ground-side Fortran
Staffing Only engineers in their 80s Small JPL team; relies on retired consultants
Records Lost entirely Fragmented paper archives (Digital Archaeology)
Hardware Stable but old Power declining by ~4 watts per year

The Final Countdown

Regardless of the software’s maintainability, the Voyagers are fighting a losing battle against physics. Their power sources—radioisotope thermoelectric generators (RTGs)—lose approximately four watts of electrical output every year. To keep the spacecraft operational, JPL has been forced to systematically turn off scientific instruments to preserve power for basic communications.

The Final Countdown
interstellar space probes

According to the official Voyager FAQ, the spacecraft may remain within the range of the Deep Space Network until approximately 2036, depending on available transmit power. Engineering data will likely continue to return for several years after the final science instruments are powered down.

The challenge of maintaining the code is critical for the next decade, but after that, the problem becomes academic. By the time the last of the current experts retire, there will likely be no power left to run the code they spent their careers protecting.

The next major milestone for the mission is the 50th anniversary of the launch in September 2027, which remains the primary target for the team’s current operational planning.

Do you think we should invest more in preserving “dead” programming languages for the sake of historical science? Share your thoughts in the comments.

You may also like

Leave a Comment