By Andrew Patterson, Mentor Graphics

1. 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. 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. 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. 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.

5. ©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).