What Is
Functional Safety?

Understand functional safety standards, their importance for safety software development, and solutions for your safety-critical IoT systems.

 

What Is Functional Safety?

In the overall safety of a system or piece of equipment, functional safety is the element that relies on automatic protection operating correctly and predictably in response to inputs or failures. It must be able to handle worker error, hardware failure, and a fluctuating operating environment. Functional safety applies to any segment (aviation, automotive, industrial, medical, transportation, and others). Its goal is to protect humans from injury or death and to prevent life-threatening damage to equipment and facilities.

Mission-Critical Systems

A mission-critical system cannot fail. Autonomous vehicles with crash sensors must not kill people, for example. The safety of lives is the basis of all functional safety certifications.

In a world that is increasingly connected, data sharing and telematics availability are critical for connecting and updating mission-critical systems and devices.

Autonomous equipment must react to environmental cues to function safely around people and other machinery.

If you have a connected autonomous system, or any connected system, you must prove that its safety-critical elements are secure, or you run the risk of a malicious actor interfering with system safety and the integrity of your data.

To address the challenges and achieve success with these systems, users must bring together platforms with different types of operating systems. The safety-critical features of real-time operating systems added to an open source Linux-based solution can address the software-centric functions of a future that is more automated, autonomous, and statistical.

Embedded Systems and the Intelligent Edge

The next generation of embedded devices is being built with cloud-native technologies that allow companies to explore new use cases at the edge. Today, embedded systems and the applications they run are leveraging the processing power of the cloud and artificial intelligence (AI) and machine learning (ML) technologies to enable greater insights and decision-making at the edge of the network, where devices are deployed.

Operational and environmental data gathering from the intelligent edge is used to improve functionality, ensure safety, and make real-time business decisions.

A mission-critical system cannot be functionally safe if it isn’t secure. End-to-end security for updates, control, and feedback is crucial.

The Difference Between Safety and Security

Safety means no injury or loss of life is caused, whether deliberately or not. Security means that people, facilities, operations, data, and more are protected from loss, interference, theft, or negative changes, and that no deliberate harm is caused. Another way of putting this is that safety means protecting the world from the system, whereas security means protecting the system from the world. Both are crucial, but a system cannot be functionally safe if it isn’t secure.

Why Is Functional Safety Important?

Functional safety in systems, equipment, or devices is essential for safeguarding human lives and preventing human injuries or environmental damage. Its purpose is to use specifically designed hardware equipment and/or software systems that operate to automatically prevent life-threatening, injury-causing, dangerous failures, or that control or halt such failures if they occur so as to stop further danger or threats.

Main Aspects of Functional Safety

As humans increasingly interact with autonomous or semi-autonomous systems, automatic safety functions become an essential part of the end-to-end system.

The all-encompassing objective of functional safety is to prevent risk to human lives caused either directly or indirectly from the operation of a hardware or software system. This includes preventing risk caused by damage to equipment, property, or the environment. The critical factor at play is the appropriate and correct implementation of one or more built-in, automatic protection functions known as safety functions, which constitute a safety system or safety-related system.

The scope of functional safety is end-to-end, in that it must treat any function of a component or subsystem as part of the operation of the entire system’s automatic protection function. Thus, although the standards for functional safety focus on electrical, electronic, and programmable systems, in practice functional safety methods must extend to the nonelectrical, nonelectronic, and non-programmable components of the system.

To deliver functional safety is to provide assurance and evidence that a hardware or software system meets the properly specified functional safety requirements through certification via the appropriate testing and accreditation bodies.

Functional Safety Certification

Any claim of functional safety for a component, subsystem, or system should be independently certified to the proper recognized functional safety standards. A certified product can then be claimed to be functionally safe to a particular safety integrity level (SIL) or performance level (PL) in a specific range of applications. The certificate and the assessment report that describe the scope and limits of performance are provided to the customer.

