NORDTEST METHOD

NT ELEC 031

NT ELEC 031
Approved 1999-06
1(20)

PROGRAMMABLE LOGIC CONTROLLER (PLC): VALIDATION OF PLC SAFETY CRITICAL APPLICATION SOFTWARE
Key words: PLC, software, safety critical application, validation, method

UDC 681.3.06

TABLE OF CONTENTS
1 SCOPE 1.1 General 1.2 PLC safety validation 1.2.1 Classic validation 1.2.2 Requirement partitioned validation 1.3 Validation of PLC application SW 1.4 Validation approach FIELD OF APPLICATION REFERENCES DEFINITIONS SAMPLING TEST METHOD 6.1 Principle 6.2 Equipment 6.3 Testing environment 6.4 Preconditioning of test samples 6.5 Validation procedure and data processing 6.5.1 Safety requirements specification 6.5.2 Transfer of system I/O requirements to PLC I/O requirements 6.5.3 Definition of PLC SW safety behaviour 6.5.4 Validation of application software 6.5.5 Evaluation of PLC internal safety functions 6.5.6 Black box testing of system safety functionality 6.6 Applicability 6.7 Uncertainty 6.8 Test report 6.9 Acceptance or rejection of the results 1 1 1 1 2 2 2 3 3 3 3 4 4 4 4 4 4 4 7 9 10 10 10 11 11 12 12 13 13 15 16 17 19

1 1.1

SCOPE General

2 3 4 5 6

This Nordtest report provides a method for validation of PLC safety critical application software. This means that verification of the PLC processing HW and OS must be performed as a separate task which is not covered by this method. The validation of the PLC application program is not based on well-established techniques such as EMC or climatic testing, and additional explanations may therefore be needed to clarify the tasks to be performed. In order to enhance the readability of the report, additional descriptive information or examples (not normally included in a Nordtest report) will be provided throughout the report.

1.2

PLC safety validation

Most control systems on machinery and other automated equipment or augmented control tasks are presently implemented on a programmable logic controller (i.e. a PLC). Control of the corresponding safety critical function(s) and potential hazardous operation(s) must be formally validated, and they are therefore often implemented as separate dedicated subsystems based on safety approved components. This approach requires that a separate independent (non-programmable) safety system is applied in parallel with the main functional control system, resulting in a more costly and less flexible implementation.

1.2.1 Classic validation

The use of programmable equipment for the safety function has until now been impeded by the very complex process of validating that the programmable equipment will fail to a safe state for any external I/O-fault, or internal hardware (HW) fault, including any possible fault in the computer and/or the program memory. The complexity of such a validation task is further increased by the fact that a proper validation of the system must address not only the application software, but that as much as 5 different aspects must be considered:

ANNEX A Example of test method (Test flow) A1 System context safety specification Detailed descriptions of safety functions A2 Safety function interface specification A3 Definition of PLC SW safety behaviour A4 Validation of application software A5 Black box testing of system safety functionality

Published by Nordtest Tekniikantie 12 FIN02150 Espoo Finland

Phone: + 358 9 455 4600 Fax: + 358 9 455 4272 E-mail: nordtest@nordtest.org Internet: www.nordtest.org

ISSN: 0283717X Project: 1357-97

NORDTEST METHOD

NT ELEC 031

The PLC context, i.e. all external I/O interfaces, sensors, actuators and power supply. The PLC input/output hardware providing the interface between the context and the PLC processor. The PLC processing HW (e.g. CPU, memory, timers, interrupt, watchdog) The PLC operating system (OS) often called the kernel that provides the environment for the application software, as well as a certain amount of fault handling. The PLC application software, implementing the user specified functionality for: Primary safety functionality Derived functionality to handle context fault conditions.

The validation is carried out as described in this test method, and the result will be a verdict (Compliant/Non compliant) stating the safety system's ability to comply with the actual application safety requirements.

1.3

Validation of PLC Application SW

At the present there are no clear test methods for validating that the functionality of a PLC application is compliant with all these safety requirements.

Until now, validation and assessment of software have normally been based on an indirect method, where mainly the quality of the software as a whole has been assessed. This includes the quality of the entire development process, the documentation, the SW testing, the maintainability of the SW etc. This approach will provide a clear picture of the quality of the SW, but only a limited amount of information on the systems ability to comply to system functional requirement as well as HW-derived requirements. A typical example is that some safety functions may be based on single sensor input (e.g. interlock switch). If this sensor fails, this will result in a potentially hazardous condition. The derived system requirement is that the function must be implemented with redundant sensors, and the application software shall validate that both sensors are in a safe condition before the potentially hazardous operation is allowed. This identification of derived requirements which is not provided by the normal SW quality method is vital for the total system safety and therefore included in this method.

1.2.2 Requirement partitioned validation

The general validation approach used throughout this test method is to partition the safety system validation into the following activities: I General validation of CPU/OS on the PLC

This activity is focused on validation of the safety of the PLC CPU hardware (HW) with corresponding operating system (OS/Kernel). This activity is only required once for a given type/model of a PLC, and can thus be reused in several different applications using the same CPU HW and OS. The validation method required for this activity is NOT covered by this test method, but must be based on a general HW/SW validation method such as [Nordtest 1355-97 Basic Test Method ...] or the IEC 1508 standard. The result of this validation activity is a classification of the safety behaviour of the CPU/OS for the selected type/model of the PLC. This classification can be reused for all subsequent applications of the PLC with no extra cost. Such a validation activity is inherently performed on a safety approved PLC. II Application specific validation of the safety system

