JOB:Sr. SW Engineers Wanted-Fortune 500 Co

JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Tracy Goembel]

Bring your expertise to this globally renowned, Fortune 500 medical
device company and start enjoying your work.  This company is constantly
reinventing itself and the products produced to become the world leader
of the medical device industry.

This company develops cardiovascular products.  This life affirming work
is performed by extremely talented individuals committed to improving
other�s lives.  This is not another job-this is a chance for you to
making a difference.  Every year, people who have received implants,
come to express their sincere appreciation that they are still alive
today because of the products developed.

We are searching for Software Engineers to develop in an NT
environment.  We are looking for individuals who can contribute their
expertise to the team and work independently as well.  We are looking
for strong leaders who have real-time, embedded systems experience along
with full life cycle development and C language experience.  Qualified
individuals have 2+ years of experience and at least a Bachelors
degree.  Due to the mission critical products developed, candidates MUST
have heavy process experience.  You do not have to have medical
experience.  Our teams consist of engineers from all industries who are
putting their expertise to work.

One unique aspect of the company is the constant challenges you will
face and the unending learning potential.  You will have the opportunity
to train in areas outside of your field if interested.  Promotions are
quite common, some even within the first year of employment.

Excellent benefits are offered to you including, profit sharing, full
health and dental, on-site graduate courses and daycare, vacation, and
fitness plans at participating sites.  The company shuts down for over
one week during the holidays and you are paid for the time spent at home
with the family and is not considered vacation time.  The bonus offered
to all employees is exceptional.

Contact me today to learn more about these exciting opportunities.  All
inquiries will remain confidential.


Mark Cline
Bond Technologies
7400 Metro Blvd., #100
Minneapolis, MN  55435
Phone (612) 841-9501
Fax (612) 841-9509
mcline@bondtechnologies.com





reuse,software,development, developer, sw, hardware, hw/sw, embedded,
rtos, realtime, medical devices, biomedical, engineer, research and
development, r&d, object oriented, c/c++, language, program, smalltalk,
nt, windows, life cycle development, test, verification, validation,
v&v, mission critical, sr., senior, jr, junior, associate, minnesota,
st.paul, minneapolis, twin cities, mn

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Mike Silva]

Hyman Rosen <hymie@prolifics.com> writes:
>> Ted Dennison <dennison@telepath.com> writes:
>> >    3. I think I speak for most (if not everyone) here when I say that I
>> > find it appalling that anyone would develop a product like a pacemaker,
>> > on which the life of a human being depends on its continuous reliable
>> > operation, in a language known to be as error-prone as C. This is not
an
>> > opportunity for me to be "improving other's lives". It's an opportunity
>> > for me to screw up and *take* someone's life. No thanks.
>>
>> Good thing the Ariane 5 didn't land on anyone's house.

>OK, I'm being a smartass, but I am making a valid point.
>Having its software written in Ada was not enough to keep
>the Ariane 5 from going off-course and being blown up. In
>the same way, having the software of a pacemaker written
>in C is not enough to force it to blow up.

This is a silly strawman, since nobody (at least, nobody who wants to be
taken seriously) ever makes such extreme claims.  It's all a matter of
increasing the odds, and both the C language and the C culture invite buggy
code (sad to say, I've written my share).  Every C programmer should perform
the eye-opening exercise of determining how many C bugs they encounter would
not have been possible, or would have been quickly spotted, in Ada.  I did,
and the answer was "most!"  I wonder if the C culture doesn't just accept
these language-preventable bugs as a fact of life, as I did for many years,
without realizing how many can be caught by a safer language (and the
culture of safety that will naturally accompany it).

>I would assume
>that pacemaker software undergoes thorough critical-systems
>development and testing regardless of what language it's
>written in.

I think one Ariane investor was overheard saying something similar to
another Ariane investor just before liftoff...

Mike

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

In article <3894A823.92EC75D1@bondtechnologies.com>,
  Tracy Goembel <tgoembel@bondtechnologies.com> wrote:

> This company develops cardiovascular products.  This life affirming
> work is performed by extremely talented individuals committed to
> improving other�s lives.  This is not another job-this is a chance for
> you to making a difference.  Every year, people who have received
> implants, come to express their sincere appreciation that they are
> still alive today because of the products developed.
...
> with full life cycle development and C language experience.  Qualified

OK. I have three major problems with your posting Tracy:

   1. This in an Ada newsgroup, not a C newsgroup. Not only is this
NOT an Ada job, but your company doesn't even recruit for *any* Ada jobs
(according to the blurb at the bottom). If you don't have an Ada job,
you have no business posting anything here.

   2. This exact same posting was put here 2 years ago. It got
roughly the same responses. Why didn't you learn then not to post C
jobs here? (Perhaps it was from a different recruiter then...)

   3. I think I speak for most (if not everyone) here when I say that I
find it appalling that anyone would develop a product like a pacemaker,
on which the life of a human being depends on its continuous reliable
operation, in a language known to be as error-prone as C. This is not an
opportunity for me to be "improving other's lives". It's an opportunity
for me to screw up and *take* someone's life. No thanks.

I'd dearly love to know exactly which "Fortune 500 company" this is.
Rest assured that there is no danger of me going around you and getting
an interview with them. I just want to know whose products to aviod
should I or any of my loved ones ever be in need of a pacemaker.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Mike Silva]

Hyman Rosen wrote in message ...
>Ted Dennison <dennison@telepath.com> writes:
>>    3. I think I speak for most (if not everyone) here when I say that I
>> find it appalling that anyone would develop a product like a pacemaker,
>> on which the life of a human being depends on its continuous reliable
>> operation, in a language known to be as error-prone as C. This is not an
>> opportunity for me to be "improving other's lives". It's an opportunity
>> for me to screw up and *take* someone's life. No thanks.
>
>Good thing the Ariane 5 didn't land on anyone's house.

Good thing the Ariane managers don't make pacemakers (I hope!)

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

