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

Basics of software standards compliance

Posted: 04 Mar 2015 ?? ?Print Version ?Bookmark and Share

Keywords:security assessment? safety-critical software? IEC 61508? Risk Reduction Factor? Safety Integrity Levels?

The roots of IEC 61508 are in industrial control systems. The concept of functional safety encapsulated within the standard is based on the idea that a safety-related system is independent of the Equipment under Control (EUC), including its control system. Where industrial control is concerned, this is reasonable; systems tend to be built of generic components from multiple vendors that are brought together to achieve a specific function.

For example, consider a label applicator tunnel on a conveyor belt as the EUC. The label applicator control system ensures that each label is applied to a carton passing through the tunnel via a robot arm. However, the control system lacks awareness of whether any person can get in harm's way by putting an arm into the tunnel to clear a jam. The protection system in this case might be based on a light curtain that ensures that the label applicator or the conveyor is stopped whenever an operator's arm breaks the curtain.

Because it covers hardware as well as software, IEC 61508 also addresses the issue of reliability. This is a key concept for hardware components, but software safety requires more than simple reliability, hence the need for the standard.

Like other safety-related industry standards, when it comes to safety objectives IEC 61508 does not present an approach for eliminating risk, but instead seeks to reduce it to an acceptable level. As a result, every project starts with a risk assessment to determine any risks associated with the EUC. The probability of each risk occurring then defines what Risk Reduction Factor (RRF) is required to bring the risk to below tolerable levels, from which Safety Integrity Levels (SILs) are then determined per the table below. The maximum RRF required determines the SIL for the whole system:

The SIL is then carried forward throughout the rest of the development process. Developers not only have to achieve the safety goals for their given SIL, they have to prove that the safety goals are met.

Traditional risk reviews have not included network security, but this is changing. Many of the communications protocols on which industrial control system instrumentation rely are Ethernet based, and there is a growing list of associated security threats that create additional risk to those systems. For example, one of the most widely used architectures in industrial control is called SCADA (Supervisory Control and Data Acquisition). Increasingly, the communication between SCADA end-points is moving towards Ethernet-based solutions, and a quick search on the Internet for "SCADA Vulnerabilities" reveals how many known risks are associated with SCADA communications over Ethernet.

Other safety-critical industries have industrial standards in which the risk of failure is determined at the start of the project. The avionics community, for instance, uses the DO-178C document from Radio Technical Commission for Aeronautics (RTCA) as the reference for developing safety-critical avionics systems. DO-178C requires that development start by determining a software level, from Level A to Level E, which reflects the impact that a system failure can have on the aircraft as a whole. The more likely a system is to cause a catastrophic condition for the aircraft, the higher the assigned software level. Systems whose failure can have a catastrophic impact on safety are assigned Level A, and those systems that have no impact on safety are assigned Level E. Similar to IEC 61508, target system failure rates are associated with each DO-178C software level.

Once an SIL is determined for a system, there is a level of development rigor required to ensure that the SIL objectives are met. Although many companies still attempt to manage this manually, the easiest way to monitor this is with life-cycle management tools that capture the SIL and trace the development rigor used throughout the development process. Auditors can use this verification traceability to audit compliance and grant certification.

Figure 1: TBmanager, a requirements traceability tool from LDRA, provides visibility into the linkages between high-level requirements and how they are traced through the development process to lower level requirements, source code, unit tests, system tests, and their associated results. (Click on image to enlarge)

There are two types of tool that shine in this arena. The first focuses on requirements traceability (figure 1). These tools link requirements to all the other components in the development process from models to lower level requirements, source code, unit tests, system tests, and their associated results. With the ability to associate each phase of system development to specific individuals, these tools help to ensure that the system safety objectives flow through the entire software development life cycle.

?First Page?Previous Page 1???2???3?Next Page?Last Page

Article Comments - Basics of software standards complia...
*? You can enter [0] more charecters.
*Verify code:


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

Back to Top