System Design According to ISO/EN 13849-1:2006

We are currently in the transition period where EN ISO 13849-1 replaces EN 954-1:1997. On the 30th December 2009 all safety systems should be designed in accordance with EN ISO 13849 part 1 and 2 or other ‘Functional Safety’ safety standards like IEC 62061 and IEC 61508. If all of these standards are unfamiliar to you then the easiest place to start is EN ISO 13849-1.

EN ISO 13849-1:2006 uses the category system (from EN954-1) many of us are familiar with but expands on it using other pieces of data that are relevant to the performance of a safety system.

SISTEMA

You can download SISTEMA from the BGIA website for free. This software tool is designed by the authors of the standard. It is aimed at helping you organise and document your workings for EN ISO 13849-1:2006. The following link will take you to the download load:

No guidance has been written for this software yet. Please contact us if you need help working with this tool. We may be able to arrange some tuition on this subject.

The standard provides a simplified categories-based procedure for estimating the PL. The intention behind this approach is to provide a recognizable transition path from the original Category based standard to the Performance Level based 2006 version. The standard gives five designated architectures as shown below. They correspond to the existing five Categories B, 1, 2, 3 and 4. These diagrams must be studied carefully in clause 6 of the standard where the requirements, differences, and assumptions are explained. The architecture diagrams for Categories B and 1 and also 3 and 4 may look the same, but the standard explains the detail differences in terms of their requirements including diagnostic coverage, etc. Figure 1 to figure 3 show block diagrams of the 5 category architectures.

It will also be helpful to study Structures of Safety Related Systems in this publication which discusses the Categories in detail with practical examples of their implementation.

The standard provides a simplified categories-based procedure for estimating the PL. The intention behind this approach is to provide a recognizable transition path from the original Category based standard to the Performance Level based 2006 version. The standard gives five designated architectures as shown below. They correspond to the existing five Categories B, 1, 2, 3 and 4. These diagrams must be studied carefully in clause 6 of the standard where the requirements, differences, and assumptions are explained. The architecture diagrams for Categories B and 1 and also 3 and 4 may look the same, but the standard explains the detail differences in terms of their requirements including diagnostic coverage, etc. Figure 1 to figure 3 show block diagrams of the 5 category architectures.

It will also be helpful to study Structures of Safety Related Systems in this publication which discusses the Categories in detail with practical examples of their implementation.

Figure 1: Designated architecture for Category B and 1

Figure 2: Designated architecture for Category 2

Figure 3: Designated architecture for Category 3 and 4

Mission time represents the maximum period of time for which a subsystem (or system) can be used. After this time, it must be replaced. Mission time must be declared by the manufacturer of the components. Mission time will usually be the same as the proof-test interval as used in IEC/EN62061. The safety system designer must then consider the mission time of the components to determine the mission time of each safety function.

MTTF_d (Mean-Time-to-Dangerous Failure) Is used directly in ISO 13849-1:2006 as part of estimating the PL. The standard offers three methods to determine the MTTF_d: 1) use Manufacturer’s Data, 2) use Annexes C and D which provide component failure rates, or 3) use a default value of 10 years. Selecting the default value restricts the range to Medium as shown in Table 18.

When the safety system involves interfacing with IEC62061, the MTTF_d number must be converted to PFH_D. This is done by using the following relationship:

PFH_D = 1 / MTTF_d

And, for electromechanical devices:

MTTF_d = B10_d/(0.1 x mean number of operations per year).

The MTTF_d and PFH_D will usually be derived from the same source of test or analysis data. For low-complexity electromechanical devices, the failure mechanism is usually linked to the number and frequency of operations rather than just time. Therefore, for these components, the data will be derived from some form of lifetime testing e.g., B10 testing. Application based information such as the anticipated number or operations per year is then required in order to convert the B10_d or similar data to MTTF_d.

Diagnostic coverage (DC) represents the effectiveness of fault monitoring of a system or subsystem. DC is the ratio between the failure rate of detected dangerous failures and the failure rate of total dangerous failures.

ISO/EN 13849-1:2006 and IEC 61508 provide tables that can be used in deriving the DC, and in some cases, the DC may be provided by manufacturers.

Common-cause failures (CCF) occur when multiple faults resulting from a single cause produce a dangerous failure. These are failures of different items, resulting from a single event. The failures are not consequences of each other. Annex F of ISO/EN 13849-1:2006 provides a simplified qualitative method for determining the CCF. Table 19 shows a summary of the scoring process.