1.4

Validation approach

The test method provided here is based on a step-by-step approach. Initially, the system safety requirements are identified. Based on this information and the HW safety performance of the selected PLC, the derived requirements for the PLC are identified. This information forms the basis of the requirements specification for the PLC application SW. The actual PLC application software is then compared with these requirements, through analysis as well as additional system testing. The validation of the application software is thus closely linked to the overall system requirements, and not to the actual requirements of the PLC-HW. It is based on the condition that the application software is hosted on a HW/OS platform with a known behaviour at fault. The safety validation of the HW/OS platform is therefore reduced to identification of behaviour at fault (and NOT coupled to the actual system safety requirements). This additional validation of HW/OS can be based on NT ELEC 034 or another already established HW validation method. This approach has the advantage that the system testing requirements are reduced when the application is based on a PLC platform with an established safety behaviour, i.e. the PLC specific analysis can be reused for many different applications. If a PLC with a formal safety approval (of HW and OS) is used the total amount of testing is thus reduced significantly.

These validation activities which must be performed in detail for all different projects/applications will assess the safety of the actual complete safety system based on: the PLC/OS being used (reuse of existing information as outlined in "I" above) the actual application specific selection of I/O modules the actual application specific input sensors and output actuators the process/application to be controlled.

Because of the reuse of the validation results for the CPU/ OS, the work can to a great extent be reduced to validation of safety activities specific for the actual application/project.

NORDTEST METHOD

NT ELEC 031

The method will only validate that the PLC application software is compliant to the total system safety requirements (including derived requirements). To complete the system safety validation, the application software platform (HW/OS) as well as all the external units (the context of the PLC) must be validated according to the actual safety requirements. The validation process will be based on a step-by-step approach covering: Description of the process hazard conditions that must be avoided and listing of system safety functions. Transfer of process hazard requirements to PLC-specific I/O requirements. Validation of actual I/O safety performance versus required safety performance, including identification of derived requirements. Validation of actual safety PLC Application SW functionality versus the total system requirements. Physical testing of all of the above selected critical conditions on a system simulator.

REFERENCES
Analysis techniques for system reliability. Procedure for failure mode and effects analysis (FMEA).

IEC 812

IEC 1131-2 Programmable controllers Part 2: Equipment requirements and tests. IEC 1131-3 Programmable controllers Part 3: Programming languages. IEC 1131-4 Programmable controllers Part 4: User guidelines. EN 954-1 Safety of machinery Safety related parts of control systems. Part 1: General principles for design.

prEN 954-2 Safety of machinery Safety related parts of control systems. Part 2: Validation.

4
PLC

DEFINITIONS
Programmable Logic Controller (Digital computer designed to perform process control function) Hardware (HW) and operating system (OS) of a PLC. These facilities enable the PLC to execute the application software. The HW/OS will often provide software implemented timers, counters and registers that the application program can use. The O.S. is often called the PLC kernel. Furthermore most HW/OS will include safety facilities to provide a well defined behaviour at fault ( watch-dog, self test e.g.) PLC application software; The user program installed in the PLC in order to obtain the required functionality. The program can be implemented in several ways e.g. ladder diagram, statement list, functional blocks, and high level languages (e.g. BASIC)

The validation requirements will be based on the overall safety requirements from a relevant international standard (initially the EN954-1 will be used).

HW/OS

FIELD OF APPLICATION

This validation method applies to the application program in PLC controlled systems used for safety critical functions, in machinery, automatic control systems and other systems with safety augmentation based on a PLC with a user specified application program. Examples of such applications are: Gas burners and gas furnaces. Lifts. Safety related machine control systems. PLC-AS

This validation method addresses PLC controlled applications where some or all safety functionality has been implemented in the user specified application program. The method is based on the principle of transferring global (context) safety requirements and the actual HW behaviour to safety requirements for the PLC application software. The PLC will thus provide the required safety functionality as long as the PLC is fully operational. The only remaining validation activity required is the safety validation of the PLC-HW and the PLC-SW-kernel (OS). This activity is not application dependent, and the validation effort (for a single PLC type) can thus be reused on many different applications. The test method does not cover any other properties of the HW/SW such as HW/SW maintainability, reliability, or similar quality properties. The present version of the test method is based on the system safety requirements from a single international standard (EN 954-1), as it would be too complicated and complex a task to make a check list/tables covering all aspects of all standards.

Safety Function The safety system will normally be partitioned into several safety functions each describing the safety requirements for a restricted part of the total safety system. A safety function can normally be validated as a stand-alone function, thus reducing the complexity of the analysis. Safety Category A parameter identifying the level of safety required. This parameter ranges from B, 1 to 4 and is described in detail in section 6.5.1.2.

SAMPLING

No specific sampling and sample handling procedure is required. A PLC with the required application program installed and the manufacturers documentation will be needed.

NORDTEST METHOD

NT ELEC 031

6 6.1

TEST METHOD Principle

Familiarisation and specification of safety requirements Transfer of I/O requirements to PLC specific conditions Definition of I/O safety behaviour Validation of Application software

6.5.1 Safety requirements specification

