Re: Ada and Automotive Industry

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <1996Nov6.210957.3070@ole.cdac.com> James Thiele <james@cdac.com> writes:

  > When I did Ada work at Boeing, I found a quote calling
  > Ada "PASCAL for lawyers."  The LRM for Ada 83 was a huge,
  > dense document full of legalese.

  > The language itself was hardly consistent.  Quick, why is
  >     for i in -1..1 -- illegal in Ada 83?

   Because the call to "-" is ambiguous.  The only reason this was a
surprise is that Ada 83 had a special rule to resolve the ambiguity
and choose a type for i in the "most common" cases.  But this didn't
fit that mold, since users can redefine "-".  However, if you write:

        for I in Integer range -1..1 loop...

   It is legal and compiles fine.  (But you may have wanted some other
type...that's why you got the error.)

   In Ada 95, this rule has been extended (see RM 95 3.6(18)) to cover
this case.  (But it may surprise you that the '-' you get is for
_root_integer_ not Integer.)

  > In Ada 83 you can't schedule a periodic event reliably -- no Ada
  > task was guaranteed to run at the time requested.  Everyone I knew
  > who used Ada for avionics in the 80s wrote their own scheduler.

   A HUGE amount of wasted effort because people couldn't be bothered
to read the reference manual.  What the Ada 83 RM said, and pretty
plainly at that, was that a critical task would run exactly (within
the limits of accuracy of the physical clock, etc.) when scheduled,
unless there was an equal or higher priority task using every
available processor.  There was even an AI, published as a
ramification, titled "Preemptive scheduling is required" (AI-32).
Can it get any clearer?  

   Now true, that really does mean that the task won't run when you
requested under certain cirumstances, but those cirumstances are
either that you requested that some other task take priority, or some
other outside event, such as a power failure, has resulted in NO
processors being available.

   Did any of those homebrew hand-written schedulers find a way to
avoid either of those limits?  My experience was that those who
complained were really saying that Ada required them to pay attention
to potential situations they would rather ignore--the maximum delay is
the sum of the delays that all higher priority tasks can cause.  This
is what rate-monotonic analysis is all about.  Often it is possible to
guarentee that that all deadlines are met.  However, you often have to
modify the code in unexpected ways to get that guarentee.  My
experience with both cyclic and preemptive schedulers is that unless
you do the analysis you are fooling yourself and often putting other
lives at risk.

   Sorry, hot button.  But many years ago I asked a question in the
context of a flight simulator.  A task dealing with incoming missles
was in one of the first slots, and allowed to overrun.  What happens
if the next cycle begins while the task is still running?  We looked
at how the actual flight software--in assembler--dealt with the
situation--the answer was that not only did the flight and gunnery
controls lock, but even the ejection seat* couldn't be activated if
there were too many threats detected.  Oops!  Fortuanately it was
fixed well before the plane saw combat.

   *Well, not really, but effectively.  The interlock occured because
you don't want to blast the pilot into the ground.  There was a
timeout on the computer request, but it was a standard 1553 bus
request timeout, which was a little slow in this situation.  Of
course, the seat would fire immediately (if activated) if the computer
was down, but the computer was just, well, busy.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...