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

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
Quoted text here. Click to load it

I think the Ada and SPARK communities can, which is why I've added
comp.lang.ada to this thread.  For example, here's reference to a
100:1 residual error reduction between C and SPARK, and a 10:1
reduction between C and Ada, with all code having been previously
certified to DO178B level A:

http://www.sparkada.com/downloads/Mar2002Amey.pdf

Some more interesting reading (note that MISRA acknowledges that there
are better languages than C for safety-critical work):

http://www.sparkada.com/downloads/misracatsil4reader.pdf

This document has a table of language recommendations (search for
"Language Recommendations (IEC 1508)" ).  C is only recommended for
SIL1, while it is not recommended for SIL3 and SIL4:

https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.doc

Mike

Re: Certified C compilers for safety-critical embedded systems
On 22 Dec 2003 21:06:08 -0800, snipped-for-privacy@yahoo.com (Mike Silva)

Quoted text here. Click to load it

An interesting article, though not for the residual error reduction
references, which are simply quotes of claims made by Lockheed, with
no background. However, the author makes some excellent points,
including one I don't see made often enough - that higher level
languages tend to increase abstraction but decrease predictability.
This is countered to a significant extent by using a well-chosen
language subset, like SPARK. In particular, this leads to the
possibility of static analyzers which are, in a sense, the logic
equivalent of lint's syntax checking.

In reference to "those who maintain that choice of programming
language does not matter, and that critical code can be written
correctly in any language", he says "The claim may be true in
principle but clearly is not commonly achieved in practice." Let me
interject that my position is that "critical code can be written
correctly in any language" (actually stronger than I would contend),
but not that "choice of programming language does not matter." I'd
also point out that there is probably more critical code written in
assembler and C than in Ada or SPARK :-)
Quoted text here. Click to load it
Sorry, but the MISRA recommendations and guidelines are so poorly done
that I can't accept them as even relevant. This is not just my
opinion, but that of some very well-respected authorities, and has
been discussed here on occasion.

Quoted text here. Click to load it

This is one in a series of lectures. I would have some fun arguing
with the lecturer on some of his points, but he does include the
referenced tables from the IEC publication (which I'm too cheap to buy
:-)

I think I have to concede that, on the average, code quality can be
better with a well-chosen subset of a higher-level language other than
C. However, it's still my opinion that "average" programmers, as
described in these studies, shouldn't be writing safety-critical code.

Unfortunately, the material presented doesn't give me any idea of the
whole development process - I don't know if the code in question was
reviewed, linted, or even designed before coding ;-) It may have more
to do with other parts of the process than with the language. I won't
argue that C and poor process are often found in the same
neighborhood.

Since a large part of my work is maintenance of legacy systems, I'll
readily agree that the error rate I encounter is horrible. I'll also
claim that error rates of programs I've completely reworked are very
low. Further, most of the errors I find would have been prevented by
good practices, sticking to standard C where possible, and paying
attention to compiler warnings. In fairness to my predecessors, some
of this code was written before the standard, which excuses about 3%
of the problems I find.

Anyway, some very interesting reading. Thank you.

--
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


Just to clarify, the error reduction claims I was referring to were
those cited from a UK MoD study done by Aerosystems International.
I'd like to be able to find that study, or a fuller summary, on line.

Mike

Re: Certified C compilers for safety-critical embedded systems


[snip]
Quoted text here. Click to load it

The study was only fully reported at a private MoD briefing.  The
nearest thing to a public version is in a recent article by Andy German
(of Qinetiq) in a recent issue of Crosstalk.  The Andy German paper
covers experiencess of static analysis of a large number of air systems
and shows similar (but not quite so extreme) trends to the C130J figures.

Peter


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

I have just downloaded your paper. Interesting and well worth reading.

Regards
        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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

Ah, but do you have a way of preventing that ?

(Not just on systems you build, but on those to which you entrust your
own safety.)

Quoted text here. Click to load it

