Where does Linux fit into a car?
Today there can be over 100 electronic control modules (ECU) in a car performing a myriad of functions to assist the driver and provide comfort and convenience to the passengers. Anti-lock brakes and airbags; electronic climate control; central locking and unlocking systems; satellite navigation; in-vehicle infotainment systems. The list of features seems to be endless. But where does Linux fit into this picture?
Not everywhere. Many of these modules perform a small range of very specific tasks in a constraint environment for which a rather heavyweight general purpose operating system such as Linux is not a good fit. Examples are engine management, airbag control, anti-lock brakes, automatic gearbox etc. These will not benefit from features such as memory management, multitasking, multi-core and multi-cpu support and more that the Linux kernel offers.
However, there is one component in a modern car that seems to be predestined for Linux: the head unit. Formerly just a simple control for the car stereo, the head unit has evolved into a universal command center providing a unified user interface for entertainment, climate control, communication, navigation and more. It commonly features a color LCD display which can include touch capability for interaction but can also be controlled via wheels and knobs integrated in the center console or buttons placed in the steering wheel at the driver’s fingertips and increasingly through natural speech.
Because the head unit has to integrate and perform a range of tasks and often interrupts one task to carry out another it could greatly benefit from Linux. And indeed this is where car makers today are looking to deploy Linux. Below are five requirements that need to be addressed for Linux to meet the automotive grade needs of electronic control modules.
(Note: Linux is also a good fit for is a wide number of systems and services that fall under the umbrella term telematics. These form the core of the connected car: automated emergency call with location flagging, remote vehicle security and tracking, real-time traffic information, location-based services, concierge services, payment services for toll roads and parking, remote diagnostics and repair, breakdown prevention and maintenance scheduling, live audio-visual content and video-on-demand, and many more. All of the telematics systems and services will not only require an in-vehicle component but also infrastructure components. More great opportunities for Linux, although outside the scope of this article.)
5 ways to bring Linux up to speed
More ECUs in a car inevitably means increased consumption of electric power. But because there is considerable investment in the current electronic architecture, energy conservation to stay within the confines of the current 14.2 V system is the mandate. ECUs must reduce the peak and average power consumption during operation as well as their standby draw by dropping into a completely passive mode, waking up when they are needed and then returning to a dormant state. Reducing the total number of ECUs by integrating their functions into one or taking advantage of multi-core CPUs is another approach.
In electric vehicles the power challenges are magnified because all the power has to be provided by the batteries: for propulsion as well as for heating, cooling and every electrically-powered device including brought-in media players, smartphones and other gadgets.
Power management is a relatively new discipline within Linux. Instrumentation allowing the Linux kernel to measure power consumption of hardware components and to control power usage by turning them off is necessary to meet the automotive, as well as mobile, power challenges.
2. On-demand Configuration and Adaptation
A vehicle’s systems constantly change their mode of operation dependent on many external and internal factors. The electronic systems must be capable of dynamically reconfiguring themselves within milliseconds and without user interaction dependent on the situation and requirements.
Linux already provides a strong set of features with loadable kernel modules, udev and others. Other features may be required such as incrementally loadable kernel modules. For example, only the portion of a Bluetooth driver that handles the link management protocol (LMP) is loaded and once a connection is established the driver will load other portions according to the required Bluetooth profiles.
3. Startup, Shutdown and Loss of Power
Driver assist systems with audio-visual interfaces such as rear-view cameras, proximity sensor in the bumpers, etc., need to be ready and available within 2 to 3 seconds from starting the car. Vehicular communication buses must be initialized within as little as 50 ms from cold-starting the ECU.
Linux has made great progress in speeding up the boot process with systemd and other efforts, however, there is still more work necessary to accelerate system startup even more from various hardware states to meet all automotive requirements.
Behavior during shutdown and sudden loss of power are another area where designers of embedded systems need to take great care. At no time must an interrupted shutdown or a sudden loss of power leave the system in a state from which it cannot recover.
4. Remote Software Updates
At first glance this seems like an easy problem to solve. Any Linux system can update kernel and packages over the network. However, for embedded and automotive systems things are quite different from regular computers. Updates may need to be downloaded via cellular data networks as cars are typically not connected to wired or wireless data networks.
Bandwidth is very limited and quality-of-service may greatly vary. Updates need to be carried out transparently for the user since the user cannot or should not have to monitor the process. Certain vehicle states may prevent installing software or rebooting the ECU. In case of an error the system must be able to roll back an update autonomously and return to the previous state.
Linux package managers are a good start but they typically update the entire package, which very often is not necessary if only a few files of the package has changed. Differential or delta package updates could be a solution. Verification of update package integrity is a must. Checksums are pretty much standard and help discover accidental corruption but are no protection from malicious activity.
5. Caution! Malware Ahead!
As the connected car is becoming a reality so will remote attacks on its systems.Wireless and web-based systems for vehicle control such as unlocking doors, starting/stopping the engine, or immobilization intended as a theft deterrent could be manipulated to compromise cars belonging to unsuspecting owners.
If not secured, over-the-air software update mechanisms could be used to infiltrate vehicle systems with malware potentially compromising not only privacy but also safety and health of passengers.
To become automotive-grade Linux will need to implement additional security mechanisms throughout the system. That starts with secure bootloaders, software components signed with hardware keys, hardware security support in form of cryptographic modules, etc.
Latest posts by Linux Foundation (see all)
- Top 10 Reasons to Attend Open Networking Summit NA - March 15, 2018
- Speak at Automotive Linux Summit & OS Summit Japan — 4 Days Left to Submit a Proposal - March 14, 2018
- The Linux Foundation Welcomes Sound Open Firmware Project - March 14, 2018