Certified C compilers for safety-critical embedded systems

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

Translate This Thread From English to

Threaded View
Hello all.

As you may know, several standards mandate the use of certified or
'proven in use' compilers in safety-critical systems. To date, I've
been using 'proven in use' compilers for those systems. Now, I'm
upgrading to a new 32-bit platform and my olde yet fantastic 16-bit C
compiler cannot cope with it.

I've been looking for 'certified C compilers' (do they even exist ?)
via Google. All I've been able to find are Ada validated and/or
certified compilers / run time systems, and also certifiable RTOSes.

I've also found C compilers which claim to have passed certain test
suites (Metaware, Plum Hall, Perennial, ...)

I don't need an RTOS, just a C compiler with a very limited library
support (no file system, no console, no math; just some byte-copying
stuff and low low level I/O).

My target would be Pentium-based, multiprocessor (yeps) and
monotasking.

What do you use (even with different target architectures)? What would
you recommend?

--
Ignacio G.T.

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

And with good reason.  The C language is inherently unsafe, which
is one of the reasons languages with much higher safety (there is
no absolute guarantee) have been designed.  Ada is one such.
Pascal is another, with more insecurities than Ada, and less
power, but much simpler.

AFAIK there is no organization which certifies C compilers to
comply with the ISO standards (which does not make the language
safe).  I believe such does exist for Ada.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
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 would contend that there is no such thing as an inherently safe language,
as all languages are really translators of the designers intentions.  No
language can make up for faulty requirements, design or testing.  Ada is
considered to be safer than C because of constructs and type checking
provided by the language.  In "safety-critical" circles the hot language
seems to be SPARK which was designed with safety-critical in mind.  Despite
it short comings, C is becoming more prevalent, not less, in safety-critical
software.

For a somewhat erudite view on safety-critical, there is a mailing list run
out of the University of York, UK ( snipped-for-privacy@cs.york.ac.uk).   The
issue of languages is a common topic there.
The real issue of any safety-critical design is one of documentation and
testing.  There are some pointers and articales about this on our website.
http://www.validatedsoftware.com/white_papers.html .

In the US, one of the highest levels of safety-critical is the RTCA's
DO-178B Level A, which is used for software in avionics devices that could
result in catastrophic loss of an aircraft.  In this standard, DO-178B
certified software is preferred, but not required, for all tools (compilers,
linkers, test software, etc.).  The use of non-certified compilers is
compensated for by proper testing of all of the object code, and
traceability of the code and all related tests to the original requirements.

--
Scott
Validated Software Corp.



Re: Certified C compilers for safety-critical embedded systems
On Wed, 17 Dec 2003 08:59:16 -0700, "Not Really Me"

Quoted text here. Click to load it

For safety-critical systems, the programmer and system designer are
more important than the language. In past years, I wrote a lot of
safety-critical code, almost all in assembler, with no protection at
all from the language.

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

Agreed. The professionalism and experience of the people are more important
than the language, tools *or process* in producing any kind of decent
software. The sooner this is rediscovered, the safer we'll all be in our
planes, trains, ships and cars!

--
Peter Bushell
www.software-integrity.com




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

Negative.  This is impractical in the real world except in small projects
like with 3 engineers or less or if you work as a lone consultant.  For
medium to big projects, it is the *process*.



Re: Certified C compilers for safety-critical embedded systems

Quoted text here. Click to load it

Also coming from a medical equipment background, having a software
process is mandatory irrespective of the team size. Certainly in the
US, you can't sell medical equipment that uses a micro and is attached
to a patient, without documentation stating that you are following a
process. Perhaps one can get away with it in a 3rd world country where
morbidity is high, one can mask the defects of the equipment.

I'd imagine that developing safety-critical systems in general, would
require a Quality Process & System related to the degree of risk to
the end user.

In response to the previous poster, "professionalism and experience"
of the developer is a very inconsistent attribute. It relies on the
whims of a personal "process" to ensure a quality product. Possibly
with small groups it can be sustained but with larger teams an
appropriate quality system and software process is really required
--- provided we agree that the name of the game is producing a product
at the right quality & within the schedule scope. I say this as it is
always possible, given boundless resources & time to produce a "high"
quality product. Producing quality products within a limited time
scale is the constraint that electronic equipment manufacturers are
facing.

