Linux is already being adopted by an increasing number of car makers such as GM and Jaguar predominantly for in-vehicle infotainment systems. But much work remains to ensure that Linux is automotive-grade. In this article we will discuss the opportunities for Linux in vehicles and the five requirements that need to be addressed to bring it up to speed.
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.
We’re preparing for our weeklong extravaganza of mobile and embedded development next week. Android Builders Summit kicks off Monday and ELC follows on Wednesday, taking place February 15-17, 2012. For the really hard-core, we’ve even lined up some hands-on mobile and embedded Linux training courses over the weekend. I'm especially looking forward to the Yocto Project crash course.
This is a great way to kick off our annual events calendar for 2012, and it provides me a good excuse to share my take on the state of embedded Linux.
The face of embedded software development is changing fast. The power and functionality of mobile and embedded devices are reaching new levels of performance previously found in general purpose systems, such as desktop and mobile computers. The classic definition of an embedded system being "a computer system designed for specific control functions within a larger system" may still hold true for control modules found in cars, machinery and other core embedded applications. However, the lines are becoming blurry when it comes to mobile devices, Smart TVs and other consumer electronics products. These devices now allow users to customize their look and feel and user experience, installing third-party software applications, downloading media, and more, which a few years ago was only possible with personal computers.
Following is a breakdown of the trends I see shaping the embedded Linux area and the ways that engineers write software for these systems in the year ahead.
Convergence of development and deployment platforms
If you are a veteran embedded engineer you very well know that the systems you once utilized to develop software were substantially different from the systems you were developing for. In the majority of cases, the target systems had a different processor architecture, different I/O functionality, substantially less processing power, different or no memory management, and many other diverging characteristics. System-on-Chips (SoC) integrating processor cores of general purpose CPUs with peripheral devices typically found in embedded systems into a single chip allows software developers to tap into a large software pool previously written for general purpose CPUs. The most prominent example is certainly the Linux kernel.
Before the advent of SoCs, Linux was not a good choice for embedded or mobile systems. General purpose CPUs required too many external peripheral devices to be economically used in an embedded system, and microcontrollers typically used in such systems did not fulfill the memory management requirements of the Linux kernel. A second hurdle for Linux in embedded system design was the need for a read/write file system. Not too long ago, file system meant the use of hard drives, which are not practical for embedded and/or mobile use. Memory Technology Devices (MTD) are now closing the gap. SoCs and MTDs are enabling the use of Linux in embedded and mobile devices.
The utilization of Linux for embedded devices is naturally bringing deployment and development platforms together. Now, developers can use the exact same software development tools they are familiar with on their Linux development system to write software for a Linux-based target. The same processor architecture on development system and target may even make the use of cross-development tools unnecessary. In some cases, developers are even given the possibility of directly developing software on the target itself. Many SoCs have integrated graphics and USB ports, making connecting a display, keyboard and mouse a breeze. Development boards available for most processor architectures provide all the necessary functionality in single board computer form factor to jumpstart embedded software development.
Emulation and simulation
In the past, embedded hardware and software development were mostly serialized. Software development did not start until the first prototype of the hardware was available for the software engineers. Emulators allow software engineers to test new features even before they are accessible in the form of hardware. For example, the QEMU open source machine emulator and virtualizer can easily be used to test new CPU instructions and compilers to create code for these instructions long before the first silicon gets in the hands of software developers. Simulation can be utilized to test new APIs for sensors and other hardware devices. GUI simulators facilitate rapid prototyping of user interfaces.
The original intent of the Java platform was to provide a hardware independent platform for interactive television. It was too advanced for the digital cable television industry at the time but its adoption by the Android mobile operating system as application development and deployment platform proved that the concept of virtualization for embedded and mobile systems is fundamentally correct. Virtualization provides several benefits for embedded and mobile systems: secure partitioning of applications, migration of legacy applications, platform-independent application ecosystems. Depending on the focus for the virtualization, different solutions are appropriate. Secure partitioning of native applications can be achieved with a hypervisor. A hypervisor may also be the solution for migrating existing and consolidating existing software on a new platform. Ecosystems for third-party applications are a major differentiator for mobile devices. While Java is Android's technology for building an application ecosystem, web browsers, WebKit, HTML5 and other web technologies provide the abstraction layers necessary to build application ecosystems that extend across many different device types and categories using a variety of hardware technologies, processor architectures and operating system.
Ecosystems for third-party applications are a vital part of mobile device platforms and will undoubtedly influence purchasing decisions for other consumer electronics products such as Smart TVs, and potentially cars, in the near future. The more applications that are available for a particular platform, the more valuable it becomes in the perception of the consumer. If you trust the forecasts of market analysts, then the battle of the ecosystems has just begun. And within the next couple of years, two to three prevailing software platforms (with their respective ecosystems) will evolve as the winners. The winners will bring on board the critical mass of application developers providing a steady stream of new applications to maintain the attractiveness of the platform to consumers. In my opinion, HTML5 will make the discussion about the winning mobile platform moot and end the predicted battle of the ecosystems.
A major headache for mobile application developers is the rapidly increasing number of variances in devices, form factor, screen resolution, operating system versions, etc. An application designed for a mobile phone with a 4" screen typically viewed in portrait orientation will most likely not provide the same user experience on a tablet with a 10" screen commonly viewed in landscape orientation. Current mobile software platforms and their respective application development environments do not provide an adequate solution. HTML through CSS, allows easy separation of presentation from business logic making it straight forward for developers to change the visual layout of their applications and have it automatically adapt to the form factor and orientation of the device. HTML and CSS also give developers more freedom to design their own look-and-feel. Current SDKs for mobile applications are rather limiting in how developers can create differentiating user experiences.
New markup tags introduced with HTML5 further close the gap between native and web applications. Web applications can now access sensors, cameras and other hardware devices found on mobile platforms, store application-specific information on the device and play media through standardized tags and objects.
With these features, HTML5 provides a unique opportunity to create an application ecosystem for embedded and mobile devices that is truly independent from the underlying hardware and software platform. This ecosystem will benefit all parties involved with the value chain: the device manufacturers, the application developers and the consumers. None of them will have to make the decision for a particular platform wondering if the investment will be voided by becoming obsolete before returning the expected value.
Security and privacy
A steady and rapidly increasing number of embedded devices are either directly or indirectly connected to the Internet. This poses new challenges for embedded system developers. Even if an embedded device is only connected to a private network, engineers now must keep security in mind since other devices on the private network could act as bridges, deliberately or involuntarily, providing outside access to those devices. For instance, an engine management module in a car connected to the vehicle's private network could potentially become exposed to the Internet through an infotainment head-unit connected to the same private network while also being connected to the Internet via data modem and cell phone network. Encrypted data communication on private networks and embedded firewalls to protect them will soon become standard for embedded systems.
The widespread proliferation of smartphones may enable botnets of entirely new dimensions. Access to platform sensors, such as GPS, makes it easy to physically locate the bots and aggregate the ones close in location for attacks in specific areas. For example, thousands of compromised smartphones in a Super Bowl stadium could be used to create a mass panic or do other harm. Embedded and mobile device designers must devise technologies to protect the platforms against viruses, Trojan horses and other malware.
As more and more users of smartphones use them for online banking, financial transactions at store checkouts and to unlock their cars, among other applications, the protection of the private data stored on these devices becomes mandatory. But not only the data that the user explicitly stores on the device is at risk. but also the data that the user indirectly creates while carrying and using the device: the places he visits, the stores she pays, the pictures of places and people he takes, the tunes she plays, etc. While each piece of data by itself may be meaningless the combination of it together with information found online through social media networks and personal websites may expose the person to identity theft and more. It is not a trivial task to enable user convenience and at the same time keep the user's personal information safe from unauthorized access.
Embedded and mobile system developers must learn to understand the threats, be aware of them and proactively design their software accordingly. There is no absolute security and privacy; however, a simple message during installation that an application accesses the user's contact list, the data network, the camera, etc., and asks the user whether to proceed or not is not merely a security concept but simply an excuse.
The Future Belongs to Embedded and Mobile Computing
The future of computing is in embedded and mobile. Orders of magnitude more of these systems will be deployed and used for a myriad of applications than have ever been for PCs or other computers. The possibilities and opportunities seem limitless but so seem the challenges. However, lessons learned from the personal computing era and the Internet still apply. As embedded and general purpose computing platforms converge, embedded and mobile developers must adapt to harvest the benefits and meet the challenges.
Building an embedded Linux distribution can be a daunting task. From the Board Support Package (BSP) to Kernel configuration, root file system setup and the selection many additional software package there are many choices to make and taking the wrong turn can easily lead to a dead end and many hours of wasted time.
The Yocto Project greatly simplifies this process with a set of proven tools and recipes allowing you to build you own custom Linux distribution tailored to your requirements.
During The Linux Foundation's Embedded Linux Conference at the Hotel Sofitel San Francisco Bay in Redwood Shores from February 15 through 17, you have the unique opportunity to build your competence in embedded Linux and the Yocto Project.
On the day before the conference, February 14, the first-ever Yocto Project Developer Day you will have the opportunity to meet the Yocto Project's supporting organizations and many experts who will be presenting sessions and labs.
Stay a little longer and right after the conference on Saturday/Sunday February 18/19, you can deepen your Yocto Project knowledge with a 2-day crash course offered by The Linux Foundation.
Join me for two days of hands-on learning fun, building Linux system images to boot in an emulator and on a Beagleboard. First you will get an introduction into the Yocto Project and OpenEmbedded and how they relate. Then we will dive into the Poky Build Process, the core of the Yocto Project, and the Bitbake build orchestrator. You will learn about metadata layers, recipes and classes and how to use them to customize your distribution built by the Yocto Project.
What will you need? You know your way around on a Linux system and are not afraid of a commnad shell. You can use any of the standard text editors such as vi or emacs. You understand the basics of compiling and linking programs and constructing Makefile.
What to bring? Tag along your laptop with Ubuntu 10.04 LTS 32-bit installed on it. Or alternatively, have VirtualBox 4.1.8 installed on your system. We can provide you with an appliance ready to be imported in VirtualBox.
I am looking forward to seeing you soon in Redwood Shores!
Nearly 125 years ago, German inventor Karl Benz introduced his Patentmotorwagen Number 1, the world's first automobile tesigned to be propelled by a motor. Twenty years ago, Finnish computer science student Linus Torvalds posted on the Internet...Ok, ok, you know the rest. But fast forward to November 28, 2011 and you begin to see these two worlds come toether in collaboration for the future...