Is the term Functional Safety new to you? Chances are that you are aware of ways that Functional Safety is present in your life – you probably just did not know until now that there is an entire industry dedicated to streamlining safety into equipment and devices we often use.
The objective of this article is to provide a non-technical, high-level overview of Functional Safety and to serve as brief introduction to Functional Safety.
By the end of this article, you will be able to:
2 Why is Functional Safety important?
4 How do we achieve Functional Safety?
4.2 Safety requirements specification
4.4 Verification and validation
6 Certification and safety standards
7.1 Aviation industry: software failure
7.2 Industrial factory: hardware failure
Have you ever noticed that a jet ski will immediately turn off when the driver is thrown off or that doors at a hospital or another public place will automatically lock when an alarm is triggered? These are all prime examples of Functional Safety in practice.
In simple terms, Functional Safety seeks to identify potential risks of equipment, electronics or software and then attempts to limit that risk. Functional Safety specifically addresses the aspects of safety-related to how a device or system functions. By identifying potentially dangerous conditions, situation or events, Functional Safety can then enable corrective or preventive actions to avoid or reduce the impact of an accident.
You may be surprised to realize that Functional Safety is applied all around us – present in our daily lives and in just about every industry you can imagine. Functional Safety is used in a myriad of industries including automotive, aerospace, manufacturing, healthcare, transportation and many more! Any device or system that involves human interaction or has the potential to cause injury or harm if it malfunctions can be improved with Functional Safety.
Functional Safety limits the risk of injury or harm in industrial factories, protects while we are driving down the road, and helps the rail industry limits any potentially damaging or harmful mistakes to its team, drivers, and rail equipment.
Figure 1: Phases of the safety lifecycle
Source: HIMA Group
Let’s take for example the cars we drive every day. It is thanks to Functional Safety that the airbags are deployed instantly in the event of an accident to protect you but not deployed when you are just driving down the road. Functional safety ensures that elevator doors remain closed while in movement yet do not close on a person when standing in the way. Functional safety controls the amount of life-saving medicine a patient gets and alerts medical staff of any changes in the patient’s condition.
|
Time to reflect: |
|
Take ten minutes to think of three electronic devices or systems you use regularly that could cause harm to you, your pets and/or the environment you live in. Can you identify the application of Functional Safety features in these devices? |
Though you may not have been aware of Functional Safety, you are surrounded by its application – at home, school, work and in public spaces. Without Functional Safety mechanisms, most electronic devices or systems can cause harm to people, animals, materials and even the environment. Thanks to advancements in Functional Safety, however, we can reduce these potential risks to a tolerable level, thus limiting the harm electronic devices and systems can cause.
At home, Functional Safety helps us protect our loved ones. Smoke and carbon monoxide detectors, child safety locks on cabinets, rails on our stairways and fire-resistant doors in our garages limit the risks we face at home. At school or university built in sprinklers will automatically spray water in the case of a fire alarm. At factories, machines may automatically turn off in the case of a failure and/or natural disaster.
Note: Smoke detectors at home, work, and school help reduce the risk of injury and fatalities.
Figure 2: Example of smoke detector
Source: HIMA Group
Note: Fire exits facilitate an easy exit point during a fire and may be constructed to stop the fire from advancing.
Figure 3: Example of fire exit
Source: Thaspol
Functional Safety encompasses hardware, software, standalone equipment, and systems as a whole. When assessing and implementing features to address hardware, Functional Safety experts look at a physical electronic device, either as a standalone equipment or as part of a system. For example, experts would implement Functional Safety for a standalone piece of medical equipment such as an incubator used for premature babies. An obvious safety function that would fall under Functional Safety is the incubator’s temperature control. A safety feature would need to identify any rise in temperature that is above a defined amount, turning off the system and altering medical staff. A fault in this could cause great harm to the infant.
Functional Safety also looks at systems as a whole to ensure the risk of harm is minimized to a tolerable level.
A great example of that would be Functional Safety measures implemented in a gas turbine to trigger an automatic shutdown mechanism in the event of a natural disaster. When vibration levels in a gas turbine are detected to reach a defined limit, the system will shut down, preventing damage and injury to workers.
Similar Function Safety features also include emergency stop switches, emergency lighting, fire suppression systems, and warning devices. These devices provide a reliable way to shut down machinery and evacuate personnel in the event of an emergency, ensuring that personnel and equipment are protected from harm.
Though not as tangible as Functional Safety implemented in hardware, Functional Safety measures are also used in software to assess and mitigate risk and harm.
Let’s consider self-driving cars or even the auto-pilot feature on an aircraft. A failure in these systems can lead to serious injury and fatalities. That is where Functional Safety steps in, analyzing the risks the software poses and implementing mitigating safety features.
Note: Functional Safety seeks to minimize any failures in the software of self-driving cars that may cause accidents, injury or harm.
Figure 4: Example of self-driving car
Source: Freepik
How would a self-driving car respond to poor road conditions such as black ice? An experienced drive may be able to quickly identify the ice and respond appropriately. But how will the self-driving car’s software respond? Will it slow down quickly enough? What happens if the auto-pilot software on an airplane does not properly detect where the plane is and how it is moving and suddenly begins to quickly adjust the altitude the plane is flying at causing passengers to fall about in the cabin? These are the types of software risks Functional Safety addresses.
Functional Safety is founded on a safety lifecycle that helps ensure safety-critical systems are developed, implemented, and maintained to a high standard. The safety lifecycle exemplifies that Functional Safety cannot be implemented in an individual effort, but requires ongoing testing, analysis, and implementation. This cycle is ongoing and considers all aspects of a system, device, or software from design to operation with the goal being to reduce risk of accidents.
The safety lifecycle consists of six phases: hazard and risk analysis, safety requirements specification, design and development, verification and validation, operation and maintenance, and decommissioning. Each stage is designed to ensure that the system is designed, tested, and maintained to minimize the risk of accidents and incidents.
Note: The safety lifecycle defines the steps to integrating to Functional Safety.
Figure 5: Phases of the safety lifecycle
Source: HIMA Group
Remember that Functional Safety aims to reduce the potential risk to a tolerable level, thus limiting any negative impact. There is no such thing as zero risk and electrical, electronic, or programmable electronic systems (E/E/PE) that Functional Safety is applied to are complex, making it nearly impossible to identity every potential failure or risk.
So, Functional Safety measures risk by how likely it is that a given event will occur and how severe it would be; in other words: how much harm it would cause. Functional Safety does not aim to remove all risks, but to reduce the risk and potential harm to a level that is tolerable. Ongoing testing is key to identifying potential risk and further reducing the likelihood of harm or failure by implementing further Functional Safety measures.
During phase one of the safety lifecycle – hazard and risk analysis – Functional Safety experts identify and evaluate the different types of risks and potential hazards hardware, software and/or system pose. This phase should be implemented from even before the design phase. Risks identified during this phase will be assessed against the cost and time required to address them. Various techniques and approaches exist in different industries to weigh the risks vs. costs. Some of these include the HAZard and OPerability Study (HAZOP) and What-if Analysis.
During this phase of the lifecycle, Functional Safety experts identify and agree on the safety instruments and systems (also known as safety instrumented system) that will be implemented to reduce the risks and hazards identified in the prior phase. The safety requirements specification describes each safety function in detail and may include requirements for hardware, software and even cybersecurity. This documentation will serve as the starting point for all other phases of the safety lifecycle.
During this phase of the lifecycle, each safety instrumented function – or the mechanism to ensure safety in case of a hazardous event - will be designed and developed in line with the safety requirements specifications. These functions cover various layers of protection and can include sensors, safety valves, transmitters, logic solvers and other auxiliary components such as safety relays and switches.
After the above safety functions are designed, developed, and installed, field testing must be done to ensure everything works as specified. Validation exercises are conducted to ensure that the safety goals are sufficient and have been achieved. If necessary, a modification step will be required. The technical team will assess the root causes of the failures and return to hazard and risk analysis phase.
If testing shows that the functions work as expected in the field environment, then the equipment or project is handed over to the operations team, which may be manufacturers, factory staff, medical staff, etc. This staff is now responsible for the operation and maintenance of the safety equipment until the product and/or operations become obsolete. This is by far the longest phase of the safety lifecycle.
With time, equipment and systems may no longer be of use. This could be because the settings or plant where they are located is too outdated to use, such as an airplane, car, or factory. It could also be because the equipment itself is no longer viable to use – the cost to maintain could be too high, the demand for it could be too low or laws can change that require updates to equipment. If any of these happen, the safety instrumented system will be decommissioned or dismantled and removed. This phase requires preparation and careful implementation, so equipment is dismantled in a safe manner so that no harm is caused to people and or the environment.
Let’s look at the safety lifecycle in a real-world example – an airplane engine manufacturer using the failure modes and effects analysis (FMEA) approach. The manufacturer will want to make sure that the engine is safe and reliable for use in an airplane. Prior to designing and building the engine, the manufacturer will conduct a risk analysis using one of the various approaches. During the hazard and risk analysis phase, the manufacturer will seek to identify all possible failures of the engine. They will review whether certain parts of the engine could lead to failure, including for example a piston or bearing. They will also analyze any potential system failures such as a leak or an ignition system malfunction. Once the potential failures are identified, the manufacturer will analyze the effects of each failure on the engine, the airplane, the passengers, as well as the environment. A fuel leak could, for example, cause a fire that could lead to human injury and damage the plane.
Once these failures and effects are identified, the manufacturer will rate each failure based on the severity of the consequences. This will help them prioritize Functional Safety. For example, the fuel leak that could lead to a fire would have a higher severity rating than a failure that may cause the air conditioning to stop working. In parallel to the severity rating, the manufacturer will evaluate the likelihood of each failure occurring, assigning a probability rating. A failure connected to a part that wears out faster would have a higher probability rating compared to a part that lasts a lifetime. The manufacturer will also analyze the engine’s ability to detect and prevent each failure.
Based on the above risks and hazards, the manufacturer will define the safety requirement specifications which will document this potential failure, ratings and what safety functions are required. This document will be used in the design and development of the airplane engine so that it can take the risk and hazard analysis into consideration.
After the engine is designed and developed, it will be tested during the verification and validation phase to ensure that the findings of the risk analysis and safety requirement specification hold true. For example, the manufacturer would verify that a sensor that is meant to mitigate the risk of fuel leak by alarming airplane maintenance staff works in real life. If validation fails, the manufacturer will return to the risks and hazards phase. Once the engine passes verification and validation, it will be installed in commercial airplanes.
Throughout the life of the engine, the manufacturer will regularly maintain and validate the engine to identity any further risks. The lifetime of an engine is usually around 6000 hours of flight, or the equivalent to 12 years. At that point, the manufacturer will decommission the engine. If a new law was passed that required a major change in airplane engines or the maintenance of an engine becomes more costly than replacing it, the engine may be decommissioned earlier.
| Time to reflect: |
|
Now that you have learned about the six phases of the safety lifecycle, choose one hardware or software, and write a short paragraph about this device and the six phases. Think about the equipment that surrounds you at home, work, university, in public places and/or in factories. You can consider these questions:
|
With Functional Safety relevant to just about every industry – automotive, medical, aviation, nuclear power, oil and gas, manufacturing, rail, etc. – how do we ensure that Functional Safety is properly implemented consistently? This is where international standards and certifications play an important role, providing a consistent framework for Functional Safety implementation. These standards and certifications are unique to each industry and provide a common tool for identifying potential hazards, implementing appropriate safeguards, and evaluating safety performance.
There is an overarching standard that applies to every industry - the so-called umbrella standard for electrical, electronic and programmable electronic safety-related systems - (IEC 61508), and sector-specific standards that apply to a specific industry, such as the automotive industry (ISO 26262), the autonomous driving industry (SOTIF), the rail industry (EN 50128), the medical device industry (IEC 62304) and the nuclear industry (IEC 60880). These standards set out best practices for each industry and cover electronics as well as software. Companies must exhibit that they comply with these standards to get the relevant Functional Safety certification for their products.
Note: Safety standards set by each industry ensure the implementation of Functional Safety best practices.
Figure 6: Examples of Functional Safety standards
Source: HIMA Paul Hildebrandt GmbH
For some industries, certification is required by regulatory authorities and products cannot enter the market without these certifications. Additional certification may be required at the local, national, or international level depending on legislation or even by insurance companies. For other industries it is optional, however, arguably important to gain the trust of end users and can affect a products ability to sell in the market. Getting certified by globally accepted standards can help manufacturers sell their products in different regions without having to get new certification.
Certifications of function safety are assessed by independent organizations that are accredited certification bodies. In most countries there are accreditation bodies, such as ANSI (American National Standards Institute) in the United States, TÜV (Technischer Überwachungsverein) Nord/Süd/Rheinland in Germany, or UKAS (United Kingdom Accreditation Service) in the United Kingdom. These bodies conduct an independent review to determine if the product is designed to be safe and can be safely operated by the target user. The review also considers the risk assessment and mitigation.
On October 29th, 2018, Lion Air Flight 610 was scheduled to fly from Jakarta to Indonesia. Just thirteen minutes after takeoff, the airplane crashed into the Java Sea, killing all 189 passengers and crew on board. This was the first major accident involving the new the Boeing 737 MAX aircraft which was introduced to the aviation industry in 2017. On March 10th, 2019, Ethiopian Airlines Flight 302 was a scheduled to fly from Ethiopia to Kenya but crashed just six minutes after takeoff, killing all 157 people on board. This was again a Boeing 737 MAX aircraft – the second major accident in less than six months.
As with most airline crashes, authorities opened inquires to identify the causes of the crash. The results of these investigations put the blame mostly on the Boeing flight control system known as MCAS (Maneuvering Characteristics Augmentation System). This system relied on just one sensor and this sensor had a failure. There was also no cockpit light to warn the pilots of the failure.
Figure 7: The aircraft involved in the accident
Source: PK-REN, Lion Air Boeing 737-MAX8 PK-LQP, CC BY-SA 2.0
This meant that the pilots were unable to determine the true speed and altitude the airplane was flying at. Each time the pilots pulled the airplane up from a dive, the MCAS would push the nose of the airplane down, causing the terrible accidents. This failure roots back to an update Boeing had made on the engine to make it larger. When Boeing designed the larger engine in its 737 model, instead of making improvements to the hardware or the design of the plane by making space for the larger engines, it moved the engine in front of the plane’s wing. This, in turn, meant that when pilot applied power to the engine, the aircraft would pitch up, or raise its nose.
At that point, Boeing should have returned to the design phases to address required updates to the aircraft’s hardware to fit the larger engine without causing the airplanes nose to rise. Instead, Boeing used software to address the issue of the aircraft pitching up. The reasoning behind this was mostly likely due to the significant cost with hardware updates – the delivery of new planes would be delayed, and it would take time to get certification for these hardware changes. Instead, they installed the MCAS software to automatically move the nose of the aircraft down to counter its rise caused by the location of the engine.
When the Ethiopian Airlines flight crashed, the MCAS reading was not correct, however the software assumed it was correct rather than comparing the reading to the sensor on the other side of the aircraft. In simple terms, the MCAS software was not programmed to confirm data about the plane’s speed and altitude. This failure led to a loss of life as well as the complete destruction of airplanes.
What Boeing should have considered more was the probability rating of this sensor. The single sensor tasked with alarming pilots of issues with the MCAS fails all the time. These sensors can fail when hit by a bird or when they freeze, which should have raised the probability rating.
On a positive note, Boeing has used these two costly disasters as an opportunity to improve its 737 MAX aircraft. Additional layers of protection have been added, including a software improvement that compares data from both sensors. The MCAS will only activate if data from both sensors match, and it will only activate one time. A new alert system was developed to alter pilots when data from the two sensors are not consistent. Lastly, it has been improved so that pilots can adjust when needed. The tragic Lion and Indonesian airlines accidents highlighted several important lessons learned about implementing Functional Safety in software. Software fixes should not be imposed to address issues with hardware and redundancy, especially in sensors and alter systems: this is key to minimizing risk.
On December 3, 1984, more than 40 tons of methyl isocyanate gas leaked from a pesticide plant in Bhopal, India. 3800 people were directly killed by this leak and thousands more experienced long-term health effects and premature death due to this leak. The plant – run by Union Carbide India Limited – was built on a site that was not zoned for hazardous industry. Still the plant was approved by local government officials to formulate small quantities of pesticides from imported component chemicals. However, with time the company went on to manufacture raw materials to formulate these pesticides. This process was inherently more complex and hazardous.
By 1984, the pesticide plant was only running at a quarter of its production capacity due to decreased demand for pesticides. With decreased profitability, the plant decided to close. While the plant made plans to dismantle its equipment and facility, production continued and at standards well below those found at similar plants in other countries. The government knew of these substandard practices but did not intervene out of fears of job loss and the economic implications.
At 11.00 PM on December 2nd, 1984, an operator at the plant noticed a methyl isocyanate (MIC) gas leak and increasing pressure inside a storage tank. However, the safety device designed to neutralize any toxic discharge – a vet-gas scrubber – had been turned off three weeks earlier. In addition to the turning off of that safety measure, a refrigeration unit designed to cool the MIC storage tank had been drained of its coolant so they could use it in another area of the pesticide plant. When a faulty valve allowed water for cleaning internal pipes to mix with forty tons of MIC, pressure and heat from the chemical reaction built up in this tank with no coolant to control the temperature. The gas flare safety system had also been out of service for three months.
Figure 8: Phosgene Tank
Source: HIMA Group
This chemical reaction without proper safety functions led to a release of MIC gas into the streets of Bhopal as its million residents slept peacefully. 3800 people died immediately because of the fume – most of them residents of the impoverished slum next to the plant. Authorities estimate the death toll to be as high as 10,000 over the days following the leak.
With local hospitals overwhelmed and with limited knowledge on the health effects of this gas and the proper medical treatment, thousands more experienced poor health and premature death for decades afterwards. Several studied have confirmed a significant increase in morbidity and mortality among the population exposed to this chemical. This disaster could have sadly been avoided by enforcing international Functional Safety standards, including when decommissioning equipment.
| Time to reflect: |
|
Research one of these disasters and name the causes, impact, and measures taken in response to it.
|
List of references
[1] “Functional safety essential to overall safety | IEC.” https://www.iec.ch/basecamp/functional-safety-essential-overall-safety
[2] “IEC 60050 - International Electrotechnical Vocabulary - Welcome,” IEC - International Electrotechnical Commission. https://www.electropedia.org/
[3] USCSB, “Reflections on Bhopal after thirty years,” YouTube. Dec. 02, 2014. [Online]. Available: https://www.youtube.com/watch?v=HZirRB32qzU
[4] Wikipedia contributors, “Bhopal disaster,” Wikipedia, Feb. 08, 2024. https://en.wikipedia.org/wiki/Bhopal_disaster
[5] Wikipedia contributors, “Lion Air Flight 610,” Wikipedia, Mar. 08, 2024. https://en.wikipedia.org/wiki/Lion_Air_Flight_610