Can you afford not to certify your control system?

Mikael Åkerholm, Rikard Land, Christian Strzyz

Introduction

Industrial vehicles typically contain heavy moving parts which obviously may harm people if they do not behave as intended, or if they do not properly protect people. At the same time electronic control systems are responsible for more and more of the core functionality in the vehicles, e.g., engine control, braking, and steering; and the functions performed by the vehicles, e.g., buckets, cranes, or drills. Thus, it should be no surprise that legislative and standardization authorities around the world currently increase the pressure on vehicle manufacturers to comply with safety standards for their electronic systems, e.g., the updated EU machinery directive, (EU Directive 2006/42/EC) planned to take legal effect at the end of 2009, the safety standard for earth moving machinery (ISO15998) from 2008, the safety standard for the safety-related parts of machinery (ISO13849) from 2006, the safety standard for programmable electronic control systems in machinery (IEC62061) from 2005, the general standard for safety related electronics (IEC61508) from 2005, and the upcoming safety standard for road vehicles (ISO26262).

The whole safety area for electronic control systems may at first seem an insurmountable number of additional requirements to comply with. Nevertheless, there is not really any other choice than to work according to these standards. Even when there are no strict legislative requirements, the market will most certain gradually increase expectations on products to be certified according to the relevant safety standards, and it will be a competitive advantage to do so. Furthermore, among other advantages, following established safety standards may be the lifesaver in case of a lawsuit. And, in the end, it must not be forgotten that these requirements have been formulated in order to protect the safety of machine operators and the public. Thus, although these safety standards will imply extra development activities, one must have the attitude that these are not a burden which can be compromised in order to meet budgets and delivery deadlines.

So, what do the standards require in general?

In general the approach to demonstrate adherence to safety standards of modern electronic control systems in all types of industrial vehicles consists of both quantitative and qualitative evidence. The standards mandate a life cycle model where risk analysis is performed early in the project, where the main potential hazards involving the control system and a target level for the safety are determined. These levels are typically called Safety Integrity Level (SIL in ISO15998, IEC 61508, IEC62061, ISO26262) or Performance Level (PL in ISO13849) in the standards. All later activities in the life cycle are heavily influenced by this initial determination of the SIL or PL.

The quantitative part of the safety evidence consists of hardware reliability figures, i.e. the failure rates (sometimes called λ or MTTF(d)) for devices, channels, safety functions and related metrics like Safe Failure Fraction (SFF) and Diagnostic Coverage (DC). The overall design must be analyzed and the resulting probability of failure must meet a certain level, depending on the SIL or PL stipulated by the standard. This can be a fairly time-consuming but straight-forward process consisting of calculating the reliability figures of the design components, choosing suitable circuits for which such (high MTBF) figures are available or can be calculated. Since higher protection levels imply lower failure rates, usually redundant circuitry is used to build parallel channels which tolerate single faults within the system. Several safety standards even constrain the architecture to be used as a relation between the 3 parameters safety level, SFF/DC, and Hardware Fault Tolerance (Category), e.g., IEC61508-2 (table 3) and ISO13849-1 (figure 5).

Qualitative evidence is also needed as part of the total evidence handed to certifying authorities. The safety standards cover many practices in the systems entire life-cycle which must be appropriately addressed, e.g., how requirements are handled and traced in the development process, how the system is designed and programmed, how the potential safety hazards are analysed and handled, what compilers and development tools that are used, which test strategies to use, and how the system is planned to be maintained. This part also includes managerial issues such as using staff with appropriate skills. And in order to be presented as evidence, all this has to be appropriately documented. The strategy is to document every evidence so that it can contribute to the final safety case (or safety file), which purpose is to prove that the planned safety integrity level is actually reached by the means and measures applied during product realisation.

It should be clear that safety cannot be assessed later on the basis of the developed product. This holds particularly for the software in the system which has to be treated mainly qualitatively: software behaviour is discrete, and a seemingly small difference in input may cause it to behave quite differently. Thus, reliability and predictability, and thus safety, can never be shown statistically for software. It is a well-known principle that software testing can only reveal errors; it cannot prove their absence.

The following items give a brief overview of the main important standards for industrial vehicle control systems.

• The updated machinery directive - EU Directive 2006/42/EC, originally planned to replace the old directive at the end of 2009, is an example of how the EU forces manufacturers to comply with safety standards. The updated directive contains clarifications in its first paragraph regarding the range of machines the directive applies for, which is machines, replaceable equipment, safety components, lifting devices, chains and wires, mechanical power transmissions, and partly completed machines. The directive then clearly puts requirements on the control system for the covered range of machines to be constructed and manufactured so that hazardous situations are avoided. This implies that faults in the control systems hardware, and software, shall not lead to hazardous situations. It also implies that foreseeable faults in the handling of the machine shall not lead to hazardous situations.
  
  
• IEC61508 - from 2005 is a general safety standard not applying for a specific domain, the domain is safety of electronic programmable systems in general. Many of the more domain specific standards, e.g., the other standards introduced in this summary article, are highly influenced by or refers to IEC61508. The standard divides the level of risk reduction in Safety Integrity Levels (SIL)  1-4, where 1 is the lowest level and 4 the highest that the standard handles.
  
  
• ISO13849 - dated 2006 is a standard that is harmonized against the new machinery directive (2006/42/EC). It can be seen as a direct replacement to the old and outdated EN 954-1, which was harmonized against older versions of the machinery directive. The standard is built around a quantification of the level of risk reduction that is reached denoted Performance Levels (PL) a-e, where a is lowest and e represents the highest level of risk reduction equivalent to 61508 SIL 3.  In a clear extension to its predecessor EN 954-1, in 13849 safety relevant software is covered as well. However, for software of the highest criticality level, PL e, the standards refers to the means and measures of the generic IEC61508.
  
  
• ISO15998 - from 2008, covers safety-related machine-control systems in earth-moving machinery and its equipment. This is the segment of machines primarily designed to perform excavation, loading, transportation, drilling, spreading, compacting or trenching of earth, rock or other materials. The standard can be said to be more flexible as it refers to alternative standards, for risk assessments to ISO 14121 or IEC 16508-5, for software to ISO13849-1 or 61508-3, and for HW mainly to 61508-2 Annex A and B.
  
  
• IEC62061 - from 2005, is also a standard that is harmonized against the new machinery directive. The standard covers safety related development of control systems in machines, both hardware and software. Furthermore, the standard covers integration of sub-systems conforming to the main general safety standard IEC61508. The standard divides the level of risk reduction in Safety Integrity Levels (SIL)  1-3, where 1 is the lowest level and 3 the highest that the standard handles.
  
  
• ISO26262 – is the standard for road vehicles, planned to be released in 2010/2011. The standard is influenced by IEC61508, and harmonized against several laws and directives applying for road vehicles within EU, e.g., for braking - ECE 13 H, and for steering - ECE 79. The standard divides the level of risk reduction in Automotive Safety Integrity Levels (ASIL)  A-D, where A is the lowest level and D the highest that the standard handles. ASIL D roughly matches SIL 3 in IEC61508.