This task is partitioned into three subtasks System safety requirements definition (What are the functional safety requirements for this PLC based safety system i.e. what safety function shall be performed by the system). These requirements will normally be provided as part of the design specification for the system Definition of safety category for each safety function (the categories are analogue to the categories according to EN954-1) Detailed description of the safety functionality (for each safety function define in detail the sequence and timing of all states and state transitions).

The test is performed in the following steps:

Validation of PLC internal safety functions (refer to NT ELEC 034)

Black box testing of system safety functionality

6.2

Equipment

The PLC shall be installed in an environment simulating the actual context to be controlled. The external signals may be simulated by e.g. switches, relays, potentiometers. This setup, called a hot mock-up, will be used during system familiarisation and black box testing.

An example of the tasks required to be performed is provided in Annex A1.

6.5.1.1 System context safety specification

Define the safety specification for the system as well as for all safety functions in the system. This task can be accomplished by filling in the tables shown below.
General description The context name of the system General description of system function The overall description of the system function

6.3

Testing environment

The PLC system to be tested shall be installed in the hot mock-up described in section 6.2. The purpose of installing the PLC in a system hot mock-up is to provide an environment for the PLC-HW and the PLC application program that is as close as possible to the final environment, but still enabling the test personnel to control and monitor the PLC context, i.e. simulate system and I/O fault conditions in a controlled manner.

First safety function

Description of safety function #1

Safety category

6.4

Pre-condition of test samples

Not applicable to this test method.

The context name of A verbal description this safety function of the safety function, i.e. which hazard conditions shall be prevented

The safety category as defined in 6.5.1.2

6.5

Validation procedure and data processing

The validation is performed in a sequential manner, in several steps, where the output from one step may be used as input for one or more of the following steps. The validation is performed both as an analysis and as formal physical testing. In order to clarify the requirements in the method, an example covering all aspects of this test procedure is provided in Annexes A1 through A5.

Second safety function

Description of safety function #2

Safety category

The context name of A verbal description this safety function of the safety function, i.e. which hazard conditions shall be prevented

The safety category as defined in 6.5.1.2

NORDTEST METHOD

NT ELEC 031

6.5.1.2 Definition of safety categories (compliant with EN954-1 definitions).

Category System behaviour Example of PLC platform Standard PLC Requirements of PLC application software

The basic safety function is implemented in the PLC application SW; i.e. the PLC will perform the required safety function. A single PLC or I/O HW fault may lead to a loss of the safety function. The safety function is implemented in the PLC application SW; i.e. the PLC will perform the required safety function. A single PLC or I/O HW fault may lead to a loss of the safety function. All single hazardous I/O faults can be detected and reported by activation of a test mode.

The basic safety function shall be performed

Well-tried standard PLC plus well-tried context components

The basic safety function shall be performed

Standard PLC

This functionality is obtained through functional redundancy and monitoring/ testing of all critical input/output when the test function is activated. Any single I/Ofault condition and faults in safety functions shall be detected/reported when test mode is activated. This functionality is obtained through functional redundancy and background monitoring/testing of all critical input/output, variables, timers etc. Any single fault condition will be detected/reported by the self test function and it shall not lead to a loss of the safety function. This functionality is obtained through functional redundancy and monitoring/ testing of all critical input/output, variables, timers etc. The tests are to be performed at or before the next demand upon the safety function.

Faults in the safety functions are detected and reported during operation, by self test function incorporated in the PLC application software, or in the PLC HW/OS. Any single fault does not lead to the loss of the safety function.

Safety PLC Double/Redundant Standard PLC

Any accumulation of faults in the I/O, or PLC HW/OS shall not lead to a loss of the safety function. The safety function shall either continue safe or stop the equipment in a safe state.

Safety PLC

Categories for safety system based on a PLC system.

NORDTEST METHOD

NT ELEC 031

6.5.1.3 Detailed description of safety functions

Provide a detailed description of all safety functions. This can be accomplished by filling in tables as illustrated below.
Safety function #1 Safety category:

Main state The name of the first main state

Substate

Sub-substate

Description Verbal description of this state. Purpose of the state and conditions for switching to other states.

Substate #1 Substate #2 Sub-substate #1

Verbal description of first substate Verbal description of #1 sub-substate ..... Verbal description of #2 sub-substate ..

Sub-substate #2

The name of the second main state Substate #1 Sub-substate #1

Description.....

Description ..... Description..... ...... Description.. ......

Sub-substate #2

Substate #2

Safety function #2

Safety Category:

Main state The name of the first main state

Substate

Sub-substate

Description

The name of the second main state

NORDTEST METHOD

NT ELEC 031

6.5.2 Transfer of system I/O requirements to PLC I/O requirements

This task shall transfer the function and requirements for each external (context) interface variable to the PLC internal variable. The result will be a complete context interface specification, providing information on functional as well as safety requirements for each interface variable. The safety part of this specification will later be used to identify additional application software tasks (e.g. redundancy, validation and self test) that are required in order to fulfil the overall system safety functionality.

The input and output signals are divided into the following categories: 6.5.2.1 Discrete digital signals: This category of signals comprises the common PLC input and output signals with a single (discrete) true and a false state. Previously, they were simply called digital signals because of the resemblance to a binary signal, but with the introduction of byte oriented signals the name discrete digital is used to distinguish them from the byte oriented digital signals.

The discrete digital input can be classified as follows:

