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

(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 26th _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?

(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?

• This is a problem, because both parts need to be

(7)

Some basic RAMS fundamentals…..

(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, 6th _{Edition, Butterworth}

(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.

Diagram from:

‘Understanding the Use, Misuse and Abuse of Safety Integrity levels’, Felix Redmill. Risk Assessment Development process S I L

(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”

(12)

confusion is almost guaranteed”

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

(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. :

– EN50126-129, 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)

• Therefore two aspects to RAC validation:

• 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).

– 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?

(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?