OMG: Short of pulling out an old Arthur C. Clarke novel, these three vehicles, all related, crashed within the same mission profile. Two of the causes are laid at the feet of the demi-gods of software design and test. Clearly there were failures of the simulation/modeling environment and the use of actual hardware models in simulated but physical scenarios. F# would have been a big help in the simulation/modeling environment, likely aiding the modeling experts to more rapidly make changes to the simulations from data supplied by the hardware models running real physical scenarios.
One of the things that worries me about the concept of simulation and modeling is that it is not real without physical evaluation. I have had experience in the 80s and 90s in designing a flight control system and then having the opportunity of doing the actual flight test in the airplanes. Quite often the simulations were not only off, but the flight test team worried that the simulation team was maybe working on another aircraft. (Hey are there any MD-11 Flight test team from Yuma reading this? Leave a comment or hit my Facebook page.)
In the Mars Climate Orbiter (MCO), Mars Polar Lander (MPL) and Deep Space 2 (DS2), case the simulation and modeling team should have been able to find the errors that caused the problems in the MCO and MPL. What happened? Well, after the fact, the ability to determine the failure is somewhat difficult since the spacecraft’s are lying on a planet that is hundreds of millions of miles away. Yet, the MCO crashed due to the failure of dimensional analysis. The MPL likely crashed due to a control law (software) error with Hall Effect (magnetic detectors) in the landing legs indicating that the MPL had landed when it had just deployed the parachute. As to the DS2, the hardware appears to be the blame, mainly the battery structure was not tested prior to flight, and since the DS2 basically were dropped with the protective aeroshell from the MPL during re-entry without parachute or landing rockets, the simplest explanation is that the batteries broke on landing.
F# would be a useful simulation language, although without complete research, I have not been able to determine the simulation software for this vehicle, but in 1990s, it might have been FORTRAN. How would F# be used to extend the FORTRAN libraries in a useful manner? Don’t be confused, F# is an implementation of OCAML, and the language is NOT related to FORTRAN, except that both could be considered Functional Languages and not Imperative languages like C#, VB.NET, VC++ (sort of). However, F# is definitely designed to consume existing FORTRAN libraries, if you need to as an engineering simulation using previously designed algorithms. If using previously designed algorithms is a good idea, in the case of the MPL, it was likely that new algorithms should have been created and then tested against live physical tests as well as previous similar Mars landing systems.
For the next few blog entries I will be discussing the way F# would be used to create a new simulation, how to use existing FORTRAN libraries and how to hook into live physical tests
Links from the Mar Climate Orbiter (MCO), Mars Polar Lander (MPL) and Deep Space 2 (DS2)
Dimensional Analysis links: