It would also be interesting to know how the financing of the different components of Exomars
was handled within the overall budget for the mission. For instance, did TGO and Schiaparelli
have their own "ringfenced" budgets or was it possible to raid the budget of one to pay
for the other?

Shouldn't the title of the topic be changed to "...attempted Schiaparelli landing" seeing as it was not successful ?

The word "landing" doesn't imply success. See exchange below.

How to test systems that operate in the uncertain realm of fluid dynamics is an interesting proposition.

The Wright brothers tried to use an analytical approach to design propellers for an airplane, and realized that they couldn't do it. So, they started off with the design of ship propellers, which were a proven technology, and adjusted as best they could for the different parameters of air vs. water. It worked.

I see that the Schiaparelli parachute system evolved from the Huygens system. That also involves very different parameters, though certainly not as different as the Wright brothers' case.

Parachutes have worked for entry on Venus, Earth, Mars, Jupiter, and Titan. It would seem like there's not much left to prove there.

Supersonic Mars parachutes are complicated. Viking proved the original ring-sail design, but this design doesn't scale very well. MSL development was all done in non-marslike conditions (higher pressure, lower velocity) in the big wind tunnel at NASA Ames and resulted in some failures which were only fixed late in testing. LDSD did flight-like testing at great expense for a larger parachute and despite lots of expert consulting (see https://www.nasa.gov/jpl/ldsd/the-supreme-c...rachute-experts ) both flights' chutes failed completely. One of the reasons that NASA is participating in SpaceX's Mars demo mission is because larger parachutes are not looking feasible after LDSD.

That said, the EDL demonstrator should have been well within the Viking/Pathfinder/MER experience base and should not have required additional flight testing IMHO. We'll just have to wait for the report to see.

I misspoke. While ring-sails were tested on Viking (and one was initially proposed for MSL) all US Mars missions have used disc-band-gap parachutes. See https://solarsystem.nasa.gov/docs/p491.pdf

The LDSD failures were of ring-sails.

Looks like it was the IMU being saturated, confusing the computer.

http://www.esa.int/Our_Activities/Space_Sc..._makes_progress

http://www.bbc.com/news/science-environment-38082636

