MISRA tutorial and seminar announcement. Standards or Guidelines?

If you are a world traveler, The Motor Industry Software Reliability Association (MISRA) just announced a tutorial and seminar:

"A tutorial and seminar in collaboration with the Safety-Critical Systems Club (SCSC) will be held on 24 and 25 November 2010 in London, UK. On the first day there will be two half-day tutorials, on the MISRA C and MISRA C++ guidelines for the use of these languages in critical systems. The second day will be a seminar that will consider how the MISRA guidelines support safety-related systems development in various industry sectors, and we are particularly keen to feature presentations of case studies. If you would like to speak at this seminar, please discuss your idea with me in the first instance.

Further details of the programme will be available in due course.

There will also be a small exhibition on the second day. Details of the exhibition are available from Joan Atkinson at the SCSC

____________________
Dr David Ward
MISRA Project Manager
Article:

http://www.misra.org.uk/forum/viewtopic.php?f=210&t=1058&p=2032#p2032"

For those not familiar with MISRA, MISRA publishes a set of 'Guidelines' on 'Best Practices' for the languages C and C++. For example what languages constructs are bug prone and should be avoided in embedded systems used in vehicles. Many companies outside of the automotive industry have adopted the use of these guidelines, to help keep bugs out of their products.

Netrino also has a similar set of guidelines, with some links to some real world tips: Embedded C Coding Standard.

A technical semantic nit I want to pick is that these are guidelines. Standards are set by recognized bodies like IEEE and IEC - International Electrotechnical Commission. I frequently see things like "MISRA Standard". The distinction is a subtle one, but could be important to a product liability suite. Which is not to say that a company can not set 'internal standards' for coding practices. English is such a wonderful language... :-(

IEEE P730 Standards Software Quality Assurance, IEEE/EIA 12207.0 Standard for Information Technology - Software Life Cycle Processes, and IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems, are all example of standards used in Embedded Systems. There are more examples at my Software Safety site.

Update on IEC 60730 Self-Tets. Added Microchip

I updated my previous post on IEC 60730 Power Up Self-Tests, to add Microchip to the list of vendors supplying IEC 60730 compatible libraries.

IEC 60730 Power Up Self-Tests

[April/6th/2010: Updated this entry to add Microchip. Do you know of any others to be added?]

I was asked this week what I knew about "a self test at power up according standard IEC61508". First thing I can tell you is that Functional safety of electrical/electronic/programmable electronic safety-related systems has a price tag of over $1200! I always find the high prices of these numerous standards extremely frustrating and expensive.

In the past I was involved with the creation of reports, Programmable Electronic Mining Systems: Best Practice Recommendations (In Nine Parts) for the Centers for Disease Control (CDC)/ National Institute for Occupation Safety and Health (NIOSH) Mining Division. These reports draw heavily from International Electrotechnical Commission (IEC) standard IEC 61508 [IEC 1998a,b,c,d,e,f,g] and other standards. They are in the public domain, and can be found at my hardware site.

The newer standard, IEC 60730 is also mandating power up self-tests. You can preview what you are getting for your big bucks here.

The IEC 60730 safety standard for household appliances is designed for automatic electronic controls, to ensure safe and reliable operation of products. I always find it a bit ironic that now things like our refrigerator and dishwasher, have more stringent standards than some of the devices that really can kill us.

IEC 60730 segments automatic control products into three different classification:

• Class A: Not intended to be relied upon for the safety of the equipment.
• Class B: To prevent unsafe operation of the controlled equipment.
• Class C: To prevent special hazards.

Hardware:

• Independent clocked Watchdog Timer - this provides a safety mechanism to monitor:
• The flow of the software
• Interrupt handling & execution
• CPU clock too fast, too slow and no clock
• CRC Engine when available - this provides a fast mechanism for:
• Testing the Flash memory.
• Check on serial communication protocols such as UART, I2C, SPI.

Software:

• CPU Register
• Program Counter
• Flash CRC Using software and/or hardware CRC engines
• RAM Tests
• Independent Watchdog Timeout

Safety regulations and their impact on MCUs in home appliances has a short introduction to 60730.

Fortunately for us several companies have implemented IEC 60730 compliant libraries. Listed alphabetically:

• Atmel: AVR998: Guide to IEC60730 Class B compliance with AVR microcontrollers.
• Frescale: IEC 60730: Automatic electrical controls for household and similar use. Along with AN3257: Meeting IEC 60730 Class B Compliance with the MC9S08AW60.
• Liminary Micro [Now part of TI]: Stellaris IEC 60730 Library.
• Microchip: Class B Safety Software Library for PIC MCUs and dsPIC DSCs
• NEC: Application Note IEC60730 Class B Support for certification, at 88 pages is the longest of them all.
• ST: claims to have STM32 60730 MISRA compliant library, however I could find no such library in a quick search.
• TI: How IEC 60730 Impacts Appliance Design and MCU Selection.
• Renesas: IEC 60730-1 Standard.
• Zilog: Z8FMC16100 Series of Flash MCUs PB020302-0207 Motor Control Library Class B Compliant.

What all of these tests fail to address in any meaningful way is what happens when a power up test fails? Best you can hope for is that you have a beeper or LED hooked up directly to a Micro pin that you can blink or beep. For example if you find that your accumulator has a stuck bit, you are hosed as at that point. You can not guarantee that anything you do is going to be correct.

There is also the problem of the trade off of being thorough with exhaustive tests, verses being fast. Some standards such as NFPA mandate that the system must be operational in under one second to complicate maters even further. I did have a micro one time that did have a hardware failure. The XOR instruction was broken, but only on certain bit combinations. Every other aspect of the part worked just fine. It took days to debug that problem. As at the time the micro in question was hard to get and expensive, swapping it first was not an option.

One closing thought is that you need to be vary wary of simple RAM tests. Writing 0xAA/0x55 tells you almost nothing about open address lines etc.