How Swift programming could lead to safer missions to Mars

By Chris Bailey, on


On Dec. 11, 1998, NASA launched the Mars Climate Orbiter from Cape Canaveral on a mission to Mars. The aim of that mission was to spend one Martian year studying the climate and atmosphere of Mars and to act as a communications relay for a future Mars Polar Lander mission. On Sept. 23, 1999, after 284 days, radio contact was lost and never reestablished, resulting in the mission being declared a loss on Sept. 25, at an estimated cost of $327.6 million.

This raises two questions: “Why did the mission fail?” and “How does that relate to Swift programming?”

Mars Climate Orbiter mission failure

Over the Climate Orbiter’s 415 million-mile journey to Mars, it made a number of trajectory modification maneuvers (TCMs), each designed to make small changes to its course in order to set it into orbit around Mars. The last of these TCMs, TCM-4, was due to bring it into position for its final insertion into orbit at an altitude of 140 miles above the surface. Unfortunately, after TCM-4 was completed, the Climate Orbiter was much closer to the surface than expected, at around 35 miles from the surface. This resulted in the disintegration of the orbiter in the Mars atmosphere.

Cause of failure

The eventual cause of the failure was determined to be in the software, due to a discrepancy between two interoperating components. The first, developed by Lockheed Martin in Bethesda, Maryland, was responsible for calculating the thrust produced by firing the thrusters, and the second, produced by the NASA Jet Propulsion Lab in Pasadena, California, used this data to calculate the position and trajectory of the orbiter. The data was transferred between these two pieces of software through a software interface specification.

The discrepancy between the two components was alarmingly basic. The thrust values provided by Lockheed Martin were in pounds-to-seconds, whereas the trajectory software expected the data to be in newtons-to-seconds. As one pound-to-second is equivalent to 1.488 newtons-to-seconds, the calculations for position and trajectory were incorrect. Attempts to correct the position used the wrong amounts of thrust.

Lessons for software development

Though the cause of the Mars Climate Orbiter software failure seems obvious on the surface, the underlying reason was really the challenge of software development and interoperability across siloed teams. Regardless of skill or experience, having two teams building independent implementations to a specification results in the possibility of inconsistencies. Specifications must be exact, without any room for potential interpretation, in order for the two implementations to interoperate correctly. If the specification is not 100 percent exact, developers have the scope to add their own interpretation of what the specification means, which may not match that of the other team.

Software interoperability and mobile development

The software pattern of having two application components that communicate through an interface is exactly the pattern used in mobile applications where they communicate with back-end server components, typically through a REST API. Here, that exchange of data between components, typically developed by two separate teams, has the same scope to introduce failures. In this case, the data was for thrust, but an example of data that is more commonly passed between mobile applications and their server components is date and time. This can be a particular area for challenges given time zone differences, with the mobile device and the server located in two different regions. Errors can be introduced if both sides aren’t using the same time zone or transferring the data using the same date and time format.

How does this relate to Swift programming?

With the addition of Swift on the server as well as the mobile client, Swift is now bringing the ability to break down the silos between the mobile application and back-end server teams. Rather than having the mobile client and back-end server components developed by separate teams in separate programming languages to an agreed-upon REST API specification, the availability of Swift on both sides enables the silos to be removed and for more collaborative development to occur.

At the most basic level, the client and back-end server teams are able to view and review each other’s code, as they are written in a common language everyone understands. This means the two teams agree upon the API specification and the behavior of the code on each side of the interface. Additionally, it becomes possible to share the interface code itself, along with the data model that is being passed, between the two components. This means that when a mobile client uses a common design pattern such as Model-View-Controller or Model-View-ViewModel, those models can be reused on both the client and the server, ensuring the consistency of the data itself, what the data means and how it is used.

Swift programming for safer missions to Mars?

Though no one is suggesting that Swift should be used for the SpaceX-manned missions to Mars proposed by Elon Musk — at least not yet, anyway — the ability to write end-to-end applications with Swift both from the mobile client and back-end server reduces and removes the risk of experiencing a whole category of software interoperability problems. It may seem that mistakes such as using pounds-to-seconds instead of newtons-to-seconds is so obvious that it would be spotted during code review, unit testing or integration testing, but those are the types of mistakes even rocket scientists can make.

About The Author

Chris Bailey

Runtime Architect for Swift at IBM

Chris is a Senior Technical Staff Member (STSM) and Runtime Architect at IBM. He has worked on programming languages for over 15 years, largely focussing on Java, Node.js and Swift. He is a committor for the Swift core libraries, and a member of the steering team for the Swift Server APIs project.

Articles by Chris Bailey
See All Posts