Usually, one of the first topics we see when studying science is units and measurements. And then we run into some units that are not very common in many countries, including Brazil, such as feet and pounds. But we learn that there are conversion factors between these units and the ones we are used to, and this topic is usually considered simple and even boring.
In this article, we will see how NASA lost multimillion-dollar projects because of simple unit conversion errors. We will also see which system of units took humans to the Moon in the Apollo Program, by looking at the source code of the onboard computer.
If you prefer to watch a video, click the player below (the video is in Portuguese). The full article follows the video.
Mars Climate Orbiter (MCO) #
On December 11, 1998, NASA launched the Mars Climate Orbiter (MCO), a 638 kg spacecraft whose goal was to study the Martian climate. However, on September 23, 1999, when the probe was maneuvering to enter orbit around Mars, communication with it was lost.
One of the reports produced afterward to understand the reasons for the accident determined that the main cause was the use of conflicting systems of units. The software used by the control team on Earth provided data in the United States customary system of units (similar to the imperial system), while the probe used units of the International System of Units (also known as SI, from the French Système International d’unités). As a result, incorrect instructions were sent to the probe, making it approach the planet too closely. It is believed that it was destroyed on entering the atmosphere or, if it managed to leave the atmosphere, was lost in space. Mission cost: $327.6 million.
The figure compares the planned trajectory with the actual one:
According to the report, the ground system that calculated the probe’s impulse produced results in pound-force seconds (lbf s), while the trajectory calculation system expected the result in Newton seconds (N s). The conversion factor is approximately 4.45, as shown in the image below using the SpeedCrunch calculator.
NASA had hired the company Lockheed to build the mission’s software system, and the specifications required the whole system to use the International System of Units. However, NASA chose not to blame Lockheed for the accident, stating that NASA itself failed to perform the verifications and tests that would have warned of the discrepancy. The report points to a series of internal communication and procedural failures, even showing that part of the team had already detected something strange in the data during the probe’s journey, but decided to report it by e-mail(!) instead of opening a formal analysis procedure, which perhaps explains this stance by NASA. Let us look at some excerpts from the report:
In the MCO project, and again in the MPL project, there is evidence of inadequate communications between the project elements, including the development and operations teams, the operations navigation and operations teams, the project management and technical teams, and the project and technical line management. It was clear that the operations navigation team did not communicate their trajectory concerns effectively to the spacecraft operations team or project management. In addition, the spacecraft operations team did not understand the concerns of the operations navigation team.
An early comparison of these spacecraft-generated data with the tracking data might have uncovered the units problem that ultimately led to the loss of the spacecraft. When conflicts in the data were uncovered, the team relied on e-mail to solve problems, instead of formal problem resolution processes such as the Incident, Surprise, Anomaly (ISA) reporting procedure. Failing to adequately employ the problem tracking system contributed to this problem “slipping through the cracks.”
The report also shows that the software modules were tested separately, but due to file formatting failures (see page 17 of the report), the integration tests, where the output of one module is used as input to another, were postponed, and the team had little time for analysis.
The Software Interface Specification (SIS) was developed but not properly used in the small forces ground software development and testing. End-to-end testing to validate the small forces ground software performance and its applicability to the specification did not appear to be accomplished. It was not clear that the ground software independent verification and validation was accomplished for MCO. The interface control process and the verification of specific ground system interfaces was not completed or was completed with insufficient rigor.
As in most accidents, there were human components that were decisive in causing it. This excellent IEEE Spectrum article shows other aspects of this accident in more detail, with interviews. One section of the article shows that project participants reported decision-making problems that already existed at NASA earlier and resulted in the unfortunate Space Shuttle Challenger accident, which killed all 7 crew astronauts in 1986.
NASA’s decision-making and risk management process was also pointed to as one of the reasons for another space shuttle explosion four years after the loss of the MCO, in 2003, when Columbia disintegrated on reentering Earth’s atmosphere, also killing all 7 crew members.
Demonstration for Autonomous Rendezvous (DART) #
In 2005, only 6 years after the loss of the MCO at Mars, another NASA project ran into trouble. DART’s main goal was to test automatic navigation techniques, being able to dock automatically with other aerospace devices while avoiding collisions. The project had no means of interactive control from the ground, nor were there ways to update the software after launch. All operations in orbit depended solely on pre-programmed criteria. DART collided with the MUBLCOM satellite during an approach maneuver. Mission cost: 110 million dollars.
In the artist’s concept below, DART approaches the satellite:
In a preview of the report produced by the accident analysis team, the software development process was harshly criticized. There were parameters in the code that were not used (leftovers), tests were not run for several scenarios, and there was a unit conversion error in one of the mathematical simulation models.
It is notable that a section of this preview states that the velocity measured by the instruments was “about” 0.6 meters per second more than it should have been (original: DART’s primary GPS receiver consistently produced a measured velocity that was offset or “biased” about 0.6 meters per second from what it should have been.). Some suspect that a unit conversion was done wrongly in the code. Since 1 ft/s is equivalent to 0.3048 m/s, the difference in magnitudes is 0.6952 or, using the scientific terms of the report (haha), about 0.6. Thus, it is suspected that some conversion factor from feet to meters, incorrectly done as an addition, might be in the code. The suspicion grows given that there is a mention of a unit conversion error in one of the mathematical simulation models (original: an omitted units conversion caused an error in a simulation math model.)
Unfortunately, more details were not made public, since the full report was not released. According to NASA, there were details protected by the United States' ITAR, the International Traffic in Arms Regulations. But the report preview makes clear several problems in the software development workflow, just as in the MCO case. The report also clearly shows the concerns about communication and software development at NASA, which was also a target of the media at the time.
NASA and the International System of Units #
The trip to the Moon #
NASA’s history with systems of units is quite long. For example, the Apollo Guidance Computer (AGC), the computer aboard the command module and the lunar module of the Apollo Project, stored data internally in the International System of Units, but displayed data and results in the United States customary system of units. This was because NASA’s operational-level personnel and the astronauts themselves understood the American system better.
The figure shows the computer and its keyboard:
Thus, although internally altitude and velocity, for example, were stored in meters and meters/second, they were displayed in feet and feet/second. Likewise, masses were displayed in pounds, although stored in kilograms. The analysis of the source code that is available makes this very clear:
# *** THE ORDER OF THE FOLLOWING SIX CONSTANTS MUST NOT BE CHANGED ***
FDPS 2DEC 4.3670 B-7 # 9817.5 LBS FORCE IN NEWTONS
MDOTDPS 2DEC 0.1480 B-3 # 32.62 LBS/SEC IN KGS/CS
DTDECAY 2DEC -38
FAPS 2DEC 1.5569 B-7 # 3500 LBS FORCE IN NEWTONS
MDOTAPS 2DEC 0.05135 B-3 # 11.32 LBS/SEC IN KGS/CS
ATDECAY 2DEC -10
# ********************************************************************
FRCS4 2DEC 0.17792 B-7 # 400 LBS FORCE IN NEWTONS
FRCS2 2DEC 0.08896 B-7 # 200 LBS FORCE IN NEWTONS
SETLOC P40S1
BANK
COUNT* $$/P40
# *** APS IMPULSE DATA FOR P42 ***************************************
K1VAL 2DEC 124.55 B-23 # 2800 LB-SEC
K2VAL 2DEC 31.138 B-24 # 700 LB-SEC
K3VAL 2DEC 1.5569 B-10 # FAPS (3500 LBS THRUST)
# ********************************************************************
S40.136 2DEC .4671 B-9 # .4671 M NEWTONS (DPS)
S40.136_ 2DEC .4671 B+1 # S40.136 SHIFTED LEFT 10.In this snippet of code, we have specifications for the Lunar Module’s engine.
DPS stands for Descent Propulsion System and APS for Ascent Propulsion System.
Note that in the code comments, indicated by #, the respective values in the
American system of measurement were placed.
The mission report itself is interesting from the point of view of systems of units. The more engineering-oriented part, with data on the spacecraft and the trip, uses the American system, while the part with the results of the experiments uses the international system. This reflects the fact that, even back then, the American scientific community used the international system more, probably because journals and other publications generally require this system of units.
The figure below shows an example of each part:
The $300 million system-of-units migration #
At some points in its history, NASA started movements toward the transition to the International System of Units. This link on NASA’s website is fascinating: it cites an American law that forces the use of SI in government-funded programs, unless its use is impractical. Governments and their brilliant legislators… It is no surprise that, a few lines later, we find: “Although the use of SI in the US is increasing, the aerospace sector is recognized as an area where adoption will be difficult, due to the long-standing use of the US-based ‘inch-pound’ system for aircraft.”. Well, OK then…
The case of the Constellation Program is emblematic when it comes to systems of units. The program, started in 2005, was quite ambitious, proposing to complete the construction of the International Space Station and return to the lunar surface before 2020. We know that this did not happen: the program was canceled in 2010 because of its high costs, although some ongoing projects were redirected to other programs. The program had initially proposed that it would use the metric system, but… internally a request was made that the metric system not be used, and a report was produced from the analysis of that request. Let us briefly analyze this report.
According to the report, the Constellation Program team had estimated a cost of $368 million between 2009 and 2015 to make the transition to SI. A large part of this cost would come from reusing hardware and software from past programs, so that documentation and interface revisions would be needed. And the team would also have found it impractical to make the change because there were technical problems of other kinds that led to the need to cut costs and speed up procedures to meet deadlines.
The report thus estimated the cost of the conversion, year by year:
The response given by the reviewers in the report is incredible. First, they criticized the fact that the program had raised the cost of adopting SI. OK, but what about the cost of NOT adopting it? A life-cycle cost analysis was not done. Considering the internationalization of space programs, not migrating to SI could cost more in the future, because a large part of the international community uses the metric system and training in the American system would be needed.
Another argument from the Program team is that the conversion would add unacceptable risks to the project. But the report questions why, then, in 2007, during the Program’s planning period, the metric system was selected on the team’s own justification that it was simpler, less error-prone, and aligned with NASA’s international policy. And it even cites the MCO case we have already described to show that changing policy involving systems of measurement with the project under way can lead to risks that are, in fact, unacceptable.
The Program team also tried to use the argument that parts and other components are generally manufactured with measurements compatible with the American system. However, the report states that metric measurements are equally available and that, again, the overall life cycle must be considered. With industries increasingly migrating to the metric system, it was not reasonable to start a new program in the American system. And, again, the text at this point reinforces the importance of considering international partnerships for parts, as well as commercial and personnel partnerships, all using the metric system.
The Program’s decision ended up conflicting with another US government agency, the National Institute of Standards and Technology (NIST). The report shows the communication between the two state entities, pointing out that NIST was not at all happy with NASA’s stance. This passage is notable (paraphrased): "[a] successful voluntary US transition to the metric system is a critical factor in the competitive success of companies and of the country. NASA is a flagship federal agency to which other agencies and industry look for leadership and inspiration."
Finally, the Program team’s last argument was that NASA’s use of the metric system was hindered by the fact that the Department of Defense does not use it in its projects. This would mean that aerospace companies would not have as many parts available for the metric system, given the great influence of Department of Defense contracts. Earlier in the report, it had already been shown that there are enough parts available and, at this point, the report even cites Department of Defense projects that were done entirely in SI.
It seems that the space cowboys do not mind picking fights much… First NIST and now the Department of Defense. Someone there really does not like unit conversion factors and the metric system.
This decision was not well received by the private sector, as shown in this article from the time. Company representatives complained, rightly, that NASA’s delay in migrating to SI made it harder to create a global aerospace market, in addition to hindering international research collaborations. After all, a state-owned organization the size of NASA greatly impacted the market with every decision it made. Remember that we are talking about a little over a decade ago.
Current situation #
But how are we doing now, a decade after all of this happened? Has NASA succumbed to the International System of Units?
Well, if you have read this article up to here, you must have realized that the system of units is the least of NASA’s problems. What becomes evident are the various communication and management issues of these projects. If a seemingly “simple” change of system of units costs millions of dollars, imagine the other factors involved in these projects. Each report clearly shows several project development problems, from the software to the equipment itself. The reality is that each project has become bigger and more expensive, and money, even government money, is finite.
With that in mind, since the mid-2000s, NASA has intensified collaboration programs with private companies such as Boeing, Orbital, Sierra Nevada, and the best known, SpaceX. These programs saved NASA millions of dollars. Obviously, there are still programs led by NASA, but a significant part of them are in cooperation with companies and space agencies from other countries such as Japan, Canada, and the European Space Agency. Thus, reality imposed itself, and when the American system of measurement is still used, it is on a smaller scale and internally. Equipment and software are (hopefully) developed in SI.
This does not mean that the culture of the people involved and of the institution has changed. A simple visit to NASA’s website shows this. Outreach materials still use the American system. For example, see this Space Launch System material, a launch rocket under development. The material is clearly aimed at Americans themselves, which is to be expected from an American government agency, isn’t it?
Now look at this material on SpaceX’s Falcon vehicles. Throughout the document, the metric system is shown first, with the conversion to the American system in parentheses. After all, it is a service-providing company, so it will seek to communicate in a way that reaches as many customers as possible. Besides, the company’s marketing and public perception are also important.
If a large part of the world uses the metric system, it is essential for the company that people can understand its materials. This is notable in SpaceX’s launch videos:
In the videos, altitude is shown in kilometers and velocity in kilometers per hour. This drew press attention at the time of the first launches.
To get an idea of how much of our planet has already adopted the metric system, the following map shows the state of metrication around the world:
Conclusion #
So, have you ever stopped to think that the topic of conversion/systems of units could have so many ramifications? Although the systems and the conversions themselves are simple, there are several human factors involved, especially cultural ones. We also took advantage of the topic to have some discussions about software development. I hope you enjoyed the article, and don’t forget to leave your comments and share it.
If you want to read more about another situation where unit errors caused problems, see the case of the airplane that ran out of fuel in mid-flight.
See you next time.