Ted Dennison <dennison@telepath.com> writes:
>    3. I think I speak for most (if not everyone) here when I say that I
> find it appalling that anyone would develop a product like a pacemaker,
> on which the life of a human being depends on its continuous reliable
> operation, in a language known to be as error-prone as C. This is not an
> opportunity for me to be "improving other's lives". It's an opportunity
> for me to screw up and *take* someone's life. No thanks.

Good thing the Ariane 5 didn't land on anyone's house.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

Hyman Rosen <hymie@prolifics.com> writes:
> Ted Dennison <dennison@telepath.com> writes:
> >    3. I think I speak for most (if not everyone) here when I say that I
> > find it appalling that anyone would develop a product like a pacemaker,
> > on which the life of a human being depends on its continuous reliable
> > operation, in a language known to be as error-prone as C. This is not an
> > opportunity for me to be "improving other's lives". It's an opportunity
> > for me to screw up and *take* someone's life. No thanks.
> 
> Good thing the Ariane 5 didn't land on anyone's house.

OK, I'm being a smartass, but I am making a valid point.
Having its software written in Ada was not enough to keep
the Ariane 5 from going off-course and being blown up. In
the same way, having the software of a pacemaker written
in C is not enough to force it to blow up. I would assume
that pacemaker software undergoes thorough critical-systems
development and testing regardless of what language it's
written in.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

Gautier <gautier.demontmollin@maths.unine.ch> writes:
> OK, but in Ada, the pacemaker maybe will issue:
> "You've lost! CONSTRAINT_ERROR - Unhandled exception
>  at line 3082. Symbolic stack dump follows".

Nonsense! As we know from the Ariane 5, the error code will be
translated into signals driving the heart, which will then beat
out an error message in Morse code :-)

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Pat Rogers]

"Hyman Rosen" <hymie@prolifics.com> wrote in message
news:t73drc6a1k.fsf@calumny.jyacc.com...
> "Pat Rogers" <progers@NOclasswideSPAM.com> writes:
> > No.  They treated all exceptions as indication of hardware failures
> > because they didn't believe
> > they could happen due to software.  They didn't meaningfully handle
the
> > exception -- they aborted the program!  Since they abused the
software
> > they were reusing (by using it in a different context, in which
> > exceptions were unavoidable) their assumptions were invalid.
>
> When you have proved that something can not happen, you will not then
> add code to handle that event gracefully. After all, that's the entire
> point of software proofs in the first place.

First, the Ariane 5 people did not prove that exceptions could not
happen.  The Ariane 4 team did, but Ariane 5 had a different flight
profile that made the Ariane 4 proofs invalid for the reused software.

You seem to believe that a rigorous, correct proof against something
happening means that it cannot happen.  I don't agree.  For example, all
the analysis that says a certain value can never go out of range --
such that an exception handler is not necessary -- is invalidated by the
stray particle of radiation that toggles a bit in memory.

Just as problematic are the errors in the specifications that the proofs
are built against.  I am not saying that proofs are inappropriate -- far
from it!  But ignoring the possibility of errors in proven components is
a dangerous approach indeed.

> If it turns out that your
> proof is in error, it is exceedingly unlikely that the code will fall
> back to a reasonable behavior.

What's the basis for that assertion?  Certainly if there is no design in
place to handle errors then there will likely be no graceful response!
But that is a (poor) design choice.

IMHO one should design the code to respond to the very real possibility
of exceptions in a meaningful way. (Ariane 5 did not.)   For critical
software, that means having a backup if the situation permits.
Structured exception handlers are one way of invoking the backup.

> Do you see people writing 'if a = 3 and then a = 3' just in case the
> first equality was a fluke?

No, I see* a certain aerospace company experiencing 4 or 5 errors per
year in their flight software. The prove everything rigorously -- the 4
or 5 errors are due to corresponding errors in the specifications.  For
those cases I hope they have some fall-back approach.

*Told to me first-hand by a member of their team.

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Larry Kilgallen]

In article <s9e96d4uer236@corp.supernews.com>, "Pat Rogers" <progers@NOclasswideSPAM.com> writes:

> No.  They treated all exceptions as indication of hardware failures
> because they didn't believe
> they could happen due to software.

And there was a hardware failure -- all of a sudden the rocket reported
behavior well outside the capability of an Ariane 4.  Perhaps the most
likely cause was a warp in the space-time continuum :-) so aborting the
journey of this Ariane 4 is certainly appropriate.

Perhaps Microsoft could show them how to hand out stickers "This software
validated for use on Ariane 5."

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Larry Kilgallen]

In article <Z%Dl4.961$dw3.47427@news.wenet.net>, "Mike Silva" <mjsilva@jps.net> writes:

> Firstly, shortening the development process by catching more errors quicker
> is a Good Thing.  Secondly, I can imagine plenty of scenarios where software
> and/or hardware glitches can be captured, corrected in some manner (even if
> via restart) and logged in a running pacemaker, to be analysed later,
> perhaps resulting in the loading of improved code into the device (I believe
> this is possible -- it certainly should be!)

I doubt the possibility of a mechanism that would load improved code
but decline to load degredated code.  The most that can be said for
the mechanism is that it can load "different" code :-).

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Larry Kilgallen]

In article <t7bt606bro.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> writes:

> But it's exactly that mechanism that led to the Ariane 5 crash. I have
> argued before that *not* catching such errors at runtime might be a
> better approach, because it's possible that such an error would cause
> only slight local effects which would quickly damp out, whereas invoking
> error handling leads to massive global effects.

And some small fraction of automobile collision victims who are not wearing
safety belts are "thrown clear".  Exceptional cases do get more press.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Gautier]

> OK, I'm being a smartass, but I am making a valid point.
> Having its software written in Ada was not enough to keep
> the Ariane 5 from going off-course and being blown up. In
> the same way, having the software of a pacemaker written
> in C is not enough to force it to blow up. I would assume
> that pacemaker software undergoes thorough critical-systems
> development and testing regardless of what language it's
> written in.

