Functional safety

Last updated

Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely systematic errors, hardware failures and operational/environmental stress.

Contents

Objective

The objective of functional safety is freedom from unacceptable risk of physical injury or of damage to the health of people either directly or indirectly (through damage to property or to the environment) by the proper implementation of one or more automatic protection functions (often called safety functions). A safety system (often called a safety-related system) consists of one or more safety functions.

Functional safety is intrinsically end-to-end in scope in that it has to treat the function of a component or subsystem as part of the function of the entire automatic protection function of any system. Thus, although functional safety standards focus on electrical, electronic, and programmable systems (E/E/PS), the end-to-end scope means that in practice, functional safety methods must extend to the non-E/E/PS parts of the system that the E/E/PS actuators, valves, motor controls or monitors.

Achieving functional safety

Functional safety is achieved when every specified safety function is carried out and the level of performance required of each safety function is met. This is normally achieved by a process that includes the following steps as a minimum:

  1. Identifying what the required safety functions are. This means the hazards and safety functions have to be known. A process of function reviews, formal HAZIDs, HAZOPs and accident reviews are applied to identify these.
  2. Assessment of the risk-reduction required by the safety function, which will involve a safety integrity level (SIL) or performance level or other quantification assessment. A SIL (or PL, AgPL, ASIL) applies to an end-to-end safety function of the safety-related system, not just to a component or a part of the system.
  3. Ensuring the safety function performs to the design intent, including under conditions of incorrect operator input and failure modes. This will involve having the design and lifecycle managed by qualified and competent engineers carrying out processes to a recognized functional safety standard. In Europe, that standard is IEC EN 61508, or one of the industry specific standards derived from IEC EN 61508, or for simple systems some other standard like ISO 13849.
  4. Verification that the system meets the assigned SIL, ASIL, PL or agPL by determining the probability of dangerous failure, checking minimum levels of redundancy, and reviewing systematic capability (SC). These three metrics have been called "the three barriers". [1] Failure modes of a device are typically determined by failure mode and effects analysis of the system (FMEA). Failure probabilities for each failure mode are typically determined using failure mode, effects, and diagnostic analysis FMEDA.
  5. Conduct functional safety audits to examine and assess the evidence that the appropriate safety lifecycle management techniques were applied consistently and thoroughly in the relevant lifecycle stages of product.

Neither safety nor functional safety can be determined without considering the system as a whole and the environment with which it interacts. Functional safety is inherently end-to-end in scope. Modern systems often have software intensively commanding and controlling safety-critical functions. Therefore, software functionality and correct software behavior must be part of the Functional safety engineering effort to ensure acceptable safety risk at the system level.

Certifying functional safety

Any claim of functional safety for a component, subsystem or system should be independently certified to one of the recognized functional safety standards. A certified product can then be claimed to be functionally safe to a particular safety integrity level or a performance level in a specific range of applications: the certificate and the assessment report is provided to the customers describing the scope and limits of performance.

Certification bodies

Functional safety is a technically challenging field. Certifications should be done by independent organizations with experience and strong technical depth (electronics, programmable electronics, mechanical, and probabilistic analysis). Functional safety certification is performed by accredited certification bodies (CB). Accreditation is awarded to a CB organization by an accreditation body (AB). In most countries there is one AB. In the United States, the American National Standards Institute (ANSI) is the AB for functional safety accreditation. In the United Kingdom, the United Kingdom Accreditation Service (UKAS) provides functional safety accreditation. ABs are members of the International Accreditation Forum (IAF) for work in management systems, products, services, and personnel accreditation or the International Laboratory Accreditation Cooperation (ILAC) for laboratory testing accreditation. A multilateral recognition arrangement (MLA) between ABs will ensure global recognition of accredited CBs.

IEC 61508 functional safety certification programs have been established by several global Certification Bodies. Each has defined their own scheme based upon IEC 61508 and other functional safety standards. The scheme lists the referenced standards and specifies procedures which describes their test methods, surveillance audit policy, public documentation policies, and other specific aspects of their program. Functional safety certification programs for IEC 61508 standards are being offered globally by several recognized CBs including Intertek, SGS, TÜV Rheinland, TÜV SÜD and UL.