Discrete digital input Input type Description of Input types Active High The input will detect a Hi; (Off = Lo) Active Low The Input will detect a Lo; (Off = Hi) Three state The input actively detects both Hi and Lo; (Off = Fault)

Input fail safe state The input state that will make the system safe

Safe High A static Hi will prevent a system unsafe state

Safe Low A static Lo will prevent a system unsafe state

None Neither stuck Hi or Lo will prevent a system unsafe state

Both Both stuck Hi and Lo will prevent the system from entering an unsafe state

The discrete digital output signals can be classified as follows:

Discrete digital output Output type Description of Output type Active High High-side driver, or relay connected to the power input Active Low Open collector or relay connected to return/0V Push-Pull Totem pole output, or dual relay Three state Has three states High, Low, and Off

Output fail safe state An output state/value that will prevent the system from entering an unsafe state

Safe High If the output switches to Hi the system will not be unsafe

Safe Low If the output switches to Lo the system will not be unsafe

Safe OFF If the output switches to OFF the system will not be unsafe

NORDTEST METHOD

NT ELEC 031

6.5.2.2 Analog signals

This category of signals comprises the inputs used to measure an external parameter, or to control an external parameter with more than one vale (ON/OFF). There are many types of analog signals, and only the most common will be listed here. The typical analog input can be classified as follows:
Analog input Input type 010 V The input is a voltage input, and OFF condition is not well defined 020 mA The input is a current input, and OFF condition is well defined (= 0 mA) 420 mA Current input with well defined out-ofrange values (<4 mA; >20 mA)

6.5.2.3 Digital communication signals

This category of signals comprises classical digital signals. It comprises all kinds of byte-oriented signals (serial, parallel or as memory reference), versus the bit-oriented category of I/ O signals (normally called discrete digital). The category was until recently not related to the PLC application, but has become widespread with the extended use of serial I/O bus systems and multiprocessor/process PLCs.
Digital communication signal interface Digital Internal communication variable signal type Data is exchanged by use of common memory External serial variable External bus variable

Input Fail Safe behaviour

Cannot detect Open and open or shorted shorted wire input/wire hack same input value

Has capability to detect Out-Of-Range conditions

Data is exchanged as a point-to-point serial connection channel

Data is exchanged using addresses on a common bus

Analog output Output type 010 V Output varying from 0 V to 10 V. No general valid value 020 mA Output varying from 0 mA to 20 mA. No general valid value 420 mA The receiver can use in range validation to detect faults

Signal fail safe Stuck at fixed behaviour value, sgl. bit stuck

Sgl. bit stuck at converter. Channel blocked on faults. Parity check inherent in protocol

Sgl. bit stuck at interface. Channel blocked on bus failure. Parity check, CRC inherent part of protocol

Fail safe measures

Self test, read back, redundant data

Read back, Read back, redundant data redundant data

Analog input/output

Fault behaviour/handling

Under range Characteristics The value is below the define valid range

Over range The value is above the define valid range

Scale factor The sensitivity/scale factor is incorrect by ??% error Perform self test or use redundant data channel

Stuck @ value The output/ or input is stuck at a fixed value inside the valid range Use redundant data or compare with process model. Perform self test
Not likely to happen in Scanner/ multiplexer; Use self test on common A/D or D/A converter

6.5.2.4 Safety function interface specification requirements

This specification shall cover all relevant safety aspects concerning the signal connecting the PLC to the external context. The specification will normally be partitioned into an Input part and an output part. The input specification shall provide at least the following information: Input name Description Type The name of the external parameter/ sensor What is the function of the input The input type as described in 6.5.2.1 to 6.5.2.3

Test measures

Can be detected by simple outof-range test

Can be detected by simple outof-range test

Notes:

Not likely to happen in Scanner/ multiplexer; Use self test on A/D converter

Context definition What action in the context corresponds to a certain value or state on the input. Safe state What input value/state will not cause the system to enter an unsafe state

NORDTEST METHOD

NT ELEC 031

Sensor fail behaviour

How can the sensor fail providing the input signal fail (if the sensor has a certain fail mode, then there is no reason to protect against this mode in the PLC input) What is the application software variable name for this input. What is the full range of this input signal (on the PLC input) What is the valid range for this signal at the source/sensor (this information can be used for in-range validation of data) How can the actual single PLC input fail. This information shall be based on the properties of the actual selected PLC.

Variable name Signal range Valid range

What is the application software variable name for this output. What is the full range of this output signal (on the PLC output) What is the valid range for this signal at the actuator (this information can be used for in-range validation of data) How can the actual PLC output fail. This information shall be based on the properties of the actually selected PLC.

Variable name Signal range Valid range

PLC fail mode

Input fail mode

6.5.2.5 Safety function interface specification table

One of the most practical ways of providing the data required in 6.2.5.4. is to make a table with the actual information. This will allow for a great depth of details and still provide sufficient overview of the system. This paragraph provides a template for such an interface specification table, see templates at the bottom of this page.

The output specification shall provide at least the following information: Output name Description Type The name of the external signal/ function What is the function of the output The output type as described in 6.5.2.1 to 6.5.2.3

6.5.3 Definition of PLC SW safety behaviour

