Ultimate Guide to Functional Safety and Safety Certification

Safety Certification Terminology

Functional safety actively prevents the failure of a system from causing harm to people and property. Developers often need to certify a system as compliant with a functional safety standard. In this section, you’ll learn about functional safety and explore functional safety terms, such as dependability and availability, faults and failures, pre-certified versus compliant, HARA and safety case
Safety Certification Terminology

Do you want to build safety systems? Do you want to safety-certify an embedded product with complex software? Safety certification demonstrates compliance with a safety standard such as IEC 61508, the basic functional safety standard for electrical, electronic, and programmable electronic safety-related systems, and industry-specific standards such as IEC 62304 for medical devices, ISO 26262 for vehicles, IEC 60880 for nuclear power plants, EN 50128/50129/50657 for rail systems, and ISO 25119 for agricultural and forestry equipment.

At BlackBerry QNX, safety is at the heart of everything we do. We have safety certified our products and helped many of our clients to safety certify their systems. In this guide, you’ll learn why it’s important to shift your primary focus from certification to building safe systems. Building safe systems is more about promoting a safety culture in your organization and following best-practice processes, so safety is considered at every step in the software development lifecycle.

What Is Functional Safety?

Functional safety is the absence of unreasonable risk due to hazards caused by malfunctioning behavior. Functional safety requires the safe management of software errors, operator errors, hardware failures and environmental changes. A key aspect of functional safety is that it depends on the continuous operation of a safety-related system—an active system that detects and responds such as a fire suppression system and not a passive safety system such as fire-resistant door.

Functional safety depends on the continuous operation of an active system that detects and responds to a safety-related event.

functional safety system is a secondary system designed to prevent unintended harm to people, property and the environment. In addition to hardware and software, a functional safety system also may include protective equipment worn by the operator, system maintenance, and guidance for the safe use of the product such as a safety manual and operator training.

Systems are demonstrated to be functionally safe when they have been assessed and issued certification as compliant with a safety standard by an accredited third-party certifier such as TÜV Rheinland. Sometimes involving a third-party certifier is optional. For some industry-specific standards, such as ISO 26262, companies can self-assess their own compliance.

Almost all safety standards impose requirements on processes that, if followed systematically throughout the software development lifecycle, can increase the level of safety in systems.

The following safety terminology will help you better understand safety certification, functional safety standards, building safe systems and making safety claims.

Standards Versus Guidelines

There are many reasons companies follow functional safety standards, including:

  • Standards are often enforced with guidelines from industry consortiums and government regulators. Some regulators require pre-market approval.
  • Failure to follow the standard could expose a company to greater liability.
  • OEMs and integrators may specify compliance as a requirement for purchase.
  • Some companies have a well-entrenched safety culture.

Safety Integrity Levels: ASIL, SIL and Class

Many safety standards have different requirements based on the risk posed by a subsystem, each of which may need to be certified to a different safety integrity level (SIL). Functional safety standards differ in criteria and terminology for safety integrity levels, such as:

  • Safety Integrity Level (SIL) 1, 2, 3, 4: IEC 61508 bases SIL on the probability of failure per hour of operation
  • Automobile Safety Integrity Level (ASIL) A, B, C, D: ISO 26262 calculates ASIL based on the severity of the injuries that could result from an event, the likelihood the event will occur in normal operation, and how many drivers could control the situation to avoid the injury
  • Medical Device Class A, B, C: Under IEC 62304, medical devices are classified based on the amount of injury that could be caused to a patient, an operator, or an onlooker
  • Railway Safety Integrity Level (SIL) 0, 1, 2, 3, 4: EN 50128/50129/50657 bases SIL on the level of software safety integrity for railway control, protection, and rolling stock systems

Dependability, Reliability and Availability

  • Dependability: The ability of the system to respond correctly to events in a timely manner, for as long as required. Dependability is a combination of system availability and reliability.
  • Availability: How often the system responds to requests in a timely manner.
  • Reliability: How often the system responses are correct.

Faults, Errors and Failures

A fault can lead to an error, which can lead to a system failure.

  • Fault: A mistake in the code.
  • Error: Undesired behavior caused by a fault in the code.
  • Failure: An inability of the system to perform a required function due to an uncontained error.

Error recovery can prevent an error from becoming a failure:

  • Backward error recovery: The system returns to a previous state.
  • Forward error recovery: The system moves to a predefined state.

As illustrated in the following figure, an error at one level in a system may cause a fault at another. A fault in training could cause a software developer to make an error and insert a bug into the code, which ultimately results in a failure of the system.

Figure 1: Faults, errors and failures. Source: Hobbs, Chris. Embedded Software Development for Safety-Critical Systems. CRC Press, 2016.
Figure 1: Faults, errors and failures. Source: Hobbs, Chris. Embedded Software Development for Safety-Critical Systems. CRC Press, 2016.

