One of the indisputable facts about the automotive industry is that the overall electronic system content in vehicles is increasing.

As vehicles become more sophisticated and include features that sense, think and act for the driver, the type of electronic content changes. In particular, there will be massive growth in hybrid electric vehicle and electric vehicle content, as well as for automated drive functions.

However, a key issue that needs to be addressed is that the current business model for electric vehicles is not profitable long term for OEMs. The average estimated cost for base electric vehicles is still a major concern.

OEMs will be looking to close this gap by bringing more design back in-house, or by bypassing Tier 1 suppliers to talk directly to IC suppliers. The disrupter here will be to integrate embedded electronic architectures by combining ECUs and clustering functions in a new way.

This is why NXP is working closely with partners across the industry to accelerate how these constraints are met. One way is by developing reference designs that combine our system know-how with our safety expertise. This means that reference designs include key safety system elements from the outset.

To develop safety concepts for system reference designs, NXP has to be able to define the safety goals, concept and functions for the intended item to be able to identify the right system implementation into our system design.

We do this by following the ISO 26262 development process. This provides recommendations for each step along the development process for safety system products with a V cycle project management tool.

The V cycle groups each step as a Part and specific work products are expected at each level. IC suppliers like NXP can anticipate and develop system ECUs just like a Tier 1 supplier does. By doing this, we can speed development time and provide standard deliverables that are of benefit throughout the development chain.

The goal is not necessarily to provide a solution with the same level of maturity that a Tier 1 could provide, rather to accelerate the development of the work products for the Tier 1.

Let’s consider as an example, how to develop a safety concept for a power inverter module as a SEooC for an EV application. As an IC supplier, we would work through parts 3, 4, 5, 6 and 7 of the V cycle and provide the work products associated to each part. We start by defining the item within the target system – i.e. what are the potential hazards and safety goals that we want to apply to our reference design?

Figure 1: HV Inverter for EVs

As figure 1 shows, the power inverter is the main traction system of an electric vehicle. It controls the energy conversion between the electric energy source and the mechanical shaft of the electric motor, based on the torque request from the Vehicle Control Unit (VCU).

The VCU interprets the driver needs into acceleration or deceleration of the electric motor. The inverter translates the torque request into phase currents going into the traction motor.

In a battery electric vehicle, this connection is usually made with a simple gearbox without a clutch. This is our first assumption. It is important to be specific here, since the safety case would be different if the vehicle has a clutch.
In our case, if a hazard should occur, it is impossible for the driver or the electrical system to stop the traction of the vehicle by simply opening the connection between the electric motor and the wheels of the car.

We also need to identify possible sources of EE malfunction – whether due to driving or non-driving scenarios. These hazards are then ranked by risk level according to the ASIL levels laid out in ISO 26262. As shown in figure 2, in this case a safety goal could be to avoid unintended acceleration if the vehicle is stopped.

Figure 2: Examples of hazards and safety goals for an EV HV inverter

These safety goals lead to a functional safety architecture with functional requirements (FR) and functional safety requirements (FSR) with associated ASIL levels and FTTI such as:

Figure 3: Functional safety architecture

Now that we have the functional safety architecture, figure 3, we need to demonstrate that the system architecture will be able to fulfil the safety requirements and design constraints.

To do this, we derived a technical safety concept from the functional safety concept. This combines the hardware and software sub-element functions that will be used to achieve the intended item and system functionality.

A safety analysis is then run to check that all possible system failures have been identified and that the appropriate safety mechanisms are in place. This may result in new safety requirements being allocated to the safety architecture.

By doing this, the technical definition can provide the necessary evidence that the appropriate reactions have been identified and that a safe state can be achieved in less time than FTTI: therefore that there is no violation of the safety goals of the item.

In our example, safe state is complex because of the high amount of energy flowing into the electric motor. A safe state here means stopping the propulsion of the vehicle, by opening or shorting the three phases of the motor depending on the speed of the motor.

As we progress through the V cycle, the work products are developed to ensure the safety concerns a customer may have are fulfilled. A hardware design is covered by the process in the same way; the safety concept reduces the development and prototyping phase for customers by three to six months.

In the NXP reference design, the complete safety architecture is built out using NXP ICs and diagnostics and reaction to safe state are tested. The reference design helps to speed development and provides a level of technical safety architecture, along with evidence of the safety integrity level as part of the overall package.

Find out more about the power inverter reference design here.

Source: https://www.automotive-iq.com/electrics-electronics/articles/power-inverter-safety-system-concept-for-iso-26262