Introduction to part III - Overview of 61508

Transcription

1 to - Overview of rg> December 22, 2015

2 Outline to - to of Some of /pre-existing SW

3 intro Focus: System scope embedding functional safety Managing complexity - system context Provide Methodology of achieving tolerable risk Help you specify sound and consistent procedures Focus on generic aspects Says nothing about certification! is a basic safety standard - it is the basis for a number of application sector specific standards. No mater what derived standard you work with you should take the time to read Ed 2. to -

4 What is? A generic safety process template: procedural safety life-cylce -> safety case risk based approach (SIL/SC + ALARP) generic safety life-cycle specification guidance more than guide-lines. A major objective is to facilitate the development of application sector specific standards [-1 Ed 2 ] to -

5 scope Functional Safety Focus on a conceptually monolitic safety case Slanted towards systems of low complexity Targeting organisational, specification and design faults Limited considerations for human factors [ Note 2] Very limited considerations for security [ m)] You can t follow - it can guide you though on your path after you defined your path. to -

6 constraints System Level global safety context somewhat hardware centric no notion of failure mode (fail-safe/fail operational) slant towards low complexity PES must be heavily interpreted When you read it the first time it will seem vague, inprecise and inconsistent - and if you try to treat it as a checklist it is! to -

7 Context - reduce risk to an acceptable level: Social Economic Regulatory (National) to -

8 Context - reduce risk to an acceptable level: Social Economic Regulatory (National)...in a given context: must be reinterpreted in the specific context of its application - don t limit this to the technical aspects only. is not about a safety development lifecycle, it s about a system safety life-cycle - requirements to decommissioning. It does state requirements on the safety development lifecycle - and typically one of the fist steps will be to define eactly this life-cycle in the specific context. to -

9 Costs of faults Products with a year life-cycle Development: 20-30% Requirements 70% Design 15% Implementation 3% Integration 10% Testing 2% Maintenance: 70-80% And if you would include decommissioning some domains would have 99% of the coste there (e.g. Nuclear Power-plants - anybody have an idea how to dismantle them?) can help you save costs - if applied from the very outset of your project to -

10 Location of faults Primary cause by phase Frequ. % Inad. functional requirements specification 4 12 Inad. safety integrity requirements specification Total specification Total design and implementation 5 15 Total installation and commissioning 2 6 Inadequate operation 1 3 Inadequate maintenance 4 12 Total operation and maintenance 5 15 Inadequate modification 7 20 Inadequate de-commissioning 0 0 Total change control after commissioning 7 20 [HSE, Out of control, HSG 238, 2003] to -

11 Generic Goals Plan A - Hazard elimination to -

12 Generic Goals Plan A - Hazard elimination Plan B - Hazard mitigation to -

13 Generic Goals Plan A - Hazard elimination Plan B - Hazard mitigation Diagnostic tests can provide significant benefits in the achievement of functional safety of an E/E/PE safety-related system. However, care must be exercised not to unnecessarily increase the complexity which, for example, may lead to increased difficulties in verification, validation, functional safety assessment, and maintenance and modification activities. Increased complexity may also make it more difficult to maintain the long-term functional safety of the E/E/PE safety-related system. [-2 C.2 Note 2] All of IEC and its derived standards are only Plan B to -

14 Tollerable Risk - Definition tolerable risk risk which is accepted in a given context based on the current values of society [IEC -4 Ed ] [IEC Guide 51:1999, definition 3.7] to -

15 Tollerable Risk - Definition tolerable risk risk which is accepted in a given context based on the current values of society [IEC -4 Ed ] [IEC Guide 51:1999, definition 3.7] IEC can t say what your target risk goal is. Causes rate All causes (mid life including medical) pa All accidents (per individual) pa Accidents in the home pa Road traffic accidents pa Natural desaster (per individual) pa to - [Elsevier, Safety Critical Systems Handbook, Section 1.1]

16 Tollerable Risk - Context Different tollerable risks depending on relation to individual Context rate Employee 10 3 pa Public 10 4 pa Broadly acceptable risk 10 6 pa [HSE R2P2 - Reducing Risks, Protecting People] to -

