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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f948976d12c7ee33 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-24 11:00:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc03.POSTED!not-for-mail Message-ID: <3EF891AE.20601@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Boeing and Dreamliner References: <3EF5F3F3.6000806@attbi.com> <3EF7EE09.7040505@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc03 1056477625 24.62.164.137 (Tue, 24 Jun 2003 18:00:25 GMT) NNTP-Posting-Date: Tue, 24 Jun 2003 18:00:25 GMT Organization: AT&T Broadband Date: Tue, 24 Jun 2003 18:00:25 GMT Xref: archiver1.google.com comp.lang.ada:39685 Date: 2003-06-24T18:00:25+00:00 List-Id: Hyman Rosen wrote: > The report says that these physical constraints were not described in the > documentation of the SRI software, and therefore the people who attempted > to reuse it had no clue that it would fail outside of such limits. > > Do you think it's appropriate to write software like that and not tell > anyone about it? If the code was in C++ and the failure mode was a > buffer overflow, would you accept that argument, or would you be villifying > that language? Be careful, you are asserting something the report does not say. Remember this report was much more a political document than an engineering document. The requirements document DID include the Ariane 4 related requirements. As anyone who has ever writen control law software should know, the physical moments of the system are required inputs, and you need the physical limitations of the system to get the constraints on the output right. All those were in the SRI specification--for the Ariane 4. Those values were incorrect for the Ariane 5, but no one was PERMITTED to see both the Ariane 5 performance specification and the SRI system specification. NO ONE. Sorry to shout, but that is the key finding of the investigation. It is surrounded by lots of dry language to make it sound like it could happen to anyone, but it was pure and simple politics. The whole discussion of "protecting" the conversion that failed is a red herring. The software people wanted to put in the code, they were overruled because in the Ariane 4, that overflow was physically impossible. It was very reasonable for the software designers to want to put the check in, and it was very reasonable for management, in the context of the overall system, to decide that the default action was correct. If the software engineers or project management had access to the Ariane 5 specifications, the decision would have been different.