OK, but in Ada, the pacemaker maybe will issue:
"You've lost! CONSTRAINT_ERROR - Unhandled exception
 at line 3082. Symbolic stack dump follows".

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

In article <87646g$qal$2@wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
> 
> Hyman Rosen <hymie@prolifics.com> a �crit dans le message :
> t7iu09q36i.fsf@calumny.jyacc.com...
>> Good thing the Ariane 5 didn't land on anyone's house.
> The Ariane5 launch pad is on the east side of south-america, and since
> rockets are always fired eastbound, there was really no risk there...

Spoken like a true non-sailor :-)

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

In article <87646g$qal$2@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> Hyman Rosen <hymie@prolifics.com> a �crit dans le message :
> t7iu09q36i.fsf@calumny.jyacc.com...
> > Good thing the Ariane 5 didn't land on anyone's house.
> The Ariane5 launch pad is on the east side of south-america, and since
> rockets are always fired eastbound, there was really no risk there...

Hoboy, you stepped in it this time. Now you're going to get all sorts of
flames from Falkland Islanders...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Ted Dennison]

In article <t7g0vdq2x0.fsf@calumny.jyacc.com>,
  Hyman Rosen <hymie@prolifics.com> wrote:
> Hyman Rosen <hymie@prolifics.com> writes:
> > Ted Dennison <dennison@telepath.com> writes:
> > > find it appalling that anyone would develop a product like a
> > > pacemaker, on which the life of a human being depends on its
> > > continuous reliable operation, in a language known to be as
> > > error-prone as C. This is not an opportunity for me to be
> OK, I'm being a smartass, but I am making a valid point.
> Having its software written in Ada was not enough to keep
> the Ariane 5 from going off-course and being blown up. In

That's a good point. Luckily, I never claimed any such thing. If someone
does, tell me and I'll jump in with you.

> the same way, having the software of a pacemaker written
> in C is not enough to force it to blow up. I would assume
> that pacemaker software undergoes thorough critical-systems
> development and testing regardless of what language it's
> written in.

No. But testing does not guarantee the total absence of bugs either
(another Arianne lesson). Thus it is not sufficient in my view to make
up for poor development tools with testing. By that logic it would be
perfectly OK for me to hand-machine aircraft parts with a hammer and
chisel, as long as they were all thoroughly tested.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Mike Silva]

Hyman Rosen wrote in message ...
>"Mike Silva" <mjsilva@jps.net> writes:
>> This is a silly strawman, since nobody (at least, nobody who wants to be
>> taken seriously) ever makes such extreme claims.  It's all a matter of
>> increasing the odds, and both the C language and the C culture invite
buggy
>> code (sad to say, I've written my share).  Every C programmer should
perform
>> the eye-opening exercise of determining how many C bugs they encounter
would
>> not have been possible, or would have been quickly spotted, in Ada.
>
>I would assume that for safety-critical code, the development process
>is such that these errors would be found if they were present. After
>all, Ada's error checks can help only in the development process, not
>once the pacemaker is installed, so the code would have to be carefully
>checked to make sure that no exceptions would actually be triggered.
>This is the same process the C code would go through.

Firstly, shortening the development process by catching more errors quicker
is a Good Thing.  Secondly, I can imagine plenty of scenarios where software
and/or hardware glitches can be captured, corrected in some manner (even if
via restart) and logged in a running pacemaker, to be analysed later,
perhaps resulting in the loading of improved code into the device (I believe
this is possible -- it certainly should be!), or leading to hardware
improvements.  Surely a pacemaker has to be able to recover quickly from
just about any data foul-up possible, and no amount of design and testing
can provide a 100% guarantee against such foul-ups.

The essence of your comments seems to be that equal cost and quality code
can be produced with any language.  This seems like an ivory tower position,
ignoring the constraints of time, money and human fallibility.

Mike

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Pat Rogers]

"Hyman Rosen" <hymie@prolifics.com> wrote in message
news:t7n1pk6gwx.fsf@calumny.jyacc.com...
> "Mike Silva" <mjsilva@jps.net> writes:
> > This is a silly strawman, since nobody (at least, nobody who wants
to be
> > taken seriously) ever makes such extreme claims.  It's all a matter
of
> > increasing the odds, and both the C language and the C culture
invite buggy
> > code (sad to say, I've written my share).  Every C programmer should
perform
> > the eye-opening exercise of determining how many C bugs they
encounter would
> > not have been possible, or would have been quickly spotted, in Ada.
>
> I would assume that for safety-critical code, the development process
> is such that these errors would be found if they were present. After
> all, Ada's error checks can help only in the development process, not
> once the pacemaker is installed, so the code would have to be
carefully
> checked to make sure that no exceptions would actually be triggered.
> This is the same process the C code would go through.

Error checking at run-time is still vital, and Ada's checking (if left
in) can help.

Although it is a common practice in (well-done!) safety-critical
development to prove that exceptions cannot occur, they still can.  The
obvious cause is radiation-induced hardware errors.  The more difficult
issue, because it is based upon human imperfection, is that of errors in
the specification.  No amount of program proof will circumvent that
problem.  In that case run-time checks can serve to invoke the fault
tolerance mechanisms, however extensive those may or may not be.
Clearly some applications can have no fall-back position (the classic
example is a launched missile) and in those cases there's no point in
checking.   But in those cases in which faults can be tolerated the
checks are directly helpful.

That's not to say that similar checks cannot be hand-coded in any
language, but that is another issue.

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Mike Silva]

