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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public From: WhiteR@CRPL.Cedar-Rapids.lib.IA.US (Robert S. White) Subject: Re: Ariane 5 failure - latest S/W tech vs. cold hard facts Date: 1996/10/06 Message-ID: <537ggl$mc8@flood.weeg.uiowa.edu>#1/1 X-Deja-AN: 187875347 references: <96100112290401@psavax.pwfl.com> <32531A6F.6EDB@dynamite.com.au> <3252B46C.5E9D@lmtas.lmco.com> <531mdv$tfm@flood.weeg.uiowa.edu> content-type: Text/Plain; charset=US-ASCII organization: self (but I work for a big one) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-10-06T00:00:00+00:00 List-Id: In article , 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!