Functional safety: a must for electric vehicle development

Development means responsibility

If something goes wrong and (personal) injury occurs, you as the project manager or business owner must take responsibility for the products developed and sold in the event of liability issues. Functional safety helps you wear them.

Who says I’m liable?

Decades ago, every country enacted product liability laws. The EU created the “Council Directive 85/374/EEC of 25 July 1985 on the approximation of the laws, regulations and administrative provisions of the Member States concerning liability for defective products”, which provides the following (please note this text whas been auto translated):

“(…) Consumer protection requires that all parties involved in the production process be liable if the final product or the ingredient or raw material they supplied was defective. For the same reason, the person who imports products into the Community, as well as any person who purports to be the manufacturer by affixing his name, trademark or other distinctive mark, or who supplies a product whose manufacturer cannot be identified, shall be liable. (…)

In order to protect the consumer (…), the determination of the defectiveness of a product must not be based on its lack of usability, but on a lack of safety, (…). In assessing this safety, any misuse of the product shall be disregarded, (…).

(…) that it must be possible for the manufacturer to exempt himself from liability if he provides evidence of circumstances exonerating him. (…)

Consumer protection requires the recovery of damages caused by death and bodily injury, as well as the recovery of property damage. (…).“

Of course, Switzerland also has corresponding laws. These are known as the “Federal Law on Product Safety (PrSG) – Art. 930.11” and the “Federal Law on Product Liability (PrHG) – Art. 221.112.944” and have very similar content to that of the EU.

The legal texts are written in a complex manner and are not always easy to understand in detail. If you look at case law (laws applied to individual cases), the picture becomes clearer. The last decades have shown that the manufacturer is guaranteed to be liable for the following types of defects:

• Development errors (requirement, system design, specification)
• Design flaw
• Manufacturing defect
• Instruction error
• Violation of the product monitoring obligation

People make mistakes in development, production and – not to be neglected – in operation. Even if, in the distant future, automated systems are developed, produced and even operated by machines from start to finish, wear and tear on components will remain. This includes not only mechanical but also electrical components. The man-made error, or wear and tear cause a fault in the machine, which can be a hazard. The task of functional safety is to protect people and the environment from hazards caused by faults in (automated) systems. It also helps clarify liability in the event of a legal conflict.

Why doesn’t everyone do functional safety?

All companies that claim “Safety First” would have to develop all products within the framework of Functional Safety. The following obstacles and mistakes cause these companies not to adhere to their own credo.

From the perspective of development

The following challenges arise in the context of product development. They are not useful for proving a safety level.

Incorrect specifications

The engineering world is specification and requirements driven. Based on technical requirements, products and services are developed that have the task of fulfilling the intended function. This excludes all functions or mechanisms that are not explicitly mentioned.

Developments are iterative processes

Product development often goes through multiple iterations where components are evaluated and swapped. If safety-critical components are changed, they must be incorporated into the functional safety process.

Safety costs time and money

A function that not only fulfills the technical requirement but also includes safety aspects results in a main function that has secondary functions, thus increasing complexity. Thus, a product will take more time in the development phase and thus be more expensive overall.

Developments are creative processes

When it comes to developments, you can rarely rely completely on 08/15 components and therefore look for creative solutions. In Functional Safety, these have to be analyzed in detail, which has an impact on time and costs.

The following topics are formed from the nature of functional safety and its regulations:

Functional safety is not a feature

Functional safety is subtle. In concrete terms, this means that often not the entire product fulfills a safety level, but only a partial function of a subsystem (e.g. a shutdown path).

Functional safety is part of the development

A product with a safety level requires the entire development of the product and its documentation.

An existing product cannot be upgraded to a security level

Once a product has been developed, it is not possible to subsequently install other components with the expectation that safety levels will be achieved.

Functional safety is part of the business processes

Furthermore, not only developers, but also production and management have tasks and responsibilities.

In order to save on development resources, one cuts back on functions that do not have a security level requirement (beware of specification errors!). Then there are only errors from requirements, or errors from the wrist of the engineer, which may be covered by countermeasures.