Hyman Rosen wrote in message ...
>"Pat Rogers" <progers@NOclasswideSPAM.com> writes:
>> Error checking at run-time is still vital, and Ada's checking (if left
>> in) can help.
>>
>> Although it is a common practice in (well-done!) safety-critical
>> development to prove that exceptions cannot occur, they still can.  The
>> obvious cause is radiation-induced hardware errors.  The more difficult
>> issue, because it is based upon human imperfection, is that of errors in
>> the specification.  No amount of program proof will circumvent that
>> problem.  In that case run-time checks can serve to invoke the fault
>> tolerance mechanisms, however extensive those may or may not be.
>> Clearly some applications can have no fall-back position (the classic
>> example is a launched missile) and in those cases there's no point in
>> checking.   But in those cases in which faults can be tolerated the
>> checks are directly helpful.
>
>But it's exactly that mechanism that led to the Ariane 5 crash.

I'd argue that it wasn't the mechanism that was at fault, but the
assumptions encoded into the error handler.  It's easy to conceive of an
error handling strategy that would have let the Ariane survive.

> I have
>argued before that *not* catching such errors at runtime might be a
>better approach, because it's possible that such an error would cause
>only slight local effects which would quickly damp out, whereas invoking
>error handling leads to massive global effects.

Since the nature of an unforseen error is, well, unforseen, it's hard to
hard to catch every case.  Still, I'd much rather see an effort at handling
errors than a blissful disregard of them.  Such error handling need not lead
to "massive global effects".  I think it's noteworthy that the Ariane report
did -not- advocate ignoring errors, but rather (picking the two
recommendations that seem most appropriate to this discussion):

"R6 Wherever technically feasible, consider confining exceptions to tasks
and devise backup capabilities."

"R8 Reconsider the definition of critical components, taking failures of
software origin into account (particularly single point failures)."

Mike

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Pat Rogers]

"Hyman Rosen" <hymie@prolifics.com> wrote in message
news:t7bt606bro.fsf@calumny.jyacc.com...
> "Pat Rogers" <progers@NOclasswideSPAM.com> writes:
> > Error checking at run-time is still vital, and Ada's checking (if
left
> > in) can help.
> >
> > Although it is a common practice in (well-done!) safety-critical
> > development to prove that exceptions cannot occur, they still can.
The
> > obvious cause is radiation-induced hardware errors.  The more
difficult
> > issue, because it is based upon human imperfection, is that of
errors in
> > the specification.  No amount of program proof will circumvent that
> > problem.  In that case run-time checks can serve to invoke the fault
> > tolerance mechanisms, however extensive those may or may not be.
> > Clearly some applications can have no fall-back position (the
classic
> > example is a launched missile) and in those cases there's no point
in
> > checking.   But in those cases in which faults can be tolerated the
> > checks are directly helpful.
>
> But it's exactly that mechanism that led to the Ariane 5 crash.

No.  They treated all exceptions as indication of hardware failures
because they didn't believe
they could happen due to software.  They didn't meaningfully handle the
exception -- they aborted the program!  Since they abused the software
they were reusing (by using it in a different context, in which
exceptions were unavoidable) their assumptions were invalid.

> I have
> argued before that *not* catching such errors at runtime might be a
> better approach, because it's possible that such an error would cause
> only slight local effects which would quickly damp out, whereas
invoking
> error handling leads to massive global effects.

A man falls off a very, very tall building.  Halfway down he is heard to
say "This isn't so bad after all!".

Placing one's head in the sand seems a very unhelpful approach.  The
Ariane 5 management made a very bad mistake by doing just that.

--
Pat Rogers                            Training and Consulting in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Ole-Hjalmar Kristensen]

Ted Dennison <dennison@telepath.com> writes:

> In article <t7g0vdq2x0.fsf@calumny.jyacc.com>,
>   Hyman Rosen <hymie@prolifics.com> wrote:
> > Hyman Rosen <hymie@prolifics.com> writes:
> > > Ted Dennison <dennison@telepath.com> writes:
> > > > find it appalling that anyone would develop a product like a
> > > > pacemaker, on which the life of a human being depends on its
> > > > continuous reliable operation, in a language known to be as
> > > > error-prone as C. This is not an opportunity for me to be
> > OK, I'm being a smartass, but I am making a valid point.
> > Having its software written in Ada was not enough to keep
> > the Ariane 5 from going off-course and being blown up. In
> 
> That's a good point. Luckily, I never claimed any such thing. If someone
> does, tell me and I'll jump in with you.
> 
> > the same way, having the software of a pacemaker written
> > in C is not enough to force it to blow up. I would assume
> > that pacemaker software undergoes thorough critical-systems
> > development and testing regardless of what language it's
> > written in.
> 
> No. But testing does not guarantee the total absence of bugs either
> (another Arianne lesson). Thus it is not sufficient in my view to make
> up for poor development tools with testing. By that logic it would be
> perfectly OK for me to hand-machine aircraft parts with a hammer and
> chisel, as long as they were all thoroughly tested.
> 
> --
> T.E.D.

It seem to me that you are severly underestimating the utility of hand
tools, and the precision you can obtain by manual work.
Followups to rec.crafts.metalworking :-)

> 
> http://www.telepath.com/~dennison/Ted/TED.html
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
E pluribus Unix

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]


Hyman Rosen <hymie@prolifics.com> a �crit dans le message :
t7iu09q36i.fsf@calumny.jyacc.com...
> Good thing the Ariane 5 didn't land on anyone's house.
The Ariane5 launch pad is on the east side of south-america, and since
rockets are always fired eastbound, there was really no risk there...

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

"Mike Silva" <mjsilva@jps.net> writes:
> This is a silly strawman, since nobody (at least, nobody who wants to be
> taken seriously) ever makes such extreme claims.  It's all a matter of
> increasing the odds, and both the C language and the C culture invite buggy
> code (sad to say, I've written my share).  Every C programmer should perform
> the eye-opening exercise of determining how many C bugs they encounter would
> not have been possible, or would have been quickly spotted, in Ada.

I would assume that for safety-critical code, the development process
is such that these errors would be found if they were present. After
all, Ada's error checks can help only in the development process, not
once the pacemaker is installed, so the code would have to be carefully
checked to make sure that no exceptions would actually be triggered.
This is the same process the C code would go through.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Scott Ingram]

