Functional safety – a kid’s playground?

The boy was 11 years old, and the electric trike was supposed to be a Covid-related father-son project. But suddenly there was a fully functional vehicle on the road. Read on to find out what went wrong in this story, how it relates to the issue of functional safety and why a father is able to sleep soundly again today.

Header_Safety_1093x410

Without a concept, you are sure to fail

To get straight to the point - I had to choose an example for the structure of our CADFEM training on functional safety, so I decided to go with what I had actually experienced. The following is a true story. During the Covid phase, my son built a modern soapbox in the basement, which consisted of half a bicycle, an attachment made from aluminum profiles and a standard kit for electrifying bicycles. Soon after, this vehicle was put to the test.

To my great surprise, his idea had work well, perhaps too well. Innocent as we were, we had built a “not-so-street-legal” motorized vehicle in our household but driving at 35 km/h in an urban area goes against nearly every German road traffic law. We therefore had to find a less monitored area, so we took the vehicle to a “Schrebergarten” near a popular swimming lake. There were plenty of private roads there, so we were certainly going to have a bit of fun.

There I was, standing in the spring sunshine in the garden with my shovel, while my son was off on a tour with his vehicle, when suddenly I hear "Dad, Dad… the trike ... the trike is in the lake!". Sure enough, my son had managed to sink the whole thing into the nearby lake. As a father, I was just glad that nothing serious had happened to my son. Every parent in the world would be able to understand what was really going on in the back of my head: pure fear, of course. But were my fears justified? That's exactly what I wanted to find out. Now was the perfect time to unleash Medini Analyze upon our situation. This professional software from the automotive safety sector would certainly be able to clarify what was really going on.

Tech_Article_Safety_03_Hazard_DrowningAnimation

Unsuspecting, the father is working in the garden while an emergency occurs at the lake. | © CADFEM Germany GmbH 


HARA - what is the risk of malfunctions?

What had gone wrong? It was simple. My son’s trip took him to the shore of the lake. There were pleasant sunbathing lawns alongside this quarry pond and my son stopped to take a photo of the surroundings in the beautiful weather. As he got off the trike, he didn't notice that it was parked on a slope. It started rolling and soon disappeared into the water at a depth of 4-5 meters. We were now dealing with a very special use case of the vehicle.

HARA (Hazard Analysis & Risk Assessment) is the first ever analysis in the creation of safety concepts in the automotive industry. Translated into this language, we first deal with the "Safe Parking" function for the e-Trike, which in its negation would become "Safe Parking not possible". In essence, the process is: “function” to “malfunction” to “conclusion”. Conclusions are derived from the comparison of malfunctions in various scenarios with respect to the vehicle usage. And this is where the weakness of the fun-oriented homemade trike became apparent; no technical device that could have ensured robust parking.

Now let this scenario play in your mind: if you park (normally) on level ground, this problem doesn’t occurs. But if you park on a slope, of course trouble can arise. In the HARA, there are 3 factors – "Severity", "Exposure" and "Controllability" – which are used to determine the ASIL (Automotive Safety Integration Level). If this is A or B, there is a risk. From C and D, life and limb are in serious danger. To our surprise, the supposedly critical situation at the lake is actually only at level A. This is due to the "exposure" value. The likelihood of parking directly on the slope towards the lake is very low, so you assume you have the all-clear signal.

Tech_Article_Safety04_HARA

In HARA (Hazard Analysis & Risk Assessment), hazard scenarios are examined, and safety targets are derived for critical malfunctions. | © CADFEM Germany GmbH 


ASIL: from safety goal to technical concept

All well and good - but now I was hooked. I was sitting here in front of a tool that seemed to be quite suitable for sorting out my thoughts and making the design concept more secure. What could be done to change the concept for "E-Trike 2.0"? According to the ISO 26262 standard, the ASIL class leads to the obligation to define safety goals to prevent certain risks ("hazards"). In our case, this meant

  1. Ensuring that the e-Trike cannot roll away when parked
  2. If the e-Trike falls/rides into a body of water, it should not sink to the floor