Certifications should be completed by independent organizations with experience and strong technical depth (electronics, programmable electronics, mechanics, and probabilistic analysis). Functional safety certification is performed by accredited certification bodies. Accreditation is awarded to a certification organization by an accreditation body. In most countries there is one accreditation body. In the United States, the American National Standards Institute (ANSI) is the organization for functional safety accreditation. In the United Kingdom, the United Kingdom Accreditation Service (UKAS) provides functional safety accreditation.

Functional Safety Standards

There are functional safety standards for various industries, including aviation, automotive, industrial, medical, transportation, and more. For the industrial sector, IEC 61508 is the functional safety standard. Functional safety certification programs for IEC 61508 standards are offered globally by several recognized certification bodies, including Intertek, SGS, TÜV Rheinland, TÜV SÜD, and UL.

Other functional safety standards that have been derived from IEC 61508 include international standards IEC 62304 for medical device software and the ISO 26262 road vehicles functional safety standard for automotive equipment for all automotive electronic and electrical safety-related systems. For railway transportation, there is EN 50126/8/9.

For the aviation market, the U.S. Federal Aviation Administration has enacted a similar process for functional safety certification. Known as RTCA DO-178C for software and DO-254 for complex electronic hardware, these are applied throughout the aerospace industry. For Europe, the corresponding certification is EURICAE ED-12C.

RTCA DO-178C – Aerospace

DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is the principal document that the FAA, EASA, and Transport Canada certification agencies use to review and approve all commercial software-based aerospace systems.

DO-178C DAL A

DO-178C by itself does not guarantee safety aspects of the software running in a system. In the system design, the safety attributes and their functions must contain and conduct mandatory additional system safety tasks to implement and demonstrate clear and objective evidence of meeting the specific safety requirements. As specified by DO-178C and as required by the certification authority bodies, the correct Design Assurance Level (DAL) must be established using comprehensive analysis to establish the software level A–E. Any software that commands, controls, and/or monitors safety-critical functions should receive the highest DAL, Level A.

ARINC 653 – Avionics

ARINC 653 (Avionics Application Standard Software Interface) is a software specification for space and time partitioning in safety-critical avionics real-time operating systems. It allows the hosting of multiple applications of different software levels on the same hardware in the context of an integrated modular avionics (IMA) architecture.

IEC 61508 – Industrial

IEC 61508 is the industrial functional safety standard.

ISO 26262 – Automotive

ISO 26262 is the functional safety standard in the automotive industry.

EN 50128/9 – Railway

EN 50128 is the functional safety standard for software for railway control and protection.

EN 50129 is the functional safety standard for railway safety-related electronic systems for signaling.

IEC 62304 – Medical Devices

The international standard IEC 62304 specifies lifecycle requirements for the development of medical software and software within medical devices. It has been adopted by both the United States and the European Union and so can be used as the benchmark for compliance with regulatory requirements in both these markets.

Functional Safety Software Development and Considerations

The future will be autonomous. How can our platforms evolve and continue to solve customer challenges while incorporating software-centric features such as machine learning and computer vision — all while maintaining safety criticality in a connected world?

A Safety-Certified Real-Time Operating System

Any device or system that is mission critical will also need to be safety certified. If you need to guarantee that the brakes function or that the ailerons will work, you will need a real-time operating system that is certified for the specific standards within its market, be that aerospace, defense, automotive, industrial, medical, or rail.

You’ll also need functional safety consideration and support applied throughout the product lifecycle, including the legacy-device stage.

Finally, as silicon manufacturers move toward multi-core environments, you will need operating system support for these devices and systems.

A Customizable Linux Development for AI, ML, and Deep Learning (DL)

To address autonomous middleware and AI challenges going forward, most development will be on Linux. As the most popular development operating system for AI, ML, and DL, it will be critical for minimizing the distro size for devices out in the field.

In a safety-critical use case, however, this means introducing Linux into a system that typically requires an RTOS. A device may require an RTOS for guaranteed performance, for example, but coupled with AI/ML algorithms that are mostly associated with Linux. Developers and customers need applications and systems that span both types of operating systems, and system integrators are needed to work on both sides of this equation.