Pre-certified Versus Certifiable Versus Compliant

The use of pre-certified software solutions can reduce an organization’s certification effort. The software used in product development will be part of the safety certification of the overall system. Safety certification is simplest when using commercial off-the-shelf (COTS) software that is pre-certified for safety by an external auditing firm. The definitions of pre-certified, certifiable and compliant software have different interpretations depending on whom you ask, but here’s a general guideline:

  • Pre-certified: The product has passed an audit and is assessed to be compliant with a safety standard by a certification firm, such as TÜV Rheinland. Pre-certified software provides a high level of confidence that it is suitable for use in a safety-critical system.
  • Certifiable: There’s a continuum of possible meanings. For example, the vendor may be prepared to or in the process of pre-certifying software, or this term may only indicate that the vendor is available to participate in your safety certification effort at your expense.
  • Compliant: This is a loose term that means a system follows the safety standards or requirements. However, unless external validation or documentation is provided and rigorous testing has been done, like that required when certifying a system, it is impossible to verify whether the claim is true.

Verification Versus Validation

Functional safety experts hold differing opinions on the topic of verification versus validation. At a high level, though, validation looks at the design to show that in logic simulations it does not create a hazard. Higher SIL levels require formal design validation. In contrast, verification involves lifecycle steps such as unit testing, integration testing, system testing and statistical analysis.

Self-Assessment Versus Third-Party Audit

Many functional safety standards allow participants to self-assess a product’s compliance. In tightly regulated industries such as avionics, industrial automation and power generation, an external auditor is a mandatory requirement. The use of a third-party auditor provides a higher level of confidence in a product’s suitability for use in a safety-critical system.

Many functional safety standards allow participants to self-assess a product’s compliance.

HARA and Safety Cases

With systems comes exposure to hazards and conditions that could cause a mishap and result in damage, loss, injury or death.

Hazard and risk analysis (HARA): Analysis of what could go wrong that would make a system unsafe.

Safety case: Explains why the product is safe, proving that hazards are mitigated and the system is acceptably safe for a given application in a given environment.

Book Offer: Embedded Software Development for Safety-Critical Systems

Meet with BlackBerry QNX safety experts to discuss your project and get a free copy of this deep, practical guide to designing safe systems.

Safety Certification Fundamentals

Safety certification requires a safety culture from the start and throughout the software development lifecycle. In this section, you’ll learn about key concepts for safety certification to help you get the process right, understand the hazards, choose reliable components, design with safety in mind, leverage expertise and keep a system safe over its lifecycle.

Get the Process Right (a Fast Intro)

Get yourself a cup of coffee because it’s time to talk process. Yawn, right? Have you heard the joke about how “getting the process right is more than half the battle to receive a functional safety certification?” But it’s no joke. A large percentage of most safety standards are dedicated to defining what processes you should follow to build a safe system.


A good example to illustrate safety process is the V-model, a reference process model for each phase of product development defined in ISO 26262. The standard explains: “The software development process is based on the concept of a V-model with the specification of the software requirements and the software architectural design and implementation on the left-hand branch, and the software integration and testing, and the verification of the software requirements on the right-hand branch.”
Figure 2: The V-model from ISO 26262, Road vehicles — Functional safety — Part 2: Management of functional safety
Figure 2: The V-model from ISO 26262, Road vehicles — Functional safety — Part 2: Management of functional safety

Safety throughout the Product Lifecycle

ISO 26262 goes on to explain that the safety lifecycle encompasses “the principal safety activities during the concept phase, product development, production, operation, service and decommissioning. Planning, coordinating and documenting the safety activities of all phases of the safety lifecycle are key management tasks.”

To summarize, a well-defined safety process ensures that an organization keeps safety in mind at every step in the software development lifecycle.

Safety throughout the Product Lifecycle

Understand the hazards

Functional safety standards typically start with hazard identification, because the risks posed by hazards drive the safety requirements for a system. In the following example, you can see how risks lead to safety requirements for three hazards that could emerge when the prescribed action A does not occur within time T after receiving a command:
Risk Safety Requirement
The operating system does not respond within time T after receiving the command.
The operating system must have an upper bound for the response time less than T.
A logical error could occur in action A.
The design of action A must be free from logical errors.
Another action B could interfere with the proper execution of action A.
Action A must be free from interference from another action in the system.
Safety Requirement
The operating system does not respond within time T after receiving the command.
The operating system must have an upper bound for the response time less than T.
A logical error could occur in action A.
The design of action A must be free from logical errors.
Another action B could interfere with the proper execution of action A.
Action A must be free from interference from another action in the system.

Functional safety standards start with hazard identification, because risks drive safety requirements.

No SOUP for You

