The Schiaparelli Analysis

I like the title. It has that Indian Robert Ludlumish feel to it. Lying in my bed with a bad backache for a few days and looking at only the fan rotating on the roof got me thinking of safety. A friend had pointed out the ExoMars report to me and we got to thinking of making a college level formal methods problem statement of the Schiaparelli failure. The Schiaparelli failure is nicely explained here. The failure was very simple. The parachute opened in the Martian atmosphere. There was a large oscillation which was higher than the expected. They are blaming inadequate simulation for this. Due to the large oscillation the inertial measurement unit, which was providing the angular rates, saturated and indicated so to the system. The radio altimeter height is computed from the measured altitude and a cosine of the attitude. This is to take care of the tilt measured by the radio beam and the actual which is straight line to the ground. The attitude angle is computed by integrating the angular rate (which had saturated). As the angle increased greater than 90 deg the cosine term became negative and this in turn indicated to the system that the altitude was negative. This could only happen on ground, thought the system, and shut the retro rockets thus plummeting towards the Martian soil. It is laid to rest in a small crater, created due to the impact, in Mars with the white parachute fluttering a little away.

There is a small timing element associated with this. If the saturation persists for a certain duration the fault is indicated and the angle is no longer used. Unfortunately this timing duration was a little longer than required. This makes an interesting case for formal analysis. We made a model in Simulink. This was easy. You need an integrator to compute the attitude from the rate, a cosine term, a multiplier to multiply the altitude. A small persistence circuit to count up if the input is saturated. The input saturation is a simple comparator. We set the persistence to a long duration and asked Simulink Design Verifier, our formal engine, please madam can you let us know if the altitude can ever be negative. It thought over this exciting prospect and in two minutes showed that a saturated input for a long duration can make the altitude negative. We made the persistence small and it said “C'est carrément impossible”. (Pardon my google French). This is what happened on the Martian soil.

The example is available for you to look at and experiment here.

But the story does not end here as my backache continued. We used an assertion that ensures altitude cannot be negative. This is after the fact. I have made similar analysis, after the fact, why I have this pain in my back. Could I have avoided this? Now, can we extend this line of thinking to all our safety system? We have a huge database of failures. Can we look at all these assertions and use them as point check in our design? I have done one analysis in an environment control system. I asked the question I am actually in air from the data I have. Can the system looking at a bounded erroneous noisy data tell me that it is on ground? I got a few scenarios where this could happen and these were worth exploring. In case of the earlier example I have written about – can the channel fail? Can the slat be negative anytime?

Can we make a Good Book “of sins” collectively that we could refer to and ask questions during the design phase?