“The explosive growth and importance of software in future cars will require new hardware that can be dynamically reconfigured to accommodate future car features. This will affect the computing units of several Electronic control units (ECUs) installed in the car, as well as the in-vehicle network.

“

Author: Nicola Concert

Imagine driving a new car in the not too distant future. The new cars are electric vehicles with more advanced driver assistance systems (ADAS) capabilities, can be networked, and come with a variety of software.

Connected cars allow people to download various apps and services on demand. Imagine lending your car to the kids. You might want to install a car-tracking app and set a speed limit or even a distance limit remotely. Want to drive up the mountain and ski for a week? A safety package could be installed for ADAS systems to better deal with snow and ice, and perhaps a remote diagnosis of the tires to check if everything is in order. Or install a multi-zone audio app and drive down a steep mountain road listening to your favorite podcast while the kids watch cartoons?

Reconfigurable Ethernet Backbone

Of course, these are all examples, but some of these scenarios will soon become reality. All of these scenarios depend on the specific features this future car needs to support:

• The car of the future needs to be connected to the cloud
• Hardware components support all new features and can be upgraded to features that were not even envisioned when the vehicle was designed
• The in-vehicle network connects all computers, sensors and actuators in the car, enabling data traffic and communication patterns generated by new applications

These new requirements, which focus on Ethernet-based in-vehicle network backbones, conflict with the current way of working, where all data traffic is determined statically at design time, and systems are optimized for specific assumptions without knowledge of future application needs.

In particular, Ethernet switches use the IEEE Audio Video Bridging (AVB) and Time Sensitive Networking (TSN) standards to classify and prioritize traffic based on its importance. Ethernet switches and network processors use the Generalized Precision Time Protocol (gPTP) to establish synchronous clocks that can synchronize the playback of audio and video streams in vehicles, or combine objects observed by different sensors such as cameras, radar, and lidar by ADAS ECUs stand up.

Want to learn more about automotive architecture? Welcome to the NXP Automotive Network page.

Changing something in a network or TSN configuration is no longer the task of a single entity. Instead, it requires changes to the configuration of several network controllers, processors and Ethernet switches associated with the vehicle network.

1. Define what needs to change on each networking component
2. Define how this new configuration will be deployed to network equipment, usually from different vendors

Solving this problem requires an abstract model that can summarize in a unified way what each device does, and how to configure and update them.

For example, AUTOSAR™ software on classic platforms provides a common configuration view for all connected devices, but it supports only a limited set of network functions, it is static, and does not support dynamic configuration updates after deployment to a vehicle.

And the IEEE defines several standards to model and configure networks. In particular, IEEE 802.1Qcc (see Figure 1) provides an abstract model that includes:

• Centralized User Configuration (CUC) Module
– Capture all application requirements
– Centralized Network Configuration (CNC)
• Centralized Network Configuration (CNC) module
– Understand all the specific functions of the actual hardware of the network
– Ability to calculate new network configurations for each network device such as bridges, listeners, talkers, etc.
• A general-purpose abstract data modeling language called YANG (Figure 2)
– Ability to capture and model network commands, which can then be parsed by each target device

This software-defined networking (SDN) model leverages software to steer traffic on the network to address the limitations of previous network architectures. SDN is software-based rather than hardware-based traditional networking. It provides more flexibility to control the network, change configuration, allocate resources and increase network capacity.

Figure 1: IEEE 802.1Qcc compliant SDN architecture

Figure 2: Example of YANG model describing network configuration
Download the YANG model

Of course, that’s what the IEEE standard does. They specify what needs to happen, but not how. There are several tools that implement the IEEE standard. Figure 3 shows some of the tools that can deploy the YANG model to a real network.

These tools support:

• Networked devices query the capabilities and status of the network and generate new service requests or update existing services
• The CNC module queries the status of any networked device and generates and transmits configuration messages to any networked device

How each tool encodes the YANG data in the Ethernet frame (e.g. binary or clear text), how the data is transported (TCP or UDP, secure or non-secure, etc.) and the type of resources required by the network host (e.g. POSIX, AUTOSAR or RTOS) etc. are different.

Figure 3: Examples of tools that enable SDN processes

NXP’s role

The final step is to convert such configuration messages based on the abstract model into concrete configuration definitions that match the specific hardware implementing the networked device.

This requires software packages tightly coupled to the chip that are capable of compiling the abstract configuration described in the YANG model into device-specific register settings.

NXP is developing such drivers for several devices in its portfolio, including the SJA1110 10 10 10-port TSN Ethernet switch and the S32G car networking processor.

Which serialization method and protocol to use depends on the capabilities of the target device it will run on. On resource-constrained devices with smaller CPU subsystems (such as the SJA1110), tools with a small memory footprint and low computing power requirements are preferred. Our first implementation demonstrates that this is possible by choosing the appropriate tool from Figure 3.

NXP firmly believes that software-defined networking will become a reality for automotive networking and that solutions need to be standards-based.

Epilogue

The explosive growth and importance of software in future cars will require new hardware that can be dynamically reconfigured to accommodate future car features. This will affect the computing units of several electronic control units (ECUs) installed in the car, as well as the in-vehicle network.

Updating a distributed system consisting of ECUs and chips made by different manufacturers requires standardized abstractions and a set of tools that can meet this need.

NXP is committed to supporting standardized solutions and is currently developing the necessary software to implement the required SDN steps for key networking products such as the S32G processor and the SJA1110 Ethernet switch.

author:


Nicola Concert
Product Manager, Automotive RT Controller, NXP Semiconductors

Nicola Concert is NXP Automotive RT Controller Product Manager, focusing on electrification and regional EE architecture markets. Before that, he was a product manager for NXP’s Ethernet switches for seven years. Nicola holds a PhD in Computer Science from the University of Bologna in collaboration with STMicroelectronics and Columbia University in New York.