Counterfeit ESD products. Guide on EMC for Functional Safety.

Interference Technology of ITEM Publications, has released their 2010 EMC Directory and Design Guide - Digital Edition. [Alas the Digital Edition is an annoying FlipBook that does not render correctly in Opera. Using FireFox you can find the link to the PDF version.]

Several interesting articles, but there are two in particular I wanted to bring to your attention:

• The Dip Tube by Robert J. Vermillion.
• The IET’s Guide on EMC for Functional Safety by Keith Armstrong.

To the first one you've got to be wondering whats a Dip Tube? Properly rendered as DIP, Dual Inline Package, it makes more sense to you I'm sure. Those long plastic rails that our ICs are supplied to us in from the factory. It seems that not only do we have to worry about counterfeit parts. We now have to also worry about real parts coming in counterfeit anti-static protection, making the real parts unusable junk. Also offers some words of wisdom on reusing anti-static protection. The words are "don't do it".

The lengthy second article is an introduction to the Guide on EMC for Functional Safety, August 2008, ISBN 978-0-9555118-2-0. Available from The Institution of Engineering and Technology as a PDF, or as a real book (colored chemicals on dead trees). Checklists are found here.

The guide is a 9-step Process to Functional Safety taking EMC in to account. It even includes useful checklists to aid project management, design and compliance assessment.

I'll quote Mr. Armstrong introduction directly:

"Electronic complexity is increasing with no end in sight, increasing self-generated noise levels, while the feature sizes in silicon integrated circuits continue to shrink, making them emit more noise while at the same time more susceptible to noise. The use of electronics in safety related applications is growing very rapidly indeed, with (once again) no end in sight.

We have already reached the point where the normal testing-based approach to electromagnetic compatibility (EMC) is totally inadequate where safety is concerned, as current media interest in automobiles with malfunctioning 'electronic throttles' shows. [The Toyota problem seems like a classic case of Priority Inversion to me.]

...

It comprehensively describes practical and cost-effective procedures for both management and engineering, and can be used immediately to help to save lives and reduce injuries, whenever electronic technologies are used in safety-implicated products, systems or installations of any kind. It is so practical that it even includes useful checklists to aid project management, design and compliance assessment.

...

The IET Guide can also be used to improve reliability, for example in high-reliability, mission-critical, or legal metrology applications.

...

EMC immunity testing is never sufficient on its own for safety I hope I have shown that EMC testing can never be sufficient - on its own - to demonstrate that functional safety risks are low-enough, or that risk-reduction will be high enough, over the life-cycle of an EFS, taking its physical and climatic environments (including wear and aging) into account. The number of variables is simply too large. Test plans could be drawn up which would provide the necessary design confidence, but no-one (even governments) could afford their cost, or the very long time they would take. But we’ve been here before! In the 1990s it was realised that testing was not sufficient to demonstrate that software programs were reliable enough for use in safety systems. After many hundreds of man-years of work by academia and industry, the result was Part 3 of IEC 61508."

While on the subject of EMC, Mr. Armstrong is a frequent contributor to the EMC Journal freely available from the Compliance Club. Do check out the past archives of the Journal.

Explaining Interrupts to Non-Programmers, or "I got a go Potty!".

I needed to explain interrupts to people that know nothing about how computers work, can you think of a better example?:

EMI has been getting a lot of blame for the Toyota problems. I speculate that the problem is an even more insidiously interrupt race condition.

Designing for EMI compliance is not new, as this simple and archaic introduction to the subject shows, from 1999: http://www.zilog.com/docs/appnotes/an_noise_imm.pdf

What those of us in the Embedded System industry want to see is the Toyota Source Code. The standard cooperate argument is that this would be a "Trade Secret", and lead to the loss of revenue if available. Perhaps. But in Toyota's case they've already lost trust and substantial amount of revenue. The only way to regain trust is an independent analysis of their software.

There are experts in such systems, like myself, that know how to look for things like improperly handled timer overflow interrupts, or other race conditions. Looking at the source code is what needs to be done, to put the issue of there being a software problem to reset. What we lack is the source code from Toyota to analyze.

Even without EMI causing problems for Embedded Systems (ECU's), there are other more subtle ways that things can go wrong with software that is not correctly written.

In any modern system there are things known as "Interrupts" running. The timing of interrupts can be tricky to those without experience. You could unknowingly create a single instruction window that last only nano-seconds, that if an interrupt falls in *exactly* the wrong place, things go bad, and do not recover. It may take exactly the right sequence of events, to fall exactly in the aberrant interrupt timing window, that is *extremely* hard to reproduce because of the timing issue.

Lets put this in a non-programming perspective:

Lets say you and a group of friends are all setting around your living room talking, drinking some healthy Green Tea. We will call this a running program. Now your two year old daughter enters the room and forcefully announces for all to hear "I got go potty!". Your conversation has been "interrupted", and unless you like it messy, you immediately stop what you are doing, put your tea down, and go service your daughter's request. Once her needs have been dealt with you return to your friends, pick up your tea and continue your conversation where you left off.

The point that your daughter makes her request is completely random in relation to the conversation that is taking place. There might be one particular spot in the conversation where handling the request could have a worse overall long term outcome, such as you just dumped boiling hot tea on someone. Such can be the timing of interrupts.

Program Runs: Chat with friends while drinking tea.
Program is interrupted: I got to go potty!
Save Program State: Pause conversation, put down tea.
Handle interrupt request: Take daughter to bathroom; need I say more here?
Interrupt ends.
Restore original program state: Pickup tea, continue conversation.

http://www.softwaresafety.net