Skip to main content

4 Safety Handbook - SIL2

For the development of a function with a required safety integrity level SIL 2, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.

SIL2 Required Safety Integrity SIL 2

SIL2 - SIL2

MANAGEMENT/GENERAL

SIL2 - SIL2 - Gen

Independent of development (System, HW or SW) the following rules have to be followed for development in compliance with required SIL 2:

  • Project management
    • Definition of actions and responsibilities; scheduling and resource allocation
  • Safety planning
    • Definition of methods, techniques, actions and responsibilities; training of relevant personnel; consistency checks after modifications
  • Modification
    • Impact analysis
    • Re-verify changed modules
    • Re-verify affected modules, by regression tests
    • Regression validation
    • Configuration management
    • Data recording and analysis [A7]
  • Documentation
    • Graphical and natural language, e.g., block diagrams, or flow diagrams.
SYSTEM & HARDWARE – PHASE 1 to 7

SIL2 - SIL2 - Sys

PHASE 1 - Requirements definition

  • Requirements Spec.
    • Structured specification, i.e., manual hierarchical separation into sub-requirements; Well defined interfaces between E/E/PE safety related systems and non-safety related systems [A6]
    • Separation of safety and non-safety E/E/PE (This can be done by naming convention) [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]
    • FPGA development according to FPGA Verification Methodology ref [A24].
    • Structured specification [A6]
    • Structured design, e.g., Reuse of tested circuit parts; [A6]
    • Structured methods (used for FPGA) [A6]
      Selected measures (from a group of recommended measures):
    • Use of well-tried components (Component standard)

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.

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 and non-safety E/E/PE [A6]
    • Modularization HW (modular design) [A6]
    • Use of well-tried components (Component standard)
    • Structured specification [A6]
    • Structured design [A6]
    • Graceful degradation [A6]
    • Semi-formal methods (for FPGA) [A6]
    • Program sequence monitoring [A6]
  • Detailed Design
    • Structured and modularized HW (modular design)
    • Observance of guidelines and standards [A6]
    • De-rating for hardware components
    • Use of well-tried components (Component standard)

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.
    • → See ref [A34] ABB approach to avoid common cause failures in PM/ SM where the different strategy is described.

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]
  • 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
    • Functional and black box testing [A7]
      Selected measures (from a group of recommended measures):
    • Field experience. [A7]

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 by the FMEDA (diagnostic coverage >= 90%) [A7]
      Selected measures (from a group of recommended measures):
    • Static/dynamic analysis and failure analysis [A7].
SOFTWARE – PHASE 1 to 7

SIL2 - SIL2 - SW

PHASE 1 - Requirements definition

  • Requirements Spec.
    • Structured specification, i.e., manual hierarchical separation into sub-requirements; Well defined interfaces between E/E/PE safety related systems and non-safety related systems [A6]
    • Separation of safety and non-safety E/E/PE (This can be done by naming convention). [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]
    • Use of trusted/verified software elements (if available) [A6]
    • No dynamic reconfiguration (to the extent applicable to PLC) [A6]
    • Diverse monitor techniques (external monitor) [A6]
    • Cyclic behavior, with guaranteed maximum cycle time [A6]
      Selected measures (from a group of recommended measures):
    • Computer-aided design tools [A6]
    • Fault detection and diagnosis [A6]
  • High-Level Design
    • Design and coding standards [A6]
    • Modular approach SW (modular design) [A6]
    • Semi-formal methods [A6]
    • Computer-aided design tools [A6]
    • Use of error-detecting codes (where applicable)

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
    1. Specifies: who, what, and when shall be integrated.
    2. Consider: projects, related groups, teams, and programs.
    3. 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 and non-safety 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 (external monitor) [A6]
    • Use of trusted/verified software elements (if available) [A6]
      Selected measures (from a group of recommended measures):
    • Assertions
    • Computer-aided design tools [A6]
    • Fault detection and diagnosis [A6]
  • 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]
    • Modification protection [A6]
    • Use of trusted/verified software elements (if available) [A6]
      Selected measures (from a group of recommended measures):
    • Fault detection and diagnosis [A6]

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.
    • → 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 [A6]
    • Use of trusted/verified software elements (if available) [A6]
    • Structured programming [A6]
    • Suitable, strongly typed programming language
      Selected measures (from a group of recommended measures):
    • Defensive programming [A6]
  • 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

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]
    • 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
        (Coverage measurement during the other tests might be an alternative)
    • Test of sequence diagrams
    • State machine testing [A7]
      Selected measures (from a group of recommended measures):
    • Interface testing (by using the techniques under Functional and black box testing). [A7]

PHASE 6 – Function/Component type test

  • Integration testing (ABB: Function/ Component Type Test)
    • Functional and black box testing [A7]
      • Test the behavior of the system for different inputs made by a user in a user interface
      • Test the behavior of the system for different in and outputs to the function provided by other system parts
      • Equivalence classes and input partition testing (covers boundary value analysis) [A7] (covered by low-level integration testing)
  • Data recording and analysis [A7]
  • Dynamic analysis and testing [A7]
    • Error guessing – including inputs from System FMEA / SW-HAZOP [A7]
    • Test of sequence diagrams
    • State machine testing [A7]
      Selected measures (from a group of recommended measures):
  • Performance testing – e.g. critical timing, max. load, max. configuration

PHASE 7 – Validation PTT/STT

  • Validation
    • Functional and black box testing [A7]
      • Test cases defined on the requirement basis (validation objectives)
      • Equivalence classes and input partition testing (covers boundary value analysis) (covered by integration testing) [A7]
    • Data recording and analysis [A7]
      Selected measures (from a group of recommended measures):
    • Simulation (wherever suitable as a validation method) [A7]

Owner: Functional Safety Team