From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,9f0bf354542633fd X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public From: molagnon@ifremer.fr (Michel OLAGNON) Subject: Re: Fortran or Ada? Date: 1998/10/06 Message-ID: <6vcj6f$ak7$1@ys.ifremer.fr>#1/1 X-Deja-AN: 398443180 References: <3618dc33.0@news.passport.ca> Organization: Ifremer Reply-To: molagnon@ifremer.fr Newsgroups: comp.lang.fortran,comp.lang.ada Date: 1998-10-06T00:00:00+00:00 List-Id: In article <3618dc33.0@news.passport.ca>, "Ian St. John" writes: > >Michel OLAGNON wrote in message <6v9s4t$egn$1@ys.ifremer.fr>... >>In article <3617AA49.340A5899@icon.fi>, Niklas Holsti >writes: > >>> >>At the time of writing the software, it might not have been wrong. >>But later on, the launch procedure was changed for Ariane 4, and >>the computation no longer needed. IMHO, not removing unnecessary >>computations that may have side effects IS a "software error". >> >>The designers failed, IMHO, to note that even if hardware might >>be more likely to be wrong than software at time T0, over the whole >>expected service life of the system, it was software that had the highest >>probability to end up wrong. >> > > >IMHO, well tested software doesn't fail. But, IMHO, such well tested software doesn't exist. > Hardware does. At least, in the >sense of random errors. Software can have systematic errors, or design >limitations. Random errors and unexpected data indicate hardware problems. > >The problem in the Ariane 5 case, were that there was no proper review of >whether the software testing was *valid* for Ariane 5. The point, IMHO, is that the software was *useless* for Ariane 5, recognized so by the reviewers, and yet kept because of ``commonality reasons'', which, IMHO again, is a polite way to say ``lack of thought''. Although I could not make it out again clearly from the report, I remember that the launch procedure was changed at some time for Ariane 4, and that the software was also *useless* for it, but was kept for a similar reason: If it ain't broken, why change it ? > This was a >*management* issue, not a technology issue. If the Ariane 4 had reported >such values ( causing overflow ) it *would* have been a hardware error. This is pure speculation. It might have been a software error or a hardware error, no one can tell. But even if it had been a hardware error, my experience is that it would be very likely to have happenned *after* T-5 seconds rather than before (hardware errors happen with vibrations, heat, ...), i.e. at a time when the computations were no longer needed, that is, IMHO, when the software error of making useless computations had already happenned. > This >was taken into the design, and is correct as such. > >The software was *correct* for the mission it was designed for ( Arianne >4 ). You cannot expect software re-use without evaluation of the >interface/inputs. > >Nor can you design software with the viewpoint that it *might* be used in >the first warp drive spaceship. KISS, and stick to reality. > > Michel -- | Michel OLAGNON email : Michel.Olagnon@ifremer.fr| | IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer| | Centre de Brest - B.P. 70 phone : +33-2-9822 4144| | F-29280 PLOUZANE - FRANCE fax : +33-2-9822 4650| | http://www.ifremer.fr/ditigo/molagnon/molagnon.html |