Imagine yourself driving your new car in the not-so-distant future. It will be
electric, it will have more advanced driver assistance system (ADAS) features,
it will be connected and it will be full of software.
Your connected vehicle will allow you to download apps and services based on
your needs. Imagine you are lending your car to your kids. You may want to
install a vehicle tracking application and set a maximum speed or maybe even a
range remotely. Are you driving to the mountains for a week of skiing? How
about installing a new safety package for your ADAS system to better deal with
snow and ice, and maybe having remote diagnostics for your tires, just to
check that all is well. Or how about installing a multi-zone audio application
to listen to your favorite podcast while your kids watch cartoons during the
drive to the slopes?
The Reconfigurable Ethernet Backbone
These are all examples of course, but some of these scenarios will soon become
reality. All these scenarios rely on specific capabilities that this future
car will need to support:
- It needs to be connected to the cloud
-
The hardware components that support all the new functionalities need to be able to be upgraded with features that were not even conceived at the time
the vehicle was designed
-
The in-vehicle network that connects all the computers, sensors and
actuators of your vehicle needs to be capable of supporting the data traffic
and the communication patterns that those new applications can generate
Focusing on the Ethernet-based in-vehicle network backbone, these new
requirements clash with the current way of working where all data traffic is
statically decided at design time and the system is optimized for specific
assumptions with no knowledge of future application needs.
In particular, Ethernet switches use IEEE audio video bridging (AVB) and time
sensitive networking (TSN) standards to classify and prioritize traffic based
on its criticality. Ethernet switches and networking processors collaborate to
establish a synchronized clock using generalized precision time protocol
(gPTP) that can be used to synchronize the playback of audio and video streams
in the vehicle or by an ADAS ECU to combine objects observed by different
sensors such as cameras, radars and LiDARs.
Changing something in a network or a TSN configuration is not a task for a
single entity. Instead, it requires changing the configuration of several
networking controllers, processors and Ethernet switches associated with the
vehicle networks.
- Defining what needs to be changed on each networked component
-
Defining how this new configuration can be deployed to networking devices
that typically come from different vendors
The solution to this problem requires an abstraction model capable of
summarizing in a uniform way the capabilities of each device and how they can
be configured and updated.
For example, AUTOSAR™ software on a classic platform offers a
common configuration view of all networked devices, but it supports only a
limited set of network functions, it is static and it does not support dynamic
configuration updates after it is deployed to a vehicle.
Instead, IEEE defined several standards to model and configure a network. In
particular IEEE 802.1Qcc (see Figure 1) offers an abstraction model which
includes:
- A centralized networking configuration (CNC) module
- Captures all application requirements
- Centralized networking configuration (CNC)
- A centralized user configuration (CNC) module
-
Is aware of all the specific capabilities of the actual hardware of the
network
-
Is capable of computing a new network configuration for each network
device: bridges, listeners, talkers
- A common abstract data modeling language called YANG (Figure 2)
-
Is capable of capturing and modeling networking commands that can then be
interpreted by each target device
This software-defined networking (SDN) paradigm has emerged to address the
limitations of previous network architectures by leveraging software to direct
traffic on the networks. SDN is software-based instead of traditional
networking that is hardware-based. It is much more flexible to control the
network, change configurations, provision resources and increase network
capacity.
Figure 1: SDN architecture according to IEEE 802.1Qcc
Of course, IEEE standards are just that. They specify what needs to happen,
but not how.
To implement the IEEE standards, there are several tools. Figure 3 shows some
of the tools that allow the deployment of the YANG model to an actual network.
These tools allow:
-
Networked devices to query the capabilities and status of the network and
generate requests for new services or update existing ones
-
CNC module to query the status of any connected device, and generate and
transport configuration messages to any networked device
Each tool differs on how the YANG data is encoded in an Ethernet frame (e.g.
in binary or clear text), how the data is transported (TCP or UDP, secure or
non-secure, etc.) and the type of resources needed by the network host (e.g.
POSIX, AUTOSAR or RTOS).
Figure 3: Example of tools capable of implementing a SDN flow
The Role of NXP
The last step is the translation of such configuration messages based on an
abstracted model into a specific configuration definition matching the
specific hardware implementing the networked device.
This requires software packages tightly coupled with the silicon that are
capable of compiling abstracted configurations described in a YANG model into
device-specific register settings.
NXP is currently developing such drivers for several devices in our portfolio
including the SJA1110 10-port TSN Ethernet switch and the S32G vehicle
networking processors.
The appropriate serialization method and protocol depends on the capabilities
of the target device on which it will run. On resource constrained devices
with a smaller CPU subsystem (e.g. SJA1110), a selection of tools with a small
memory footprint and low compute power needs is preferred. Our first
implementations prove that this is feasible by picking the right tools from
Figure 3.
NXP is a firm believer that software-defined networks will become a reality
for vehicle networks and that a corresponding solution needs to be based on
standards.
Conclusion
The explosive growth and importance of software in future vehicles will
require new hardware that can be reconfigured dynamically to accommodate
future vehicle functionality. This will impact several of the electronic
control unit's (ECU's) compute units implemented in the vehicle, along
with the in-vehicle network.
Updating a distributed system comprised of ECUs and silicon manufactured by
several vendors requires a standardized abstraction and a set of tools capable
of delivering on this need.
NXP is a strong supporter of standardized solutions and is currently
developing the necessary software capable of implementing the required SDN
steps for our key networking products such as the S32G processor and SJA1110
Ethernet switch.
For more information, please visit
nxp.com/SJA1110
and
nxp.com/vehiclenetworking.