What is a domain controller? Why are OEMs moving to domain controllers?

01

Functional safety of domain controller (DC) ECU

With the emergence of attractive user experience, electrification and automotive ADAS functions, vehicle architecture is strongly moving towards domain controllers. In this article, let's explore the following aspects:

• What is a domain controller? Why should OEMs move to domain controllers?

• What considerations should we have regarding functional safety in domain controllers?

• If multiple vendors are involved in the development of a domain controller, what challenges exist and how are they addressed?

• What is a domain controller? Why should OEMs move to domain controllers?

Traditional automotive architecture is decentralized and distributed, with one ECU typically implementing one feature/function. Every time a new feature/function is added, a new ECU is added. This architecture is extremely complex and heavy in terms of wiring (a large number of cables, contacts, fuses, relays, etc.), making it very expensive to arrange all ECUs in a car. In addition, with the increasing focus on autonomous driving and user experience, cars are becoming more and more software-centric. It is necessary to introduce additional applications or new features/functions with software wireless updates without having to add or change hardware. This has prompted automakers to move to a centralized vehicle architecture, in which several ECUs related to a single domain are combined into one ECU. Such an architecture is significantly lighter and simpler in terms of production logistics processes, and leads to improved quality. An ECU that integrates multiple functions in one domain is called a domain controller.

Below is a view of a decentralized traditional vehicle architecture. Each box in the figure represents an ECU.

Below is a view of a vehicle architecture based on a centralized domain controller.

There are domain controllers in different domains:

a. Infotainment DC (Sample Product)

b. ADAS DC (sample product)

c. Powertrain DC (sample product)

A DC implements all functions in a system-on-chip with multiple cores and the required real-time performance and computing power.

Research predicts that overall domain controller penetration will approach 60% by 2028, despite the absence of a concerted effort toward a domain-based architecture.

From the perspective of ISO26262, a domain controller can be considered to implement several "related items" or part of several "related items". For example, an ADAS DC implements different ADAS functions such as ACC, AEB, etc., and can be considered as part of ACC-related items, AEB-related items, etc.

02

What should we consider regarding functional safety in domain controllers?

1. DC architecture is ready to meet the highest ASIL level requirements

Domain controllers are not fixed in terms of features/functionality and will be upgraded, added, and modified during their lifecycle. From a functional safety perspective, the OEM/Tier 1 should be able to "predict" the highest ASIL level required by the DC. The prediction must be made based on the new features that may be added and the ASIL level they will require. The DC's hardware and software architecture should be designed to meet the requirements of this highest ASIL level.

For example, let’s take a cockpit domain controller that currently has an ASIL-A safety target. It has an ASIL-A compliant SoC and a SW architecture that has an ASIL-A operating system and two ASIL-A and QM partitions.

Now, if this DC achieves ASIL-B safety goals in the future, its existing architecture will not be able to support it. The SoC and OS need to be replaced with ASIL-B compliant SoC and OS, and an additional partition needs to be created for ASIL-B. The hardware design of the DC may also need to be modified to achieve the required hardware indicators.

In the example above, the cockpit DC architecture is not scalable to support new safety goals at higher ASIL levels. This kind of predictive flaw is exactly what must be avoided.

Let’s take another example of an ADAS domain controller that currently supports an ASIL-C architecture and has a camera sensor that is ASIL C. If this DC must support an ASIL-D safety target in the future, its existing hardware architecture does not support it. In this case, the DC must 1) upgrade to an ASIL-D rated camera sensor, or 2) perform ASIL decomposition between the camera and another redundant sensor that is at least ASIL-A, and the other sensor must be considered in the DC’s architecture.

2. Existing security features not affected by software upgrades

When a SW upgrade is made on the road, this should not affect other already qualified safety features, otherwise re-qualification will be required every time even if there is no changed functionality, making it an extremely expensive affair.

3. Implement fail-safe, fail-downgrade and fail-operation requirements for multiple functions

