TECH REPRINT

w w w . m e n t o r . c o m

Connected Cars Quickly Becoming Part of the Internet of Things (IoT)By Andrew Patterson

experience and don’t want to quickly hand over the privilege to an autono-mous vehicle.

With safety in mind, autonomous vehicles are rightly extremely cautious machines, programmed not to take risks and work in a fail-safe manner if anything should go wrong. Car makers have started to gradually introduce automation aids, such as automatic braking and self-parking into new models, but still, the driver maintains overall control. This hybrid model benefits from external environment connectivity and awareness, and will no doubt serve as the standard for some years to come. Even when a driver fully hands over control to an on-board computer, there may still be occasions when it is desirable to take back control; perhaps on the open road enjoying the drive, or obviously, in case of an emergency. In essence, the

s we put more and more trust into the Internet of Things (IoT), we allow

our more valuable personal possessions and data to be potentially accessed by other Internet users, whether human or machine. In general, we trust that our data is held securely, and service providers will make every effort to make it hard for any unauthorized access to happen. Our technology providers need to ensure that all new “things” on the Internet behave in a safe way, and that our personal inform-ation that goes with them is carefully managed. If this is not achieved, the con-sequences of personal data or financial loss, as well as unwanted headlines and media will be significant. Unwanted access to any IoT edge device could have serious safety implications, but when a moving vehicle is involved, a whole new level of security is needed. Analysts have estimated that we already have 15 billion connected devices at the start of 2016,

rising to 50 billion connected devices by 2020. The vast majority of these devices will be small sensors and actuators, working and communicating autonom-ously. Without question, our motor vehicles will be one of the larger and more expensive items to be hooked into the IoT ecosystem. So what needs to happen in order for connectivity to be safe, secure, useful, usable, and future- proof?

The adoption of autonomous driving Autonomous driving depends on external vehicle connectivity to satellite and road-side technology, as well as to Internet cloud servers. This connectivity has to be continuous and secure, but even when these technical requirements are covered, there are many legal and cultural hurdles to overcome before widespread driverless car adoption takes place. It turns out that many drivers positively enjoy the driving

A

2

w w w . m e n t o r . c o m

autonomous car could be left to navigate more tedious, slow-moving city traffic or other more adverse driving conditions. Another factor in the relatively slow take-up of autonomous, self-driving vehicles are the many stakeholders who are involved, who want to see their products or technologies promoted. Car makers need to provide features that sell cars, but also meet their obligations on safety, security, and reliability to avoid expensive down-stream litigation and loss of brand value. The car owner will care about personal safety and Advanced Driver Assistance Systems (ADAS) features to make driving easier and safer. They will also care about the cost of any wireless data services, and how well these services work in different geographic areas.

Highway agencies are increasingly interested in connected vehicles as a way of crowd-sourcing traffic information, and making our highways safer. This service can then be pro-active, alerting drivers if there are problems ahead, as well as provid- ing up-to-date maps and navigation assistance.

New attack surfaces The connection to the Internet from your vehicle can take several physical forms and will make use of different

communications technologies. The common factor is that the connection will be made wirelessly, and new wireless ports on a vehicle mean new attack surfaces, which have to be considered from a safety perspective. Figure 1 shows some of these new potential access points that need to be reviewed and tested to prevent unwanted intruders. Historically, security for embedded software in a vehicle has been focused on individual electronic control units (ECUs), but now security needs to cover not only the entire car, but also surrounding networks and any hosted infrastructure due to the expansion of types of wireless connect-ions. Any weakness in the chain can be a hack-point opportunity. A vehicle will need to have its embedded software regularly updated as known viruses and software updates become available. Many parallels can be drawn between the historical computer network, and upcoming connected car network, with anti-virus protection and regular software patches.

Further, it’s important to realize that embedded security goes beyond discus-sing it only within technical parameters. An employee, for example, could have access to details of ECU keys and software design, and later leave the company with the possibility of misusing or selling that very design data. Embedded software ECU solutions increasingly include encryption,

