Slashdot Mirror

Tesla is a member of MISRA (Motor Industry Software Reliability Association).

MISRA prohibits unions.

MISRA: Unions shall not be used.

There is a discussion on Stackoverflow about the rationale for this restriction, and also some permitted exceptions to the rule.

lame arse 100Mhz 16 bit CPU the electrical engineers gave me when the brake guys are telling me I need to react to wheel slip within 100us otherwise I could kill somebody

From what I've seen of that sort of computing? They were lucky to have that much to work with :P Also, they should have to stick to MISRA standards.

There are some quality/safety standards for UK automotive software

You know, before making fun of someone due to an unknown abbreviation you might want to google for it first. Otherwise you only make your lack of knowledge obvious.
One can definitely argue whether MISRA really prevents "most of the coding issues" as claimed by the GP (or whether it is the rigorous testing) but restricting C definitely helps.

MISRA which has become the basis for coding standards for things like Joint Strike Fighter doesn't allow recursion. I wonder to what standard they code to?

The MISRA software development guidelines for C can make a lot of sense in embedded, real-time or safety-critical systems, and can also be applicable outside of that application domain.

On the whole though.. one thing that tends to be lacking in coding standards is an underlying reason behind many rules - it's hard for developers to judge the applicability of an exception if they don't know why the standard was introduced - common error? Past internal experience?

Try http://www.iec.ch/zone/fsafety/scope.htm. I also recommend looking at MISRA C http://www.misra.org.uk/index.htm.

Unlike coding standards that merely make your surce look pretty, these standards actually help improve quality by improved design. They are well worth looking at if you can buy (or find) a copy.

It's pretty remarkable that in this entire discussion not one person has made reference to the MISRA guidelines, which are specifically designed to make it feasible to build highly-reliable systems in C (and now C++, although that is still work in progress), and which are backed by a worldwide community, excellent tools, etc. All the detials are at http://www.misra.org.uk./

hence a lot of these sorts of systems are still hand coded in assembler , never mind C.

This is just plain wrong. Most vehicle manufacturers apply the MISRA guidelines for C for their embedded systems. These are intended to provide quality assurance and highly robust systems.

The guidelines/rules actively discourage the use of assembly language except where necessary to inteface with hardware. It is much more difficult to develop robust assembly than robust C.

The idea that assembly is significantly faster than C is also a myth, unless you have an exceedingly poor compiler. Compilers are good at micro- and macro- optimisation, and often choose better instructions and constructs than a developer. There are very few developers that dedicate themselves to complete familiarity with a processor architecture and its instruction set (without which you simply can't optimise efficiently).

There is no substitute for a competent programmer if you wish to write secure code. There is equally no substitute for a well-designed language, nor for effective tools to support programming in that language.

The safety-critical software community has been tackling these very issues for the past fifteen years or more; the security community is sometimes guilty of re-inventing the safe software wheel, and doing it badly. Safety engineers have already come up with the MISRA C subset (here) and tools to enforce it, but the general conclusion appears to be that C (and C++) are inherently unsafe languages and there's only so much you can do to patch over the problems.

If programmers are serious about wanting to write correct code, they are going to have to check their egos at the door and use tools that tell them where they are going wrong as early as possible. My personal suggestion is the SPARK Ada subset and associated toolset, but then I'm biased. :-)

Take a little longer over your code. Get it right first time. Write your tests before you write the code. Use static analysis tools that are proven to pick up real errors. But enjoy what you're doing, because the best programmer in the world is still going to produce crap code if he's bored...

Adrian

Some great information re State-of-the-art in 1980, Notations, Exception/Concurrency etc. My thanks, take a virtual "+1 Informative" from me.

As for the 'success' of ADA, what little success it has had has almost without exception been coerced. It does not say anything for the suitability of ADA for safety critical systems that it is used when the original proponents of ADA require its use as a contract condition.

• Reuters news service
• Swiss Postbank Electronic Funds Transfer system
• Airbus 330 and 340
• Beechjet 400A and Beech Starship I
• Beriev BE-200 (Russian forest fire patrol)
• Boeing 737-200, -400, -500, -600, -700, -800
• Boeing 747-400
• Boeing 757
• Boeing 767
• Boeing 777
• Canadair Regional Jet
• Embraer CBA-123 and CBA-145
• Fokker F-100
• Ilyushin 96M (Russian jetliner)
• Saab 2000
• Tupolev TU-204 (Russian jetliner)
• Cairo Metro
• Calcutta Metro
• Caracas Metro
• Channel Tunnel
• Conrail (major U.S. railway company)
• French High-Speed Rail (TGV)
• French National Railways
• Hong Kong Suburban Rail
• London Underground
• Paris Metro
• Paris Suburban Rail

[arguments for using a restricted subset of C.] "Nonetheless, it should be recognised that there are other languages available which are in general better suited to safety-related systems, having (for example) fewer insecurities and better type checking. Examples of languages generally recognised to be more suitable than C are Ada and Modula 2. If such languages could be available for a proposed system then their use should be seriously considered in preference to C."

This post is getting long - most people won't read this far. But if you want, I'll follow-up with more hard data regarding reliability, cost etc. Basically, the reason Ada gets used is that it's provably better, the numbers on reliability, cost-to-develop, defect-rates etc. show it.

First you should understand the difference between testing and verification. With testing, you rule out a certain number of bugs, but you can never guarantee the absence of bugs. The latter is only possible with software verification, where you prove that the software contains no bugs and fulfills its specification.

Unfortunately, software verification is very expensive. Also, software verification is still a subject of research, and AFAIK it has not been tried for large software projects so far. (My current research project aims at verifying a complete operating-system kernel -- check out the VFiasco project.)

So in most cases, verification is too expensive, and you need to ensure robustness by other means like a good programming standard and testing. (I believe that is what you are looking for, despite the title of your question including the word ``verification.'')

If your shop uses C, I recommend the following book: Les Hatton, Safer C . It explains what a good programming standard should contain, and advocates automatic enforcability. (It also explains what the standard should not contain -- in particular, issues of style such as indentation and variable naming.) One example of such a programming standard for C are the Guidelines for the Use of the C Language in Vehicle Based Software, which should be particularly relevant to you as you also work in the automotive industry.

Testing is another important aspect. In safety-related environments such as yours, a high test coverage for your code is desirable. This requirements suggests automated testing on the unit level. Automated unit testing is practical only if the code is designed to be testable, and there are a number of strategies which provide this property, such as avoiding dependency cycles (for C and C++, John Lakos' Large-Scale C++ Software Design still is the ultimate guide), or creating the unit test before the program (the Extreme Programming way). I also liked Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert Binder - a huge and thorough guide to all imaginable kinds of testing, especially for object-oriented systems.

MISRA site, I think. It doesn't appear that it contains any free information, just ISBN info so that you can buy the specs and recommendations.