Certified C compilers for safety-critical embedded systems

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.

Reply to
Ignacio G.T.
Loading thread data ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

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.

formatting link

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.
Reply to
Not Really Me

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
 Click to see the full signature
Reply to
Alan Balmer

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

formatting link

Reply to
Peter Bushell

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

Reply to
Mike Harding

From a medical equipment point of view, the tool (being the C Compiler in this case) has to be demonstrated to be appropriate for use and that appropriate mitigations are in place in the event of it's failure. The issue of whether it is "inherently unsafe" and thus unsuitable to use, is a developer decision. The FDA guidelines on 3rd Party tools mandates a risk analysis be performed on the system and thus this would lead to fault analysis of the components used. The fault in the compiler, such as producing incorrect code, would have a mitigation. In any case, anyone developing software for safety-critical systems would have their own acceptance criteria for the compiler and not soley rely on a piece of paper saying that it's ISO C compliant or whatever.

A don't disagree that probably Ada and Pascal are better languages to program in but their use restricts the choices of microprocessors that can be used. Pragmatically the device that is to be developed has to be commercially viable. Also the experience depth of those software engineers who know Pascal and Ada are limited.

The approach of using C or any language in a safety-critical application is to ensure an appropriate degree of testing, commiserate to the level of criticality, is applied to all levels of testing from unit, integration and system. For example, for the level of criticality, if 100% structural coverage in unit testing is desired then this may mean that the software should be designed for testability. This in my mind is the more important aspect, rather than whether the compiler is C or Ada (even if Ada were "certified" safe).

Ken.

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

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
Reply to
Rene Tschaggelar

In article , Ignacio G.T. writes

What is the target?

No.

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

That is not ISO C complience though.

Comencu.

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

If you read Safer C by Les Hatton you will discover that Ada and Pascal are in practice no safer than C

this is correct. At the moment only one C compiler claims to be ISO C compliant.

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

Quite a lot of people use C in automotive systems. Somethings can be done which reduce risk. The first is to use a subset of the language usually something like the MISRA C standard. There are tools availible from several companies which check compliance against such standards.

The other thing is to either only use minimal or no optimisation at all so the mapping of C to machine code is as exact as possible.

Of course this only facilitates the testing that must be done it doesn't remove the need for it.

-p

--
Paul Gotch
CoreSight Tools
 Click to see the full signature
Reply to
paul.gotch

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

Reply to
Bill

CBFalconer wrote in news: snipped-for-privacy@yahoo.com:

Could you tell me why is C language inherently unsafe? And why Ada or Pascal are considered safer?

P.Krumins

Reply to
Peteris Krumins

Mostly it is historical: C has always allowed 'enough rope to hang yourself', whilst other languages are more strict in type declaration, paramater checking, and scope control as examples. Modern C's CAN (by option), of course, get close to the same, but the problem is that they do not REQUIRE it - so the issue becomes one of programming discipline, and that's not a good place to put all your safety critical eggs. The best recipe is a structured language AND strong programming & Test discipline. Included in that is the version control practice of mking sure you freeze the compiler version you developed/tested with.

-jg

Reply to
Jim Granville

SPARK is a subset of Ada.

Reply to
John R. Strohm

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.

Reply to
John R. Strohm

Basically because of redundancy. In Pascal you can say you are dealing with a limited subset of things, and the compiler will enforce this. In C you are always dealing with integers, to all practical purposes. Ignoring floating point, everything else in C is made up of integers with no restrictions, or pointers, again with no real restrictions.

People can write Pascal (and Ada) code in terms of integers, and avoid all the checks. But this is pure foolishness.

In C you can fling pointers about with total abandon, and sometimes make some sense out of the usage. In Pascal such usage is closely controlled, and a misused variable is very likely to be uncovered early, rather than by its effects hours later.

Underneath the languages are very similar.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

This is fine in theory. However good C compilers are VERY good. I once had to work in Modular2 because it was a "safe" language but the compilers were so buggy and inconsistent it made a complete mockery of a "safe" language.

The other thing is because C is the most popular language on the planet there are many high quality testing tools for it. Unlike Pascal etc.

People use a subset of C , Ada etc for safety critical. When you come down to subsets most languages are OK for safety critical.

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

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

Which one ?

-- Ignacio G.T.

Reply to
Ignacio G.T.

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
Reply to
Ken Lee

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.