Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Practical design tips for safety-critical software

Posted: 07 May 2014     Print Version  Bookmark and Share

Keywords:embedded systems  IEC 61508  safety-critical software  processor 

Embedded systems may need to comply with a variety of safety standards based on the market and intended use. These standards can also outline requirements that need to be met based on international standards. Standards such as ones based on the International Electrotechical Commission (IEC) attempt to develop a common set of requirements so that each individual country and/or market doesn't have completely separate requirements.

First, this paper outlines some various ways that the safety requirements for the system can be understood. It includes customer interaction, competitive intelligence, and professional assistance.

Second, it covers the basics of the IEC 61508 document standard, and the concept of safety integrity levels. There is also an explanation of how faults in an embedded system can lead to errors, and how these can lead to failures. The progression of these failures and their possible multiple instances is also discussed.

Finally, also discussed are some of the various system architectures and their designs. Each is based on the safety integrity level of the overall system, and each is discussed for their applicability to embedded systems.

Which safety requirements?
One of the most important aspects of developing safety-critical software is determining which requirements and standards are going to be followed. Depending on the newness of either your product or the intended market, you may need to get outside help to determine what standards need to be met. Consider following the steps below to aid in your safety certification effort:

Step #1—Customer interaction: If you are entering a new market, the intended customer probably knows the starting point for which safety requirements need to be met. They may be able to provide information on the safety standards that a similar product already meets. If the end customer is just using the product without a lot of technical background, then this step should be skipped.

Step #2—Similar product in same intended market: It may be more straightforward to see what safety requirements and standards a similar product meets. For instance, if your company or a partner already sells a medical device to the same market, and your product is similar, this may be a good place to start.

Step#3—Competitive intelligence: Doing basic research on the Internet or from freely available open information from marketing materials may help determine a good starting point as well. Often, paperwork needs to be filed with agencies on which specific standards were met.

Step #4—Professional assistance: Each market or market segment normally has agencies or contract facilities that can aid in determining which standards need to be met. Paying a little up front, especially after gathering necessary information from steps 1-3 above, will help make this particular step pay off in the long run.

After gathering this information, you should have a good idea about which standards need to be met. During this investigation, also determine whether or not it is a self-certification activity, a standardised assessment activity, or a full- fledged independent assessment certification.

For the sets of requirements that need to be met, the team should develop a strategy and initial analysis of how they could comply with the requirements and which IEC 61508 SIL safety level should be required.

What EC 61508 requires
One of the more commonly used standards for the design, implementation, and maintenance of a safety-critical system is maintained by the International Electrotechical Commission (IEC). The standard covers all kinds of industries and isn't specific to a particular one. It defines a characterisation called "the equipment under control" or EUC. For the EUC, it further stipulates that the process to develop it, its usage, and maintenance can impact how safety-related risk can be reduced.

The origins of the standard come from the process control industry, and specify a safety life-cycle of sixteen phases categorised as follows:
Phases 1-5: Analysis
Phases 6—13: Design and implementation
Phases 14—16: Operation and maintenance

The definitions of risk and safety function are also specified in the standard. A risk is a function of the likelihood and severity of any event that can happen within the EUC. A safety function reduces the risk, by either reducing the severity of the event or reducing the likelihood of the event. The standard drives home the fact that there can never be a zero risk system – our only option is to manage those risks with safety functions.

Faults, errors, and failures
A fault is a characteristic of an embedded system that could lead to a system error. An example of a fault is a software pointer that is not initialized correctly under specific conditions, where use of the pointer could lead to a system error. There are also faults that could exist in software that never manifest themselves as an error, and are not necessarily seen by the end user.

An error is an unexpected and erroneous behaviour of the system that is unexpected by the end user. This is the exhibited behaviour of the system whenever a fault or multiple faults occur.

An example could be a sub-process that quits running within the system from a software pointer that is not initialized correctly. An error may not necessarily lead to a system failure, especially if the error has been mitigated by having a process check to see if this sub-task is running, and restarting it if necessary.

1 • 2 • 3 Next Page Last Page

Comment on "Practical design tips for safety-cri..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top