Certified C compilers for safety-critical embedded systems

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.

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

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

Indeed. For safety critical systems it's essential that the subset of the language you intend to use is clearly specified. Using a decent lint tool with strong type checking and the warning level set high can also significantly improve type checking.

I think that the using a validated compiler can also provide a false sense of security. Throw in a few unchecked conversions and you can easily make an inherently unsafe Ada program. Plus a validated compiler will only do what you tell it, rather than what you want it to do.

Agreed.

Andy

Reply to
Andy Sinclair

Sorry, but MISRA is not to C what SPARK is to Ada.

MISRA is a collection of seemingly-random, often contradictory guidelines that attempt to steer the programmer away from the darker corners of the language. Some of the rules are good, some bad, some indifferent, some are impossible to break (e.g., Rule 85, "don't call a function that takes no parameters without an empty set of parentheses"), and some are impossible to understand (e.g., Rule 29, "The use of a tag shall agree with its declaration").

The best thing about MISRA is that it gives you permission to break the rules if you have to. And you _will_ have to. For example, rule

3 says "break rule 1". In almost exactly those words.

Following MISRA will not (in itself) result in better code. It will allow you to check off a MISRA box (if your customer has one). That's about it.

But tools. Now _there's_ an idea. Specifically lint. Especially Gimpel's PC-lint or FlexeLint. Lint early. Lint often. Lint is your friend. (Now where have I heard that before? ;-)

Note it is very important to _understand_ the messages lint is giving you, not just work around or disable them. You will learn a lot about C and a lot about your code and how the compiler must translate it. If you do this, you _will_ get better code.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

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

What is? I don't follow.

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

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

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

-- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, & Control

-- Raytheon Missile Systems - Member Team Ada & Team Forth

-- NOTE: please remove in email address to reply

---------------------------------------------------------------------------------

Reply to
Jerry Petrey

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

formatting link

Reply to
Peter Bushell

Yes. I like lint. A valuable tool, once set up properly. However, every user should be required to memorize your second paragraph and recite it at least four times per day :-)

Some modern compilers do a pretty good job when set for max warnings.

--
Al Balmer
Balmer Consulting
 Click to see the full signature
Reply to
Alan Balmer

All else being equal, look at GreenHills.

--
#include 
 _
 Click to see the full signature
Reply to
Kevin D. Quitt

I do not know of any certified C compilers for Safety-Critical applications.

None of which would provide enough "real evidence" for safety critical applications.

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.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

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.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

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.

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

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

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.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

Well, this article discusses a review, by the UK Ministry of Defense, of code certified at DO-178B Level A. Thus it is reasonable to consider it an apples-vs-apples comparison. The review found that Ada code had only 10% of the residual errors of C code, and that SPARK code had only 1% of the residual errors of C code.

formatting link

Mike

Reply to
Mike Silva
[text deleted]

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

I would -love- to be able to use Modula-2 today, but sadly it died the death of the obscure ( I guess having a non-buggy M2 compiler spoiled me). Having to write "safe" code (isn't that the goal for all of us, whether it's for life-support applications or not?) in C scares me to death.

Given the choice of the language looking out for you or not, I'll take the language looking out for you. What else is all this CPU horsepower for?

-MG.

Reply to
Mike

It's not for providing excuses. Telling the boss "it's not my fault, the compiler should have fixed it" won't wash in my business.

--
Al Balmer
Balmer Consulting
 Click to see the full signature
Reply to
Alan Balmer
[...]

There are a few still out there, e.g.,

formatting link
for the 8051. You can probably find more if you poke around the Modual-2 webring,
formatting link
though I'm not sure what you'll find targetting embedded processors...

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

You must belong to the Microsoft school of applications development -- if some is good, a /lot/ more is better! 8-)

As with all work of this nature, there are tradeoffs. It's nice to have a lot of processing power, but if it's wasted mostly "looking out for you" and little is left for doing some real work, then you've missed the target.

Reply to
Everett M. Greene

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.