Recently several regions world-wide decided to enforce by law ADAS active safety functions to boost the zero-fatality mission. In Europe the new General Safety Regulation (GSR EU2019/2144) will be mandatory for new type approval from mid-2022 and for all new registrations from mid-2024. The mandatory safety functions are basic SAE Level 0 and Level 1 assistance features, but it pushes the roll-out of ADAS to the entire vehicle fleet, from small entry to large premium class cars.
In parallel, first we have the stepwise launch of the much more complex L3 (temporary automation) pilot features started with the market introduction and second, pilot fleet applications with fully automated connected features (L4) are making remarkable progress – strongly driven by operating cost savings substituting human drivers, preferred in the heavy-duty truck and logistics area.
Different level ADAS/AD features are therefore operating coexistent in several controllers disadvantaging modularity, flexibility and finally also cuts the possibility to balance electrical power consumption accordingly.
Zone computers
Traditionally, in automotive electronic networks, for each feature, the control, sensors, and actuators are treated together as a unit. Typically provided by a tier-1 supplier. For instance, brake actuators, necessary sensors, the ABS and ESP control are treated as a unit. Since there are many features in a vehicle, many such subsystems must be integrated together – also leading to a lot of control units. For ADAS and AD functions, this is currently done in a similar way. For instance, a typical ACC sensor could include the processing for object detection and the calculation of the force ramp for a smooth breaking in the same box.
Currently, an alternative approach is being discussed and first steps are being taken to implement it: Why not the separation of the sensors and actuators from the control, and then centralize the control in bigger, more powerful control units? These central units (zone computers) can replace potentially dozens of little control units. The obvious advantage of such an approach is cost, weight, and power savings because of fewer control units, boxes, and cabling. In addition, the flexibility of the OEM is increased: It is much easier to optimize e.g., sensors if they are not integrated in an all-in-one box that provides functionality of a complete feature set. A tier-1 supplier would have to adopt offerings to separate sensors, actuators, and control software. The processing power would be provided by specialized zone computer makers. Obviously, tier-1’s can then concentrate on part offerings, i.e. only offering the best sensor technique, ignoring the necessary control software know-how – or vice versa.
ADAS/AD example
Let us look at how this could work for ADAS or autonomous driving functionality: We can assume that for cars the minimum requirement is to provide the GSR functions (automatic emergency braking, emergency lane keeping, and others). For this, typically a radar and a camera are used as minimum sensor configuration. Processing power demand is already significant, for object detection of camera and radar data. On the other end of the line are autonomous driving functions that can independently steer the vehicle in certain situations (like on a highway). Such level 3/4 features require many more sensors: Additional radars, cameras and lidars are potentially needed to achieve the necessary view and to add some redundancy for safety.
Zone computers can be used in preparation for this range of requirements. We can summarize the requirements of such a system for the front zone like this.
- Scalable interfaces
- Minimum one camera and a radar sensor
- Maximum 3-8 cameras, 3 radar sensors, 1-3 lidars
- Scalable processing power
- Minimum object perception capability for one camera and one radar
- Maximum 6-12 channels of object perception capability from different input
- Safety and security
- Minimum full protection against hostile access from outside.
- Minimum fail safe capability (switch off ADAS functions in case of a failure, never operate wrongly)
- Maximum fail operation capability (provide minimum operation in case of a failure in order to stop the vehicle in a safe manner)
The AVL ADAS ECU
AVL has developed an embedded processing platform based on the above requirements. We use it here to show how a zone computer can be built to meet all the ADAS/AD challenges in an electric car. Figure 2 shows the block diagram of the fully equipped system.
The system has two main sections for redundant processing (system-on-chips SoC 1 and SoC 2). The SoCs can be scaled up to a power that enables them to process 6-8 channels of object recognition, calculate several trajectories, and make decisions in each of them. Each of these sections are electrically separated, have their separate power supply and interface lines. The third controller, the “Safety Controller”, is used to supervise the diagnostic state of the two separate sections. In case of a failure in one of the sections, the safety controller makes sure that the sections is closed down, a system mode change is initiated (finally to organize the safe ending of the autonomous driving function by informing the driver and/or bring the vehicle to a safe stop).
Note that Figure 2 also shows HDMI and USB interfaces. These are part of the development platform to make the ECU accessible for debugging. They will not be part of a series version.
Just by not equipping the system with all interfaces and SoCs, the same unit can be scaled down to a minimum system that only covers the mandatory GSR functions (see Figure 3, optional debugging interfaces still shown).
Summary
Zone computing can greatly increase the efficiency of ADAS and AD subsystems. Processing performance and interfaces of a zone controller needs to be sufficient to host all ADAS and AD functions. However, other requirements are also important:
- Scalability: The ADAS/AD zone computer architecture supports a range of functions (from GSR up to autonomous Level-4 driving)
- Safety: The zone computer shall have internal redundancy to provide fail operational modes to survive any kind of sensor or processor failure in a safe way
- Automotive grade power consumption and robustness
AVL provides an open development platform called Ajunic that is built up by two independent high-performance sections. It offers easy access for developers (Linux operating system, USB and HDMI interfaces), however is already made in a modular way only from automotive grade parts. The design can be easily adopted to a series version just by leaving out areas that are not needed.
