MENU

In-vehicle infotainment software architecture: Genivi and beyond – Part 1

In-vehicle infotainment software architecture: Genivi and beyond – Part 1

Technology News |
By eeNews Europe



One of the first computer systems within an automobile was the 1978 Cadillac Seville’s trip computer, run by a Motorola 6802 microprocessor with 128 bytes of RAM and two kilobytes of ROM. The printed source code could not have occupied more than a handful of pages.

In contrast, even the lowest end automobile today contains at least a dozen microprocessors; the highest end cars incorporate in excess of 100 microprocessors. Examples of computers embedded within a modern automobile are shown in Figure 1:

Figure 1 – embedded computing within the modern automobile

With infotainment systems running sophisticated operating systems such as Microsoft Windows and various distributions of Linux, the total embedded software content can easily exceed 100 million lines of code.

Complexity is driven by the inexorable demand for better capabilities, the digitisation of manual and mechanical functions, and the interconnection of our world. While this growth in electronic content has been beneficial to society, that growth is also a key source of our reliability, security, cost, and time-to-market woes. Next-generation infotainment system architecture must help developers manage this complexity.

Automotive Electronics Consolidation

Another important automotive trend is ECU consolidation. As the automobile continues its transformation into an electronic system of systems, electronic component counts and associated wiring content within the car have skyrocketed. This electronics growth poses a significant production cost, physical footprint, and time to market challenge for automotive manufacturers. The response is to reverse the growth trend and instead merge disparate functions into a fewer number of electronic components.

Processor consolidation is closely aligned with the trend towards mixed criticality systems in which safety, security, or real-time critical components must coexist with less critical components. For example, consolidating the infotainment head-unit with the real-time, safety-critical rear-view camera and/or driver information cluster components results in a mixed-criticality system, as shown in Figure 2.

Figure 2 – mixed criticality next-generation infotainment system

Next-generation infotainment system architecture must ensure that consolidated components do not interact in unforeseen ways, posing a reliability risk to critical systems.

Automotive Electronics Security

In 2010, researchers from two universities investigating the security in modern automobiles disabled a moving car’s engine and brakes by hacking through an on-board diagnostics port. This is a sobering example of how safety assurance in automobiles is faced with a formidable set of challenges, including legacy components not designed for security and a supply chain approach that has arguably reached scalability limits.

Also in 2010, U.S. carmakers introduced a feature to enable car owners to manipulate the locks and start the engine from anywhere on the planet using a smartphone. This connectivity piggybacks on the car’s remote telematics system, which has become standard in many models.

Connecting the automobile to wide-area networks is the trigger that brings in the threat of sophisticated attackers. A single flaw may allow a remote attacker to perpetrate damage to an entire fleet of vehicles. Communications may include car to service centre or other OEM infrastructure, car to multimedia provider, car-to-car, car to power grid (electric vehicles), car to smartphone or even car to bank. Figure 3 shows some examples of long-range radio connections in next generation vehicles.

Figure 3 – examples of next-generation extra-vehicular communications

Unlike high-end data centres, the car is unlikely to be outfitted with a full complement of IDS, IPS, firewalls, and UTMs. Regardless, recent intrusions at Sony, Citigroup, Amazon, Google, Sony, and RSA starkly demonstrate that these defence mechanisms are Swiss cheese against sophisticated attackers.

When the Stuxnet attack came to light in 2010, US DoD CYBERCOM chief General Keith Alexander suggested that the U.S.’s critical infrastructure ought to be isolated on its own secure network, distinct from the Internet. While this may seem heavy-handed, it is precisely the kind of thinking needed. The car’s critical systems must be strongly isolated from ECUs and networks not critical for safe operation.

While physical network isolation is desirable, touch points will inevitably exist. For example, the car’s navigation system, in some markets, must be disabled while the car is in motion, implying communication between systems of widely differing safety criticality. These connections increase the risk of software-borne threats such as privilege escalation due to operating system vulnerabilities, side-channel attacks on cryptography, and denials of service.

Next generation infotainment system architecture must address these important emerging security threats from the ground up. Interactions between critical and non-critical systems and networks must be justified at the highest management levels, rigorously controlled at run-time, and analysed and certified devoid of vulnerabilities at the highest assurance levels. 

Part 2 of this 2-part article will describe software techniques and strategies that allow car electronics architects that harden the vehicle’s internal IT against hacking attempts.

 

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News

Share:

Linked Articles
10s