Originally Posted by Chris Scott
Originally Posted by roullishollandais
What is still unknown is the altitude read on the altimeter on the cockpit
That is correct, strictly speaking, for two reasons:
(1) there is no video of the cockpit altimeters;
(2) we only have the testimony of the pilots that they had set their altimeter sub-scale settings to the transmitted QFE of 984.
However, as you know, it is a simple process to convert the DFDR readings of pressure altitude ("FINF") to the reading of an altimeter set to 984 hPa, simply by subtracting 808 ft.k
For those who have not already done that, here are the readings at one-second intervals,
starting at TGEN 310 (t -24), and finishing at TGEN 334 (t -0):
126, 115, 111, 104, 101, 89, 85, 75, 70, 69, 68, 61, 60, 60, 60, 54, 54, 56, 53, 51, 52, 55, 56, 60, 56.
As I have stated in an earlier post, it appears that the a/c levelled off at 61 ft on the QFE at about t -13, gently lost indicated height from about t -10, and then recovered most of it by t -1. It is likely, however, that the accuracy of the readings available to the crew would have suffered from increasing position-error in the last seconds, because of the high AoA. Also, the static ports are between the cockpit and the CG, so the increasing pitch-attitude means the CG is increasingly lower than the static ports (whereas the pilot eye -height is increasingly higher).
I know all that Chris Scott ! I am able to do substractions... but please accept that we don't know how the pressure (total and static) are 'handled' by the software to appear as a graduated scale on the PFD on the glass cockpit.
AEROSPATIALE/AIRBUS INDUSTRY chosed to keep the A320 and next types software secret/private/hiden.
Not a post from Dozy Wanabee assessing that option as legitim, not a post from Iself assessing the opposite option that responsibility of the pilots need they may have access to ALL algorithms used on the aircraft.
Dozy thought it was in the sense of Open Source Software, free of copyright ; no, it is with protected copyright, as you may protect your rights when you are an author of published text or music that you would not hide !!!
What is different with digital design has been well pointed by the JACQUES-LOUIS LIONS report after the ARIANESPACE rocket ARIANE 501 crash. That crash and that report came much later than HABSHEIM, eight years later, but just before the HABSHEIM trial.
Since the beginning of the Airbus project Aérospatiale was growing on a paranoid way of writing software (ie the A320 simulator with the 'locked software' used to train the AF pilots) and some typical method failures were done by that community .
These many many method failures have been studied with a great accuracy (and diplomacy) in the report but read between the lines as a software professional I was in a highly challenging science ' the conclusions were just terrifying, and some sentences are absolute rules we just NEVER can jump over after that référence report.
Here is the link to the english traduction of the 12 pages report, followed by the most important sentences that no line of code may ignore.
Owain G already said me that Aérospatiale teams in the both projects were not the same, but from what I know from that history of software methods, both were involved in similar software design ... temerity. That temerity is a natural result of the fact that human brain does not work so logicaly as it seems, engineers -happily- incluses. They are many ways to do the altimeter figures and scale wrong via hiden software... Alas
ARIANE 5 Failure - Full Report
the Board wishes to point out that software is an expression of a highly detailed design and does not fail in the same sense as a mechanical system. Furthermore software is flexible and expressive and thus encourages highly demanding requirements, which in turn lead to complex implementations which are difficult to assess.
An underlying theme in the development of Ariane 5 is the bias towards the mitigation of random failure. The supplier of the SRI was only following the specification given to it, which stipulated that in the event of any detected exception the processor was to be stopped. The exception which occurred was not due to random failure but a design error. The exception was detected, but inappropriately handled because the view had been taken that software should be considered correct until it is shown to be at fault. The Board has reason to believe that this view is also accepted in other areas of Ariane 5 software design. The Board is in favour of the opposite view, that software should be assumed to be faulty until applying the currently accepted best practice methods can demonstrate that it is correct.