This task will provide an in-depth description of the safety functionality required to be implemented in the PLC application software. The result will be a specification covering: all functional states, and state transition conditions (using data from 6.5.1) state transitions at input fault condition (using data from 6.5.2) for each state all output conditions including fault and potential hazard conditions. The analysis shall also consider hazards originating outside the PLC e.g. Output driver fault as well as actuator faults.

Context definition What is the coupling between output signal and the context function. Safe state Which output value/state will not cause the system output to enter an unsafe state How can the actuator connected to the output fail (if the actuator has a certain fail mode there is no reason to protect against this mode in the PLC output)

Actuator fail behaviour

NORDTEST METHOD

NT ELEC 031

10

for each state, requirements for additional safety functionality that must be provided by the application software (input /output redundancy, self test and similar requirements). The derived requirements shall be based on the properties required by the safety category for the actual safety function. i.e. for a category B safety function there will be no derived requirements for single fault protection.

based on a set-use-matrix or any similar documentation tool for the PLC programming environment. An example of the tasks required to be performed is given in Annex 4.

The output from this task will be a complete specification of the requirements for the application software. This specification will provide the input for the validation of the application software in 6.5.4., as well as the inputs for the black-box testing described in 6.5.6. An example of the tasks required to be performed is provided in Annex 3.

6.5.5 Evaluation of PLC internal safety functions

This validation task is not a part of this test method, and the paragraph is only included to highlight the fact that the HW/ OS platform must be successfully validated before the entire system is considered as validated. The validation can be performed according to Nordtest method NT ELEC 034, or any other recognised method. The HW/OS platform shall be validated to be compliant with the I/O conditions used in 6.5.2.5.

6.5.4 Validation of application software

This part is the actual validation of the application software. The test is mainly performed by reading the detailed requirements and comparing them with the source code. The aim is to validate the functionality of the application software against the detailed requirements identified above in 6.5.3. The analysis shall comprise at least the following sub tasks: Are the states and state machines defined in the requirement, implemented? The state machine(s), as defined in section 6.5.2 shall be present in the application software, either as a formal state or as a boolean substate. Are the state transitions described in the requirements correctly performed? The algorithms and the conditions used to change state in the state machines are to be identified and documented. The transition conditions shall be unambiguous to provide safe and clear transitions between the states. Is the required functionality implemented? Identify the logic of the software. Does the software perform the specified functionality? The methods used for comparison shall provide a clear picture of the functionality. Well known specification and analysis methods such as Karnaugh Map, Functional Table, Pseudo Code or State machine shall be used. Is the required safety critical functionality, specified in 6.5.3, implemented? Does the software carry out the necessary checks to perform a correct handling of safety critical inputs and outputs (the derived requirements)? The methods used to achieve the functionality required by the safety category (redundancy, read back e.g.) shall be validated against the requirements in 6.5.3. Are the variables, timers and counters used by the safety functions correctly implemented? Confirm that all data used by the safety function are updated only in the safety functions. Noncritical functions are not allowed to write to the safety critical data. Timers and counters are not allowed to be changed or reused by non-safety-critical functions. This validation can be

6.5.6 Black box testing of system safety functionality

Functional testing aims to evaluate the external behaviour of the system and shall be seen as a complement to an analysis of the source code. This test shall mainly focus on the safety critical aspects of the system. The test is divided into four parts. An example of a test table made for a black box test according to this section is given in Annex 5.

6.5.6.1 Safety functions In this part the functionality of the software is tested. The logic functions identified in 6.5.3 are now to be validated. Each input shall be tested, one by one, and the logic is verified by studying the output state. This shall be made while the system is performing the appropriate safety critical function.

6.5.6.2 Safety related response time This test mainly focuses on reaction timing for the system in a critical situation. It shall validate the required or specified timing behaviour for the system to act when a critical state has occurred. An example can be the time consumed before an over temperature sensor used in an engine control will cause the engine to stop, or the time before the computer detects that the flame has gone out during the combustion process in a gas burner.

6.5.6.3 System behaviour at fault Failure detecting mechanisms for safety critical inputs and outputs are to be tested to confirm that the overall system safety functional requirements are fulfilled (this is required for all safety systems with a safety category higher than B). The following list shows some examples of inputs and outputs with a higher level of safety. This test shall validate that the failure detecting mechanisms can detect and react properly upon faults.

NORDTEST METHOD

NT ELEC 031

11

Type of I/O

Test

Discrete redundant input, built up by two individual inputs

The inputs are assigned to different states. The software shall detect the inconsistency and enter the predefined state.

iour of the system while the voltage is decreasing. Are there any actions which need to be taken before the system dies out? Is the brownout procedure safe?

6.6

Applicability

Discrete redundant The outputs are simulated to output, built up by different states. The system shall two individual stay/enter a predefined state. outputs Analog inputs checked by self test A self test routine which is used to test the correctness of the input. It can be an extra input connected to a defined level. Assign a false value to the test input. The software shall detect the false value and enter a predefined state. The inputs are assigned to different values. The software shall detect the inconsistency and enter a predefined state.

This test method can be used to validate PLC application software to be used for safety critical applications. The main part of the activities is based on testing by analysis and classical test parameters such as repeatability, stability etc. are therefore not relevant. This test method can only be used for validating the application software being hosted on a PLC HW/OS platform with a known behaviour at fault. It will not provide any information about the safety of the HW/OS or the host platform. The safety of the host platform should be ascertained by using a method appropriate for this purpose such as Nordtest NT ELEC 034. The test method will only provide a verdict concerning the application program's ability to perform the safety functions specified. It is not intended to cover other properties of the application program, such as maintainability, reliability, or similar quality properties.