One of the big flaws in replacing a software system outright is to
ignore the fact that requirement capture has been inadequate.

Re: Certified C compilers for safety-critical embedded systems
On 23 Dec 2003 14:33:11 -0600, snipped-for-privacy@SpamCop.net (Larry Kilgallen)

Quoted text here. Click to load it

I'm not quite sure what you mean. In maintenance work, the only reason
to modify a program is because it doesn't, in some respect, meet
requirements, either the original requirements or new requirements
which have evolved. Requirements are rarely static during initial
development, let alone a few years down the road :-)

When I say "completely reworked", I don't mean to imply that I rewrite
programs from scratch. I make them ANSI compliant and warning free,
eliminate unused elements, eliminate globals as far as possible,
eliminate unsafe (often erroneous) practices and code,  restructure
and recode to make the code more maintainable, and  where possible
replace internal functions with standard C functions or functions from
our proven in-house libraries. At that point I can stand to read it,
and the real work begins <g>. After this, usually there is
considerable refactoring and often some replacement of algorithms.
Some testing is done during the process. A code review follows,
corrections are made if needed, and more formal unit testing is done
before turning the product over to QA.

Typically, during this process, I'll identify a dozen or more bugs in
an average thousand-line program. Some of them will be recognized by
our support people - "Gee, it's been doing that every couple of
months, but we couldn't reproduce it" , or more often "It's always
done this, but we have a workaround."

That last, incidentally, is a real problem for us. Our support people
are good, and often come up with workarounds to problems they never
tell us about. They enjoy being heroes to the customer, and can't be
persuaded that they'll never run out of work ;-)

--
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

For years the program has met some requirements that are "hidden".
Users depended upon certain features but they were never called out
as features in the documentation - they were useful interactions
between different documented features.

A good example is the VMS Mail program, which someone decided to
rewrite from Bliss into C, most likely because they favored C.
Now, ten years later, they are just getting rid of the MAIL/OLD
command that invoked the previous Bliss implementation.  They
had to carry it that long because of all the undocumented features
missing from the Bliss version.

Quoted text here. Click to load it

Ok, that is different.

Larry Kilgallen
Who subsequently rewrote a Bliss program into Ada, knowing
the lesson of VMS Mail, because the original Bliss design
was incompatible with new requirements.  That rewrite is
just now starting to hit the streets.  Wish it luck :-)

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

That will change.

Quoted text here. Click to load it

Praxis has a vested interest in not letting C be used for SIL 4

BTW
slide 3 is erroneous.
slide 5 is also erroneous.

AFAIK Praxis are not "involved" with MISRA-C they may have been some
years ago in the original version but much work has been done since
then. AFAIK they have not taken much, if any part, in this.

AFAIK they did not make their SPADE C results available to the MISRA-C
working group who for the last 3 years have been working on MISRA-C2.

Praxis don't have a unique view of MISRA-C.  They are one of many who
were involved in MISRA-C1. They are not one of the main companies who
were promoting and working with it in the last 5 years.

Slide 6 is interesting. The quotes are out of context and misleading.
The Praxis presentation is clearly written with a (commercial) axe to
grind. I was at the MISRA-C 2002 forum. In fact I did one of the
presentations that has been misquoted....

As it goes on they rubbish C and surprise surprise come up with a
solution that is their tools.... :-)

The Ada (tools) community must be rattled if it needs to spend time
trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
longer push a MISRA-C tool?

Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
several major automotive companies, aerospace companies, also  members
of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
available at the end of Q1 2004


Quoted text here. Click to load it

Yet  C is used in some of the highest integrity systems around. Other
languages that are recommended hardly exist and certainly not on many
platforms.

Empirical evidence and a glance at 61508 may require a change in the
table D2.... BTW table D2 in the lecturers notes is NOT in 61598.

In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
copy of 61508, all 7 parts. We find a similar table to "D2" above:

            Sil1   Sil2   Sil3 Sil4
Ada          HR    HR      R    R
ADA (subset) HR    HR      HR   HR
C            R     -      NR    NR