authentication, and intrusion detection. ECU update systems should involve symmetric and more likely, asymmetric key exchange. Public keys needed for ECU software flashing can be sent over a public network from a vehicle manufact-urer, but can only be read with a matching private key. This means dealers can dis-tribute public keys for an ECU update, matching a private key held by the car owner. By adding a digital signature/certificate, a further level of authentication is available to prove that sender and receiver are valid and trusted suppliers. Key management for IoT-connected cars must also include key updates, owner traceability, and the ability to disable accounts in the event of any theft/fraud detection.

IoT connected car communication trends Nearly 100 percent of all car drivers are smartphone owners, and have the ability to communicate while in transit. These devices are increasingly being integrated into the vehicle through MirrorLink, Apple CarPlay, or Google Android Auto – all offer a means to stream external network data into the vehicle’s in-dash system. However, tethering through a smartphone is not secure or robust enough for the needs of passive or active autonomous vehicle control and these technologies do not meet the IoT con-nectivity goal.

Embedded modems are increasingly being used by automotive OEMs, allow-ing the full range of data services needed by an IoT connected car. According to Gartner, by 2020 one in five vehicles will have wireless connectivity as features dependent on outside connectivity are implemented in high-volume, mass market models. A recent study also found that 13 percent of people would immed-iately rule out buying a new car without Internet access, while 25 percent already prioritize external connectivity over features such as engine power and fuel efficiency.

Figure 1: Potential wireless attack points on a modern connected vehicle.

3

w w w . m e n t o r . c o m

Digital media in the IoT car One of the main benefits of the con-nected car is the availability of digital media to both driver and passengers (Table 1). New in-vehicle networking standards such as Ethernet Audio-Video

Bridging (eAVB) and Automotive Audio Bus® (A2B®) are evolving to allow fast transmission of high-quality audio and video to digital destinations in the vehicle. The digital media use envelope is large, covering availability of streamed videos, social media services, concierge services, in-vehicle email, video conferencing, smartphone links, as well as data feeds from wearable devices such as health trackers and smartwatches. The commun- ication bandwidth for in-vehicle Ethernet is already well-established at 100MB/s or more, and maximizing the bandwidth of the wireless link that feeds the digital media is essential for consumer satisfaction.

Ethernet is widely used in office computing environments, and the IEEE 802.1Q, IEEE 802.1Qat, and IEEE802.1Qav extensions specify the operation of Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks, which are implemented by in-car Ethernet network switches. To help ensure interoperability between devices that implement the AVB standards, the AVNU Alliance has been established to develop device certification for the automotive, consumer, and professional audio and video markets. eAVB tech-nology solves the time synchronization problem that occurs when audio and

video streams around the vehicle run over standard Ethernet networks. Figure 2 shows a typical eAVB in-vehicle architecture with a range of different “source” and “sink” nodes in the vehicle.

Monetizing the IoT/connected car As connected car technology becomes more established, new markets will emerge. Already some service providers are tapping into the connected car IoT market. Subscriptions for data connect-ivity via embedded modems, or tethered smartphones are well established. Car makers are also providing their own cloud services, such as concierge support, parking space locators, energy consumption monitoring, remote diagnostics, and roadside assistance to name a few. Other car makers provide integration with smartphones and tablets, accessing

many vehicle functions, and these can improve the lifetime link between the vehicle supplier and the owner, as well as provide a continuous revenue stream for the manufacturer.

Connected car technology stack Wireless communication standards have their foundation in the IEEE specification 802.11. The standard captures a set of MAC and physical layer (PHY) specifications covering the implementation of both fixed Local Area Networks (LANs) and Wireless Local Area Networks (WLANs). It is by far the most popular solution for network-based communication, and used by many device types ranging from office and home computers to smartphones and consumer electronics.

In 2010, the IEEE published the IEEE 802.11p wireless amendment which allows for environments where there are high-speed moving components to wirelessly connect, such as auto-mobiles on a highway. It addresses challenges such as Doppler shifts, rapidly changing wireless path con-ditions, the need to quickly establish a