Analog redundant input

6.5.6.4 Power interruption The system behaviour at power interruptions is tested in this part. First of all choose a worst case state for when to test the system. It might even be necessary to test the system in several cases. Four different power interruptions are to be assigned to the system; Power on, Power off, Power cycling and Brownout. Power on Power up the system. Does the system start full operation immediately or is it waiting for a signal from the operator before it is in full operation? Will the system temporarily enter an unsafe state? Compare with the result from the source code analysis. Is the start up safe? Power off Power off the system. Study the safety critical functions while the system is still alive. Are there any actions which need to be taken before the system dies out? Is the power off procedure safe? Power cycling Cycle the incoming power from full power, no power and back to full power again. The time slot where no power is given to the system shall be adjusted from a very short period of time to a time long enough to cause the system to be switched off. Study the safety critical functions to find out if the system is stable or if the system is switched off completely during the off period. Brown out Variations in the incoming power are applied by using a variable power supply. The range of variation shall start at the maximum voltage and decrease slowly down to a point where the complete system has died out. Study the behav-

6.7

Uncertainty

The main part of the activities is based on testing by analysis and classical test parameters such as repeatability, stability etc. are therefore not to be considered. When physical testing is required, a measurement accuracy sufficient to validate the actual safety function shall be used (i.e. when testing for an analog limit of 4 mA, test levels of 3 mA and 5 mA can be used. Higher accuracy will only test the conversion accuracy of the A/D converter, but will not provide any further information concerning the safety functionality). Whenever testing is performed by analysis, one of the following verdicts shall be used: Compliant (C): The application program is compliant with the requirements. The program will therefore perform as specified in the requirements when required to perform the function being analysed. The application program is not compliant with the requirements. The program will therefore NOT perform as specified in the requirements when required to perform the function being analysed. This may cause a non-allowed hazardous condition. This requirement is not applicable to the present safety function / application / safety level etc. It is not possible to provide a clear verdict concerning the ability to comply with the actual requirement. If this verdict is used, a clear explanation, stating the full requirement as well as the analysis result shall be provided in the report. This verdict shall NOT normally be used.

Non Compliant (NC):

Not Applicable (NA): Inconclusive (INC):

NORDTEST METHOD

NT ELEC 031

12

6.8

Test report

The test report shall include the following information: a) Name and address of the testing laboratory b) Identification number of the test report c) Name and address of the organisation or person who ordered the test d) Purpose of the test e) Name of manufacturer or supplier of the tested object f) Type and serial number of the tested object g) Short description of the tested object h) Date of supply of the tested object i) j) l) Date of the test Reference to this method System requirements used to develop a test specification

o) Identification of the hot-mock-up which has been used during the test p) Identification of source code descriptions, flowcharts etc. q) Version of tested software r) Test results and statement of conformance (or nonconformance) s) Date and signature of the responsible engineer.

6.9

Acceptance or rejection of the results

k) Deviations from this method m) Identification of the test equipment and instruments used n) Identification of electronic schematics, wiring diagram including context etc.

The acceptance criteria for this test method are outlined in section 6.5.1.2. These criteria are set to reflect the corresponding system requirements criteria in EN954-1. When the PLC application program is compliant to the requirements defined in section 6.5.1.2. and the PLC HW/OS compliant in accordance with the corresponding supplementary requirements, the entire PLC based safety system will be compliant with the corresponding category in EN 954-1.

NORDTEST METHOD

NT ELEC 031 ANNEX A

13

ANNEX A: EXAMPLE OF TEST METHOD (TEST FLOW)

The test method described in chapter 6 provides the formal method and the framework for the test. To assist the reader to understand the method in greater detail, an example of a PLC application software validation is provided in this example. The example does not provide the complete set of test sheets, but consists of selected parts of the test that will provide the reader with a clear picture of the real life contents of such a set of test sheets. The example for the method is based on a Gas Burner control system including an overtemperature protection. The Annex provides examples of all parts of the method. Where a certain part of the method is used several times, the examples are only provided to the extent required to illustrate the method i.e. it will only be repeated when necessary to illustrate the diversity of the method, and it will not cover the complete control system. The example covers: Annex A1 System context safety specification Detailed descriptions of safety functions Annex A2 Safety function interface specification Annex A3 Definition of PLC SW safety behaviour (Safety tables for selected subsystem) Annex A4 Validation of application software (Safety state validation) (State switching validation) (Safety functionality validation) (Fault handling validation) (Resource management validation) Annex A5 Black box testing of system safety functionality (Logic functionality) (Safety timing) (Fail detect functionality) (Power interruption)

Annex A1 Example of an overall safety requirement specification

Safety function Safety description Safety category 3

Gas burner safety The gas burner safety system system shall prevent the gas burner entering a potentially hazardous condition. In case of detection of a fault the safety system shall intercept. All interceptions from the safety system shall latch in a safe state, and it shall require a manual restart to return to normal mode. Overtemperature monitoring system The over temperature monitoring system shall limit the water temperature to < 75 C

NORDTEST METHOD

NT ELEC 031 ANNEX A

14

Example of a detailed requirement specification

NORDTEST METHOD