An important element of functional safety certification is on-going surveillance by the certification agency. Most CB organizations have included surveillance audits in their scheme. The follow-up surveillance ensures that the product, sub-system, or system is still being manufactured in accordance with what was originally certified for functional safety. Follow-up surveillance may occur at various frequencies depending on the certification body, but will typically look at the product's field failure history, hardware design changes, software changes, as well as the manufacturer's ongoing compliance of functional safety management systems.

Military aerospace

For military aerospace and defense systems MIL-STD-882E addresses functional hazard analyses (FHA) and determining which functions implemented in hardware and software are safety significant. The Functional safety focus is on ensuring safety critical functions and functional threads in the system, subsystem and software are analyzed and verified for correct behavior per safety requirements, including functional failure conditions and faults and appropriate mitigation in the design. These system safety principles underpinning functional safety were developed in the military, nuclear and aerospace industries, and then taken up by rail transport, process and control industries developing sector specific standards. Functional safety standards are applied across all industry sectors dealing with safety critical requirements and are especially applicable anytime software commands, controls or monitors a safety-critical function. Thousands of products and processes meet the standards based on IEC 61508: from bathroom showers, [2] automotive safety products, sensors, actuators, diving equipment, [3] Process Controllers [4] [5] [6] and their integration to ships, aircraft and major plants.

Aviation

The US FAA have similar functional safety certification processes, in the form of ARP4761, US RTCA DO-178C for software and DO-254 for complex electronic hardware, [7] [8] which is applied throughout the aerospace industry. Functional safety and design assurance on civil/commercial transport aircraft is documented in SAE ARP4754A as functional design assurance levels (FDALS). The system FDALs drive the depth of engineering safety analysis. The level of rigor (LOR) or safety tasks performed to ensure acceptable risk are dependent upon the identification of specific functional failure condition and hazard severity relating to the safety-critical functions (SCF). In many cases functional behavior in embedded software is thoroughly analyzed and tested to ensure the system functions as intended under credible fault and failure conditions. Functional safety is becoming the normal focused approach on complex software intensive systems and highly integrated systems with safety consequences. The traditional software safety tasks and model based functional safety tasks are performed to provide objective safety evidence that the system functionality and safety features perform as intended in normal and off nominal failures. The entry point of functional safety begins early in the process by performing Functional Hazard Analyses (FHA)to identify hazards and risks and to influence the safety design requirements and functional allocation and decomposition to mitigate hazards. The behavior of the software and SCFs at the system level is a vital part of any functional safety effort. Analyses and implementation results are documented in functional hazard assessments (FHA) or system safety assessments or safety cases. Model-based functional safety processes are often used and required on highly integrated and complex software intensive systems to understand all of the many interactions and predicted behavior and to help in the safety verification and certification process.

Safety Review Boards

At Boeing, a Safety Review Board (SRB) is responsible for deciding only if an issue is or is not a safety issue. An SRB brings together multiple company subject-matter experts (SMEs) in many disciplines. The most knowledgeable SME presents the issue, assisted and guided by the Aviation Safety organization. The safety decision is taken as a vote. Any vote for "safety" results in a board decision of "safety". [9]

Space

In the US, NASA developed an infrastructure for safety critical systems adopted widely by industry, both in North America and elsewhere, with a standard, [10] supported by guidelines. [11] The NASA standard and guidelines are built on ISO 12207, which is a software practice standard rather than a safety critical standard, hence the extensive nature of the documentation NASA has been obliged to add, compared to using a purpose designed standard such as IEC EN 61508. A certification process for systems developed in accord with the NASA guidelines exists. [12]

Automotive

