ExoMars - Schiaparelli landing Options

[tolis]

Maybe the radar caught the heatshield flying down in its line of sight...

It might be, but the way the sentence is phrased points to a coding issue instead.
A simple unit conversion problem, for instance: alt=4km -> alt=4m.
Not to suggest that this is actually the culprit, just an example.

[Art Martin]

That would be mind blowing if the sequences of landing were placed entirely within the control of the just switched on radar without some background logic going on dealing with the timing of the descent. I would think that even if the craft overshot or undershot its target a bit, the overall timing of events would still end up within a few seconds of the expected and any results coming back from the radar which were way out of those parameters should be considered suspect. I'm a computer programmer but have never been involved in code for spacecraft so I'm talking only from the standpoint of someone that has written code where mistakes could cost a lot of money. You put in what ifs and alternate paths for the logic in those critical events. Of course I have the luxury of not having the decisions come at me over a very short span of time. I'm curious how NASA would handle this in code. Radar would seem to be a critical component but what would software do if the results from it made no sense?

[nogal]

That sounds like something you should catch during testing

I've been writing code since 1970 (when the world was "young and uncomplicated" ), but I never dealt with real-time, or near-real-time handling code which, I suspect, Schiparelli must use, and imposes a lot of constraints on code, including path-length (the time available for a given algorithm to execute).

I red somewhere that it has been mathematically proved that, except for simple cases, it cannot be demonstrated that a program is 100% correct. So, given one has to live with errors, what can be done to minimize them? Software building, coding methodologies can be used. "Proven" code can be reused - as long as the context of the proof remains valid for the case at hand and people are aware of it. And, of course, testing. A lot of testing. Automated testing can catch some errors, and test cases are specifically created. Can one foresee everything? Every possible combination of inputs? Some errors are caught by sheer luck, others may remain hidden for a long time, until a rare set of conditions manifests itself. Every time an error is caught its correction is included in the next release of the software. It works for the relatively forgiving environments of every day life. Space is much, much more harsh.

I'm just offering my own experience, not excusing anyone or anything. Sometimes, getting the kinks out of a program, feels harder than landing on Mars [pun intended].
Fernando

[Habukaz]

According to this audio (transcript) from Deutschlandradio, there was a timeout in the radar altimeter that ultimately made the onboard computer think it was on the ground far too early.

[katodomo]

The transcript link above also links:

the EDM mission overview
a paper on the tests performed with the radar
(both in English)

[JRehling]

As a career software engineer, I doubt very much if either logical correctness or speed of execution are much of an issue here. The logic of the program is almost certainly a small matter compared to the complexity of the dynamic situation with multiple hardware systems operating in a complex and partly uncertain physical world. Even if a program were proven "correct," if that meant correct given that your radar behaved normally and during the actual landing, the radar experienced a glitch, then the correctness of the program could prove irrelevant.

The speed of modern microprocessors probably exceeds the requirements by more than one order of magnitude.

My take, from the outside looking in, is how to make a system that can save the spacecraft if physical events and the performance of sensor hardware go a bit beyond expected limits. If they go radically outside of expected limits, then the software might not be the problem anyway. But if they go moderately beyond normal expectations, then an ideal system might save the spacecraft whereas a good one might not.

I don't know which, if any, of those possibilities apply here. It seems, though, that telemetry took place past the point when things went wrong, so there's a good chance that we'll eventually know the root cause.

[PDP8E]

I would like to know if ESA released a test article out of an airplane at 20K feet to test the system in real-time/real-world....
I would love to see that film...

[mcaplinger]

As a career software engineer, I doubt very much if either logical correctness or speed of execution are much of an issue here.

Logical correctness is always an issue. As an unrelated example, MPL failed because of a lack of proper software debounce in the contact sensor that detected landing. I guess you can call that dynamics, but I'd call it a logical failure. At any rate, however you characterize them, software errors can be stupid and simple or extremely subtle or anywhere in between. If I had to make mistakes, I'd prefer to make subtle ones, but failure is failure and nothing much would surprise me in this case.

[Explorer1]

English language article saying main hunch is a computer glitch; it may have thought it was on the ground already, and the scientific instruments even turned on!

http://www.nature.com/news/computing-glitc...-lander-1.20861

At least it should be easier to fix than a hardware problem (all of which seemed to perform flawlessly).

[siravan]

One of the difficulties of landing on Mars (among others) is the inability to do a full EDL rehearsal on Earth. Software verification and validation is all well and good, but if you cannot test your system in its entirety, all bets are off. We just don't know what happened (yet), it could be a subtle logical error only apparent in Mars environment or a simple error like the big-endian/little-endian mix up that doomed MGS. However, the whole point of Schiaparelli EDM lander was an end-to-end testing of the EDL system, and as such, it was a very successful test.

[tolis]

Whatever the cause of the mishap, I doubt that Exomars will come out of December's ministerial meeting unscathed.
Ministers are politicians; if they simply allocate 300-odd million Euros for something that then
ends up a smoking heap of ruins on Mars, there will be questions asked.
At the very least, some additional oversight will be imposed - perhaps in the form of an external review panel -
to ensure that the EDL system that is to deliver Exomars 2020 will work end-to-end. In the worst-case scenario,
there may be an increase in cost for additional testing and a delay to 2022 or later.

[Art Martin]

Reading that paper about the radar testing is a bit disturbing. From what I read the unit was not tested in actual flight conditions but instead simply by sending it simulated echoes. I understand we cannot recreate Mars in drop tests but we can certainly put a unit in some sort of bouncing vibrating box hanging from a parachute under as tough conditions as we can manage and force it to report back its findings over very varied terrain. Anyone have any idea why that wasn't done if I'm reading things right?

[Explorer1]

$$$, (or in Schiaparelli's case €€€)
Galileo's jammed HGA comes to mind for me, with insufficient testing after the long period in storage. Though to be fair, we are all backseat flying here on this board, and our speculation is just that. Until we get official word from ESA or raw data is released we should give the team the benefit of the doubt. In the meantime, we can wait for the HiRISE imagery of the site.

[mcaplinger]

From what I read the unit was not tested in actual flight conditions but instead simply by sending it simulated echoes.

You don't subject your flight hardware to harsh conditions, you take an identical unit out for "qualification testing". IIRC, in the case of MPL, for example, this involved bolting a radar to an F-16 and diving it at the ground.

There are limits to the fidelity of testing, but simulations are a key element. For landings many thousands of simulated landings are done to build up statistics on the distribution of behavior.

With all that, MPL was doomed by a couple of missing lines of code that would have taken 5 minutes to write. The Genesis SRC crashed because its G-switches were installed backwards. Stupid mistakes happen.

[stevesliva]

Logical correctness is always an issue. As an unrelated example, MPL failed because of a lack of proper software debounce in the contact sensor that detected landing. I guess you can call that dynamics, but I'd call it a logical failure.

Lack of hysteresis in state transitions.... it's sort of both. It's not necessarily on the state machine designer to create hysteresis for a noisy sensor. The senor could instead be improved. But sure, it's easy to do that sort of thing in code-- hold down the power button for 10 seconds to force reboot-- if the need is communicated.