Hyman Rosen wrote:
> 
> OK, I'm being a smartass, but I am making a valid point.
> Having its software written in Ada was not enough to keep
> the Ariane 5 from going off-course and being blown up. In
> the same way, having the software of a pacemaker written
> in C is not enough to force it to blow up. I would assume
> that pacemaker software undergoes thorough critical-systems
> development and testing regardless of what language it's
> written in.

I spent my high school years working in Emergency Rooms and 
Intensive care units with cardiac monitoring devices that I
later took a job as final test and calibration technician for.

Testing and cal were fairly well defined, and after I finished
with them they went to a QA inspector whose procedure differed
slightly from mine.  I used the lead set supplied with the device
from the production line, and the QA inspector used a set that
stayed at her bench.  It was only after a device had failed QA
4 consecutive times and I went to watch her do QA that I realized
where the problem lay.  The soldering process for the lead set
socket wasn't appropriate, and most, if not all of the monitoring
devices were defective.  Since this is a diagnostic tool used
when a patient is already in extremis, chances of applying a
harmful or deadly treatment were incredibly high.  Every device
of that model had to be called in for repair.

Admittedly, using Ada won't solve all bugs and can't fix poor
hardware design--but its usually one of the first tools I pull
out because its so good at helping me not make mistakes in the
first place.  And I know from frighteningly real experience
that testing can be flawed.
-- 
Scott Ingram
Sonar Processing and Analysis Laboratory
Johns Hopkins University Applied Physics Laboratory

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

Ted Dennison <dennison@telepath.com> writes:
> No. But testing does not guarantee the total absence of bugs either
> (another Arianne lesson). Thus it is not sufficient in my view to make
> up for poor development tools with testing. By that logic it would be
> perfectly OK for me to hand-machine aircraft parts with a hammer and
> chisel, as long as they were all thoroughly tested.

I said *development* and testing. This also means careful code inspections.
When you develop pacemaker software in Ada, you still must scrutinize the
code to insure that runtime exceptions will never happen. Runtime exceptions
will help you detect errors during testing, but such exceptions must never
be allowed to happen in production. The same scrutiny will be applied to C
code.

And you certainly can hand-machine the aircraft parts, if you can still do
that to spec. What's wrong with doing that? If you mean to imply that hand-
machining is somehow equivalent to coding in C, I must confess that I don't
understand the analogy.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

"Mike Silva" <mjsilva@jps.net> writes:
> The essence of your comments seems to be that equal cost and quality code
> can be produced with any language.  This seems like an ivory tower position,
> ignoring the constraints of time, money and human fallibility.

This is absolutely not my position. I am willing to believe for the sake
of argument that Ada code can be produced more cheaply and with higher
quality than equivalent C code. I am responding to the claim that it is
irresponsible, dangerous, and possibly criminal to code safety-critical
in C or C++.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

"Pat Rogers" <progers@NOclasswideSPAM.com> writes:
> Error checking at run-time is still vital, and Ada's checking (if left
> in) can help.
> 
> Although it is a common practice in (well-done!) safety-critical
> development to prove that exceptions cannot occur, they still can.  The
> obvious cause is radiation-induced hardware errors.  The more difficult
> issue, because it is based upon human imperfection, is that of errors in
> the specification.  No amount of program proof will circumvent that
> problem.  In that case run-time checks can serve to invoke the fault
> tolerance mechanisms, however extensive those may or may not be.
> Clearly some applications can have no fall-back position (the classic
> example is a launched missile) and in those cases there's no point in
> checking.   But in those cases in which faults can be tolerated the
> checks are directly helpful.

But it's exactly that mechanism that led to the Ariane 5 crash. I have
argued before that *not* catching such errors at runtime might be a
better approach, because it's possible that such an error would cause
only slight local effects which would quickly damp out, whereas invoking
error handling leads to massive global effects.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

"Pat Rogers" <progers@NOclasswideSPAM.com> writes:
> No.  They treated all exceptions as indication of hardware failures
> because they didn't believe
> they could happen due to software.  They didn't meaningfully handle the
> exception -- they aborted the program!  Since they abused the software
> they were reusing (by using it in a different context, in which
> exceptions were unavoidable) their assumptions were invalid.

When you have proved that something can not happen, you will not then
add code to handle that event gracefully. After all, that's the entire
point of software proofs in the first place. If it turns out that your
proof is in error, it is exceedingly unlikely that the code will fall
back to a reasonable behavior.

Do you see people writing 'if a = 3 and then a = 3' just in case the
first equality was a fluke?

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Karel Thoenissen]

Ted Dennison schreef:

> > Hyman Rosen <hymie@prolifics.com> a �crit dans le message :
> > t7iu09q36i.fsf@calumny.jyacc.com...
> > > Good thing the Ariane 5 didn't land on anyone's house.
> > The Ariane5 launch pad is on the east side of south-america, and since
> > rockets are always fired eastbound, there was really no risk there...
>
> Hoboy, you stepped in it this time. Now you're going to get all sorts of
> flames from Falkland Islanders...

Buy a map.

--

Groeten, Karel Th�nissen

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Richard D Riehle]

All this fuss about Arianne 5.

Arianne 5 failed because of bad engineering decisions.  The choice
of Arianne 4 components, proven and tested, for Arianne 5 would have
been fine if they were both the same design.  They weren't.

Using the wrong component, however good that component might be, is
equivalent to a physician prescribing a perfectly good medication
to someone with a medical history for which it is contraindicated.

Richard Riehle
richard@adaworks.com  

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> And some small fraction of automobile collision victims who are not wearing
> safety belts are "thrown clear".  Exceptional cases do get more press.

I am clearly in need of enlightenment, so please explain to me. After
you have decided that a given situation is impossible, will you
nevertheless add an error handler for that impossible situation, so
that if it happens anyway, you can recover gracefully? To what level
of detail and impossibility will you go? When you write Ada code, how
many exception handlers for Program Error do you put into your code?

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Hyman Rosen]

