So you have a prediction function that takes as input your previous estimated state and some form of "common sense" that's hard-coded or learned and which outputs a prediction of the current state. Then you look at your current measurements and if one of it disagrees to much it gets downweighted or outright discarded. The updated estimate is then computed from the prediction and the current measurements.

Or... run the flight controller through a 'fuzzer' that throws lots of unexpected scenarios at it. To be honest I'm rather disappointed that a project at this level has succumbed to a bug like this. It's a few thousand dollars of additional dev effort versus the whole project failing; classic small certain initial cost versus large possible future cost (see Taleb's Antifragile, systemic failure of financial markets, etc.)

Ho hum.

We in hindsight, now know that a little extra development could have avoided the problem.

The trick is trying to figure out where to spend your limited resources as the project is going.

There are lots of areas that might have caused problems. There may well be other flaws in the system that would also have caused a failure on descent.

In a situation such as this where you don't have the funds to test everything to the level you would like and the cost of a failure is large, I wonder if a reasonable compromise is to hire a smallish team of 'adversaries'. I.e. their full time job is to try and find issues with other people's work; and to ask what could go wrong, or, what is likely to to go wrong - let's go see if we can break that.

I also find the idea of a risk register useful. I.e. during development you'll often have thoughts about whether particular edge cases are truly being handled properly, but often the day to day cost versus benefit decisions mean you can't explore all of these issues. If however you log them then this can serve as a source of ideas for an adversarial team, or indeed your own investigations if you happen to have bits of free time for testing.

As I see it with the limited information we have right now it seems that either the error was made when writing the requirements for the IMU or the IMU wasn't the correct one. Having worked writing navigation software I cannot help siding with the software developers. The IMU is usually the central piece of the navigation system, at best they could have flagged it as failed but that is usually way more improbable that the altimeter failing. And even if they discarded the IMU measures I don't know what other sensors could be used to get at least the vehicle attitude. I think that after the saturation they were doomed and a software solution is not realistic.

I would expect such a role to be holistic; to consider the entire system and ways it could fail. The boundaries between sub-systems would be high on the list of targets; software-software, software-hardware, hardware-hardware.

It's not a matter of siding with anyone, it's about accepting that an error has been made at some level, and asking if there are general purpose strategies for increasing the probability of identifying errors without having to build a simulation. Simulations of course have all the same problems - they're complex and therefore expensive and will contain defects.

Regarding the other point about probabilistic models compensating for sensor failures; it depends on which sensors fail and when. Parts of a descent are highly predictable, so e.g. if you know height and you're in free-fall then you can model pretty accurately where you're likely to be in +t seconds, and can use that as a prior for sensory input. OTOH if you're in the final landing stage using retro-thrusters then feedback sensors are paramount to doing landing correctly.

I accept that a probabilistic model would be more expensive to develop; initially anyway, and therefore may be unrealistic with the resources available.

In the case of an altimeter it makes sense to be aggressive with the 'common-sense' component to throw out bad data. But with other things like temperature, you wouldn't want to throw out data that could look wrong, but could actually be caused by some unknown phenomenon (like say, superheated gas pockets on mars) as that's exactly the type of weird stuff you'd be interested in.

I guess the problem is distinguishing [data that differs greatly from what was expected] and [data from a sensor malfunctions]

https://en.wikipedia.org/wiki/Sensor_fusion

TIL, thanks.

Well, computer vision is a different issue. Imagine you're a human sealed inside this thing, with no vision from the outside. You reach the point when the parachute's supposed to deploy, you feel something goes wrong - there's a big force, or it's in the wrong direction. Did the parachute rip off? Did it fail? You look at your two altimeters; one says that you're 3.5km up, one says that you're at almost ground level (that it's negative is a red herring I think - the probe knows the readings might be noisy and expects to handle that). What do you do?

It would also require you to anticipate the malfunction in which case you already know that things like that could happen, in which case you'd likely determine how it could happen and how to avoid it and continue having useful data. Sounds to me like a better solution than trying to recover without data.

> This in turn successively triggered a premature release of the parachute and the backshell, a brief firing of the braking thrusters and finally activation of the on-ground systems as if Schiaparelli had already landed.

It would have been better to do nothing, in the hope that the altimeter data will resume to reasonable values, especially since the article mentions that the error is not supposed to last long:

> Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.

All inputs and outputs should be run through sanity checks, with a plan for when they go wrong.

Essentially, when you've got a system that can't be fixed, plan for failure of each and every component (in isolation).

... and that was a single sensor out.

This is not a new idea. Airplanes cannot fly without instruments, and all the instruments have backups and alternate means. Everything deemed "flight critical" has a backup alternative.

My friend's Honda literally stopped combustion when his battery died while driving (no, I have no idea how, but that was the diagnosis).

In contrast, I've limped my Miata along on alternator-only when the battery wouldn't hold a charge. Note: feathering the gas at a stop with brakes and clutch depressed to keep your spark from dying is an "interesting" experience.

More fun is driving a vehicle with no clutch: stalling at every stop and starting the motor in first gear, and shifting without clutching. I had to do that in my '83 280ZX in its last days.

They weren't telling that. As far as I understood, the sensors were fully right, the software just hasn't expected the rotation to last "so long" -- the whole second, so it calculated the result wrong ("negative height") by incorrectly processing these multiple (in time) for their model unexpected inputs.

If radar altimeter had never had a lock, either the radar altimeter has faulted in a way you can't detect, or you are above the lock range for your radar altimeter.

If the radar altimeter had locked, you have a very accurate measurement of height above ground.

This is why I'm deeply pessimistic about achieving human level AI any time soon, even within the next 100 years. I'm 50 years old today. AI researchers back when I was born expected to have substantially solved AI as a problem by now, but we're still barely scratching the surface of a very big domain. This accident is a really good demonstration of the limitations of modern computer systems in terms of autonomous independent situational awareness.

>The first thing to do was to try to seal up the hole. This turned out to be impossible, because the ship’s sensors couldn’t see that there was a hole, and the supervisors, which should have said that the sensors weren’t working properly, weren’t working properly and kept saying that the sensors were fine. The ship could only deduce the existence of the hole from the fact that the robots had clearly fallen out of it, taking its spare brain-which would have enabled it to see the hole-with them.

You could stack layer upon layer of fault detecting modules and supervising software and error and redundancy modules, but then you'd probably wind up with something like Dark Star's Bomb 20:

>Unfortunately, Doolittle has mistakenly taught the bomb Cartesian doubt and, as a result, Bomb #20 determines that it can only trust itself and not external input. Convinced that only it exists, and that its sole purpose in life is to explode, Bomb #20 states "Let there be light," and promptly detonates.

Notably, this obviously wasn't a failure case they programmed for. But it does seem a pretty fragile system to throw across the solar system in retrospect.

Not everything is as easy as it seems.

The effect is that the intended landing site is at an altitude of -250m, and the lowest point on Mars is at an altitude of -8200m.

That is, how do you develop fault-tolerant software and at the same time have logic that would reject some sensor readings if they deviate too much from up-to-now readings?

How many readings would you reject in the hope that fresher readings would be better?

I doubt anyone care about my opinion, but since you ask, I do notice that simulation seems to be a big part of their development. So I'm sure there has to be a way to use some kind of an evolutionary algorithm for creating descent procedures.

First, you define a Bayesian model for the system. This includes discrete propositions such as "sensor X is not working" as well as things like a description how the craft's velocity, angular velocity and displacement at t0 can evolve to at t1, expressed as a continuous probability distribution. This takes into account the prior distribution for altitude.

All sensor inputs have distributions -- generally gaussian -- describing what values they could read given the "actual" value they're supposed to be measuring if they're not broken and giving completely erroneous results.

Feeding sensor inputs into this model as they're received to produces a posterior describing the craft's physical state probabilistically. Dimensions which are relevant only insofar as they affect knowledge of the craft's physical state (such as "sensor X is not working") are marginalised out.

Secondly, you define a utility function. This function takes some definite physical state of the craft's and a possible control output, and describes how "good" the outcome of that is. Then you choose the control outputs that maximise the expected utility, integrated over the craft's posterior state distribution.

If sensor X started giving results unlikely under the time evolution model, P(Sensor X is not working|inputs,control signals,prior information) would start to increase very rapidly.

If, somewhow, this probability was only 0.5, but the sensor was showing results that the craft was below the ground, the decision process would "decide" that "if sensor X is telling the truth, firing the landing thrusters will not lead to successful mission completion; if sensor X is lying it is too early to fire the landing thrusters" and not fire the thrusters.

In reality, such a situation is absurd because sensor X showing the craft below the ground would lead to an extremely high probability for "sensor X is not working". However, the point is that even under extremely pathological conditions decision theory will continue to give reasonable results.

One important consequence to note is that the sensor readings and state estimate do not matter in themselves, only as inputs to the decision theory process.

To answer your specific question: if sensor X is determined to be, with high probability, faulty, its inputs aren't "discarded" per se, but will have a very small contribution to the state estimate. If sensor X is only believed to be faulty with moderate probability, both possibilities are considered and the optimal decision will be made given the information available and utility function.

For more information, I recommend reading chapters 13 and 14 of "Probability Theory: The Logic of Science" by E.T. Jaynes [0].

[0]: http://www.med.mcgill.ca/epidemiology/hanley/bios601/Gaussia...