Service & Support. Questions and Answers about the Proof Test Interval. Proof Test According to IEC FAQ August Answers for industry.

Size: px

Start display at page:

Download "Service & Support. Questions and Answers about the Proof Test Interval. Proof Test According to IEC FAQ August Answers for industry."

Della Casey
6 years ago
Views:

1 Cover sheet Questions and Answers about the Proof Test Interval Proof Test According to IEC FAQ August 2012 Service & Support Answers for industry.

2 Contents This entry originates from the Siemens Industry Online Support. The conditions of use specified there apply ( Go to the following link to download this document. Caution The functions and solutions described in this article confine themselves predominantly to the realization of the automation task. Furthermore, please take into account that corresponding protective measures have to be taken in the context of Industrial Security when connecting your equipment to other parts of the plant, the enterprise network or the internet. Further information can be found in Entry ID:! !. Question What actions are required for carrying out the proof test in particular when nonsafety-certified hardware components are involved in performing the safety functions? Answer Follow the instructions and notes listed in this document for a detailed answer to the above question. Contents 1 Questions and Answers about the Proof Test Interval What Is to be understood by "Proof Test"? Why is the Proof Test important? What is tested by a Proof Test? What must be considered when working with non-safetycertified Hardware Components? How often must the Proof Test be carried out? How is the Proof Test carried out in Practice? Scheduled Phases before the Proof Test Carrying out the Proof Test... 8 Safety Integrated Page 2/11 Proof-Test-Intervall

3 1 Questions and Answers about the Proof Test Interval 1.1 What Is to be understood by "Proof Test"? In a safety-relevant application the safety-relevant electrical control system (SRECS) must be in a state that guarantees the specified safety integrated level from the point of view of risks. The proof test is the test to be carried out to confirm this in the end. Errors or deterioration in a subsystem of the SRECS might be recognized during the test. If this is the case, you must take measures for the subsystem to return the SRECS to a state that is as close as possible to the "as new state". In any case the specified safety integrated level must be proven to be reestablished and guaranteed. As long as this is not the case the proof test is not concluded and the safety-relevant application is not be put back into operation. The proof test interval is included as T 1 in the formula of the basic subsystem architectures of IEC for calculating the dangerous failure rates. 1.2 Why is the Proof Test important? The proof test discovers dangerous errors not found by the diagnostics. The failure rate of a dangerous failure λ D is proportional to the value of the proof test interval T 1: λ T D 1 This means: The smaller the proof test interval, the less the probability of a dangerous failure ( PFH = λ h ). D D 1 Safety Integrated Page 3/11 Proof-Test-Intervall

1.3 What is tested by a Proof Test? The safety-relevant electrical control system (SRECS) executes the safety-relevant control function (SRCF) in compliance with IEC 62061.

4 1.3 What is tested by a Proof Test? The safety-relevant electrical control system (SRECS) executes the safety-relevant control function (SRCF) in compliance with IEC The SRECS consists of subsystems; the subsystems consist of one or more subsystem elements. A proof test tests a complete subsystem and not separate components (subsystem elements), unless the subsystem consists of just one subsystem element. The user defines the subsystems. If individual hardware components have proof test interval specifications, it is useful to group these individual components together in groups (like Sensor and F-AI, for example). Since the necessary tests are repeated, you can reduce the time for testing and documenting. Possible subsystem elements: Electromechanical components (contactors, relays) Less-complex electronic devices that have a predefined behavior (SIMATIC IO modules, for example) Complex electronic devices (SIMATIC PLC, for example) In each case testing of the subsystem is limited to the functions that are actually involved in the safety function. Safety Integrated Page 4/11 Proof-Test-Intervall

5 Example: A safety-relevant analog value to be captured for the application is shown digitally for further processing from a measuring range of 4mA to 15mA. The module that reads in the analog value has a possible measuring range of 4mA to 20mA and 0V to 10V. The proof test tests the measuring range of 4mA to 15mA. It is not necessary to test the measuring range of 15mA to 20mA in addition. Likewise it is not necessary to test the measuring range of 0V to 10V that is not used at all in the application. Furthermore, the usability of the diagnostics is to be tested regardless of whether They are implemented by default in the system (passivation of F IO, for example). They are parameterized (parameterization of the certified F blocks from the library of distributed safety, for example). They are programmed (programming plausibility check in the F program of the F CPU, for example). The diagnostics is also to be implemented to test the error reaction and whether it functions correctly after a diagnostics result. Safety Integrated Page 5/11 Proof-Test-Intervall

6 1.4 What must be considered when working with nonsafety-certified Hardware Components? It is not always possible to configure a subsystem exclusively with safety-certified components. In the case of non-safety-certified hardware components you must first decide whether or not they are involved in the safety function. Only if this is the case are they Subsystem elements of the subsystem and thus Part of the proof test. In the case of non-safety-certified hardware components that are involved in the safety function you must take additional measures. These include the following: Additional diagnostics (plausibility considerations, for example) Redundant configuration to increase the hardware failure tolerance (HFT) Diversity (recommended) of the redundant hardware Utilization of diverse hardware Utilization of different measuring ranges: 4mA to 20mA and 0V to 10V Unlike safety-certified components the non-safety-certified hardware components do not have characteristic values like Failure rate with dangerous errors (λ D ) or Probability of dangerous failure per hour (PFH D ) However, for standard calculations in compliance with IEC 62061, these values are also required for the non-safety-certified hardware components involved in the safety function. These values can be inferred from the MTBF (Mean Time Between Failure) value: 1 λ D = and PFH D = λ D 1h 2 MTBF The MTBF values for SIMATIC products are available in this entry: You will also find additional information about MTBF in this entry. Safety Integrated Page 6/11 Proof-Test-Intervall

7 1.5 How often must the Proof Test be carried out? In many cases, for organizational reasons, the proof test interval is coupled with the revision cycle of a plant (during company vacation shutdown, for example). It might be useful, for example, to carry out the proof test also on other subsystems although they are not yet scheduled for proof testing. This avoids downtimes and ensuing non-availability of the plant. However, such a revision interval must always be less than the shortest proof test interval of a subsystem element. The values for the proof test interval must be specified by the manufacturer. The most convenient case is when a subsystem consists exclusively of safetycertified components. In such cases, you can have proof test intervals of up to 20 years. To assess a Performance Level (PL) the ISO standard assumes a working life of 20 years. For safety-certified components with a proof test interval of 20 years this means that no proof test is necessary (working life = proof test interval). At the link below you will find a list of safety-certified components with their proof test intervals. Basically the following holds: The hardware component (subsystem element) with the smallest specified value for the proof test interval determines the proof test time for the subsystem. There are no proof test interval specifications for non-safety-certified hardware components. The following holds if they are involved in the safety function: The proof test interval is one year ( T1 = 1a ) for the subsystem in which the non-safety-certified hardware component is located, unless there are specifications for the working life or the MTBF of less than one year. In this case the specifications for that working life or that MTBF would hold. After carrying out the proof test, the non-safety-certified hardware component does not necessarily have to be replaced. Safety Integrated Page 7/11 Proof-Test-Intervall

8 1.6 How is the Proof Test carried out in Practice? Scheduled Phases before the Proof Test Configuration phase Since the proof test is designed to discover dangerous errors, this aspect should be taken into consideration already in the configuration phase of the SRECS and its subsystems. You can do this by ensuring in the configuration phase that Test ports are provided for carrying out the proof test later. The documentation includes instructions for carrying out the proof tests. These should also already include a classification of the test results (which lead to the passing/failing of the test). Verification The verification is a component of the configuration phase and includes the analyses and tests for the subsystems of the SRECS. The results achieved are compared with the specified setpoints of the development phase. The tests during the verification are defined by the manufacturer of the subsystem. Therefore, the verification includes tests which do not differ essentially from those of the proof test. The following holds: The analyses and measures for the subsystems of the SRECS during the verification phase correspond to a proof test carried out for the first time Carrying out the Proof Test Preparation Before carrying out the test you must clean the hardware of the subsystem to be tested and make a visual check of the configuration. Dust must be removed with a vacuum cleaner and not with a blower. Elements in the subsystem (tanks, silos, motors, etc.) must be checked for leaks (excessive dirt deposits?). The connection fastness must be checked (cables, couplings, etc.). A check list for these preparatory activities should be made and included in the proof test documentation. Safety Integrated Page 8/11 Proof-Test-Intervall

9 Testers The proof test can be carried by one or more testers. The testers who carry out the proof test must be people who Have sufficient know-how in safety engineering. However, it is not absolutely necessary that the proof test be carried out by a qualified safety engineer. However, the safety engineering know-how and therefore the suitability of such persons for carrying out the proof test must be documented, for example, through A job description Specific professional experience Proof of successfully completed advanced training Were not directly involved in designing the safety function in order to ensure the greatest degree of neutrality and unprejudiced when carrying out the proof test Regardless of the design and implementation of the safety function. Regardless of other persons, departments and positions. The responsibilities must be made clear (testers, department). Test equipment used The test equipment used for the proof test (scales, multimeters, etc.) must be in proper working order. To ensure this, you must calibrate the equipment at regular intervals. The calibration of test equipment must comply with the requirements of ISO Companies that are certified in compliance with ISO 9001 or wish to be certified must have proof of such a calibration process. Independent of the requirements of ISO 9001, companies not certified in compliance with ISO 9001 must also present proof that the test equipment used for the proof test is adequate and suitable. Error lists Errors determined in the proof test must be documented in error lists. These error lists must include Measures for clearing errors. Documented arguments for the case of error exclusion. It is recommended to have different error lists (per product, technology, etc.). Safety Integrated Page 9/11 Proof-Test-Intervall

10 Documentation All the points mentioned so far in this chapter (check list for the preparation, testers, test equipment and error lists) are part of the proof test documentation. The proof test documentation is mandatory! Furthermore, the points below are to be featured in the documentation. Specifications for testing the safety functions Operating modes during testing Performance criteria (triggering of safety function after x milliseconds, for example) Procedure descriptions (for example, value x 1 set, key x 2 pressed, function x 4 tested with test device x 3 ). Error diagnostics and correct error reaction Operating and ambient conditions (to prove that the test environment is comparable with the operating and ambient conditions). Analysis of all relevant errors (through FMEA (failure mode and effect analysis, for example)). The documentation must be complete, consistent, easy to understand and traceable. Archiving All results and documentation (in particular that mentioned above under "Documentation") of the proof test must be archived (plant log book, for example). It is not absolutely necessary to have (additional) archiving in paper form, but this is very practical in many cases. In the end, it is up to the user to decide under the particular conditions. It is obligatory to retain the documentation for as long as the controller is operated in the plant. Proof test interval and replacement of hardware components If a safety-certified hardware component has a specification for a proof test interval or if a time for a proof test interval can be derived for a non-safety-certified hardware component through specification of the working life or the MTBF, then the following holds: The proof test is not carried out for a hardware component, but for a subsystem of an SRECS in compliance with IEC If a proof test is due, not necessarily all the hardware components (subsystem elements) have to be replaced. After successful completion of the test, it is permitted to continue using these hardware components (even non-safetycertified components but which are involved in the safety function). It is known and must be taken into consideration in each case that certain subsystems and/or subsystem elements (in particular electromechanical components with a high utilization factor) require replacement within the proof test interval of the SRECS. Furthermore, subsystem elements are to be replaced on the occasion of the proof test if their service life (or specified MTBF) is less than the period of use until the next proof test. Safety Integrated Page 10/11 Proof-Test-Intervall

11 Example: MTBF=3a; previous period of use: 2a; Proof test interval=2a The subsystem element must be replaced in the proof test, because: MTBF < previous period of use + proof test interval PFD/PFH values VDI 2180 and IEC provide formulas for calculating the PFD and PFH D values in which these values depend on the proof test interval T 1. If a required safety integrated level (SIL) cannot be attained (because the PFD or PFH D values are too high), reducing the T 1 might help to attain that required SIL. Safety Integrated Page 11/11 Proof-Test-Intervall

Safety Manual. Process pressure transmitter IPT-1* 4 20 ma/hart. Process pressure transmitter IPT-1*

Safety Manual. Process pressure transmitter IPT-1* 4 20 ma/hart. Process pressure transmitter IPT-1* Safety Manual Process pressure transmitter IPT-1* 4 20 ma/hart Process pressure transmitter IPT-1* Contents Contents 1 Functional safety 1.1 General information... 3 1.2 Planning... 4 1.3 Instrument parameter