A Hypervisor for Interoperation

With modern silicon containing two to eight cores on a single system-on-chip, in today’s complex systems a safety-certified RTOS and an embedded Linux OS are no longer two different control units spanning a network. Instead these two very different operating systems run side-by-side on a single system-on-chip. In this scenario, having a means to monitor both sides with high-speed communication is critical. A hypervisor that is certified, fast, and able to manage the host operating system(s) becomes essential.

A hypervisor enables multiple operating systems with different characteristics to run on a single system-on-chip.

How Can Wind River Help?

In the new era of autonomy and connectivity, where it is increasingly important to identify and implement safety-related systems, Wind River® continues to lead the way. Our software runs the “can’t fail” computing systems of the most important modern critical infrastructure, including aerospace and defense, rail, automobiles, medical devices, robotics, industrial control systems, smart factories, and more.

Only Wind River offers the complete set of components that go above and beyond what is available from the rest of the market. We have the class-leading safety-certified real-time operating system; the most common commercial embedded Linux solution, based on the Yocto Project; and a safety-certified hypervisor.

Wind River also has extensive experience meeting the safety-critical standards of crucial sectors, including flight safety (DO-178C DAL A), industrial (IEC 61508), rail (EN 50126/8/9), and automotive (ISO 26262).

Functional Safety Certifiable Software

VxWorks CERT Edition

VxWorks® has an extensive portfolio in safety certification of software products, including 600+ safety certification programs with more than 360 individual customers, including more than 100 civilian and military aircraft. Its robust safety features provide advanced time and space partitioning capabilities to enable reliable consolidation of multiple applications with different levels of criticality on a single- or multi-core platform. Conformance to standards such as POSIX® and FACE have been leveraged in the certification of VxWorks to DO-178C, IEC 61508, IEC 62304, and ISO 26262 safety standards.

VxWorks 653

VxWorks 653 Multi-core Edition is a safe, secure, and reliable real-time operating system. It delivers an ARINC 653–conformant system by providing robust time and space partitioning on the latest hardware platforms to ensure fault containment and the ability to upgrade applications with minimal test and integration demands.

Wind River Helix Virtualization Platform

Wind River Helix Virtualization Platform has been designed to be certified and to simplify the certification of safety-critical applications according to the stringent requirements of the DO-178C Software Considerations in Airborne Systems, IEC 61508 industrial functional safety, and ISO 26262 automotive safety standards. It is an OS-agnostic edge compute platform with a real-time, embedded, Type 1 hypervisor that can manage unmodified guest operating systems running VMs and consolidating the workloads for devices.

Medical Application #1

Medical Application #2

Application #3

Application #4

VM 1 VxWorks
(Safety Critical)

VM 2 Wind River Linux

VM 3 Windows

VM 4 Third-Party OS
(Safety/Non-Safety)

Wind River Helix Virtualization Platform — Hypervisor

Multi-core Hardware

Professional Services

Certification of a system is a complex, costly, and demanding process. The A&D, medical, industrial, and security industries each have their own different but similar safety standards. Wind River Professional Services provides the safety-critical expertise to help you through the certification process.

>>  Learn more

Functional Safety FAQs

