Skip to main content

6 Safety Handbook - SIL - Library


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

SIL Libraries according to IEC 61508 and IEC 61511

SIL - Lib

MANAGEMENT/GENERAL for Libraries according to SIL

SIL - Lib - Gen

  • Project management
    • 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.
  • 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, flow diagrams.
    • Guidelines for consistent content; computer-aided documentation management, and formal change control.
Libraries – SIL – PHASE 1 to 7

SIL - Lib - Lib

PHASE 1 - Requirements definition

  • N/A

PHASE 1 - Verification activities:

  • N/A

PHASE 2 - Analysis and functional design

  • Architecture
    • Library Object Guideline ref [A30]
    • System 800xA Faceplate Style Guide ref [A32]
  • High-level design
    • Design and coding standards [A6]
    • Modular approach SW (modular design) [A6]
    • Structured methods [A6]
    • Structured design, e.g., reuse of well-proven components. [A6]
    • Fault detection and diagnosis [A6]
    • Computer aided design tools [A6]
    • Modularity of functionality;
    • Testability of functionality (including fault-tolerant features) and of internal structure;
    • The capacity for safe modification;
    • Traceability to, and explanation of, application functions and associated constraints. [A37]

NOTE: Wherever possible proven software modules should be used.

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

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
  • Integration test descriptions
    • Low-level integration test descriptions.
  • Functional test descriptions
    • Functional Test Descriptions.

PHASE 3 - Detailed design

  • Architecture
    • Library Object Guideline ref [A30], System 800xA Faceplate Style Guide ref [A32]
  • Detailed design
    • Modular approach SW (Modular design) [A6]
    • Structured methods [A6]
    • Tools and translators with increased confidence from use [A6]
    • Design and coding standards [A6]
      Selected Measures (from a group of recommended measures):
    • Use of trusted/verified software elements (if available) [A6]
    • Computer-aided tools
    • Fault detection and diagnosis [A6]
    • Modification protection [A6]
    • Defensive programming [A6]
    • Plausibility checks of each input variable including any global variables used to provide input data;
    • A full definition of input and output interfaces;
      The application software should:
    • Be readable, understandable and testable;
    • Satisfy the relevant requirements specified during safety planning

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
    • Design guideline
    • Modular approach SW (modular design) [A6]
    • Coding standards [A6]
    • Structured programming [A6]
    • Suitable, strongly typed programming languages
    • Defensive programming [A6]
    • Forward traceability between the software safety requirements specification and software design [A37]
      Selected Measures (from a group of recommended measures):
    • Use of trusted/verified software elements (if available) [A6]
  • Tools
    • Use of 'confidence-from-use' tools

For more explanation of the above-mentioned techniques, measures and related Guidelines refer to the ABB approach to IEC 61508 2nd Ed Design ref [A6] and ABB Approach to IEC 61508 Traceability [A37].

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

  • Application module testing
    • Test of intended function (unintended functions are not executed) from input points to output points
    • Forward traceability between the Description of Function and the module and integration test specifications [A37]
    • Functional and black box testing [A7]
    • Equivalence classes and input partition testing (covers boundary value analysis) [A7]
    • Simulation (e.g. for elements that need feedback from the equipment under control, like controllers, or timing effects due to the sequence of execution.) [A7]
    • Review techniques
      • Code review
      • Data recording and analysis [A7]
      • Structural testing
      • Dynamic analysis and testing [A7]
      • Structural test coverage (White box testing) [A7]
        • Branch coverage
        • Entry point coverage
        • Statement coverage
      • Error guessing [A7]

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 6 – Function/Component Type Test

  • Integration testing (ABB: Function/ Component Type Test)
    • Automated test, when applicable
    • Forward traceability between the system and software design requirements for hardware/software integration and the hardware/software integration test specifications [A37]
    • Functional and black box testing [A7]
      • Equivalence classes and input partition testing (covers boundary value analysis) [A7]
    • Structural test coverage (White box testing) [A7]
    • Data recording and analysis [A7]
    • Interface testing (if not covered by functional and black box testing) [A7]
    • Performance testing [A7]

Related guidelines: ABB Approach to Test of Library Types ref [A35] and ABB Approach to IEC 61508 Traceability [A37].

PHASE 7 – Validation PTT/STT

  • Validation
    • Functional test based on the requirements
    • 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: FTT) [A7]
    • Data recording and analysis [A7]
    • Simulation / modelling [A7]

Related guidelines: ABB approach to IEC 61508 2nd Ed Test ref [A7].


Owner: Functional Safety Team