It is permissible to use off-the-shelf components if they come with sufficient evidence from the supplier to support the overall system’s safety case. Building all software from scratch won’t necessarily result in a safer system than one that uses COTS components with tens of millions of hours of in-use history.

However, many COTS components are considered software of unknown provenance (SOUP) unless they are pre-certified for safety. If you use off-the-shelf (OTS) software in a system requiring SIL 3 or 4, for example, EN 50128 requires you to develop a strategy to detect failures of the OTS software and to protect the system from these failures. If sufficient support is not provided by the supplier, SOUP can result in an overwhelming burden for your software development team. That’s why functional safety engineers, at least the ones who are Seinfeld fans, say, “No SOUP for you!”

Choosing pre-certified software, such as QNX® OS for Safety, can save money, lower risk, and significantly reduce the time you’ll spend documenting an uncertified software component such as Linux®.

Components with a Safety Pre-Certification Can Speed Your Development and Validation Efforts and Facilitate Regulatory Approval

Consider these four criteria when selecting OTS components for a safety critical system:

  • Supplier reputation and track record
  • Product information including development artifacts
  • Standards compliance, preferably certification
  • Supplier audit

An effective way to test the safety depth of your supplier is to ask about the availability of some key documents that can support your safety case, such as:

  • Functional safety requirements
  • Functional safety management plan
  • Safety case
  • Hazard and risk analysis
  • Safety manual

Design with Safety in Mind

Working from the premise that errors lead to faults and faults lead to failures, you’ll need multiple lines of defense to design and build a functionally safe system, including isolation and freedom from interference.

Isolation and Freedom from Interference

An aspect of functional safety is designing the system to isolate safety-critical functions from other functions and ensure they are free from interference. For example, the important warning displays on an automobile digital instrument cluster should be isolated from vehicle infotainment systems even if they share display space on the dashboard.

Subsystems within a single system-on-chip (SoC) may be subject to safety requirements at different safety integrity levels, such as ISO 26262 ASIL A, B, C or D for a subsystem in a passenger vehicle. Sufficient temporal and spatial separation between safety-critical and non-safety-critical domains allows for a simpler design, which leads to a simpler safety case and a lower certification effort.

A microkernel and embedded hypervisor are two ways to provide isolation and freedom from interference.

A microkernel architecture, such as QNX® Neutrino® Real-Time Operating System (RTOS) can separate multiple functions, both spatially and temporally, and provide isolation and freedom from interference in embedded systems with mixed criticality.

An embedded hypervisor divides hardware resources into separate execution environments called virtual machines. The hypervisor manages these virtual machines, making sure they share resources without conflict. An embedded hypervisor, such as QNX® Hypervisor for Safety, allows designers to run separate and isolated guest operating systems such as Linux, Android™ and QNX®—on a single SoC.

Leverage Expertise Where Available

Safety certification is complicated and time-consuming. Most development organizations engage outside expertise to avoid missteps and delays. Some organizations benefit from assistance from start to finish, while others only need expertise in specific areas. These three examples show how development organizations use safety services differently:

  • An organization new to functional safety wants training to bring its technical team up to speed on the relevant functional safety standard, assessment services to examine the organization’s internal processes, and help designing safety requirements and safety architecture.
  • An organization with experience in functional safety wants expert advice on a specific technical area, such as how to use the memory protection features of a specific RTOS.
  • An organization attempting to use a certifiable or compliant software solution (not pre-certified) wants a gap analysis and assistance to document what can be done to fill the gap to satisfy an auditor

Keep It Safe

Release cycles matter. Safety certification is always linked to specific versions of all software components and will have a lifespan of years. When it’s time to revamp the product, some of the software may have reached end-of-life.

Choosing a more modular OS, such as a microkernel RTOS, can isolate the impact of software changes and simplify certification.

Additionally, an embedded hypervisor can play an important role in a product team’s ability to rapidly create, test and certify a new version of a safety-critical product. With a hypervisor, the development team can re-use proven legacy software (for example, running it in a dedicated virtual machine) and keep safety functions separate. Software components can be built by independent groups, tested separately, run together, and swapped out without affecting other systems or having to retest the whole system repeatedly.

Finally, there is no safety without security. Unfortunately, since security is a newer topic for embedded systems than safety, there is less accumulation of security knowledge, expertise solution sets and industry guidance. Security for embedded devices calls for a different set of skills and solutions than IT security, and there isn’t a dominant security standard to follow.

BlackBerry has developed in-depth security expertise and technology over the last 35 years. Our tens of thousands of patents and more than 80 security certificates reflect a deeply entrenched security culture and capability.

Glossary of Functional Safety Standards

