Chapter 8 - Validation

Last edit: 11/08/2023

Chapter 8 describes the validation activity, that consists in making sure what was designed and engineered as a Safety Control System (IEC 62061) or a Safety Related Part of the Control System (ISO 13849-1), is implemented correctly. Validation is the activity of demonstrating that the Safety-related Control System, SCS or SRP/CS, meets the Safety Requirements Specification. We remind that the whole “Functional Safety House” is based upon

  • Hardware safety Integrity. The validation goes through the verification that:
    – The components have the required Reliability data
    – The subsystem Architectures or Categories have been properly implemented and
    – The calculations were done correctly.
  • Systematic Safety Integrity, including software: in other words, the lack of systematic failures (also called Systematic Capability §3.4.2). This is the most difficult aspect to verify, since its objective is that there were no mistakes in the engineering and construction phase. For example, the cables were correctly sized and protected, the software was correctly configured or the cabling was properly done. Many of those Systematic Capabilities are listed in the Basic and Well-tried safety principles: Annexes A to D of ISO 13849-2.

A loss of the safety function in the absence of a hardware fault is due to a systematic failure, which can be caused by errors made during the design and integration stages (a misinterpretation of the safety function characteristics or an error in the logic design or an error in hardware assembly or also an error in typing the software code). Some of these systematic failures will be revealed during the design process, while others should be revealed during the validation process, otherwise they will remain unnoticed. In addition, it is also possible that an error is made during the validation process: e.g. failure to check a characteristic.

 

Hereafter some excerpt from the chapter.

8.1 Introduction
Validation is the activity of demonstrating that the Safety-related Control System, SCS or SRP/CS, meets the Safety Requirements Specification.
I remind that the whole “Functional Safety House” is based upon

  • Hardware safety Integrity. The validation goes through the verification that:
  • – The components have the required Reliability data
    – The subsystem Architectures or Categories have been properly implemented and
    – The calculations were done correctly.

 

  • Systematic Safety Integrity, including software: in other words, the lack of systematic failures (also called Systematic Capability § 3.4.2). This is the most difficult aspect to verify, since its objective is that there were no mistakes in the engineering and construction phase. For example, the cables were correctly sized and protected, the software was correctly configured, or the cabling was properly done. Many of those Systematic Capabilities are listed in the Basic and Well-tried safety principles: annexes A–D of ISO 13849-2.

A loss of the safety function in the absence of a hardware fault is due to a systematic failure, which can be caused by errors made during the design and integration stages (a misinterpretation of the safety function characteristics or an error in the logic design or an error in hardware assembly or also an error in typing the software code). Some of these systematic failures will be revealed during the design process, while others should be revealed during the validation process; otherwise, they
will remain unnoticed. In addition, it is also possible that an error is made during the validation process: e.g. failure to check a characteristic.