NT ELEC 031 ANNEX A

15

Annex A2 Example of a safety function interface specification

nput Input name Airflow Description Type of input indicate airflow into the burner Digital Discrete; ON = High Flame detect indicate combustion Digital; ON = High Gas pressure low pressure in the gas valve Digital Discrete; ON = High Boiler temp actual Analog; temperature of the boiler 420 mA 4 mA = 0C 20 mA = 160C >12 mA (80C) out of range, Boil_temp drift in range, stuck at fault Overtemp boolean Digital value from Communitemperature cation control 400-2000 High/Low/ drift/stuck at 0-2048 OFF => gas safe low pressure>limit fail Off Press_low ON/OFF NA High/Low ON = flame detected safe low fail On/Off Flame_on ON/OFF NA High/Low Context definition ON = Airflow Safe state Sensor fail behaviour fail On/Off Variable name Air_Flow Signal range ON/OFF Valid range NA PLC fail mode High/Low

safe low

NORDTEST METHOD

NT ELEC 031 ANNEX A

16

Annex A3 Definition of PLC SW safety behaviour

Two states are documented here. The other states are to be analysed in the same manner in order to cover all possible critical inputs and outputs. Example, Off state fault handling
Actual State: Off state, no heating is performed

Example, run purge state fault handling

Actual State: run purge state, the gas is purged from the combustion chamber Input transition table Gas Flame pressure detect low ON OFF X ON OFF OFF OFF OFF Overtemp X X ON OFF OFF OFF Heating Airflow X X X X OFF ON 28 next second state time-out X X X X X OFF (timer > 0) ON (timer = 0) Shutdown Shutdown Off Stop Shutdown Run Purge Ignition

X X X OFF ON ON

Input transition table Airflow Gas pressure low ON OFF OFF OFF OFF OFF X ON OFF OFF OFF OFF Flame detect X X ON OFF OFF OFF Overtemp X X X ON OFF OFF Heating next state Shutdown Shutdown Shutdown Off Off Purge
Input failure table fail High Shutdown enable Shutdown enable Off enable enable Ignition (1*) Shutdown Run Purge OFF OFF OFF OFF

X X X X OFF ON

OFF

OFF

OFF

ON

ON

Input failure table fail High Shutdown Shutdown Shutdown Off Purge

fail Low

enable Off

fail Low

enable

enable

enable

enable

Off

Output state table Gas on ReFan mark on ReIgnition Re28 mark on mark sectimeout Off (high) Off (high) On (low) safe safe safe Run Run Stop (low) Remark

Output state table Gas on Normal state Fault of output Off (low) Off (low) On (high) Remark Fan on safe safe (1*) Off (low) Brake (low) On (high) OFF Remark Ignition Remark on safe safe safe (2*) safe Off (high) Off (high) On (low) safe safe safe
Normal state Off (low) safe safe

On safe (high) Brake safe (low) (3*) On safe (high) OFF safe

safe safe (*1)

Fault of Off output (low)

(2*) On (high)

Stop safe (High)

Actuator fault

Off

safe

run stop

safe safe

Off

safe

Actuator Off fault

safe

run stop

safe safe

Off

safe

Result from the output state table will be as follows; (1*) The Gas on output must NOT fail in On state, since it will cause the combustion chamber to be filled with gas. The output must be guaranteed safe by the following technique: The output must be redundant The software must monitor the condition of the output, and If a fault is detected, the system shall switch to shutdown The self test input must be monitored. (2*) This is not considered to be a hazard condition since the fault will cause an uncommanded purge of the system, which is a safe handling. Result from the output state table will be as follows; (1*) The timer must be tested in a self test to make sure that the purging has been performed for an appropriate time. (2*) The Gas on output must NOT fail in On state, since it will cause the combustion chamber to be filled with gas. For more information see Off state, output table, on previous page. (3*) If the fan output fails in stop position, it will be detected by the airflow detector. It results in a safe handling.

NORDTEST METHOD

NT ELEC 031 ANNEX A

17

Annex A4 Example of validation of application software

State definition
State machine Gas_System State Off Purge_init Purge_run Ignition Burning_normal Burning_no_flow Burning_no_flame Stop Shutdown Overtemp Idle Active_inrange Active_overtemp Failure State variable and value Gas_state = off Gas_state = prg_init Gas_state = prg_run Gas_state = ignit Gas_state = burn_norm Gas_state = burn_no_flow Gas_state = burn_no_flame Gas_state = stop Gas_state = shutdown temp_state = idle temp_state = in range temp _state = otemp temp_state = failure Gas_System Gas_System Purge_run Purge_run Purge_run no action Shutdown IF !(Gas_on OR Flame) THEN Gas_state = shutdown IF Over_temp THEN Gas_state = Stop IF (!Heating) THEN Gas_state = Stop IF (Time_1 > 280) THEN Gas_state = Ignit (C) (NC) Airflow missing Gas_System Off Purge_init

State transition table

