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?
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:
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.
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:
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.
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:
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).
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.
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.
Nicola Concer is a product manager for NXP’s Automotive Real-Time Controllers focusing on the Electrification and Zonal EE architecture markets. Prior to that, he worked as a product manager on NXP’s Ethernet Switch portfolio for seven years. Nicola holds a Ph.D. in Computer Science from the University of Bologna in collaboration with ST Microelectronics and Columbia University in the City of New York.
