Certified C compilers for safety-critical embedded systems - Page 12

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Certified C compilers for safety-critical embedded systems
On 18 Dec 2003 01:36:04 GMT, Peteris Krumins

Quoted text here. Click to load it
Actually, it's the programmers who are unsafe, not the language. C
provides little to protect them against themselves, whereas Ada and
some other languages make it somewhat harder to write unsafe code.

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it

I'm jumping into this discussion a bit late, but let me just try an
analogy that I have used at my workplace. I think C is to Ada as a
motorcycle is to a car. Yes, a motorcycle is likely to be more fun to
ride than a car is to drive. Also, an expert rider who rides
cautiously might even be able to ride safer than a bad driver can
drive. But we all know that, in general, motorcycles are not as safe
as cars. Not even close. And if you are trying to develop
safety-critical systems with C, that is comparable to using a
motorcycle for basic family transportation. Not the wisest thing to
do.

But that's just my opinion. If you want the opinions of experts at
DoD, MISRA, ARINC, NASA, and CENELEC, check out the one-page summary I
put together at http://RussP.org/Ada-recommend.pdf . Check out the
other links at my Ada page too while you're at it
(http://RussP.org/Ada.htm ).

Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it

that will change in 3 months time with MISRA-C2

Quoted text here. Click to load it
61508 has C (with subset etc) as HR the same as Ada.
Quoted text here. Click to load it

You will need to modify it.

Whilst looking though some notes I found a table  in the IEE Computing &
Control Engineering Journal Vol 11.1 The edition was loking at 61508 the
paper by R. Bell and PA Bennett.

The table shows failures in safety related systems  

44.1%  were due to specification faults
20.6 due to changes after commissioning

joint 3rd with 14.7% were:
design and implementation
operation and maintenance

there was also
5.9% on installation and commissioning.

So it's not down to the language as much as specification and
process.....  

See the Arianne 5 rocket project. The system failed 29 seconds in due to
Sw errors. the problem was not so much Ada but the way it was used and
the project managed.

NB the project would have flown if C had been used because C is not
strongly typed and the same error would not have been generated.... OK..
I know, if they used C it would never have lifted off in the first
place.... :-)

With a good process in place and proper engineering removing the vast
majority of errors we start to discover the differences in languages is
less important. More important is how good the tools and support tools
for a language are.

I know of one very high integrity system that is using C because the
quality of the compiler is very high and the support tools are
available. They are not available for Ada for the same target. they
could not have done the same level of testing and validation.






 



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it

That's interesting, and I should probably look up this paper (is it
online?). After thinking about it a bit, however, this result is not
too surprising. After all, it seems to me that "specification fault"
is a rather general term. What does it mean? Is it perhaps a catch-all
term for everything other than the software development process
itself?

I work in an engineering environment. Engineers come up with ideas,
which are then often translated into software. Sometimes the
translation process (design/programming) is done directly by the
engineer, but more often it is done by communicating the idea to a
programmer or software engineer. Any defect in the idea itself or in
its communication to the programmer falls under the category of
"specification fault," it seems to me. Being an aerospace engineer
myself, I like to think of myself as an important part of the process.
If our portion of the errors was too small, I'd think that perhaps we
engineers were not taking enough risks with our ideas. So I'm proud
that we're at the 44% level. ;^)

What I am getting at, in a roundabout way, is that, as you probably
realize, "specification faults" have nothing to do with the choice of
programming language. That's an engineering problem. So it is as
irrelevant to the choice of language as, say, drug abuse in the
workplace, just to give an off-the wall example. Would you argue that
the choice of programming language is of minimal importance if half of
the critical errors were due to drugged programmers? Of course not. So
why are you implying that language choice is unimportant because
engineering is important?

Quoted text here. Click to load it

Is that what we sometimes call "maintenance"? My impression is that
Ada excels in this stage.

Quoted text here. Click to load it

Of course it isn't. If the engineering isn't done right, the best
programmers and software engineers in the world are unlikely to
salvage the project.

Quoted text here. Click to load it

Are you claiming that the Arianne 5 wouldn't have failed
catastrophically if the same bug had occurred in C code? If so, that's
definitely interesting. I'm certainly not knowledgable enough here to
comment, but I'm sure others on this forum are.

Quoted text here. Click to load it

You lost me there. As I explained above, I agree that the choice of
language has little effect on the engineering. But the point is that
the choice of language has a strong effect on the software design and
development process. Isn't that what we're talking about here? If not,
sorry, wrong number.

Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it

Yes if you are an IEE member with access to the library

Quoted text here. Click to load it

Yes.


Judging by some of the code I have seen the two may not be unrelated :-)

Quoted text here. Click to load it

I was arguing that the larger problem is the engineering process rather
than which language. However (catch 22 time again) if you have a good
engineering process you are less likely to make errors and be more
meticulous because the sort of people that would set up and ruin a good
engineering process will by definition try and "do things right"

