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
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.
A 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.
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.
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.
V-Model
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.”
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.
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.
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.
- Read more about how your OS choice could affect IEC 62304 certification in 5 Reasons to Consider an Alternative to Linux for Your Medical Device
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.
Check Out Our Other Ultimate Guides
Real-time Operating Systems
Provides embedded RTOS basics and considerations when choosing between an open source or commercial OS options
READ THE GUIDE
Embedded Systems Security
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
READ THE GUIDE
WP.29 Cybersecurity Vehicle Regulation Compliance
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.
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.