Richard D Riehle <laoXhai@ix.netcom.com> writes:
> All this fuss about Arianne 5.

We know that Ariane 5 failed in the larger sense because of bad
management decisions. Where humans work, mistakes can happen.
We're (now) discussing the propriety of enabling runtime checks
in production code. Ariane 5 makes a good example for discussion.
What happens when proofs of behavior turn out, for whatever reason,
to be wrong? When you code, you are always proving things, or else
you would never be able to make any progress -

	if a = 3 and then a = 3 and then a = 3 and then ...

At some point, you must be satisfied that a condition for which
you are checking holds. How much time and effort do you then devote
to worrying about whether that condition *really* holds, and to
writing code which will trigger if that condition does not hold?

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Rod Chapman]

> When you develop pacemaker software in Ada, you still must scrutinize the
> code to insure that runtime exceptions will never happen.

There's an alternative...we now have the tools do construct
proofs that exceptions are never raised, and thus we can
_justifiably_ turn off checks.  Proofs are (given some
reasaonable failure hypothesis) valid for all input data.
It also (surprisingly) turns out that the proof work was _more_
cost effective than unit testing on one project - see our paper
in FM'99 for details.

This stuff really works, and we've done it on several large
projects, mostly in the safety-critical aerospace arena.  Most
people seem to think that program proofs on reasonable size
projects is impossible, perhaps owing to bad experiences
on University courses (just like me!)
 - Rod Chapman

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Ole-Hjalmar Kristensen]

Hyman Rosen <hymie@prolifics.com> writes:

> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> > And some small fraction of automobile collision victims who are not wearing
> > safety belts are "thrown clear".  Exceptional cases do get more press.
> 
> I am clearly in need of enlightenment, so please explain to me. After
> you have decided that a given situation is impossible, will you
> nevertheless add an error handler for that impossible situation, so
> that if it happens anyway, you can recover gracefully? To what level
> of detail and impossibility will you go? When you write Ada code, how
> many exception handlers for Program Error do you put into your code?

Or as my father used to say: "It's no use protecting a (electrical)
fuse with another fuse"

-- 
E pluribus Unix

Re: Geography (was: JOB:Sr. SW Engineers Wanted-Fortune 500 Co)

[Jean-Marc Bourguet]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

In article <879hjf$ggv$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article <38972EA0.D8BE3932@hello.nl>,
>   Karel Thoenissen <thoenissen@hello.nl> wrote:
> > Ted Dennison schreef:
> >
> > > > Hyman Rosen <hymie@prolifics.com> a �crit dans le message :
> > > > The Ariane5 launch pad is on the east side of south-america, and
> > > > since rockets are always fired eastbound, there was really no
risk
> > >
> > > Hoboy, you stepped in it this time. Now you're going to get all
> > > sorts of flames from Falkland Islanders...
> >
> > Buy a map.
>
> No need to. When someone such as yourself needs correcting,
[ demonstration of web search ]

You missed a point, what was the starting point of Ariane?

A+

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Geography (was: JOB:Sr. SW Engineers Wanted-Fortune 500 Co)

[Ted Dennison]

In article <38986DC2.1D921776@hello.nl>,
  Karel Thoenissen <thoenissen@hello.nl> wrote:
> Ted Dennison schreef:
>

> No amount of weblinks can mask your ignorance. The Falklands are about
> 6300 km to the south of Kourou, Guayana, France (!). I mean 'south'
> when I write 'south', not 'south-east', not even 'south-south-east'.

No one (other than yourself just now) mentioned Guayana, Kourou, or
France. Go back 3 posts. The geographic term in question was "South
America" The islands in question are indisputably dead east of South
America. Any decent map I could go out and buy, as you kindly suggested,
will show it this way.

My main point in bringing this up at all was poke fun at those folks out
there that are literally itching to flame someone over statements that
are in essence true, but technically incorrect because of their general
nature. In return I get roasted for just that reason. When I'm done
dusting the ashes off of myself, I'll have to sit back and savor the
irony.

(brush)(brush){cough!}

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Geography (was: JOB:Sr. SW Engineers Wanted-Fortune 500 Co)

[Gautier]

Ted Dennison:

> > No amount of weblinks can mask your ignorance. The Falklands are about
> > 6300 km to the south of Kourou, Guayana, France (!). I mean 'south'
> > when I write 'south', not 'south-east', not even 'south-south-east'.

> No one (other than yourself just now) mentioned Guayana, Kourou, or
> France. Go back 3 posts. The geographic term in question was "South
> America" The islands in question are indisputably dead east of South
> America. Any decent map I could go out and buy, as you kindly suggested,
> will show it this way.

But, anyway, buy that map!
Or if you are pressed, zoom out (-) your Web map several times.
Big surprise awaiting!

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Richard D Riehle]

In article <t7ln544nkz.fsf@calumny.jyacc.com>,
	Hyman Rosen <hymie@prolifics.com> wrote:

>We're (now) discussing the propriety of enabling runtime checks
>in production code. Ariane 5 makes a good example for discussion.
>What happens when proofs of behavior turn out, for whatever reason,
>to be wrong? When you code, you are always proving things, or else
>you would never be able to make any progress -
>
>	if a = 3 and then a = 3 and then a = 3 and then ...
>
>At some point, you must be satisfied that a condition for which
>you are checking holds. How much time and effort do you then devote
>to worrying about whether that condition *really* holds, and to
>writing code which will trigger if that condition does not hold?

Industrial engineers used to be taught to question whether 100%
checking was appropriate for 0.001% errors.  This notion led to
a question during a meeting I attended where we were planning the
architecture for a hospital laboratory software system.  One of
the system engineers asked, "Well, what is the probability of
this event occurring?"  The laboratory manager replied, "We cannot
rely on probability. We can kill people with this stuff."

Your example, an if ... end if statement suggests the need to encode
this checking in the program.  In his famous Turing lecture, Tony
Hoare criticized Ada for even having exception handling and suggested
the same approach: if there is a possibility of error, write your code
to detect and handle it rather than rely on some exception mechanism.