as expected  BUT

C (subset, codinng standard and static analysis)
             HR   HR      HR     HR


So whilst straight ADA *is* better than vanilla C. No one would debate
that!  Spark ADA is no better than C with a subset, coding standard and
using static analysis....  IE much the same constraints as SPARK ADA has
over ADA...

I know of projects using C in Railway, space, aero and medical projects.

PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
for these for many targets. BTW is there ADA for the PIC, AVR and 8015?

I come back to my comment previously that the ADA tools vendors must be
worried if they are spending this much effort trying to rubbish MISRA-C
which is an automotive guide.  Though it has gained widespread use
outside the automotive industry due to those involved with it.


Regards
        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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

Thanks for the good analysis. I'd like to keep up with news about
MISRA-C2. What's a good source?

--
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

Well come the new year comp.lang.c.misra  assuming I can get the
paperwork sorted.

Otherwise just ask me.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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
Great. I'll keep a lookout.

--
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

Nit: it's "Pascal," "Modula-2," and "Ada."

The PIC I doubt. I'm hard-pressed to consider some of the "C"
compilers for PIC to be C.  As an alternative HLL, JAL (Just Another
Language) is kind of interesting.  http://www.voti.nl/jal /

The AVR is supported by GCC, so GNAT might work, though the runtime
support probably isn't there.  I haven't tried it in any case.

The 8015 I've never heard of.  I assume you mean 8051, to which I'd
have to say I haven't heard of one, though there is a Modula-2
compiler.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems
Quoted text here. Click to load it
:-)
I know what you mean.

Quoted text here. Click to load it
GCC is not usually suitable for 8 and 16 bit embedded systems. IT is a
generic compiler system that is not usually a patch onthe commercial
ones..

Quoted text here. Click to load it



yes.... though some one will now tell us about the 8015 from 197* that
was around for 2.3 years :-)

Quoted text here. Click to load it

But is it any good?

I once had to work on an embedded system using Mod2 a none of the
compilers supported the basic language in the same way.  Let alone
extensions.  It turned out that the most stable compiler was the least
standard :-(

A theoretically good language is no use at all if the compiler
implementations are no good.

At least with C there will usually be several commercial compilers and a
multitude of testing and checking tools.  

It's one thing having a compiler but what about the rest. How many ICE
support ADA?

Regards
        Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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

Avr-gcc actually generates _very_ nice code for the AVR, better than
one commercial compiler I use, and comparable with another.  Of
course, unlike the 8051, the AVR was developed with HLL (esp. C) in
mind.  For example, it has 32 general-purpose registers.

[...re: 8051...]
Quoted text here. Click to load it

You'd have to ask Mr. Granville.  Though I think I know what he'd say.
;-)

But as a datapoint, it was able to come within one instruction of my
handwritten assembly on a pathological checksum routine I posted back
in January of 1999 (seven instructions vs. six).  The Keil C compiler
I was usingat the time (v5.5 IIRC) was unable to do better than 13,
even when using the intrinsics for byte rotation and testing the carry
bit.

So from what little I've seen, I'd say it looks quite good.

Quoted text here. Click to load it

Fewer implementations implies fewer good implementations, true.  At
least the odds are reduced.  Fewer targetted platforms means your code
is less portable as well.

Quoted text here. Click to load it

I think I said it earlier in this thread: The only processors I'm
aware of that don't have a C or NQC (Not Quite C) compiler are
four-bitters.  It's ubiquitous.

But C can be, umm, subtle, and static checking tools (particularly
Lint) are IMHO _required_.  Sadly, they're not often used.

Quoted text here. Click to load it

Nit: ICE is hardware.  And the various debuggers I've seen shipped
with most ICE systems don't support C particularly well either.

And I haven't used an ICE in years.  

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

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

I like "NQC"....  it is a useful TLA as the standards people get in to a
tizz when you talk about the C that is on most 8/16 bit embedded
compilers.

Quoted text here. Click to load it

