Software Safety Management

Reading time: 8 minutes - Difficulty: advanced
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.

More specifically:

  • 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
  • Development
  • 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


Download Infographics

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

For more information or to request a quote

What does HARA mean for ISO 26262?

The HARA method The HARA method aims at identifying and categorizing hazardous events of items, and also at specifying safety goals according to ISO 26262 and ASILs (Automotive Safety Integrity Levels) related to the prevention or mitigation of the associated hazards in order to avoid unreasonable risk. This means that the combination of a hazard […]

Read more

A brief introduction to ISO 26262

ISO 26262 Standard Application It covers the implementation of functional safety through electrical and/or electronic (E/E) systems, and presents a specific lifecycle for items used in the automotive sector. Thus, it provides a reference for the automotive safety life cycle and supports the adaptation of activities to be performed during the lifecycle phases, i.e. development, […]

Read more
Byhon Logo bianco

Subscribe to our newsletter to stay up to date on Functional Safety and Industrial Cyber Security news and events

Send this to a friend