The automotive industry has developed ISO 26262 "Road Vehicles Functional Safety Standard" based on IEC 61508. The certification of those systems ensures the compliance with the relevant regulations and helps to protect the public. The ATEX Directive has also adopted a functional safety standard, it is BS EN 50495:2010 "Safety Devices Required for the Safe Functioning of Equipment with Respect to Explosion Risks" covers safety related devices such as purge controllers and Ex e motor circuit breakers. It is applied by notified bodies under the ATEX Directive. The standard ISO 26262 particularly addresses the automotive development cycle. It is a multi-part standard defining requirements and providing guidelines for achieving functional safety in E/E systems installed in series production passenger cars. ISO 26262 is considered a best-practice framework for achieving automotive functional safety. [13] The compliance process usually takes time as employees need to be trained in order to develop the expected competencies.

Contemporary functional safety standards

The primary functional safety standards in current use are listed below:

The standard ISO 26262 particularly addresses the automotive development cycle. It is a multi-part standard defining requirements and providing guidelines for achieving functional safety in E/E systems installed in series production passenger cars. The standard ISO 26262 is considered a best practice framework for achieving automotive functional safety. [13]

See also

Related Research Articles

<span class="mw-page-title-main">Safety engineering</span> Engineering discipline which assures that engineered systems provide acceptable levels of safety

Safety engineering is an engineering discipline which assures that engineered systems provide acceptable levels of safety. It is strongly related to industrial engineering/systems engineering, and the subset system safety engineering. Safety engineering assures that a life-critical system behaves as needed, even when components fail.

<span class="mw-page-title-main">Safety-critical system</span> System whose failure would be serious

A safety-critical system or life-critical system is a system whose failure or malfunction may result in one of the following outcomes:

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

In functional safety, safety integrity level (SIL) is defined as the relative level of risk-reduction provided by a safety instrumented function (SIF), i.e. the measurement of the performance required of the SIF.

A hazard analysis is used as the first step in a process used to assess risk. The result of a hazard analysis is the identification of different types of hazards. A hazard is a potential condition and exists or not. It may, in single existence or in combination with other hazards and conditions, become an actual Functional Failure or Accident (Mishap). The way this exactly happens in one particular sequence is called a scenario. This scenario has a probability of occurrence. Often a system has many potential failure scenarios. It also is assigned a classification, based on the worst case severity of the end condition. Risk is the combination of probability and severity. Preliminary risk levels can be provided in the hazard analysis. The validation, more precise prediction (verification) and acceptance of risk is determined in the risk assessment (analysis). The main goal of both is to provide the best selection of means of controlling or eliminating the risk. The term is used in several engineering specialties, including avionics, food safety, occupational safety and health, process safety, reliability engineering.

<span class="mw-page-title-main">ARP4754</span>

ARP4754, Aerospace Recommended Practice (ARP) ARP4754B, is a guideline from SAE International, dealing with the development processes which support certification of Aircraft systems, addressing "the complete aircraft development cycle, from systems requirements through systems verification." Revision A was released in December 2010. It was recognized by the FAA in AC 20-174 published November 2011. EUROCAE jointly issues the document as ED–79.

IEC 61508 is an international standard published by the International Electrotechnical Commission (IEC) consisting of methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.

IEC standard 61511 is a technical standard which sets out practices in the engineering of systems that ensure the safety of an industrial process through the use of instrumentation. Such systems are referred to as Safety Instrumented Systems. The title of the standard is "Functional safety - Safety instrumented systems for the process industry sector".

In software engineering, software system safety optimizes system safety in the design, development, use, and maintenance of software systems and their integration with safety-critical hardware systems in an operational environment.

In functional safety a safety instrumented system (SIS) is an engineered set of hardware and software controls which provides a protection layer that shuts down a chemical, nuclear, electrical, or mechanical system, or part of it, if a hazardous condition is detected.

MISRA C is a set of software development guidelines for the C programming language developed by The MISRA Consortium. Its aims are to facilitate code safety, security, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C / C90 / C99.

