With the advent of enticing user experience, Electrification and ADAS features in the car, vehicle architecture is strongly headed towards Domain Controllers. In this article, let us discuss the following aspects:
- What is a Domain controller? Why are OEMs going towards Domain Controllers?
- What considerations should we have for functional safety in Domain Controllers?
- In case multiple suppliers are involved in the development of the Domain controller, what challenges exist and how to handle them?
What is a Domain controller? Why are OEMs going towards Domain Controllers?
Traditional vehicle architectures are de-centralized and distributed with one ECU typically implementing 1 feature/function. Every time a new function/feature is added, a new ECU is added. This kind of an architecture is extremely complex and heavy in terms of wiring (lots of cables, contacts, fusing, relays etc) and makes it very expensive to package all the ECUs into a car. Also, with the increased focus on automated driving and User experience, the car is becoming more software centric. There is a need to introduce additional apps or new features/functions with SW over-the-air updates without having to add or change hardware. This has driven OEMs towards a centralized vehicle architecture, where several ECUs related to a single domain are combined into a single ECU. Such an architecture is significantly lighter and simplified in terms of production logistics processes and has an improved quality. An ECU that consolidates several functions of a domain is called a Domain Controller.
Here is a view of a de-centralized traditional vehicle architecture. Each box in this picture represents an ECU.