Table 1: In-vehicle connectivity for high-bandwidth nodes.

Figure 2: Typical eAVB architecture.

4

w w w . m e n t o r . c o m

wireless link, and manage data exchange in very short times typically less than 100ms. IEEE 802.11p provides a multi-channel control mechanism for com- munication channels defined in the Dedicated Short Range Communication (DSRC) spectrum.

For connected car/V2X communication, frequencies based on 5.9GHz DSRC have been selected. This provides the capa-bilities needed for connected cars, communicating with each other and road-side infrastructure that are sum-marized in Table 2.

The 5.9GHz band is divided to several channels (Figure 3). One channel is

defined as a Control Channel (CCH) dedicated for ITS (Europe only) road safety, and other channels are so-called Service Channels (SCH) that may be used for ITS road safety as well as for arbitrary data exchange (weather forecast, software-over-the-air (SOTA) updates, Internet services, and more.)

Implementing Linux platforms with wireless communication Linux® is increasingly becoming an established and preferred operating system in moving vehicles. Many different versions have emerged, but few are considered automotive-grade

and production-ready in their original form. Open source com-munities have contributed middle- ware layers, which support multiple and different communication tech-nologies. Car makers do not want the liability introduced by unnecessary and unused functionality, so com-panies like Mentor Graphics have specialized in customizing many aspects of default Linux distrib-utions. Typical changes include boot-time optimization; from a default of 15 to 20 seconds down to 2 seconds or less, as well as hardening communications drivers. Porting Linux onto automotive- grade hardware with optimized secure memory partitions, boot loader authent-ication, and device driver optimiz- ations are some of the other changes that are needed.

A typical automotive Linux stack, highlighting the IEE 802.11p wireless communication elements is shown in Figure 4.

There are also many Linux user-space tools available, such as iw and iwconfig for configuration and status checking of wireless devices. Car makers are developing skills in-house to support these new technologies and are also turning to specialist support organizations such as Mentor Graphics for external assistance. Design tools are available that allow performance measurements, along with system tuning and testing to satisfy the needs of ISO 26262 functional safety standards. Car makers are trying to create reusable assets that eventually reduce the cost of design and development while enabling innovation.

Table 2: Overview of technologies for wireless vehicle communications. (Source: NHTSA, 2006)

Figure 3: External connection paths for the IoT/connected car.

©2016 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks mentioned in this document are the trademarks of their respective owners.

For the latest product information, call us or visit:

MGC 00-16 xxxxxxxxxx

w w w . m e n t o r . c o m

Author’s Bio:

Andrew Patterson is the Market and Business Development Director for Mentor Graphics Embedded Software Division. The division has a specific focus on automotive software and electronics, and Andrew has led many of the recent product initiatives in this area, working with Linux and RTOS solutions on a range of silicon platforms. Prior to Mentor, Andrew spent over 20 years in the design automation market specializing in technologies including wire harness design, automotive simulation model development, virtual prototyping, and mechatronics. Andrew holds a masters degree in Engineering and Electrical Sciences from Cambridge University, UK.

Conclusion Connected cars are an important part of our IoT revolution. Not everyone will want to be transported in an autonomous or driverless vehicle, but we will benefit from receiving improved real-time information, and from being connected to the Internet with billions of other electronic devices as we travel to and from our destinations.

Having an optimized, secure, and future-proof software platform is an important first step for connected vehicle technology and Mentor Graphics has established itself as a market leader in the provision of Linux-based in-car systems. A Tier 1 designer or OEM manufacturer can take Mentor’s software building blocks and reference designs to create differentiated solutions for ADAS and connected car implementations.

Figure 4: Linux software stack to support wireless communication.

For more information on Mentor’s connected car technology, please visit Mentor’s automotive infotainment website.

For more detailed information, download the AXSB Hardware Reference Platform datasheet (Connected OS).