Naresh Nayak, Uthra Ambalavanan, Jishnu Murali Thampan, Dennis Grewe, Marco Wagner, Sebastian Schildt, Jörg Ott
©SHUTTERSTOCK/QUARDIA
Automotive electrical and electronic (E/E) engineering architectures are being radically overhauled to satisfy the needs of the current automotive trends ranging from electrification to connected vehicles and autonomous driving. Novel networking technologies are being explored for future-proofing in-vehicular networks and making them ready for applications emerging from these trends. Programmable data plane technologies based on reconfigurable match-action tables have been successfully used in data center networking for handling data center-specific applications. In this article, we seek to explore programmable data planes for their utility in in-vehicular networks. To this end, we briefly discuss programmable data plane technologies and present a case study on implementing a distributed feedback control loop using SOME/IP, an automotive service-oriented communication middleware. We outline the parts of the SOME/IP stack that can be moved from the end systems to the network devices for achieving a better workload split using these technologies, thus improving system utilization.
The emergence of trends such as autonomous/teleoperated driving, connected vehicles in smart cities, electrification, and so on is leading to a paradigm shift in the design of automobiles. Automotive E/E architectures, traditionally designed for the real-time transfer of minuscule amounts of data (sensor signals and actuator commands) using fieldbuses and processing on microcontroller platforms, must be reworked to support newer applications. These architectures are moving toward centralized models (e.g., domain and zonal architectures) characterized by the centralization of computing capabilities in the form of multicore system-on-chip platforms [1].
To meet these new challenges, the industry is striving to decouple software from the underlying hardware. Functions can then be developed as independent software components (SWCs) that can be integrated into powerful vehicle control units (VCUs) following a service-oriented-architecture (SOA) approach. Furthermore, SWCs can be upgraded, and new components can be added using over-the-air (OTA) upgrades in line with modern DevOps. Future-proofing in-vehicular networks is an important step toward realizing this vision.
To this end, multigig automotive Ethernet takes a massive step forward, providing communication bandwidths of beyond 10 Gb/s. IEEE Time-Sensitive Networking (TSN) has also equipped the Ethernet with real-time extensions and can thus guarantee bounded communication latency and jitter [3]. Moreover, to improve the programmability of in-vehicular networks, the software-defined networking (SDN) paradigm is being explored. SDN introduces a network controller, a software application, which programs the underlying network elements based on the application requirements [4]. However, this programming is limited to populating lookup tables (LUTs) used by the network elements for processing incoming frames. The automotive network elements are limited to simply forwarding frames based on predefined combinations of header fields (usually media access control (MAC)/Internet Protocol (IP) addresses and VLAN tags). Realizing customized forwarding functions is beyond the bounds of the programmability offered by SDN.
Meanwhile, programmable data plane devices are becoming increasingly commonplace in data center networking. These technologies offer flexible architectures (such as reconfigurable match-action tables), programmed using domain-specific languages, such as P4 [5], for modeling and implementing customized forwarding functions in the network elements. This can be exploited for incorporating application awareness into the network, which can then better react to the application needs.
Considering that programmable data planes emerged from data centers, we strive to figure out the added value, if any, they might bring to in-vehicular networking. We observe that automotive service-oriented communication protocols, e.g., SOME/IP, as specified in the AUTOSAR Foundation standard (R22-11) [10], are gaining increasing relevance. The current state-of-the-art (SOA) protocols assume an application-agnostic transport overlay. We ponder whether parts of their implementations could be offloaded into the network devices to create a service-aware network that could discern between the different services provided and consumed by the SWCs and react accordingly to improve overall performance. Our contributions in this article are as follows:
This article is organized as follows. The “Technical Background and SOA” section presents the background, while the “Challenges in Automotive Service-Oriented Communication” section presents the challenges to implement distributed applications using automotive service-oriented communication. The “Programmable Data Plane Devices for Service-Oriented Communication” and “Open Challenges: Automotive Adoption of Programmable Data Planes” sections present a solution with programmable data planes and the corresponding implementation.
This section forms the technical background for the technologies used in this article.
SDN is commonly deployed to manage complex and dynamic networks [4]. SDN separates the network data plane (responsible for the packet forwarding process, e.g., lookup addresses, and moving the packets to the corresponding egress ports) from the network control plane (responsible for managing the LUT entries). SDN advocates the centralization of the control plane by means of a centralized network controller, which populates the LUTs of the network elements to (re)configure the network elements based on a global view of the network. Thus, SDN is limited to parameterizing fixed-function blocks translating predefined header field combinations to egress port numbers. The programmable data plane technologies complement SDN by providing additional flexibility to define and implement custom forwarding functions that consider user-defined header fields.
At the heart of programmable data planes are pipelines of reconfigurable match-action tables that determine the classification of packets and the actions to be executed on each of these packet classes. As shown in Figure 1, the processing pipeline in such architectures starts with a programmable parser, which extracts custom header fields from an incoming packet. Subsequently, the packet is processed by a sequence of match-action tables before a deparser reconstructs the packet.
Figure 1 The programmable data plane based on reconfigurable match-action tables.
The forwarding functions can be modeled based on the reconfigurable match-action table abstraction provided by these devices by using domain-specific languages, such as P4 [5]. A P4 program starts by defining the different header fields of the supported communication protocols and implementing a state machine-based parser to extract these headers from the packet. Subsequently, the program defines which of the packet attributes or its metadata (such as the ingress port, ingress time stamp, and so on) are used as lookup keys for the different match-action tables. Additionally, it defines the actions that need to be executed if a packet is matched. Actions here could range from modifying specific header fields to dropping the packet or sending it to specific egress ports. The entries in the match-action tables are usually populated from the control plane. P4 also allows user-defined metadata fields to carry a limited amount of the state between the match-action stages. P4 programs also describe the reconstruction of the packet headers by the deparser prior to sending it over the egress port determined by one of the preceding actions. To implement complex forwarding functions, P4 allows the recirculation of packets in the pipeline. This, however, comes at the cost of decreased throughput and increased latency.
The P4 language provides mechanisms, such as registers and counters, to store limited per-flow state. Architecture-specific constructs (labeled using the extern keyword) can further extend the P4 language and enable the inclusion of additional primitives, e.g., new arithmetic functions, in a program.
The P4 toolchain consists of a generic front-end compiler, which converts the P4 program into an intermediate representation, followed by a platform-specific back-end compiler for the target (e.g., a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), and so on). The toolchain also creates interface specifications that can be used by the control plane to populate custom LUT entries corresponding to the P4 program. The control plane itself can be centralized with a global network view (such as in SDN) and can be fully distributed with a local view (e.g., executing on the coprocessor of a switch).
SOA programmable data plane devices available on the market retain hardware forwarding performance despite having the flexibility to implement customized forwarding functions. For example, Intel Tofino processes packets at line rate, irrespective of the P4 program, provided the packets are not recirculated in the pipeline.
This programmability coupled with the uncompromised hardware performance has been primarily exploited for implementing low-latency content distribution networks, e.g., content-based publish–subscribe middlewares [6]. Additionally, a variety of distributed applications have been accelerated by deploying novel forwarding functions. For instance, in-network key value caches store information in network elements and thus reduce latency for resolving lookups [7]. Improved fault tolerance by means of fast rerouting in case of link and switch failures has also been achieved by detecting the failures directly in the forwarding function [8], [9].
In this article, we look to explore whether in-vehicular communication can benefit in similar ways from the application of programmable data planes. This is one of the first articles that puts programmable data planes in the context of automotive applications.
SOME/IP [10] is an automotive communication middleware specified within the AUTOSAR Foundation standard (R22-11), striving to incorporate service-oriented design in automotive software. SOME/IP is implemented on top of the transport layer [Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)] and specifies features, such as remote procedure calls, request/response interactions, and event notifications, for realizing distributed applications in resource-constrained environments. SOME/IP services are identified by a network-wide unique 16-b service ID, while the different methods that can be invoked on these services are assigned a 16-bits method ID.
A key aspect of SOME/IP is service discovery (SD), which specifies mechanisms for SOME/IP services to discover the communication endpoints (network addresses and transport ports) of their counterparts at runtime. SOME/IP-SD is encapsulated in a SOME/IP header (Service ID = 0 × FFFF; Method ID = 0 × 8100) and is transported exclusively using the UDP over a multicast group. For further information on SOME/IP and SOME/IP-SD, we refer the readers to the corresponding AUTOSAR specifications [10], [11].
In this section, we describe a case study implementing a distributed feedback control loop, commonly found in several automotive systems, by means of three replicated SWCs implementing SOME/IP services: SC implements the feedback control algorithm (e.g., proportional integral derivative control), SI streams the values of the sensor, and SO steers the actuator based on the inputs from the control algorithm.
To realize the feedback control loop, one instance of each of these services is required. It may be noted that SOME/IP includes the concept of service instances (each identified by a unique 16-b instance ID) that may be used for such a multi-instance deployment. Figure 2 displays an in-vehicular topology along with the services available on each of the nodes. Here, SX, i implies the service SX with an instance ID i. The interservice communication may be secured and authenticated using mechanisms prescribed in the AUTOSAR secure onboard communication (SecOC) standard [12].
Figure 2 The interservice communication (excluding SD) to realize a distributed feedback control loop in an in-vehicular network consisting of two vehicle computers (VCU1 and VCU2), two zonal controllers (ZC3 and ZC4), and three switches (SW1–SW3). Zonal controllers are used in the centralized zonal architecture for interconnecting sensors and actuators with VCUs.
In SOME/IP-SD [11], the nodes broadcast the services they provide (using the OfferService message) and the services they desire (using the FindService message). With a broadcast-based discovery mechanism, all the nodes in the network are informed of all the available service instances and their corresponding locations in the network. This allows the nodes to subscribe to the necessary services they seek to consume (using Subscribe/SubscribeAck messages). In Figure 2, service SO,3 subscribes to the data from service SC,2 (flow F2, shown in blue), which, in turn, consumes information from service SI,4 (flow F1, shown in green), thus realizing the desired feedback control loop. Additionally, an arbitrary application (e.g., diagnostics) is realized by service SD,1 requesting data from service SI,3 (flow F4).
SOME/IP-SD is completely distributed among the end systems and agnostic of the underlying topology, while the network elements are ignorant of the overlying services. This can, at times, lead to inefficient network usage (e.g., overdependence on broadcasts, suboptimal routing of discovery traffic and so on).
Once discovered, services communicate over the IP, with the endpoint information exchanged as part of the SD phase. The network elements, however, being blind to these services, engage only in IP forwarding. This makes scenarios in which one service is subscribed to by multiple recipients particularly challenging.
IP multicast requires additional mechanisms to manage the multicast groups, such as the Internet Group Management Protocol. Furthermore, the sender cannot respect the differing frequencies with which the recipient services desire to be served. To satisfy all subscribers, data are streamed at the highest requested frequency, resulting in an additional load in some parts of the network. Recipients requiring the data at significantly lower rates can, however, fetch the data from the sender (e.g., using request/response primitives of SOME/IP) to reduce the network load. In Figure 2, service SD,1 fetches data directly from service SI,3, as it needs the data at a much lower frequency as compared to SC,2, by using a request/response mechanism.
Fault-tolerant E/E architectures are exceedingly important when it comes to autonomous and teleoperated driving. While redundant components/network paths are available in these architectures to tackle failures, a fast switch to backup paths during failover is critical. Approaches to handle network outages (such as link and switch failures) have been well researched over the years and resulted in many standardized redundancy protocols, e.g., the Rapid Spanning Tree Protocol. These approaches must be extended to include service failures, e.g., due to application crashes.
Since the network is currently unaware of the overlying applications/services, failures (faulty sensors, software crashes, and so on) must be detected and handled at the application level, e.g., using heartbeat messages and application-level error codes. In the event of failure, services have enough information available from SD to subscribe to alternate service instances. However, as the services themselves are responsible to detect the failures and initiate failover, additional latency is induced until the redundant services are connected. The possibility to incorporate application semantics into the network elements using programmable data plane devices can be exploited to detect failures and trigger failover mechanisms with low latency.
In this section, we present our attempt to exploit programmable data plane technologies for an efficient implementation of the case study from the “Challenges in Automotive Service-Oriented Communication” section. For this, we assume that all the underlying network elements are based on the reconfigurable match-action table paradigm and that the forwarding function they implement can be modeled using a P4 program. Furthermore, we assume that the header fields are not encrypted but may use authentication mechanisms from AUTOSAR SecOC.
With programmable networking technologies, we can push parts of the SOME/IP stack and the application logic from the end systems into the network elements. The programmable parser can implement a state machine, as shown in Figure 4, to extract the necessary header fields from the packets to make forwarding decisions based on SOME/IP and SOME/IP-SD semantics.
SOME/IP services broadcast discovery messages (e.g., FindService, OfferService, Subscribe, SubscribeAck, and so on) to all the other services in the network so that services do not require any a priori information for discovery. However, services now also receive discovery traffic from other services that are not of interest. A SOME/IP-aware network implemented using programmable data plane devices can filter discovery traffic and forward only information of interest to the services. Using the parsed information, SOME/IP-SD packets can be forwarded on selected ports alone based on the services they offer and request.
For instance, the FindService for service SI, sent by SC, may be broadcast by a network element if it has not yet encountered any packets from SI while updating its LUTs to store the port over which service SC is reachable. Eventually, when the network element encounters the OfferService from SI, it is forwarded only to service SC. Alternatively, any further FindService messages for service SI will be forwarded only from the ports over which the OfferService from SI was received. Similar mechanisms are used for resolving IP addresses using ARP. With programmable data planes, the network elements can parse header fields in the SOME/IP header and act based on these fields.
It may be noted that SOME/IP-SD already strives to be highly optimized, e.g., by collecting several FindService and OfferService entries in a single discovery message, limiting the number of messages after start-up. The use of programmable data plane devices will make another contribution in this direction by further reducing the discovery traffic, especially in dynamic scenarios.
Programmable network elements can be used to cache data (e.g., sensor values that are relatively small) from the packets either directly in the registers of the forwarding pipeline or in the memory of its coprocessor, such as a key value store. This can be used for decoupling the data providers from their consumers. While a service provides data with the highest requested frequency, the network elements can transparently extract the payload from the stream and cache it in its registers. Services intending to consume the data at a much lower speed can fetch the data directly from the en route caches in the network elements. For example, the service SD,1 fetches sensor data cached at the network element, SW1, at its desired frequency instead of burdening any of the service instances with additional queries (see flow F3 in Figure 3). Since the switches only cache the data and do not modify it, the appended SecOC authenticator remains valid and can be used by the consuming service to ascertain the authenticity of the data.
Figure 3 The service-oriented communication on top of programmable data plane devices: the implementation of the case study from the “Challenges in Automotive Service-Oriented Communication” section, using programmable data planes.
Programmable data plane devices enable the incorporation of application fault tolerance semantics into the network elements and can enable faster fault detection and failover [9]. In the failure-free mode of Figure 3, the sensor data stream, flow F1, from SI,4 is forwarded by the network element, SW2, to SC,2 for processing. The resulting actuator stream is forwarded to SO,3 for actuating. Service SI,3 also streams the sensor data (flow F1’), which is dropped by SW2 to conserve available bandwidth for other applications.
Crashes of services can now be directly detected in the network and reacted upon swiftly without the need for application intervention. If service SO,3 crashes, this can be detected directly in the network, e.g., through missing heartbeat messages and by an Internet Message Control Protocol (ICMP) message indicating that the destination port is unreachable. Subsequently, the network element, SW3, redirects the actuator stream (flow F2) to SO,4 (via SW2) while also rewriting the destination MAC/IP address, all of which can be achieved within the forwarding function implemented on the network element. Similarly, a faulty sensor service can be detected at the network ingress (again using fault codes and timing checks), and the data from SI,3 instead of SI,4 can be sent to SC,2.
We model the forwarding function discussed in the case study by using six LUTs (see Table 1), as demonstrated in Figure 5.
Table 1 The description (match fields and set of actions) of the LUTs implementing forwarding based on SOME/IP.
The parser, presented in Figure 4, processes incoming packets to extract the header fields of interest (shown in column “Match Fields” of Table 1). We designed the parser to also handle other protocols, e.g., IP traffic. One challenge here is to identify SOME/IP data streams. While SOME/IP is encapsulated in the transport layer, the TCP/UDP ports used by SOME/IP services are not standardized. Since the ports are not known a priori, we need to implement our parser to assume all TCP and UDP packets as SOME/IP streams, as in Figure 4. This is visible in the default state transition from the states “Parse TCP” and “Parse UDP.” In addition to parsing SOME/IP and SOME/IP-SD header fields, the parser also extracts the header fields for ICMP packets. This is used to detect application layer failures; e.g., sending messages to a transport port that is closed triggers an ICMP destination unreachable message (ICMP type = 3).
Figure 4 The P4 ingress parsing for SOME/IP and SOME/IP-SD. ICMP: Internet Message Control Protocol.
The different match-action tables used for processing incoming packets are listed in Table 1. Figure 5 gives the organization of the match-action stages in the ingress packet processing pipeline.
Figure 5 The forwarding pipeline implemented using P4.
Since we parse all TCP/UDP packets as if they were SOME/IP services, in ingress processing, the first step is to ascertain whether this is indeed the case. To this end, we store the source IP/transport addresses of SOME/IP streams of interest in the SOME/IP validator LUT. This stage of the pipeline separates non-SOME/IP TCP/UDP packets from the SOME/IP ones. This work-around is necessitated, as only LUTs can be modified at runtime in the P4 ingress pipeline and not the parser. Thus, detecting SOME/IP streams in the parser would require hard coding the TCP/UDP ports associated with the SOME/IP streams.
After the SOME/IP validation stage, all the non-SOME/IP packets are directly processed using the forwarding handler. This ensures that non-SOME/IP packets are not affected by any additional processing.
SOME/IP-specific processing is done in the three LUTs: the source handler, caching handler, and destination handler. The source handler processes SOME/IP packets associated with replicated data sources (e.g., the service SI in Figure 3). In the event of multiple instances of a service (one of which is marked as the primary service), this LUT marks packets from the redundant services to be dropped. However, if the packets from the primary service are not received, the packets from the redundant source are forwarded. To this end, this stage stores, in a register, the ingress time stamp of the last received packet from the service of interest and uses this to evaluate the failure of the primary service.
The caching handler works on SOME/IP’s request/response communication pattern (the message type in the SOME/IP header is request/response) only. This stage returns the value of the requested method of a service, if cached and valid, and modifies the packet to the response type and exchanges the source and destination IP/MAC addresses. This can be seen in action in flow F3 in Figure 3.
The destination handler determines the routing of SOME/IP packets based on the failure of SOME/IP services associated with data sinks (e.g., the service SO in Figure 3). The failures are detected by the ICMP handler, which sets register flags used by the destination handler. In case of the failure of the primary SOME/IP service receiving the data, this stage rewrites the IP/MAC addresses to point to the redundant SOME/IP services. Finally, the processed SOME/IP packets are forwarded to the forwarding handler, which then forwards them based on the IP addresses, which may have been modified.
Together these LUTs realize service-aware forwarding. We outline in Table 2 the additional information that needs to be available in the network elements in comparison to plain Ethernet/IPv4 forwarding.
Table 2 The memory consumption for the custom LUTs from Figure 5 for handling different types of streams and implementing different use cases from the “Programmable Data Plane Devices for Service-Oriented Communication” section.
We validate and evaluate our P4 pipeline using Mininet (http://mininet.org/), a network emulator, and the bmv2 (https://github.com/p4lang/behavioral-model) software switch. Our evaluation setup, provided in Figure 6, uses containerized endpoints (we used Docker for this), which offer and consume SOME/IP services implemented using the vsomeip (https://github.com/COVESA/vsomeip) software stack from COVESA. Containerizing our applications enables us to isolate their process and network namespace for emulating their behavior as if they were running on separate VCUs.
Figure 6 The evaluation setup for the SOME/IP P4 pipeline.
In this setup, we have server A and server B offering SOME/IP services: service A and service B to client A and client B, respectively. We monitor the traffic over all the links of this network by using the Wireshark network packet analyzer. We compare the number of SD messages seen in a conventional Ethernet/IP network versus in a SOME/IP-aware network, such as the one proposed here with different SD frequencies (1 and 2 Hz). We observe, on average, a ∼40% reduction in the total number of messages with the latter. With Ethernet/IP forwarding, all the SD traffic is simply broadcast; i.e., client A gets information pertaining to service B, and client B receives information pertaining to service A. With SOME/IP-aware networking, the dissemination of SD can be reduced to only those applications that benefit from it. The factors influencing the reduction are the topology and the service orchestration within the network.
The benefits of caching and detecting failures in the network can be seen by measuring latency. However, since bmv2 is implemented in software and not a production-grade switch, any evaluations pertaining to the throughput and latency are going to be misleading. Nonetheless, it must be noted that we do not recirculate packets into the ingress pipeline to achieve any of the functions and thus should not incur any penalty in terms of either latency or throughput.
The SOME/IP protocol has been standardized for the automotive domain in the AUTOSAR consortium and is being used in the industry. This case study is primarily motivated by the intention to benefit from the programmability of data planes for contemporary E/E architectures. However, these benefits are not attached to either the SOME/IP protocol or the service-oriented communication paradigm.
Similar performance improvements can be achieved for other service-oriented communication middlewares (e.g., Data Distribution Service). Moreover, with the ability to reprogram the network elements (e.g., in the field by using OTA updates) when upgrading the communication protocol and for moving altogether to another communication paradigm, these technologies can contribute significantly to future-proofing E/E architectures.
This section discusses the open challenges hindering an adoption of programmable data planes in the automotive domain.
Automotive systems, being safety critical, must undergo rigorous development and testing processes before being approved for usage according to International Organization for Standardization (ISO) 26262. The ISO 26262 standard describes safety certification on different levels, such as the certification of a device as a safety element out of context and the achievement of failure-in-time rates that match the ASIL scheme. With programmable data plane technologies, the complexity of the on-chip switching fabric is only going to increase. When considering the deployment of programmable data plane technologies within the automotive context, the target architectures also need to undergo necessary safety certifications. It remains an open question whether the manufacturers of switching ASICs are willing and able to deliver this complex technology with the required safety certifications.
P4 does not provide any support for handling security and encryption in the data plane. Hence, encrypted header fields and payloads cannot be parsed and interpreted by the subsequent stages of the forwarding pipeline.
Particularly challenging is the implementation of security standards, such as point-to-point MAC security (MACSec), often used in automotive in-vehicle networks, as all the header fields beyond the link layer are no longer accessible in the data plane. However, P4-MACSec [13] presents how MACSec can be incorporated in the forwarding pipeline if supported by the architecture vendor.
Many automotive applications demand at least weakly hard real-time guarantees from the underlying network. With TSN, the Ethernet has been equipped with a set of mechanisms (different traffic shapers, policing mechanisms, and so on) to provide real-time guarantees and improve fault tolerance, e.g., Frame Replication and Elimination for Reliability as specified in IEEE 802.1CB [14]. The TSN Task Group is now in the process of defining an automotive profile for the TSN standards, paving the way for deployment in automotive networks [15]. An adoption of programmable data planes will come to fruition only if it also incorporates the automotive TSN profile.
The current P4 ecosystem encompasses hardware targets ranging from FPGAs to smart network interface controllers along with software switches [2]. The current products, e.g., Intel Tofino, are overdimensioned in terms of bandwidth, energy consumption, and so on for automotive needs or are not production grade, e.g., the bmv2 software switch.
Nonetheless, many useful aspects, e.g., the modeling language and the reconfigurable match-action table abstraction, of this technology can be applied in the automotive domain for implementing novel applications. We hope that our work triggers interesting discussions on a suitable automotive profile for programmable data plane technologies.
In-vehicular networks are currently at a crossroads, with novel applications around the corner. In this article, we explored programmable data plane technologies, which enable the implementation of flexible forwarding functions expressed using a network modeling language, such as P4. We presented a case study implementing a distributed feedback control loop using SOME/IP, an automotive communication middleware. By means of this case study, we outlined where programmable data plane technologies bring significant improvements in the design and performance of automotive applications. We conclude that programmable data planes have a good potential in enabling and accelerating innovations in future E/E architectures. However, there are significant open challenges that need to be tackled.
We thank Balu Menon for his help in evaluating the different use case scenarios in this article. This work was partly funded by the European Union CELTIC-NEXT project PICCOLO (grant C2019/2-2), supported by the German Federal Ministry of Economic Affairs and Climate Action, and managed by the German Aerospace Center, under grant 01MT20005A.
Naresh Nayak (naresh.nayak@de.bosch.com) is a research engineer in the Bosch Research division of Robert Bosch, 71272 Renningen, Germany. He received his Ph.D. degree in time-sensitive networking and software-defined networking from the University of Stuttgart, Germany, in 2019. His research interests include programmable networking technologies and in-network computing.
Uthra Ambalavanan (uthra.ambalavanan@de.bosch.com) is a Ph.D. student in computer science at the Technical University of Munich, 80333 Munich, Germany, in collaboration with the Bosch Research division of Robert Bosch. She received her M.Sc. degree in electrical engineering and information technology in 2019 from the University of Applied Science, Darmstadt, Germany. Her research interests include programmable networking technologies as well as in-network computing for automotive electrical and electronic architectures.
Jishnu Murali Thampan (jishnu.murali_thampan@nokia.com) is a software developer in the networks division of Nokia Solutions and Networks GmbH & Co. KG, 90411 Nürnberg, Germany. He received his M.Sc degree in electrical engineering and IT with a focus on embedded systems in 2021 from Darmstadt University of Applied Sciences, Germany. His research focused on programmable networking technologies for automotive use cases during his internship at Robert Bosch GmbH.
Dennis Grewe (dennis.grewe@de.bosch.com) is a research engineer in the Bosch Research division of Robert Bosch, 71272 Renningen, Germany. In 2021, he received his Ph.D. degree in computer science from the Unversity of Koblenz–Landau, Germany. His research interests include network protocols and architectures to support computing on network infrastructures, including principles from software-defined and data-oriented networks for connected vehicular systems.
Marco Wagner (marco.wagner3@de.bosch.com) is with the Automated Driving business unit of Robert Bosch, 71636 Ludwigsburg, Germany. He received his Ph.D. degree from the University of Koblenz–Landau, Germany, in 2015 for his work in adaptive software and system architectures for the vehicular domain. His research interests include automotive electrical and electronic architectures and networking paradigms.
Sebastian Schildt (sebastian.schildt@de.bosch.com) is a research engineer in the Bosch Research division of Robert Bosch, 71636 Ludwigsburg, Germany. He received his Ph.D. degree in delay-tolerant networks from the Technical University of Braunschweig, Germany. His research interests include network protocols and architectures for in-vehicle networks.
Jörg Ott (ott@in.tum.de) holds the Chair of Connected Mobility in the Faculty of Informatics, Technical University of Munich, 80333 Munich, Germany. He is also an adjunct professor at Aalto University, Espoo, Finland. He received his Ph.D. degree in 1997 from the Technical University of Berlin, Germany. His research interests include edge and in-network computing as well as decentralized (cloudless and hyperlocal) services, incorporating a range of devices all the way to mobile and microcontrollers.
[1] V. Bandur, G. Selim, V. Pantelic, and M. Lawford, “Making the case for centralized automotive E/E architectures,” IEEE Trans. Veh. Technol., vol. 70, no. 2, pp. 1230–1245, Feb. 2021, doi: 10.1109/TVT.2021.3054934.
[2] E. F. Kfoury, J. Crichigno, and E. Bou-Harb, “An exhaustive survey on P4 programmable data plane switches: Taxonomy, applications, challenges, and future trends,” IEEE Access, vol. 9, pp. 87,094–87,155, 2021, doi: 10.1109/ACCESS.2021.3086704.
[3] IEEE Standard for Local and Metropolitan Area Network—Bridges and Bridged Networks, IEEE Standard 802.1Q-2018 (Revision of IEEE Standard 802.1Q-2014), Jul. 2018.
[4] M. Haeberle et al., “Softwarization of automotive E/E architectures: A software-defined networking approach,” in Proc. IEEE Veh. Netw. Conf. (VNC), 2020, pp. 1–8, doi: 10.1109/VNC51378.2020.9318389.
[5] P. Bosshart et al., “P4: Programming protocol-independent packet processors,” ACM SIGCOMM Comput. Commun. Rev., vol. 44, no. 3, pp. 87–95, Jul. 2014, doi: 10.1145/2656877.2656890.
[6] R. Kundel, C. Gärtner, M. Luthra, S. Bhowmik, and B. Koldehofe, “Flexible content-based publish/subscribe over programmable data planes,” in Proc. IEEE/IFIP Netw. Oper. Manage. Symp. (NOMS), 2020, pp. 1–5, doi: 10.1109/NOMS47738.2020.9110381.
[7] X. Jin et al., “NetCache: Balancing key-value stores with fast in-network caching,” in Proc. 26th Symp. Oper. Syst. Princ. (SOSP), Oct. 2017, pp. 121–136, doi: 10.1145/3132747.3132764.
[8] R. Sedar, M. Borokhovich, M. Chiesa, G. Antichi, and S. Schmid, “Supporting emerging applications with low-latency failover in P4,” in Proc. Workshop Netw. Emerg. Appl. Technol. (NEAT), Aug. 2018, pp. 52–57, doi: 10.1145/3229574.3229580.
[9] S. Lindner et al., “P4 in-network source protection for sensor failover,” in Proc. IFIP Netw. Conf. (Netw.), 2020, pp. 791–796.
[10] SOME/IP Protocol Specification – AUTOSAR FO R22-11, Munich, Germany [Online] . Available: https://www.autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_PRS_SOMEIPProtocol.pdf, 2022
[11] SOME/IP Service Discovery Protocol Specification – AUTOSAR FO R22-11, Munich, Germany. [Online] . Available: https://www.autosar.org/fileadmin/standards/foundation/22-11/AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf, 2022
[12] Specification of Secure Onboard Communication – AUTOSAR CP R22-11, Munich ,Germany. [Online] . Available: https://www.autosar.org/fileadmin/standards/classic/22-11/AUTOSAR_SWS_SecureOnboardCommunication.pdf, 2022
[13] F. Hauser, M. Schmidt, M. Haeberle, and M. Menth, “P4-MACsec: Dynamic topology monitoring and data layer protection with MACsec in P4-based SDN,” IEEE Access, vol. 8, pp. 58,845–58,858, 2020, doi: 10.1109/ACCESS.2020.2982859.
[14] IEEE Standard for Local and Metropolitan Area Networks—Frame Replication and Elimination for Reliability, IEEE Standard 802.1CB-2017, Oct. 27, 2017.
[15] TSN Profile for Automotive in-Vehicle Ethernet Communications, IEEE P802.1DG Draft, Dec. 2021.
Digital Object Identifier 10.1109/MVT.2022.3225787