Introduction
Usually, one of the first topics we see when studying physics is units and measurements. And then we come across some units that are not very common in many countries, such as feet and pounds. But we learn that there are conversion factors between these units and those we are used to, and generally, this topic is considered simple and even boring.
In this article, we will see how NASA has lost million-dollar projects due to simple unit conversion errors. We will also look at which unit system took man to the Moon in the Apollo Program by analyzing the source code of the onboard computer.
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 Mars’ orbit, communication with the probe 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 unit systems. The software used by the control team on Earth provided data in the United States customary units’ system (similar to the imperial system), while the probe used units from the International System of Units (also known as SI, from French Système International d’unités). As a result, incorrect instructions were sent to the probe, causing it to approach the planet too closely. It is believed that it was destroyed upon entering the atmosphere or was lost in space if it managed to exit the atmosphere. Mission cost: $327.6 million.
According to the report, the ground system that calculated the impulse of the probe produced results in pound-force seconds (lbf s) while the trajectory calculation system expected the result in Newton seconds (N s). The conversion is approximately 4.45, as shown in the image below using the SpeedCrunch calculator.
NASA had contracted the company Lockheed to make the mission’s software system, and the specifications requested that the entire system’s unit system to be the International System of Units. However, NASA chose not to blame Lockheed for the accident, stating that NASA itself failed to conduct checks and tests that would have alerted to the discrepancy. The report indicates that there were a series of internal communication and procedural failures, including showing that part of the team had already detected something strange in the data during the probe’s journey but decided to communicate by email(!) instead of opening a formal analysis procedure, which perhaps explains this posture of NASA. Let’s take a look at some report excerpts:
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), integration tests, where the result of one module is used as input for 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 with most accidents, there were human components that were crucial for the occurrence of the accident. This excellent article from IEEE Spectrum shows other aspects of this accident with more details and interviews. A section of this article shows that project participants reported decision-making problems that already existed at NASA previously and resulted in the unfortunate accident of the space shuttle Challenger, which killed the 7 astronaut crew members in 1986.
The decision-making process and risk management at NASA were also pointed out as one of the reasons for another space shuttle explosion four years after the loss of the MCO, in 2003, when the Columbia disintegrated upon re-entering the Earth’s atmosphere, also killing the 7 crew members.
Demonstration for Autonomous Rendezvous (DART)
In 2005, just 6 years after the loss of the MCO in the Martian atmosphere, another NASA project had issues. The DART’s main goal was to test automatic navigation techniques, being able to automatically dock with other aerospace devices while avoiding collisions. The project had no form of interactive ground control nor were there ways to update the software after launch. All orbit operations rely solely on pre-programmed criteria. DART collided with the MUBLCOM satellite during an approach maneuver. Mission cost: 110 million dollars.
In a preview of the report made by the accident analysis team, the software development process was heavily criticized. There were parameters in the code that were not used (residuals), no tests were done for various scenarios, and there was a unit conversion error in one of the simulation mathematical models.
It is noteworthy that a section of this preview states that the speed 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 there was a poorly done unit conversion 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, there is suspicion that some conversion factor from feet to meters incorrectly done in the form of addition may be in the code. Suspicion that increases given that there is mention of a unit conversion error in one of the simulation mathematical models (original: an omitted units conversion caused an error in a simulation math model.)
Unfortunately, more details were not made public as the full report was not disclosed. According to NASA, there were details protected by the ITAR – International Traffic in Arms Regulations of the United States. But the preview of the report makes clear various problems in the software development flow, as well as in the case of the MCO. The report also clearly shows the concerns of communication and software development at NASA, which was also targeted by the media at the time.
NASA and the International System of Units
The trip to the Moon
NASA’s history with unit systems is quite long. For instance, the Apollo Guidance Computer (AGC), the computer aboard the command module and lunar module of the Apollo Project, internally stored data in the International System of Units but displayed data and results in the United States customary units system. This was because the operational level people at NASA and the astronauts themselves understood the American system better.
Thus, although internally altitude and speed, for example, were stored in meters and meters/second, they were displayed in feet and feet/second. Similarly, masses were displayed in pounds although stored in kilograms. The analysis of the source code available makes this quite 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 code snippet, we have specifications for the Lunar Module engine. DPS stands for Descent Propulsion System and APS, Ascent Propulsion System. Note that in the code comments, indicated by #, the respective values in the American measurement system were placed.
The mission report itself is interesting from the perspective of unit systems. The part more oriented towards engineering, with data from the aircraft and the trip, uses the American system, while the part with the results of the experiments uses the international system. A reflection of the fact that, already at that time, the American scientific community used the international system more, probably because journals and other publications usually require this unit system.
The $300 million unit system migration
NASA began at some points in its history movements to transition to the International System of Units. It is fascinating this link from NASA’s website where an American law is cited that forces the use of the SI in government-funded programs unless its use is impractical. Governments and their brilliant legislators… It is not surprising that, a few lines later, it appears: “Although use of SI in the U.S. is increasing, aerospace is recognized as one area where adoption will be difficult, due to the long-standing use of the U.S.-based “inch-pound” system for aircraft.”. So it goes…
The case of the Constellation Program is emblematic concerning unit systems. 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 due to 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 it was requested that the metric system not be used, and a report was generated from the analysis of this request. Let’s 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 the SI. Much of this cost would come from the reuse of hardware and software from past programs, so that documentation and interface reviews would be necessary. And the team would also have found it impractical to make the change because there had been technical problems of other natures that led to the need to cut costs and streamline procedures to meet deadlines.
The response given by the reviewers in the report is sensational. First, they criticized the fact that the program raised the cost of adopting the 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 the SI could cost more in the future because much of the international community uses the metric system and training in the American system would be necessary.
Another argument of the Program team is that the conversion would add unacceptable risks to the project. But the report questions why then, in 2007 during the planning period of the Program, the metric system was selected under the justification of the team itself that it was simpler, less prone to errors, and aligned with NASA’s international policy. And it even cites the case of the MCO that we have already described to show that changing policy involving measurement systems with the project underway can lead to risks that, indeed, are unacceptable.
The Program team also tried to use the argument that parts and other components are usually manufactured with measurements compatible with the American system. However, the report states that measurements in the metric system are equally available and that, again, the overall life cycle should be considered. With industries increasingly migrating to the metric system, it was unreasonable 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 for commercial and personnel partnerships, all using the metric system.
The Program’s decision ended up clashing with another U.S. government agency, the National Institute of Standards and Technology (NIST). The report shows communication between the two state entities, pointing out that NIST was not at all satisfied with NASA’s posture. It is noteworthy this passage: “[t]he successful voluntary U.S. transition to the metric system is a critical factor in the competitive success of companies and the country. NASA is a flagship federal agency to which other agencies and industry look for leadership and inspiration.”
Finally, the last argument of the Program team was that the use of the metric system by NASA was hindered by the fact that the Department of Defense did not use it in its projects. This would mean that aerospace sector companies would not have as many parts available for the metric system, given the great influence of the Department of Defense contracts. Earlier in the report, it had already been shown that there are indeed enough parts available, and at this point, the report still cites Department of Defense projects that had been done entirely in the SI.
It seems that the space cowboys don’t care much about arranging disagreements… First NIST and now the Department of Defense. Someone there really doesn’t 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. Representatives of the companies complained, rightly, that NASA’s delay in migrating to the SI hindered the creation of a global aerospace market, in addition to hampering international research collaborations. After all, a state-owned company the size of NASA greatly impacted the market with each decision it made. Remember that we are talking about just over a decade ago.
Current situation
But how are we now, a decade after all this happened? Has NASA succumbed to the International System of Units?
Well, if you’ve read this article this far, you must have realized that the unit system is the least of NASA’s problems. What is evident are the various communication and management issues of these projects. If an apparently “simple” change of unit system has a cost of millions of dollars, imagine other factors involved in these projects? Each report clearly shows various project development problems, from software to equipment itself. The reality is that each project became increasingly larger and pricier, and money, even state money, is finite.
With this in mind, since the mid-2000s, NASA has intensified collaboration programs with private companies such as Boeing, Orbital, Sierra Nevada, and the most well-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 like Japan, Canada, and the European Space Agency. Thus, reality imposed itself, and when the American measurement system is still used, it is on a smaller scale and internally. Equipment and software are (hopefully) developed in the 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. The dissemination materials still use the American system. For example, see this material from the Space Launch System, a developing launch rocket. The material is clearly aimed at Americans themselves, which is to be expected from an American government agency, isn’t it?
Now see this material from 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 provider company, so it will seek to communicate in a way to have as many customers as possible. In addition, marketing and public perception of the company are also important.
If much of the world uses the metric system, it is essential for the company that people can understand their materials. This is noticeable in SpaceX’s launch videos:
In the videos, altitude is shown in kilometers and speed in kilometers per hour. This attracted the attention of the press 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 how the process of metrication is going around the world:
Conclusion
So, have you ever stopped to think that the topic of conversion/unit systems could have so many ramifications? Although the systems and conversions themselves are simple, there are various human factors involved, especially cultural ones. We also took advantage of the topic and had some discussions about software development. I hope you enjoyed the article, don’t forget to leave your comments and share.
Follow Chemistry Programming on social media. Check out some Python programming articles.
See you next time.