These points could be implemented using a parking brake, an automatic roll-away lock and an automatic floatation mechanism. The second point in particular is a maximum requirement, based on the idea that the boy could have been pulled underwater by the trike. Besides, the water is just too cold in April, and I never want to dive to a depth of 4 meters again at that time of year to recover an object.

Let’s get back to the concept creation process. Safety objectives are further substantiated with more and more detailed specifications for implementation (the "requirements"). Here it becomes clear that a parking device is completely missing from the e-Trike architecture and needs to be installed. This changes a lot in the project. Safety-relevant extensions to the functional concept must be made, which of course also increases the number of possible malfunctions at the next level. And a technical concept for implementation must be created, which can also fail.

Tech_Article_Safety_05_FSC_TSC_Overview_Part1

Tech_Article_Safety_05_FSC_TSC_Overview_Part2

Based on the safety goals, requirements can be formulated and implemented as a concept at the functional level. | © CADFEM Germany GmbH 


FMEA: inductive analysis of cause and effect

It is therefore now necessary to examine the technical level further and link the results of the analysis(es) with the functional level. The FMEA (Failure Mode and Effects Analysis) is classically suitable for this. In principle, it starts at the lowest system level of technical failure and generally links the cause of the failure with its immediate effect. We can apply it several times in our concept in order to link the corresponding design levels: first in the technical concept, and then for the functional concept.

This approach can run into complexity, as functional safety always demands the traceability of information in all steps involved. With a process based on tables, incorrect and/or duplicate entries would cause problems and the introduction of cross-file links would pose further challenges. With Medini, none of these problems were noticeable. On the contrary, since the software is model-based and I had already defined the concepts at all levels as an of architecture, I was able to derive my analyses directly from this with just one click.

For the e-Trike, I designed an immobilizer into the rear axle brake system and analyzed it via a FMEA. This worked wonders for the targeted safety concept. It was now clearly possible to park the trike safely. Of course, you also have to ensure that the system is functional, which can be achieved by considering "detection" and "prevention" of the cause of the fault. Being a motorcyclist myself, this was particularly enjoyable. This is where measures such as visual inspection, brake testing at the vehicle level and regular vehicle maintenance came into play.

Tech_Article_Safety_06_FMEA_RearDrive

The FMEA (Failure Mode and Effects Analysis) links malfunctions with technical failures and enables measures to be taken to detect and/or prevent them. | © CADFEM Germany GmbH 


FTA: the deductive approach via fault trees

Still, something was not quite right. For parking, it is not necessary for the braking effect of both rear brakes to be applied; one would be sufficient to prevent rolling. The FMEA cannot represent this issue, as it can only show linear, direct correlations: "Brake fails" directly leads to "safe parking not possible". In order to represent the principle of redundancy in the safety concept, another method was needed that could represent logic. The FTA (Fault Tree Analysis) does exactly that, plus it offers a top-down approach that works in synergy with the FMEA.

As an analysis, the FTA starts at the top with the violation of the safety goal. From there, events can be linked via Boolean logic to describe the occurrence of the top-level event. Once again, I realized how practical the model-based approach was. Any previously created model, be it in the architecture, a malfunction or an already defined failure, could be automatically used as an event with a simple drag-n-drop. The software automatically ensures traceability by linking the created event to the source model.

And so I very quickly got what I wanted. In the FTA, I was able to clearly describe that, in the event of failure when parking, the left AND right rear brakes must not be locked. That was much more realistic! But as always, you want more; my focus then quickly turned to the possibility of quantitatively modeling the probability of events occurring.

Tech_Article_Safety_07_FTA_RearDrive

The FTA (Fault Tree Analysis) formulates events and uses Boolean logic to further analyze the violation of safety objectives or malfunctions. | © CADFEM Germany GmbH 