17 Tollerable Risk - Context Different tollerable risks depending on relation to individual Context Employee Public Broadly acceptable risk [HSE R2P2 - Reducing Risks, Protecting People] rate 10 3 pa 10 4 pa 10 6 pa...and role of the individual Serious or fatal injury to a relatively small number of the occupants other than the flight crew. [RTCA DO 178C 2.3.2] to -

18 Tollerable Risk Tollerable risk is not a static property of a system it must be maintained over the lifetime of the system. initial development: to -

19 Tollerable Risk Tollerable risk is not a static property of a system it must be maintained over the lifetime of the system. initial development: reduce to atleast the specified safety target (thats what the SIL level expresses) reduce below the specified safety targets as far as economically feasible to -

20 Tollerable Risk Tollerable risk is not a static property of a system it must be maintained over the lifetime of the system. initial development: reduce to atleast the specified safety target (thats what the SIL level expresses) reduce below the specified safety targets as far as economically feasible operations: to -

21 Tollerable Risk Tollerable risk is not a static property of a system it must be maintained over the lifetime of the system. initial development: reduce to atleast the specified safety target (thats what the SIL level expresses) reduce below the specified safety targets as far as economically feasible operations: ensure the fielded systems achieve atleast the expected level. continuously strive to improve the systems safety and the organisational safety capabilities. to -

22 Tollerable Risk Tollerable risk is not a static property of a system it must be maintained over the lifetime of the system. initial development: reduce to atleast the specified safety target (thats what the SIL level expresses) reduce below the specified safety targets as far as economically feasible operations: ensure the fielded systems achieve atleast the expected level. continuously strive to improve the systems safety and the organisational safety capabilities. decommisioining: to -

23 Tollerable Risk Tollerable risk is not a static property of a system it must be maintained over the lifetime of the system. initial development: reduce to atleast the specified safety target (thats what the SIL level expresses) reduce below the specified safety targets as far as economically feasible operations: ensure the fielded systems achieve atleast the expected level. continuously strive to improve the systems safety and the organisational safety capabilities. decommisioining: extract lessons learned and feed into new developments to -

24 Tollerable Risk and SIL Why do we need the SIL concept? If risks where qunatifiable we could just use failure rates and be good? to -

25 Tollerable Risk and SIL Why do we need the SIL concept? If risks where qunatifiable we could just use failure rates and be good? What is with analysis level faults? Management faults? Methods/Tools? to -

26 Tollerable Risk and SIL Why do we need the SIL concept? If risks where qunatifiable we could just use failure rates and be good? What is with analysis level faults? Management faults? Methods/Tools? Can t quantify them! to -

27 Tollerable Risk and SIL Why do we need the SIL concept? If risks where qunatifiable we could just use failure rates and be good? What is with analysis level faults? Management faults? Methods/Tools? Can t quantify them! For those non-quantifiable risk contributions SIL/SC expresses a level of rigour that is broadly accepted to relate to the severity implied by the allocated SIL/SC level. The SIL/SC does not imply that systematic faults have a failure rate or that a set of measures/rigour will result in a specific failure rate at the system level. to -

28 Tollerable Risk and SIL Why do we need the SIL concept? If risks where qunatifiable we could just use failure rates and be good? What is with analysis level faults? Management faults? Methods/Tools? Can t quantify them! For those non-quantifiable risk contributions SIL/SC expresses a level of rigour that is broadly accepted to relate to the severity implied by the allocated SIL/SC level. The SIL/SC does not imply that systematic faults have a failure rate or that a set of measures/rigour will result in a specific failure rate at the system level. Requirements of SIL/SC strive to ensure a consistent treatment of risks at all levels (organisation,process,technology,tools/methods) to -

29 Generic Goals - Example states goals not methods Structural test coverage (statements) 100 % to -

30 Generic Goals - Example states goals not methods Structural test coverage (statements) 100 % Where 100% coverage cannot be achieved (e.g. statement coverage of defensive code), an appropriate explanation/justification should be given to -