These functional safety standards deliver benefits to developers, system integrators and users. By following a standard, a development organization builds safer products and documents a safety case. A system integrator can state its expectations to a supplier by requiring compliance with a standard. And users have fewer injuries and deaths. This section provides a list of functional safety standards.
Figure 3: Examples of functional safety standards
Figure 3: Examples of functional safety standards

IEC 61508 – Functional Safety of Electrical/Electronic/ and Programmable Electronic

IEC 61508 is the foundational source for good software methods, techniques and tools to support functional safety.

ISO 9001:2015 – Quality Management Systems – Requirements

ISO 9001:2015 includes requirements for leadership, planning, support, operation, performance evaluation and continual improvement.

IEC 62061 – Safety of Machinery: Functional Safety of Electrical, Electronic and Programmable Electronic Control Systems

IEC/EN 62061 defines requirements for system-level design of safety-related electrical control systems in machinery and design of non-complex subsystems and devices.

ISO 26262-6:2018 – Road Vehicles – Functional Safety – Part 6: Product Development at the Software Level

Part 6 covers software and provides lists of recommended and highly recommended techniques for each automotive safety integrity level (ASIL). Only events deemed to be ASIL A, B, C or D need to comply with ISO 26262.

IEC 62304 – Medical Device Software – Life Cycle Processes

IEC 62304 includes requirements for the software development process, software maintenance process, software configuration management process and software problem resolution process.

EN 50128, 50129, 50657 – Railway Applications – Communication, Signaling, Processing, and Rolling Stock Systems

These three European standards define safety-related software process standards, hardware, and approval processes for railway applications. EN 50128 provides process standards for software for railway control and protection systems. EN 50129 covers safety-related electronic systems for signaling. EN 50657 identifies requirements for software intended for railway rolling stock systems.

ISO 25119 – Agricultural and Forestry Tractors and Machinery – Safety-Related Parts of Control Systems

This safety standard for agriculture and forestry equipment covers general principles for design and development, concept phase, series development for hardware and software, and processes for production, operation, modification and support.

IEC 61513 – Instrumentation and Control Systems Important to Safety in Nuclear Power Plants

IEC 61513 defines general requirements for systems important to safety in the nuclear power industry.

ISO/SAE 21434 (coming soon) – Road Vehicles – Cybersecurity Engineering

BlackBerry QNX is participating in the development of this automotive cybersecurity standard. ISO/SAE 21434 is bringing the auto industry together with the goal of developing reasonably secure vehicles and systems.

How Can BlackBerry QNX Help You?

Achieving safety certification for an embedded system is time-intensive and costly. BlackBerry QNX reduces that burden for our customers by pre-certifying our real-time operating system and hypervisor to the highest automotive, industrial and medical standards. We also offer safety services, from maintenance and support through to flexible custom services plans. In this section, you’ll learn about our pre-certified software solutions and our safety services.

BlackBerry QNX has developed in-depth safety expertise and technology. In addition, having certified our own products to the highest levels of ISO 26262 (ASIL D) and IEC 61508 (SIL 3), as well as IEC 62304, we have the tools and experience to help get your embedded product across the finish line, too.

The BlackBerry® QNX® safety-certified RTOS is used in hundreds of millions of devices, including life-critical medical products.

See our complete list of certifications.

BlackBerry QNX Safety Services

Acquiring safety certifications for mission-critical applications is one of our core competencies. BlackBerry QNX has helped customers achieve certification to many different safety standards – including ISO 26262, IEC 61508, IEC 62304 and EN 50128 – by leveraging our own certification experience and deep knowledge of functional safety best practices.

We offer training, consulting, custom development, root cause analysis and troubleshooting, system-level optimization and onsite services across a range of embedded systems in automotive, medical, robotics, industrial automation, defense and aerospace, among other industries.

Learn more about our safety services.

Functional Safety Training and Workshops

Developed by renowned experts, learn how to apply functional safety concepts to embedded system design and streamline your certification efforts.

  • Introduction to Functional Safety Course: This live online introductory course covers the basics of functional safety as it applies to embedded system design and can be customized to focus on specific industry standards. Read the course curriculum.
  • Functional Safety Workshop: This interactive and hands-on discovery workshop includes a system design and technical safety concept review and provides recommendations for products and processes to streamline safety certification. Learn more.

Talk to us about your safety training needs.

Check Out Our Other Ultimate Guides

Structural Dependency
Provides embedded RTOS basics and considerations when choosing between an open source or commercial OS options
Structural Dependency
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
Structural Dependency
Information about the UNECE WP.29 regulations, the countries where they apply and how they aim to mitigate the cybersecurity risks posed to passenger vehicles.
Structural Dependency
Defines autonomous systems and the various levels of autonomy
Read the Guide

Get this Ultimate Guide as a PDF

Click here to download the Ultimate Guide to Functional Safety and Safety Certification.

Contact Us

Our team of experts are here to answer your questions.