And put into practice

In this section we briefly illustrate how functional safety can be applied in practice. Fundamental to all safety standards is that safety has to be addressed during all life-cycle phases, from early analysis, throughout design, implementation, production, maintenance and decommissioning, also taking into account human aspects such as training of developers as well as of users. All safety standards therefore specify a reference process model, which essentially specify how certain tasks are performed before others in an integrated project. This reference process model is usually some kind of V-model. In Figure 1 we illustrate how an existing iterative development process based on the Rational Unified Process (RUP) have been successfully tailored to a hybrid development process. The figure shows how the steps in the V-model can be mapped to the different RUP phases Inception, Elaboration, Construction, and Transition. The arrows pointing leftwards in the V-model normally means that an error found in a testing activity requires going back to an earlier previous requirements or design activity, but it is also possible on the lower levels to let them represent iterations. The following bullets exemplify the most important safety related deliverables in the different phases:

• Inception – One of the most important safety related artifacts is “the safety plan”. This document outlines a plan for the how the requirements of the applicable safety standard is approached by the project. This plan can to a large extent be made to a generic plan for how a company approaches safety, but with some sections specific for each project, e.g., planned set of documents, personnel assigned to certain project roles, and a brief introduction of the system that is planned to be developed. The goal should be to get an agreement with the certifying authority that adherence to the safety plan will result in a certifiable deliverable from the project. The safety plan will preferably refer to a set of corporate guidelines, each defining how different safety related tasks will be performed during the project, e.g., Requirements Management Guideline, Hazard Analysis Guidelines, Design Guidelines for Hardware and Software, Coding standard, Printed Circuit Board (PCB) CAD Guideline, Verification & Validation Guideline, Traceability Guideline, Change and Configuration Management Guideline and more.
  
  
• Elaboration – The “safety requirements specification” and the “preliminary hazard analysis” are the most important safety related artefacts in this phase. The purpose with the preliminary hazard analysis is to explore the risks with the planned outcome from the project that may lead to hazardous situations, and to define additional safety-requirements that counteract these situations. This preliminary analysis can only be established using appropriate domain knowledge and field experience, the composition of team and reviewers is thus of great importance. A structured approach, e.g., a Failure Mode Effects and Criticality Analysis (FMECA) shall be used for the analysis. For the safety requirements, it is of greatest importance that the requirements are very well specified, e.g., it is mandatory in many safety standards to provide a specification beyond natural language with some formal or semi-formal requirements management method and diagrams or figures. Furthermore architectural decisions are important with respect to safety; the architecture must support a good separation of safety functions and non-safety related functions as well as meet any requirements (from safety standards) on redundancy. Estimations of the impact of hardware architecture on the system reliability figures should also be used to guide decisions.
  
  
• Construction - During construction detailed hazard analysis should be performed in order to determine how realization details impacts safety. According to our experience suitable methods are Fault Tree Analysis (FTA) or Failure Modes, Effects and Diagnostic Analysis (FMEDA). Static analysis of, e.g., source code and PCB, and finalization of the system reliability figures are other important safety related artefacts.
  
  
• Transition – This phase is a matter of conducting the tests, and performing the final safety assessment. For the testing it is often, depending on the target SIL och PL, important to be able to demonstrate some metrics, e.g., coverage criterion for the source code, completeness of the requirements-based testing etc.     

Figure 1, A hybrid process model based on an iterative RUP-based process and the V-model mandated by safety standards.

Conclusions

We have provided a short summary and introduction of the current most central directives and standards in the area of safety for industrial vehicles and machines. We hope that the introduction can be useful for actors just entering the area of safety, and also have a calming effect regarding the work that has to be done. In the end safety is about building better and more reliable systems. If you think safety is too expensive for your organization - Try an accident!

Mikael Åkerholm, PhD, works as chief software platform architect at CC Systems. Besides this role he is also involved in research on safety critical systems at Mälardalen Univeristy in Sweden.

Rikard Land, PhD, works as software specialist at CC Systems. He also holds a senior lecturer position at Mälardalen University where he is involved in research on safety critical systems and teaches software engineering.

Christian Strzyz, MSc, is in charge of CC Systems internal safety work. Christian has a solid experience in the area from his eight years as safety assessor at Tüv in Germany.