31 Generic Goals - Example states goals not methods Structural test coverage (statements) 100 % Where 100% coverage cannot be achieved (e.g. statement coverage of defensive code), an appropriate explanation/justification should be given Plan to use GCOV with a set of test-cases. to -

32 Generic Goals - Example states goals not methods Structural test coverage (statements) 100 % Where 100% coverage cannot be achieved (e.g. statement coverage of defensive code), an appropriate explanation/justification should be given Plan to use GCOV with a set of test-cases. -7 C.5.6 Error seeding to -

33 Generic Goals - Example states goals not methods Structural test coverage (statements) 100 % Where 100% coverage cannot be achieved (e.g. statement coverage of defensive code), an appropriate explanation/justification should be given Plan to use GCOV with a set of test-cases. -7 C.5.6 Error seeding Aim: To ascertain whether a set of test cases is adequate. What ever you applie from any clause,subclause or notes from an annex the first question is what is the goal of that requiremnt/statement -> Interpretation. to -

34 Strategies as Requirements states some strategies as requirements: Some clauses are stragey recommendations not even requirements: As far as practicable the design shall keep the safety-related part of the software simple. to -

35 Strategies as Requirements states some strategies as requirements: Some clauses are stragey recommendations not even requirements: As far as practicable the design shall keep the safety-related part of the software simple. Some clauses are not requiremnts at all: The overall, E/E/PE system and software safety lifecycle figures are simplified views of reality and as such do not show all the iterations relating to specific phases or between phases. Iteration, however, is an essential and vital part of development through the overall, E/E/PE system and software safety lifecycles. to -

36 Strategies as Requirements states some strategies as requirements: Some clauses are stragey recommendations not even requirements: As far as practicable the design shall keep the safety-related part of the software simple. Some clauses are not requiremnts at all: The overall, E/E/PE system and software safety lifecycle figures are simplified views of reality and as such do not show all the iterations relating to specific phases or between phases. Iteration, however, is an essential and vital part of development through the overall, E/E/PE system and software safety lifecycles. Some clauses are formal non-compliance waifers: Provided that the software safety lifecycle satisfies the requirements of Table 1, it is acceptable to tailor the V-model (see Figure 6) to take account of the safety integrity and the complexity of the project. to -

37 Monolitic Nature of Documented DLC - highly iterative tailoring V-model iteration to -

38 Monolitic Nature of Documented DLC - highly iterative tailoring V-model iteration Consolidated CDP - monolitic view verified input/outputs for each phase Once you reached a consisten state of work (e.g. before entering service) your overall consolidated work-products forma a waterfall model and all the intermediate states are no longer visible - that ideal waterfall model is purlely monolitic and fits exactly one system. to -

39 Mitigation by procedures Systematic problem We can t quantify systematic faults of HW/SW We can quantify faults of Humans - which are very often systematic faults (e.g. lack of understanding, prejudice, confirmatory bias, ignorance..) What prevents us from deteting cause? to -

40 Mitigation by procedures Systematic problem We can t quantify systematic faults of HW/SW We can quantify faults of Humans - which are very often systematic faults (e.g. lack of understanding, prejudice, confirmatory bias, ignorance..) What prevents us from deteting cause? blame to -

41 Mitigation by procedures Systematic problem We can t quantify systematic faults of HW/SW We can quantify faults of Humans - which are very often systematic faults (e.g. lack of understanding, prejudice, confirmatory bias, ignorance..) What prevents us from deteting cause? blame The mitgation Manage it - structured approach that can be traced 2 n eye principle (minimum 4) at all steps Complet,consisten -> prcesses, procedures and methods Effective, efficient -> state of the art in engineering. Add managed competence and you have IEC to -

42 Mitigation by procedures Systematic problem We can t quantify systematic faults of HW/SW We can quantify faults of Humans - which are very often systematic faults (e.g. lack of understanding, prejudice, confirmatory bias, ignorance..) What prevents us from deteting cause? blame The mitgation Manage it - structured approach that can be traced 2 n eye principle (minimum 4) at all steps Complet,consisten -> prcesses, procedures and methods Effective, efficient -> state of the art in engineering. Add managed competence and you have IEC The root-cause is that our meager brains can t handle the complexity of the systems we are building. to -

