Datenorientierte Kommunikation im Fahrzeug - Was wir von der Netzwerk Industrie lernen können

Kurzfassung

Seit vielen Jahren wird im Automobil nun die Signalbasierte Kommunikation über z.B. CAN und Flexray eingesetzt. Inzwischen kommen mit Ethernet, WIFI und 3G / LTE Mobilnetzen auch Schnittstellen aus der IT und Netzwerk Industrie in das Fahrzeug. Neue Anforderungen wie Automatisiertes Fahren, Connected Mobility und Cloud Services erfordern den Umstieg von der Signalbasierten Kommunikation zu einer Datenorientierten Kommunikation.

Dieser Wandel erfordert aber prinzipielles Umdenken und einige der bisher geltenden Paradigmen müssen überdacht werden. Erfreulicherweise werden viele dieser Technologien in anderen Industrien (z.B. Telekommunikation / Netzwerktechnologie) schon lange eingesetzt und wir können uns die Erfahrungen aus diesen anderen Märkten zu Nutze machen.

Der Vortrag beleuchtet die Unterschiede zwischen den bisher existierenden Mechanismen im Fahrzeug (z.B. periodischer Broadcast auf dem CAN) und den neuen Methoden (z.B. Service Orientierte Kommunikation) und zeigt die Herausforderungen mit den neuen Modellen z.B. der IP Kommunikation wie der hohen Datenrate, der Notwendigkeit von Sicherheitskonzepten (Stichwort Firewalls) und Lösungsansätze aus anderen Industrien, wie diese gelöst wurden.

Abstract

For quite some time signal based communication, e.g. over CAN and Flexray has been used in the automotive industry. Recently new Interfaces like Ethernet, WIFI, 3G / LTE from the IT and networking industry have been added into vehicle networks. New applications like automated drive, connected mobility and cloud services require the migration from signal based communication to true data networks.
However this requires some fundamental redesign of communication principles and models. Luckily other industries (e.g. telecommunication and networking) are using those standards already for quite some time and learnings from those industries can be reused.

The presentation will highlight differences between existing methods today (e.g. periodic broadcast on CAN) and new methods (e.g. Service Oriented Communication) and will show some of the challenges of high speed IT networks, the requirements for security architecture (e.g. firewall) and will present some potential solutions from other industries.

1. Vehicle multiplexing background

Historically, CAN was designed for multiplexing conventional wiring onto a single bus. Instead of individual wires between each switch and its load (e.g. a light bulb), one common bus was used to multiplex multiple of those functions,

Data payload is restricted to a maximum of 8 bytes and higher layer protocols are required to segment and reassemble larger junks of data (e.g. ISO Transport Protocol). It was not originally designed to transfer data over a network. Data is transferred in PDU (Protocol Data Units), which are logical data containers for exchanging signals between applications and allowing greater decoupling from the underlying communication System.

Bild 1: CAN Multiplexing

By default, CAN is used as a shared bus system and typically messages are sent as broadcast to all nodes. Since message reception is not guaranteed, most signals are sent cyclically (e.g. wakeup message). Historically bandwidth limitations have been worked around, by segmenting the CAN network into more and more individual CAN sub networks (up to 8 today, e.g. diagnostic CAN, body CAN, Infotainment CAN, Powertrain CAN, Chassis CAN, …). Going forward with Ethernet networks, segmentation of CAN networks remains important, but now for security reasons as will be explained below.

Gateways (either central or distributed) are used to interconnect those CAN sub networks. Since most messages are broadcasts to many receivers, however a significant percentage of CAN messages is sent on ALL or many sub networks, which results in less bandwidth gain by this splitting as expected. In other words, while one high speed CAN bus typically will run at 500 KBps, two CAN buses will not achieve twice the system bandwidth, but significantly less.

2. Addition of Ethernet Networks to the Vehicle

Using signal based communication on Ethernet will create some severe challenges. Ethernet is a data transport network designed to transfer data packets. One of the side effects here is, that e.g. the minimal packet size is 64 bytes and that you typically will have a relatively large header to identify the nature of the payload. While this is fine for large packets, it results in a very significant overhead for very short message.

An initial reaction for many automotive people is the idea to tunnel traditional automotive interfaces like e.g. CAN over Ethernet. This is clearly misusing Ethernet and destroying the value it should bring into the vehicle!

Instead relevant data content should be translated for each interface to the natural protocol used. Since messages might be received or sent on any interface (CAN, Flexray, Ethernet), this can require some significant effort in the Gateway and also the nature of communication paradigm (e.g. signal or service based) for each interface should be observed.

3. Service Based Communication

Instead of the simple model in signal based communication, more complex service interfaces contain methods and events. This means, that one node offers a „service“ and therefore acts as a “server” and another node is interested in that „service“ and subscribes to it. This node is the ”client” for that service.

This model typically includes multiple communication options:

  • Request/Response Method: Client uses a method by issuing a request to the server and receives a response with the desired result
  • Fire & Forget Method: Client fires a message to the server without waiting for the result
  • Event: Client registers with a service to receive event notifications, whenever something happens

Overall communication does not generically happen as a broadcast (exceptions do exist), but is based on service relationships between client and server.

Instead of statically pre-build communication relationships, services are advertised and nodes can discover the available services. A typical example in the consumer world is UPnP (Universal Plug and Play). Here a description from Wikipedia: “Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications, and entertainment. UPnP is intended primarily for residential networks without enterprise-class devices.”. Of course, this is not the only option, another example would be Google Protocol Buffers, which is another, lighter weight alternative.

