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.7 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00,
	INVALID_MSGID,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,74b55538385b7366
X-Google-Attributes: gid103376,public
From: William Dale <william.dale.jr@lmco.com>
Subject: Re: Ada safety road Was: Which is right ...
Date: 1999/06/16
Message-ID: <37682F64.59E2@lmco.com>#1/1
X-Deja-AN: 490504881
Content-Transfer-Encoding: 7bit
References: <928083159.436.79@news.remarQ.com>
 <m33e0el4vr.fsf@deneb.cygnus.stuttgart.netsurf.de>
 <928174549.336.98@news.remarQ.com> <7iuqkc$ln6$1@nnrp1.deja.com>
 <928529202.956.79@news.remarQ.com> <928569312.951.42@news.remarQ.com>
 <7jb1l9$694$1@nnrp1.deja.com> <928703068.617.98@news.remarQ.com>
 <375F6F0B.AD735B5B@praxis-cs.co.uk> <7jo1d2$kno$1@pegasus.csx.cam.ac.uk>
 <929128919.557.95@news.remarQ.com> <7jsdkf$v3p$1@nnrp1.deja.com>
 <489533776wnr@diphi.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Organization: LMMS, O/EA-10, (408)743-6812
Mime-Version: 1.0
Reply-To: n2rhv@nospam.amsat.org
Newsgroups: comp.lang.ada
Date: 1999-06-16T00:00:00+00:00
List-Id: <comp.lang.ada>

JP Thornley wrote:
> 
> In article: <7jsdkf$v3p$1@nnrp1.deja.com>  Robert Dewar
> <robert_dewar@my-deja.com> writes:
> 
> (with reference to the HRG Guidance)
> 
> > it is VERY specifically aimed at safety critical programming
> > in Ada
> 
> Definitely not so - and if this becomes the accepted idea then a number
> of programmers are likely to ignore a very useful document.
> (Particularly if they take Robert's other comments to mean that
> safety-critical programming is an arcane art with little connection to
> the 'real-world').
> 
> The Guide is _aimed at_ producers of high integrity software, where the
> software supplier is (usually) required to demonstrate the integrity of
> the software to a third party (who may be a certification authority or,
> perhaps, a knowledgeable customer).
> 
> It is _useful to_ anyone who wants to make consistent use of one or more
> of the verification methods referenced in the Guide as it helps them to
> avoid language features that are difficult to verify by the chosen
> techniques. (All of the usual techniques are included in the Guide.)
> 

I hope the document covers the system trade-offs of going through
such rigorous and costly certifications when a simple hardware addition 
would make the system safe.  

Too often the software effort is forced to shoulder the entire 
burden of system safety.  Gutting language features to make software 
certifiable is often coupled with irrational fear of new features 
and technology. 

Many times it still does not make for a "safe" system. When safety 
certified applications sit on top of untested operating systems 
and amidst other COTS applications disaster is possible, 
maybe probible. 

[snip]
-- 

"The difference between hardware and software is that the more you play
with hardware, the more likely you are to break it, but the more you
play with software the more likely you are to FIX it."

Bill Dale 
LMMS
mailto:william.dale.jr@lmco.com
mailto:N2RHV@amsat.org