How Software Drives the Need for Dynamic Network Management

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.

1. Defining what needs to be changed on each networked component
2. 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.

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

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.