Road vehicles are equipped with a rising number of driver assistance systems resulting in increasing bandwidth demand and need  for reconfiguration that are difficult to satisfy with traditional in-vehicle networks. As a result, automotive Ethernet networks become more common. With rising complexity of in-vehicle networks, new requirements emerge and call for more flexible automotive  network architectures. In this work, we give examples of how Ethernet-based automotive network architectures can profit from software-defined networking (SDN) and present an SDN-based architecture that allows to reconfigure the network dynamically

Grewe, Dennis

Haeberle, Marco

Heimgaertner, Florian

Loehr, Hans

Menth, Michael

Nayak, Naresh

Schildt, Sebastian

English

Publikationsserver der Universität Tübingen

Extended AbstractAn SDN Architecture for Automotive EthernetsMarco Haeberle∗, Florian Heimgaertner∗, Hans Loehr†, Naresh Nayak†,Dennis Grewe†, Sebastian Schildt†, and Michael Menth∗∗ University of Tuebingen, Chair of Communication Networks, Tuebingen, GermanyEmail: {marco.haeberle,florian.heimgaertner,menth}@uni-tuebingen.de,† Robert Bosch GmbH, Corporate Sector Research and Advance Engineering, Renningen, GermanyEmail: {hans.loehr,naresh.nayak,dennis.grewe,sebastian.schildt}@de.bosch.comI. INTRODUCTIONThe electrical/electronic (E/E) architecture of cars hasevolved from a single CAN bus to a domain-based modelwith domain-specific buses and centralized gateways. Withincreasing bandwidth demand resulting from the integrationof camera and multimedia applications, Ethernet becomesa relevant network technology for in-vehicle networks [1].Automotive Ethernet is based on 100Base-T1 over unshieldedtwisted single pair (UTSP) cables. Today, automotive Ethernetnetworks are still statically deployed and configured during themanufacturing process like traditional bus systems. In order todecouple hardware- and software-development cycles [2] dy-namic in-vehicle networks are needed. We propose an SDN [3]architecture for automotive Ethernet networks that can bereconfigured after delivery to the customer or even duringoperation. For Ethernet-based real-time communication, 802.1Time Sensitive Networking (TSN) [4] can be used.This paper is structured as follows. Section II describes usecases for flexible in-vehicle networks. Section III presents anovel SDN architecture for automotive Ethernets. Section IVexplains mechanisms for device and application discovery. Weconclude our work in Section V.II. USE CASESA use case that could particularly benefit from reconfig-urable in-vehicle networks are trailers connected to cars ortrucks. Today, trailers are connected to the car electricallyusing one of several standardised connectors using 5 to 22pins. The connectors support only few fixed functions, e.g.,tail lamps, stop lamps, turn signals or in rare cases electricbrakes. More sophisticated applications are not supported bytraditional trailer connectors. An automotive SDN architecture,however, brings the ability to connect networked componentsin the trailer to the car’s network. One of the most obviousapplications in this use case is connecting park distance control(PDC) sensors or a rear view camera located in the trailer tothe car’s infotainment system.Aside from feature use-cases like connecting trailers tocars, an automotive SDN architecture can also change howconnected components are developed and serviced during theirlife cycle. Traditionally, the feature set of a car and thefunctionality of it’s components does not change after the caris produced. If the software running on a component needs tobe patched, the car needs to be brought to a repair shop withFig. 1. Trailer connected to the in-vehicle network.specialized diagnostic hardware. Adding new features with up-dates is usually not possible at all as the car’s E/E architectureis static and cannot be changed. In recent years, software incars has gotten more and more complex and the state of theart of complex systems like driver-assistance changes rapidly.This makes the ability to patch existing systems and addnew features to it via over-the-air (OTA) updates desirable.An automotive SDN architecture gives manufacturers moreflexibility to develop updates and new features for cars as itenables them to change the car’s data network. One exampleis an update of a collision avoidance system. Originally, thecollision avoidance monitors traffic in front of the car usinga camera. The manufacturer then wants to update the systemand add a feature that monitors traffic behind the car whilereversing by checking the PDC sensors. Using a traditionalE/E architecture, this feature cannot be added as the collisionavoidance system has no access to the PDC sensors. Using anSDN architecture, the network can be re-configured to clonethe packets coming from the PDC sensors and send the copiesto the collision avoidance system.III. ARCHITECTUREFigure 2 shows an overview of the proposed networkarchitecture. We use the topology introduced in [5] as a basis.The in-car data plane connects all components and appli-cations to each other and to the management system. Trafficon the data plane is divided into hard real-time traffic, softreal-time traffic, best-effort traffic and network configurationtraffic classes. Hard real-time traffic originates at safety-criticalcomponents, e.g., the brake system, and must be transmittedwith bounded low latency. Soft real-time traffic is associatedwith systems that are less critical and can operate in adegraded state if the deadline is not met, e.g., light andrain sensors. A rate limiter prevents faulty components fromDataplaneControlplaneInventory DBPermissions DBTSN CalculatorAuthenticatorNetwork ControllerTSN SchedulerFirewallFailsafe MechanismsAccess ControlFig. 2. Architecture overview.flooding the network. Additionally, traffic of different classesand possibly within a class are isolated from each other toprevent faulty systems from impacting other systems and toprevent malicious attacks from intruders.Fig. 3. Car network with in-band controller.Figure 3 shows a possible network topology. During normaloperation, the two links between the back and the front ofthe car are bonded together using link aggregation. Differentscheduling variants can be used depending on the requirementswith regard to throughput and safety. Possible scheduling vari-ants may be round-robin scheduling for creating one logicallink, distributing traffic on both links on a per-flow or per-component basis or using 1+1 protection for redundancy only.In case of a link failure, all traffic is redistributed to thefunctioning link. If maximum throughput on the single link isnot sufficient, best-effort traffic can be dropped to guarantee asafe operation of the car. Furthermore, it is possible to reducesensor rates to the minimal safe rate in order to reduce totaltraffic.The data plane is configured by the network controllervia in-band signalling. The network controller is connecteddirectly to one of the switches. The network controller fea-tures a northbound interface that can be used by componentsand applications to trigger certain re-configurations of thenetwork. Access to the northbound interface is regulated byaccess control lists (ACLs) and different permission levels.Configuration of the network is done using information froman inventory of components (e.g., sensors, actuators, andinfotainment systems) and applications.IV. DEVICE AND APPLICATION DISCOVERYThe ability to add new components to the car’s network,e.g., a trailer as described in section II, requires a mechanismfor automated detection of new components and subsequent re-configuration of the network. At the same time, the networkmust not be compromised by malicious devices that areconnected to the network.To prevent attacks from unidentified devices, all trafficexcept for traffic on a dedicated and rate-limited discoverychannel is dropped by the switch on ports that have notbeen in use so far. A device that gets connected to thenetwork communicates its identification and requirements tothe network by sending a signed manifest to the controller viaa broadcast message on the discovery channel. The switchesforward all packets sent on this channel to the networkcontroller. The controller then checks the manifest’s integrityand trustworthiness by checking if the manifest’s signature isvalid and originates from a trusted manufacturer. In case thedevice is deemed trustworthy, the controller then re-configuresthe network according to the requirements in the manifest.In addition to devices that are added to the car’s network,new applications may be installed on devices. These applica-tions might have requirements to the network as well. Dis-covery of applications is performed similarly to the discoveryof devices by sending a signed manifest to the controller.However, the manifest is not sent over a discovery channel bythe application itself, but by the device running the applicationvia the northbound interface.V. CONCLUSIONTraditional in-vehicle networks are based on low bandwidthtechnologies like CAN. They are statically deployed andconfigured in the manufacturing process depending on thevehicle configuration. In this work we presented use cases thatparticularly benefits from configurable in-vehicle networks andproposed an SDN based architecture for automotive Ethernets.ACKNOWLEDGMENTThe research leading to this results was funded by RobertBosch GmbH. The authors alone are responsible for thecontent of this paper.REFERENCES[1] L. L. Bello, “The Case for Ethernet in Automotive Communications,”SIGBED Rev., vol. 8, no. 4, pp. 7–15, Dec. 2011.[2] S. Apostu, O. Burkacky, J. Deichmann, and G. Doll, “AutomotiveSoftware and Electrical/Electronic Architecture: Implications for OEMs,”McKinsey & Co, Tech. Rep., Apr. 2020.[3] W. Braun and M. Menth, “Software-Defined Networking Using Open-Flow: Protocols, Applications and Architectural Design Choices,” FutureInternet, vol. 6, no. 2, pp. 302–336, 2014.[4] J. L. Messenger, “Time-Sensitive Networking: An Introduction,” IEEECommunications Standards Magazine, vol. 2, no. 2, pp. 29–33, 2018.[5] D. Pannell, L. Chen, J. Dorr, W. Lo, M. Potts, H. Zinner, and A. Zu,“Use Cases - IEEE P802.1DG V0.4,” Jul. 2019.2

An SDN Architecture for Automotive Ethernets

https://publikationen.uni-tuebingen.de/xmlui/bitstream/10900/100582/1/abstract_automotive_sdn.pdf

An SDN Architecture for Automotive Ethernets

Abstract

Similar works

Full text

Available Versions

Publikationsserver der Universität Tübingen