Functional safety is part of overall safety, and it depends on a system or equipment operating correctly in response to its inputs. For example, an over-temperature protection device that uses a thermal sensor in the windings of an electric motor to deenergize the motor before it can overheat is an example of functional safety. But providing specialized insulation to withstand high temperatures is not an instance of functional safety — although it is still an instance of safety and could protect against exactly the same hazard.
The role of safety engineering is accident prevention, reducing the risks of human injury or loss of life associated with human error. It derives safety benefits from engineered hardware and software systems design. It is applied to product designs to make functional safety an integral part of equipment or system operations.
DO-178C is the short name for a document written by RTCA; its complete title is “Software Consideration in Airborne Systems and Equipment Certification.” The document was produced by Special Committee 205 (SC-205) of RTCA and Working Group 71 (WG-71) of the European Organization for Civil Aviation Equipment (EUROCAE). The EUROCAE name for this document is ED-12C. RTCA provides copies of this document at www.rtca.org. The document provides the avionics community with guidance for determining, in a consistent manner and with an acceptable level of confidence, which the software aspects of airborne systems and equipment comply with airworthiness requirements. The document defines several Design Assurance Levels, from Level A to Level E, based on the consequence of a failure condition. Failure of Level A software would cause (or contribute to) a catastrophic failure condition for the aircraft that would prevent continued safe flight and landing.
The certification authorities FAA and EASA require aircraft manufacturers to show their software’s compliance to the objectives defined in DO-178C. There are 66 objectives for Level A. Makers of aircraft and avionics that use software must always adhere to DO-178C standards in developing and testing software whenever these systems are to be approved by the FAA. A manufacturer could use another standard to certify its software to meet FAA requirements, but the burden of proof would be on the manufacturer.
IEC 61508 is the standard for industrial functional safety. It specifies the functional safety standards for the lifecycle of industrial electrical, electronic, or programmable electronic systems and products. This standards document focuses on the components of an industrial device or system that perform automated safety functions, including sensors, control logic, actuators, and microprocessors.
ISO 26262, “Road vehicles – Functional safety,” is the international standard for functional safety of electrical and/or electronic systems in automobiles and road vehicles. It was originally defined in 2011 by the International Organization for Standardization, then revised in 2018.
This IEC Standard is also known as “Medical device software – Software life cycle processes.” Software is often an integral part of medical device technology, and thus gauging the safety of these devices depends on knowledge of what the software is intended to do and being able to demonstrate that use of the software fulfills those intentions without causing any unacceptable risk.

This standard provides a framework of lifecycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. It provides requirements for each lifecycle process and further divides those processes into sets of activities, most of which are then further divided into sets of tasks.
Functional safety is designed to ensure that any product automatically prevents dangerous, life-threatening, or injury-inducing incidents that threaten humans or the environment about the product. Additionally, functional safety systems can cut costs and improve efficiency of operations.
The main aspects of functional safety are to design and build automatic safety functions into equipment, a device, or a system such that it operates in a manner that prevents or stops a potentially dangerous situation or mitigates life-threatening injury to humans or to the environment about the product.
Functional safety management is the act of identifying and defining all of the activities of the functional safety lifecycle of a product, equipment, device, or system that are needed to achieve the required level of functional safety to meet the specified functional safety standard.
Functional safety ensures acceptable implementation, operation, and ongoing maintenance of the safety-related functions. This calls for the system to operate as expected when needed and to provide the required safety protection to prevent a hazardous event from occurring and causing injury to people or harm to the environment or the asset.
Certain industries are safety-critical and must comply with safety standards that are specified in their industrial sector. Here is a list of a few functional safety standards:
  • IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems
  • ISO 26262: Automotive
  • IEC 61511: Process industry
  • IEC 62304: Medical devices
  • EN 50126, EN 50128, EN 50129: Railway application (signaling and rolling stock)
  • ISO 25119: Agriculture