Whether it is a traditional ECU or a DC, the principles of implementing fail-safe, fail-degraded, and fail-operational requirements are the same. However, the interesting thing about DC is that there are several safety functions coexisting with a wide variety of fail-safe, fail-degraded, and fail-operational requirements. It is interesting to implement all of these functions in a single system.

A failure in one function should not affect another function unless they are related to each other. Otherwise, it will lead to a complete loss of availability of all functions. For example, in the instrument cluster-audio domain DC, if the audio system fails, the instrument cluster should still be able to function and provide the driver with the required safety notifications and instructions. In an ADAS system, if the lane keeping assist function fails, the performance of the automatic emergency braking function should not be affected.

The system architecture of DC should identify the faults that affect each function and only move the function to a fail-safe/fail-degraded state when these relevant faults occur, rather than any other faults that do not affect the function. For example, if the emergency brake function uses a radar sensor and the parking assist system uses an ultrasonic sensor, a failure of the ultrasonic sensor will only degrade the parking assist function and the emergency brake function should still be fully available.

If there is a common fault that spans functions and affects all of these functions, such as a CPU failure, this will result in an overall fail-safe condition for all functions.

Fail-operational requirements can often only be achieved by implementing hardware redundancy. For example, a DC can have 2 independent SoCs performing the same processing so that even if one fails, the other SoC continues to provide the functionality. End-to-end redundancy of features must be considered to implement fail-operational behavior. If the function reads some inputs from sensors, redundant sensors can be implemented in the design in case the primary sensor fails. Two independent CAN channels receiving and sending the same messages and redundant actuators are additional aspects that must be considered for a DC with fail-operational features.

03

If multiple vendors are involved in the development of a domain controller, what challenges exist and how are they addressed?

It is common to have different vendors develop different functions of a DC for a variety of reasons. One aspect is the complexity of the system and the development effort required for one vendor to develop the entire system. An even greater challenge is the knowledge/technical expertise required to develop each function. A single vendor may lack the knowledge and expertise to develop all functions.

Whether it is a DC or a traditional ECU, the challenges when dealing with suppliers are very similar. However, the reason we emphasize it here is because DC usually has more suppliers. This makes it obviously more challenging to obtain the required safety dossiers from each supplier and bring them together to provide a safety case for the entire system.

Tier 1 is usually the overall owner of the security concept. Tier 1 suppliers must know what is required of each supplier to gain confidence that risks in the system have been adequately mitigated.

Typical challenges when dealing with suppliers are:

1. The supplier’s responsibilities are vaguely defined.

For example: Let's say a vendor provides a complex IC for DC, such as a Micro or sensor. Should this vendor only provide the hardware, or does the first tier require them to provide any supporting software?

Example 2: If vendor 1 develops feature 1 and vendor 2 develops feature 2, who is responsible for feature 2 not being interfered with by feature 1? Is this the responsibility of vendor 1 or vendor 2 or anyone else?

2. Assume the ASIL level of the hardware/software provided by the vendor.

For example, a vendor may say their hardware/software supports ASIL-B, or say they have a “technology roadmap” for ASIL certification, but the Tier 1 supplier assumes the hardware/software was developed to ASIL-B.

3. The supplier’s timeline for delivering the required ASIL hardware and software does not meet the project deadline.

This is a common problem not only in security but even in other areas. In the case of security, it often happens that the hardware/software is functionally ready on time, but the completion of the security dossier is delayed. As a result, the vendor's security dossier is not completed by the project's deadline.

Uncertainty in supplier responsibility is caused by a lack of clear definition of roles and responsibilities of each supplier in the DIA. Supplier DIAs are often blindly reused from previous projects without fully considering the challenges and context of the currently developed project. This must be avoided. If possible, the supplier DIA must be evaluated during the RFQ phase. During the implementation of the safety concept, all real-time challenges must be considered upfront. Instead of doing a post-mortem analysis after things have gone wrong, it is better to do a pre-mortem analysis at the beginning of the project to understand what should have been considered right at the beginning to prevent failures.