Ada 95 offers this option in the X'Valid attribute.  The question of
100% checking for 0.001% error needs to be asked each time one decides
to use X'Valid.  Ada (and Eiffel) Exception handling carries none
of the overhead associated with 100% error checking within the program
code.  The exception handler is invoked only when some variable fails,
at run time, to conform to its run-time profile.  

For example, should one check for divide-by-zero each time through a
iteration:

         for I in Data'Range loop
             X := some computed value using I;
             Y := X/Z;
         end loop;

Would it be proper to add code to ensure that the computation of X
could never be zero and process that code during every iteration? 
In a long running program, this would seem to be foolish to some,
essential to others.

In Arianne, the failure was in a piece of code that was short-lived
and had critical timing implications.  It would have been perfectly
OK to do the checking since the code would not be revisited again
during the mission.  That is 100% checking would have been very
inexpensive.  

We see the practice of turning off checks all the time in space
applications.  Software deployed on the MIL-STD 1750A almost always
has a pragma Suppress(All_Checks).  The reason given is the need for
reserve memory over and above that required for initial deployment.
It rarely has to do with timing factors.  In fact, in current 
design, it is assumed that space applications will be deployed with
All_Checks turned off.  This is probably a mistake with current
architectures and code optimizers, but has simply become the habit.

So your question, "How much time and effort do you then devote ..."
will be answered differently by the laboratory manager than by the 
engineering manager responsible for a communication satellite. 
In the case of Arianne 5, nobody asked the right questions or did
enough analysis to determine the correct answer to the right
questions, even if they had been asked.

Richard Riehle
richard@adaworks.com

           
 

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Roger Racine]

On 01 Feb 2000 16:19:12 -0500, Hyman Rosen <hymie@prolifics.com>
wrote:

>kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>> And some small fraction of automobile collision victims who are not wearing
>> safety belts are "thrown clear".  Exceptional cases do get more press.
>
>I am clearly in need of enlightenment, so please explain to me. After
>you have decided that a given situation is impossible, will you
>nevertheless add an error handler for that impossible situation, so
>that if it happens anyway, you can recover gracefully? To what level
>of detail and impossibility will you go? When you write Ada code, how
>many exception handlers for Program Error do you put into your code?

I am currently working on a fault tolerant computer project.  The
faults we are tolerating are -hardware- faults.  We assume that
-anything- can happen if hardware fails.  If you just checked that X =
3, it does not matter.  As Pat Rodgers said, in a space environment X
could experience a singe-event-upset that could change its value to 2.

So for our system, we have 4 processors each running the same
software.  RAM scrubbing checks memory.  Presence tests check that the
software is in the same place at the same time on each processor.
Voting of inputs guarantee that a maximum of 1 processor will have bad
data (if any do).  Outputs are voted at the actuators.  

This protects against any single hardware failure from affecting the
system.  With our system we can tolerate 2 hardware failures if they
happen sufficiently long enough apart for the software to have
reconfigured after the first failure.

The numbers folks have given this sort of system about a probability
of 99.999999999% of success (defined as the computer system not
failing during the mission).  I might have missed some "9"s, but it is
at least this good.  For comparison, a single computer that is
performing Built-in-test periodically has a probability of about 95%
or less (depending on the radiation environment).

If the system has a design error (such as Ariane 5), nothing can save
the system.  It is similar to getting 4 failures at the same time in
our system.  That is what testing, proofs, peer reviews, etc are for.
To get rid of design and manufacuring errors (where manufacturing
errors for software would be coding errors).

Getting back on the initial track of this thread, Ada helps to prevent
coding errors.  It certainly can not stop design errors.  Can one
trust C or C++ in a pacemaker?  Probably.  Could the errors that were
found during the extensive testing been prevented if used Ada?  Some.
Could they save time and money by using Ada?  Very likely.  Would
maintenance be easier?  Definitely.  Can you re-use the software on
another system without somehow verifying the new system?  NO!

Roger Racine

Re: Geography (was: JOB:Sr. SW Engineers Wanted-Fortune 500 Co)

[Karel Thoenissen]

Ted Dennison schreef:

> In article <38972EA0.D8BE3932@hello.nl>,
>   Karel Thoenissen <thoenissen@hello.nl> wrote:
> > Ted Dennison schreef:
> > > > Hyman Rosen <hymie@prolifics.com> a �crit dans le message :

> > > > The Ariane5 launch pad is on the east side of south-america, and
> > > > since rockets are always fired eastbound, there was really no risk
> > >
> > > Hoboy, you stepped in it this time. Now you're going to get all
> > > sorts of flames from Falkland Islanders...
> >
> > Buy a map.
>
> No need to. When someone such as yourself needs correcting, there are
> web-based maps such as MapQuest I can point them to. For example, this
> nifty one I just generated shows the Falkland Islands:

No amount of weblinks can mask your ignorance. The Falklands are about 6300
km to the south of Kourou, Guayana, France (!). I mean 'south' when I write
'south', not 'south-east', not even 'south-south-east'.

Kourou:     5.09 N   52.39 W
Falklands: 51.45 S   59.00 W

> I'm not sure how long the link stays good. But if you see it, note the
> large body of land just to the West. That's South America. In case the
> source of your confusion was actually the meaning of the term "eastbound",
> I don't need to buy a dictionary either, as I can point you to the webster
> definition at:

> http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=eastbound&method=
> exact which states:
>    eastbound adj : moving toward the east; "eastbound trains" [syn:
> {eastward}]

Thanks for pointing this out. It saves me from explaining what southbound
means.

Perhaps Latin-America is larger than you thought (-8

--

Groeten, Karel Th�nissen

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Larry Kilgallen]

In article <m3emaug917.fsf@blight.transcend.org>, Ray Blaak <blaak@infomatch.com> writes:

> Errors will still happen, but the number of idiotic, invalid index, invalid
> pointer errors that can be completely preventable just go way down.

