Jaguar, Elektrobit call for plug-and-play network

Article By : Julien Happich

The companies propose to integrate a scalable computing platform with an Ethernet backbone providing redundant links, smart Ethernet switches and remote IO devices.

While consumers are used to upgrade their electronic devices through simple software updates, car OEMs are only starting to offer some form of user interactivity, with customer-centric features. But as the number of sensor nodes and ECUs increases throughout the car, each configured and networked differently depending on the car models and features, OEMs face an increasing number of network configurations, where each introduction or removal of an ECU for the relocation of specific functionalities calls for a new round of validation.

In a joint presentation at IEEE-SA's Ethernet & IP @ Automotive Technology Day, Michael Ziehensack (left, above) of Elektrobit and Hari Parmar of Jaguar Land Rover (right) talked about a scalable and flexible E/E network.

"The high number of static network configurations currently used imposes limitations on how new features can be updated" said Michael Ziehensack, of Elektrobit. "We need to adopt a more dynamic methodology to configuring E/E networks, else we'll hit a brick wall."

Moving away from designing static, manual network configurations, Elektrobit's idea is to maximise hardware and software re-use between different configurations. Not only novel features should be supported without necessarily changing the hardware, by sharing sensors and actuators across multiple features that could be located in different parts of the vehicle. But also on the software side, one should build services as re-usable discrete pieces of code instead of monolithic implementations serving the whole car, Ziehensack hinted.

__Figure 1:__ *The pros and cons of static and dynamic networks.*

To complete the picture, a flexible network configuration should be able to support increased bandwidth "on-demand" for future features, by simply upgrading the links between its switches. Summarising what he would see as fit for the evolving automotive industry, Ziehensack described a structured network with different speed grades giving access to any service from any sub-network or bus, where every function in the car could be represented as a service offered to apps or to the user.
"Such a network should automatically update itself when functions or ECUs are moved around the car," he said, introducing the Automotive Plug & Play network.

The Automotive Plug & Play network he described would consist of a scalable network architecture made up of structured network and platform components, integrating an Ethernet backbone with redundant links, smart Ethernet switches, remote IO devices for access to all the end nodes, together with a scalable computing platform. Using software, this hardware part of the network would translate into a Service Oriented Architecture (SOA), where every discrete function would be represented as a service (to be combined into more complex services) used by apps to provide certain vehicle features such as ACC, climate control, engine control. In that context, services and apps would use a middleware for automated discovery and interaction, to show their availability or to exchange their IP addresses, UDP/TCP ports.

__Figure 2:__ *Four key components for the Automotive Plug & Play network.*

In learning mode, the switches and end nodes (switch forwarding tables, address assignment, VLANs, ARP table, bandwidth allocations, master clock and port roles etc..) would be automatically configured using plug & play protocols adapted from the IT industry, then the network configuration would be frozen before being fully tested. The freeze part is necessary to protect the configuration against undesired changes, the plug & play protocols are disabled and the network configuration is stored so it can operates reliably in a stable manner.

This is not all, the Automotive Plug & Play network should allow for the dynamic integration of low speed networks (CAN, LIN, FlexRay), offering functions of the devices on these networks as services in the Ethernet network, via a gateway taking care about service discovery and conversion from signal based to service-based communication.

The gateway would be automatically configured knowing that devices might be connected to different low speed networks depending on the vehicle variant and feature set, creating a device proxy on the gateway for each device that might be connected to the low speed network. Data from the devices detected by the proxy would then be converted and passed onto the Ethernet network as services.

The two companies have built a concept demonstrator consisting of multiple hardware setups and test sequences to validate their new concept. They are also planning to share their findings early 2017, with a technical whitepaper that they hope will serve as basis for standardisation.