Re: Interresting thread in comp.lang.eiffel

["Ken Garlington" <Ken.Garlington@computer.org>]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8l4u3s$3nvvm$1@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> 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*.