There is NO EXCUSE for not using a static analyser on C. There are free
Lints,  Commercial ones i.e.   PC-Lint is only a couple 100 USD

I can't see ANY justification for not using some form of Lint with C.

Quoted text here. Click to load it

Yes.... of course it is. It is an embedded debugging tool. Somewhat
relevant in a discussion on language support in an embedded NG

Quoted text here. Click to load it
I have... several.

ICE support C VERY well.  As well as (actually better) than simulators.

There is little of no similar support for most other languages.  There
is some for ADA... Years ago I saw some for Pascal and Modula2 but I
don't know any supporting them now.

If you don't use an ICE how do you debug and test?

Regards
  Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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

Certainly there is an excuse -- it is not enforced by the compiler.

That is quite different from the situation with Ada.

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

So it all has to be enforced by the compiler?

The main difference between C and ADa is that the average ADA programmer
is in a safety critical environment. The average C programmer is not.

If C program development was *normally* taught as though it was going to
be used in a safety critical environment I think things would change.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ 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

No, it doesn't.  I agree with you that (in principle) there's nothing
wrong with running 'lint' or whatever in addition to the compiler.
However, 'lint' (in the case of C) doesn't have enough information
to perform the checks that are routinely done by Ada compilers.

The issue is not (primarily) which tool does the analysis (the compiler
versus lint).  The issue is how much information about the intent of the
programmer is contained in the source code.

Quoted text here. Click to load it

I think it's a mistake to assume that that "average" Ada programmer is
doing safety critical work.  Ada (and/or SPARK) are good in that
environment, but Ada is also quite good for writing run-of-the-mill
non-safety-critical programs, too.  I don't know the statistics, so I
can't say about "average", but the program I'm working on right now
is not safety critical, or even real-time or embedded, but I get some
productivity benefit from Ada's ability to allow me to express various
(compile-time-checkable) constraints.

So I don't agree that the "main" difference between C and Ada is their
environment.

(Boy, I guess the spelling police will really get after you for spelling
"Ada" wrong twice in the same sentence -- "ADa" and "ADA".  Sheesh.  ;-))

Quoted text here. Click to load it

Probably.  But to learn Ada, you have to first learn to write "Hello,
world", and then learn some more simple stuff, and so on.  Same with C.
Nobody learns to write real-time/embedded/high-integrity/safety-critical
stuff on the first try.

- Bob

Re: Certified C compilers for safety-critical embedded systems

Quoted text here. Click to load it

Two simple examples are array bounds checking and scalar range checking.

The C standard explicitly permits accessing one element beyond the end
of an array. Neither the C compiler nor lint can determine if an array
index is outside the bounds of the array. Ada compilers detect static
references beyond the end of an array every time.

Examples:

int foo[10];

int i;

for(i = 0; i < 100; ++i)
{
   foo[i] = i;
}

Although human inspection clearly identifies the for loop indices
to be beyond the bounds of the array, neither the C compiler nor lint
will detect the problem. Since the problem can be clearly identified
using human inspection one might assume this is a problem one would
never see. Unfortunately, the definition of the array may occur many
dozens or even hundreds of lines of code away from the "for" loop.
The definition and the "for" loop may even be located in different
source files, making the likelihood of human identification very low.

type my_index is range 0..9;
type My_Array_Type is array(my_index) of integer;

foo : My_Array_Type;

for num in 0..99 loop
   foo(num) := num;
end loop;

All Ada compilers will correctly identify the error in the for loop.
The type of "num" is not the same as the type of the index, because
the range of values defined for "num" are not all within the range of
values in my_index. This detection will happen properly no matter how
far the definition is separated from the "for" loop.

Another problem, at least in my uses of lint in the past, was the
settings for lint. You can set lint sensitivity from very low to
very high. The lowest settings for lint miss a number of errors, while
the highest settings for lint often produce a number of false error
indications. It is not always obvious which lint setting to use for
the best level of error identification with a minimum of false error
messages.

Jim Rogers

Site Timeline