Re: Ariane 5 failure - latest S/W tech vs. cold hard facts

[WhiteR@CRPL.Cedar-Rapids.lib.IA.US (Robert S. White)]

In article <dewar.844517570@schonberg>, dewar@schonberg.cs.nyu.edu says...

>There are certainly cases where careful consideration of these three factors
>still results in a decision to use less hardware and more complex software,
>but I think we have all seen cases where such decisions were made, and n
>in retrospect turned out to be huge mistakes.

  In business when making hard decisions about embedded systems products, 
such studies are almost always made.  One factor now causing a lot of study 
and implementation of "complex software" are efforts to reduce procedure call 
overhead and virtual dispatching for object oriented high level languages 
that might be used for embedded products.  The extra thruput and memory 
required does end up using more memory chips and faster (more power 
hungary) processors.  This is a major problem when power consumption, size and 
cost requirements are taken into consideration.  Engineering has to look at 
the entire picture.

  We want to use the latest software technology that results in the cleanest 
most easy to maintain design.  Sometimes it takes a while to hone the tools 
that use this new technology till they are ready for prime time in mission 
critical software that has to operate in an enviroment with a lot of other 
constraints.  Ada 83 in 1984 had a lot of problems in implementations that 
were mostly solved by 1991.  Ada 95 (with advantage taken of its new object 
oriented features) and Java bytecode virtual machines also need a significant 
amount of effort expended till they are ready for these more constrained 
embedded products.  Not to say that it won't happen, just that they often 
don't pass the rigorous cost/feature analysis tradeoffs at this date for 
immediate product implementation.

  And we NEVER want to make a mistake for flight critical software :-<
or have a critical task not able to run to completion within its deadlines.
We need that processor thruput reserve to have a safety margin for rate 
monotonic tasks.  

  I agreed with most everything Ken Garlington and other Lockheed Martin 
engineers have posted in this thread on this same subject.  Their statements 
ring  with my industry experience for the last 21 years.
___________________________________________________________________________
Robert S. White                    -- an embedded systems software engineer
WhiteR@CRPL.Cedar-Rapids.lib.IA.US -- It's long, but I pay for it!