The two separate aspects of RAC validation: Why they need to be considered together

Transcription

1 The two separate aspects of RAC validation: Why they need to be considered together George Bearfield Head of Safety Knowledge and Planning RSSB RAC-TS Workshop Lille 26 th June

2 Premise The purpose of the RAC-TS functional failure rate number is its use in the context of the development processes that align with it. Application of these processes will improve your confidence in the system integrity but not guarantee any particular rate. Therefore we need to be looking at validating the RAC- TS rates, and harmonising the Codes of Practice to demonstrate that an appropriate approach to meeting them together

3 The problem The problem that needs to be addressed, with respect to application of a risk based approach, is: how to allow a manufacturer to be able to demonstrate to a project and member state that safety related functions of their system have acceptable functional failure rates.

4 The problem This question has two parts: What functional failure rate criteria would be considered to be acceptably safe if met in practice? What methods and approaches to specification, design, build and test of a technical system and its functions will give us the best possible confidence that functions meet each required failure rate?

5 The problem The part that we are currently trying to address is: What functional failure rate criteria would be considered to be acceptably safe if met in practice? What methods and approaches to specification, design, build and test of a technical system and its functions will give us the best possible confidence that functions meet each required failure rate?

6 The problem The part that we are currently trying to address is: What functional failure rate criteria would be considered to be acceptably safe if met in practice? What methods and approaches to specification, design, build and test of a technical system and its functions will give us the best possible confidence that functions meet each required failure rate? This is a problem, because both parts need to be considered together

7 Some basic RAMS fundamentals.. Lets start with the simplest bit..hardware.

8 Some basic RAMS fundamentals.. Reliability prediction, based on the manipulation of failure rate data, involves so many potential parameters that a valid repeatable model for failure rate estimation is not possible. Thus, failure rate is the least accurate of engineering parameters and prediction from past data should be carried out to provide relative comparisons in order to make engineering decisions concerning optimum redundancy Dr David J Smith, Reliability, Maintainability and Risk, 6 th Edition, Butterworth Heinemann.(2001)

9 Some basic RAMS fundamentals.. So: the purpose of the number is to support the development process It only makes sense in the context of the wider RAMS program It is very inaccurate as an estimate..ok so what about software? (NB: SIL would generally be applied at a lower level than RAC-TS, however a SIL allocation might arise from the use of the RAC-TS where sub-systems were prone to systematic failure)

10 Some basic RAMS fundamentals.. SIL levels link risk assessment to appropriate development processes. Risk Assessment S I L Development process Diagram from: Understanding the Use, Misuse and Abuse of Safety Integrity levels, Felix Redmill.

11 Some basic RAMS fundamentals.. however, the development processes used, however good, appropriate and carefully adhered to, do not necessarily lead to the achievement of the defined SIL (rate). And, even if in a particular case they did, the achievement could not be proved Understanding the Use, Misuse and Abuse of Safety Integrity levels, Felix Redmill.

12 Also Unless one states the standard that forms the context of a reference to SILs, misunderstandings can arise. Further if the recipient of the information is unfamiliar with the standard in question, confusion is almost guaranteed

13 Lessons So in summary, when considering either random failures (generally hardware) or systematic failures (typically software): The purpose of a number is its use in the context of the development processes that align with it. Application of these processes will improve your confidence in the system integrity (but not guarantee any particular rate of functional failure)

14 Question: If we identify a set of functional failure rates that would be considered safe if met in practice, but we publish them without the associated development processes, what do you fear would happen?

15 What should we do? We need to also focus on part (ii) of the question: What functional failure rate criteria would be considered to be acceptably safe if met in practice? What methods and approaches to specification, design, build and test of a technical system and its functions will give us the best possible confidence that functions meet each required failure rate?

16 Harmonising Codes of Practice Risk-based approach Codes of practice describing the approach to design, build, test exist e.g. : EN , International standard IEC61508 These processes incorporate the use of quantitative failure rate criteria as part of a broader design and development process. What other approaches are used in practice? These codes of practice are most appropriate ro E/E/PE systems and novelty

17 Harmonising Codes of Practice Compliance based approach There are also Codes of Practice which describe technology/system specific: design solutions engineering calculations and analysis testing approaches In this case: The RAC-TS is not needed Application of these approaches, where they exist, should be the preferred approach. Coordination of our work with those closing open points on the TSIs is therefore needed.

18 Revisiting the Premise The purpose of the RAC-TS functional failure rate number is its use in the context of the development processes that align with it. Application of these processes will improve your confidence in the system integrity but not guarantee any particular rate. Therefore we need to be looking at validating the RAC- TS rates, and harmonising the Codes of Practice to demonstrate that an appropriate approach to meeting them together

19 Summary Therefore two aspects to RAC validation: what functional failure rate criteria would be considered to be acceptably safe if met in practice? What methods and approaches to specification, design, build and test of a technical system and its functions will give us the best possible confidence that functions meet each required failure rate? i) and ii) need to be considered together as they are intrinsically related. We need to also understand what Codes of Practice are applicable for a compliance based approach to safety demonstration (links to TSI open point work).

20 Question? How should we approach the primary aspect of validation? What methods and approaches to specification, design, build and test of a technical system and its functions will give us the best possible confidence that functions meet each required failure rate?

21 Question? How do we align our work with a compliance based approach to safety demonstration?