Automotive Ethernet

Can Ethernet Switches Solve the Communication Needs of the Software-Defined Vehicle?

June 6, 2022

If you ask people only vaguely familiar with the topic of automotive technologies they could claim that state-of-the-art automotive on-board communication just uses Ethernet. Individual Ethernet links are interconnected by Ethernet switches which are dirt cheap, have high throughput, and low latency. So, it looks as if we have solved all the interconnection problems in the car in a cost-effective and elegant way.

Well... The solution that works in your home office and living room is not quite what is necessary and sufficient for secure on-board communication (SecOC) in vehicles.

Let’s take a look at the current situation which has inspired GuardKnox to develop a high-performance FPGA-based Communication Engine (or CommEngine) as a core component of the zonal architecture for automotive communication.

Are Ethernet Switches Enough?

While it is true that a fully Ethernet-based communication infrastructure is a long-term objective for most automakers, legacy technologies like CAN and LIN still prevail for inexpensive low-speed communication with lenient throughput and latency requirements. 

Unfortunately CAN and LIN do not use Ethernet frames, and their protocol layers are incompatible with Ethernet, so we need gateways to connect these legacy networks. As a result, protocol conversion has to be performed between all the links with different technologies, and messages cannot simply be switched on layer 2 but have to be routed on higher layers. Routing can occur directly between interfaces of a routing device but also towards the processor of an ECU for some more sophisticated semantic processing. 

In today’s typical automotive implementations, routing functions are performed in software running on standard processors, an approach that does not meet stringent throughput and latency requirements.

So we understand that a cheap Ethernet switch along with a software-based routing implementation is not enough to suit our needs. However, as networking professionals, we know about Network Processors (NPs). These are processing devices which have been designed with fast protocol processing in mind. They are used in large quantities in routers and other networking appliances, primarily for layer 2 and 3 functionality.

GK-CTA- 64 - Automotive Ethernet Whitepaper-1-1

What About Network Processors?

A large amount of automotive software has been implemented using the AUTOSAR environment. AUTOSAR comes in two flavors: AUTOSAR classic for interface abstraction and AUTOSAR adaptive as a generic software environment for ECUs. AUTOSAR message exchange requires routing at layer 5 of the OSI protocol stack, well above the function of an IP router. As AUTOSAR covers the entire spectrum of automotive software functionality it also includes highly time critical and data-hungry applications, like uncompressed video streams from cameras. Therefore, the routing mechanisms have to be performed with very low latency and very high throughput.

Furthermore, NPs are non-pipelined systems. Therefore, they can exhibit non-deterministic timing behavior, particularly under high load situations and with complex protocol processing. While this could be solved by costly multi-core NPs, if we take cost and performance into consideration, an FPGA-based HW accelerator for protocol processing quickly seems like a better solution.

Security Requirements for Vehicle Communication

The security of the communication inside of a car and with its environment is absolutely critical. Hacking a vehicle’s electronics can lead to fatal consequences. Automotive communication security cannot be an after the fact, nice-to-have add-on. Instead, vehicle architecture must be built with a secure-by-design approach. 

There are several communication mechanisms and paths that need to be protected:

  1. Protection of safety-critical functions from being impacted by flawed or malicious third party applications. 

    There is a strong trend of increasing smartphonization of cars, i.e., the use of 3rd party applications in cars, similar to their role in smartphones. While these applications will initially be part of the infotainment systems, going forward they will also be used to enhance or even replace the ADAS systems provided by the automakers. Such applications must only get the absolutely necessary access to critical car functions. Therefore, their communication behavior has to be carefully monitored and restricted.
  2. Restriction of the communication between ECUs and their functions within the car.

    Every large software system contains a certain number of bugs, with a certain probability that grows with the number of lines of code. In order to prevent flawed automaker-provided software modules from impacting the car’s safety, the exchange of messages has to be restricted to previously defined source-destination relationships and message types. Even parameter values exchanged through these messages can be screened whether they fit into a predefined range of values. This is part of Guardknox’s patented Communication Lockdown methodology.
  3. Protecting automotive functions inside the car from being impacted by external communication.

    The connected car relies on external communication through cellular mobile networks, wireless LAN, Bluetooth, or satellite links. All this external communication can potentially be used as an entry point for malicious behavior, by directly hacking into the car functions, or by deploying malicious applications. Therefore, the supervision and control of this external communication is one of the most important tasks for the on-board communication infrastructure.

Once these requirements are all laid out, there is a strong case for protection using stateless and stateful firewalls, intrusion protection, deep packet inspection and encryption in addition to the more basic routing and switching tasks.

Finding a Comprehensive Solution

It is now easy to see why neither Ethernet switches nor Network Processors are sufficient to perform complex routing and security tasks to achieve throughput values in the tens-of-Gbps and latencies in the few-microseconds ranges.Zonal Gateway with GuardKnox CommEngineExample for Zonal Gateway with GuardKnox CommEngine 

The customizable F.A.S.T.E.R. CommEngine FPGA-based solution has been designed with all these requirements in mind to build high-performance secure Zonal Gateways. From security to fast PDU routing across multiple interfaces, the F.A.S.T.E.R. CommEngine addresses the needs of next generation E/E architecture. Our next blog will provide an in-depth insight into the concept of the CommEngine. Stay tuned and subscribe to our blog to make sure you don’t miss an update!


Lets’s Talk