Spurious trip level (STL) is defined as a discrete level for specifying the spurious trip requirements of safety functions to be allocated to safety systems. An STL of 1 means that this safety function has the highest level of spurious trips. The higher the STL level the lower the number of spurious trips caused by the safety system. There is no limit to the number of spurious trip levels.

<span class="mw-page-title-main">LDRA</span> Software companies of the United Kingdom

LDRA is a provider of software analysis, test, and requirements traceability tools for the Public and Private sectors. It is a pioneer in static and dynamic software analysis.

ISO 26262, titled "Road vehicles – Functional safety", is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles, defined by the International Organization for Standardization (ISO) in 2011, and revised in 2018.

TargetLink is a software for automatic code generation, based on a subset of Simulink/Stateflow models, produced by dSPACE GmbH. TargetLink requires an existing MATLAB/Simulink model to work on. TargetLink generates both ANSI-C and production code optimized for specific processors. It also supports the generation of AUTOSAR-compliant code for software components for the automotive sector. The management of all relevant information for code generation takes place in a central data container, called the Data Dictionary.

<span class="mw-page-title-main">Parasoft C/C++test</span> Integrated set of tools

Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.

Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety for Road Vehicles standard. This is an adaptation of the Safety Integrity Level (SIL) used in IEC 61508 for the automotive industry. This classification helps defining the safety requirements necessary to be in line with the ISO 26262 standard. The ASIL is established by performing a risk analysis of a potential hazard by looking at the Severity, Exposure and Controllability of the vehicle operating scenario. The safety goal for that hazard in turn carries the ASIL requirements.

Hercules is a line of ARM architecture-based microcontrollers from Texas Instruments built around one or more ARM Cortex cores. This "Hercules safety microcontroller platform" includes a series of microcontrollers specifically targeted for Functional Safety applications, through such hardware-base fault correction/detection features as dual cores that can run in lock-step, full path ECC, automated self testing of memory and logic, peripheral redundancy, and monitor/checker cores.

Cantata++, or simply Cantata in newer versions, is a commercial computer program for dynamic testing, specifically unit testing and integration testing, and code coverage at run time of C and C++ programs. It is developed and sold by QA Systems, and was formerly a product of IPL Information Processing Ltd.

High-integrity software is software whose failure may cause serious damage with possible "life-threatening consequences." "Integrity is important as it demonstrates the safety, security, and maintainability of... code." Examples of high-integrity software are nuclear reactor control, avionics software, automotive safety-critical software and process control software.

[H]igh integrity means that the code:

References

  1. Van Beurden, Iwan (November 2017). "Safety Instrumented Function Verification: The Three Barriers" (PDF). exida.
  2. "RADA Sense - Shower T3" (PDF). Rada. 2008. Archived from the original (PDF) on 2011-07-15. Retrieved 2009-07-25.
  3. "IEC 61508 Safety Case Example: Diving Equipment". Deep Life. Archived from the original on 2016-03-03. Retrieved 2013-01-22.
  4. "Industrial IT System 800xA High Integrity". ABB.
  5. "IEC 61508 SIL 3 certified RTOS". Green Hills Software.
  6. "SAFETY AUTOMATION ELEMENT LIST". exida.
  7. V. Hilderman, T. Bagha, "Avionics Certification", A Complete Guide to DO-178B and DO-254, ISBN   978-1-885544-25-4
  8. C. Spritzer, "Digital Avionics Handbook, Second Edition - 2 Volume Set (Electrical Engineering Handbook", CRC Press. ISBN   978-0-8493-5008-5
  9. Lie, Simon (2014). In Service Safety at Boeing (PDF). Paper presented at ISASI 2014 Seminar, October 2014, Adelaide, Australia. ISASI.
  10. NASA Software Safety Standard NASA STD 8719.13A
  11. NASA-GB-1740.13-96, NASA Guidebook for Safety Critical Software.
  12. Nelson, Stacy (June 2003). "Certification Processes for Safety-Critical and Mission-Critical Aerospace Software" (PDF). NASA/CR–2003-212806.
  13. 1 2 "26262-1:2011". ISO. Retrieved 25 April 2013.