Most important to me is that inspectors cannot find any of those "easy"
defects so they will be concentrating their efforts on the "hard" ones.

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Mike Silva]

Since nobody else has answered your question I didn't want to let it go
without a try.  The general approach, whether via built-in or hand-coded
exception handling, is to try to continue to supply best-guess results.  If
you think of a given chunk of software as a black box with some input, some
output, and a red "Exception!" light on it, the idea is that when the red
light goes on you try to stick something useful in the output even if you
don't know where in the box the problem lies.  This something useful could
be predetermined data, or previous-pass data, or perhaps data from another
process which is good enough to limp along on.  Or perhaps you switch to
another mode which doesn't require the output of the failed "box".  At the
same time you can try to re-initialize any hardware associated with the box
(e.g. I've seen LCD displays that sometimes go out to lunch and need to be
coaxed back into a working electrical state via re-initialization).  The
possibilities are endless, depending on the hardware and the software
functional breakdown, but quite often you can think of something useful to
do, especially in the short term (in the case that the hardware just had a
momentary hiccup).

To extend the safety belt analogy, you add collapsible steering columns and
safety glass windows even though the safety belt will never allow you to hit
the wheel or the windows.

Mike

Hyman Rosen wrote in message ...
>kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>> And some small fraction of automobile collision victims who are not
wearing
>> safety belts are "thrown clear".  Exceptional cases do get more press.
>
>I am clearly in need of enlightenment, so please explain to me. After
>you have decided that a given situation is impossible, will you
>nevertheless add an error handler for that impossible situation, so
>that if it happens anyway, you can recover gracefully? To what level
>of detail and impossibility will you go? When you write Ada code, how
>many exception handlers for Program Error do you put into your code?

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[JP Thornley]

In article <s9e3f6fver26@corp.supernews.com>, Pat Rogers
<progers@NOclasswideSPAM.com> writes
>Error checking at run-time is still vital, and Ada's checking (if left
>in) can help.
>
>Although it is a common practice in (well-done!) safety-critical
>development to prove that exceptions cannot occur, they still can.  The
>obvious cause is radiation-induced hardware errors.

But for random memory events, run time checks don't do the job.

Firstly because a protection mechanism where the level of protection
depended on the declared range of the variable's type would not be
acceptable. (For a variable of Character type, stored in one byte, the
protection would be zero.)

Secondly because compiler writers work very hard at removing run-time
checks when it is 'known' that a run time check cannot fail.

The ideal way to approach protection of data from corruption is to
determine three things:
1. what are the hazards that could be caused by corruption of the data
2. what is the cost (all aspects) of identifying and correcting that
corruption
3. what is the probability of the corruption occurring.

When you have all this data you can make a reasoned judgement based on
ALARP principles (as low as reasonably possible) to determine what to
do.

Unfortunately, in the work I have done in this area, we have zero data
for the probability of data corruptions occurring. So a common strategy
(based on the current use of cyclic schedulers) is to protect and check
any data that is stored between cycles, but not to protect data values
that are created and used within a cycle. This makes the data to be
protected easy to identify and bounds the time that any data remains in
store without being checked (and gets us out of having to protect tricky
stuff such as stack frame pointers and subroutine return addresses).
This works well in systems with low feedback, and where a bad output on
one iteration can be tolerated but a sequence of bad outputs is not
acceptable (which I suspect covers a large number of safety-critical
systems).

It also supports the use of pragma Suppress_All, having of course proved
that no run-time check would have failed if it had not been suppressed.

Note that if run-time checks are left in they create a substantial
testing task. Safety-critical standards require test coverage of every
branch in the executable code. So the tester must first identify where
run-time checks have been compiled in and then create test data that
will cause each one of them to fail - not always easy and probably
requiring the use of intrusive test techniques (also regarded with deep
suspicion when developing safety-critical code).

Cheers,

Phil

-- 
JP Thornley

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Charles Hixson]

I am working on a non-critical project.  Really non-critical:  I'm using Visual
Basic :-(.  But I notice that after I've taken all the valid paths to an if
statement, I throw in an else that 1) throws up an error message dialog and 2)
exits the subroutine.
Now I don't even try to do an error recovery, but I do check for the "Impossible
Error" occurring.  I *think* that so far it's only happened during development.
If not, the users are failing to follow the instructions and call me. (This is an
internal-use project.)

Hyman Rosen wrote:

> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> > And some small fraction of automobile collision victims who are not wearing
> > safety belts are "thrown clear".  Exceptional cases do get more press.
>
> I am clearly in need of enlightenment, so please explain to me. After
> you have decided that a given situation is impossible, will you
> nevertheless add an error handler for that impossible situation, so
> that if it happens anyway, you can recover gracefully? To what level
> of detail and impossibility will you go? When you write Ada code, how
> many exception handlers for Program Error do you put into your code?

Re: JOB:Sr. SW Engineers Wanted-Fortune 500 Co

[Charles Hixson]

Richard D Riehle wrote:

> -- snip
> Industrial engineers used to be taught to question whether 100%
> checking was appropriate for 0.001% errors.  This notion led to
> a question during a meeting I attended where we were planning the
> architecture for a hospital laboratory software system.  One of
> the system engineers asked, "Well, what is the probability of
> this event occurring?"  The laboratory manager replied, "We cannot
> rely on probability. We can kill people with this stuff."
> -- snip

<rant>
But, of course, one MUST rely on probability.  There is no other choice.
One can insist on higher standards, but that is itself relying on
probability.  The sun rising tomorrow is the classic statement of
certainty.  But the probability still hasn't reached 100%.  In fact, I
didn't see the sun rise today...

People must rely on either a numeric or an intuitive estimate of
probability.  It's a question of which one chooses to use.  In an informal
setting, I usually use the intuitive estimate, unless a more formal
estimate it REALLY easy.  But if people's lives depend on it, then one
should insist on a more formal estimate (unless it would be ridiculously
complicated).
</rant>