This leads to a black-and-white view of problems. These problems or errors then fall into either the “procedural alarm” or “emergency shutdown” category.

In other words, does the error interfere with the process, or not? For functions that do not have a requirement for the security level, this is not wrong either. A good engineer asks himself during the development if the condition of the machine is dangerous for people. Most of these safety considerations are gut feelings or experience of an engineer and do not come from a hazard and risk analysis (H&R). Furthermore, thoughts of availability always resonate. The engineer doesn’t want to have to force a shutdown because of every little problem. Thus, each engineer weighs “safety relevant” differently.

Functional safety has its origins in the machine industry. This has created a general set of rules in the form of IEC/EN 61508. Industry-specific standards were derived from this (homologated). In order to understand the industry-specific standards, knowledge of ISO 12100 and EN 61508 is of great advantage.

Do you speak functional safety?

The world of safety is exclusively permeated by standards, which bring with them their own vocabulary. As in any engineering discipline, it’s hard to get ahead without the jargon. The general EN 61508 has 29 pages of term definitions and the industry-specific ISO 26262 has 32 pages of vocabulary and abbreviations.

Everyone joins in!

Functional safety not only expects extra performance from the development department, but also from other departments. Management must also align supporting business processes with functional safety and be present and involved in top-level reviews. If the device or vehicle is produced in-house, the production processes must also be designed for this.

Calculated death

Regardless of the industry, Functional Safety uses probability of occurrence and hazard. The two numbers are then used to calculate the risk to which the persons are exposed. It also calculates how likely fatalities are during operation of the machine.

Operation and maintenance

The functional safety not only defines the development and production, but also puts emphasis on the correct operation and maintenance. Therefore, not only the development documentation, but also the customer documentation is an important part of an functional safety development.

When deciding whether to develop a product in the context of functional safety, it is important to consider the tool chain. This helps in all phases of development at the technical level and has building blocks aligned with functional safety documentation.

The development of the product in the Durot tool chain starts with the analysis of the requirements specifications and the modeling of the product in SYSML / UML in the SW tool “SOX”. These are the basic building blocks upon which the Hazard & Risk Analysis (H&R) is created. This in turn is the basis for all subsequent steps and classical engineering.

The development of the product in the Durot tool chain starts with the analysis of the requirements specifications and the modeling of the product in SYSML / UML in the SW tool “SOX”. These are the basic building blocks upon which the Hazard & Risk Analysis (H&R) is created. This in turn is the basis for all subsequent steps and classical engineering.

For functional safety development – like classical engineering and safety engineering – a reliable tool chain is indispensable and unfortunately also cost-intensive, since each design level must be tested. This also includes a hardware-in-the-loop (HIL) test. This setup – in our case with Vector – simulates for example the specified HW environment of a VCU. During this HIL test, all possible combinations of error conditions or faulty manipulations are tested and the reaction of the developed VCU is recorded.

For functional safety development – like classical engineering and safety engineering – a reliable tool chain is indispensable and unfortunately also cost-intensive, since each design level must be tested. This also includes a hardware-in-the-loop (HIL) test. This setup – in our case with Vector – simulates for example the specified HW environment of a VCU. During this HIL test, all possible combinations of error conditions or faulty manipulations are tested and the reaction of the developed VCU is recorded.

Even if you have done everything right in the design, functional safety and testing, errors can occur that lead to the death of a person. FuSi helps you prove that you have done enough technically and organizationally to avoid this.

GPA, the
Part of speech: noun, masculine
Meaning: Abbreviation for “Greatest Probable Accident”,
or most severe fault that can occur in a system.
[und für den beim Bau der Anlage entsprechende Sicherheitsvorkehrungen zu treffen sind].

DAU, the
Part of speech: noun, masculine
Meaning: Abbreviation for “Dumbest Assumed User”,
or most serious operating errors that the user can cause in a system.
[und für den beim Bau der Anlage entsprechende Sicherheitsvorkehrungen zu treffen sind].