News

Nov 12, 2023

Inside a Software

Related Video How do you eat an elephant? One bite at a time. How do you develop the incredibly complex electrical architecture required to operate the next generation of electrified, connected,

Related Video

How do you eat an elephant? One bite at a time. How do you develop the incredibly complex electrical architecture required to operate the next generation of electrified, connected, (increasingly) autonomous, and continuously upgradable vehicles? In much the same way: You divide the many different computing tasks into manageable forkfuls assigned to anywhere from five to nine "domain" controllers, each of which is considerably more sophisticated than the 100 or more small electronic control units it replaces. Then you connect these various domain minicomputers via a dedicated gateway controller.

Even this simplified, rationalized solution is viewed as an interim step toward a future architecture where onboard computing tasks will be further aggregated into an even more powerful central processing unit taking constant real-time input from perhaps four zonal gateway processors. Each of these will connect directly to myriad nearby sensors and actuators handling widely varying tasks, relaying messaging to and from the CPU. For now, let's examine the typical domains powering the current generation of software-defined vehicles.

This minicomputer handles all tasks related to battery management, monitoring, and controlling all power transfers into the high-voltage battery during wired or wireless charging and regenerative braking, and out of it for acceleration or accessory use, vehicle-to-home or -grid export power, etc.

Here is where all the route planning and decision making for autonomous driving takes place, with input from incoming sensor data, safety-related algorithms, multi-scenario decision-tree look-up tables, and with the benefit of artificial intelligence. Control input requests are relayed from this domain to the Vehicle Performance domain controller. Note that some developers separate the sensors and sensor-fusion computing function as a separate "Perception" domain that then communicates with the autonomy domain.

This central hub connects to the various domains, serving as a connection port for service and managing much of the data-privacy and cybersecurity functionality by demanding multi-factor authentication and other countermeasures that comprise a firewall against malware attacks and attempts to hack into vehicle controls or data. The gateway continuously monitors the various vulnerability fronts (USB ports, SD card slots, connectivity ports, etc. ).

This domain informs and entertains the vehicle occupants, providing infotainment, augmented and virtual reality, onboard gaming or shopping, etc. Sound systems and screens are managed by this domain, often communicating with offboard entertainment providers via the connectivity domain.

This domain oversees data communication between the car and the cloud, the vehicle manufacturer, telematics systems (e.g., the various global-positioning satellite systems), the road infrastructure and other road users (aka V2X—vehicles, pedestrians, cyclists, etc. ), charging stations, home or office, and myriad other nodes on the global "internet of things." This communication can be via cellular networks, WiFi, Bluetooth, wired connections, and other means. This domain serves as the conduit for over-the-air updates of software and firmware.

This minicomputer translates all control inputs, whether from a driver or autonomous controller, into how the powertrain and chassis will handle acceleration, braking, and cornering responses. It considers inputs from onboard body and chassis sensors and offboards database information regarding road conditions, climate, terrain, etc. This domain controller optimizes performance to balance requirements for passenger comfort, speed to destination, energy use, or other predetermined priorities within programmed safety parameters.

Some automakers and suppliers still treat the following as separate domains, instead of rolling them into the above:

Gathering and presenting all of the various information that gets presented on the main instrument and/or head-up display can be complex enough to task a warrant to a separate domain independent of Vehicle Experience.

Infrared cameras monitoring driver gaze, in-seat-vibration sensors or remote ultrasonic sensors that monitor heart and breathing rates will determine fitness, and other such systems can be assigned their own domain if not incorporated into Driver Assistance/Autonomy.

Monitoring and guaranteeing safety is not something that can be centralized in a separate domain, at least not at present. Safety protocols must be baked into each of the above domains.