Often engineers blame the "process" for project over-runs and even
product defects. If this is the case then probably this would suggest
that the wrong quality system & process are being used.

The general rule is that if the software process in use doesn't add
value to producing good software  then you're using the wrong process.
A good process is habitual not confrontational.

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@noname.com "Ken Lee" writes:

Quoted text here. Click to load it

Professionalism, surely, demands that the engineers employ a development
process that stands the test by producing dependable systems. Whether it
is an individual engineer, or many teams, there should be a decent
development process in place to manage any project from initial quotation
to de-commissioning at end of system life. For the lone engineer it means
that his process should be acceptable to his clients.

Quoted text here. Click to load it

Any development process for high integrity systems should be quite
visibly employed, leave a decent audit trail and prove that the
development has followed the prescribed path (whatever that path may
be it must be as described in the development process description).

As for large teams;

I favour having more surgical teams. The number of people in one team
should be no more than 7. The team should have regular technical reviews
of each other's designs. Where the project is so large that more than
one such team is required then the requirements should be factored such
that these teams can then deal with a more specific part of the
requirements. This naturally requires the development of interfaces
between the designs of each of the teams. There should also be some way
of cross-reviewing the work of the teams (team a sits in review of team
b's work etc).

Quoted text here. Click to load it

Time-scales have to remain reasonable. It is quite hard to tell a client
that their expectations are not realistic but it has to be done. However,
once a date is promised it must be met, barring the client deciding to
add further requirements (which should be quoted separately including
the knock on effects for the timescale).
 
Quoted text here. Click to load it

When I have seen that some companies QA manual runs to eight or more
volumes I know they are not following any of it. Such is an example
of the wrong process because it is not memorable enough. My own
document is a mere 35 pages but has always stood me in good stead.
The whole process is simply represented on a single page in a
flowchart which is also on my web-site.

--
********************************************************************
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 20:37:52 +0000 (UTC), snipped-for-privacy@amleth.demon.co.uk

Quoted text here. Click to load it

Don't get me wrong -- you'd think what you stated would be true, but
there is no "standard" for professionalism. The fact that one has a
piece of paper stating that they are a bona fide engineer doesn't mean
that they're any good. However by "natural selection", those engineers
that are gainfully still employed and are regarded by their peers as
professional, do use acceptable processes (personal or otherwise).

<snip>

Quoted text here. Click to load it

Although I'm not an advocate of quality manuals of biblical
proportions, I do believe that the QM is dependant on the type of
product one is developing. If one's company is subjected to external
regulatory audits, then the scope of the QM should be so appropriate
(as a minimum) to the auditor's expectations. Theoretically the QM
should be scoped to be appropriate to the level of criticality of the
system.

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

What is? I don't follow.

Quoted text here. Click to load it
Process can be important, certainly, but I've never seen a process
which can crank out a failsafe system design without expert input.

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

While I doubt anyone would deny that a small team of top notch engineers and
programmers could produce a quality product with most any language or tools
(and with minimum process), the reality is that you rarely find this situation,
especially in large companies and on large projects.  What is more common is a
mix of say 10% top notch people, 20% (if you're lucky) near worthless people
and the rest average.  The challenge is to still turn out a quality product.
In this situation, process, language and tool choices make a big difference.
If the top people are running the show (if they're not forget it!), these
things help them to achieve the goal using these average (and below average)
people in a way that makes the product quality more or less independent of the
individuals on the team.  This is what you must have for safety and mission
critical software.  In my 30 years in this business, I have seen plenty of
examples of this not being done right and a few where it has been.

Jerry
--
---------------------------------------------------------------------------------

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

Thank you for stopping that run, Alan. Nowhere did I say that the process
didn't matter, but the following posts are testament to the fact that people
have become obsessed with it. I've come across many people who can write
acceptable C, several companies with good processes and some companies where
engineers actually get to follow the processes. In spite of all this, the
general quality of design I have seen is *appalling*. Nothing much has
changed in that area, lamentably, in the past 20 years!

--
Peter Bushell
www.software-integrity.com




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

Yes, BUT...

Various companies have, to varying degree of formality, done apples-to-apples
comparisons, in their respective domains of expertise.  They have learned that,
IN GENERAL, they get more bang for the buck out of high-order languages than
they do out of assembly language, using comparable teams.

Pratt & Whitney accidentally did an internal study, over the course of several
years, on jet engine controllers.  They were using roughly equivalent teams, and
the tasks to be accomplished were about the same.  The commercial side of the
house was using whatever they wanted to use; the military side of the house was
required to use Ada.  They kept metrics from all of the projects.  The metrics
guy crunched the numbers, and discovered that the Ada projects were getting
something like twice the programmer productivity, across the board, and 1/4 the
defect density, across the board, compared with the commercial side of the
house.

The commercial side of Pratt & Whitney now uses Ada for engine controllers.

In other words, yes, professionalism and experience matter, AND SO DO THE TOOLS.
Given equivalent teams, whether equally brilliant or equally absymal, the team
with the better tools will get the better results.



Re: Certified C compilers for safety-critical embedded systems
On Wed, 17 Dec 2003 22:16:58 -0600, "John R. Strohm"

Quoted text here. Click to load it

Of course. That's been known for decades, and was obvious before any
studies were done. In fact, it is the reason high level languages were
invented. However, the topic of discussion here is not productivity,
but safety. The point is that safe software can be written in any
language, and no language can guarantee safe products if the designers
and programmers don't know how to make them safe.

--
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
           DELETEnewsreplyALL@software-inCAPStegrity.com  writes:

Quoted text here. Click to load it

As long as we are looking at decent development processes, that will
produce sufficient evidence trails for each product, that a notified
body can audit and feel confident enough in the work you have done
then language matters not. It is just easier to produce the evidence
with some languages. Forth and Assembler happen to be reasonably easy
to certify due to visibility of resultant code and the effects of
regular testing of individual modules. It can all fall apart, however,
if the prcess is lax or the developers are un-professional.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Certified C compilers for safety-critical embedded systems
On Wed, 17 Dec 2003 08:59:16 -0700, "Not Really Me"
Quoted text here. Click to load it

What happened to the VIPER? A micro designed in the UK
about 15/20? years ago. I remember hearing assurances
that this was ideal for safety critical stuff because it was
"mathematically correct" or similar?

Mike Harding


Re: Certified C compilers for safety-critical embedded systems
On Thu, 18 Dec 2003 07:55:30 +1100, Mike Harding

Quoted text here. Click to load it

IIRC the design (at the time) had to be synchronous so that it could
be proven correct by automatic proof tools and the speed was limited
to a few MHz because of this.  Another problem was that they used a
diamond on sapphire process (for radiation hardness) that was
complicated and had very low yield.

George
==============================================
Send real email to GNEUNER2 at COMCAST dot NET

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

I once had the misfortune to work on a safety critical project where the use
of interrupts was not permitted.
That was done because it was not possible to prove mathematically that code
containing interrupt service routines was correct.
Instead, polling was used. The resulting increase in code complexity to
ensure that asynchronous events were serviced in a timely manner was
frightening.
There is no doubt in my mind that the use of interrupts would have been
safer.
As for using C, it is a simple language that can be and is used safely by
many people.
I would venture to say that if someone can't use C safely, then they
certainly shouldn't be using a more complex language like C++.
As for Pascal, Modula 2, etc., IMHO they are next to useless in that
interesting place where software meets hardware.

Tanya



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

What a breath of fresh air! Thank you, Tanya.

--
Peter Bushell
www.software-integrity.com




Re: Certified C compilers for safety-critical embedded systems
On Mon, 22 Dec 2003 10:14:48 -0000, "Peter Bushell"

Quoted text here. Click to load it

Me too :)

Mike Harding


Site Timeline