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: fac41,ade50c51fbe16698 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,ade50c51fbe16698 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,ade50c51fbe16698 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,ade50c51fbe16698 X-Google-Attributes: gid1108a1,public From: Ken Garlington Subject: Re: *LONG* DRAFT - Critique of "The lessons of Ariane" Date: 1997/07/31 Message-ID: <33E09D9E.62FD@flash.net>#1/1 X-Deja-AN: 261219327 References: <33D274B0.24D4@flash.net> <33DAA372.5C1CAADD@deltanet.com> Reply-To: kennieg@flash.net Organization: Flashnet Communications, http://www.flash.net Newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object,comp.software-eng Date: 1997-07-31T00:00:00+00:00 List-Id: Phlip C Plumlee wrote: > > My essay is the only one I have read so far that ignores DBC and testing > issues. It proposes a much simpler software design goal that might have > prevented the crash and made DBC a moot point. Please take the time to > read it, and you'll see what I mean. > > -- Phlip > ====== http://users.deltanet.com/~tegan/home.html ====== Here's why the typecast occured: Inside the IRS, many of the calculations need to be done at a fairly high precision. Lower precision calculations cause the "drift" rate (the rate at which the IRS measurements start to disagree with the "real" system state) to be unacceptably large. However, some of the users (and Flight Controls is typically in this group) don't need all of that precision. So, the high-precision floating point value is converted to a fixed-point value for transmission purposes. Why not just send the extra precision as a floating-point value anyway? There are several potential reasons; here are a few common ones... 1. Floating-point formats vary between processor types. For example, the MIL-STD-1750 processor (very popular for spaceborne operations, because of its ability to withstand adverse effects from solar radiation) does not use the IEEE format popular with other types of processors. Converting between the two formats is time-consuming and error-prone. The only real problem with integer formats is little-endian-ness. 2. Certain devices (microsequencers, digital-to-analog converters) don't support ANY type of floating-point format. In these cases, you have to comply with the interface to these devices. (Your note about "We are not talking about 4-bit Zilog chips here" is interesting, because in fact we still have operational systems using 4-bit and 8-bit Zilogs! Generally, high-speed CPUs are different to use in airborne control systems due to power utilization, thermal properties, board space, weight requirements, cost, rad-hardness, and design maturity.) 3. For busses organized around 16-word message groups (such as the MIL-STD-1553), there can be a problem sending values that don't fit in a single word. Some hardware devices that deal with these protocols can permit the software to read one word that was sent in the current message block, and another word that was sent in the previous message block. If this were to happen in the middle of a floating-point value, then the value would be invalid. There are several ways to avoid this, but keeping values limited to a single word helps. Usually, most of the typecasting in these systems is at the I/O boundary, to match the interface of some other piece of equipment. Scaling is a common requirement for that interface. Believe me, no one does scaling for the fun of it! However, there are ways to avoid the potential for an exception, such as saturation arithmetic. Unfortunately, without explicit hardware support, saturation arithmetic can add time. When a large amount of I/O is being processed, this time can be significant. So, it is not unusual to do what the Ariane 5 team did: analyze the system to try to apply protection only where needed. Unfortunately, their analysis was unable to take into account the future reuse, and the system was not re-analyzed (or re-tested!) for the new environment.