Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Create safety certified code for industrial systems

Posted: 14 Jul 2015 ?? ?Print Version ?Bookmark and Share

Keywords:industrial automation? real-time operating system? RTOS? IEC 61508? system-on-chip?

As industrial automation becomes more pervasive, there is an unprecedented need for safety-certified code. To compound the issue, industrial device software complexity is increasing at an alarming rate along with the costs associated with device certification. A real-time operating system (RTOS) with a light-weight process model and power management framework C along with the utilisation of a Trusted Execution Environment (an embedded hardware technology) can assist software developers in reducing code complexity and limiting costs when developing industrial embedded systems.

The demand for increasing amounts of software presents significant challenges for software developers as they strive to develop devices that meet the IEC 61508 safety certified standard. The software design selected, which comprises both safety critical and non-safety critical applications, can have a direct impact on the reduction of system complexity and overall certification costs. Knowing which parts of the code are which is an important design consideration.

Obtaining safety integrity level certification for a device requires software documentation and testing for every line of critical code in the system. Because this comes at a significant cost, only the safety-critical code should be certified. Designing the software so the certified applications are separated from the non-critical applications is a necessity to keep software certification costs down.

Certified and non-certified code
One option for software developers is to partition certified software from non-certified software. This is done by developing two different hardware sub-systems: one sub-system to execute the certified applications, and a second sub-system for non-certified applications. While effective, this approach has several drawbacks including added hardware costs; additional testing; and increased space, weight, heat, and power consumption.

An alternative to the dual sub-system approach is consolidating both the safety critical and non-safety critical applications onto a single system-on-chip (SoC). Clearly, there are advantages to developing a mixed-criticality system on a single module. For such a design, issues to be considered include:

???Partitioning for safety assurance
???Sharing for efficient resource usage
???Certified applications/tasks must be guaranteed system resources
???Non-certified applications/tasks given best possible service
???Assurance that the behaviour of non-certified applications will not adversely impact the behaviour of certified software
New processors now on the market allow for the consolidation of a rack or multi-CPU system into a single small card. These new processors offer enough power to run both the safety certified and non-safety certified applications. They also offer provisioning for space and resource partitioning and can contain failures in the non-certified application to prevent any impact on a safety critical application.

Mixed criticality systems
A software framework designed for "mixed criticality" provides software developers with the option to use a single hardware module to execute both certified and non-certified applications. More sophisticated software frameworks include a certified hypervisor or an ARINC653 certified operating system (OS), of which, both are very good for heterogeneous operating system designs. However, for many devices, these options add unnecessary complexity to the software development and come with a cost of increased testing and documentation.

1???2???3?Next Page?Last Page

Article Comments - Create safety certified code for ind...
*? 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