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-26 12:12:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc53.POSTED!not-for-mail Message-ID: <3EFB4575.8050008@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: rwcrnsc53 1056654728 24.62.164.137 (Thu, 26 Jun 2003 19:12:08 GMT) NNTP-Posting-Date: Thu, 26 Jun 2003 19:12:08 GMT Organization: AT&T Broadband Date: Thu, 26 Jun 2003 19:12:08 GMT Xref: archiver1.google.com comp.lang.ada:39785 Date: 2003-06-26T19:12:08+00:00 List-Id: Alexander Kopilovitch wrote: > I read this report yesterday, and now I'd like to make several comments. Good. >>... it doesn't take a >>genius to tell you what that ten second period of "pressure surges" in >>the flight control hydraulics was. But of course the politics of the >>situation kept the fact that oscillations were building up in the stack > >>from being an obvious part of the official report--and from being left > >>out of it: > "These nozzle deflections were commanded by the On-Board Computer (OBC) > software on the basis of data transmitted by the active Inertial Reference > System (SRI 2). Part of these data at that time did not contain proper flight > data, but showed a diagnostic bit pattern of the computer of the SRI 2, which > was interpreted as flight data." > > "The reason why the active SRI 2 did not send correct attitude data was that > the unit had declared a failure due to a software exception." This happened at around 38 seconds. The "hunting" of the flight guidance system was prior to that. Ten Hertz (cycles per second) is almost certainly not due to any of the inertial moments of the system but a multiple of the SRI clock. > First, there was protocol error, so the "bugs" weren't localized in SRI. > Second, possibly there were other inconsistensies in SRI software. and those > additional inconsistencies might influence that "diagnostic pattern". which > was transmitted to OBC. Correct, the OBC did no validation or sanity checks on the information sent from the SRI to the engine controls. Nothing wrong with that--if you understand that the SRIs are category 1 systems. (Failure will cause system failure.) I didn't like at all the idea of sending diagnostic data over the bus from SRI to OBC, but it can be justified by this view that failure of the SRIs leads to failure of the system, and you want to get as much diagnostic information as possible before the telemetry fails as the Ariane is blown up. But the other systemic mistake that I an nowhere near comfortable with was the implicit idea that that the SRI software must be correct. I would prefer in the first Ariane 5 launched to allow for the possibility that the flight dynamics model doesn't perfectly match the actual system. This would argue for a diagnostic data stream that shows the deviations between the model and the system, while still continuing the "best effort" to fly the Ariane. In other words, the SRI should send both engine deflection commands and diagonstic data to the OBC. > They simply put the software written for previous model -- > Ariane 4 (where it worked well) -- to new Ariane 5, and did not bother > themselves with testing it on the new rocket before the launch. So, > when the Ariane 4 software appeared (in the flight) incompatible with > new Ariane 5 they became very surprised -- and blamed the software. Before the Ariane 501 disaster, the shorthand for this problem with reuse was that an M2 tank is not an M1 tank. In other words, you have to repeat the requirements definition part of the effort. Even if you can, in the end, reuse the software without change. Of course, now we just say Ariane 5.