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.