5 Safety Handbook - SIL3
For the development of a function with a required safety integrity level SIL 3, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.
SIL3 Required Safety Integrity SIL 3
MANAGEMENT/GENERAL
Independent of development (System, HW or SW) the following rules have to be followed for development in compliance with required SIL 3:
-
Project management
- Definition of actions and responsibilities; scheduling and resource allocation
- Project monitoring; configuration management (CM), and software support tools for CM.
-
Safety planning
- Definition of methods, techniques, actions and responsibilities; training of relevant personnel; consistency checks after modifications
- Validation independent from design; standardized validation procedure; configuration management, software support tools for CM.
-
Modification
- Impact analysis
- Re-verify changed modules
- Re-verify affected modules, by regression tests
- Revalidate the complete system or
- Regression validation
- Configuration management
- Data recording and analysis [A7]
- Forward traceability between SW safety requirements and the SW modification plan [A37]
- Backward traceability between SW modification plan and SW safety requirements [A37]
-
Documentation
- Graphical and natural language descriptions, e.g., block diagrams, or flow diagrams.
- Guidelines for consistent content; computer-aided documentation management, and formal change control.
SYSTEM & HARDWARE – PHASE 1 to 7
Note: the following definitions of the requirements are valid for a SYSTEM. This includes software as well as hardware.
PHASE 1 - Requirements definition
- Requirements Spec.
- Structured specification, i.e., hierarchical separation described (using computer-aided engineering tools); automatic consistency checks; refinement down to functional level.
- Separation of safety and non-safety E/E/PE (This can be done by naming convention) [A6]
- Checklists (Checklists for reviews)
- Computer aided specification tools [A6]
- Observance of guidelines and standards [A6]
- Forward traceability between the system safety requirements and the software safety requirements [A37]
- Backward traceability between the safety requirements and the perceived safety needs [A37]
For further explanation of the above-mentioned techniques, measures and related Guidelines refer to the ABB approach to IEC 61508 Ed2, Design ref [A6].
PHASE 1 - Verification activities: Task: to verify the correctness and completeness of the output documents of PHASE 1
Technique/Measure:
- Inspection of the specification
- The safety requirement specification shall be inspected by an independent person or organization.
- The checklist “Review of Safety Requirement Specification; “Checklist for Reviews” ref [A8].
- → No specific guidance document.
Test equipment to be used:
- Checklist
- No test equipment for this phase. The only equipment used is the “Checklist for Reviews” ref [A8], checklist “Review of Safety Requirement Specification”
Test documentation:
Further details of validation tests to be performed shall be described in a test plan
- Validation test descriptions: Product Type Test Description (PTTD)
PHASE 2 - Analysis and functional design
- Architecture
- Separation of safety and non-safety E/E/PE [A6]
- Modularization HW (Modular design) [A6]
- Observance of guidelines and standards [A6]
- Diverse or different HW
- FPGA development according to FPGA Verification Methodology ref [A24].
- Structured specification [A6]
- Structured design, e.g., Reuse of tested circuit parts; [A6]
- Semi-formal methods (used for FPGA) [A6]
Selected measures (from group of Recommended measures): - Use of well-tried components (Component standard)
- Computer aided design tools [A6]
PHASE 2 – Verification activities
The following described techniques shall be used to verify the correctness and completeness of the output documents of this phase:
Technique/Measure:
- Inspection of the specification
- The safety system architecture specification shall be inspected by an independent person.
- The control architecture description shall be inspected by an independent person.
- → Refer “Checklist for Reviews” ref [A8]. The checklist for review of DoF is used.
- → See ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
- Checklists
- Prepared checklists shall be used concentrating on all safety-critical issues.
- → Refer “Checklist for Reviews” ref [A8].
- System FMEA
- To analyze a system design, by examining all possible sources of failure of a system's components and determining the effects of these failures on the behavior and safety of the system. → Refer “Checklist for Reviews” ref [A8]. The checklist for review of DoF is used.
Test documentation:
Describe the details of tests to be performed in the test plan.
- Verification test specification
- Function/Component type Test descriptions
- Integration Plan
- Specifies: who, what, and when shall be integrated.
- Consider: projects, related groups, teams, and programs.
- Internally within teams: use project or team descriptions for this purpose
- Product Tests
- Details in the test plan
- Environmental Tests
- Climatic, Mechanical and EMC (RFI; EMC; EMI)
- Electrical safety Tests
- -
- Integration test descriptions
- Low-level integration test descriptions.
- Functional test descriptions
- Functional Test Descriptions.
PHASE 3 - Detailed Design
- Architecture
- Observance of guidelines and standards [A6]
- Separation of safety related and non-safety related E/E/PE [A6]
- Modularization HW (Modular design) [A6]
- Use of well-tried components (Component standard)
- Structured specification [A6]
- Graceful degradation [A6]
- Structured design, e.g., reuse of tested circuit parts; traceability between specification, design, circuit diagram and parts lists; [A6]
- Semi-formal methods (for FPGA) [A6]
- Program sequence monitoring [A6]
- Computer aided design tools [A6]
- Forward traceability between the safety requirements specification and hardware design [A37]
- Detailed Design
- Structured and Modularized HW (Modular design)
- Observance of guidelines and standards [A6]
- De-rating for hardware components (e.g. see also EN 298 for further guidance)
- Use of well-tried components (Component standard)
- Computer aided design tools [A6]
- Forward traceability between the software safety requirements specification and hardware design [A37]
PHASE 3 – Verification strategies and techniques
Task: to verify the correctness and completeness of the output documents of this PHASE 3:
Technique/Measure:
- Checklists
- Prepared checklists for all documented outputs of safety lifecycle phases shall be used concentrating on all safety critical issues.
- → Refer “Checklist for Reviews” ref [A8].
- Inspection or walkthrough
- Design descriptions shall be walked-through including a person independent of the design.
- For SIL3 Inspection, by an independent organization using a formal procedure
- → See ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
- Detailed HAZOP analysis
- To determine safety hazards in the proposed design, their possible causes and consequences, and recommend action to minimize the chance of their occurrence. Shall be performed for new functionality or error corrections. If not performed, a rationale shall be given in the 'quality log'.
Test equipment to be used:
- Checklist (→ “Checklist for Reviews” ref [A8].)
Test documentation:
Describe details of design tests to be performed in the test plan:
- Integration test descriptions (Low-level integration test descriptions)
- Design test descriptions (Design Test Descriptions)
PHASE 4 – Implementation / Manufacturing
- Implementation
- FPGA development according to FPGA Verification Methodology ref [A24].
- Hardware FMEDA
PHASE 4 - Verification activities:
Task: to verify the correctness and completeness of the output documents of PHASE 4:
Technique/Measure:
- Hardware FMEDA including determination of the SFF
- To rank the criticality of components that could result in injury, damage or system degradation through single-point failures, in order to determine which components might need special attention and necessary control measures during design or operation.
- → “ABB approach to IEC61508 failure classification and probability calculations for AC 800M HI” ref [A38]
- PFD calculation
- The PFD calculation shall be based on typical conditions.
- → “ABB approach to IEC61508 failure classification and probability calculations for AC 800M HI” ref [A38]
- The PFD calculation shall be based on typical conditions.
- Analysis
- For VHDL follow FPGA Verification Methodology ref [A24].
Test equipment to be used:
- Checklist (→ “Checklist for Reviews” ref [A8]).
- Hardware FMEDA (→ Analysis tools for the FMEDA).
- Analysis for VHDL (→ according to FPGA Verification Methodology [A24]).
PHASE 5 – Module/Design and low-level integration test
- Module Testing
- FPGA development according to FPGA Verification Methodology ref [A24].
- Functional testing.
PHASE 6 – Function/Component type test
- Integration Testing
PHASE 7 – Validation PTT/STT
- Validation
- Functional testing
- Functional testing under environmental conditions [A7]
- Interference surge immunity testing [A7]
- Expanded functional testing [A7] (Test that all safety functions are maintained in the case of static input states and/or change over situations and/or unusual input changes, caused by faulty process or operating conditions)
- Fault insertion testing, when required diagnostic coverage >= 90% [A7]
Selected measures (from a group of recommended measures): - Static/dynamic analysis and failure analysis. [A7]
SOFTWARE – PHASE 1 to 7
PHASE 1 - Requirements definition
- Requirements Specification
- Structured specification, i.e., hierarchical separation described (using computer-aided engineering tools); automatic consistency checks; refinement down to functional level.
- Separation of safety and non-safety E/E/PE (This can be done by naming convention) [A6]
- Checklists (Checklists for reviews)
- Computer aided specification tools [A6]
- Observance of guidelines and standards [A6]
- Forward traceability between the system safety requirements and the software safety requirements [A37]
- Backward traceability between the safety requirements and the perceived safety needs [A37]
For further explanation of the above-mentioned techniques, measures and related Guidelines refer to the ABB approach to IEC 61508 Ed2, Design ref [A6].
PHASE 1 - Verification activities:
Task: to verify the correctness and completeness of the output documents of PHASE 1
Technique/Measure:
- Inspection of the specification
- The safety requirement specification shall be inspected by an independent person or organization.
- The checklist “Review of Safety Requirement Specification; “Checklist for Reviews” ref [A8].
- → No specific guidance document.
Test equipment to be used:
- Checklist
- No test equipment for this phase. The only equipment used is the “Checklist for Reviews” ref [A8], checklist “Review of Safety Requirement Specification”
Test documentation:
Further details of validation tests to be performed shall be described in a test plan
- Validation test descriptions: Product Type Test Description (PTTD)
PHASE 2 - Analysis and functional design
- Architecture
- Separation of safety and non-safety software [A6]
- Modular approach SW (Modular design) [A6]
- Semi-formal methods [A6]
- No dynamic reconfiguration (to the extent applicable to PLC) [A6]
- Computer-aided tools
- Fault detection and diagnosis [A6]
- Diverse redundancy, implementing the same software safety requirements specification (Diverse or different programming)
- Diverse monitor techniques (use of external monitor) [A6]
- Design and coding standards [A6]
- Use of trusted/verified software elements (if available) [A6]
- Cyclic behavior, with guaranteed maximum cycle time [A6]
- Static resource allocation
- Forward traceability between the software safety requirements specification and software architecture [A37]
- Backward traceability between the software safety requirements specification and software architecture [A37]
NOTE: Also see ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
- High-Level Design
PHASE 2 – Verification activities
The measure “Control and Data flow analysis” required by the standard is replaced by the measures of System-FMEA and SW-HAZOP based on UML. The following described techniques shall be used to verify the correctness and completeness of the output documents of this phase:
Technique/Measure:
- Inspection of the specification
- The safety system architecture specification shall be inspected by an independent person.
- The control architecture description shall be inspected by an independent person.
- → Refer “Checklist for Reviews” ref [A8]. The checklist for review of DoF is used.
- → See ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
- Checklists
- Prepared checklists shall be used concentrating on all safety-critical issues.
- → Refer “Checklist for Reviews” ref [A8].
- System FMEA
- To analyze a system design, by examining all possible sources of failure of a system's components and determining the effects of these failures on the behavior and safety of the system.
- → Refer “Checklist for Reviews” ref [A8]. The checklist for review of DoF is used.
- Software Safety Criticality analysis
- To determine safety hazards in the proposed system architecture, their possible causes and consequences, and recommend action to minimize the chance of their occurrence.
- → Refer “SW HAZOP Guideline” ref [A51].
Test documentation:
Describe the details of tests to be performed in the test plan.
- Verification test specification
- Function/Component Type Test Descriptions
- Integration Plan
- Specifies: who, what, and when shall be integrated.
- Consider: projects, related groups, teams, and programs.
- Internally within teams: use project or team descriptions for this purpose
- Product Tests
- Details in the test plan
- Software safety criticality analysis
- Analysis tools for the HAZOP.
- Integration test descriptions
- Low-level integration test descriptions.
- Functional test descriptions
- Functional Test Descriptions.
PHASE 3 - Detailed design
- Architecture
- Design and coding standards [A6]
- Separation of safety related and non-safety related software [A6]
- Modular approach SW (Modular design) [A6]
- Semi-formal methods [A6]
- Tools and translators with increased confidence from use [A6]
- No dynamic reconfiguration [A6]
- Modification protection [A6]
- Diverse monitor techniques [A6]
- Fault detection and diagnosis [A6]
- Computer aided design tools [A6]
- Use of trusted/verified software elements (if available) [A6]
- Forward traceability between the safety requirements specification and software design [A37]
- Backward traceability between the software safety requirements specification and software architecture [A37]
Selected measures (from a group of recommended measures): - Assertions
Also see ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
- Detailed design
- Modular approach SW (Modular design) [A6]
- Semi-formal methods [A6]
- Tools and translators with increased confidence from use [A6]
- Program sequence monitoring [A6]
- Structured programming [A6]
- Design and coding standards [A6]
- Computer aided design tools [A6]
- Fault detection and diagnosis [A6]
- Modification protection [A6]
- Defensive programming [A6]
- Forward traceability between the safety requirements specification and software design [A37]
- Use of trusted/verified software elements (if available) [A6]
Selected measures (from a group of recommended measures):
Also see ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
PHASE 3 – Verification strategies and techniques
Task: to verify the correctness and completeness of the output documents of this PHASE 3:
Technique/Measure:
-
Checklists
- Prepared checklists for all documented outputs of safety lifecycle phases shall be used concentrating on all safety critical issues.
- → Refer “Checklist for Reviews” ref [A8].
-
Inspection or walkthrough
- Design descriptions shall be walked-through including a person independent of the design.
- For SIL3 Inspection, by an independent organization using a formal procedure
- → See ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.
-
Detailed SW HAZOP analysis
- To determine safety hazards in the proposed design, their possible causes and consequences, and recommend action to minimize the chance of their occurrence.
- → (No specific guidance document)
Test equipment to be used:
- Checklist (→ “Checklist for Reviews” ref [A8].)
- HAZOP (→ Analysis tools for the HAZOP.)
Test documentation:
Describe details of design tests to be performed in the test plan:
- Integration test descriptions (Low-level integration test descriptions)
- Design test descriptions (Design Test Descriptions)
PHASE 4 – Implementation / Manufacturing
- Implementation
- Modular approach SW (Modular design) [A6]
- Coding standards
- Structured programming [A6]
- Suitable, strongly typed programming languages
- Defensive programming [A6]
- Use of trusted/verified software elements (if available) [A6]
- Forward traceability between the software safety requirements specification and software design [A37]
- Tools
- Use of tools with increased confidence from use
PHASE 4 - Verification activities:
Task: to verify the correctness and completeness of the output documents of PHASE 4:
Technique/Measure:
- Static code analysis
- → “Static Code Analysis Guideline” ref [A17]
- → And for VHDL “FPGA Verification Methodology” ref [A24]
- Code review
- Refer to section Code Reviews.
Test equipment to be used:
- Checklist (→ “Checklist for Reviews” ref [A8].)
- PC-Lint (→ Static Code Analysis Tool)
PHASE 5 – Module/Design and low-level integration test
- Module testing (ABB: Module/Design and low-level integration Test)
- Functional and black box testing [A7]
- Equivalence classes and input partition testing (covers boundary value analysis) [A7]
Selected measures (from a group of recommended measures): - Error guessing, guided by System FMEA [A7]
- Data recording and analysis [A7]
- Test management and automation tools
- Dynamic analysis and testing [A7]
- Error guessing [A7]
- Equivalence classes and input partition testing (covers boundary value analysis) [A7]
- Structural test coverage if not planned for function test level. (White box testing):
- 100% entry points
- 100% statements
- 100% branches
(Coverage measurement during the other tests might be an alternative) [A7]
- Interface testing [A7]
- Performance testing (covered by FTT) [A7]
- Forward traceability between the software design specification and the module and integration test specifications) [A37].
PHASE 6 – Function/Component type test
- Integration testing (ABB: Function/ Component Type Test)
- Functional and black box testing [A7]
- Data recording and analysis [A7]
- Dynamic analysis and testing [A7] e.g. tests to show coverage of sequence diagrams as specified
- Performance testing [A7]
- Stress testing including critical timing, max. load, max. configuration
- Response timings and memory constraints
- Simulation / modeling [A7]
- Finite State machines (mainly for FPGA VHDL) [A7]
- Forward traceability between the system and software design requirements for hardware/software integration and the hardware/software integration test specifications [A37]
- Forward traceability between the software design specification and the software verification (including data verification) plan. [A37]
- Backward traceability between the software verification (including data verification) plan and the software design specification. [A37]
Related Guidelines: ABB approach to IEC 61508 2nd Ed Test ref [A7], ABB Approach to Code Coverage Analysis [A47] and ABB Approach to IEC 61508 Traceability [A37].
PHASE 7 – Validation PTT/STT
- Validation
- Functional and black box testing [A7].
- Test cases are defined on a requirement basis (validation objectives).
- Equivalence classes and input partition testing (covers boundary value analysis) (covered by integration testing: LLIT and FTT) [A7].
- Data recording and analysis [A7].
- Simulation/modeling (covered by integration testing: Function/Component Type Test) [A7]
- Forward traceability between the software safety requirements specification and the software safety validation plan [A37].
- Backward traceability between the software safety validation plan and the software safety requirements specification [A37].
- Functional and black box testing [A7].
Owner: Functional Safety Team