A score of at least 65 must be achieved to claim conformance to Categories 2, 3, and 4.

The standards have requirements for the control and avoidance of systematic failure. Typical types of possible systematic failure are software design errors, hardware design errors, and requirement specification errors.

Systematic failures differ from random hardware failures which are failures occurring at a random time, typically resulting from degradation of parts of hardware. Annex G of ISO/EN 13849-1:2006 describes measures for the control and avoidance of systematic failure.

When the design criteria are evaluated, the SRCS will be assigned a Performance Level. The performance level is a discrete level that specifies the ability of the safety related parts of the control system to perform a safety function.

In order to assess the PL achieved by an implementation of any of the five designated architectures, the following data is required for the system (or subsystem):

• MTTF_d (mean-time-to-dangerous failure of each channel)
• DC (diagnostic coverage)
• Architecture (the category)

Figure 4 shows a graphical method for determining the PL from the combination of these factors. Table 21 shows the tabular results of different Markov models that created the basis of this Figure 4. Refer to the table when more precise determination is needed.

Figure 4: Graphical method to determine PL

The reader will notice there is some overlap at the PL division lines. If MTTF is only provided in categorical terms (as low, medium or high), use Figure 5 to determine the PL.

Figure 5: Simplified graphical method

For example, an application uses the Category 3 architecture. If the DC is between 60% and 90%, and if the MTTF_d of each channel is between 10 and 30 years, then according to Figure 5, PLd is achieved.

Other factors must also be realized to satisfy the required PL. These requirements include the provisions for common cause failures, systematic failure, environmental conditions and mission time.

If the PFH_D of the system or subsystem is known, Table 20 (Annex K of the standard) can be used to derive the PL.

Subsystems that conform to a PL can be combined into a system using Table 20. The rationale behind this table is clear. First, the system can only be as good as its weakest subsystem. Second, the more subsystems there are, the greater the possibility for failure.

In the system shown in Figure 6 the lowest Performance Levels are at Subsystems 1 and 2. Both are PLb. Therefore, using Table 20, we can read across b (in the PLlow column), through 2 (in the Nlow column) and find the achieved system PL as b (in the PL column). If all three subsystems were PLb the achieved PL would be PLa.

Figure 6: Combination of series subsystems as a PLb system

Validation plays an important role throughout the safety system development and commissioning process. ISO/EN 13849-2:2003 sets the requirements for validation for systems designed to the original ISO 13849-1 (EN 954-1). It is anticipated that this standard will be revised to bring it in line with EN ISO 13849-1:2006 of systems designed to ISO/EN 13849-1:2006. Validation in ISO 13849-2 calls for a validation plan and discusses validation by testing and analysis techniques such as Fault Tree Analysis and Failure Modes, Effects and Criticality Analysis. Most of these requirements will apply to the manufacturer of the subsystem rather than the subsystem user.

At the system or machine commissioning stage, validation of the safety functions must be carried out in all operating modes and should cover all normal and foreseeable abnormal conditions. Combinations of inputs and sequences of operation must also be taken into consideration. This procedure is important because it is always necessary to check that the system is suitable for actual operational and environmental characteristics. Some of those characteristics may be different from the ones anticipated at the design stage.

One of the primary analysis tools for safety systems is failure analysis. The designer and user must understand how the safety system performs in the presence of faults. Many techniques are available to perform the analysis. Examples include Fault Tree Analysis; Failure Modes, Effects and Criticality Analysis; Event Tree Analysis; and Load-Strength reviews.

During the analysis, certain faults may be uncovered that cannot be detected with automatic diagnostic testing without undue economic costs. Further, the probability that these faults might occur may be made extremely small, by using mitigating design, construction and test methods. Under these conditions, the faults may be excluded from further consideration. Fault exclusion is the ruling out of the occurrence of a failure because the probability of that specific failure of the SRCS is negligible.

ISO13849-1:2006 allows fault exclusion based on the technical improbability of occurrence, generally accepted technical experience and the technical requirements related to the application. ISO13849-2:2003 provides examples and justifications for excluding certain faults for electrical, pneumatic, hydraulic and mechanical systems. Fault exclusions must be declared with detailed justifications provided in the technical documentation.

Fault exclusion can lead to a very high PL. Appropriate measures to allow this fault exclusion must be applied during the complete mission time. It is not always possible to evaluate SRCS without assuming that certain faults can be excluded. For detailed information on fault exclusions, see ISO 13849-2.