A 193,1 million USD loss because of a bad conversion

December 11th, 1998. The Mars Climate Orbiter blasts off, starting its voyage of over 200 million kilometers to Mars. Its mission was to orbit and survey the red planet, looking at both the atmospheric conditions and any surface changes due to climate. It was part of a project to send several missions to Mars and was to pave the way for future landers.

23rd of September 1999. After a long journey, the Mars Climate Orbiter begins a series of maneuvers to slow its speed and to place itself into orbit. It had been flying on a course calculated with as much precision as possible, but we simply cannot send a probe to another planet without some sort of course correction from Earth. Communications via radio can take anywhere between 5 minutes and 21 minutes, depending on the distance to Earth. Corrective procedures had been previously calculated on the ground and loaded into the onboard flight computer. Everything was ready. Mars Climate Orbiter prepared to burn its thrusters to slow down and enter a stable orbit, the final part of a long trip. During the procedure, it passed behind Mars, severing communications. 21 minutes later, it was supposed to exit the planetary occlusion and resume communications but was never heard from again. The mission was declared a loss two days later.

An electrical voltage can represent any physical quantity...

Most of us are used to switching between scales frequently, often without even knowing it. On a business trip to the US, my American colleague was in shock looking at the thermometer of the car, where the temperature showed 0. I shrugged it off, living in France, I am used to a winter temperature of 0. When I got out of the car, it hit me. He was talking about Fahrenheit when I am used to Celsius. His 0 Fahrenheit was -18 in my Celsius, well below what I was expecting and far below the clothes that I brought for the occasion. The consequences were far less dramatic than the fate of the Mars Climate Orbiter, but it was still a mistake. While it is fairly easy to convert between Fahrenheit and Celsius (take your temperature in Fahrenheit, take away 32, and then divide the result by 1.8 to obtain the result in Celsius), there are other scales that are more complicated.

What about your embedded design? If you are using an LM35 temperature sensor, you are using a precision sensor calibrated for Celsius, one that will deliver 10 millivolts per degree Celsius. On the other hand, if you are using an LM34, you are again using a precision sensor, but one calibrated in Fahrenheit, 10 millivolts per degree Fahrenheit. When you are using this in a design that you control, it is up to you to read the right temperature. The data you receive doesn't have any information identifying what it is. There are no units; there are no scales.

Following the disappearance, an investigation was ordered to understand what happened. The mission was costly, and they had to make sure that whatever brought the mission down never happened again. Several contractors were brought in on a project of this scale, each handling a specific part of the project. It did not take too long to find the culprit, a simple mathematical equation. Ground-based computers ran calculations and fed the results directly to the spacecraft. The ground-based software delivered results in a US customary unit, and the spacecraft accepted those results in SI units. Instead of receiving the anticipated newton seconds, the results were in pound-force seconds, off by a factor of about 4.5, so the thrusters burned much longer than they should have. By simulating what would have happened using these values, it became clear that the angle of attack was too steep and would have brought the spacecraft too close to the surface. It was expected to come within 110 km of the surface but was programmed to enter 57 km, over 20 kilometers below the minimum survivable altitude for the orbiter. It either burnt up in the atmosphere or bounced off the atmosphere and entered a heliocentric orbit, never to be heard from again. An entire mission was lost to a simple conversion.

Embedded scales

We often work best when we have rules to follow, things that must be put in place to achieve a goal. A sort of fail-safe, if you will. Guidelines on how to do things, and everyone must be aware of that. If the tools are good, you probably don't even notice. In large companies that have offices around the world, it is the email client that will change the timezone according to who is invited; if in France I arrive at 8 AM for a business meeting with the US at 8 AM, then I'm going to feel very alone for quite a few hours. In embedded systems, we don't have the processing power of a computer, and we don't necessarily have the luxury of signing every communication and value with a unit. We tend to just say that every time stamp on the network is either local time, or if different timezones are involved, then we'll use GMT, UTC, or something like that (which is basically what happens with Unix and Linux boxes).

There are a few tools and libraries out there that force you to write a specific type of value. Linux has a nice way of telling the system what to use. One tool that I've found is Luos, a library used for inter-microcontroller communications that "forces" you to use SI in transactions, but also proposes a series of tools to convert. The LM34 will output Fahrenheit, the display will also use Fahrenheit, but transparently, this information will transit as Celsius, and if another part of the system needs that information in Celsius, then the conversion is automatic, you don't even need to convert it, or even know what unit your sensor was using in the first place.