So a good team with a good system will do a good program irrespective of
if it is C or Ada... Ie if C they would use a C subset, static analysis
coding standards, code reviews, full test plans etc...

If Ada they would use SPARK  

However a bad team using a poor engineering system is likely not to
worry too much about the rest of it. SO in that case the enforced parts
of Spark Ada probabluy would be an advantage over C

That was a generalisation!!!! I know everyone can pull up their own
exception!

The Arriane 5 rocket show the problem. Ada but from what I understand
the corners were cut on the testing due to management pressure to do
with launch windows.... Good language. "adjustments" to the system the
rocket failed.


Quoted text here. Click to load it

Maintenance is that which is done by other people after we have all
finished the design and implementation and moved on to the next
excepting project.

Ditto testing :-)

Ditto documentation :-)

Quoted text here. Click to load it

But will get blamed for it :-(


Quoted text here. Click to load it

Definitely. C is not strongly typed. You can chuck a long into a char
and nothing will complain. So IN THIS PARTICULAR CASE an error would not
have been raised and the rocket continued..... However in the 99 similar
cases you would have wanted it to flag an error and it would not have
done so :-)

There are many who point out that had it been written in C it would not
have lifted off anyway due to other errors that would inevtiabley been
in the system.(and the crash would not have occurred ergo C is safe :-)


Quoted text here. Click to load it

I was making  the point that a language, no matter how theoretically
good is only as good as the implementation of the tools to support it.
Ada has less of a problem as compilers can be validated and certified.
Not something that happens with C.

I would agree that the choice of language does have an effect on the sw
and development process. Ada AFAIk is usually taught and used in a
strong safety critical and  Enginering way.  C is often badly taught and
certainly not (usually) with any sort of Engineering or safety critical
ethos. In fact often due to it's history  quick and dirty and hacking
seem more related :-(




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it

As an aside, I disagree with this for two reasons.  First, I expect
that sensor failure, as indicated by "impossible values," would have
been checked for in C code as well as in Ada code.  _Something_ had to
be done if the Horizontal Bias value went berzerk during a launch.
Given the stated bias of the project (untrapped errors were assumed to
indicate hardware failure), the code would have been designed to do
exactly what the Ada code did, through an explicit range check and
switch-to-backup-unit action.

Second, it appears that the "Operand Error" that started the ball
rolling (or the rocket dropping) was actually a hardware FPU
exception.  The Ariane hardware has been reported as Motorola
68020/68881, and Operand Error is the name of the FPU exception that
would result from an out-of-range FP to INT conversion.  Even if the
code were written in C, the exception would have been generated, and
presumably the exception handler would have performed the same
deliberate and intended actions of shutting down the device so the
backup device could take over.

Mike

Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it

Maybe.  Well you would like to thing so.

But I did say in this specific case of putting a large number into a
smaller sized int.

Quoted text here. Click to load it

No complaint about that. My understanding was that the "error" occurred
after the figures from the SW unit were being used as it was past the
point in the flight where they were needed.


Quoted text here. Click to load it

Ok... thats HW so it makes no difference on the language used.

Quoted text here. Click to load it

presumably... It's like the "should" word that keeps cropping up just
before things go wrong :-)

Quoted text here. Click to load it

But as the back up had the same problem.... the rest is history.


Interesting analysis.


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

Quoted text here. Click to load it

Or, as it's know in comp.lang.ada, "not that damned rocket _again_!" :)

Re: Certified C compilers for safety-critical embedded systems
           snipped-for-privacy@sneakemail.com "Russ" writes:

Quoted text here. Click to load it

You do, of course, write all your specifications down, have them
reviewed and corrected if necessary. For you to be proud to be 44%
of the final manifestation of the problem will make me re-consider
whether or not I fly again. Of course errors are made in specification.
We are, after all, only human. However, I think you will find that the
44% is the number of errors that make it all the way from specification
into the final code/equipment. It is really a pointer to innadequate
reviw at the specification stage.
 
Quoted text here. Click to load it

Except that drug abuse in a "Safety Critical Systems" environment is
actually a criminal offence in many countries.

Quoted text here. Click to load it

Programming language has never been the issue. A task may be easier in
some languages than others but more important than the language is the
personnel, the work ethics of those people and the process you employ
to keep the project develoment under control. Programming language is
certainly less than 1% of the consideration.

[%X]
 
Quoted text here. Click to load it

Does that mean you consider programmers and software engineers to be
NOT on the engineering team?
 
[%X]

Quoted text here. Click to load it

IIRC the report virtually stated that that particular error would not
have manifested itself in C. I know that at the time someone posted a
lengthy summary from the report.
 
[%X]

Quoted text here. Click to load it

As one who does not wander into using Algol-like languages very much
I will leave that to others to answer. With the oddball languages I
use (D3, S80, Forth and Assemblers) choice of language does not change
my software design by very much at all.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Certified C compilers for safety-critical embedded systems

<snip>

Quoted text here. Click to load it

The choice of the implementation language should have no bearing on
the software design, unless one is using a language specific feature
as a design feature.