43 Principle It s simple - almost trivial... Achieving and Maintaining an acceptable level of risk by: to -

44 Principle It s simple - almost trivial... Achieving and Maintaining an acceptable level of risk by: Risk assessment to -

45 Principle It s simple - almost trivial... Achieving and Maintaining an acceptable level of risk by: Risk assessment Risk elimination to -

46 Principle It s simple - almost trivial... Achieving and Maintaining an acceptable level of risk by: Risk assessment Risk elimination Residual Risk Mitigation to -

47 Principle It s simple - almost trivial... Achieving and Maintaining an acceptable level of risk by: Risk assessment Risk elimination Residual Risk Mitigation Effective Risk Monitoring...a bit hidden. No system is risk free - but every system must stay in the tollerable range. to -

48 Flow -> Define system -> Identify potential hazards -> Map to risks -> Derive SIL requirement(s) for system -> Apply appropriate methods -> Deriove SIL requirement(s) for decomposition -> Apply appropriate methods -> Justify risk mitigation (safety case) -> Monitor the system - verify your claims to - This path is followed by all derived standards inside a framework for functional safety management. Note that it does not depend on the component being /OSS or bespoke.

49 System Safety to -

50 Types of Safety Inherently Safe to -

51 Types of Safety Inherently Safe Reactive Safety fault detection fault reaction self-check requirements to -

52 Types of Safety Inherently Safe Reactive Safety fault detection fault reaction self-check requirements Composite Safety fault tolerance detectability through isolation availability issues does not differenciate betwee fail-safe/fail-silent/fail-operational - it is a very generic process. to -

53 Functional Safety Architecture HW architectural protection: Redundancy/Replication HFT 1: 2oo2...NooM relevance of random errors (types) SIL/SC level [ /11] to -

54 Functional Safety Architecture HW architectural protection: Redundancy/Replication HFT 1: 2oo2...NooM relevance of random errors (types) SIL/SC level [ /11] Diversity: types of diversity effects of diversity safety case based on diversity [-6 Ed 1 Appendix E] The architecture is an essential component in SW safety. to -

55 (SW) -4 Definitions (global) Clause 5/6 Doc/Management (global) Development of Requirements (<- Part 5) 7.6 Allocation of safety functions 7.10 Implementation -> -2,-3-6 guide to application of -2/3-7 Methods is not a simple standard as it has strong horizontal and vertical linking of clauses. You must develop your path! to -

56 phase structure IEC -1 Ed 2 Phases 1-5 address analysis and requirements development (technology independent) Phases address realisation: planing, HW and SW Phases address operation and de-commissioning. IEC > -2 IEC > -3 Part 1 focus on the broader system aspects and supporting process, part 2 focusses on the system implementation and part 3 on software aspects. to -

57 (SW) to -

58 -3 Overview Functional Safety of software for E/E/PES safety related systems Tightly coupled to -2 Software is never maintained only modified [ ] Anything using an OS or libraries qualifies as high-complexity Previously developed software == Ed 2 provides relatively well defined routes for. FLOSS ==? pre-existing software: software developed prior to the application currently in question, including (commercial off-the shelf) and open source software [EN Ed ] to -

59 -4/5/6/7 provides the methods necessary to handle - notably -6 Appendix E gives a based SIL3 system concept overview! 4 - Definitions 5 - Guidance in assigning SIL 6 - Guidance in applying -2, Approved methodologies The problem is that too many engineers simply do not read it - your safety can t read it for you... to -

60 Safety Management Problem: Fault -> Error -> Failure -> Hazard -> Accident : Hazard identification is the key to functional safety management in and derived standards. Hazards are not limited to technical hazards -> organisation, methods, processes, tools... The main worry of functional safety management is to preserve consistency - this is in my opinion the main reason for the dominance of the monolithic safety model. Humans are very bad in finding inconsistencies in compex systems - a structured and traceable aproach is currently the only defence we have. to -