Quantification: playing it safe

Quantification - this is where we have to step on the brake ourselves, otherwise there would be no end to this article. In Medini Analyze, there is an incredible amount that can be done in this respect. Libraries with failure rates and failure modes, access to catalogs such as those from the SN 29500 standard, the calculation of quantitative properties based on the underlying formulas as a function of temperature, mission profiles, etc., are all possible. This is absolutely the right approach for detailed analyses of electronic components, although for my rather low-level analysis here, I actually did not need that much functionality.

Still, I couldn't resist and created a yet another fault tree. My aim this time was to check the overall safety concept. I wanted to assess the occurrence of all events that had gone wrong, but also to examine the effectiveness of safety mechanisms such as the parking brake, the anti-roll automatic and the float system. And again, my eyes were very quickly opened. I simply defined and linked events with rough and conservative, fixed probabilities of occurrence for all situations. The scenario unfolded interactively in front of me in the software.

The trick was to use the "AND" gates in FTA. If you systematically build up how the trike-in-the-lake scenario came about, you can estimate a probability of 0.075%. That in itself is already very low and reflects the outcome from the HARA very well in terms of a low ASIL class. Yet, safety mechanisms could now be built in and the concept probed step by step. The parking brake allows us to arrive at 0.015% probability for a goal violation, the automatic roll-away reduces the scenario to 0.0003% and adding the automatic flotation system finally arrived at a probability of only 0.000006% for the e-Trike sinking into the lake.

Tech_Article_Safety_08_FTA_Quantitative_Part1

Tech_Article_Safety_08_FTA_Quantitative_Part2

In quantitative FTA, the probability of an event occurring can be derived from the underlying events across many levels. | © CADFEM Germany GmbH 


With a good concept, it will certainly work ...

As I am writing this, I am actually out in the Schrebergarten looking at version 2.0 of the e-Trike. After we pulled the first version out of the lake, we needed a few weeks to dismantle everything and allow the electronics to dry out. Unfortunately, the battery did not survive its adventure, but the rest could be successfully reanimated with the help of a hairdryer and a bit of patience. After re-assembly, the safety concept for parking was integrated, which consists of a simple piece of rope and a cable tie. This might seem like overly straight-forward solution, but up until now, it has proven to be extremely effective.

I myself am delighted with how this story unfolded. Based on the analyses I performed, and the knowledge gained, I can sleep extremely peacefully today. I am quite convinced that I will be spared from taking freezing-cold April baths in lakes in the future. What I found most interesting, however, was that I was able to realize how much a fear-based, emotional assessment of a situation differs from a rational concept based on analysis. When it comes to safety, it always boils down to the assessment of residual risks that we of course want to minimize but never will be able to completely rule out.

Let's now come to a conclusion. I was able to apply Medini Analyze to a real application and experienced an efficient and powerful tool for the purpose of setting up a safety concept and executing related analyses. Preparing the entire training course took a lot more time than the coverage of the base practices described here. The devil is in the details and these are meticulously recorded in the projects in checklists so that the participants can understand exactly how any model or work product is created. But all the work seems worth-while and the story well-chosen. Speaking about the e-Trike, I regularly manage to put a smile on people's faces. And after all, fun is still the healthiest basis for success in learning.

Tech_Article_Safety_09_eTrike2.0_ParkingBrake

The e-Trike was salvaged from the lake, dried out and rebuilt. In the new version, a very simple but efficient immobilizer adorns the handlebars. | © CADFEM Germany GmbH 

Training on the topic

Let’s Simulate on the topic

Author

Jan Seyfarth

Business Development Manager, Functional Safety

+49 (0)8092 7005-561
jseyfarth@cadfem.de

Editor

Dr.-Ing. Marold Moosrainer

Head of Professional Development

+49 (0)8092 7005-45
mmoosrainer@cadfem.de

Cover images: © CADFEM GmbH | Getty Images