1 Safety Handbook - NonSIL: Recommended SIL1

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

NonSIL Recommended Safety Integrity SIL 1

MANAGEMENT/GENERAL

Independent of development (System, HW or SW) the following rules have to be followed for Non-SIL development with a recommended SIL 1:

• Project management
  • Definition of actions and responsibilities; scheduling
• Modification
  • Consistency checks after modifications
  • Configuration management
  • Data recording
• Documentation
  • Graphical and natural language, e.g., block diagrams, or flow diagrams.

SYSTEM & HARDWARE – PHASE 1 to 7

PHASE 1 - Requirements definition

• Requirements Spec.
  • N/A (to be done before any criticality allocation)

PHASE 1 - Verification Activities:

• N/A

PHASE 2 - Analysis & Functional Design

• Architecture
  • Separation of safety and non-safety E/E/PE [A6]
  • Modularization HW (modular design) [A6]
  • FPGA development according to FPGA Verification Methodology ref [A24]

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
  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
• 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)
• Detailed design
  • Modularization HW (modular design)
  • Use of well-tried components (Component standard) [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.
  • 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.

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 for safety-relevant products.

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

Test equipment to be used:

• Checklist (→ “Checklist for Reviews” ref [A8].)
• Hardware FMEDA (→ Analysis tools for the FMEDA.)
• PC-Lint (→ Static Code Analysis Tool)

PHASE 5 – Module/Design and low-level integration test

• Module testing
  • No specific requirements.

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
  • Interference surge immunity testing [A7]

SOFTWARE – PHASE 1 to 7

PHASE 1 - Requirements definition

• Requirements Specification
  • n/a (to be done before any criticality allocation)

PHASE 1 - Verification activities:

• N/A

PHASE 2 - Analysis and functional design

• Architecture
  • Separation of safety and non-safety software [A6]
  • Modular approach SW (modular design) [A6]
    Selected measures (from a group of Recommended measures):
  • For complex software: Structured specification methods, not necessarily CASE tools [A6]
• High-level Design
  • No specific requirements for non-SIL

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 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]
    Selected measures (from a group of recommended measures):
  • For complex software: Structured specification methods, not necessarily CASE tools [A6]
• Detailed design
  • Modular approach SW (modular design [A6])
  • For all interference free modules, there shall exist a Design Description
    Selected measures (from a group of recommended measures):
  • Use of trusted/verified software elements (if available) [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.
  • 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.
  • → (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]
• Tools
  • No specific requirements.

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)
  • No specific requirements.

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]
  • Error guessing [A7]
  • Performance testing [A7]
  • Test of sequence diagrams (if part of the design)
  • State machine testing (if part of the design). [A7]

PHASE 7 – Validation PTT/STT

• Validation
  • Functional and black box testing [A7]
  • Data recording and analysis [A7]

---