by Anil Khanna, Andrew Patteron, Mentor Automotive

IoT connectivity for next-generation automotive apps is made possible by new software devised with audio and video networking in mind.

There’s a shifting landscape when it comes to today’s modern automobiles. Automakers face the challenge of satisfying consumer expectations for rich, multimedia experiences within the vehicle cabin. Meanwhile, security has become a big issue as regulations and requirements have begun to apply to external vehicle connectivity.

The electronification of the car generates large amounts of data within and across the vehicle. This data must be integrated, processed and presented, usually in real time, in a format the occupants of the vehicle find actionable.

And finally, cost issues are as critical as ever. The challenge is to innovate while keeping research and development costs down. Embedded systems have taken a lead role in meeting such challenges.

There has been a steady progression in vehicle electronics, from simple electronic control units (ECUs) that had no need for an embedded operating system (OS), to today’s complex multi-function ECUs, which can require multiple operating systems. Once upon a time, an embedded operating system was treated as a separate isolated entity, but for performance and security reasons, this can no longer be the case. The operating system directly influences safety, security and connectivity to devices both inside the vehicle and to the roadside infrastructure, cloud or other vehicles externally.

Connectivity inside the vehicle encompasses communications across a wide range of physical networks. Traditional in-vehicle networking technologies such as CAN, FlexRay, MOST, and LIN are being supplemented by more capable technologies such as Ethernet, Ethernet Audio Video Bridging (eAVB), Automotive Audio Bus (A2B), and wireless solutions. The design of individual networks is typically driven by application needs, with gateway ECUs connecting different vehicle domains. The combination of powerful SoCs and software systems let automakers consider new consolidated system architectures. One example of this would be a joint in-vehicle infotainment (IVI) and driver information cockpit that not only displays infotainment choices, but also overlays vehicle operation data such as speed, engine status, safety pointers, and data from lane departure warning systems (LDWS) and other kinds of warning systems.

ECU and module consolidation
Luxury vehicles now carry more than 100 ECUs. And ECUs are migrating from 8- and 16-bit microcontrollers to 32-bit microprocessor-based system SoCs and into multicore architectures.

As vehicles sport more electronic features, it becomes obvious that electronic functions need to consolidate into modules. Therein a number of issues arise. The vehicle wiring harness grows more complex and heavier. The growing number of ECUs in the vehicle also forces designers into more standardization. There’s a challenge to reengineer the software and perhaps re-architect the system to move or consolidate functions among modules.

Partnership efforts, such as the Automotive Open System Architecture (Autosar), have done an exceptional job of creating and establishing open standards for various automotive software architectures to address these types of issues. Automotive OEMs, electrical suppliers, chip manufacturers and software companies are all Autosar members.

A modern infotainment system is the cockpit through which the driver and passenger command and control data across the vehicle. The infotainment system must connect with the vehicle network to collect data from multiple ECUs and report on its own status. Externally, there are connections to smart devices, increasingly fulfilled through apps and technologies for car-smartphone connectivity, such as Apple CarPlay, Google Android Auto and MirrorLink.

With the advent of autonomous cars, the infotainment functions must also connect to other vehicles and the outside world. It is not surprising that the OS of the infotainment system, typically in the head-unit, has become the proverbial brain of the car.

Consequently, the embedded system forming the cockpit is a crucial piece of technology. One concept addressing this role is called Connected OS. Devised by Mentor Graphics, it covers the integration and connectivity needed for next-generation in-car experiences.

The Connected OS software employs a modular, GENIVI-based Linux platform with a board support package (SuperBSP) and a middleware layer (OPTstack). Out of the box, the software platform delivers technologies such as fast boot, instant-on, and optimized audio/video—all necessary for cutting-edge automotive applications. One example of its use might be enabling a rapid system start-up along with quick turn-on of audio and video, necessary for infotainment systems with back-up cameras.

In addition, Connected OS offers middleware support for emerging networking technologies such as eAVB and A2B. The pre-integration of the eAVB software stack is especially helpful in developing applications that require low-latency, real-time communications, such as those found in Advanced Driver Assistance Systems (ADAS).

Beyond this, the combination of support for protocols, such as eAVB with video processing expertise, allows Connected OS based systems to deliver features such as Rear Seat Entertainment (RSE). The eAVB stack in Connected OS is developed to IEEE AVB standards and complies with AVnu Alliance deterministic networking standards.

Supported IEEE implementations include IEEE 802.1AS (to ensure synchronization for time-sensitive applications such as audio and video); 802.1Qat (protocols, procedures and managed objects that let network resources be reserved for specific traffic streams traversing a bridged LAN); 802.1Qav (lets bridges provide guarantees for time-sensitive, loss-sensitive, real-time AV data transmission); 1722.1 (provides the audio video discovery, enumeration, connection management, and control protocol for AVB devices); and 1733 (protocol, data encapsulations, connection management, and presentation time procedures for interoperability between AV-based stations). Similarly, support for the A2B software stack in Connected OS lets automakers develop less expensive audio networks that still deliver exceptional in-car audio.

Safety and security are always high on car maker priority lists. With the advent of autonomous vehicles, more wireless “attack surfaces” have appeared for hackers to exploit. Security must be at every level of the vehicle architecture, from the hardware to embedded software, through to applications and even human factors. Embedded software protection techniques—such as key-exchange protocols, public-key cryptography, data hashing algorithms, and symmetric-key encryption—can help improve vehicle data security. Further, ECUs that must communicate with each other can exchange manufacturer-assigned security keys before proceeding with any data exchange, so only necessary and authorized data transmits.

On the safety side, minimization of software defects is a must. Strategies for exhaustive testing of safety-critical software continue to evolve. Through careful partitioning, safety-critical elements can be isolated and certified separately from more complex systems that are harder to fully validate line by line.

Mentor Graphics has developed a mixed-criticality instrument cluster solution that combines certified safety-critical graphics indicators with rich 3D graphics on a single display. The safety-critical graphics operate in a secure hardware zone. They run on a stand-alone safety-certified Nucleus SafetyCert RTOS for security from external interference and denial-of-service attacks.

The Connected OS concept covers more than just a foundation Linux operating system. New multicore architectures allow for the hosting of multiple operating systems with tight communication among them. These include, for example, the Autosar basic software (BSW) operating system, real-time operating systems such as Nucleus RTOS, and even links to Android running natively or in a Linux container (LXC).

Once multiple operating systems are used, secure communication is enabled using protocols such as Remote Processor Messaging (RPMsg) and VirtIO, so information generated in one domain can transmit to another. An example could be a phone status message, needed on the secure driver information cluster display. Separating domains on multicore frameworks, or through use of embedded hypervisors, helps manage security and separation while simultaneously optimizing performance.

Mentor Graphics
www.mentor.com/solutions/automotive

Autosar
www.autosar.org