This BBC report says the IMU error was "propagated forward when the data from the doppler radar kicked in," whatever that means. [I can see that instrument rotational velocity might be subtracted from Doppler velocity to get spacecraft velocity, but I don't see why this would figure into calculating altitude, which I assume would be determined by the delay time of a reflected radar pulse.]

If it was used to calculate altitude – and I can't say if or why – the how might have involved the assumption that a rocking/rotating spacecraft would show changes in the measured distance/velocity with respect to the ground as the radar beam pointed at various angles deviating significantly from the nadir.

When I personally leapt from an airplane and hung by parachute, I was surprised by how nearly stationary I felt at the top of my descent, because my horizontal and vertical motion was so small compared to the distance from the ground. It didn't look like I was descending or moving laterally. I promise you, the final few seconds of my descent did not seem that way at all.

I wasn't rocking or rotating – much – but when a spacecraft is, you can't count on the radar beam being pointed right at the nadir, and then the measurement of distance to the end of the beam will exceed the actual altitude. So I guess that an algorithm designed to derive the true altitude of a rocking, rotating, and/or decelerating spacecraft from those changing measurements is necessary until the time when the radar's direction can be guaranteed.

ESA has told us that they have simulated the fault and it matches what happened. OK.... but...
The problem is that the 'glitch' makes as much sense as the Italian Space Agency's story a few days ago.
And there is a very good reason for that. We have no insight into the EDL software design used by the ESA designers and programmers
As an RTOS programmer for decades (VxWorks, also used by MER, Pathfinder, Odyssey, etc) , sanity checks are part of the landscape.
For example: when the craft is at an altitude of 4 Km and in the next second it thinks it is 'on the ground', one of the background sanity checks would have said 'we just accelerated to 14 Million KM/hr -- ignore the readings, wait until they get back in 'range', and do it again. If the controller is taking 50 readings per second, you might say something like: check the next 100 readings to see if they come into range.... ELSE do something different - like maybe rely on a nominal 'EDL Timeline' to do things in sequence for a while, if you are temporarily instrument blind.
Controlling machinery in real-time is very tricky but it also a 'well-plowed' field of study. Controlling a speeding craft during a Mars EDL has to be one of the most demanding situations (you travel very far in a few seconds) and so it requires a robust, well-designed, autonomous controller operating in Real Time
I believe the IMU used on Schiaparelli is the Northrop Grumman LN-200S (S for space) -- see the link below for a PDF of specs.
It looks pretty hard to get this device into delta-theta saturation (laser-gyros) and/or delta-v saturation (accelerometers)
I look forward to reading the final ESA report in early 2017

LN-200S IMU Specs

AFAIK, typical flight control software doesn't use explicit validity checks but relies on Kalman filter weights to merge data from different sources. There is usually a big discontinuity at radar lockup as the IMU propagated altitude gets replaced. The story isn't making much sense yet but it seems like the filter was confused at this point, which seems like a pretty fundamental mistake as this is a known critical time.

So if the radar beam is pointing off-nadir by an angle of theta, the actual altitude y could be calculated as y = x cos(theta), where x is the altimeter reading?
In that case, if theta exceeds 90 degrees, cos(theta) and hence y would be negative. Hmm. Could it be that simple?

Unlikely, it's a multiple beam Doppler radar which should be able to estimate attitude on its own.

Yes, three beams at the vertices of an equilateral triangle should be able to uniquely determine altitude, assuming a spheric surface below, reliable sensors, and no serious latencies in the analog-digital read. If any of those assumptions is not met, an algorithm might return nonsensical calculations of altitude, in which case, some sanity checking ought to exist – changes in altitude and velocity have to be continuous and considerably bound. Meridiani, as we've seen, is pretty flat, so the spheric assumption should work extremely well. A negative altitude calculation could have resulted from an inaccurate sensor reading or significant rotation between the time that discrete measurements were made.

I think the murky picture will finally emerge when the early 2017 report comes out.
Apparently, Schiaparelli transmitted 600 Mega-Bytes of data back to the orbiter.
That's a lot of engineering and science data!

Esa Twitter link:

600 Mb Data Returned

Maybe they can release some (all) of it in the future.

Ariane V initial launch? It would have failed your sanity checks. Nonetheless he software commanded a wild course correction. I just don't know how many layers of "wait and see" you're supposed to put in there though. Ariane V may well have had plenty of "wait and see" but not amount of it was going to undo the overflow. You can reject a certain amount of garbage data, but eventually that might be all you have left.

There is a limit of the number of such sanity checks you can explicitly implement in a control system. You get a huge number of rules because you need to consider different combinations of inputs. Instead, since the time of Apollo, most (all?) s/c control systems have used Kalman filter or one of its descendants. The basic idea is that each piece of input comes with a measure of its accuracy that affects how it is incorporated into a state vector. It seems that for Schiaparelli, the control system assigned a higher accuracy to IMU inputs than to the radar readings and therefore rejects radar inputs in favor of the wrong state vector generated from IMU.

ESA has just announced that the Schiaparelli landing investigation has been completed. A report summary can be downloaded from this page.

Here is an excerpt:

Fernando

Wow. Basically there were several issues, but there was one parameter that was supposed to be 15 msec and was set to some unstated larger value and nobody caught it.

That's gotta hurt.

It always does. Just like Mars Observer and the metric mixup, or Galileo and the HGA, or Genesis accelerators being upside down, or (for ESA) the Huygens Channel A. Nothing to do but live with it and learn from mistakes.

That's Mars Climate Orbiter. The Mars Observer problem was a lot more subtle (as was the Galileo problem.)

Oops, yes. Looking at the report, I note that they used the observations Oppy took of its heat shield during their analysis. Good use of ground truth and previous experience to build on for the future.
Also from page 18, for something this thread discussed:

As mentioned upstream in the thread, a few overriding sanity checks can and should be layered on top of the real-time Kalman NAV computer in an EXEC manner.
(underlines are mine)

(ESA) Recommendation 05 – Robust and reliable sanity checks shall be implemented in the on-board S/W to
increase the robustness of the design, which could be, but not limited to :
- Check on attitude
- Check on altitude sign (altitude cannot be negative).
- Check on vertical acceleration during terminal descent and landing (cannot be higher than gravity).
- Check altitude magnitude change (it cannot change from 3.7 Km to a negative value in one second).
- Check wrt pre-flight timeline (altitude or acceleration profile vs time) to check consistency of measurements

Let's get this done and see a working 2020 lander on the surface of Mars!

it turns out Schiaparelli finally did provide a little bit of science data:
ExoMars 2016 Schiaparelli Module Trajectory and Atmospheric Profiles Reconstruction (pdf freely downloadable)

The PDF led me to this page which I will have to investigate a lot!

From PDF:

Summary:
14:42:22 Atmosphere entry (T0)
14:45:23 Parachute opening (T1=T0+181)
14:46:04 Heatshield (T2=T0+222 , T1+41)
14:46:46 Parachute/backshield released (T3=T0+263 , T2+41)
14:46:50 Thrusters on (T4=T0+267, T3+4)
14:46:53 Thrusters off, freefall from 2.76 km altitude(T5=T0+270 , T4+3)
14:46:58: end of data (?)

The Schiaparelli parachute has shifted a bit in the wind between 2016 and 2019:

Click to view attachment

I will try to update this with the older image ID and date later. The images have slightly different orientations.

Phil

Here's the full set of available images of the Schiaparelli parachute. The first 3 are all in late 2016 and show a quick change to the parachute after landing. The last one is from this March and shows a bit more movement, or perhaps parts being covered with dust.

Phil

Click to view attachment

I think all future flight logic systems can WLOG rule out the possibility that a descending lander is below the surface.

*without loss of generality