The choice of language may affect the software development process in
so much as coding guidelines and associated work instructions. For
instance, the choice of C over Ada may mean that a more rigorous code
syntax checking be performed and/or more comprehensive structural unit
testing be carried out. The integration and system testing of a system
built with either language should pretty much be the same.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Certified C compilers for safety-critical embedded systems
           snipped-for-privacy@phaedsys.org "Chris Hills" writes:

Quoted text here. Click to load it

I think that makes the points I have been promulgating so often, on this
and other groups, very nicely Chris. Thanks.

The only other point is that whatever your process, it should generate
the necessary evidence for your audit trail to be able to back-track to
where problems were introduced. I know that Def-Std 00-56 was recently
being reviewed to see if the evidential position could be improved.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Certified C compilers for safety-critical embedded systems


Quoted text here. Click to load it

You wish to make a safety critical system with C in a
multiprocessor environment yet not with multitasking ?

To start with, even with a certified compiler, how are you
going to verify, to debug the system ?

Rene
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net


Re: Certified C compilers for safety-critical embedded systems

Quoted text here. Click to load it

Not trying to advocate the use with or without multitasking, I would
have thought that a single-threaded application was much easier to
debug & verify for the following reasons:

1. Processes are more deterministic & predictable
2. To implement single threaded systems, a better understanding of
system timing is required.
3. Test harnesses are much easier to construct and even run on
non-target environments. Running unit tests on a PC-based enviroment
presents the developer with many advantages over target-based
verification, only if an OS port or clone doesn't need to be
installed.
4. A level of testing is removed as there are no acceptance testing or
mitigation required for the OS.

Of course it's horses for courses, and not all single-threaded
implementations are appropriate.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Certified C compilers for safety-critical embedded systems

Quoted text here. Click to load it

Good point. We have done it with a 16 bit compiler, plus some ASM,
plus remote debugging via monitors. The n processors run the same code
(one task), and communicate with each other via common memory and
dedicated bus signals. The debugging could be done because we had the
source code of the monitor: we had to change it in order to start and
stop the n programs 'simultaneously', etc. It was a funny experience.
And it worked. By the way, the hardware was developed by ourselves.

Of course, we followed a strict process (CEN 50126 / 50128 / 50129)
which included (documents and code) inspections, rigurous C coding
procedures ('safe' subset without dynamic memory usage, very
restricted use of pointers, etc.), unit testing with 100% coverage
(this was hard), incremental integration, strict validation
procedures, etc, etc.

We have all of that. What we don't have right now is a tool-chain to
do the same job, but for 32-bit platforms. We know our 16-bit tools
pretty well (we've been working with them for 15 years, and all their
peculiarities -i.e., bugs- are known and well documented; that's what
I call 'proven in use'). I wish we could get a reliable tool-chain for
32-bit, just to reduce the costs of debugging them: our process will
(hopefully)  detect those bugs, but the fewer the bugs, the fewer the
cost.

--
Ignacio G.T.

Re: Certified C compilers for safety-critical embedded systems
snipped-for-privacy@evomer.yahoo.es> writes
Quoted text here. Click to load it

What is the target?

Quoted text here. Click to load it
No.


Ada has a certification system C and C++ compilers don't

Quoted text here. Click to load it

That is not ISO C complience though.

Quoted text here. Click to load it

Comencu.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems
All else being equal, look at GreenHills.


--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
We've slightly trimmed the long signature. Click to see the full one.
Re: Certified C compilers for safety-critical embedded systems
           snipped-for-privacy@evomer.yahoo.es "Ignacio G.T." writes:

Quoted text here. Click to load it

I do not know of any certified C compilers for Safety-Critical applications.
 
Quoted text here. Click to load it

None of which would provide enough "real evidence" for safety critical
applications.
 
Quoted text here. Click to load it

Looking in IEC 61508 it seems that Assembler is still an acceptable
programming environment for such applications but you will need to
apply quite a lot of checking of the design intention translation
to final code.

IEC61508 and other safety critical systems development environments
are leaning towards evidence based approaches. It may be that to get
to a basis of being able to use your new C compiler you may need to
do a lot of your own leg-work in building the evidence of the
integrity of the compiler and follow suitable codes of practice and
reccommended sub-sets.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Certified C compilers for safety-critical embedded systems
On Thu, 18 Dec 2003 18:25:37 +0000 (UTC), snipped-for-privacy@amleth.demon.co.uk

[text deleted]
Quoted text here. Click to load it

It amazes me why validation of the tools isn't done as a matter of
course for safety critical system -- if I read your post correctly.
Mind you it does look good on a FDA 510K submission that the tool used
has this-or-that certification but the legwork (in the medical devices
field) still has to be done.

Certainly for medical devices, the suitability of all tools that are
used in development has to be demonstrated. Certainly for compilers,
these would have to be factored into the risk analysis and appropriate
mitigations implemented. Also with something like compilers or code
generators, in-house acceptance tests & validation tests would have to
be run.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Site Timeline