State transition condition State machine Gas_System Gas_System State Off Off Next state Off Shutdown Switch condition no action IF (Gas_on OR Air_flow OR Flame) THEN Gas_state = Shutdown (line # 243) IF (!Over_temp AND Heating) THEN Gas_state = prg_init (line # 256) (C) Remark (C) (C)

Gas_System

Purge_run

Off

(C)

Gas_System

Purge_run

Stop

(C)

Gas_System

Purge_run

Ignition

(C)

* Gas_state must be redundant and/or tested to be considered safe. (See variable matrix.)

NORDTEST METHOD

NT ELEC 031 ANNEX A

18

Fail Safe handling of inputs and outputs

Input/output Type Additional safety requirement Implementation Remark

Set-Use matrix of used variables, timers and counters

Variable Safety Used by critical Off Purge_init Purge_run Ignition Burning_normal Burning_no_flow Burning_no_flame Stop Shutdown Fault (bit) Yes fault_check line # 216 Set by Off Purge_init Purge_run Ignition Burning_normal Burning_no_flow Burning_no_flame Stop Shutdown Off Purge_init Purge_run Ignition Burning_normal Burning_no_flow Burning_no_flame Stop
(C)

Remark Since the variable is safety critical it shall be either redundant or checked by a self test routine Since the variable is safety critical it shall be either redundant or checked by a self test routine

Gas_state Yes
(C) IF (Man_rst1 != Man_rst2) THEN {Man_reset = 0 Fault = TRUE} ELSE Man_reset = Man_rst1 line # 456

Man_reset

Discrete Must not fail input Hi therefore redundant input

(byte)

Boil_temp

Analog input

In range test performed to achieve safety

IF (Boil_temp_in (C) < Maxrange) AND (Boil_temp_in > Minrange) THEN Boil_temp = Boil_temp_in ELSE {Boil_Temp = MaxRange Fault = TRUE} line # 468

Overtemp

Discrete Must not fail input to unsafe position, therefore redundant inputs

IF (Otemp_1 != Otemp_2) THEN {Overtemp = TRUE Fault = TRUE} ELSE Overtemp = Otemp_1 line # 372

Shutdown Idle Active_inrange Active_overtemp Failure Time_1 (timer) Yes Purge_run Purge_init (C)

Gas_on

Discrete Must not fail output to ON-state, If one output fails to ON the unit shall switch to shutdown

(C) IF (! Gas_on) THEN {{Gas_on1 = Gas_on2 = 0} IF (Gas_mon1 OR Gas_mon2) THEN Fault = TRUE} line # 490

The bit Gas_state must be redundant and/or tested to be considered safe. (See variable matrix)

NORDTEST METHOD

NT ELEC 031 ANNEX A

19

Annex A5 Example of black box testing

Test table, Logic functionality
State Gas press input OFF Flame input OFF Overtemp Heati. input input OFF OFF OFF OFF = > ON ON ON ON ON 2 sec timer OFF OFF OFF OFF Airflow input OFF OFF OFF OFF Gas output OFF OFF OFF OFF Fan output ON OFF OFF ON Ignition output OFF OFF OFF OFF Next state Initial purge Shutdown Shutdown Initial purge
according to test

Remarks (C) (NC) (INC) (NA) (C) (C) (C) (NC) Shall enter off state according to spec.

Initial purge Initial purge Initial purge Initial purge

OFF = > OFF ON OFF OFF OFF = > ON OFF

Test table, safety timing

State Purging Input Airflow ON = > OFF Combustion Flame ON = > OFF Combustion Gas press ON = > OFF Action Shutdown entered no later than 2 sec No-Flame entered in less than 0,5 sec Gas is switched off Stop-state entered in less than 0,5 sec 1500 ms (NC) Time consumed before action 1,2 sec Remark (C)

300 ms

(C)

NORDTEST METHOD

NT ELEC 031 ANNEX A

20

Test table, Power interruption

Voltage NA NA NA NA NA NA NA NA 244 V 230 V 200 V 170 V 138 V 110 V Power time NA NA 1 ms 2 ms 10 ms 50 ms 100 ms 250 ms NA NA NA NA NA NA disruption Type of power interruption Power ON Power OFF Power Cycling Power Cycling Power Cycling Power Cycling Power Cycling Power Cycling Brown out Brown out Brown out Brown out Brown out Brown out Result System starts up, and waits for master_reset Gas supply is switched off and flame goes out System stays alive, all functions in operation System stays alive, all functions in operation System stays alive, all functions in operation System stays alive, all functions in operation System switch off, Gas valve NOT switched OFF System reset and restarted again System stays alive, all functions in operation System stays alive, all functions in operation System stays alive, all functions in operation System stays alive, all functions in operation Gas valve switched off System switched off (C) (NC) (INC) (C) (C) (C) (C) (C) (C) (NC) (C) (C) (C) (C) (C) (C) (C)

Test table, Fail detect functionality

Input/Output Man_Reset (Input) Man_Reset (Input) OverTemp (Input) OverTemp (Input) Gas_On (Output) Gas_On (Output) Fault injected Man_Rst1 = OFF, Man_Rst2 = ON Man_Rst1 = ON, Man_Rst2 = OFF Otemp_1 = OFF, Otemp_2 = ON Otemp_1 = ON, Otemp_2 = OFF Gas_On1=ON, Gas_On2=OFF Gas_On1=OFF, Gas_On2=ON Result/Action Man_Reset = 0 System remains in shutdown state Man_Reset = 0 System remains in shutdown state OverTemp = ON OverTemp = ON Gas valve is off and detected by GasMon_2 Gas valve is off and detected by GasMon_1 Remark (C) (C) (C) (C) (C) (C)

NORDIC
COUNCIL OF MINISTERS