A functional safety assessment usually involves an audit of processes and procedures in place for a piece of equipment, a device, or a system to ensure compliance with the specified functional safety requirements for the specific industry. This includes verification for each lifecycle stage and validation of the full set of industry-specific safety requirements.
Each functional safety standard is risk based. In order to apply the standard, some specific industry criteria must be established that define the tolerability of safety risks in the operation and use of the product. It is this level of risk that establishes the stated standard, processes, and validation that must occur and be provided.
Functional safety analysis is the performance of equipment, device, or system usage or activity by a competent senior engineer or systems engineer to determine whether the safety system that is part of the product meets specifications and actually achieves functional safety (that is, it is free of any unacceptable risk). This safety assessment is a critical part of reducing systematic failures.
Automotive or car functional safety is defined and set by the international standard ISO 26262, which pertains to the electrical and electronic systems of the hardware and software components of the vehicle. It provides the requirements that must be met for the safe function of the vehicle systems and the processes, methods, and tools used during development. This functional safety standard makes sure that all appropriate safety levels are met and maintained throughout the vehicle lifecycle.
Since the first automobile rolled out, safety has been a desired feature. As cars have become more advanced, with electrical systems, compute systems, sensors, and an array of systems important to the operation of the vehicle, functional safety has become a requirement. It is important that proper functional safety standards are met that help limit the number of failures in a car and ensure the safety of the driver and passengers.
To prepare its vehicle product to be ISO 26262 compliant, the manufacturer or OEM must obtain evidence or proof from all of the Tier 1 suppliers and supply chain providers of the vehicle's components that their products are ISO 26262 compliant. Then all of this evidence or proof documentation must be packaged and submitted to an ISO-accredited certification organization for analysis and ultimate certification that the vehicle is ISO 26262 compliant.
TÜV is a German safety agency that tests equipment, devices, and systems for functional safety. Its certification for meeting functional safety standards is accepted primarily in Europe. EC is an abbreviation for European Certification. A company can use the EC’s CE mark (from the French phrase “Conformité Européene”) on products that have at least one safety agency mark from an agency recognized in Europe. Hence a product with the TÜV mark can also use the CE mark. The CE mark is recognized in Europe but not in the U.S.

For more than 125 years, the U.S.-based Underwriters Laboratories (UL) has developed thousands of safety standards for a wide variety of products. The UL mark is recognized globally. For a company to use the UL mark on any of its products, the product must meet UL safety standards and adhere to UL inspections.
Automotive Safety Integrity Level, or ASIL, is a risk classification system defined and set by the ISO 26262 standard for the functional safety of road vehicles or automobiles.
Threadsafe functions allow users to implement concurrent functions at the same time. These concurrent functions can be dependent on each other for execution, or they can be independent of each other.
The advantage of functional testing is that it helps ensure customer or end-user satisfaction by producing a higher level of defect-free products/software. It provides the process to ensure that all operation and product requirements are met. Functional testing also helps ensure that all the functionalities of an application, software, or product are working properly.
Safety integrity levels (SILs) are the relative safety levels of risk reduction provided by a safety function for equipment, a device, or a system. A SIL may also target level of risk reduction. SIL is a performance measurement required for a safety instrumented function.
DO-254 and EUROCAE ED-80 define five Design Assurance Levels, commonly referred to as DALs, that describe how critical these components are for safe flight. The DALs run from Level A to Level E, based on the consequence of a failure condition. For example, failure of Level A software would cause (or contribute to) a catastrophic failure condition for the aircraft that would prevent continued safe flight and landing.
  • Catastrophic (Level A): Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft.
  • Hazardous (Level B): Failure has a large negative impact on safety or performance, or it reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or it causes serious or fatal injuries among the passengers. It is safety significant.
  • Major (Level C): Failure is significant but has a lesser impact than a hazardous failure (for example, it leads to passenger discomfort rather than injuries), or it significantly increases crew workload (safety related).
  • Minor (Level D): Failure is noticeable but has a lesser impact than a major failure (for example, causing passenger inconvenience or a routine flight plan change).
  • No effect (Level E): Failure has no impact on safety, aircraft operation, or crew workload.
Commercial off-the-shelf, or COTS, software and hardware are products that already exist and are commercially available to obtain or purchase. Synonymous terms are “off-the-shelf” or “OTS.”
SOUP is an acronym for "software of unknown (or uncertain) pedigree (or provenance).” It refers to safety-critical systems, such as software for medical systems, that have not been developed via a known software development process and may have unknown or no safety-related properties.
Code coverage testing helps determine the amount of the code that has been tested. This assists in accessing the quality of a test suite and analyzing how meticulously a given piece of software has been verified. Simply put, code coverage testing refers to the level at which the source code of the software has been tested.
As a form of subsystem hazard analysis, software hazard analysis is designed to validate specified software closed-box behavior to ensure that it satisfies system safety design constraints. Additionally, it verifies that specified software behavior meets and satisfies general software system safety design criteria.