In the Automotive world AUTOSAR starting with Release 4.1 has defined its own service oriented protocol with SOME/IP (Scalable Service-Oriented Middleware over IP). SOME/IP is based on TCP/IP and uses Unicast communication, preserving network bandwidth. For Service Discovery SOME/IP-SD is used and which will identify the addresses for the SOME/IP communication.

4. Vehicle Network Evolution

While over the last decade many car architectures have moved to a central Gateway, there seems to be a trend that many vehicles will move to a domain architecture around 202x. Ethernet will be used as a logical “backbone” (Since it is a switched topology, the word backbone could potentially be misleading).

Bild 2: Evolution from Central Gateway to Domain Architecture

5. Vehicle Network Security

Historically automotive networks were designed as closed private networks using automotive specific communication standards such as CAN, LIN, FlexRay. Since those are all wired communication standards, security was basically achieved by limiting the physical access to the wires, protecting access through hiding those wires in the sheet metal. OEMs have specific design requirements for that, which e.g. avoid the outside side mirrors having CAN, which would allow easy access to those wires.

In the last couple of years wireless communication systems for multiple standards (e.g. Bluetooth, 3G/LTE, WIFI, V2X) have been added to vehicles somewhat as an add-on without redesigning the internal communications network. The effects of that development are now visible in a number of public hacks (e.g. “JEEP Hack”).

It is unrealistic to assume, that ECUs with huge footprint (e.g. infotainment head units based on Linux) can be made absolute bullet proof against exploits! Many industries (e.g. pay TV, banking) have failed in achieving absolute security, so future architectures must be robust against individual nodes being compromised. It must further be assumed, that such hacked units cannot be trusted anymore and that they might send any malicious traffic possible on their connected interfaces. The only mitigation against this is, that the network architecture must be designed in a way to protect against harm resulting from this.

Bild 3: Network Security Exposure after Exploit

It is important to understand, what this actually means. While it cannot be avoided, that the compromised unit will actually send potentially harmful data, in a real life system there are certain communication rules that must be observed by elements in the network and checked for those rules. If those rules are violated, the communication must not be forwarded on the network. An example here could be, that if the infotainment node would e.g. transmit any message that controls the breaks or steering of the car (This is exactly what happened in the Jeep case), this message should be blocked by the router / firewall.

In the IT world a layered security approach has been advocated for a long time. The principle is derived from historic defense situations, e.g. in a castle under attack, where multiple / many lines of defense are used to protect the most valuable assets. Exactly the same model is replicated by using multiple firewalls and routers to protect the interior core network (e.g. of a company) from Perimeter Networks (e.g. the Internet Service Provider) and the public Internet.

Bild 4: Layered Security Architecture Example in IT

In the same fashion a future IP based Automotive network needs to be built in a layered Approach.

Bild 5: IP based Automotive Network Infrastructure

An important element of such an architecture is the central Gateway, Router and Firewall unit sitting in the core of the network. We assume an architecture with layered Ethernet switches, that separates the network in multiple domains, e.g. ADAS, Infotainment, … In this approach domains are separated in VLANs and traffic within one Domain can be switched by Layer 2 Ethernet Switches, but traffic crossing domains must be routed at higher layers (IP, Gateway, …) and inspected (Firewall, Stateful inspection).

The terms IP routing and Firewall technology would suggest e.g. a traditional Linux based approach. However there are some automotive specific requirements, which create some real challenges here. E.g. those systems use DRAM and this limits the maximum temperature allowed in such an environment. Probably even bigger is the startup time requirement. Boot times in seconds rather than milliseconds for such a system are a real issue. An additional consideration is that switching and routing functions should not be able to be configured or controlled by nodes that are likely to be compromised as this would compromise the data flows.
Due to different nature of signal based and service based communication an overlay network of legacy automotive protocols (i.e. CAN, Flexray) connected through a gateway might be a solution to avoid redesigning many legacy nodes.

Bild 6: Central Gateway / Router / Firewall

A secondary function of this box is also the Diagnostic over IP Operation. With IP networks and Ethernet the importance of this will grow dramatically. The central Gateway is directly connected to the OBD port and therefore the node visible to the tester. Today many nodes are connected to the Gateway via CAN and Flexray and the Gateway acts as the DoIP access control point for DoIP traffic for those nodes. Since the bandwidth is very moderate, this is not a problem. As large nodes are connected through Ethernet, this will become more of a problem and the Gateway can act as a DoIP router for Ethernet nodes.
As “over the air” updates become a realistic scenario, this of course can open huge security problems that need to be managed.

Telematics functions with exposed interfaces to the outside can either be integrated or implemented in separate modules. It is mandatory, that traffic from ALL external connections (e.g. Cellular 3G/LTE, Infrastructure / Car2X or wireless internal Bluetooth / WIFI) must be inspected and controlled by a firewall, as demonstrated in the IT world. That firewall engine must be physically separated, meaning not sharing the same resources as other functions (e.g. 3G/LTE modem chipset) to avoid that the firewall gets compromised with an exploit of that other function.

Another upcoming function in connected cars deals with communication between the vehicle and the “cloud”. The amount of data generated in a vehicle is far too big to be completely transmitted to the Cloud and analyzed there. „Big Data“ must be filtered for desired data sets and privacy protection attributes must be observed. This could for example mean to encrypt that traffic. But despite encryption, authentication should not be forgotten, so that all traffic is verified to be from trustworthy sources, incoming or outgoing.

Bild 7: Telematics Firewall

Conclusion

Technologies and Methods from IT and networking industry can show promising solutions also for vehicle networks. However automotive specific requirements need to be understood and managed.

Autor des Artikels

Dipl.-Ing. Stefan Singer, Freescale, München