61 Safety Integrity Level (SIL) Discrete level (one out of a possible four) for specifying the safety integrity requirements of the safety functions to be allocated to the E/E/PE safety related systems, where safety integrity level 4 has the highest level of safety integrity and safety integrity level 1 has the lowest [ ] risk reduction needed to achieve acceptable risk level defined for continuous and low demand mode Note not all derived standards define SIL4! : if analysis results in SIL4 requirements -> go fix your system design [ IEC -1 Ed ] Safety Integrity Level can be assigned by quantitative or qualitative methods [-5]. to -

62 Safety-related (component) Safety-related electronic control system: Electronic control system of a machine who s failure can result in the immediate increase of the risk(s) [ ] Subsystem: Entity of the top-level architectural design of the SRECS where a failure where a failure of any subsystem will result in the failure of a safety related control function. [ ] Module: routine, discrete component or a functional set of encapsulated routines or discrete components belonging together [ ] to -

63 Diversity Types of diversity software: N-version programming hardware: different HW-platforms usage: diversity of access temporal: diversity of env-state level of diversity organisational specification (procedural vs. rule-driven) Selection (i.e. libraries, servers) implementation (i.e. languages) integration (i.e. compiler, generators) Diversity can address some of the worries of. to -

64 Options for SW 1 S Compliant development 2 S Proven in use 3 S Non-compliant development (pre-existing software) Note that pre-existing software does not mean pre-dating the standard but rather: pre-existing software: software element which already exists and is not developed specifically for the current project or safety-related system. [IEC -4 Ed ] to -

65 Proven-in-use Evidence - not specified clearly Route 2 S : compliance with the requirements for evidence that the equipment is proven in use [-2 Ed ] Requirements for proven in use elements [-2 Ed ] Field experience [-7 Ed 2 B5.4] Proven-in-use [-7 Ed 2 C ] In case of tools - Increased confidence from use [-3 A3 4b)] Especially the derived standards have a quite varying interpretation of evidence and multiple terms for. Proven-in-use is not going to be your main strategy for any complex component/system. to -

66 Softwares role in safety As far as practicable the design shall minimize the safety-related part of the software.[ ] constraints on software: Architectural constraints (HW) [ ] Probability of dangerous random HW failures [ ] Requirements for systematic SIL (SILCL) [ ] is a derivative for the Machine sector. This is well in line with Ed to -

67 previously developed software - Ed 1 if standard or previously developed software is to be used as part of the design then it shall be clearly identified. [-3 Ed ] The software suitability in satisfying the specification of requirements for software safety (see 7.2) shall be justified. [-3 Ed ] Suitability shall be based upon evidence of satisfactory operation in a similar application... [-3 Ed ] or having been subject to the same verification and validation procedures as would be expected for any newly developed software [-3 Ed ] Constraints from the previous software environment shall be evaluated [-3 Ed ] This is very strongly reflected in EN Ed 1 (Rail signaling) to -

68 previously developed software Ed 2 Route 3 S (pre-existing software elements only): compliance with the requirements of IEC -3, [ ] Route 3 S assessment of non-compliant development. Compliance with [-3 Ed a)] provide a safety manual (see Annex D of IEC -2 and Annex D of this standard) that gives a sufficiently precise and complete description of the element to make possible an assessment of the integrity of a specific safety function that depends wholly or partly on the pre-existing software element. [-3 Ed b)] to -

69 Route 3 S Requirements a) documented software safety requirements b) satisfies the objectives of -3 c) documented design d) evidence includes the hardware e) evidence of systematic V&V f) side-effect freedom of dead code g) credible failures have been identified h) well defined configuration i) satisfaction of safety manual constraints Note that this is really very much simplified - more on this later to -

70 Ed2 Concluding Remarks Read it first - take your time How: part 1 (with part 4 and 7 on your desk) part 5 part 2 (with part 4,7 and 1 on your desk) part 3 (with part 4,7 and 1 on your desk) part 6 Make sure all engineers involved in the safety related project read it (CM, QA, testers, coders, managers, piza-deliverer...) The big problem - no fast route into - if you don t have the time in your plan - don t do safety. to -