IEC 61508 considers two different types of software in regards to electrical /electronic/programmable electronic safety-related system: software system and applicative software.
Software System and Applicative Software
Software system is part of the software of a programmable electronic system that relates to the operation and services provided by the programmable device itself, such as a PLC Embedded Software.
The applicative software is rather part of the software of a programmable electronic system that specifies the functions that are performed in relation to EUC (Equipment Under Control) safety.
In regards to functional safety, all software faults are systematic failures.
Recommended in-depth study:
What are systematic failures?
In general, a fault occurs when a predetermined function cannot be performed or performance is outside the requirements.
- Systematic failures will always repeat when the activation condition is available.
- Systematic failures can be introduced at any time during the device lifecycle.
- Systematic failures are caused by an error at any stage of the lifecycle + a certain condition. The fault is hidden until a specific condition occurs.
- Systematic failures are unavoidable events.
- The ability to avoid systematic failures is called systematic capability.
- Human error is a systematic failure.
IEC 61508-3 Standard
IEC 61508-3 applies to:
- Operating and system software
- Communication software
- Human-machine interface functions
- Development support tools
- Firmware Application software
Compliance with IEC 61508-3 is required for software that performs safety functions. Compliance with the requirements is not required for software that does not have this role.
For the latter, only non-interference property is required.
Recommended in-depth study:
Software Safety Lifecycle
The objectives and requirements for the phases of the overall safety lifecycle are contained in IEC 61508-1 clauses 7.2 to 7.17.
Where applicable, the implementation phase must meet IEC 61508-3 requirements (Safety Software). It applies to any software that is part of or used to develop a safety-related system under IEC 61508-1 and IEC 61508-2.
Such software is defined as safety software (including operating systems, system software, software in communication networks, human-machine interface functions, firmware and application software).
The standard suggests a software development model, called the V-Model, which aims at:
- Defining Requirements: for the architecture, the system, and each single module
- Testing, following the defined requirements.
Among Software Safety Lifecycle, there are two important steps:
- Software Verification, a series of intermediate checks to verify the congruence of the ‘semi-finished’ product with the product used as a starting point
- Software Validation, i.e. targeted control to measure compliance with requirements
Do you want to contribute to our page? Follow us on Linkedin
Requirements for Software Management
Software documentation management must be handled in accordance with ISO 9001:2015.
The first objective of software management requirements is to specify the responsibilities in managing functional safety for the individuals in charge of the safety software or of one or more phases of the life cycle.
All individuals, departments, and organisations responsible for carrying out activities in safety software lifecycle phases must be identified and their responsibilities must be thoroughly and clearly communicated to them. Competence adequately matched to responsibility/role must also be demonstrated.
Even in managing software, safety must be examined through a Functional Safety Assessment in order to analyze whether the safety function can achieve a specific SIL level, prior to issuing the SIL certificate as a proof of software reliability against IEC 61508 requirements.
For more information:
Software Safety Manual
A Software Safety Manual is an integration of the more generic Safety Manual, as per IEC 61508-2, annex D.
A safety manual defines an element’s features, i.e. hardware and/or software constraints of which the integrator must be aware and take into account during application.
Specifically, Software Safety Manual minimum contents are:
- Software Configuration
- Recommended configurations
- Skills required for use
- Installation instructions
- Reasons for a possible update
- Anomalies that may occur
- Compatibility with previous versions
- Compatibility with other systems
- Various constraints
- Configurable Elements
- Security measures against attacks