5.                  USER'S GUIDE DISCUSSION

5.1.            Validation methodology for SRCES

To deal with the validation of SRCES, functional steps should be processed in the recommanded order of operations as follows :

• Obtain the allocation of safety requirements. Update the safety planning as appropriate during SRCES development.
• Determine the requirements for SRCES, including the safety integrity requirements, for each safety function. Allocate requirements to software.
• Start the phase of planning for SRCES validation.
• Access the architecture (configuration) for the SRCs logic system, sensors and final elements.
• Review with the software supplier/developer the hardware and software architecture and the safety implications of the trade-offs between the hardware and software. Iterate if required. The methodology for software validation is split into six main levels :
  • The first step is to make certain that software specifications are in compliance with user needs and safety requirements. Ensure that all necessary information for functions are complete, precise, explicite, coherent and correct.
  • The second level of evaluation corresponds to moving from specifications via the software design to the final code ; the final code must be in compliance with the software specifications.
  • The third level of evaluation, corresponding to moving from the final code to the software behaviour, consists in executing the final code to check the software behaviour.
  • The fourth level of evaluation consists in making certain that the final code is in compliance with the user needs. For the same reasons as those expressed for the first level of evaluation, which are inherent to the nature of the user needs, this compliance is very difficult to demonstrate.
  • The fifth level of evaluation, corresponding to moving from specifications to software behaviour, consists in checking that the software behaviour is in compliance with what is described in the specifications. This activity was previously referred to as verification.
  • Finally, the sixth level represents the total validation activity.
• Develop a model for the hardware architecture dedicated to safety-related systems. Develop this model by examining each safety function separately and determine the subsystem (component) that will be used to carry out this function. Deterministic and probabilistic analysis are required.
• For deterministic approach, two methods are generally employed to predict common mode faults :
  • Fault Tree Analysis (FTA), this deductive method starts out from a dangerous system failure, determined for instance by risk analysis, and looks for combinations of events that could lead to this failure. It reveals random, systematic and common mode faults. Ultimately, all the logic branches of a FTA must be developed through to the basic events. In practice, the tree is developed to be capable of analysing the effect of input, processing and output failures.
  • Failure Mode and Effect Analysis (FMEA), This is an inductive method that starts out from failures of the functions or components of the system to be analysed in order to determine the dangerous failures that could affect it. It highlights failures due to single failure modes that affect the software or the hardware.
• Use FMEA and Markov models for probabilistic approach. These techniques have been chosen because of their considerable capability of handling many of the technical features usually implemented in modern safety devices. Especially with Markov modelling, periodic events like online tests can be modelled quite comfortably.
• Establish the system parameters for each components used in the complex electronic safety-related systems. For each of the components, determine the following :
  • the mean time to restoration ;
  • the diagnostic coverage ; and
  • the probability of failure.
• Create a reliability model for each of the safety functions that the SRCES is required to carry out.
• Implement the design of the SRCES. Select measures and techniques to control systematic hardware failures, failures caused by environmental influences and operational failures.
• Integrate the verified software onto the target hardware and, in parallel, develop the procedures that users and maintenance staff will need to follow when operating the system.
• Together with the software developer, validate the SRCES. The purpose of safety validation is to check that all safety-related parts of the system meet the specification for safety requirements. Safety validation is carried out according to the safety validation plan. As a result of the safety validation, it is possible to conclude that the safety related system meets the safety requirements since all the safety requirements are validated. When discrepancies occur between expected and actual results it has to be decided whether to issue a request to change the system, or the specifications and the corresponding possible fiels of applications. Also, it has to be decided whether to continue and make the needed changes later, or to make changes immediately and restart the validation process in an earlier phase.

Finally, SRCES should also comply with generic safety requirements :

• Electrical safety.
• Electromagnetic compatibility : susceptibility and radiation is required by the European EMC directive.
• Environmental compatibility.
• Climatic and mechanical stress.
• Quality management in production, test field and revision handling. This is particularly important for software based systems.

5.2.            What we cannot answer

From the research undertaken in this project, some limitations, sometimes inherent to the nature of the faced problems, need to be summarized :

• A fixed mapping of the safety integrity levels of IEC 61508 to the categories of EN954-1 could not be established. This is primarily due to the category definitions in EN954-1 not placing any quantifiable requirements regarding the rate of failure of the safety functions.
• The non-hierarchical structure of EN 954-1’s categories is often misinterpreted into a hierarchical one. This is because the category definitions have to be carefully analysed to understand their full meaning. An informative annex interpreting the categories for different technologies may be useful.
• IEC 61508 covers all phases of equipment’s life from concept through to decommissioning. In the machinery sector, very rarely would one party have responsibility across the entire lifecycle. It is considered that there is a need to delineate responsibilities. This is particularly so in the case of manufacturers who are producing machines or safety components for use in a variety of applications where it may not be practical for the manufacturer to undertake a complete hazard and risk analysis and identify suitable safety functions for all applications at an early stage in the safety lifecycle. In such cases the emphasis must be on the manufacturers to supply sufficient and suitable information (including the SIL) so users can take proper account of the equipment’s performance characteristics in the final application.
• There is a large difference between software development practices and theoretical works which treat the subject. It is difficult to elaborate an operation safety methodology for small and average sized companies. Organisational restriction, and more particularly the lack of operation safety culture, greatly complicate the elaboration of an operation safety process. There are no specific software safety specification tools for small size applications.
• Complex components are indeed so complex that it is difficult to analyse them thoroughly, and it is very difficult to predict the failure modes of the components. Also, the inner programs related to programmable components may contain critical errors. All these reasons cause some uncertainty related to the analysis of the complex components. A single complex component alone cannot control a safety function safely enough, and some redundancy, diversity and/or monitoring is needed. This means that the architecture of the control system is of major importance and it can make the risks caused by complex components to become negligible.
• The increasing complexity of new systems (integrated function, processing speed, components and assembling technology miniaturisation, etc) is complicating largely the execution of tests late in design (e.g., in validation). Structural tests will not get to go in depth and will be applied more and more to external layers, what supposes a process of functionalization or change to more functional testing. These obstacles, are forcing to apply design techniques that make easier further testing of circuits and programs (so called, testability techniques), and direct testing from a physical to a simulation domain.
• Physical fault injection at pin level and Software implemented fault injection techniques has shown to be the most interesting techniques for fault injection into prototypes of programmable electronic systems. Each technique allows to introduce a subset of all potential faults in a system, so tester will have to choose the technique and plan the test properly depending the specific set of faults to emulate. Software implemented fault injection arises as a better option for emulating transient and precise internal faults, unlike Physical fault injection at pin level that allows to emulate, in an easier way, stuck at faults at data, address and control lines. However, it is difficult to say in what extent one technique cover the other because fault emulation capability of these techniques depend largely on the nature of the system and its load.
• Generally, existing safety-related electronic control systems for machinery have not been designed using the guidance contained in IEC 61508 and, as a consequence, suitable documentation, required in order to verify the various safety lifecycle stages, is not likely to be available. Documentation, in a form suitable for assessment purposes, will become available only when IEC 61508 derived standards like draft IEC 62061 gains credibility in machinery manufacturers. Until this time, it could be difficult to carry out assessments of safety-related electronic control systems at machinery, especially in relation to the quantitative analysis. This report intends to encourage manufacturers to fill this gap in the near future and to issue the step-by-step needed documentation in the course of the development of new safety products.