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.6 required=5.0 tests=BAYES_00,FROM_WORDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/19 Message-ID: X-Deja-AN: 648411869 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <8k5alv$1oogm$1@ID-9852.news.cis.dfn.de> <8kl25k$2q7k0$1@ID-9852.news.cis.dfn.de> <8kt18p$36aor$1@ID-9852.news.cis.dfn.de> <8l4u3s$3nvvm$1@ID-9852.news.cis.dfn.de> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 964049932 216.215.73.136 (Wed, 19 Jul 2000 18:38:52 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Wed, 19 Jul 2000 18:38:52 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-19T00:00:00+00:00 List-Id: "Joachim Durchholz" wrote in message news:8l4u3s$3nvvm$1@ID-9852.news.cis.dfn.de... > Ken Garlington wrote: > > See, you're already in trouble. Horizonal bias is not a "physical > > parameter", in this case. It's an _output_ of the SRI, derived from > > physical measurements of the environment, not an input. > > Arrrgh... do you *ever* read what I say elsewhere, or do I have to > reiterate the *full* reasoning whenever I deal with you? > > I assume that the horizontal bias is a physical property, measured by > the IRS and returned by the IRS. Arrrgh... again, you assume wrong. Horizonal bias is not a "physical property", in this case. It's an _output_ of the SRI, *derived* from physical measurements of the environment, not an input. It's related to the inputs measured by the IRS (as are most outputs), but it's not a "physical property" like (for example) roll rate. > In that case, the IRS has a contract that relates physical bias and > measured bias. (If the IRS has just paper specifications, it's easy > enough to translate them to contracts.) Unfortunately, it's not necessarily a simple relationship between the system inputs and outputs such as horizonal bias, so it's unlikely that a simple contract could be written in the form you want. It's usually a complex series of calculations, lookups to correction tables, etc. More to the point, the *abstract* relationship between the inputs and the output (horizontal bias) *prior to scaling* was not violated in the Ariane 5. The relationship between the values achievable for horizontal bias (produced by the abstract relationship between inputs and outputs), and those that could be accepted for conversion (scaling) prior to transmission on the output communications bus, *was* violated. > The general flight control software somewhere, in some way, retrieves > the measured bias from the IRS. Or the IRS spontaneously sends its data, > then there's an interrupt routine that will receive that data. In any > case, there is some software that uses this data; and the programmer of > that line will very likely see the contract. Actually, it's reasonably unlikely that the OBC (general flight control software) programmer would see the IRS source code. Of the various flight control programs I'm familiar with (F-16, F-111, A-12, F-22, JSF, T-50), I've never seen a FLCS programmer ask for IRS source code. I have looked at IRS (and FLCS) source code as part of other activities (IIV&V, etc.) but never as part of software programming. What the OBC programmer would likely have been given is an Interface Control Document (a.k.a. Interface Requirements Specification, Interface Design Document, etc.). This document would describe the messages on the communications bus -- the senders, receivers, etc. For the IRS, he would likely have been given a description that says (roughly): "The horizontal bias parameter is a scaled value in the range -32768 .. 32767 (one bus word). -32768 is mapped to -5.0, and 32767 is mapped to 3.0." He would then write a routine to take the integer value and "un-scale" it appropriately. As mentioned previously, this definition guarantees that you will never get an out-of-range value (say, 3.5), since there's no way to put a value greater than 32767 (or less than -32768) in a 16-bit quantity. However, this approach also makes it useless to do traditional range-based contracts. However, let's say for the sake of argument that the OBC programmer looked at the IRS source code. What would he have seen in the output routine? A contract that would have said: "require horizontal_bias_prescaled >= -5.0 and horizontal_bias_prescaled <= 3.0". He would have said, "Yep, that's what my interface document says: the value will represent the range -5.0 .. 3.0, before it's scaled." The fact that the IRS -- *prior* to the output routine -- was capable of generating a value outside the range would probably be overlooked by the OBC programmer, since he doesn't have enough of a background to know how the IRS computes horizontal bias. > He will also enter this > contract into the contract of the software that he, in turn, is writing, > so the contract will percolate up the software layers, until it is seen > by somebody at a high level who *also* knows the Ariane-5 trajectories. Well, we'll have to agree to disagree on this point. I've given specific examples in my paper and elsewhere as to why this is untrue -- the aeronautical engineers and managers at the prime would likely neither want to examine a vendor's source code, nor have the resources to do so if they did want to. I've never heard a counter-argument advanced for why your assumption should be considered valid for a project like Ariane 5. > *If* that high-level programmer looks at the details of these contracts, > *then* the problem would have been detected. You seem to believe that these projects are staffed homogenously by programmers. I obviously can't convince you that there is a world outside of software engineering on projects such as Ariane 5, so we'll just have to agree to disagree on this presumption as well. (Said more explicitly - the guy you describe ain't there.) But let's go with your thesis that he exists. He looks at the IRS side, and sees a contract that maps -3.0 to -32768 and 5.0 to 32767. He looks at the OBC side, and sees a contract that maps -32768 to -3.0 and 32767 to 5.0. What problem has he just detected? I must not be a sufficiently "high-level" (acolyte?) programmer, because it looks OK to me! Again, he would have to have three things to detect the problem by analysis: (1) The actual flight profile (2) An understanding of the (non-trivial) relationship between the profile and a value like horizontal bias (3) An understanding of the (much simpler) relationship between the calculated (floating-point) value for horizontal bias and the value expected by the scaling routine. As you saw when you looked at the YF-22 profile, that #2 is a toughie for someone who's not an expert in the particular domain of interest (inertial measurements). However, if he's an expert, he's probably not also a "high-level programmer" looking at the IRS, OBC, propulsion system... On the other hand, you don't necessarily have to have #2 or #3 (or at least, not a deep understanding of them) if you feed the values from #1 into the actual IRS. At least with respect to detecting gross failures of the type in Ariane 5, *testing* the unit (as opposed to analyzing the unit) can be simpler. I know several projects where these sort of integrated system tests are done successfully without any detailed examination of the source by the test team. In test theory, these are called "black box" tests, and they can be quite powerful, particularly for detecting these sort of integration-class faults. They are particularly effective when supplemented by "white-box" analyses and tests that look for internal *inconsistencies*.