Modern Middlewares for Automated Vehicles: A Tutorial
Extracted source text · arXiv 2412.07817
\documentclass[conference]{IEEEtran}
% \documentclass[12pt,journal,draftclsnofoot,a4paper,twoside,onecolumn]{IEEEtran}
\IEEEoverridecommandlockouts
% \usepackage{cite}
\usepackage{amsmath,amssymb,amsfonts,amsthm}
\usepackage{algorithmic}
\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{xcolor}
\usepackage{orcidlink}
\usepackage{xcolor}
\usepackage{siunitx}
\usepackage{acronym}
\usepackage{placeins}
\usepackage{subfigure}
\usepackage{multirow}
\usepackage{float}
\usepackage{todonotes}
\usepackage{tabularx,booktabs, tabulary}
\usepackage{lipsum}
\usepackage{adjustbox}
\usepackage[capitalise]{cleveref}
\Crefname{equation}{Eq.}{Eqs.}
\Crefname{figure}{Fig.}{Figs.}
\Crefname{tabular}{Tab.}{Tabs.}
\usepackage[normalem]{ulem}
\usepackage[style=ieee, sorting=nty, dashed=false, maxcitenames=1, mincitenames=1,isbn=false,url=true,doi=false,date=year]{biblatex}
\AtEveryBibitem{
\clearlist{language}
}
\addbibresource{CPM.bib}
\usepackage{todonotes}
\usepackage{pgfplots, pgfplotstable}
\usepackage{tikz}
\pgfplotsset{compat=1.15}
\usetikzlibrary{shapes.geometric, arrows, patterns}
\usetikzlibrary{pgfplots.groupplots, matrix}
\usetikzlibrary{arrows,backgrounds}
\tikzset{every picture/.style={/utils/exec={\footnotesize}}}
\definecolor{rwthBlue}{cmyk}{1.0,0.5,0.0,0.0}
\definecolor{rwthGreen}{cmyk}{0.7,0.0,1.0,0.0}
\definecolor{rwthOrange}{cmyk}{0.0,0.4,1.0,0.0}
\definecolor{rwthRed}{cmyk}{0.15,1.0,1.0,0.0}
\newcolumntype{L}[1]{>{\raggedright\arraybackslash}p{#1}}
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
\def\soamid{\textit{architecture platform}}
\def\soamids{\textit{architecture platforms}}
\def\commid{\textit{communication middleware}}
\def\commids{\textit{communication middlewares}}
\def\COMMIDS{\textit{Communication Middlewares}}
\def\COMMID{\textit{Communication Middleware}}
\def\Soamid{\textit{Architecture platform}}
\def\Soamids{\textit{Architecture platforms}}
\def\Commid{\textit{Communication middleware}}
\def\Commids{\textit{Communication middlewares}}
\def\shsoamid{\textit{platform}}
\def\shsoamids{\textit{platforms}}
\def\pattern{software design pattern}
\def\Pattern{Software design pattern}
\def\patterns{software design patterns}
\def\PATTERN{Software Design Pattern}
\def\system{automotive software system}
\def\systems{automotive software systems}
\def\commpat{communication pattern}
\def\commpats{communication patterns}
\def\Commpat{Communication pattern}
\def\Commpats{Communication patterns}
\def\COMMPAT{Communication Pattern}
\def\middleware{middleware}
\def\ImageSize{0.5\textwidth}
\usepackage{tcolorbox}
\tcbuselibrary{theorems}
\theoremstyle{definition}
\newtheorem{definition}{Definition}[section]
\makeatletter
\def\ps@IEEEtitlepagestyle{%
\def\@oddfoot{\mycopyrightnotice}%
\def\@evenfoot{}%
}
\def\mycopyrightnotice{%
\begin{minipage}{\textwidth}
\centering \scriptsize
This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.\hfill% <--- Change here
\end{minipage}
\gdef\mycopyrightnotice{}% just in case
}
\makeatother
\begin{document}
\title{Modern Middlewares for Automated Vehicles: A Tutorial
\thanks{$^{1}$ The authors are with the Chair of Embedded Software, RWTH Aachen University, \texttt{kluener@embedded.rwth-aachen.de, molz@embedded.rwth-aachen.de, kampmann@embedded.rwth\-aachen.de and kowalewski@embedded.rwth-aachen.de} }
\thanks{$^{2}$ The author is with the Department of Aerospace Engineering, University of the Bundeswehr Munich, Germany, {\texttt{bassam.alrifaee@unibw.de}}}
}
\author{
\IEEEauthorblockN{
David Philipp Klüner$^{1}$\,\orcidlink{0009-0006-3451-9435},
Marius Molz$^{1}$\,\orcidlink{0009-0005-8406-8727},~\IEEEmembership{Student~Members,~IEEE},
Alexandru Kampmann$^{1}$\orcidlink{0009-0008-8340-1913},\\
Stefan Kowalewski$^{1}$\orcidlink{0000-0001-9397-2009}, and Bassam Alrifaee$^{2}$\,\orcidlink{0000-0002-5982-021X},~\IEEEmembership{Senior Member,~IEEE}
}
}
\maketitle
\begin{abstract}
This paper offers a tutorial on current middlewares in automated vehicles.
Our aim is to provide the reader with an overview of current middlewares and to identify open challenges in this field.
We start by explaining the fundamentals of software architecture in distributed systems and the distinguishing requirements of \aclp{AV}.
We then distinguish between \commids\ and \soamids\ and highlight their key principles and differences.
Next, we present five state-of-the-art middlewares as well as their capabilities and functions.
We explore how these middlewares could be applied in the design of future vehicle software and their role in the automotive domain.
Finally, we compare the five middlewares presented and discuss open research challenges.
\end{abstract}
\begin{IEEEkeywords}
Middleware, Architecture Platform, \aclp{AV}, ROS 2, Service-Oriented Architectures, Middleware Frameworks, Communication Middlewares
\end{IEEEkeywords}
\section{Introduction}
\label{sec:intro}
\subsection{Motivation}
New challenges to computing in vehicles arise as \acfp{AV} provide new automated driving functions, requiring advanced perception and complex decision making \cite{bello_recent_2019,liu_impact_2022}.
These functions require resource-intensive processing of sensor data and the implementation of advanced decision-making algorithms.
Changed perspectives lead customers of \acp{AV} to increasingly expect their vehicles to behave like other modern computing products with ongoing updates and enhancements to their capabilities \cite{aaron_aboagye_facing_2017}.
These new computing challenges have consequences on the \ac{E/E} domain and the software domain in \acp{AV} \cite{burkacky_rethinking_nodate}.
In the \ac{E/E} domain, these challenges are affecting a transition from domain-based architectures to centralized zone controller architectures \cite{zhu_requirements-driven_2021,wang_review_2024}.
In current \ac{E/E} distributed architectures, which are still prevalent today, embedded microcontrollers are used to perform some selected vehicle functions \cite{zhu_requirements-driven_2021}.
The hardware offers very limited excess compute capacity, as the hardware is cost-optimized to the software requirements.
Updating an \ac{ECU} in a current architecture requires reflashing the complete \ac{ECU}, and due to resource constraints, offers limited space for new functionalities \cite{benckendorff_comparing_2019}.
In contrast, zone controller \ac{E/E} architectures use more powerful, multi-function \acp{ZCU} for compute intensive tasks.
These platforms provide significantly more compute resources by incorporating many-core processors, different \acp{OS}, and accelerators such as \acp{FPGA} and \acp{GPU}.
In these architectures, traditional \acp{ECU} at the edge of the system interact with hardware sensors and actuators, while zone controllers or central vehicle computers perform high-level functions \cite{benckendorff_comparing_2019,zhu_requirements-driven_2021}.
In the software domain, the automotive industry is moving from current signal-oriented software architectures to new software architectures built on modern automotive middlewares \cite{wang_review_2024}.
In signal-oriented software architectures, the software on each \ac{ECU} is designed to implement a limited number of functions and, due to the strong dependence on the microcontroller, is often not reusable \cite{vetter_development_2020}.
To alleviate these challenges and support new \ac{E/E} architectures, new middlewares such as AUTOSAR \ac{AP} seek to address them \cite{autosar_ap_explanation_sw_arch}.
Modern middlewares have not yet reached market dominance in the automotive domain and are still under active development \cite{autosar_ap_explanation_sw_arch}.
However, in other domains, such as robotics, middlewares have achieved the status of ubiquity and default tooling.
In the robotics domain, the \ac{ROS 2} middleware has emerged as the de facto standard middleware that attempts to solve similar challenges \cite{malavolta_how_2020}.
Middlewares should serve as foundational software for the development of automotive software \cite{burkacky_rethinking_nodate}.
They define elements of the vehicle software architecture and provide crucial functions such as communication, update, and security for automotive applications.
Consequently, choosing the correct middleware for automotive application development is important for manufacturers, developers and researchers.
Current state-of-the-art middlewares vary in supported features, software architecture, and license requirements.
This paper provides an introduction to middlewares in \acp{AV} and an overview of the current state-of-the-art.
\subsection{Main Contributions}
\label{sec:intro:contrib}
The main contributions of this article include:
\begin{enumerate}
\item Introduction to \ac{E/E} architectures, middlewares and underlying concepts.
\item Overview of five state-of-the-art middlewares from the robotics and automotive domain and comparison of their features.
\item Examples showing how middlewares affect the software architecture of a system.
\item Discussion of current challenges facing modern middlewares.
\end{enumerate}
\subsection{Outline}
\label{sec:intro:outline}
This article is structured as follows:
\Cref{sec:background} provides the background information necessary to understand middlewares in the automotive domain.
\Cref{sec:middleware} presents the fundamental concepts of middlewares and their function in a modern automotive software stack. It also provides an overview of the state-of-the-art middlewares FastDDS, \ac{SOME/IP}, Zenoh, ROS 2, and AUTOSAR \ac{AP}.
In \cref{sec:middleware_comp}, we compare these middlewares and discuss their features and \cref{sec:challenges} presents current research challenges for middlewares in the \ac{AV} domain.
\section{Fundamentals}
\label{sec:background}
Before addressing middlewares and system software architectures in \acp{AV}, this section outlines the fundamental aspects of the software and computing hardware utilized in modern vehicles. The computing hardware is defined by the vehicle's \ac{E/E} architecture, which we explore through the following questions:
What defines an \ac{E/E} architecture and what is the current state of \ac{E/E} architectures?
Then we consider what challenges are associated with \ac{E/E} architectures and what future direction attempts to address these challenges \ac{E/E} architectures?
Once the hardware and \ac{E/E} architecture are understood, we focus on software architecture, addressed through the following questions:
What defines a software architecture and why is a well-defined software architecture essential?
To remain in the automotive domain, we consider how the software architecture influences an automotive software systems.
\begin{figure}[tb]
\centering
\includegraphics[width=0.48\textwidth]{Fig1_EEDCA.png}
\caption{Illustration of a domain-based \ac{E/E} architecture. Actuator controllers are depicted in black with gray representing a sensor. The components are connected within their own domain. The domains are determined by the function that the \acp{ECU} contribute to, for example drive train control while cooperation between domains is limited \cite{wang_review_2024}.}
\label{fig:domain_based}
\end{figure}
\subsection{What defines an \ac{E/E} architecture?}
\label{sec:background:arch}
\begin{definition}[\textit{\ac{E/E} Architecture}]
According to \citeauthor{zhu_requirements-driven_2021} \cite{zhu_requirements-driven_2021}, the E/E architecture can be defined as the organization of the electric and electronic components of the vehicle and their interactions. Key components of the architecture include \acp{ECU}, sensors, actuators, power systems, and \ac{IVN}. The \ac{IVN} allows for interactions between the components and enables the components to cooperate to perform their expected functions.
\end{definition}
\noindent The core elements of the E/E architecture are various control units known as \acp{ECU} \cite{vetter_development_2020}.
\acp{ECU} are traditionally responsible for executing control functions within the vehicle, including management of the engine, drive train, and body electronics \cite{wang_review_2024}.
These units vary in computational power, ranging from traditional embedded \acp{ECU} to high-performance zone controllers.
\begin{definition}[\ac{ECU}]
Electronic control units are the fundamental compute platforms in the vehicle. Classically based on microcontrollers and constrained in compute resources and interconnected via fieldbus systems, they operate fundamental components in the vehicle \cite{autosar_explanationPlatformDesign_2024}.
\end{definition}
\noindent Furthermore, the \ac{E/E} architecture specifies the interconnection of \acp{ECU}.
Communication is achieved through a fieldbus system, such as \ac{CAN}, FlexRay, or an Ethernet-based \ac{IVN}, which provides higher bandwidth, or a combination of these systems \cite{kampmann_dynamic_2019}. The interconnection and placement of \acp{ECU} is also referred to as the \ac{ECU} topology.
\begin{definition}[Automotive Software System]
The automotive software system refers to all software components in a vehicle. These components range from the operating system, individual functions, to algorithms in the vehicle.
\end{definition}
The choice between these communiation systems and \acp{ECU} is driven by the requirements of the \system\ \cite{wang_review_2024}.
Initially, \cref{sec:background:sig_oriented} discusses the current domain-based \ac{E/E} architectures and the challenges introduced by \acp{AV} and increased software demands at large in vehicles.
Subsequently, \cref{sec:background:ee_challenges} discusses these challenges extensively.
Finally, \cref{sec:background:zone_based} introduces the zone-based \ac{E/E} architecture, which in cooperation with middlewares, addresses these challenges.
\subsection{What is the current state of \ac{E/E} architectures?}
\label{sec:background:sig_oriented}
In current vehicles, the domain-based architecture is dominant \cite{benckendorff_comparing_2019,zhu_requirements-driven_2021}.
The core component of this current architecture is the dedicated single-application \ac{ECU}, where processor and hardware have been narrowly selected, with limited additional computing resources, to support a single or few functions \cite{van_dijk_future_2017, zhu_requirements-driven_2021,kampmann_asoa_2022}.
An example for such a single-application \ac{ECU}, is the engine control unit, which is specifically tasked only with monitoring and controlling the internal combustion engine in a vehicle.
These \acp{ECU} are commonly embedded microcontroller-based devices running real-time operating systems or software directly on the hardware.
Changes in these embedded devices often require reflashing of the microcontrollers, making changes to the software difficult.
Communication in this architecture is characterized by static fieldbus systems with fixed mappings between senders and receivers \cite{vetter_development_2020}.
This architecture pattern is also referred to as a signal-oriented architecture and is characterized by its statically defined \ac{IVN} between \acp{ECU}.
These signals follow predetermined routes from senders to receivers, organized in a communication matrix shared among all ECUs.
The statically defined communication matrix allows for real-time constraints and predictable behavior \cite{vetter_development_2020,wang_review_2024}.
The \acp{ECU} and their communication are structured by domains such as engine control or body control. Domain-based architectures require many component interconnections, as components in a single domain may not be physically close in location.
Different domains are interconnected by gateway \acp{ECU}, which bridge messages between the domains. Generally, domains are isolated from each other with gateways that provide limited interconnection between networks.
\begin{definition}[ Domain-based \ac{E/E} Architecture]
A domain-based \ac{E/E} architecture typically consists of multiple single-application \acp{ECU} interconnected to each other based on their domain. Communication is characterized by static fieldbus systems with fixed communication schedules saved in communication matrices.
\end{definition}
\Cref{fig:domain_based} illustrates an exemplary domain-based \ac{E/E} architecture, where multiple \acp{ECU} are interconnected using multiple \ac{CAN} fieldbus systems according to the domain.
The cooperation between applications in separate domains is generally limited due to bandwidth limitations.
Data from connected sensors is primarily processed locally within each ECU and is not commonly shared across the \ac{IVN}.
\subsection{What challenges are associated with \ac{E/E} architectures?}
\label{sec:background:ee_challenges}
New challenges to vehicles in general also present challenges for \ac{E/E} architectures.
Providing increasingly automated functions requires additional compute resources, and software updates require other types of software architecture.
\citeauthor{zhu_requirements-driven_2021} \cite{zhu_requirements-driven_2021} define these challenges as follows:
\begin{enumerate}
\item The bandwidth bottleneck in modern vehicles is a significant challenge, as current \acp{IVN} have limited capacity to handle the data demands of advanced perception systems in \acp{AV}. This limitation requires more efficient data transmission methods to support increased bandwidth requirements.
\item With the addition of numerous \acp{ECU} to support new vehicle functions, the wiring complexity within vehicles has increased. This increase in complexity not only makes maintenance more challenging, but also contributes to more complicated vehicle architectures, negatively affecting performance and reliability.
\item Ensuring low deterministic latency in \acp{IVN} is critical, especially in the context of highly concurrent computations, and large traffic volumes, such as sensor data. The requirement for deterministic latencies poses a challenge, necessitating improved \ac{IVN} management and data prioritization strategies.
\item The design of future automotive architectures must prioritize flexibility and scalability, facilitating online updates, maintenance, and dynamic reconfiguration.
\end{enumerate}
\subsection{What is the near-future of \ac{E/E} architectures?}
\label{sec:background:zone_based}
The currently emerging \ac{E/E} architecture, seeking to address current challenges, is the zone-based \ac{E/E} architecture \cite{zhu_requirements-driven_2021}.
The components in this \ac{E/E} architecture are structured in vehicle zones by proximity and \acp{ECU} interconnected within these zones.
In contrast to the current domain-based architecture, components are no longer integrated based on function, but rather location.
In this architecture, traditional \acp{ECU} at the edge of the vehicle are supported within a zone by \acp{ZCU} and central vehicle computers.
\acp{ZCU} represent higher performance \acp{ECU} supporting multiple vehicle functions rather than a single one. As required for co-hosting several functions at once, these architectures also support more modern software architectures. The \acp{ZCU} may employ a PC \ac{OS}, such as Linux or QNX. \cite{wang_review_2024,zhu_requirements-driven_2021}
Communication in zone-based \ac{E/E} architectures often uses automotive Ethernet as an \ac{IVN} or a hybrid communication architecture.
Hybrid topologies that integrate different fieldbus and ethernet networks, such as an ethernet \ac{IVN} between \acp{ZCU} and fieldbus \acp{IVN} to the edge \acp{ECU}, are also employed \cite{wang_review_2024}.
Automotive ethernet is an extension to classical ethernet, allowing higher data rates and increases the possible amount of interconnected components in comparison the fieldbus \acp{IVN} \cite{hu_gatekeeper_2022,noauthor_ieee_2022}.
\acp{ECU} within a zone are connected to their zones \ac{ZCU}, while the connection between zones is established by linking \acp{ZCU} either directly or using a central vehicle computer.
Due to this simplified topology, the wiring complexity is greatly reduced and software updates and new communication paths can be more easily implemented using the \acp{ZCU}.
However, more communication between \acp{ECU} and \acp{ZCU} is required, as cooperating \acp{ECU} are likely to be in separate zones \cite{wang_review_2024,zhu_requirements-driven_2021}.
For example, in hybrid topologies, the in-zone communication between edge \acp{ECU} to the \ac{ZCU} could be implemented using fieldbus-based networks, while the \acp{ZCU} use automotive ethernet to address greater bandwidth and latency requirements.
\begin{figure}[tb]
\centering
\includegraphics[width=0.48\textwidth]{Fig2_EEZCA.png}
\caption{Illustration of a zone-based \ac{E/E} architecture. Actuator controllers are depicted in black with gray representing a sensor. Each component is connected to a zone control unit, which in turn is connected to a central vehicle computer VC1. This architecture divides the vehicle into four separate zones connected according to proximity with a high degree of cross-zone cooperation \cite{wang_review_2024}.}
\label{fig:zone_based}
\end{figure}
\Cref{fig:zone_based} illustrates an example zone-based \ac{E/E} architecture.
Based on the division of the vehicle into zones, the example depicts multiple \acp{ZCU} performing multiple functions and interacting with \acp{ECU} at the edge of the vehicle.
Following the zone-based \ac{E/E} architecture, the centralized architecture has emerged as the target architecture for multiple \acp{OEM} \cite{,zhu_requirements-driven_2021}. However, the exact implementation of this architecture remains an area of active research and development.
\subsection{ What defines a software architecture?}
\label{sec:background:softarch}
\begin{definition}[\textit{Software Architecture}]
A \textit{software architecture} is defined by \citeauthor{bass_software_2003} \cite{bass_software_2003} as the structure or structures of the system. The structure is defined by the software elements, their properties, and relationships.
\end{definition}
Similar to the \ac{E/E} architecture in \cref{sec:background:arch}, design decisions include the core components of the system and the key properties of each component.
Components can take different forms, such as classes in an application, services for a web application, or individual applications composing a distributed system.
A architecture also specifies the interactions between the components of the software system.
For classes as components, interactions could be made via function calls or, in the case of web applications, HTTPS API calls.
The software architecture ensures a clear division of the responsibilities and paths of interaction in the software system.
\begin{figure}[tb]
\centering
\includegraphics[width=0.48\textwidth]{Fig3_Domain.png}
\caption{Illustration of the interaction of software and hardware in a domain-based \ac{E/E} architecture. The \system\ depicted is based on the requirements outlined in \cref{sec:background:signal_oriented_example}.}
\label{fig:domain_based_with_sw}
\end{figure}
\subsection{Why is a well-defined software architecture essential?}
\label{sec:background:arch_adv}
An automotive software architecture is based on design decisions which often have to be made quite early in the development process and have far-reaching effects on the quality of the resulting software.
It is well known that architectural design decisions determine most non-functional attributes of a \system, and therefore can either support or impair properties like maintainability, updateability, reuseability \cite{garlan_software_2014}.
\begin{itemize}
\item With the appropriate top-level design decision, the software architecture can ensure the \textit{updateability} of the software system.
The architecture can constrain the components and specify that the components must be designed with update mechanisms and modularity.
Taking into account that continued development during the vehicle lifecycle is one of the drivers of automotive software especially for \ac{SDV}, an architecture can contribute significantly to this goal.
\item Architecting a software system with well-defined paths of interaction offers additional advantages for \textit{reuse}. A software component with clear interfaces explicitly defines what the software system needs to provide and what the component offers the software system. For automotive software development, for example, multiple software components that share the same interfaces and interface definitions can easily be exchanged for one another.
\item The division of responsibilities aids in the \textit{construction} of software. Each component has well-defined tasks and responsibilities in the software system, allowing a developer to know what functions must be implemented and which are the responsibility of another developer.
\end{itemize}
\begin{figure*}[t]
\centering
\includegraphics[width=0.9\textwidth]{Fig4_MindMap.png}
\caption{Illustration of the different domains interacting with middlewares. Domains are positioned according to their topical closeness. Black signifies increased importance from the perspective of the authors.}
\label{fig:topics_mindmap}
\end{figure*}
\subsection{How does the software architecture influence automotive software systems?}
\label{sec:background:signal_oriented_example}
To show how a software architecture influences the capabilities and maintainability of a software system, we consider an example \system.
The example consists of an \ac{AD} system, and we explore how the software affects an expansion of its functionality.
As the expansion and improvement of software functions is a major consideration in automotive software architectures, this example highlights the advantages and disadvantages of the three presented software architectures.
In this example the \system\ is responsible for the automated driving functions of the vehicle and can operate safely in the operational domain of a highway. This example has been derived from the UNICARagil project, where automated vehicles were developed \cite{woopen_unicaragil_2018}.
For this purpose, the \ac{AV} has long-range, narrow field-of-view cameras.
Additionally, the \ac{AV} can park using short-range, near-field cameras and sensors, to achieve automated parking functions.
For safe operation, multiple requirements must be fullfilled and cooperation of multiple vehicle \acp{ECU} is required.
We define the basic requirements for the original, unmodified \system\ as follows.
\begin{enumerate}
\item \textit{The \system\ must detect lane boundaries, road users and traffic signs reliably on highways.}
\item \textit{The \system\ must plan a legal and safe trajectory through the detected highway environment.}
\item \textit{The \system\ must execute this trajectory safely.}
\end{enumerate}
To analyze the expansion of an architecture, we introduce one new requirement: \textit{The vehicle must drive automatically in city environments.}
We assume that this new requirement must be satisfied by updating the \system.
First, we consider an \system\ built on a domain-based \ac{E/E} and signal-oriented software architecture.
In this architecture, each function is executed on a single \ac{ECU} as depicted in \cref{fig:domain_based_with_sw}.
The \acp{ECU} for each function are connected via a \ac{CAN} fieldbus with a fixed communication schedule.
The \system\ architecture is illustrated in \cref{fig:domain_based_with_sw} involving the following \acp{ECU}:
\begin{itemize}
\item The automation \ac{ECU} performs the automated driving functions in the vehicle on the highway. In this example, these include the perception and planning functions. It transmits trajectory commands using the fieldbus to the drivetrain module. Directly connected to this system are long range cameras for the highway domain.
\item The \ac{HMI} \ac{ECU} provides the drive interface functions, such as information on the vehicles' states, and other interfaces, such as the infotainment system.
\item The drive train \ac{ECU} is responsible for controlling the drive train, including the vehicle engine, and communicating the state of the drive train back to other components of the \system. In this example, it is also responsible for executing the vehicles planned trajectory.
\item The parking \ac{ECU} implements automated parking functions. For this purpose it has access to short range, near field cameras and ultra sound distance sensors which enable the vehicle to park itself automatically.
\end{itemize}
To satisfy the new requirement of city operations, the functions of the automated driving module must be expanded.
To accomplish this, the core functionality of the automated driving module could be updated.
The functionality of the perception component must be expanded for additional requirements of the city and the AD \ac{ECU} requires access to the near-field sensors and cameras of the parking module.
Motion planning capabilities must be expanded to deal with the additional complexity of city roads and crosswalks.
As \acp{ECU} are commonly sized for their specific task, this addition of requirements could require switching to another \ac{ECU} or even adding more \acp{ECU}.
Both cases would then have to be integrated into the existing vehicle \ac{CAN} fieldbus network, require additional gateways, or consume more bandwidth than is available.
The benefits of this architecture are the avoidance of resource contention between applications, since each functionality is assigned to a dedicated \ac{ECU} that is appropriately sized.
Additionally, each \acp{ECU} can be cost-optimized to its specific function.
Changes to the communication matrix and the vehicle gateways also avoid possible \ac{IVN} contention.
However, the costs of switching hardware platform or addition of a new \ac{ECU}, additional wiring or gateways required to connect sensors or cameras, and the integration with other \acp{ECU} are high.
Consequently, implementing such changes post-manufacture is highly impractical and cost prohibitive in such an architecture.
To solve the issues highlighted by this example, new approaches to software are equally required as well as new \ac{E/E} architectures.
The following \cref{sec:middleware} will present such a new approach in the form of modern automotive middlewares in conjunction with modern \ac{E/E} architectures.
First, we introduce automotive middlewares at large, then discuss how we classify middlewares and compare five state-of-the-art middlewares in detail.
\section{Automotive Middlewares}
\label{sec:middleware}
Middlewares are used in various computing domains, including \ac{IoT} , web services and \ac{CPS} with similar objectives \cite{perera_context_2014,zeng_qos-aware_2004,kang_rdds_2012}.
\begin{definition}[\textit{Middlewares}]
\citeauthor{neely_adaptive_2006} broadly define middlewares as the layer between the application and system software, abstracting the underlying system to enable developers to focus on application-specific tasks \cite{neely_adaptive_2006}.
\end{definition}
Built on modern \ac{E/E} architectures, a new generation of automotive middlewares has emerged as the foundation of new software architectures in the automotive domain \cite{henle_architecture_2022}.
In contrast to other domains, the automotive domain is differentiated by distributed E/E architectures, heterogeneous computing platforms, and high safety requirements.
\Cref{fig:middleware_idea} presents the software stack underlying such software architectures using the example of two communicating applications in a distributed system.
\begin{definition}[\textit{Automotive Software Stack}]
We define the automotive software stack as the layers of software used to support applications. Starting with either the \ac{OS} or hypervisor, additional software frameworks and middlewares are added to provide functions to the application.
\end{definition}
The application uses an \ac{API} offered by the middleware layer to send messages from one \ac{ECU} to another application on a second \ac{ECU}.
AUTOSAR \ac{AP} in this case forwards the message to \ac{SOME/IP}, which uses the operating systems network stack to relay the message from the microcontroller to the \ac{HPC}.
This example depicts a typical automotive software stack.
In practice, as in \Cref{fig:middleware_idea}, the automotive middleware is separated into two layers.
The lower layer is a software framework concerned with communication in distributed systems, in this example \ac{SOME/IP}.
The upper layer, in this case AUTOSAR \ac{AP} is built on the communication framework, to offer features beyond communication, such as \ac{OTA} updates, resource control and security.
\begin{figure}[t]
\centering
\includegraphics[width=0.48\textwidth]{Fig5_Layers.png}
\caption{Illustration depicting the role of a middleware in the development of distributed software. The middleware functions as an intermediary between the application and the operating system. In this case AUTOSAR \ac{AP} makes use of DDS and the operating systems network stack to communicate across the two devices.}
\label{fig:middleware_idea}
\end{figure}
In literature and in the automotive domain at large, the nomenclature for these two complementary layers is not well established, and terms are used loosely.
While some authors refer to the combination of both layers as middlewares, others describe only the lower layer as a middleware, while referring to the upper layer using new, different nomenclature.
This inconsistency extends to developers, as the developers of \ac{ROS 2} mostly refer to it as a \textit{set of libraries and tools}, while AUTOSAR \ac{AP} uses \textit{platform} \cite{autosar_ap_explanation_sw_arch, open_robotics_ros_2024}.
In academia, researchers refer to \ac{ROS 2} as a middleware \cite{wu_oops_2021}, while others use different nomenclature, such as architecture platform \cite{henle_architecture_2022}.
In an effort to establish uniform terminology, we propose the term middleware as a general descriptor of the class, in keeping with its original definition \cite{neely_adaptive_2006}.
We also propose a new term for the lower communication layer, while making use of the \textit{\soamid} nomenclature defined by \citeauthor{henle_architecture_2022} \cite{henle_architecture_2022} to refer to the upper layer.
Consequently, we define automotive middleware by the following characteristics:
\begin{figure}[t]
\centering
\includegraphics[width=0.48\textwidth]{Fig6_Nomenclature.png}
\caption{Illustration depicting elements of the \system with our proposed nomenclature. We distinguish between \commids, \soamids\ and application frameworks, to refer to different elements of the automotive software stack. In the left half of the illustration, the nomenclature is shown. In the right half, AUTOSAR \ac{AP} is used as an example. }
\label{fig:middleware_nome}
\end{figure}
\begin{definition}[\textit{Automotive Middlewares}]
We define automotive middlewares as as the software layer between the application and system software. These middlewares operate in distributed, heterogeneous automotive \ac{E/E} architectures and due to the distributed system architecture, communication and structured software execution are their core functions.
\end{definition}
As a consequence of this position, middlewares interact with a wide variety of domains.
\cref{fig:topics_mindmap} illustrates these domains and highlights the section in which they are discussed.
Middlewares accomplish communication in distributed system by using new \commpat\ on \acp{IVN} to interconnect applications on different \acp{ECU}.
Some middlewares are comprehensive platforms that address many software domains in automated vehicles, such as communication, security, updates, and resource control.
To highlight the communication function of the lower layer framework, we define them as \commids\ and will discuss them in detail in \cref{sec:middleware:communication}.
We use the definition by \citeauthor{henle_architecture_2022} to refer to the higher layer, built on \commids, as \soamids \cite{henle_architecture_2022}.
Beyond communication, \shsoamids\ provide additional features such as resource control, deterministic execution, and security functions.
These \shsoamid\ also commonly rely on other \patterns .
\begin{definition}[\textit{\PATTERN}]
Software design patterns are generalized solutions for common design problems.
They are defined by \citeauthor{bass_software_2012} as descriptions of elements, for example, clients and services, and relations, such as requests between these elements, with constraints on how they can be used. They commonly describe only a subset or repeating pattern in a software architecture and classic patterns examples include the client-server pattern, the n-tier pattern, or service-orientation \cite{bass_software_2012}.
\end{definition}
Employing such \patterns, \soamids\ determine high-level architecture decisions, such as the components and communication methods of the software system.
As such, the \soamid\ is an integral part of the \system.
This class of middleware is discussed in \cref{sec:middleware:soa}.
In \cref{fig:middleware_overview}, we present an illustration of common middlewares.
The figure distinguishes between closed-source and open-source middlewares as well as our classification into \soamids\ and \commids.
\begin{figure}[bp]
\centering
\includegraphics[width=0.48\textwidth]{Fig7_MWMap.png}
\caption{Overview over common \commids \ and \soamids\ in the automotive and CPS domain. The illustration divides middlewares according to the \commid \ and \soamid\ distinction as well as according to their access limitations.}
\label{fig:middleware_overview}
\end{figure}
\subsection{What are \COMMIDS?}
\label{sec:middleware:communication}
\noindent \Commids\ are core to automotive software architectures, facilitating data exchange between various \acp{ECU} \cite{autosar_consortium_ip_2023}.
They accomplish this by separating the application from the underlying \ac{IVN} topology. This is commonly implement by discovery, where communication paths are not predetermined but are dynamically discovered at runtime.
Alternatively, centralized definitions of network topology can be used to separate the \ac{IVN} from the application.
This conceptually simple \pattern\ allows the application built on the middleware to be independent of the specific ECU and \ac{IVN} topology, since all other applications in the network are dynamically discovered.
\begin{definition}[\COMMIDS]
\Commids\ are middlewares designed to implement communication within distributed systems.
They provide \commpats\ such as publish-subscribe or request-response communication and configurable \ac{QoS} \cite{eprosima_dds_2024}.
\end{definition}
\begin{definition}[\textit{Discovery}]
Discovery in a modern middleware allows an application to automatically discover and connect to all peer applications, commonly in the same network, without manual configuration of connections \cite{eprosima_5_2024}.
\end{definition}
\noindent As a result, no changes to communication parameters are necessary if an application is updated or moved to another \ac{ECU}.
For simplified communication, these middlewares implement \commpats\ that define how communication is structured.
\begin{definition}[\textit{\COMMPAT}]
We define communication patterns, derived from the software pattern definition, as the structure and sequence of messages, whether it is one-sided communication or an exchange of messages, and how recipients of these messages are determined.
\end{definition}
\noindent Simple \commpats\ allow developers to focus on the core functions of their applications instead of \ac{IVN} configuration.
The two most common \commpats\ in modern middlewares are publish-subscribe and request-response communication. These \commpats\ are present in most middlewares presented in this tutorial.
In \textit{Publish-Subscribe} communication, data is separated into messages, which are structured using topics \cite{eprosima_dds_2024}.
Topics serve as separate channels of communication that allow access to all messages on them.
\Cref{fig:example_dds} depicts an example of a topic-based communication.
A participant can publish messages on a topic, and a participant which wants to receive the message can subscribe to it to be notified.
As a result, messages are not directly associated with a recipient, but only with their topic. Thus, allowing new participants to easily join existing networks, as it can just interact with already existing topics.
In \textit{Request-Response} communication, a participant can send a request to another remote participant, which will return a response to the request \cite{autosar_consortium_ip_2023}.
This \commpat\ is commonly used to call remote methods on other machines, similar to regular function calls.
\begin{figure}[tb]
\centering
\includegraphics[width=0.48\textwidth]{Fig8_DDS.png}
\caption{Illustration depicting topic-based communication between publishers and subscribers components in a DDS domain. }
\label{fig:example_dds}
\end{figure}
\Commids\ may also address reliability and security considerations in \acp{IVN}. To facilitate functional safety in communication, some middlewares offer configurable \ac{QoS} which can ensure the reliability of message transmission. For security considerations, the middlewares may directly support encryption of exchanged messages while others may offer optional extensions to supplement security features.
The implementation of \commids\ is commonly built on the IP network stack in the host operating system to access ethernet-based \ac{IVN}.
\ac{TCP}, \ac{UDP}, and shared memory are commonly used as communication protocols.
Commonly, middlewares automatically determine which transport to use depending on the \ac{IVN} and \ac{E/E} architecture.
The following sections present three \commids. FastDDS,
an open source implementation of the \ac{DDS} standard, \ac{SOME/IP} the automotive industries approach and Zenoh an emerging middleware.
\subsubsection{SOME/IP}
\label{sec:middleware:someip}
A standard that defines a \commid\ is the \acfp{SOME/IP}.
It was defined as an automotive \commid\ standard for the AUTOSAR project and maintained in connection with the project.
It is under development by the AUTOSAR consortium consisting of major \acp{OEM} and automotive tier one suppliers. It represents an approach to middlewares by the automotive industry.
It shares some concepts with other middlewares, such as \ac{DDS} discussed in \cref{sec:middleware:fastdds}. These similarities include \commpats\ and methods, such as the underlying protocols and the use of the \ac{OS} network stack \cite{autosar_consortium_ip_2023}.
In its core design principles, \ac{SOME/IP} was specifically developed to work with stringent resource budgets of embedded devices and aims to ensure compatibility across a wide range of use cases and communication partners.
Due to its origin in the AUTOSAR project, it is specifically and narrowly designed for the automotive domain.
Additional design objectives due to the origin of the middleware were compatibility with its predecessor AUTOSAR classic and the ability to scale to full \system\ with hundreds of applications.
To transport \ac{SOME/IP} messages, different transport protocols can be used, currently supporting \ac{UDP} and \ac{TCP}. \ac{SOME/IP} can be configured to use both; however, developers recommend configurations depending on the network characteristics.
\ac{SOME/IP} supports both publish-subscribe and request-response communication but uses proprietary names for these \commpats, detailed in \cref{sec:middleware:communication}. In addition to these common \commpats, it also supports \patterns\ to distribute values globally throughout a \system. These values, called fields, are accessible by every application in a \ac{SOME/IP} software system. These \commpats\ are implemented in three features:
\underline{Methods} are a \textit{request-response} communication paradigm and allow remote methods to be called.
A request sent to a local or remote application is processed and an optional response is returned to the calling service.
This \textit{request-response} communication also supports \textit{fire-and-forget}, where only the request is transmitted without a response.
The standard specifies this with an initial request message and a corresponding response message.
\underline{Events} are transmitted by notification to inform other applications of an event in the \system.
Notifications follow the \textit{publish-subscribe} concept, where applications can decide to subscribe to the notification.
For example, these events could be used to notify other components of a brake event when an automated system detects a possible collision.
Notifications can be sent according to different strategies, such as cyclical, on-change, and epsilon-change when the considered value changes beyond an epsilon threshold.
\underline{Fields} are shared values in a automotive system based on \ac{SOME/IP}.
They are accessible via the \textit{getter and setter functions} and use event notification to distribute values throughout the software system.
They allow applications to share values and receive updates on changes to this value.
The \textit{getter and setter} functionality builds on the methods functions, and updates are sent via events.
An exhaustive overview of the capabilities of \ac{SOME/IP} can be found in \cite{autosar_consortium_ip_2023}.
\ac{SOME/IP} also supports with an extension the automatic discovery of applications in a network \cite{autosar_consortium_ip_2023}.
The SOME/IP-SD (SOME/IP-Service Discovery) extension allows the application to locate service instances inside the \ac{IVN} on other \acp{ECU}.
It also enables \ac{SOME/IP} to determine whether a service instance is running and subsequently implement the publish subscribe handling.
For its implementation, \ac{SOME/IP} uses the network stack of the underlying POSIX operating system.
It supports \ac{UDP} and \ac{TCP} communication and standard documentation recommends the use of both under specific conditions.
The service discovery functionality is implemented using \ac{UDP} multi-cast messages.
\ac{SOME/IP} does not directly provide communication security features. In the AUTOSAR \ac{AP} stack, security is provided by the \ac{CM} with the addition of another layer of security protocols layered on \ac{SOME/IP} \cite{autosar_communicationManagement_2024}.
\subsubsection{FastDDS}
\label{sec:middleware:fastdds}
An open-source \commid\ standard in competition with \ac{SOME/IP} is the \ac{DDS} standard defined by the \ac{OMG}.
FastDDS is an open-source implementation of this standard.
The \ac{DDS} standard defines \commpats\ in distributed systems and a wire protocol \cite{eprosima_dds_2024}.
Due to the open-source nature, large community, and inclusion in the \ac{ROS 2} project, it represents a good choice for communication middleware.
Communication in \ac{DDS} is data centric.
Data in \ac{DDS} is structured using the publish-subscribe \commpat.
It is associated with a topic and is accessible to all participants who are subscribed to the topic.
This type of communication can also be classified as anonymous communication because the sender is not required to determine a specific receiver \cite{eprosima_11_2024}.
The core component for communication on the DDS layer is the domain participant which an application can create to begin FastDDS communication.
To send data to a topic, a participant can create a publisher for this topic \cite{eprosima_3_2024}.
To receive this data, a participant that requires this data can create a subscriber to be informed when new data is available.
This mechanism continues to work even for newly joined FastDDS applications, which can subscribe and/or publish to existing topics and seamlessly interact with the existing network at runtime.
The integration of new participants is enabled by dynamic service discovery, where FastDDS applications advertise their presence using multicast \ac{UDP} messages to other applications on the same network \cite{eprosima_5_2024}.
Discovery takes place in two phases; In the first phase, other applications in the same network using FastDDS are discovered.
Once these are known, information about endpoints such as subscribers and publishers is exchanged and communication channels are established.
FastDDS also offers other mechanisms, such as manual, static, or predefined discovery, to reduce discovery times and to have more control over the discovery process.
This allows for the configuration of a fixed communication topology, eliminating the need for the discovery process, or a dynamic discovery process, where new participants are connected at runtime into the communication at the cost of overhead discovery traffic.
DDS specifies the RTPS protocol on top of \ac{TCP} or \ac{UDP} for communication, but additionally FastDDS also supports shared memory \cite{eprosima_6_2024}.
It seamlessly switches between these depending on the network topology, similar to \ac{SOME/IP}.
To address mixed-criticality traffic with different requirements, FastDDS offers control over \ac{QoS} to configure transmission reliability, message history storage behavior, among other settings for each topic, endpoint, and participants in the network \cite{eprosima_12_2024}.
Using these \ac{QoS} settings, the application can configure if a history of past sent messages should be kept, if the communication must be reliable, or if only the best transmission effort should be made. These configurations present a trade off, as reliability may incur overhead while best-effort may result in messages lost in case of contention.
FastDDS offers extensive \ac{QoS} parameters, defined in \cite{eprosima_12_2024}.
To address security challenges in \acp{IVN}, the \ac{DDS} standard offers multiple extensions.
From these extensions, FastDDS implements tools for the authentication of participants when joining a \ac{DDS} network \cite{eprosima_8_2024}.
In addition, it implements access control methods to prevent participants from performing protected operations, cryptographic extensions that enable the encryption of traffic between endpoints, and additional security features.
\subsubsection{Zenoh}
\label{sec:middleware:Zenoh}
\begin{figure}[tbp]
\centering
\includegraphics[width=0.48\textwidth]{Fig9_Zenoh.png}
\caption{Non-comprehensive illustration of Zenohs resource-structured \commpats. Publishers and subscribers communicating using keys and selectors and Queryables operating as sources of Zenohs resources.}
\label{fig:zenoh_paradigm}
\end{figure}
Zenoh is a recent addition to the domain of \commids.
According to the developers \citeauthor{corsaro_zenoh_2023} \cite{corsaro_zenoh_2023}, it was designed with the lessons learned from more established middlewares, such as \ac{DDS} and \ac{MQTT}.
It aims to improve performance by decreasing protocol transmission overhead and reducing latency in contrast to existing protocols.
In addition, Zenoh seeks to address a multitude of challenges, such as scale, network topology, resource constrained devices, and data in motion and at rest.
In Zenoh, data is structured in \textit{resources} $(\texttt{key},\texttt{value})$ and associated with keys \cite{corsaro_zenoh_2023}.
Keys are used to identify data, such as \textit{/key/a} and accessed by using either the key or a selector \cite{corsaro_zenoh_2023}.
A selector allows for the specification of matching operators that enable access to multiple keys at once.
For instance, to select multiple subresources at once, \textit{/key/*} could be used.
\cref{fig:zenoh_paradigm} illustrates the communication paradigms used by Zenoh, such as resource-structured publish-subscribe and queryables.
Supporting this data model, the core components of Zenoh are publishers, subscribers, and queryables.
Publishers can be understood as origins of Zenoh resources, creating resources for a single key or for a key expression. Shown in \cref{fig:zenoh_paradigm} in example one.
Similarly, subscribers can be understood as the sink of resources, again delivering all resources that match either a single key or an expression. This is shown in \cref{fig:zenoh_paradigm} in example two by a subscriber for \textit{/key2/*}, as this subscriber receives both messages from \textit{/key2/a} and \textit{/key2/b} publishers.
Queryables deviate from the known publish-subscribe \commpat\ by delivering a resource if a key to which their expression matches is queried \cite{corsaro_zenoh_2023}. \cref{fig:zenoh_paradigm} again illustrates this in example three, where a participant queries for \textit{/key3/*}, to which the queryable that generates \textit{/key3/a} resources responds with a \textit{/key3/a} resource.
The components in Zenoh are built from a limited set of primitives.
These allow for the declaration of the previously discussed components, such as subscribers, publishers, resources, and queryables.
However, they can also be used directly as atomic primitives. These primitive are \textit{put}, \textit{delete}, and \textit{get}.
The \textit{put} primitive allows for the creation of new resources, while the \textit{delete} allows for destruction. The query operation \textit{get} issues queries to the Zenoh system. The parameters allow for the specification of the matching policy.
The Zenoh protocol can be used on the data link, network, or transport layer, which enables it to operate with embedded systems in resource constraint environments.
To secure communication, Zenoh offers support for authentication and secure channel plugins and can operate on the TLS security layer.
\subsubsection{\COMMID\ example}
In a \system\ built on a \commid\ and a modern \ac{E/E} architecture, a single \ac{ECU} can support multiple applications and is likely to have additional compute capacity.
The middleware allows applications to communicate transparently between different \acp{ECU} and new applications can dynamically extend the \system.
\begin{figure}[tb]
\centering
\includegraphics[width=0.47\textwidth]{Fig10_DDS.png}
\caption{Example software system architecture using a \commid. Multiple applications share \acp{ECU} and communicate using DDS. In DDS, topics serve as the communication keys. In signal-oriented architectures fieldbus systems structure communication, illustrated in \cref{sec:background:signal_oriented_example}.}
\label{fig:example_commid}
\end{figure}
To implement the expansion of the operational domain to the city, presented in \cref{sec:background:signal_oriented_example}, the applications in an architecture based on a \commid\ could be updated.
If sufficient compute resources are available, the updated applications could be deployed to the existing \ac{ECU}.
The deployment of such an application is illustrated in \cref{fig:example_commid}, in contrast \cref{sec:background:signal_oriented_example} illustrates the system in a domain-based architecture.
No changes to the communication infrastructure or other applications are required, as the new application can integrate into the \ac{DDS} domain.
To accomplish this, the application can subscribe to existing topics and access the data required for its function.
The new application can then easily collect images and sensor data from all sensors in the vehicle, including the near-field sensors, originally included in the vehicle for automated parking.
In addition, it can also send new trajectory commands using the existing \textit{Control} topic to send commands to the drivetrain \ac{ECU}.
This can be accomplished by publishing new messages using \ac{DDS} and can occur without changes to the drivetrain \ac{ECU}.
The core advantage of this approach is that no new dedicated \ac{ECU} is required to add new functions.
However, \commids\ do not provide automated tools for this process and offer few other assurances, as their focus is on communication.
No changes are required to the remaining applications as a result of the extension.
However, this approach presents the risk of computing resource contention on the automation module and possible network contention.
Additionally, \acp{ECU} or vehicle computers running a full operating system and communicating over ethernet introduce new cyber security attack vectors over a signal-oriented architecture.
\subsection{What are \soamids?}
\label{sec:middleware:soa}
\begin{definition}[\Soamids]
\Soamids\ are comprehensive frameworks for the development of automotive software systems.
Beyond communication, they enforce \patterns, offer comprehensive tooling for development and deployment, and often provide execution models, security features, and system state management concepts.
\end{definition}
\noindent While communication is the core challenge of any middleware, automotive software systems present additional challenges.
Among these challenges are wide-ranging questions such as real-time requirements and deterministic compute in distributed systems, requiring mechanisms to ensure communication and compute deadlines are met, and computations are unaffected by varying propagation delays through the software system.
In the same vein, in a distributed software system, allocation of resources becomes a non-trivial task, especially in a changing software system supporting \ac{OTA} updates.
\Commids\ commonly offer no solutions to these questions, while \soamids\ seek to address them.
\Soamids\ are broad software frameworks that address multiple challenges from different domains, such as software updates, maintenance, resource allocation, and determinism.
To provide communication, they generally make use of a \commid\ discussed in \cref{sec:middleware:communication}.
This relationship was already illustrated in \cref{fig:middleware_idea}, where AUTOSAR \ac{AP} uses \ac{SOME/IP} for its communication.
Thereby, inheriting the advantages these \commids\ offered to applications and building on them.
In addition \soamids\, commonly use \patterns.
An example of these \patterns\ is service-orientation, which proposes a division of software into individual components according to their functionality \cite{kampmann_dynamic_2019}.
This offers advantages for reuse, development, management of responsibilities, and updatability of the software system.
Examples of these \soamids\ include \ac{ROS 2} and AUTOSAR \ac{AP}, which will be discussed in the following \cref{sec:middleware:ap,sec:middleware:ROS 2}.
\subsubsection{ROS 2}
\label{sec:middleware:ROS 2}
The dominant \soamid\ in the robotics domain is \ac{ROS 2} \cite{malavolta_how_2020}.
We classify it as a \soamid, as it is a feature-rich framework for robotic software development \cite{macenski_robot_2022}.
\ac{ROS 2} is a publicly available open-source project.
Researchers and organizations have suggested adopting \ac{ROS 2} in the automotive sector, given the success of \ac{ROS 2} in the robotic domain and similarities to the automotive domain \cite{henle_architecture_2022}.
A private company seeking to bring \ac{ROS 2} to the automotive domain is Apex.AI.
The company provides a proprietary spin-off variant of \ac{ROS 2}, known as Apex.OS, which is tailored for the automotive industry.
Apex.OS is certified to ISO 26262, ASIL D.
Consequently, this framework is suitable for use in safety-critical automotive software applications \cite{becker_safety-certified_2021,ekberg_autosar_2022}.
The software architecture in a \ac{ROS 2}-based software system follows \ac{SOA} \patterns, as the software is divided into distributed nodes in a compute graph \cite{open_robotics_nodes_2024}.
These nodes perform functions similar to services and are in general independent of their underlying hardware.
\ac{ROS 2} employs a DDS-based \commid\ for its communication. This \commid\ provides features as discussed in \cref{sec:middleware:fastdds}, such as discovery and publish-subscribe \commpat.
However \ac{ROS 2} also builds on \ac{DDS} to implement additional functions and offers the option to exchange \ac{DDS} implementations \cite{open_robotics_interfaces_2024}.
For basic communication between nodes, two \commpats\ are available in the framework.
\begin{itemize}
\item Publish-Subscribe communication is used by \ac{ROS 2} for connections between nodes.
Consequently, the DDS topic \pattern\ is retained, but \ac{ROS 2} provides its own serialization solution.
With this solution, \ac{ROS 2} enables communication between multiple programming languages. Thereby allowing for cooperation between nodes using different languages.
Additionally, \ac{ROS 2} provides an execution model that controls communication callbacks to user code.
In this model, imposes an execution order on these callbacks and timer activation's using the executor execution model.
\item Request-Response is build on \ac{DDS} publish-subscribe communication.
This \pattern\ is implemented in services and actions.
Services expose a remote interface possibly on another \ac{ECU}, which can be called and returns a response upon completion.
Actions behave similarly; however, in addition to responding, they provide periodic feedback to the calling node on the progress of the request.
\end{itemize}
In \ac{ROS 2}, the execution model takes the form of the executor model with a callback-driven interface \cite{macenski_robot_2022,open_robotics_executors_2024}.
User-specified timers, events, and message handlers can be enrolled in the executor instance. The executor itself then processes the callbacks of the enrolled function, such as the callbacks of the message handler, in a partially predictable manner \cite{macenski_robot_2022}.
Execution models, such as executors, enable assumptions about the behavior of a node and, by conclusion, the \system\ at large.
However, the standard execution model of \ac{ROS 2} does not support a strict execution order or deterministic execution times \cite{henle_architecture_2022}.
When events or messages must be queued for processing, which could be the case when the frequency and processing time of callbacks exceed the capacity of a single thread, the executor handles them using a round-robin approach. This can have adverse consequences, such as priority inversion and task starvation. Consequently, critical task timings may be missed, making it difficult to reliably estimate worst-case execution times for task execution \cite{open_robotics_executors_2024,belsare_micro-ros_2023}.
\begin{figure}[t!]
\centering
\includegraphics[width=0.48\textwidth]{Fig11_ROS2States.png}
\caption{Overview of the ROS 2 lifecycle state machine. Transitory states are shown in grey and primary states in black\cite{macenski_impact_2023}.}
\label{fig:ROS2Lifecycle}
\end{figure}
An improved version of the \ac{ROS 2} execution model is implemented in the \textit{micro-ROS} framework. Designed for embedded systems, it offers an improved executor compared to the default in \ac{ROS 2} \cite{belsare_micro-ros_2023,macenski_impact_2023}.
This executor, called \textit{rclc}, enables a fixed execution order and deterministic scheduling \cite{staschulat_rclc_2020}. In addition, it can directly manage the operating system scheduler, enabling custom task prioritization \cite{belsare_micro-ros_2023}.
\ac{ROS 2} also supports configuration management.
It provides a parameter \ac{API} that allows the user to set default parameters and change the parameterization of nodes at runtime \cite{macenski_robot_2022,open_robotics_parameters_nodate}.
To start a \ac{ROS 2} software system of multiple nodes, it provides launch files to define the required nodes and start them automatically \cite{open_robotics_launch_2024}.
To start a \ac{ROS 2} software system and transition it to an active state, multiple steps, such as initialization of software components or hardware, might be required.
To formalize this startup process and the larger lifecycle of nodes, \ac{ROS 2} supports a lifecycle model.
This model is implemented as a state machine in every \textit{lifecycle} node.
\cref{fig:ROS2Lifecycle} illustrates the transitions between \textit{primary} states.
These state transitions allow for the representation of tasks at the start and termination of nodes.
These may include the start sequence for a sensor system or initialization of external software components.
This mechanism can also be used to free system resources if a node is temporarily inactivated or shutdown.
The transitions of the state machine within the node can be controlled both externally by a central controller or internally by the node itself \cite{macenski_robot_2022,macenski_impact_2023}.
\ac{ROS 2} supports secure communications between nodes using the DDS security standard \cite{open_robotics_ros_2024}.
The standard supports extensions for access control to limit the operations that each entity can perform. Authentication ensures that only permitted entities can join the ROS 2 network. The cryptographic service in the standard allows message encryption to prevent unauthorized access.
The security services in ROS 2 are, consequently, provided by the underlying \commid.
To enable security in \ac{ROS 2}, each participant in the \ac{ROS 2} software system needs configuration files, which require additional software for setup. However, to simplify the configuration process, \ac{ROS 2} offers the \textit{sros2} package, which includes tools that facilitate the setup of the underlying DDS-Security layer \cite{vilches_sros2_2022,open_robotics_setting_nodate}.
\ac{ROS 2} provides as an expansive open-source project additional tools such as logging with a common interface. To visualize data in an ROS 2 network, the RQT visualization supports many ROS 2 standard messages and can visualize them graphically. ROS 2 rosbag supports recording data in a \ac{ROS 2} network and replaying the data to easily replicate and test the nodes.
\subsubsection{AUTOSAR Adaptive Platform}
\label{sec:middleware:ap}
AUTOSAR \ac{AP} is a standard proposed by the automotive industry for an automotive \soamid\ \cite{reichart_progress_2021}.
This standard originated in industry to realize the shift from signal-oriented architectures, standardized in AUTOSAR Classic, to middleware-based architectures.
It is developed by a large consortium of \acp{OEM} and automotive suppliers specifically for the automotive domain.
Due to its commercial origin, implementations of the standard are commercially available by a number of companies.
AUTOSAR \ac{AP} form a comprehensive standard, providing solutions to many challenges in modern centralized or domain controller architectures \cite{furst_autosar_2016}.
\begin{figure}[tbp]
\centering
\includegraphics[width=0.5\textwidth]{Fig12_AP.png}
\caption{Overview of the AUTOSAR Adaptive Platform Functional Clusters, derived from \cite{autosar_consortium_explanation_2023}.}
\label{fig:adaptivePlatform}
\end{figure}
The explanation of the standards outlines several core \patterns\ \cite{autosar_consortium_explanation_2023}, such as planned dynamics, service-oriented architecture, and parallel processing, among others.
Under the idea of planned dynamics, dynamic operations should be pre-planned in the vehicle such as to ensure their safety and move the computation from the moment of change to before.
In the \pattern\ of service-oriented software architectures, software is divided into separate services to harness simplified updateability and understanding of the software system.
\acp{AA} are built on AUTOSAR \ac{AP} and use functionalities provided by it.
To access functionality provided by \ac{AP} \acp{FC} applications use the \ac{ARA} API \cite{autosar_explanationPlatformDesign_2024}.
In AUTOSAR \ac{AP} several clusters exist that serve purposes such as communication, execution, and state management, with an exhaustive list enumerated in \cref{fig:adaptivePlatform}.
Adaptive applications and functional clusters are implemented on a POSIX \ac{OS} and provide their functions through requests or directly using a library interface.
Both of these components run on the underlying machine as processes and generally communicate via \ac{IPC}. This communication method uses operating system functions, such as pipes or shared memory, to efficiently communicate between processes.
As a core functionality, the communication management functional cluster exposes several methods for communication between services \cite{autosar_communicationManagement_2024}.
Based on the \ac{SOME/IP} \commid, it enables inter- and intra-machine communication.
It supports the same \commpats\ in fields, methods, events, and static or dynamic application discovery as \ac{SOME/IP}.
In addition, it also ensures the type and allowable range of every field in a message.
To support communication with the AUTOSAR Classic \acp{ECU}, \ac{S2S} components can also be employed.
These enable transparent mapping between \ac{SOME/IP} ethernet-based communication and fieldbus systems.
To manage all adaptive applications and functional clusters in a vehicle and ensure their correct startup procedure, the state management and execution management functional clusters exist \cite{autosar_executionManagement_2024}.
The \ac{EM} cluster controls execution in adaptive applications, starting and pausing applications as \ac{OS} processes, while the \ac{SM} decides which function group to start.
In AUTOSAR \ac{AP} the state management is modeled as a state machine, which controls the initial startup and the configuration of the function group at run-time. Like in \ac{ROS 2}, the lifecycle can be modeled by transitioning the state machine between multiple discrete states, such as \textit{Startup}, \textit{Shutdown} or \textit{Restart} \cite{henle_architecture_2022,autosar_executionManagement_2024}.
Additional responsibilities of the state management include the enforcement of resource constraints and ensuring that only trusted applications can be executed.
AUTOSAR \ac{AP} also supports methods for deterministic execution in the form of data and time determinism \cite{autosar_communicationManagement_2024}.
In the case of execution determinism, the same internal state and input data deterministically produce a predictable result, whereas time determinism ensures that the computation completes before the deadline.
To this end, the execution management supports event-based and cyclically triggered execution using the deterministic client interface.
To allow for parallelism, the execution management also supports worker pools that a main thread can defer execution to.
This approach enables deterministic execution, which is currently not achievable in \ac{ROS 2} \cite{macenski_impact_2023}.
However, \citeauthor{menard_achieving_2020} claim that this approach is insufficient to yield a deterministic system and present an approach to address this shortcoming \cite{menard_achieving_2020}.
To ensure security, AUTOSAR \ac{AP} contains functional clusters for cryptography, firewall, and intrusion detection.
These clusters enable encryption of \ac{IVN} traffic, ensure that all machines only expose necessary ports to the \ac{IVN} and attempt to detect intrusion attempts \cite{autosar_ap_explanation_sw_arch}.
The \ac{UCM} functional cluster in AUTOSAR \ac{AP} performs package management functions.
It supports operations such as updating, installing, removing, and keeping records, similar to traditional package managers.
\ac{UCM} maintains a local registry of packages, which serve as the units of installation within the AUTOSAR \ac{AP}.
Using this mechanism, \ac{OTA} updates can be applied \cite{henle_architecture_2022,autosar_consortium_explanation_2023}.
AUTOSAR Adaptive also offers clusters for persistence in vehicles, automatic configuration of the \ac{IVN}, time syncing, diagnostic services, logging and efficient data transmission using raw data streams. \cref{fig:adaptivePlatform} depicts a comprehensive overview of all functional clusters specified in AUTOSAR \ac{AP}.
\subsubsection{\Soamid\ example}
\label{sec:middleware:soamid_example}
\begin{figure}[tbp]
\centering
\includegraphics[width=\ImageSize]{Fig13_AUTOSAR.png}
\caption{Example software system architecture using a \soamid. All components are finely divided into individual service-oriented components and have an individual runtime environment provided by the \shsoamid.}
\label{fig:example_soamid}
\end{figure}
In a software system built on a \soamid, the \shsoamid\ commonly enforces a service-oriented architecture of the applications.
Furthermore, \soamids\ often have a run-time environment in which the application runs.
This environment supports additional functions to help in the deployment, maintenance, and development of the \system\ and its applications.
\noindent In our example, using a \soamid\ would make it possible to implement the expansion of the operational design domain by automatically deploying a new service to the automated driving \ac{ECU}.
This deployment can be accomplished using \ac{OTA} updates using AUTOSAR \acp{AP} \ac{UCM} cluster, and the service is provisioned with the required resources by the execution management functional cluster.
This approach inherits the benefits of the underlying \commid, such as modular and flexible communication, as depicted in \cref{fig:example_soamid}.
Applications can still use the topic-based publish-subscribe paradigm for message exchange, and the service could access all sensors in the vehicle.
It would also be able to issue commands seamlessly, similar to the \commid\ example.
The core advantage of this approach is that \soamids\ require the division of software components into services and offers support for these services.
The service-oriented architecture ensures a clear division of responsibilities and therefore simplifies updates, maintenance, and even development.
The \soamid\ introduces additional capabilities for \ac{OTA} updates, software system parameterization, and resource management.
The runtime environment aids in the deployment of the new service, employing virtualization techniques to efficiently allocate and manage computational resources.
However, the increased cyber-security risk is also retained, due to the increased complexity of components involved in supporting an application.
\section{Comparison of Modern Middlwares}
\label{sec:middleware_comp}
\begin{table*}[!htb]
\renewcommand{\arraystretch}{1.2}
\caption{Middlewares in the Automotive Domain}
\label{tab:middleware-comparison}
\begin{footnotesize}
\begin{tabulary}{\textwidth }{l *{5}{C}}
\toprule
Criteria & Robot Operating System 2 & AUTOSAR Adaptive Platform & DDS (FastDDS) & SOME/IP & Zenoh \\
\midrule
Non-Technical Criteria & & & & & \\
\midrule
Type of Middleware & \textit{Platform} & \textit{Platform} & \textit{Communication} & \textit{Communication} & \textit{Communication} \\
Operation Domain & robotics \cite{macenski_robot_2022} & automotive \cite{autosar_consortium_explanation_2023} & general \cite{eprosima_11_2024} & automotive \cite{autosar_consortium_explanation_2023} & general \cite{corsaro_zenoh_2023} \\
License and Accessibility & open-source, free \cite{macenski_robot_2022} & closed-source, commercial \cite{autosar_consortium_explanation_2023} & open-source, free \cite{eprosima_11_2024} & closed-source, commercial & open-source, free \cite{eclipse_foundation_abstractions_2024} \\
Documentation & open, comprehensive documentation \cite{macenski_robot_2022} & standards, commercial partner\textsuperscript{2} \cite{autosar_consortium_explanation_2023} & open, comprehensive documentation \cite{eprosima_11_2024} & standards, commercial partner\textsuperscript{2} & open documentation \cite{eclipse_foundation_abstractions_2024} \\
Software Tooling & extensive \cite{open_robotics_ros_2024} & commercial partner\textsuperscript{2} & extensive & commercial partner\textsuperscript{2} & limited \\
Industry Adoption & widely, robotics \cite{malavolta_how_2020} & emerging, automotive industry \cite{zhu_requirements-driven_2021} & widely, various industries & emerging, automotive industry & emerging, various industry \cite{eclipse_foundation_zenoh_2024} \\
\midrule
Technical Criteria & & & & & \\
\midrule
\Commpats & publish-subscribe, request-response \cite{macenski_robot_2022} & methods, fields, events \cite{autosar_communicationManagement_2024} & publish-subscribe \cite{eprosima_11_2024} & methods, fields, events \cite{autosar_someip_2024} & publish-subscribe, put-get, queryables \cite{corsaro_zenoh_2023, eclipse_foundation_abstractions_2024} \\
Real-Time Communication & soft real-time \cite{macenski_robot_2022} & soft real-time \cite{autosar_communicationManagement_2024} & soft real-time \cite{eprosima_11_2024} & soft real-time \cite{autosar_someip_2024} & unsupported \\
Quality of Service & derived from DDS \cite{open_robotics_quality_2024} & derived from DDS \cite{autosar_communicationManagement_2024} & extensive \cite{eprosima_12_2024} & limited/unsupported \cite{autosar_someip_2024} & limited - Reliable/BestEffort \cite{eclipse_foundation_zenoh_2024} \\
Communication Protocols & DDS - RTPS \cite{macenski_robot_2022} & \ac{DDS} - RTPS, SOME/IP & RTPS - TCP/UDP, shared memory \cite{eprosima_6_2024} & proprietary - TCP/UDP \cite{autosar_someip_2024} & proprietary \cite{corsaro_zenoh_2023} \\
\midrule
Execution Model & executors concept \cite{open_robotics_executors_2024} & EM deterministic client \cite{autosar_executionManagement_2024} & unsupported & unsupported & Zenoh-Flow \cite{eclipse_foundation_zenoh-flow_2024} \\
System State Management & lifecycle nodes \cite{macenski_robot_2022} & State Management \cite{autosar_ap_explanation_sw_arch} & unsupported & unsupported & unsupported \\
Application Configuration Management & node parametrization \cite{macenski_robot_2022} & UCM \cite{autosar_ap_explanation_sw_arch} & unsupported & unsupported & unsupported \\
\midrule
Application Discovery & automatic \cite{macenski_robot_2022,eprosima_5_2024} & automatic \cite{autosar_consortium_ip_2023} & manual / automatic \cite{eprosima_5_2024} & manual / automatic - SOME/IP-SD \cite{autosar_consortium_ip_2023} & automatic \cite{eclipse_foundation_deployment_2024} \\
Application Update Mechanism & unsupported & UCM \cite{autosar_ap_explanation_sw_arch} & unsupported & unsupported & unsupported \\
Feature Extension & supported\textsuperscript{3} \cite{macenski_robot_2022} & unsupported \cite{autosar_ap_explanation_sw_arch}\textsuperscript{1} & supported\textsuperscript{3} \cite{eprosima_11_2024} & unsupported \cite{autosar_ap_explanation_sw_arch} \textsuperscript{1} & supported \cite{eclipse_foundation_zenoh_2024} \\
Application Resource Management & unsupported & supported, EM \cite{autosar_executionManagement_2024} & unsupported & unsupported & unsupported \\
\midrule
Communication Encryption & supported, SROS 2 \cite{open_robotics_ros_2024,macenski_robot_2022} & supported, \ac{CM} \cite{autosar_communicationManagement_2024} & supported \cite{eprosima_8_2024} & unsupported \textsuperscript{4} & supported, TLS \cite{corsaro_zenoh_2023} \\
Application Authentication & supported, SROS 2 \cite{open_robotics_ros_2024,macenski_robot_2022} & supported, \ac{CM} \cite{autosar_communicationManagement_2024} & supported, DDS Sec \cite{eprosima_8_2024} & unsupported \textsuperscript{4} & supported, TLS \cite{corsaro_zenoh_2023} \\
Additional Security Features & DDS Sec, SROS 2 \cite{open_robotics_ros_2024,macenski_robot_2022} & IDS, Firewall, Network & access control \cite{eprosima_8_2024} & unsupported \textsuperscript{4} & unsupported \\
\midrule
Platform Support & Linux, MacOS, Windows \cite{open_robotics_installation_2024} & POSIX OS \cite{autosar_ap_explanation_sw_arch} & Linux, MacOS, Windows, Android, QNX \cite{eprosima_dependencies_2024} & POSIX OS & Desktop OS, embedded devices \cite{corsaro_zenoh_2023} \\
\bottomrule
\end{tabulary}
\end{footnotesize}
\textsuperscript{1} Outside of the AUTOSAR Consortium and the cooperation processes.
\textsuperscript{2} As a standard, the implementation and support provided depends on the individual company that completed the implementation and the tools they provide.
\textsuperscript{3} As open source software, additions are possible without membership in a committee.
\textsuperscript{4} Handled in the AUTOSAR AP by the Communication Management functional cluster.
\textsuperscript{5} An open-source implementation of \ac{SOME/IP} exists, in the form of VSOMEIP by BMW.
\end{table*}
We compare the five introduced middlewares, \ac{ROS 2}, AUTOSAR \ac{AP}, FastDDS, \ac{SOME/IP} and Zenoh in \cref{tab:middleware-comparison} from an automotive perspective.
Each column contains information about a single middleware and they are sorted according to our \commid\ and \soamid\ classification.
The middlewares were assessed based on non-technical and technical criteria, reflecting their design purposes, adoption in the community, \commpats, real-time capabilities, and other significant features.
In conclusion of the presented \commids, DDS and its implementations is the most fully featured and proven middleware.
Its large set of discovery features, highly configurable quality of service settings, and large number of security features are among its advantages.
In addition, its use in \ac{ROS 2} and now the inclusion of \ac{DDS} in the AUTOSAR \ac{AP} standard attest to the maturity and feature richness of \ac{DDS}.
In contrast, \ac{SOME/IP} offers a reduced feature set, especially in the context of security, shared memory transport, and limited quality of service configurability.
Additionally, for a time, no open-source \ac{SOME/IP} implementation was available, while multiple DDS implementations are freely accessible, well supported, and tested.
However, due to the support of the AUTOSAR Consortium and its focus specifically on the automotive domain, it may remain relevant in the domain.
The newest and least proven \commid\ in this comparison is Zenoh. In our opinion Zenoh does not present fundamentally different paradigms in comparison to existing \commids, but may present a performance improvement over \ac{DDS} implementations or \ac{SOME/IP}.
Zenoh promises to be more efficient and offer higher communication throughput than the other two \commids. However, the amount of independent literature to verify these claims is limited.
Furthermore, Zenoh supports both resource-constrained and embedded devices and various network topologies, making it more versatile than \ac{DDS}.
Consequently, Zenoh should be evaluated in future work for its performance in different automotive environments and could present a challenger to \ac{DDS}.
When comparing the two presented \soamids, the main difference is the part of the development cycle at which these \shsoamids\ are aimed.
While AUTOSAR \ac{AP} provides a large number of features for the deployment of applications to production vehicles, \ac{ROS 2} is focused on development.
This is reflected in the license model of these \shsoamids. \ac{ROS 2} targets research and development, is free and open-source, while AUTOSAR \ac{AP} is only accessible through the purchase from commercial partners, as it targets \acp{OEM} and automotive suppliers.
Consistent with this focus, AUTOSAR \ac{AP} specifies many features for resource control, configuration management, and state management, to ensure that applications can be correctly deployed in real vehicles.
\ac{ROS 2} on the other hand, offers many features such as visualizations, standard messages, already implemented packages, and a large ecosystem to support the easy and fast development of new applications.
Although provisions for starting applications are implemented, for example, no system health monitoring or complete software system configuration tools, as can be found in AUTOSAR \ac{AP}, is build into \ac{ROS 2}.
This reduces the suitability of \ac{ROS 2} for deploying applications in production vehicles.
In this context, the developments of APEX.AI should be examined, as their proprietary \ac{ROS 2} fork combines some advantages of both software systems.
\section{Research Challenges}
\label{sec:challenges}
Middleware-based software architectures in cooperation with zone-based \ac{E/E} architectures address many current challenges for \acp{AV}.
However, despite being the solution to considerable challenges, middlewares also face
open research challenges themselves.
These challenges range from real-time communication in ethernet-based \acp{IVN} to resource allocation in a \system\ where services can be arbitrarily assigned to \acp{ECU}.
The following section presents some of these challenges, organized into five categories, and research seeking to address them.
\subsection{Challenges in Real-time Communication}
Despite the disadvantages of legacy \ac{E/E} architectures, an advantage is better predictability and control over message scheduling.
However, in regular ethernet-based \acp{IVN} the same property is not guaranteed, as network congestion, packet loss, and mutual interference in communication between \acp{ECU} are possible \cite{wang_review_2024}.
To address this challenge, researchers propose the use of \ac{TSN}, an ethernet extension that introduces additional controls on communication and flow \cite{kugele_data-centric_2018}.
\citeauthor{brunner_automotive_2017} \cite{brunner_automotive_2017} proposed an initial research on this topic, which highlights the advantages of \ac{TSN} use in the automotive domain.
\citeauthor{migge_insights_2018} \cite{migge_insights_2018}, present details on the performance and configuration of \ac{TSN} in the ethernet \acp{IVN}.
However, currently no standard solution has been introduced in ROS 2 and AUTOSAR AP.
Another approach to provide more guarantees for \ac{IVN}s is the use of \ac{SDN} features.
\citeauthor{hackel_dynamic_2023} \cite{hackel_dynamic_2023} investigate the combination of \ac{TSN} and \ac{SDN} combination to assess its suitability for the automotive domain.
\citeauthor{rotermund_requirements_2020} \cite{rotermund_requirements_2020} research the performance of \ac{SDN} controllers for vehicles. To achieve heterogeneous systems, where middlewares operate on all devices in a \systems, support for embedded devices is necessary. \citeauthor{kampmann_portable_2019} \cite{kampmann_portable_2019} implement \ac{DDS} for multiple automotive platforms.
\subsection{Challenges in Real-time Execution}
The introduction of \ac{ZCU} and high performance \acp{ECU} in vehicles \ac{E/E} architecture also requires the use of full-scale operating systems, such as Linux \cite{furst_autosar_2016}.
This change of platform directly affects the execution of software and associated hard real-time requirements.
However, the use of Linux in safety-critical systems remains also an area of active research \cite{schlosser_considering_2024}.
By default, Linux does not guarantee real-time execution, and with OTA updates and updates to vehicle software, tight control over thread execution, timing, and predictability are not guaranteed \cite{blass_automatic_2021}.
Furthermore, with possible resource congestion both on the \ac{IVN} and between applications, new approaches are necessary to guarantee reliable and deterministic execution.
To address this challenge and ensure intelligent resource provisioning, \citeauthor{blass_automatic_2021} propose a latency management framework for ROS 2 \cite{blass_automatic_2021}.
A similar problem is addressed by \citeauthor{menard_achieving_2020} \cite{menard_achieving_2020} in the context of the AUTOSAR Adaptive framework.
However, in the case of ROS 2 and AUTOSAR Adaptive, no holistic implementation has been integrated into the framework and the standard yet.
It remains an active research question as to how best to achieve a deterministic distributed automotive software system.
\subsection{Challenges in Security and Safety}
Another consequence of the inclusion of Ethernet-based \acp{IVN} and high performance \acp{ECU} is the increased cyber-security attack vectors \cite{dieber_application-level_2016,vilches_sros2_2022,rumez_overview_2020}.
While in traditional \acp{ECU} the code was deeply embedded in the hardware, now the middleware, the OS, and the network present new attack vectors.
To survey these challenges, \citeauthor{rumez_overview_2020} \cite{rumez_overview_2020} provides an overview of the security implications of the application of service-orientation to automotive software architectures.
Approaches, such as \ac{IDS}, firewalls and encryption can already be found in some middleware, for instance AUTOSAR \ac{AP} offers functional clusters for these challenges \cite{autosar_ap_explanation_sw_arch} \cite{pullen_security_2023}.
\citeauthor{vilches_sros2_2022} \cite{vilches_sros2_2022} propose a security approach for \ac{ROS 2}, while \ac{ROS 2} also offers some features based on the \ac{DDS} security extension.
However, more research is required to identify whether these solutions are comprehensive and what additional approaches might be required.
\subsection{Challenges in Orchestration and Resource Management}
Applications build on middlewares are, unless they require interaction with specific sensors, actuators, or compute accelerators, such as GPUs, independent of the platform that executes them \cite{burkacky_rethinking_nodate}.
This independence also presents a resource allocation challenge for applications in the automotive software system and the specific \ac{ECU}.
An approach to manage resource use and separation of applications is containerization and virtualization \cite{berger_containerized_2017}.
Enabled by containerized applications, multiple research questions emerge such as where to deploy individual applications and how to orchestrate them.
To address this question, \citeauthor{nayak_automotive_2023} in \cite{nayak_automotive_2023} presents an overview of the requirements, challenges, and directions of containerization for automotive applications.
Similarly to the ability to control containerized applications, ROS 2 lifecycle nodes and AUTOSAR \ac{AP} applications offer lifecycle controls.
These controls enable a controller, such as an Orchestrator, Kubernetes, or AUTOSAR AP \ac{SM} to free parts of the resources used by a service by deactivating it \cite{autosar_ap_explanation_sw_arch, kampmann_optimization-based_2022}. One approach by \citeauthor{kampmann_dynamic_2019} using an orchestrator to manage an \system, is the \ac{ASOA} \cite{kampmann_dynamic_2019}.
More research is required to achieve an optimal assignment of resources and to conform the software system to the requirements of the specific situation \cite{jatzkowski_integration_2021}.
\subsection{Challenges in Machine Learning Applications}
Modern software systems and software in automated vehicles are increasingly based on artificial intelligence and \ac{ML} capabilities.
Applications built on these technologies present unique challenges to software architecture in general \cite{amershi_software_2019}, and specifically to the automotive domain, as recognized by \citeauthor{kugele_service-orientation_2017}.
\citeauthor{serban_adapting_2022} \cite{serban_adapting_2022} and \citeauthor{amershi_software_2019} \cite{amershi_software_2019} discuss in detail the unique challenges of artificial intelligence that applications pose.
The challenges include the limited interpretability of \ac{DL} models and their potential non-robustness on unseen data.
In a software system with multiple \ac{DL} components, the authors predict a potential cascade of failures as each component produces adverse results for the next.
From these requirements, they derive increased monitoring requirements and the need to increase robustness using, for instance, n-versioning.
These challenges are interwoven with the application design, but middlewares could offer solutions to these challenges.
\section{Conclusions}
\label{sec:conclusion}
This article presented a tutorial on middlewares for automated vehicles.
The tutorial introduced the fundamentals of automotive computing, gave an overview of five modern middleware, and compared them.
We classified middlewares into \commids\ and \soamids, to highlight the former's communication purpose and the multi-domain, framework nature of the latter.
Among the \commids\ we presented, \ac{DDS} remains the most fully-featured solution, while the Zenoh \commid\ represents a new challenger to \ac{DDS} promising improved performance and latency.
Among \soamids\ we concluded that the place in the development cycle determines the \shsoamid\ to choose.
\ac{ROS 2} focuses on features for development and testing, while AUTOSAR Adaptive offers comprehensive features for deployment.
Although middleware addresses many challenges in vehicles, research questions remain.
Finally, the article presented open research questions for middlewares.
The most prominent questions were related to real-time or deterministic communication and execution in automotive software systems. Increasing complexity and capability of automotive software systems also require new approaches to safety and security. Middleware-based architecture also pose resource allocation and orchestration challenges.
\section{ACKNOWLEDGMENT}
This research is accomplished within the project ”AUTOtechagil” (FKZ 01IS22088x). We acknowledge the financial support for the project by the Federal Ministry of Education and Research of Germany (BMBF).
\section{ACRONYMS}
\begin{acronym}[asdfasdvs]
\setlength{\itemsep}{0pt}
\acro{AA}{Adaptive Application}
\acro{AD}{Automated Driving}
\acro{AP}{Adaptive Platform}
\acro{API}{Application Programming Interface}
\acro{ARA}{AUTOSAR Runtime for Adaptive Applications}
\acro{ASOA}{Automotive Service Oriented Architecture}
\acro{AV}{Automated Vehicle}
\acro{CAN}{Controller Area Network}
\acro{CM}{Communication Management}
\acro{CPS}{Cyber Physical Systems}
\acro{DDS}{Data Distribution Service}
\acro{DL}{Deep Learning}
\acro{E/E}{Electrical/Electronic}
\acro{ECU}{Electronic Control Unit}
\acro{EM}{Execution Management}
\acro{FC}{Function Cluster}
\acro{FPGA}{Field Programmable Gate Array}
\acro{GPU}{Graphics Processing Unit}
\acro{HMI}{Human Machine Interface}
\acro{HPC}{High-Performance Computer}
\acro{IDS}{Intrusion Detection System}
\acro{IoT}{Internet of Things}
\acro{IPC}{Inter-Process Communication}
\acro{IVN}{In-Vehicular Network}
\acro{ML}{Machine Learning}
\acro{MQTT}{Message Queuing Telemetry Transport}
\acro{OEM}{Original Equipment Manufacturer}
\acro{OMG}{Object Management Group}
\acro{OS}{Operating System}
\acro{OTA}{Over-The-Air}
\acro{QoS}{Quality of Service}
\acro{ROS 2}{Robot Operating System 2}
\acro{S2S}{Service-to-Signal}
\acro{SDN}{Software-Defined Network}
\acro{SDV}{Software Defined Vehicles}
\acro{SM}{State Management}
\acro{SOA}{Service-oriented Architecture}
\acro{SOME/IP}{Scalable service-Oriented MiddlewarE over IP}
\acro{TCP}{Transmission Control Protocol}
\acro{TSN}{Time-sensitive Networking}
\acro{UCM}{Update and Configuration Management}
\acro{UDP}{User Datagram Protocol}
\acro{ZCU}{Zone Control Unit}
\end{acronym}
\printbibliography
\begin{IEEEbiography}
[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{Kluener.jpeg}}]{David Klüner}
David Klüner received the B.Sc. and M.Sc. degrees in computer science from RWTH Aachen University, Aachen, Germany. He is currently a Research Associate at Informatik 11–Embedded Software, RWTH Aachen University. His research interest includes automotive middlewares and machine learning in automotive software systems.
\end{IEEEbiography}
\begin{IEEEbiography}
[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{Molz.jpeg}}]{Marius Molz}
Marius Molz received the B.Sc. and M.Sc. degrees in computer science from RWTH Aachen University, Aachen, Germany. He is currently a Research Associate at Informatik 11–Embedded Software, RWTH Aachen University. His research interest includes automotive middlewares and safety in automotive software systems.
\end{IEEEbiography}
\begin{IEEEbiography}
[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{Kampmann.jpg}}]{Alexandru Kampmann} earned his master’s degree in computer science from RWTH Aachen University in 2016, followed by a Ph.D. in 2023. He is currently a research scientist at the Embedded Software Chair at RWTH Aachen University. His primary research interests lies in the area of automotive software engineering, with a focus on middleware and engineering tools.
\end{IEEEbiography}
\begin{IEEEbiography}
[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{Kowalewski.png}}]{Stefan Kowalewski}
Stefan Kowalewski is a full professor of embedded software at RWTH Aachen University. He earned his Dipl.-Ing. degree in Electrical Engineering from the University of Karlsruhe and holds both a Dr.-Ing. and a habilitation degree in Control and Safety Engineering from the University of Dortmund. Before joining RWTH Aachen, he served as a group manager in the Corporate Research and Advanced Engineering division of Robert Bosch GmbH in Frankfurt, Germany, where he specialized in automotive software engineering. His primary research
interests include the design and analysis of software-intensive embedded systems, with a focus on the application of formal methods and safety-critical systems.
\end{IEEEbiography}
\begin{IEEEbiography}
[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{Alrifaee.jpg}}]{Bassam Alrifaee}
Dr. Bassam Alrifaee is a Professor in the Department of Aerospace Engineering and Director of the Control of Autonomous Systems Lab at the University of the Bundeswehr Munich. Prior to this, he served as a Senior Researcher and Lecturer and was the founding director of the Cyber-Physical Mobility (CPM) group and CPM Lab at RWTH Aachen University, Germany (2017–2024). He held a Visiting Scholar position at the University of Delaware, USA, in 2023. Dr. Alrifaee received his Ph.D. from RWTH in 2017. His research focuses on distributed predictive control, service-oriented architectures for control systems, and their applications in connected and automated vehicles. Dr. Alrifaee has secured grants from various institutions and received awards for his advisory and editorial contributions. He holds Senior Member status at IEEE.
\end{IEEEbiography}
\vfill\null
\end{document}
% $ biblatex auxiliary file $
% $ biblatex bbl format version 3.2 $
% Do not modify the above lines!
%
% This is an auxiliary file used by the 'biblatex' package.
% This file may safely be deleted. It will be recreated by
% biber as required.
%
\begingroup
\makeatletter
\@ifundefined{ver@biblatex.sty}
{\@latex@error
{Missing 'biblatex' package}
{The bibliography requires the 'biblatex' package.}
\aftergroup\endinput}
{}
\endgroup
\refsection{0}
\datalist[entry]{nty/global//global/global}
\entry{aaron_aboagye_facing_2017}{misc}{}
\name{author}{6}{}{%
{{hash=dedaf7af1e23bfd57f9a4772ae1c9b9b}{%
family={{Aaron Aboagye}},
familyi={A\bibinitperiod}}}%
{{hash=7cde65d92baa8fbd2c6e8c1ff7346a3c}{%
family={{Aamer Baig}},
familyi={A\bibinitperiod}}}%
{{hash=e4e508286bac09a428ec3195ac053480}{%
family={{Asutosh Padhi}},
familyi={A\bibinitperiod}}}%
{{hash=7e1a13f22ba8cfacc3ce77374c7f51c7}{%
family={{Russel Hensley}},
familyi={R\bibinitperiod}}}%
{{hash=a7016370da4269a9797f120abe16a80b}{%
family={{Richard Kelly}},
familyi={R\bibinitperiod}}}%
{{hash=7199644e2d95935a26fcc5740456a337}{%
family={{Danish Shafi}},
familyi={D\bibinitperiod}}}%
}
\strng{namehash}{cb7eb381dfdaa35116b872bb549fd0d9}
\strng{fullhash}{89d633d2a32949fcafff5f4f61831071}
\strng{bibnamehash}{89d633d2a32949fcafff5f4f61831071}
\strng{authorbibnamehash}{89d633d2a32949fcafff5f4f61831071}
\strng{authornamehash}{cb7eb381dfdaa35116b872bb549fd0d9}
\strng{authorfullhash}{89d633d2a32949fcafff5f4f61831071}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Facing digital disruption in mobility as a traditional auto player}
\field{month}{12}
\field{title}{Facing digital disruption in mobility as a traditional auto player {|} {McKinsey}}
\field{urlday}{25}
\field{urlmonth}{9}
\field{urlyear}{2024}
\field{year}{2017}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/facing-digital-disruption-in-mobility-as-a-traditional-auto-player
\endverb
\verb{url}
\verb https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/facing-digital-disruption-in-mobility-as-a-traditional-auto-player
\endverb
\endentry
\entry{amershi_software_2019}{inproceedings}{}
\name{author}{9}{}{%
{{hash=7098a2847ed504c65ef57236d3a25cc9}{%
family={Amershi},
familyi={A\bibinitperiod},
given={Saleema},
giveni={S\bibinitperiod}}}%
{{hash=2694e1d90cf02deb1abecbc6e1f2f80a}{%
family={Begel},
familyi={B\bibinitperiod},
given={Andrew},
giveni={A\bibinitperiod}}}%
{{hash=7b11a8af9b466161096907a7d8c2476d}{%
family={Bird},
familyi={B\bibinitperiod},
given={Christian},
giveni={C\bibinitperiod}}}%
{{hash=af783c30843efac5e68e235d1a427639}{%
family={DeLine},
familyi={D\bibinitperiod},
given={Robert},
giveni={R\bibinitperiod}}}%
{{hash=10d249a153a0feb15e15bf47eebf662f}{%
family={Gall},
familyi={G\bibinitperiod},
given={Harald},
giveni={H\bibinitperiod}}}%
{{hash=8871bf8ac2d0e00b8d71c1929e1ef04c}{%
family={Kamar},
familyi={K\bibinitperiod},
given={Ece},
giveni={E\bibinitperiod}}}%
{{hash=6ba3a35650ec296ab02f441c92f91724}{%
family={Nagappan},
familyi={N\bibinitperiod},
given={Nachiappan},
giveni={N\bibinitperiod}}}%
{{hash=d941a402863ff98390cb0dd78ee4ac3e}{%
family={Nushi},
familyi={N\bibinitperiod},
given={Besmira},
giveni={B\bibinitperiod}}}%
{{hash=9bfbc841af43915c12169734f59a4e7b}{%
family={Zimmermann},
familyi={Z\bibinitperiod},
given={Thomas},
giveni={T\bibinitperiod}}}%
}
\strng{namehash}{39cd4218b09c7c1d3953f7772678443d}
\strng{fullhash}{fffacdda1972a604476a177ac1c53c12}
\strng{bibnamehash}{85f4e3d48a96ecb9fb9e818042ab53d3}
\strng{authorbibnamehash}{85f4e3d48a96ecb9fb9e818042ab53d3}
\strng{authornamehash}{39cd4218b09c7c1d3953f7772678443d}
\strng{authorfullhash}{fffacdda1972a604476a177ac1c53c12}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Recent advances in machine learning have stimulated widespread interest within the Information Technology sector on integrating AI capabilities into software and services. This goal has forced organizations to evolve their development processes. We report on a study that we conducted on observing software teams at Microsoft as they develop AI-based applications. We consider a nine-stage workflow process informed by prior experiences developing AI applications (e.g., search and NLP) and data science tools (e.g. application diagnostics and bug reporting). We found that various Microsoft teams have united this workflow into preexisting, well-evolved, Agile-like software engineering processes, providing insights about several essential engineering challenges that organizations may face in creating large-scale AI solutions for the marketplace. We collected some best practices from Microsoft teams to address these challenges. In addition, we have identified three aspects of the AI domain that make it fundamentally different from prior software application domains: 1) discovering, managing, and versioning the data needed for machine learning applications is much more complex and difficult than other types of software engineering, 2) model customization and model reuse require very different skills than are typically found in software teams, and 3) AI components are more difficult to handle as distinct modules than traditional software components — models may be “entangled” in complex ways and experience non-monotonic error behavior. We believe that the lessons learned by Microsoft teams will be valuable to other organizations.}
\field{booktitle}{2019 {IEEE}/{ACM} 41st {International} {Conference} on {Software} {Engineering}: {Software} {Engineering} in {Practice} ({ICSE}-{SEIP})}
\field{month}{5}
\field{title}{Software {Engineering} for {Machine} {Learning}: {A} {Case} {Study}}
\field{year}{2019}
\field{pages}{291\bibrangedash 300}
\range{pages}{10}
\endentry
\entry{autosar_explanationPlatformDesign_2024}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{1}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{month}{11}
\field{shorttitle}{Explanation of {Adaptive} {Platform} {Design} {AUTOSAR} {AP} {R23}-11}
\field{title}{Explanation of {Adaptive} {Platform} {Design}}
\field{type}{Part of {AUTOSAR} {Standard} {Adaptive} {Platform}}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_PlatformDesign.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_PlatformDesign.pdf
\endverb
\endentry
\entry{autosar_ap_explanation_sw_arch}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{2}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{month}{11}
\field{title}{Explanation of {Adaptive} {Platform} {Software} {Architecture}}
\field{type}{Part of {AUTOSAR} {Standard} {Adaptive} {Platform}}
\field{urlday}{14}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_SWArchitecture.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_SWArchitecture.pdf
\endverb
\endentry
\entry{autosar_consortium_explanation_2023}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{3}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{month}{11}
\field{shorttitle}{Explanation of ara::com {API} {AUTOSAR} {AP} {R23}-11}
\field{title}{Explanation of ara::com {API}}
\field{type}{Part of {AUTOSAR} {Standard} {Adaptive} {Platform}}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_ARAComAPI.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_EXP_ARAComAPI.pdf
\endverb
\endentry
\entry{autosar_someip_2024}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{4}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{month}{11}
\field{shorttitle}{{SOME}/{IP} {Protocol} {Specification} {AUTOSAR} {FO} {R23}-11}
\field{title}{{SOME}/{IP} {Protocol} {Specification}}
\field{type}{{AUTOSAR} {Standard} {Foundation}}
\field{urlday}{19}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_PRS_SOMEIPProtocol.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_PRS_SOMEIPProtocol.pdf
\endverb
\endentry
\entry{autosar_consortium_ip_2023}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{5}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{month}{11}
\field{shorttitle}{{SOME}/{IP} {Service} {Discovery} {Protocol} {Specification} {AUTOSAR} {FO} {R23}-11}
\field{title}{{SOME}/{IP} {Service} {Discovery} {Protocol} {Specification}}
\field{type}{{AUTOSAR} {Standard} {Foundation}}
\field{urlday}{19}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_PRS_SOMEIPServiceDiscoveryProtocol.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/FO/AUTOSAR_FO_PRS_SOMEIPServiceDiscoveryProtocol.pdf
\endverb
\endentry
\entry{autosar_communicationManagement_2024}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{6}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{month}{11}
\field{shorttitle}{Specification of {Communication} {Management} {AUTOSAR} {AP} {R23}-11}
\field{title}{Specification of {Communication} {Management}}
\field{type}{{AUTOSAR} {Standard} {Adaptive} {Platform}}
\field{urlday}{25}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_SWS_CommunicationManagement.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_SWS_CommunicationManagement.pdf
\endverb
\endentry
\entry{autosar_executionManagement_2024}{misc}{}
\name{author}{1}{}{%
{{hash=2cb8652c6b31e10827b1c3e62273c88b}{%
family={{AUTOSAR Consortium}},
familyi={A\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{fullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{bibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorbibnamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authornamehash}{2cb8652c6b31e10827b1c3e62273c88b}
\strng{authorfullhash}{2cb8652c6b31e10827b1c3e62273c88b}
\field{extraname}{7}
\field{sortinit}{A}
\field{sortinithash}{2f401846e2029bad6b3ecc16d50031e2}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{month}{11}
\field{title}{Specification of {Execution} {Management}}
\field{type}{{AUTOSAR} {Standard} {Adaptive} {Platform}}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2023}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_SWS_ExecutionManagement.pdf
\endverb
\verb{url}
\verb https://www.autosar.org/fileadmin/standards/R23-11/AP/AUTOSAR_AP_SWS_ExecutionManagement.pdf
\endverb
\endentry
\entry{bass_software_2012}{book}{}
\name{author}{3}{}{%
{{hash=97196c0aaced1368c3042b9299a9b34b}{%
family={Bass},
familyi={B\bibinitperiod},
given={Len},
giveni={L\bibinitperiod}}}%
{{hash=806866eee4e5b55ba7360bfe43f4f397}{%
family={Clements},
familyi={C\bibinitperiod},
given={Paul},
giveni={P\bibinitperiod}}}%
{{hash=4a2e06c3fa40bc2221536e74ab90b7ec}{%
family={Kazman},
familyi={K\bibinitperiod},
given={Rick},
giveni={R\bibinitperiod}}}%
}
\list{publisher}{1}{%
{Addison-Wesley Professional}%
}
\strng{namehash}{2626ec8f22fc3baa10dbc85a9825ee79}
\strng{fullhash}{f3c472223052fa8f8a1c396381e08cd3}
\strng{bibnamehash}{f3c472223052fa8f8a1c396381e08cd3}
\strng{authorbibnamehash}{f3c472223052fa8f8a1c396381e08cd3}
\strng{authornamehash}{2626ec8f22fc3baa10dbc85a9825ee79}
\strng{authorfullhash}{f3c472223052fa8f8a1c396381e08cd3}
\field{extraname}{1}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The award-winning and highly influential Software Architecture in Practice, Third Edition, has been substantially revised to reflect the latest developments in the field. In a real-world setting, the book once again introduces the concepts and best practices of software architecturehow a software system is structured and how that systems elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a reusable asset that can be applied to subsequent systems, and is crucial to a software organizations business strategy. The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organizations business profile, and the architects professional practices. The authors also have greatly expanded their treatment of quality attributes, which remain central to their architecture philosophywith an entire chapter devoted to each attributeand broadened their treatment of architectural patterns. If you design, develop, or manage large software systems (or plan to do so), you will find this book to be a valuable resource for getting up to speed on the state of the art. Totally new material covers Contexts of software architecture: technical, project, business, and professional Architecture competence: what this means both for individuals and organizations The origins of business goals and how this affects architecture Architecturally significant requirements, and how to determine them Architecture in the life cycle, including generate-and-test as a design philosophy; architecture conformance during implementation; architecture and testing; and architecture and agile development Architecture and current technologies, such as the cloud, social networks, and end-user devices}
\field{edition}{3rd}
\field{isbn}{978-0-321-81573-6}
\field{month}{9}
\field{title}{Software {Architecture} in {Practice}}
\field{year}{2012}
\endentry
\entry{bass_software_2003}{book}{}
\name{author}{3}{}{%
{{hash=97196c0aaced1368c3042b9299a9b34b}{%
family={Bass},
familyi={B\bibinitperiod},
given={Len},
giveni={L\bibinitperiod}}}%
{{hash=806866eee4e5b55ba7360bfe43f4f397}{%
family={Clements},
familyi={C\bibinitperiod},
given={Paul},
giveni={P\bibinitperiod}}}%
{{hash=4a2e06c3fa40bc2221536e74ab90b7ec}{%
family={Kazman},
familyi={K\bibinitperiod},
given={Rick},
giveni={R\bibinitperiod}}}%
}
\strng{namehash}{2626ec8f22fc3baa10dbc85a9825ee79}
\strng{fullhash}{f3c472223052fa8f8a1c396381e08cd3}
\strng{bibnamehash}{f3c472223052fa8f8a1c396381e08cd3}
\strng{authorbibnamehash}{f3c472223052fa8f8a1c396381e08cd3}
\strng{authornamehash}{2626ec8f22fc3baa10dbc85a9825ee79}
\strng{authorfullhash}{f3c472223052fa8f8a1c396381e08cd3}
\field{extraname}{2}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{This book provides an easily accessible overview of software architecture. Anyone requiring a comprehensive overview of the software architecture field will benefit from this book.}
\field{month}{4}
\field{title}{Software {Architecture} in {Practice}, 2nd {Edition}}
\field{year}{2003}
\endentry
\entry{becker_safety-certified_2021}{inproceedings}{}
\name{author}{3}{}{%
{{hash=71032b96293644b22a224465ee4a4de5}{%
family={Becker},
familyi={B\bibinitperiod},
given={Jan},
giveni={J\bibinitperiod}}}%
{{hash=250a0802b4fc39e3bac42177f11acf7b}{%
family={Sagar},
familyi={S\bibinitperiod},
given={Mehul},
giveni={M\bibinitperiod}}}%
{{hash=781d441283b5306a3786cabb41cf71bd}{%
family={Pangercic},
familyi={P\bibinitperiod},
given={Dejan},
giveni={D\bibinitperiod}}}%
}
\name{editor}{1}{}{%
{{hash=802ba9269c0073c577b138e7404347cd}{%
family={Bertram},
familyi={B\bibinitperiod},
given={Torsten},
giveni={T\bibinitperiod}}}%
}
\list{language}{1}{%
{de}%
}
\list{location}{1}{%
{Wiesbaden}%
}
\list{publisher}{1}{%
{Springer Fachmedien}%
}
\strng{namehash}{a5b1df2a117d1352df6a7f8df1b80d98}
\strng{fullhash}{5b6a0eb6c2982155e21b65d5467026cf}
\strng{bibnamehash}{5b6a0eb6c2982155e21b65d5467026cf}
\strng{authorbibnamehash}{5b6a0eb6c2982155e21b65d5467026cf}
\strng{authornamehash}{a5b1df2a117d1352df6a7f8df1b80d98}
\strng{authorfullhash}{5b6a0eb6c2982155e21b65d5467026cf}
\strng{editorbibnamehash}{802ba9269c0073c577b138e7404347cd}
\strng{editornamehash}{802ba9269c0073c577b138e7404347cd}
\strng{editorfullhash}{802ba9269c0073c577b138e7404347cd}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Autonomous driving, connected vehicles, e-mobility, shared mobility – all mobility disruptors rely on software but lack a unified software platform is preventing cross-domain software development. In the meantime, the vehicle compute and network architecture are moving to centralized high performance computers, but the software implementation is lagging behind the hardware architecture. We are now introducing Apex.OS, the first mobility software platform that is truly integrated end to end. A primary vehicle operating system, robust and flexible enough to cover major systems throughout the vehicle and the cloud, enables user-focused development, just like iOS and Android SDK do so for embedded devices. This paper describes our approach to an automotive SDK capable of covering all automotive software domains and certified to ISO 26262 ASIL D.}
\field{booktitle}{Automatisiertes {Fahren} 2021}
\field{isbn}{978-3-658-34754-3}
\field{title}{A {Safety}-{Certified} {Vehicle} {OS} to {Enable} {Software}-{Defined} {Vehicles}}
\field{year}{2021}
\field{pages}{51\bibrangedash 67}
\range{pages}{17}
\verb{doi}
\verb 10.1007/978-3-658-34754-3_5
\endverb
\keyw{ASIL D,Apex.OS,ISO 26262,ROS,SDK,Vehicle Operating System,automotive,certification,functional safety,open-source}
\endentry
\entry{bello_recent_2019}{article}{}
\name{author}{4}{}{%
{{hash=558304b9bd9e1bb258125fd36dcc63d5}{%
family={Bello},
familyi={B\bibinitperiod},
given={Lucia\bibnamedelima Lo},
giveni={L\bibinitperiod\bibinitdelim L\bibinitperiod}}}%
{{hash=f8e266bd62d4d2ecee24b75ef5135716}{%
family={Mariani},
familyi={M\bibinitperiod},
given={Riccardo},
giveni={R\bibinitperiod}}}%
{{hash=344c0231b6cdd562f822bba32bc6a5bd}{%
family={Mubeen},
familyi={M\bibinitperiod},
given={Saad},
giveni={S\bibinitperiod}}}%
{{hash=22c41a4f542b395aaa6413d3bf75d2b9}{%
family={Saponara},
familyi={S\bibinitperiod},
given={Sergio},
giveni={S\bibinitperiod}}}%
}
\strng{namehash}{3ca237f7d36d5367f80fd081cc50b490}
\strng{fullhash}{7e30abdf7e5ba2abeaa86a9a68c9658c}
\strng{bibnamehash}{7e30abdf7e5ba2abeaa86a9a68c9658c}
\strng{authorbibnamehash}{7e30abdf7e5ba2abeaa86a9a68c9658c}
\strng{authornamehash}{3ca237f7d36d5367f80fd081cc50b490}
\strng{authorfullhash}{7e30abdf7e5ba2abeaa86a9a68c9658c}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Modern cars consist of a number of complex embedded and networked systems with steadily increasing requirements in terms of processing and communication resources. Novel automotive applications, such as automated driving, rise new needs and novel design challenges that cover a broad range of hardware/software engineering aspects. In this context, this paper provides an overview of the current technological challenges in on-board and networked automotive systems. This paper encompasses both the state-of-the-art design strategies and the upcoming hardware/software solutions for the next generation of automotive systems, with a special focus on embedded and networked technologies. In particular, this paper surveys current solutions and future trends on models and languages for automotive software development, on-board computational platforms, in-car network architectures and communication protocols, and novel design strategies for cybersecurity and functional safety.}
\field{issn}{1941-0050}
\field{journaltitle}{IEEE Transactions on Industrial Informatics}
\field{month}{2}
\field{note}{Conference Name: IEEE Transactions on Industrial Informatics}
\field{number}{2}
\field{title}{Recent {Advances} and {Trends} in {On}-{Board} {Embedded} and {Networked} {Automotive} {Systems}}
\field{volume}{15}
\field{year}{2019}
\field{pages}{1038\bibrangedash 1051}
\range{pages}{14}
\verb{doi}
\verb 10.1109/TII.2018.2879544
\endverb
\keyw{Automobiles,Automotive Ethernet,Automotive engineering,Computer architecture,Safety,Software,Standards,automotive software (SW),embedded systems,functional safety,on-board security,real-time (RT) networks,time-sensitive networking}
\endentry
\entry{belsare_micro-ros_2023}{incollection}{}
\name{author}{14}{}{%
{{hash=e2606cf7d15d39d0aa9eb72c107873bb}{%
family={Belsare},
familyi={B\bibinitperiod},
given={Kaiwalya},
giveni={K\bibinitperiod}}}%
{{hash=d1ae9060eceb9a2e91c1c4d1e0dda1c2}{%
family={Rodriguez},
familyi={R\bibinitperiod},
given={Antonio\bibnamedelima Cuadros},
giveni={A\bibinitperiod\bibinitdelim C\bibinitperiod}}}%
{{hash=7fb51f366c38fd2ad2c1c5df18b8e7ea}{%
family={Sánchez},
familyi={S\bibinitperiod},
given={Pablo\bibnamedelima Garrido},
giveni={P\bibinitperiod\bibinitdelim G\bibinitperiod}}}%
{{hash=bea05b01538cbce4a342b01f611f5a41}{%
family={Hierro},
familyi={H\bibinitperiod},
given={Juanjo},
giveni={J\bibinitperiod}}}%
{{hash=ecb29e8d2dd3a536682163b2ccdce6b4}{%
family={Kołcon},
familyi={K\bibinitperiod},
given={Tomasz},
giveni={T\bibinitperiod}}}%
{{hash=58a9a1cbfa2e11afc37418a4ef2109cc}{%
family={Lange},
familyi={L\bibinitperiod},
given={Ralph},
giveni={R\bibinitperiod}}}%
{{hash=dcc41435f3f456ea017efa87fc66cdba}{%
family={Lütkebohle},
familyi={L\bibinitperiod},
given={Ingo},
giveni={I\bibinitperiod}}}%
{{hash=02897e726bbfe7bbbab0b27b2459e9c7}{%
family={Malki},
familyi={M\bibinitperiod},
given={Alexandre},
giveni={A\bibinitperiod}}}%
{{hash=404eb5907dec820988f504a1e149dc67}{%
family={Losa},
familyi={L\bibinitperiod},
given={Jaime\bibnamedelima Martin},
giveni={J\bibinitperiod\bibinitdelim M\bibinitperiod}}}%
{{hash=cb420b04b5d5a53de278e6d8d588aca0}{%
family={Melendez},
familyi={M\bibinitperiod},
given={Francisco},
giveni={F\bibinitperiod}}}%
{{hash=70f204a5618a20759dd77bad3fec20ef}{%
family={Rodriguez},
familyi={R\bibinitperiod},
given={Maria\bibnamedelima Merlan},
giveni={M\bibinitperiod\bibinitdelim M\bibinitperiod}}}%
{{hash=e2e772d030580f96412b95e48a192f4c}{%
family={Nordmann},
familyi={N\bibinitperiod},
given={Arne},
giveni={A\bibinitperiod}}}%
{{hash=d0283c98bae23f290d03947fb405c1db}{%
family={Staschulat},
familyi={S\bibinitperiod},
given={Jan},
giveni={J\bibinitperiod}}}%
{{hash=f40de8ab34da9ac86cc73e5ef007def4}{%
family={Mendel},
familyi={M\bibinitperiod},
given={Julian},
giveni={J\bibinitperiod},
prefix={von},
prefixi={v\bibinitperiod}}}%
}
\name{editor}{1}{}{%
{{hash=bfa7caea7320966a6a6bd9ef6a4bd029}{%
family={Koubaa},
familyi={K\bibinitperiod},
given={Anis},
giveni={A\bibinitperiod}}}%
}
\strng{namehash}{d27c20a4a09fa6acfaab825ccb122387}
\strng{fullhash}{9476fbbe47b0a4a1c086537ff885eb3f}
\strng{bibnamehash}{70b04633ddd7d9edbf9f07926b939528}
\strng{authorbibnamehash}{70b04633ddd7d9edbf9f07926b939528}
\strng{authornamehash}{d27c20a4a09fa6acfaab825ccb122387}
\strng{authorfullhash}{9476fbbe47b0a4a1c086537ff885eb3f}
\strng{editorbibnamehash}{bfa7caea7320966a6a6bd9ef6a4bd029}
\strng{editornamehash}{bfa7caea7320966a6a6bd9ef6a4bd029}
\strng{editorfullhash}{bfa7caea7320966a6a6bd9ef6a4bd029}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The micro-ROS stack (micro.ros.org) integrates microcontrollers seamlessly with standard ROS 2 and brings all major ROS concepts such as nodes, publisher, subscriptions, parameters, and lifecycle onto deeply embedded systems. This enables accessing all software using the same ROS tools and APIs, regardless of the underlying computing hardware and operating system. Micro-ROS supports a broad spectrum of microcontroller families and the main open-source real-time operating systems like FreeRTOS, Zepyhr, or NuttX. It supports various microcontroller- or RTOS-specific build systems and provides ROS-CLI-based build tooling. Micro-ROS is an open-source project that has been under development at github.com/micro-ROSsince 2018. It was initiated by the EU-funded innovation activity OFERA. During the the last two years, micro-ROS has been adopted by a relevant group of professional users inside the ROS community. In this chapter, we give a technical introduction to the micro-ROS stack including APIs and architecture, as well as the corresponding middleware Micro XRCE-DDS. Furthermore, tutorials for a simple application with an ESP32 microcontroller are provided together with a report on three use-cases from industrial and research applications.}
\field{booktitle}{Robot {Operating} {System} ({ROS}): {The} {Complete} {Reference} ({Volume} 7)}
\field{series}{Studies in {Computational} {Intelligence}}
\field{title}{Micro-{ROS}}
\field{year}{2023}
\field{pages}{3\bibrangedash 55}
\range{pages}{53}
\verb{doi}
\verb 10.1007/978-3-031-09062-2_2
\endverb
\keyw{Embedded,Micro-ROS,Microcontroller,ROS 2,Robotics}
\endentry
\entry{benckendorff_comparing_2019}{inproceedings}{}
\name{author}{4}{}{%
{{hash=6d54cad93b274f95c6fdb4961080438b}{%
family={Benckendorff},
familyi={B\bibinitperiod},
given={Tenny},
giveni={T\bibinitperiod}}}%
{{hash=cc01c1ac0e9363d291b18700a586a8c9}{%
family={Lapp},
familyi={L\bibinitperiod},
given={Andreas},
giveni={A\bibinitperiod}}}%
{{hash=40d564caab476a06c0c8302147547096}{%
family={Oexner},
familyi={O\bibinitperiod},
given={Thomas},
giveni={T\bibinitperiod}}}%
{{hash=4d349af8428ea70a7dedc43ebfa7dd25}{%
family={Thiel},
familyi={T\bibinitperiod},
given={Thomas},
giveni={T\bibinitperiod}}}%
}
\name{editor}{4}{}{%
{{hash=1564e21ff8cb76b7f5e886c9d6403768}{%
family={Bargende},
familyi={B\bibinitperiod},
given={Michael},
giveni={M\bibinitperiod}}}%
{{hash=24b30b0bb3a37c47bb8b7875eed49ca9}{%
family={Reuss},
familyi={R\bibinitperiod},
given={Hans-Christian},
giveni={H\bibinithyphendelim C\bibinitperiod}}}%
{{hash=8fd3a8379cbda9c60f92e446330e16fb}{%
family={Wagner},
familyi={W\bibinitperiod},
given={Andreas},
giveni={A\bibinitperiod}}}%
{{hash=bb1dd31469997a58b753e9cdddbbdc2b}{%
family={Wiedemann},
familyi={W\bibinitperiod},
given={Jochen},
giveni={J\bibinitperiod}}}%
}
\list{language}{1}{%
{de}%
}
\strng{namehash}{d008f6ee4e04b0a7a1b4a1fb9b81c8af}
\strng{fullhash}{e0b85921482edf832c4812ce66f5a97e}
\strng{bibnamehash}{e0b85921482edf832c4812ce66f5a97e}
\strng{authorbibnamehash}{e0b85921482edf832c4812ce66f5a97e}
\strng{authornamehash}{d008f6ee4e04b0a7a1b4a1fb9b81c8af}
\strng{authorfullhash}{e0b85921482edf832c4812ce66f5a97e}
\strng{editorbibnamehash}{0cce71bccc4132fe24cf808369c099de}
\strng{editornamehash}{ec0e21cf18e704598c2b514bb90fe03d}
\strng{editorfullhash}{0cce71bccc4132fe24cf808369c099de}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The major trends of the automotive industry, such as automated driving, connectivity and electrification require the introduction of new technologies and even technology leaps. They are as well influencing vehicle E/E-architectures as a whole. Vehicles become part of cyber-physical systems and centralization is considered as one of the measures to enable innovation and to reduce complexity. High performance vehicle computers are increasingly introduced as central cornerstones of future E/E architectures.}
\field{booktitle}{19. {Internationales} {Stuttgarter} {Symposium}}
\field{isbn}{978-3-658-25939-6}
\field{title}{Comparing current and future {E}/{EArchitecture} trends of commercial vehicles and passenger cars}
\field{year}{2019}
\field{pages}{1190\bibrangedash 1200}
\range{pages}{11}
\verb{doi}
\verb 10.1007/978-3-658-25939-6_95
\endverb
\endentry
\entry{berger_containerized_2017}{inproceedings}{}
\name{author}{3}{}{%
{{hash=989e9c75cedce190a8efdde3ba9764ec}{%
family={Berger},
familyi={B\bibinitperiod},
given={Christian},
giveni={C\bibinitperiod}}}%
{{hash=714e9d075fb725acb0e61778e9c2403e}{%
family={Nguyen},
familyi={N\bibinitperiod},
given={Björnborg},
giveni={B\bibinitperiod}}}%
{{hash=14e814351848ea42c9c7c61e63e51629}{%
family={Benderius},
familyi={B\bibinitperiod},
given={Ola},
giveni={O\bibinitperiod}}}%
}
\strng{namehash}{7e8450f1ed104e07cf3121b9929c9193}
\strng{fullhash}{8a6b6ad33c949ecd7ff52989e0d21ea6}
\strng{bibnamehash}{8a6b6ad33c949ecd7ff52989e0d21ea6}
\strng{authorbibnamehash}{8a6b6ad33c949ecd7ff52989e0d21ea6}
\strng{authornamehash}{7e8450f1ed104e07cf3121b9929c9193}
\strng{authorfullhash}{8a6b6ad33c949ecd7ff52989e0d21ea6}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{In this paper, experiences and best practices from using containerized software microservices for self-driving vehicles are shared. We applied the containerized software paradigm successfully to both the software development and deployment to turn our software architecture in the vehicles following the idea of microservices. Key enabling elements include onboarding of new developers, both researchers and students, traceable development and packaging, convenient and bare-bone deployment, and traceably archiving binary distributions of our quickly evolving software environment. In this paper, we share our experience from working one year with containerized development and deployment for our self-driving vehicles highlighting our reflections and application-specific shortcomings, our approach uses several components from the widely used Docker ecosystem, but the discussion in this paper generalizes these concepts. We conclude that the growingly complex automotive software systems in combination with their computational platforms should be rather understood as data centers on wheels to design both, (a) the software development and deployment processes, and (b) the software architecture in such a way to enable continuous integration, continuous deployment, and continuous experimentation.}
\field{booktitle}{2017 {IEEE} {International} {Conference} on {Software} {Architecture} {Workshops} ({ICSAW})}
\field{month}{4}
\field{title}{Containerized {Development} and {Microservices} for {Self}-{Driving} {Vehicles}: {Experiences} \& {Best} {Practices}}
\field{year}{2017}
\field{pages}{7\bibrangedash 12}
\range{pages}{6}
\endentry
\entry{blass_automatic_2021}{inproceedings}{}
\name{author}{5}{}{%
{{hash=3b373dfa84db452f975f96b4d0bf75d1}{%
family={Blass},
familyi={B\bibinitperiod},
given={Tobias},
giveni={T\bibinitperiod}}}%
{{hash=c0b0c07f16022d5d18cf41fb0045308f}{%
family={Hamann},
familyi={H\bibinitperiod},
given={Arne},
giveni={A\bibinitperiod}}}%
{{hash=58a9a1cbfa2e11afc37418a4ef2109cc}{%
family={Lange},
familyi={L\bibinitperiod},
given={Ralph},
giveni={R\bibinitperiod}}}%
{{hash=d5193577bc88aeadb5f2c4020ff90de1}{%
family={Ziegenbein},
familyi={Z\bibinitperiod},
given={Dirk},
giveni={D\bibinitperiod}}}%
{{hash=060694732ee8ef34cff10a4ca99c2dea}{%
family={Brandenburg},
familyi={B\bibinitperiod},
given={Bjorn\bibnamedelima B.},
giveni={B\bibinitperiod\bibinitdelim B\bibinitperiod}}}%
}
\list{location}{1}{%
{Nashville, TN, USA}%
}
\list{publisher}{1}{%
{IEEE}%
}
\strng{namehash}{691ab55ce61b216dcaaf181494a5bb5f}
\strng{fullhash}{bab138cb0c22daca39c08d11cdea1200}
\strng{bibnamehash}{bab138cb0c22daca39c08d11cdea1200}
\strng{authorbibnamehash}{bab138cb0c22daca39c08d11cdea1200}
\strng{authornamehash}{691ab55ce61b216dcaaf181494a5bb5f}
\strng{authorfullhash}{bab138cb0c22daca39c08d11cdea1200}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{2021 {IEEE} 27th {Real}-{Time} and {Embedded} {Technology} and {Applications} {Symposium} ({RTAS})}
\field{month}{5}
\field{title}{Automatic {Latency} {Management} for {ROS} 2: {Benefits}, {Challenges}, and {Open} {Problems}}
\field{year}{2021}
\field{pages}{264\bibrangedash 277}
\range{pages}{14}
\endentry
\entry{brunner_automotive_2017}{inproceedings}{}
\name{author}{4}{}{%
{{hash=5efcc35c1383bcfdb7ec81337347a636}{%
family={Brunner},
familyi={B\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
{{hash=1ec9cc7e0ed7600300547b0ba776d9d4}{%
family={Roder},
familyi={R\bibinitperiod},
given={Jurgen},
giveni={J\bibinitperiod}}}%
{{hash=8d4e9750aac034f8ec014f02a3cbea05}{%
family={Kucera},
familyi={K\bibinitperiod},
given={Markus},
giveni={M\bibinitperiod}}}%
{{hash=e0773e5e69feb6924e6cbfd4d4339f59}{%
family={Waas},
familyi={W\bibinitperiod},
given={Thomas},
giveni={T\bibinitperiod}}}%
}
\strng{namehash}{cd81fbd77f4f265c7b179e523628a019}
\strng{fullhash}{60592809ada6256a748770a9502959f2}
\strng{bibnamehash}{60592809ada6256a748770a9502959f2}
\strng{authorbibnamehash}{60592809ada6256a748770a9502959f2}
\strng{authornamehash}{cd81fbd77f4f265c7b179e523628a019}
\strng{authorfullhash}{60592809ada6256a748770a9502959f2}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{A huge upheaval emerges from the transition to autonomous vehicles in the domain of road vehicles, ongoing with a change in the vehicle architecture. Many sensors and Electronic Control Units are added to the current vehicle architecture and further safety requirements like reliability become even more necessary. In this paper we present a potential evolution of the Electrical/Electronic-Architecture, including a Zone Architecture, to enable future functionality. We reveal the impact on the communication network concerning these architectures and present a potential communication technology to facilitate such architectures.}
\field{booktitle}{2017 13th {Workshop} on {Intelligent} {Solutions} in {Embedded} {Systems} ({WISES})}
\field{month}{6}
\field{title}{Automotive {E}/{E}-architecture enhancements by usage of ethernet {TSN}}
\field{year}{2017}
\field{pages}{9\bibrangedash 13}
\range{pages}{5}
\endentry
\entry{burkacky_rethinking_nodate}{misc}{}
\name{author}{4}{}{%
{{hash=d394f717ab2cebc25024643cd8d75ba7}{%
family={Burkacky},
familyi={B\bibinitperiod},
given={Ondrej},
giveni={O\bibinitperiod}}}%
{{hash=d079177046aed841d7aede92c6d8efae}{%
family={Deichmann},
familyi={D\bibinitperiod},
given={Johannes},
giveni={J\bibinitperiod}}}%
{{hash=07ba9aa587bcd7dc552b480cdfe8ac42}{%
family={Doll},
familyi={D\bibinitperiod},
given={Georg},
giveni={G\bibinitperiod}}}%
{{hash=f691b7f251035fbb43d9131ef24a699f}{%
family={Knochenhauer},
familyi={K\bibinitperiod},
given={Christian},
giveni={C\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{06ff1106c7bd49aac0f00411279490c6}
\strng{fullhash}{943fbbb6f6fd905af1e2e997368dd247}
\strng{bibnamehash}{943fbbb6f6fd905af1e2e997368dd247}
\strng{authorbibnamehash}{943fbbb6f6fd905af1e2e997368dd247}
\strng{authornamehash}{06ff1106c7bd49aac0f00411279490c6}
\strng{authorfullhash}{943fbbb6f6fd905af1e2e997368dd247}
\field{sortinit}{B}
\field{sortinithash}{d7095fff47cda75ca2589920aae98399}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Rethinking car software and electronics architecture}
\field{title}{Rethinking car software and electronics architecture {|} {McKinsey}}
\field{urlday}{14}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/rethinking-car-software-and-electronics-architecture
\endverb
\verb{url}
\verb https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/rethinking-car-software-and-electronics-architecture
\endverb
\endentry
\entry{corsaro_zenoh_2023}{inproceedings}{}
\name{author}{9}{}{%
{{hash=6c766583f4ac7d1213ecf95d254f8047}{%
family={Corsaro},
familyi={C\bibinitperiod},
given={Angelo},
giveni={A\bibinitperiod}}}%
{{hash=049c107779d2e8ea3cbec263b1b7b760}{%
family={Cominardi},
familyi={C\bibinitperiod},
given={Luca},
giveni={L\bibinitperiod}}}%
{{hash=9b1ca0be73b532705805ecd869a4ef7b}{%
family={Hecart},
familyi={H\bibinitperiod},
given={Olivier},
giveni={O\bibinitperiod}}}%
{{hash=495aa0c4fe1faa0f1977a9ddfd355c41}{%
family={Baldoni},
familyi={B\bibinitperiod},
given={Gabriele},
giveni={G\bibinitperiod}}}%
{{hash=73386503a9433d7270d82527bab5fb3d}{%
family={Avital},
familyi={A\bibinitperiod},
given={Julien\bibnamedelimb Enoch\bibnamedelima Pierre},
giveni={J\bibinitperiod\bibinitdelim E\bibinitperiod\bibinitdelim P\bibinitperiod}}}%
{{hash=a8e6d611cfca28903aa725ac4fb8ff0c}{%
family={Loudet},
familyi={L\bibinitperiod},
given={Julien},
giveni={J\bibinitperiod}}}%
{{hash=995bb172a17d3a7e84a0d48892592dec}{%
family={Guimares},
familyi={G\bibinitperiod},
given={Carlos},
giveni={C\bibinitperiod}}}%
{{hash=65e861224b9ebf1de33724ae42de5906}{%
family={Ilyin},
familyi={I\bibinitperiod},
given={Michael},
giveni={M\bibinitperiod}}}%
{{hash=1a849f130e9a1db09ab7b440c4ba7e2c}{%
family={Bannov},
familyi={B\bibinitperiod},
given={Dmitrii},
giveni={D\bibinitperiod}}}%
}
\strng{namehash}{8df565244616aa10319ea305cd8a0cb7}
\strng{fullhash}{d727c9dca42b90242b9dbf95b1ade831}
\strng{bibnamehash}{a639cc6d5f77721263b2a9e0f9e2bac2}
\strng{authorbibnamehash}{a639cc6d5f77721263b2a9e0f9e2bac2}
\strng{authornamehash}{8df565244616aa10319ea305cd8a0cb7}
\strng{authorfullhash}{d727c9dca42b90242b9dbf95b1ade831}
\field{sortinit}{C}
\field{sortinithash}{4d103a86280481745c9c897c925753c0}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{An increasing number of systems span from the data-center down to the micro-controller and need to smoothly operate across this continuum composed by extremely heterogeneous network technologies and computing platforms. Building these systems is quite challenging due to limitations of existing technological stacks. This paper introduces Zenoh a Pub/Sub-/Query protocol that unifies data at rest, data in motion and computations. Zenoh has been designed ground-up to address the needs of the cloud to micro-controller continuum. It has a minimal wire overhead of 5 bytes, it runs and perform on constrained as well as on high end networks and hardware.}
\field{booktitle}{2023 26th {Euromicro} {Conference} on {Digital} {System} {Design} ({DSD})}
\field{month}{9}
\field{title}{Zenoh: {Unifying} {Communication}, {Storage} and {Computation} from the {Cloud} to the {Microcontroller}}
\field{year}{2023}
\field{pages}{422\bibrangedash 428}
\range{pages}{7}
\keyw{Buildings,Digital systems,Hardware,Heterogeneous networks,Microcontrollers,Protocols,Wires}
\endentry
\entry{dieber_application-level_2016}{inproceedings}{}
\name{author}{4}{}{%
{{hash=7632bffe7d2809c3e9a07d188873b6c0}{%
family={Dieber},
familyi={D\bibinitperiod},
given={Bernhard},
giveni={B\bibinitperiod}}}%
{{hash=e9e24dff0b6d307372060b4f51b782ae}{%
family={Kacianka},
familyi={K\bibinitperiod},
given={Severin},
giveni={S\bibinitperiod}}}%
{{hash=7ade9571ddc325c9e91a298e25a2680a}{%
family={Rass},
familyi={R\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
{{hash=fc6f53c5534855f379f5adfafbd87134}{%
family={Schartner},
familyi={S\bibinitperiod},
given={Peter},
giveni={P\bibinitperiod}}}%
}
\strng{namehash}{63a94505b14532a90aaa30a0f4aed023}
\strng{fullhash}{136c5617bd4cc84518353485bb79c527}
\strng{bibnamehash}{136c5617bd4cc84518353485bb79c527}
\strng{authorbibnamehash}{136c5617bd4cc84518353485bb79c527}
\strng{authornamehash}{63a94505b14532a90aaa30a0f4aed023}
\strng{authorfullhash}{136c5617bd4cc84518353485bb79c527}
\field{sortinit}{D}
\field{sortinithash}{6f385f66841fb5e82009dc833c761848}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{While the topic of security in industrial applications has gained some momentum in recent years, there are still severe security vulnerabilities which are actively exploited for attacks. The robot operating system (ROS) is expected to further grow in usage and to be used in many industrial applications. Analysis, however, shows that it lacks several security enhancements in order to make it suitable for industrial use. In its current state, false data and commands can be injected posing a possible safety risk for the resulting product and humans in the production. In addition, data may be eavesdropped and used by outsiders to gain insight into the production process. In this paper we propose a security architecture intended for use on top of ROS on the application level. We use a dedicated authorization server to ensure that only valid nodes are part of the application. Cryptographic methods ensure data confidentiality and integrity. We show in a demonstration with a collaborative robot how our architecture can be used to secure a ROS-based application.}
\field{booktitle}{2016 {IEEE}/{RSJ} {International} {Conference} on {Intelligent} {Robots} and {Systems} ({IROS})}
\field{month}{10}
\field{title}{Application-level security for {ROS}-based applications}
\field{year}{2016}
\field{pages}{4477\bibrangedash 4482}
\range{pages}{6}
\keyw{Authentication,Cryptography,Digital signatures,Production,Service robots}
\endentry
\entry{van_dijk_future_2017}{misc}{}
\name{author}{1}{}{%
{{hash=a479accdb12985a2fcd6f684dc716d56}{%
family={Dijk},
familyi={D\bibinitperiod},
given={Luc},
giveni={L\bibinitperiod},
prefix={van},
prefixi={v\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\list{publisher}{1}{%
{NXP Semiconductors}%
}
\strng{namehash}{a479accdb12985a2fcd6f684dc716d56}
\strng{fullhash}{a479accdb12985a2fcd6f684dc716d56}
\strng{bibnamehash}{a479accdb12985a2fcd6f684dc716d56}
\strng{authorbibnamehash}{a479accdb12985a2fcd6f684dc716d56}
\strng{authornamehash}{a479accdb12985a2fcd6f684dc716d56}
\strng{authorfullhash}{a479accdb12985a2fcd6f684dc716d56}
\field{sortinit}{D}
\field{sortinithash}{6f385f66841fb5e82009dc833c761848}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{This article reviews today’s Electronic Control Units (ECUs), especially from a semiconductor technology perspective. Then, based on potential future vehicle networks, future ECUs are described along with the limitations and opportunities of (future) semiconductor technologies.}
\field{shorttitle}{Future {Vehicle} {Networks} and {ECUs}}
\field{title}{Future {Vehicle} {Networks} and {ECUs}}
\field{urlday}{14}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2017}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.nxp.com/docs/en/white-paper/FVNECUA4WP.pdf
\endverb
\verb{url}
\verb https://www.nxp.com/docs/en/white-paper/FVNECUA4WP.pdf
\endverb
\endentry
\entry{eclipse_foundation_abstractions_2024}{misc}{}
\name{author}{1}{}{%
{{hash=ba965a2360c8acdc8182fb5f00ea04f0}{%
family={{Eclipse Foundation}},
familyi={E\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{fullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{bibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorbibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authornamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorfullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\field{extraname}{1}
\field{sortinit}{E}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Zenoh Documentation}
\field{month}{7}
\field{title}{Abstractions · {Zenoh} - pub/sub, geo distributed storage, query}
\field{urlday}{22}
\field{urlmonth}{7}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://zenoh.io/docs/manual/abstractions/
\endverb
\verb{url}
\verb https://zenoh.io/docs/manual/abstractions/
\endverb
\endentry
\entry{eclipse_foundation_deployment_2024}{misc}{}
\name{author}{1}{}{%
{{hash=ba965a2360c8acdc8182fb5f00ea04f0}{%
family={{Eclipse Foundation}},
familyi={E\bibinitperiod}}}%
}
\strng{namehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{fullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{bibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorbibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authornamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorfullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\field{extraname}{2}
\field{sortinit}{E}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Zenoh Documentation}
\field{month}{7}
\field{title}{Deployment · {Zenoh} - pub/sub, geo distributed storage, query}
\field{type}{Documentation}
\field{urlday}{22}
\field{urlmonth}{7}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://zenoh.io/docs/getting-started/deployment/
\endverb
\verb{url}
\verb https://zenoh.io/docs/getting-started/deployment/
\endverb
\endentry
\entry{eclipse_foundation_zenoh_2024}{misc}{}
\name{author}{1}{}{%
{{hash=ba965a2360c8acdc8182fb5f00ea04f0}{%
family={{Eclipse Foundation}},
familyi={E\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{fullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{bibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorbibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authornamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorfullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\field{extraname}{3}
\field{sortinit}{E}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Zenoh Documentation}
\field{month}{7}
\field{title}{Zenoh {Adopters} · {Zenoh} - pub/sub, geo distributed storage, query}
\field{type}{Documentation}
\field{urlday}{22}
\field{urlmonth}{7}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://zenoh.io/adopters/
\endverb
\verb{url}
\verb https://zenoh.io/adopters/
\endverb
\endentry
\entry{eclipse_foundation_zenoh-flow_2024}{misc}{}
\name{author}{1}{}{%
{{hash=ba965a2360c8acdc8182fb5f00ea04f0}{%
family={{Eclipse Foundation}},
familyi={E\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{fullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{bibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorbibnamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authornamehash}{ba965a2360c8acdc8182fb5f00ea04f0}
\strng{authorfullhash}{ba965a2360c8acdc8182fb5f00ea04f0}
\field{extraname}{4}
\field{sortinit}{E}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Zenoh Flow Documentation}
\field{journaltitle}{Zenoh Flow Getting Starget}
\field{month}{7}
\field{title}{Zenoh-{Flow} 0.6.0-rc: {Getting} {Started} · {Zenoh} - pub/sub, geo distributed storage, query}
\field{type}{Documentation}
\field{urlday}{24}
\field{urlmonth}{7}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://zenoh.io/blog/2024-01-31-zenoh-flow-getting-started/
\endverb
\verb{url}
\verb https://zenoh.io/blog/2024-01-31-zenoh-flow-getting-started/
\endverb
\endentry
\entry{ekberg_autosar_2022}{misc}{}
\name{author}{1}{}{%
{{hash=b7166c1192c0a3cf0e5283cf4e838719}{%
family={Ekberg},
familyi={E\bibinitperiod},
given={Johan},
giveni={J\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{b7166c1192c0a3cf0e5283cf4e838719}
\strng{fullhash}{b7166c1192c0a3cf0e5283cf4e838719}
\strng{bibnamehash}{b7166c1192c0a3cf0e5283cf4e838719}
\strng{authorbibnamehash}{b7166c1192c0a3cf0e5283cf4e838719}
\strng{authornamehash}{b7166c1192c0a3cf0e5283cf4e838719}
\strng{authorfullhash}{b7166c1192c0a3cf0e5283cf4e838719}
\field{sortinit}{E}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The ROS 2 community and the AUTOSAR consortium are both addressing the challenges of creating a middleware that can be used in complex embed}
\field{journaltitle}{Apex.AI}
\field{month}{5}
\field{title}{{AUTOSAR} and {ROS} 2 for {Software}-{Defined} {Vehicle}}
\field{urlday}{4}
\field{urlmonth}{11}
\field{urlyear}{2024}
\field{year}{2022}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.apex.ai/post/autosar-and-ros-2-for-software-defined-vehicle
\endverb
\verb{url}
\verb https://www.apex.ai/post/autosar-and-ros-2-for-software-defined-vehicle
\endverb
\endentry
\entry{eprosima_11_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{1}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{1. Getting Started » 1.1. What is DDS?}
\field{month}{3}
\field{title}{1.1. {What} is {DDS}? — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/getting_started/definitions.html#the-dcps-conceptual-model
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/getting_started/definitions.html#the-dcps-conceptual-model
\endverb
\endentry
\entry{eprosima_12_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{2}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{12. PropertyPolicyQos Options — Fast DDS 2.14.0 documentation}
\field{month}{3}
\field{title}{12. {PropertyPolicyQos} {Options} — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/property_policies/property_policies.html
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/property_policies/property_policies.html
\endverb
\endentry
\entry{eprosima_3_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{3}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{3. DDS Layer — Fast DDS 2.14.0 documentation}
\field{month}{3}
\field{title}{3. {DDS} {Layer} — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/dds_layer/dds_layer.html
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/dds_layer/dds_layer.html
\endverb
\endentry
\entry{eprosima_5_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{4}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{5. Discovery — Fast DDS 2.14.0 documentation}
\field{month}{3}
\field{title}{5. {Discovery} — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/discovery/discovery.html
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/discovery/discovery.html
\endverb
\endentry
\entry{eprosima_6_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{5}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{6. Transport Layer — Fast DDS 2.14.0 documentation}
\field{month}{3}
\field{title}{6. {Transport} {Layer} — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/transport/transport.html
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/transport/transport.html
\endverb
\endentry
\entry{eprosima_8_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{6}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{8. Security — Fast DDS 2.14.0 documentation}
\field{month}{3}
\field{title}{8. {Security} — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/security/security.html
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/fastdds/security/security.html
\endverb
\endentry
\entry{eprosima_dds_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={{eProsima}},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{7}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{DDS API — Fast DDS 2.14.0 documentation}
\field{month}{3}
\field{title}{{DDS} {API} — {Fast} {DDS} 2.14.0 documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/02-formalia/titlepage.html
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/02-formalia/titlepage.html
\endverb
\endentry
\entry{eprosima_dependencies_2024}{misc}{}
\name{author}{1}{}{%
{{hash=3f394000194f0ea4a0d924108d2d3da4}{%
family={eProsima},
familyi={e\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{fullhash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{bibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorbibnamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authornamehash}{3f394000194f0ea4a0d924108d2d3da4}
\strng{authorfullhash}{3f394000194f0ea4a0d924108d2d3da4}
\field{extraname}{8}
\field{sortinit}{e}
\field{sortinithash}{8da8a182d344d5b9047633dfc0cc9131}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Fast DDS 3.0.0 documentation}
\field{month}{5}
\field{title}{Dependencies and compatibilities — {Fast} {DDS} 3.0.0 documentation}
\field{type}{Documentation}
\field{urlday}{31}
\field{urlmonth}{5}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://fast-dds.docs.eprosima.com/en/latest/notes/versions.html#platform-support
\endverb
\verb{url}
\verb https://fast-dds.docs.eprosima.com/en/latest/notes/versions.html#platform-support
\endverb
\endentry
\entry{furst_autosar_2016}{inproceedings}{}
\name{author}{2}{}{%
{{hash=f95d5928efa65455bd84d92ff6c6d9ff}{%
family={Furst},
familyi={F\bibinitperiod},
given={Simon},
giveni={S\bibinitperiod}}}%
{{hash=eded8ce4bd682841510023c9f422834b}{%
family={Bechter},
familyi={B\bibinitperiod},
given={Markus},
giveni={M\bibinitperiod}}}%
}
\list{location}{1}{%
{Toulouse, France}%
}
\list{publisher}{1}{%
{IEEE}%
}
\strng{namehash}{2a049adcb7b93cdfc7fe7d4be40a2dcc}
\strng{fullhash}{4b13ab1565dbf306eb97e89e73a6a9e6}
\strng{bibnamehash}{4b13ab1565dbf306eb97e89e73a6a9e6}
\strng{authorbibnamehash}{4b13ab1565dbf306eb97e89e73a6a9e6}
\strng{authornamehash}{2a049adcb7b93cdfc7fe7d4be40a2dcc}
\strng{authorfullhash}{4b13ab1565dbf306eb97e89e73a6a9e6}
\field{sortinit}{F}
\field{sortinithash}{2638baaa20439f1b5a8f80c6c08a13b4}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{booktitle}{2016 46th {Annual} {IEEE}/{IFIP} {International} {Conference} on {Dependable} {Systems} and {Networks} {Workshop} ({DSN}-{W})}
\field{isbn}{978-1-5090-3688-2}
\field{month}{6}
\field{shorttitle}{{AUTOSAR} for {Connected} and {Autonomous} {Vehicles}}
\field{title}{{AUTOSAR} for {Connected} and {Autonomous} {Vehicles}: {The} {AUTOSAR} {Adaptive} {Platform}}
\field{year}{2016}
\field{pages}{215\bibrangedash 217}
\range{pages}{3}
\verb{doi}
\verb 10.1109/DSN-W.2016.24
\endverb
\endentry
\entry{garlan_software_2014}{inproceedings}{}
\name{author}{1}{}{%
{{hash=5e93a0537dc9db010915acd5407760d4}{%
family={Garlan},
familyi={G\bibinitperiod},
given={David},
giveni={D\bibinitperiod}}}%
}
\list{location}{1}{%
{New York, NY, USA}%
}
\list{publisher}{1}{%
{Association for Computing Machinery}%
}
\strng{namehash}{5e93a0537dc9db010915acd5407760d4}
\strng{fullhash}{5e93a0537dc9db010915acd5407760d4}
\strng{bibnamehash}{5e93a0537dc9db010915acd5407760d4}
\strng{authorbibnamehash}{5e93a0537dc9db010915acd5407760d4}
\strng{authornamehash}{5e93a0537dc9db010915acd5407760d4}
\strng{authorfullhash}{5e93a0537dc9db010915acd5407760d4}
\field{sortinit}{G}
\field{sortinithash}{32d67eca0634bf53703493fb1090a2e8}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Over the past two and a half decades software architecture has emerged as an important subfield of software engineering. During that time there has been considerable progress in developing the technological and methodological base for treating architectural design as an engineering discipline. However, much still remains to be done to achieve that. Moreover, the changing face of technology raises a number of challenges for software architecture. This travelogue recounts the history of the field, its current state of practice and research, and speculates on some of the important emerging trends, challenges, and aspirations.}
\field{booktitle}{Future of {Software} {Engineering} {Proceedings}}
\field{month}{5}
\field{series}{{FOSE} 2014}
\field{title}{Software architecture: a travelogue}
\field{year}{2014}
\field{pages}{29\bibrangedash 39}
\range{pages}{11}
\keyw{Software architecture,architecture and agility,architecture description languages,architecture styles,architecture trends,software frame-works,software product lines}
\endentry
\entry{hackel_dynamic_2023}{misc}{}
\name{author}{6}{}{%
{{hash=7d5244e13d35b4779475faae95c4a804}{%
family={Häckel},
familyi={H\bibinitperiod},
given={Timo},
giveni={T\bibinitperiod}}}%
{{hash=7e1797520731ac393c1c4744f26517d5}{%
family={Meyer},
familyi={M\bibinitperiod},
given={Philipp},
giveni={P\bibinitperiod}}}%
{{hash=1ae8d90b043debf99eecc97c6a4bac37}{%
family={Mueller},
familyi={M\bibinitperiod},
given={Mehmet},
giveni={M\bibinitperiod}}}%
{{hash=54c0bcb9b9809cb326570fa01e49f58b}{%
family={Schmitt-Solbrig},
familyi={S\bibinithyphendelim S\bibinitperiod},
given={Jan},
giveni={J\bibinitperiod}}}%
{{hash=bbfff937ccfb8e2eddbd84e0baff8880}{%
family={Korf},
familyi={K\bibinitperiod},
given={Franz},
giveni={F\bibinitperiod}}}%
{{hash=c834dc8a5cb0646371794a22957a5130}{%
family={Schmidt},
familyi={S\bibinitperiod},
given={Thomas\bibnamedelima C.},
giveni={T\bibinitperiod\bibinitdelim C\bibinitperiod}}}%
}
\list{publisher}{1}{%
{arXiv}%
}
\strng{namehash}{59230bc78f0be0a9bb8c74bbc45b4f54}
\strng{fullhash}{feebaf668e4390a4a6ed814794d2e5e0}
\strng{bibnamehash}{feebaf668e4390a4a6ed814794d2e5e0}
\strng{authorbibnamehash}{feebaf668e4390a4a6ed814794d2e5e0}
\strng{authornamehash}{59230bc78f0be0a9bb8c74bbc45b4f54}
\strng{authorfullhash}{feebaf668e4390a4a6ed814794d2e5e0}
\field{sortinit}{H}
\field{sortinithash}{23a3aa7c24e56cfa16945d55545109b5}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Modern In-Vehicle Networks (IVNs) are composed of a large number of devices and services linked via an Ethernet-based time-sensitive network. Communication in future IVNs will become more dynamic as services can be updated, added, or removed during runtime. This requires a flexible and adaptable IVN, for which Software-Defined Networking (SDN) is a promising candidate. In this paper, we show how SDN can be used to support a dynamic, service-oriented network architecture. We demonstrate our concept using the SOME/IP protocol, which is the most widely deployed implementation of automotive service-oriented architectures. In a simulation study, we evaluate the performance of SOME/IP-adaptive SDN control compared to standard Ethernet switching and non-optimized SDN. Our results show an expected overhead introduced by the central SDN controller, which is, however, reduced by up to 50\% compared to SOME/IP-unaware SDN.For a large number of services, the setup time is in the order of milliseconds, which matches standard Ethernet switching. A SOME/IP-aware SDN controller can optimize the service discovery to improve adaptability, robustness, security, and Quality-of-Service of the IVN while remaining transparent to existing SOME/IP implementations.}
\field{month}{3}
\field{note}{arXiv:2303.13903 [cs]}
\field{title}{Dynamic {Service}-{Orientation} for {Software}-{Defined} {In}-{Vehicle} {Networks}}
\field{year}{2023}
\keyw{Computer Science - Networking and Internet Architecture}
\endentry
\entry{henle_architecture_2022}{inproceedings}{}
\name{author}{5}{}{%
{{hash=10976ff3585c6b42db90ebfefbc886c5}{%
family={Henle},
familyi={H\bibinitperiod},
given={Jacqueline},
giveni={J\bibinitperiod}}}%
{{hash=d6b48f43257f62a54e977ff2899d5c70}{%
family={Stoffel},
familyi={S\bibinitperiod},
given={Martin},
giveni={M\bibinitperiod}}}%
{{hash=e30188a04dabd81437799d363bef39e3}{%
family={Schindewolf},
familyi={S\bibinitperiod},
given={Marc},
giveni={M\bibinitperiod}}}%
{{hash=60b6b966bae78049f1e114d5a7b8dde8}{%
family={Nagele},
familyi={N\bibinitperiod},
given={Ann-Therese},
giveni={A\bibinithyphendelim T\bibinitperiod}}}%
{{hash=f6edc406efe2f0b7f0ce15869e359764}{%
family={Sax},
familyi={S\bibinitperiod},
given={Eric},
giveni={E\bibinitperiod}}}%
}
\strng{namehash}{a12f9585b6f9bc63bcbd50a117892cf7}
\strng{fullhash}{816ead6906692bded86db7d6b10408e1}
\strng{bibnamehash}{816ead6906692bded86db7d6b10408e1}
\strng{authorbibnamehash}{816ead6906692bded86db7d6b10408e1}
\strng{authornamehash}{a12f9585b6f9bc63bcbd50a117892cf7}
\strng{authorfullhash}{816ead6906692bded86db7d6b10408e1}
\field{sortinit}{H}
\field{sortinithash}{23a3aa7c24e56cfa16945d55545109b5}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Autonomous Vehicles (AVs) are supposed to be continuously updated, besides that they combine many diverse applications by various developers. Accordingly, they require flexible and dynamic software (SW) architectures. With communication paradigms changing from signal-based to serviceoriented architectures (SOAs), long-established standards seem no longer sufficient. The AUTomotive Open System ARchitecture (AUTOSAR) Platform came up with the Adaptive standard to meet future automobile requirements. Alongside, while requirements of AVs and robotic systems are similar to a certain extent, the Robot Operating System (ROS) gets growing attention in the automotive environment. With the introduction of ROS2 and ROS2-based commercial solutions, the Adaptive AUTOSAR Platform seems not to be the only appropriate standard for developing high-performing SW architectures.}
\field{booktitle}{2022 {IEEE} 25th {International} {Conference} on {Intelligent} {Transportation} {Systems} ({ITSC})}
\field{month}{10}
\field{title}{Architecture platforms for future vehicles: a comparison of {ROS2} and {Adaptive} {AUTOSAR}}
\field{year}{2022}
\field{pages}{3095\bibrangedash 3102}
\range{pages}{8}
\endentry
\entry{hu_gatekeeper_2022}{inproceedings}{}
\name{author}{4}{}{%
{{hash=50e7f3a2b76cc0d1934bad66092c8b22}{%
family={Hu},
familyi={H\bibinitperiod},
given={Shengtuo},
giveni={S\bibinitperiod}}}%
{{hash=070d68d23599e50e713511d14d0dca29}{%
family={Zhang},
familyi={Z\bibinitperiod},
given={Qingzhao},
giveni={Q\bibinitperiod}}}%
{{hash=f0a64cdbeecee14abe2ae82429f5cc0a}{%
family={Weimerskirch},
familyi={W\bibinitperiod},
given={André},
giveni={A\bibinitperiod}}}%
{{hash=055cf8f6bda6dc13a608c2707cac9aa3}{%
family={Mao},
familyi={M\bibinitperiod},
given={Z.\bibnamedelimi Morley},
giveni={Z\bibinitperiod\bibinitdelim M\bibinitperiod}}}%
}
\list{location}{1}{%
{New York, NY, USA}%
}
\list{publisher}{1}{%
{Association for Computing Machinery}%
}
\strng{namehash}{c0a933d49c21291ef51cd5dc98c55fcf}
\strng{fullhash}{6e79630269738dfaf0d471f16fe78a0f}
\strng{bibnamehash}{6e79630269738dfaf0d471f16fe78a0f}
\strng{authorbibnamehash}{6e79630269738dfaf0d471f16fe78a0f}
\strng{authornamehash}{c0a933d49c21291ef51cd5dc98c55fcf}
\strng{authorfullhash}{6e79630269738dfaf0d471f16fe78a0f}
\field{sortinit}{H}
\field{sortinithash}{23a3aa7c24e56cfa16945d55545109b5}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Automotive Ethernet is considered to be the next-generation in-vehicle network, because of its high bandwidth, high throughput, and low cost characteristics. However, no common standard has been established for the security protocol of Automotive Ethernet. While there are a few candidates, including MACsec, IPsec, and TLS, there is no widely favored candidate. Most importantly, existing candidates cannot fully satisfy the requirements of in-vehicle communication, specifically source authentication for broadcast/multicast communication. In this paper, we conduct a comprehensive analysis in both security and performance of existing security protocol candidates and identify source authentication and Denial-of-Service (DoS) prevention as two essential but missing properties in these candidates. We propose Gatekeeper, a gateway-based broadcast authentication protocol to ensure source authentication. In general, Gatekeeper introduces an on-path authenticator, which co-locates with the in-vehicle gateway or domain controllers and helps receivers to verify the sender's identity. To defend against DoS threats, we further integrate the time-lock puzzle with Gatekeeper to slow down malicious traffic. Our performance evaluation results show that Gatekeeper only results in 0.03 ms latency overhead for CAN data transmission and outperforms TESLA on both CAN and LiDAR transmission scenarios, highlighting the effectiveness and efficiency of Gatekeeper.}
\field{booktitle}{Proceedings of the 2022 {ACM} on {Asia} {Conference} on {Computer} and {Communications} {Security}}
\field{series}{{ASIA} {CCS} '22}
\field{title}{Gatekeeper: {A} {Gateway}-based {Broadcast} {Authentication} {Protocol} for the {In}-{Vehicle} {Ethernet}}
\field{year}{2022}
\field{pages}{494\bibrangedash 507}
\range{pages}{14}
\endentry
\entry{noauthor_ieee_2022}{article}{}
\field{sortinit}{I}
\field{sortinithash}{8d291c51ee89b6cd86bf5379f0b151d8}
\field{labeltitlesource}{title}
\field{abstract}{Ethernet local area network operation is specified for selected speeds of operation from 1 Mb/s to 400 Gb/s using a common media access control (MAC) specification and management information base (MIB). The Carrier Sense Multiple Access with Collision Detection (CSMA/CD) MAC protocol specifies shared medium (half duplex) operation, as well as full duplex operation. Speed specific Media Independent Interfaces (MIIs) allow use of selected Physical Layer devices (PHYs) for operation over coaxial, twisted pair or fiber optic cables, or electrical backplanes. System considerations for multisegment shared access networks describe the use of Repeaters that are defined for operational speeds up to 1000 Mb/s. Local Area Network (LAN) operation is supported at all speeds. Other specified capabilities include: various PHY types for access networks, PHYs suitable for metropolitan area network applications, and the provision of power over selected twisted pair PHY types. NOTE: Additional downloads are available at: https://standards.ieee.org/wp-content/uploads/2024/02/802.3-2022\_errata.pdf and https://standards.ieee.org/wp-content/uploads/2022/07/802.3-2022\_downloads.zip}
\field{journaltitle}{IEEE Std 802.3-2022 (Revision of IEEE Std 802.3-2018)}
\field{month}{7}
\field{title}{{IEEE} {Standard} for {Ethernet}}
\field{urlday}{16}
\field{urlmonth}{7}
\field{urlyear}{2024}
\field{year}{2022}
\field{urldateera}{ce}
\field{pages}{1\bibrangedash 7025}
\range{pages}{7025}
\verb{doi}
\verb 10.1109/IEEESTD.2022.9844436
\endverb
\verb{urlraw}
\verb https://ieeexplore.ieee.org/document/9844436
\endverb
\verb{url}
\verb https://ieeexplore.ieee.org/document/9844436
\endverb
\keyw{10 Gigabit Ethernet,100 Gigabit Ethernet,2.5 Gigabit Ethernet,200 Gigabit Ethernet,25 Gigabit Ethernet,40 Gigabit Ethernet,400 Gigabit Ethernet,5 Gigabit Ethernet,50 Gigabit Ethernet,AN,AUI,Auto-Negotiation,Backplane Ethernet,DTE Power via the MDI,EEE,EPON,EPON protocol over coax,EPoC,Energy-Efficient Ethernet,Ethernet,Ethernet Passive Optical Network,Ethernet in the first mile,FEC,Fast Ethernet,Gigabit Ethernet,IEEE 802.3,IEEE 802.3 Standard,IEEE Standards,LAN,MCRS,MDI,MIB,MII,MMF,MPCP,Multi-Channel Reconciliation Sublayer,Optical fiber LAN,Optical fiber cables,P2MP,PCS,PD,PHY,PLCA,PMA,PMD,PSE,Physical Layer,Physical Layer Collision Avoidance,Physical Layer device,Physical layer,PoDL,PoE,Power Sourcing Equipment,Power over Data Lines,Power over Ethernet,Powered Device,RS,SMF,Standards,attachment unit interface,balanced cable,data processing,express traffic,forward error correction,information exchange,isolation,local area network,management,media independent interface,medium dependent interface,multimode fiber,multipoint control protocol,physical coding sublayer,physical medium attachment,physical medium dependent,point to multipoint,reconciliation sublayer,repeater,single-mode fiber,type field}
\endentry
\entry{jatzkowski_integration_2021}{inproceedings}{}
\name{author}{9}{}{%
{{hash=5ef21f2df0acf011c147c4f2668ea7d3}{%
family={Jatzkowski},
familyi={J\bibinitperiod},
given={Inga},
giveni={I\bibinitperiod}}}%
{{hash=58d3fc547b9d1dcb5c02f2ec084b6aaa}{%
family={Stolte},
familyi={S\bibinitperiod},
given={Torben},
giveni={T\bibinitperiod}}}%
{{hash=65c3dacd458c18a65ddf8137559bc9a9}{%
family={Graubohm},
familyi={G\bibinitperiod},
given={Robert},
giveni={R\bibinitperiod}}}%
{{hash=4494753eefa828e7273b9373b7588d9b}{%
family={Maurer},
familyi={M\bibinitperiod},
given={Markus},
giveni={M\bibinitperiod}}}%
{{hash=a9a420fc51ee920787975f0546c95f0d}{%
family={Kampmann},
familyi={K\bibinitperiod},
given={Alexandru},
giveni={A\bibinitperiod}}}%
{{hash=eaf68c5e298227ab078999d16b1acc88}{%
family={Alrifaee},
familyi={A\bibinitperiod},
given={Bassam},
giveni={B\bibinitperiod}}}%
{{hash=882993b479ae64df7d1f06efbc01e805}{%
family={Kowalewski},
familyi={K\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
{{hash=7ce090a2fc77c824263681099a13479d}{%
family={Buchholz},
familyi={B\bibinitperiod},
given={Michael},
giveni={M\bibinitperiod}}}%
{{hash=2f1c83e71a33d1c7df6e6b4962d375bb}{%
family={Dietmayer},
familyi={D\bibinitperiod},
given={Klaus},
giveni={K\bibinitperiod}}}%
}
\strng{namehash}{26d64228a0fc03532154d5cb3ab1a195}
\strng{fullhash}{02484b92b93e6165047823ea17f28089}
\strng{bibnamehash}{1ddb4a481e8493aedc7e42e557a050a0}
\strng{authorbibnamehash}{1ddb4a481e8493aedc7e42e557a050a0}
\strng{authornamehash}{26d64228a0fc03532154d5cb3ab1a195}
\strng{authorfullhash}{02484b92b93e6165047823ea17f28089}
\field{sortinit}{J}
\field{sortinithash}{b2f54a9081ace9966a7cb9413811edb4}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{30th {Aachen} {Colloquium} {Sustainable} {Mobility} 2021, 4.–6. {Oktober} 2021}
\field{title}{Integration of a {Vehicle} {Operating} {Mode} {Management} into {UNICARagil}’s {Automotive} {Service}-oriented {Software} {Architecture}}
\field{year}{2021}
\keyw{ownOther}
\endentry
\entry{kampmann_dynamic_2019}{inproceedings}{}
\name{author}{8}{}{%
{{hash=a9a420fc51ee920787975f0546c95f0d}{%
family={Kampmann},
familyi={K\bibinitperiod},
given={Alexandru},
giveni={A\bibinitperiod}}}%
{{hash=eaf68c5e298227ab078999d16b1acc88}{%
family={Alrifaee},
familyi={A\bibinitperiod},
given={Bassam},
giveni={B\bibinitperiod}}}%
{{hash=841b927ec401aae305eb7595d71c375e}{%
family={Kohout},
familyi={K\bibinitperiod},
given={Markus},
giveni={M\bibinitperiod}}}%
{{hash=c83546cbf8420788f5fbd5ec8da817b3}{%
family={Wustenberg},
familyi={W\bibinitperiod},
given={Andreas},
giveni={A\bibinitperiod}}}%
{{hash=05d38bb1fbb55294315d5639c3603d09}{%
family={Woopen},
familyi={W\bibinitperiod},
given={Timo},
giveni={T\bibinitperiod}}}%
{{hash=5afd7626abdfeac65ad4ff208814b032}{%
family={Nolte},
familyi={N\bibinitperiod},
given={Marcus},
giveni={M\bibinitperiod}}}%
{{hash=175f35cd7ccffb357f0e8c7a458e5508}{%
family={Eckstein},
familyi={E\bibinitperiod},
given={Lutz},
giveni={L\bibinitperiod}}}%
{{hash=882993b479ae64df7d1f06efbc01e805}{%
family={Kowalewski},
familyi={K\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
}
\strng{namehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{fullhash}{4391cd0d0380007bdb87b7d0e8874a4d}
\strng{bibnamehash}{d15094d49bc3e04426aad976a185d00b}
\strng{authorbibnamehash}{d15094d49bc3e04426aad976a185d00b}
\strng{authornamehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{authorfullhash}{4391cd0d0380007bdb87b7d0e8874a4d}
\field{extraname}{1}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{2019 {IEEE} {Intelligent} {Transportation} {Systems} {Conference} ({ITSC})}
\field{isbn}{978-1-5386-7024-8}
\field{month}{10}
\field{title}{A {Dynamic} {Service}-{Oriented} {Software} {Architecture} for {Highly} {Automated} {Vehicles}}
\field{urlday}{11}
\field{urlmonth}{1}
\field{urlyear}{2024}
\field{year}{2019}
\field{urldateera}{ce}
\field{pages}{2101\bibrangedash 2108}
\range{pages}{8}
\verb{doi}
\verb 10.1109/ITSC.2019.8916841
\endverb
\endentry
\entry{kampmann_optimization-based_2022}{inproceedings}{}
\name{author}{4}{}{%
{{hash=a9a420fc51ee920787975f0546c95f0d}{%
family={Kampmann},
familyi={K\bibinitperiod},
given={Alexandru},
giveni={A\bibinitperiod}}}%
{{hash=e022535740c712039043c711f85a4835}{%
family={Luer},
familyi={L\bibinitperiod},
given={Maximilian},
giveni={M\bibinitperiod}}}%
{{hash=882993b479ae64df7d1f06efbc01e805}{%
family={Kowalewski},
familyi={K\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
{{hash=eaf68c5e298227ab078999d16b1acc88}{%
family={Alrifaee},
familyi={A\bibinitperiod},
given={Bassam},
giveni={B\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{fullhash}{a4148bab880683528a2519fb9cdf13a9}
\strng{bibnamehash}{a4148bab880683528a2519fb9cdf13a9}
\strng{authorbibnamehash}{a4148bab880683528a2519fb9cdf13a9}
\strng{authornamehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{authorfullhash}{a4148bab880683528a2519fb9cdf13a9}
\field{extraname}{2}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{This paper presents an approach for allocation of resources in an automotive service-oriented software architecture. Using mathematical optimization, we assign computational resources of an automotive compute cluster to a set of software services. Additionally, scheduling parameters of services are optimized under the consideration of dependencies between data flows and computations within services. The optimization minimizes power consumption and the maximum execution times of critical effect chains in a multi-objective optimization problem. The evaluation investigates the achievable reduction in power consumption using an exemplary system. Furthermore, we demonstrate a sharp reduction in maximum execution times of effect chains that span multiple services and ECUs.}
\field{booktitle}{2022 {IEEE} {Intelligent} {Vehicles} {Symposium} ({IV})}
\field{isbn}{978-1-66548-821-1}
\field{month}{6}
\field{title}{Optimization-based {Resource} {Allocation} for an {Automotive} {Service}-oriented {Software} {Architecture}}
\field{year}{2022}
\field{pages}{678\bibrangedash 687}
\range{pages}{10}
\verb{doi}
\verb 10.1109/IV51971.2022.9827429
\endverb
\endentry
\entry{kampmann_asoa_2022}{inproceedings}{}
\name{author}{4}{}{%
{{hash=a9a420fc51ee920787975f0546c95f0d}{%
family={Kampmann},
familyi={K\bibinitperiod},
given={Alexandru},
giveni={A\bibinitperiod}}}%
{{hash=a35cdfc1ab50c0c52f938f1118d45c0b}{%
family={Mokhtarian},
familyi={M\bibinitperiod},
given={Armin},
giveni={A\bibinitperiod}}}%
{{hash=882993b479ae64df7d1f06efbc01e805}{%
family={Kowalewski},
familyi={K\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
{{hash=eaf68c5e298227ab078999d16b1acc88}{%
family={Alrifaee},
familyi={A\bibinitperiod},
given={Bassam},
giveni={B\bibinitperiod}}}%
}
\list{location}{1}{%
{Aachen, Germany}%
}
\strng{namehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{fullhash}{0151c2135978133ca3b61667af6dd2f2}
\strng{bibnamehash}{0151c2135978133ca3b61667af6dd2f2}
\strng{authorbibnamehash}{0151c2135978133ca3b61667af6dd2f2}
\strng{authornamehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{authorfullhash}{0151c2135978133ca3b61667af6dd2f2}
\field{extraname}{3}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{31st {Aachen} {Colloquium} {Sustainable} {Mobility} 2022}
\field{title}{{ASOA} - {A} {Dynamic} {Software} {Architecture} for {Software}-defined {Vehicles}}
\field{year}{2022}
\endentry
\entry{kampmann_portable_2019}{inproceedings}{}
\name{author}{4}{}{%
{{hash=a9a420fc51ee920787975f0546c95f0d}{%
family={Kampmann},
familyi={K\bibinitperiod},
given={Alexandru},
giveni={A\bibinitperiod}}}%
{{hash=c83546cbf8420788f5fbd5ec8da817b3}{%
family={Wustenberg},
familyi={W\bibinitperiod},
given={Andreas},
giveni={A\bibinitperiod}}}%
{{hash=eaf68c5e298227ab078999d16b1acc88}{%
family={Alrifaee},
familyi={A\bibinitperiod},
given={Bassam},
giveni={B\bibinitperiod}}}%
{{hash=882993b479ae64df7d1f06efbc01e805}{%
family={Kowalewski},
familyi={K\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
}
\list{location}{1}{%
{Auckland, New Zealand}%
}
\list{publisher}{1}{%
{IEEE}%
}
\strng{namehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{fullhash}{d16dec4bdeef73937e99638a08e0a7a6}
\strng{bibnamehash}{d16dec4bdeef73937e99638a08e0a7a6}
\strng{authorbibnamehash}{d16dec4bdeef73937e99638a08e0a7a6}
\strng{authornamehash}{4e91ec8ddda6cf698324a02f3c1fd86d}
\strng{authorfullhash}{d16dec4bdeef73937e99638a08e0a7a6}
\field{extraname}{4}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{2019 {IEEE} {Intelligent} {Transportation} {Systems} {Conference} ({ITSC})}
\field{isbn}{978-1-5386-7024-8}
\field{month}{10}
\field{title}{A {Portable} {Implementation} of the {Real}-{Time} {Publish}-{Subscribe} {Protocol} for {Microcontrollers} in {Distributed} {Robotic} {Applications}}
\field{year}{2019}
\field{pages}{443\bibrangedash 448}
\range{pages}{6}
\verb{doi}
\verb 10.1109/ITSC.2019.8916835
\endverb
\endentry
\entry{kang_rdds_2012}{article}{}
\name{author}{3}{}{%
{{hash=9a768a23ffc8ce028a5ba75b9bba0698}{%
family={Kang},
familyi={K\bibinitperiod},
given={Woochul},
giveni={W\bibinitperiod}}}%
{{hash=ec9828c692f71b57bfce4f5d5bf2d2fb}{%
family={Kapitanova},
familyi={K\bibinitperiod},
given={Krasimira},
giveni={K\bibinitperiod}}}%
{{hash=4f2d32b6c781c06f8216d90d84601616}{%
family={Son},
familyi={S\bibinitperiod},
given={Sang\bibnamedelima Hyuk},
giveni={S\bibinitperiod\bibinitdelim H\bibinitperiod}}}%
}
\strng{namehash}{86edc24e0431b21ec77c499ec16c5830}
\strng{fullhash}{d4804ca20482388f56fa3111e659a12f}
\strng{bibnamehash}{d4804ca20482388f56fa3111e659a12f}
\strng{authorbibnamehash}{d4804ca20482388f56fa3111e659a12f}
\strng{authornamehash}{86edc24e0431b21ec77c499ec16c5830}
\strng{authorfullhash}{d4804ca20482388f56fa3111e659a12f}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{One of the primary requirements in many cyber-physical systems (CPS) is that the sensor data derived from the physical world should be disseminated in a timely and reliable manner to all interested collaborative entities. However, providing reliable and timely data dissemination services is especially challenging for CPS since they often operate in highly unpredictable environments. Existing network middleware has limitations in providing such services. In this paper, we present a novel publish/subscribe-based middleware architecture called Real-time Data Distribution Service (RDDS). In particular, we focus on two mechanisms of RDDS that enable timely and reliable sensor data dissemination under highly unpredictable CPS environments. First, we discuss the semantics-aware communication mechanism of RDDS that not only reduces the computation and communication overhead, but also enables the subscribers to access data in a timely and reliable manner when the network is slow or unstable. Further, we extend the semantics-aware communication mechanism to achieve robustness against unpredictable workloads by integrating a control-theoretic feedback controller at the publishers and a queueing-theoretic predictor at the subscribers. This integrated control loop provides Quality-of-Service (QoS) guarantees by dynamically adjusting the accuracy of the sensor models. We demonstrate the viability of the proposed approach by implementing a prototype of RDDS. The evaluation results show that, compared to baseline approaches, RDDS achieves highly efficient and reliable sensor data dissemination as well as robustness against unpredictable workloads.}
\field{issn}{1941-0050}
\field{journaltitle}{IEEE Transactions on Industrial Informatics}
\field{month}{5}
\field{note}{Conference Name: IEEE Transactions on Industrial Informatics}
\field{number}{2}
\field{shorttitle}{{RDDS}}
\field{title}{{RDDS}: {A} {Real}-{Time} {Data} {Distribution} {Service} for {Cyber}-{Physical} {Systems}}
\field{volume}{8}
\field{year}{2012}
\field{pages}{393\bibrangedash 405}
\range{pages}{13}
\verb{doi}
\verb 10.1109/TII.2012.2183878
\endverb
\keyw{Computational modeling,Cyber-physical systems (CPS),Data models,Load modeling,Predictive models,Quality of service,Real time systems,Reliability,data distribution,feedback control,publish/subscribe,real-time systems}
\endentry
\entry{kugele_data-centric_2018}{inproceedings}{}
\name{author}{3}{}{%
{{hash=1c71b83b2bf684d53121bd62944c6683}{%
family={Kugele},
familyi={K\bibinitperiod},
given={S.},
giveni={S\bibinitperiod}}}%
{{hash=5ec0100fe3ffdd9aba93e2144f3b004e}{%
family={Hettler},
familyi={H\bibinitperiod},
given={D.},
giveni={D\bibinitperiod}}}%
{{hash=818fbbd52af88743f41f0be030abc80c}{%
family={Peter},
familyi={P\bibinitperiod},
given={J.},
giveni={J\bibinitperiod}}}%
}
\strng{namehash}{4f0a7fa856df99b143190befb7f5362e}
\strng{fullhash}{bc3df9b64c247d2387fbe677c901b899}
\strng{bibnamehash}{bc3df9b64c247d2387fbe677c901b899}
\strng{authorbibnamehash}{bc3df9b64c247d2387fbe677c901b899}
\strng{authornamehash}{4f0a7fa856df99b143190befb7f5362e}
\strng{authorfullhash}{bc3df9b64c247d2387fbe677c901b899}
\field{extraname}{1}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Context: The functional interconnection and data routing in today's automotive electric/electronic architectures has reached a level of complexity which is hardly manageable and error-prone. This circumstance severely hinders short times from development to operation. Aim: The purpose of the study is to evaluate the feasibility of Data Distribution Services in accord with containerization technologies in an agile development process for automotive software. Method: We propose to represent services by means of topics in a data-centric publish-subscribe approach. We conduct performance benchmarks to evaluate its aptitude and present a case study illustrating fail-operational behavior in a setup recreated from highly automated driving. Results: Backed by the results and the case study we show that containerized services, along with data-centric messaging, manage to meet most of our proposed requirements. We furthermore reveal limitations of the used technology stack and discuss remedies to their shortcomings.}
\field{booktitle}{2018 {IEEE} {International} {Conference} on {Software} {Architecture} ({ICSA})}
\field{month}{4}
\field{title}{Data-{Centric} {Communication} and {Containerization} for {Future} {Automotive} {Software} {Architectures}}
\field{year}{2018}
\field{pages}{65\bibrangedash 6509}
\range{pages}{6445}
\endentry
\entry{kugele_service-orientation_2017}{inproceedings}{}
\name{author}{6}{}{%
{{hash=1c71b83b2bf684d53121bd62944c6683}{%
family={Kugele},
familyi={K\bibinitperiod},
given={S.},
giveni={S\bibinitperiod}}}%
{{hash=7663498f77fc8b68b2284c49f66bbc20}{%
family={Obergfell},
familyi={O\bibinitperiod},
given={P.},
giveni={P\bibinitperiod}}}%
{{hash=0400f839708a73aa92c6272e59618270}{%
family={Broy},
familyi={B\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=92f61cf3cde711a00fdb2079dfc96af3}{%
family={Creighton},
familyi={C\bibinitperiod},
given={O.},
giveni={O\bibinitperiod}}}%
{{hash=af2014517c1b327150ec39bdf501b581}{%
family={Traub},
familyi={T\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=e25650a4daccf2f5b9444848ddef50a4}{%
family={Hopfensitz},
familyi={H\bibinitperiod},
given={W.},
giveni={W\bibinitperiod}}}%
}
\strng{namehash}{4f0a7fa856df99b143190befb7f5362e}
\strng{fullhash}{cc17e5f33bf49ceecaa5bd456ea6768d}
\strng{bibnamehash}{cc17e5f33bf49ceecaa5bd456ea6768d}
\strng{authorbibnamehash}{cc17e5f33bf49ceecaa5bd456ea6768d}
\strng{authornamehash}{4f0a7fa856df99b143190befb7f5362e}
\strng{authorfullhash}{cc17e5f33bf49ceecaa5bd456ea6768d}
\field{extraname}{2}
\field{sortinit}{K}
\field{sortinithash}{c02bf6bff1c488450c352b40f5d853ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Background: During the last decades, the functional power and complexity of automotive E/E architectures grew radically and is going to grow further in the future. For highly and fully automated driving, functions with the highest safety integrity level need to be realized, requiring new development methodologies and a new level of formal rigor. Aim: We investigate to what extent SOA concepts are applicable for safety-critical embedded automotive software systems and whether this concept is appealing to E/E architects. Method: We conducted a survey research by interviewing system architects at our industrial partner, then we applied the grounded theory method in order to derive a theory and a set of requirements for an automotive SOA approach. Additionally, we illustrate the approach using a function needed in a highly automated driving scenario. Results: We present a formal service model and an automotive SOA framework. Both aspects, i.e., architecture structuring and formal service description resulted from the analyzed interview data. Limitation: This approach has not been evaluated extensively, yet. Conclusion: Our first results suggest that SOA concepts are indeed successfully applicable in (continuous) automotive software engineering and are a means to cope with complexity and safety requirements.}
\field{booktitle}{2017 {IEEE} {International} {Conference} on {Software} {Architecture} ({ICSA})}
\field{month}{4}
\field{title}{On {Service}-{Orientation} for {Automotive} {Software}}
\field{year}{2017}
\field{pages}{193\bibrangedash 202}
\range{pages}{10}
\endentry
\entry{liu_impact_2022}{article}{}
\name{author}{3}{}{%
{{hash=5a287414a8761bc49ac2eae801bea554}{%
family={Liu},
familyi={L\bibinitperiod},
given={Zongwei},
giveni={Z\bibinitperiod}}}%
{{hash=3ebb2d48ecc6d5188d0f3e0707376c52}{%
family={Zhang},
familyi={Z\bibinitperiod},
given={Wang},
giveni={W\bibinitperiod}}}%
{{hash=8b5cc8444abf349d37ff62d28b9250e3}{%
family={Zhao},
familyi={Z\bibinitperiod},
given={Fuquan},
giveni={F\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{989cb8e2bb771f6ca31d1ce380e1d7f9}
\strng{fullhash}{29dd94f25b70a14849d768954aaa0e7c}
\strng{bibnamehash}{29dd94f25b70a14849d768954aaa0e7c}
\strng{authorbibnamehash}{29dd94f25b70a14849d768954aaa0e7c}
\strng{authornamehash}{989cb8e2bb771f6ca31d1ce380e1d7f9}
\strng{authorfullhash}{29dd94f25b70a14849d768954aaa0e7c}
\field{sortinit}{L}
\field{sortinithash}{7c47d417cecb1f4bd38d1825c427a61a}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Software-defined vehicles have been attracting increasing attentions owing to their impacts on the ecosystem of the automotive industry in terms of technologies, products, services and enterprise coopetition. Starting from the technology improvements of software-defined vehicles, this study systematically combs the impact of software-defined vehicles on the value ecology of automotive products and the automotive industrial pattern. Then, based on the current situation and demand of industrial development, the main challenges hindering the realization of software-defined vehicles are identified, including that traditional research and development models cannot adapt to the iterative demand of new automotive products; the transformation of enterprise capability faces multiple challenges; and many contradictions exist in the industrial division of labor. Finally, suggestions are put forward to address these challenges and provide decision-making recommendations for enterprises on strategy management.}
\field{issn}{2522-8765}
\field{journaltitle}{Automotive Innovation}
\field{month}{4}
\field{number}{2}
\field{title}{Impact, {Challenges} and {Prospect} of {Software}-{Defined} {Vehicles}}
\field{volume}{5}
\field{year}{2022}
\field{pages}{180\bibrangedash 194}
\range{pages}{15}
\verb{doi}
\verb 10.1007/s42154-022-00179-z
\endverb
\keyw{Automotive Engineering,Automotive industry,Industrial reconstruction,Software-defined vehicle,Strategic suggestions}
\endentry
\entry{macenski_robot_2022}{article}{}
\name{author}{5}{}{%
{{hash=32de857faf63cd1f724ac8acd558e91b}{%
family={Macenski},
familyi={M\bibinitperiod},
given={Steve},
giveni={S\bibinitperiod}}}%
{{hash=0d11ace6e44e4742ea1692d7ddf4819e}{%
family={Foote},
familyi={F\bibinitperiod},
given={Tully},
giveni={T\bibinitperiod}}}%
{{hash=a8ad4a5f43253f69552460c946e34e49}{%
family={Gerkey},
familyi={G\bibinitperiod},
given={Brian},
giveni={B\bibinitperiod}}}%
{{hash=4e2c9f9d04cf548117105f50a9c8a7a1}{%
family={Lalancette},
familyi={L\bibinitperiod},
given={Chris},
giveni={C\bibinitperiod}}}%
{{hash=fe838d86b89f8983167a3747e11998bb}{%
family={Woodall},
familyi={W\bibinitperiod},
given={William},
giveni={W\bibinitperiod}}}%
}
\strng{namehash}{7e50f9da548a8963dec23dce06a35fa9}
\strng{fullhash}{7b3b62b95c889ecc76be786bf4c55f2c}
\strng{bibnamehash}{7b3b62b95c889ecc76be786bf4c55f2c}
\strng{authorbibnamehash}{7b3b62b95c889ecc76be786bf4c55f2c}
\strng{authornamehash}{7e50f9da548a8963dec23dce06a35fa9}
\strng{authorfullhash}{7b3b62b95c889ecc76be786bf4c55f2c}
\field{extraname}{1}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The next chapter of the robotics revolution is well underway with the deployment of robots for a broad range of commercial use-cases. Even in a myriad of applications and environments, there exists a common vocabulary of components that robots share - the need for a modular, scalable, and reliable architecture; sensing; planning; mobility; and autonomy. The Robot Operating System (ROS) was an integral part of the last chapter, demonstrably expediting robotics research with freely-available components and a modular framework. However, ROS 1 was not designed with many necessary production-grade features and algorithms. ROS 2 and its related projects have been redesigned from the ground up to meet the challenges set forth by modern robotic systems in new and exploratory domains at all scales. In this review, we highlight the philosophical and architectural changes of ROS 2 powering this new chapter in the robotics revolution. We also show through case studies the influence ROS 2 and its adoption has had on accelerating real robot systems to reliable deployment in an assortment of challenging environments.}
\field{journaltitle}{Science Robotics}
\field{month}{5}
\field{number}{66}
\field{title}{Robot {Operating} {System} 2: {Design}, {Architecture}, and {Uses} {In} {The} {Wild}}
\field{volume}{7}
\field{year}{2022}
\keyw{Computer Science - Robotics}
\endentry
\entry{macenski_impact_2023}{misc}{}
\name{author}{4}{}{%
{{hash=32de857faf63cd1f724ac8acd558e91b}{%
family={Macenski},
familyi={M\bibinitperiod},
given={Steve},
giveni={S\bibinitperiod}}}%
{{hash=9c1719794cacc820c4ec360f90eff730}{%
family={Soragna},
familyi={S\bibinitperiod},
given={Alberto},
giveni={A\bibinitperiod}}}%
{{hash=5f05202cd0f73c798a49b697c4184200}{%
family={Carroll},
familyi={C\bibinitperiod},
given={Michael},
giveni={M\bibinitperiod}}}%
{{hash=0c7cbc686f30144c4e3a9ad83c046e66}{%
family={Ge},
familyi={G\bibinitperiod},
given={Zhenpeng},
giveni={Z\bibinitperiod}}}%
}
\list{publisher}{1}{%
{arXiv}%
}
\strng{namehash}{7e50f9da548a8963dec23dce06a35fa9}
\strng{fullhash}{46522130c15d5ed8e49f20d4fd41f17e}
\strng{bibnamehash}{46522130c15d5ed8e49f20d4fd41f17e}
\strng{authorbibnamehash}{46522130c15d5ed8e49f20d4fd41f17e}
\strng{authornamehash}{7e50f9da548a8963dec23dce06a35fa9}
\strng{authorfullhash}{46522130c15d5ed8e49f20d4fd41f17e}
\field{extraname}{2}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The Robot Operating System 2 (ROS 2) is the second generation of ROS representing a step forward in the robotic framework. Several new types of nodes and executor models are integral to control where, how, and when information is processed in the computational graph. This paper explores and benchmarks one of these new node types -- the Component node -- which allows nodes to be composed manually or dynamically into processes while retaining separation of concerns in a codebase for distributed development. Composition is shown to achieve a high degree of performance optimization, particularly valuable for resource-constrained systems and sensor processing pipelines, enabling distributed tasks that would not be otherwise possible in ROS 2. In this work, we briefly introduce the significance and design of node composition, then our contribution of benchmarking is provided to analyze its impact on robotic systems. Its compelling influence on performance is shown through several experiments on the latest Long Term Support (LTS) ROS 2 distribution, Humble Hawksbill.}
\field{month}{5}
\field{note}{arXiv:2305.09933 [cs]}
\field{title}{Impact of {ROS} 2 {Node} {Composition} in {Robotic} {Systems}}
\field{year}{2023}
\keyw{Computer Science - Robotics}
\endentry
\entry{malavolta_how_2020}{inproceedings}{}
\name{author}{5}{}{%
{{hash=3ff6e286502b85077eabb7e86849d893}{%
family={Malavolta},
familyi={M\bibinitperiod},
given={Ivano},
giveni={I\bibinitperiod}}}%
{{hash=05e1443845ae61ddc5d27b0835d2fbca}{%
family={Lewis},
familyi={L\bibinitperiod},
given={Grace},
giveni={G\bibinitperiod}}}%
{{hash=41f94f4724ea60cb50a571ff628e27e5}{%
family={Schmerl},
familyi={S\bibinitperiod},
given={Bradley},
giveni={B\bibinitperiod}}}%
{{hash=b7e3fc29bccdf8a7639daddb302e1545}{%
family={Lago},
familyi={L\bibinitperiod},
given={Patricia},
giveni={P\bibinitperiod}}}%
{{hash=5e93a0537dc9db010915acd5407760d4}{%
family={Garlan},
familyi={G\bibinitperiod},
given={David},
giveni={D\bibinitperiod}}}%
}
\list{location}{1}{%
{New York, NY, USA}%
}
\list{publisher}{1}{%
{Association for Computing Machinery}%
}
\strng{namehash}{1096fd05c40e62e2a93cb6931d5228de}
\strng{fullhash}{0f15d24eee36ba6a27e77dce9574b8d9}
\strng{bibnamehash}{0f15d24eee36ba6a27e77dce9574b8d9}
\strng{authorbibnamehash}{0f15d24eee36ba6a27e77dce9574b8d9}
\strng{authornamehash}{1096fd05c40e62e2a93cb6931d5228de}
\strng{authorfullhash}{0f15d24eee36ba6a27e77dce9574b8d9}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The Robot Operating System (ROS) is the de-facto standard for robotic software. If on one hand ROS is helping roboticists, e.g., by providing a standardized communication platform, on the other hand ROS-based systems are getting larger and more complex and could benefit from good software architecture practices. This paper presents an observational study aimed at (i) unveiling the state-of-the-practice for architecting ROS-based systems and (ii) providing guidance to roboticists about how to properly architect ROS-based systems. To achieve these goals, we (i) build a dataset of 335 GitHub repositories containing real open-source ROS-based systems, (ii) mine the repositories for extracting the state of the practice about how roboticists are architecting them, and (iii) synthesize a catalog of 49 evidence-based guidelines for architecting ROS-based systems. The guidelines have been validated by 77 roboticists working on real-world open-source ROS-based systems.}
\field{booktitle}{Proceedings of the {ACM}/{IEEE} 42nd {International} {Conference} on {Software} {Engineering}: {Software} {Engineering} in {Practice}}
\field{month}{9}
\field{series}{{ICSE}-{SEIP} '20}
\field{title}{How do you architect your robots? state of the practice and guidelines for {ROS}-based systems}
\field{year}{2020}
\field{pages}{31\bibrangedash 40}
\range{pages}{10}
\endentry
\entry{menard_achieving_2020}{inproceedings}{}
\name{author}{4}{}{%
{{hash=c5a23baf9b4efd883ad42c0f2a56f530}{%
family={Menard},
familyi={M\bibinitperiod},
given={Christian},
giveni={C\bibinitperiod}}}%
{{hash=c45fd585e9ef162b6c78ec16c4f2bd92}{%
family={Goens},
familyi={G\bibinitperiod},
given={Andrés},
giveni={A\bibinitperiod}}}%
{{hash=db49ff8b8a04fe3b79c8bae156343a28}{%
family={Lohstroh},
familyi={L\bibinitperiod},
given={Marten},
giveni={M\bibinitperiod}}}%
{{hash=1772ffd954e9048e847fa2ff046f2e8c}{%
family={Castrillon},
familyi={C\bibinitperiod},
given={Jeronimo},
giveni={J\bibinitperiod}}}%
}
\strng{namehash}{7d5b49899218fd895e2e3a410bd1f18f}
\strng{fullhash}{ddc0985a4a616b2508642d18a0047b60}
\strng{bibnamehash}{ddc0985a4a616b2508642d18a0047b60}
\strng{authorbibnamehash}{ddc0985a4a616b2508642d18a0047b60}
\strng{authornamehash}{7d5b49899218fd895e2e3a410bd1f18f}
\strng{authorfullhash}{ddc0985a4a616b2508642d18a0047b60}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{AUTOSAR Adaptive Platform (AP) is an emerging industry standard that tackles the challenges of modern auto-motive software design, but does not provide adequate mechanisms to enforce deterministic execution. This poses profound challenges to testing and maintenance of the application software, which is particularly problematic for safety-critical applications. In this paper, we analyze the problem of nondeterminism in AP and propose a framework for the design of deterministic automotive software that transparently integrates with the AP communication mechanisms. We illustrate our approach in a case study based on the brake assistant demonstrator application that is provided by the AUTOSAR consortium. We show that the original implementation is nondeterministic and discuss a deterministic solution based on our framework.}
\field{booktitle}{2020 {Design}, {Automation} {Test} in {Europe} {Conference} {Exhibition} ({DATE})}
\field{month}{3}
\field{title}{Achieving {Determinism} in {Adaptive} {AUTOSAR}}
\field{year}{2020}
\field{pages}{822\bibrangedash 827}
\range{pages}{6}
\endentry
\entry{migge_insights_2018}{inproceedings}{}
\name{author}{4}{}{%
{{hash=7307f8ebe3a459187d5609fb1652be76}{%
family={Migge},
familyi={M\bibinitperiod},
given={J.},
giveni={J\bibinitperiod}}}%
{{hash=7604eabbeb521bdd53a0d9686049a72f}{%
family={Villanueva},
familyi={V\bibinitperiod},
given={Josetxo},
giveni={J\bibinitperiod}}}%
{{hash=7505ea19163a8191fe981ccec1a55c03}{%
family={Navet},
familyi={N\bibinitperiod},
given={N.},
giveni={N\bibinitperiod}}}%
{{hash=de04a9ac2585f99d0353d028150e656c}{%
family={Boyer},
familyi={B\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
}
\strng{namehash}{0a07a92f82976bec35599d7cef21f526}
\strng{fullhash}{b908086b2fd471d0155766c3a8c76b80}
\strng{bibnamehash}{b908086b2fd471d0155766c3a8c76b80}
\strng{authorbibnamehash}{b908086b2fd471d0155766c3a8c76b80}
\strng{authornamehash}{0a07a92f82976bec35599d7cef21f526}
\strng{authorfullhash}{b908086b2fd471d0155766c3a8c76b80}
\field{sortinit}{M}
\field{sortinithash}{4625c616857f13d17ce56f7d4f97d451}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Switched Ethernet is profoundly reshaping in-car communications. To meet the diverse real-time requirements in automotive communications, Quality-of-Service protocols that go beyond the mere use of priorities are required. In this work, the basic questions that we study on a case-study with diverse and demanding communication requirements is what can we expect from the various protocols aimed at providing a better timing Quality of Service on top of Ethernet? And how to use them? Especially how to use them in a combined manner. We will focus on the Credit-Based Shaper of AVB, the Time-Aware Shaper of TSN and the use of priorities as defined in IEEE802.1Q. The performance metrics considered are the distributions of the communication latencies, obtained by simulation, as well as upper bounds on these quantities obtained by worst-case schedulability analysis. If there have been over the last 5 years numerous studies on the performance of AVB CBS, the literature on comparing AVB to TSN and other candidate protocols is still sparse. To the best of our knowledge, this empirical study is the first to consider most protocols currently considered in the automotive domain, with the aim to gain insights into the different technological, design and configurations alternatives. In particular, an objective of this study is to identify key problems that need to be solved in order to further automate network design and configuration.}
\field{month}{2}
\field{title}{Insights on the {Performance} and {Configuration} of {AVB} and {TSN} in {Automotive} {Ethernet} {Networks}}
\field{urlday}{19}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2018}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://www.semanticscholar.org/paper/Insights-on-the-Performance-and-Configuration-of-in-Migge-Villanueva/ca961a75d95ac2a74aaf67a5c0d53a2348c1813c
\endverb
\verb{url}
\verb https://www.semanticscholar.org/paper/Insights-on-the-Performance-and-Configuration-of-in-Migge-Villanueva/ca961a75d95ac2a74aaf67a5c0d53a2348c1813c
\endverb
\endentry
\entry{nayak_automotive_2023}{inproceedings}{}
\name{author}{3}{}{%
{{hash=ef1a1b566af7e9c20e35928f29fcd845}{%
family={Nayak},
familyi={N\bibinitperiod},
given={Naresh},
giveni={N\bibinitperiod}}}%
{{hash=aba85a7524a58f8069268d11932d17fc}{%
family={Grewe},
familyi={G\bibinitperiod},
given={Dennis},
giveni={D\bibinitperiod}}}%
{{hash=b625349b3a52b2b3650c7642e2f11263}{%
family={Schildt},
familyi={S\bibinitperiod},
given={Sebastian},
giveni={S\bibinitperiod}}}%
}
\strng{namehash}{583b90dd102313ca2bbd575f5baf1173}
\strng{fullhash}{856ea469c03962119a864851adc5465e}
\strng{bibnamehash}{856ea469c03962119a864851adc5465e}
\strng{authorbibnamehash}{856ea469c03962119a864851adc5465e}
\strng{authornamehash}{583b90dd102313ca2bbd575f5baf1173}
\strng{authorfullhash}{856ea469c03962119a864851adc5465e}
\field{sortinit}{N}
\field{sortinithash}{22369a73d5f88983a108b63f07f37084}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{2023 {IEEE} {Vehicular} {Networking} {Conference} ({VNC})}
\field{month}{4}
\field{title}{Automotive {Container} {Orchestration}: {Requirements}, {Challenges} and {Open} {Directions}}
\field{year}{2023}
\field{pages}{61\bibrangedash 64}
\range{pages}{4}
\endentry
\entry{neely_adaptive_2006}{article}{}
\name{author}{3}{}{%
{{hash=561c428625ca71cade4f0627d1911e7b}{%
family={Neely},
familyi={N\bibinitperiod},
given={Steve},
giveni={S\bibinitperiod}}}%
{{hash=ea6b3d4be7bf520ce5917a6b43a1589e}{%
family={Dobson},
familyi={D\bibinitperiod},
given={Simon},
giveni={S\bibinitperiod}}}%
{{hash=6fb1b3c98429342e296eae06a35ca8f3}{%
family={Nixon},
familyi={N\bibinitperiod},
given={Paddy},
giveni={P\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{07f5132aaa582eee56500ff9d2bc1563}
\strng{fullhash}{6076522d298134345e0118ecd3ef91c5}
\strng{bibnamehash}{6076522d298134345e0118ecd3ef91c5}
\strng{authorbibnamehash}{6076522d298134345e0118ecd3ef91c5}
\strng{authornamehash}{07f5132aaa582eee56500ff9d2bc1563}
\strng{authorfullhash}{6076522d298134345e0118ecd3ef91c5}
\field{sortinit}{N}
\field{sortinithash}{22369a73d5f88983a108b63f07f37084}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The increasingly dynamic nature of resource discovery and binding in modern large-scale distributed and mobile systems poses significant challenges for existing middleware platforms. Future platforms must provide strong support for adaptive behaviour in order both to maintain and optimise services in the face of changing context. We use a survey of existing middleware systems to develop some core themes that characterise and constrain the ability of these approaches to support the development of adaptive and autonomic systems, and draw some possible trends for developing future platforms more appropriate to these domains.}
\field{issn}{1958-9395}
\field{journaltitle}{Annales Des Télécommunications}
\field{month}{10}
\field{number}{9}
\field{title}{Adaptive middleware for autonomic systems}
\field{volume}{61}
\field{year}{2006}
\field{pages}{1099\bibrangedash 1118}
\range{pages}{20}
\verb{doi}
\verb 10.1007/BF03219883
\endverb
\keyw{Adaptive system,Architecture système,Autonomous system,Communication égal à égal,Corba,Logiciel médiateur,Middleware,Méthode orientée objet,Object oriented method,Peer to peer communication,System architecture,Système adaptatif,Système autonome}
\endentry
\entry{open_robotics_executors_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{1}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Executors — ROS 2 Documentation: Iron documentation}
\field{title}{Executors — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Intermediate/About-Executors.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Intermediate/About-Executors.html
\endverb
\endentry
\entry{open_robotics_installation_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{2}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Installation — ROS 2 Documentation: Iron documentation}
\field{title}{Installation — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{4}
\field{urlmonth}{6}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Installation.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Installation.html
\endverb
\endentry
\entry{open_robotics_interfaces_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{3}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Interfaces — ROS 2 Documentation: Iron documentation}
\field{title}{Interfaces — {ROS} 2 {Documentation}: {Iron} documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Interfaces.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Interfaces.html
\endverb
\endentry
\entry{open_robotics_launch_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{4}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Launch — ROS 2 Documentation: Iron documentation}
\field{title}{Launch — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Launch.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Launch.html
\endverb
\endentry
\entry{open_robotics_nodes_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{5}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{title}{Nodes — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Nodes.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Nodes.html
\endverb
\endentry
\entry{open_robotics_parameters_nodate}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{6}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Parameters — ROS 2 Documentation: Iron documentation}
\field{title}{Parameters — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{26}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Parameters.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Basic/About-Parameters.html
\endverb
\endentry
\entry{open_robotics_quality_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{7}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{Quality of Service settings — ROS 2 Documentation: Iron documentation}
\field{title}{Quality of {Service} settings — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Intermediate/About-Quality-of-Service-Settings.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Intermediate/About-Quality-of-Service-Settings.html
\endverb
\endentry
\entry{open_robotics_ros_2024}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{8}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{journaltitle}{ROS 2 Security — ROS 2 Documentation: Iron documentation}
\field{title}{{ROS} 2 {Security} — {ROS} 2 {Documentation}: {Iron} documentation}
\field{type}{Documentation}
\field{urlday}{27}
\field{urlmonth}{3}
\field{urlyear}{2024}
\field{year}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/iron/Concepts/Intermediate/About-Security.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/iron/Concepts/Intermediate/About-Security.html
\endverb
\endentry
\entry{open_robotics_setting_nodate}{misc}{}
\name{author}{1}{}{%
{{hash=6d2ee5676b068857db569005a9c6205a}{%
family={{Open Robotics}},
familyi={O\bibinitperiod}}}%
}
\strng{namehash}{6d2ee5676b068857db569005a9c6205a}
\strng{fullhash}{6d2ee5676b068857db569005a9c6205a}
\strng{bibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorbibnamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authornamehash}{6d2ee5676b068857db569005a9c6205a}
\strng{authorfullhash}{6d2ee5676b068857db569005a9c6205a}
\field{extraname}{9}
\field{sortinit}{O}
\field{sortinithash}{2cd7140a07aea5341f9e2771efe90aae}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{title}{Setting up security — {ROS} 2 {Documentation}: {Rolling} documentation}
\field{urlday}{4}
\field{urlmonth}{11}
\field{urlyear}{2024}
\field{urldateera}{ce}
\verb{urlraw}
\verb https://docs.ros.org/en/rolling/Tutorials/Advanced/Security/Introducing-ros2-security.html
\endverb
\verb{url}
\verb https://docs.ros.org/en/rolling/Tutorials/Advanced/Security/Introducing-ros2-security.html
\endverb
\endentry
\entry{perera_context_2014}{article}{}
\name{author}{4}{}{%
{{hash=e5b420aba58a8d93cbbcaf2b1b0f4dab}{%
family={Perera},
familyi={P\bibinitperiod},
given={Charith},
giveni={C\bibinitperiod}}}%
{{hash=8da289bb46b6a95f52ced670c23af820}{%
family={Zaslavsky},
familyi={Z\bibinitperiod},
given={Arkady},
giveni={A\bibinitperiod}}}%
{{hash=2df88d211fd24d931ebe3bf0dd661f93}{%
family={Christen},
familyi={C\bibinitperiod},
given={Peter},
giveni={P\bibinitperiod}}}%
{{hash=25d9d97c240056793c5abcc6aee6a4d0}{%
family={Georgakopoulos},
familyi={G\bibinitperiod},
given={Dimitrios},
giveni={D\bibinitperiod}}}%
}
\strng{namehash}{3a7a2ea57f7c4872eb630a5e4ed238a4}
\strng{fullhash}{1d0a19f39e61587e4ba4540433e37ea0}
\strng{bibnamehash}{1d0a19f39e61587e4ba4540433e37ea0}
\strng{authorbibnamehash}{1d0a19f39e61587e4ba4540433e37ea0}
\strng{authornamehash}{3a7a2ea57f7c4872eb630a5e4ed238a4}
\strng{authorfullhash}{1d0a19f39e61587e4ba4540433e37ea0}
\field{sortinit}{P}
\field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{As we are moving towards the Internet of Things (IoT), the number of sensors deployed around the world is growing at a rapid pace. Market research has shown a significant growth of sensor deployments over the past decade and has predicted a significant increment of the growth rate in the future. These sensors continuously generate enormous amounts of data. However, in order to add value to raw sensor data we need to understand it. Collection, modelling, reasoning, and distribution of context in relation to sensor data plays critical role in this challenge. Context-aware computing has proven to be successful in understanding sensor data. In this paper, we survey context awareness from an IoT perspective. We present the necessary background by introducing the IoT paradigm and context-aware fundamentals at the beginning. Then we provide an in-depth analysis of context life cycle. We evaluate a subset of projects (50) which represent the majority of research and commercial solutions proposed in the field of context-aware computing conducted over the last decade (2001-2011) based on our own taxonomy. Finally, based on our evaluation, we highlight the lessons to be learnt from the past and some possible directions for future research. The survey addresses a broad range of techniques, methods, models, functionalities, systems, applications, and middleware solutions related to context awareness and IoT. Our goal is not only to analyse, compare and consolidate past research work but also to appreciate their findings and discuss their applicability towards the IoT.}
\field{issn}{1553-877X}
\field{journaltitle}{IEEE Communications Surveys \& Tutorials}
\field{note}{Conference Name: IEEE Communications Surveys \& Tutorials}
\field{number}{1}
\field{shorttitle}{Context {Aware} {Computing} for {The} {Internet} of {Things}}
\field{title}{Context {Aware} {Computing} for {The} {Internet} of {Things}: {A} {Survey}}
\field{volume}{16}
\field{year}{2014}
\field{pages}{414\bibrangedash 454}
\range{pages}{41}
\verb{doi}
\verb 10.1109/SURV.2013.042313.00197
\endverb
\keyw{Context,Context-aware services,Internet of Things,Internet of things,Middleware,Sensors,Wireless sensor networks,context awareness,context life cycle,context modelling,context reasoning,middleware,mobile,pervasive,sensor data,sensor networks,to read,ubiquitous}
\endentry
\entry{pullen_security_2023}{article}{}
\name{author}{5}{}{%
{{hash=420ab80b88aacb3b4f32013a2bfe836c}{%
family={Püllen},
familyi={P\bibinitperiod},
given={Dominik},
giveni={D\bibinitperiod}}}%
{{hash=ef1b5f560a736b3749d8413b54d01966}{%
family={Frank},
familyi={F\bibinitperiod},
given={Florian},
giveni={F\bibinitperiod}}}%
{{hash=5e89e3418eea875226b2e99bd864d40f}{%
family={Christl},
familyi={C\bibinitperiod},
given={Marion},
giveni={M\bibinitperiod}}}%
{{hash=9328f039add43c0be34786088f6c167e}{%
family={Liu},
familyi={L\bibinitperiod},
given={Wuhao},
giveni={W\bibinitperiod}}}%
{{hash=b9e502f041dbf3b5d3c907a9d726cf59}{%
family={Katzenbeisser},
familyi={K\bibinitperiod},
given={Stefan},
giveni={S\bibinitperiod}}}%
}
\strng{namehash}{a21955985cdb8be8f62d255d8bade5a3}
\strng{fullhash}{24856be6d2ec1f8a618ae7f58f5cba50}
\strng{bibnamehash}{24856be6d2ec1f8a618ae7f58f5cba50}
\strng{authorbibnamehash}{24856be6d2ec1f8a618ae7f58f5cba50}
\strng{authornamehash}{a21955985cdb8be8f62d255d8bade5a3}
\strng{authorfullhash}{24856be6d2ec1f8a618ae7f58f5cba50}
\field{sortinit}{P}
\field{sortinithash}{ff3bcf24f47321b42cb156c2cc8a8422}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The Automotive Service-Oriented software Architecture (ASOA) is a framework for the effective design, fast deployment, and efficient maintenance of automotive software architectures, facilitating reliable communication among loosely coupled services. It maintains a global view of functional units, allowing them to be updated, replaced, and reconnected so that road vehicles obtain or lose capabilities. While the ASOA lives up to expectations regarding reliability and real-time behavior, it lacks a security concept and, therefore, cannot be safely deployed in automotive systems. This work presents a security process to protect ASOA-based communication from compromise and prevent passenger harm. We propose annotating dataflows with security attributes in a web-based architecture design tool and introducing a central component responsible for converting the communication model into tokens securely distributed to ASOA services. They enable secure communication among components while preserving the desired loose coupling, a critical factor for cost-effective system maintainability. Moreover, we support shielded and technically constrained devices in a heterogeneous domain or zonal vehicle network. After formally verifying our token distribution protocol, we evaluate our security process in a self-driving vehicle and prove that it imposes only negligible overhead during operation.}
\field{journaltitle}{IEEE Transactions on Vehicular Technology}
\field{title}{A {Security} {Process} for the {Automotive} {Service}-{Oriented} {Software} {Architecture}}
\field{year}{2023}
\field{pages}{1\bibrangedash 16}
\range{pages}{16}
\endentry
\entry{reichart_progress_2021}{inproceedings}{}
\name{author}{2}{}{%
{{hash=c331f80cb755082924deaf197ee1342f}{%
family={Reichart},
familyi={R\bibinitperiod},
given={Günter},
giveni={G\bibinitperiod}}}%
{{hash=a5af3d147df441c3864752e5e3bd0acf}{%
family={Asmus},
familyi={A\bibinitperiod},
given={Rinat},
giveni={R\bibinitperiod}}}%
}
\name{editor}{1}{}{%
{{hash=802ba9269c0073c577b138e7404347cd}{%
family={Bertram},
familyi={B\bibinitperiod},
given={Torsten},
giveni={T\bibinitperiod}}}%
}
\list{language}{1}{%
{de}%
}
\strng{namehash}{036a3376284097ff971f5a0b6c4569ca}
\strng{fullhash}{759d978cea658833a89c339e667fd49d}
\strng{bibnamehash}{759d978cea658833a89c339e667fd49d}
\strng{authorbibnamehash}{759d978cea658833a89c339e667fd49d}
\strng{authornamehash}{036a3376284097ff971f5a0b6c4569ca}
\strng{authorfullhash}{759d978cea658833a89c339e667fd49d}
\strng{editorbibnamehash}{802ba9269c0073c577b138e7404347cd}
\strng{editornamehash}{802ba9269c0073c577b138e7404347cd}
\strng{editorfullhash}{802ba9269c0073c577b138e7404347cd}
\field{sortinit}{R}
\field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The AUTOSAR community has grown to over 280 partner companies since the first AUTOSAR Classic Platform specification was released more than twelve years ago. Based on the well-established high-quality standards, mature processes and strong communication channels inside this organization, AUTOSAR has been developing a completely new approach to cope with the challenging market trends in the automotive industry such as internet access in cars, highly automated driving and vehicle to vehicle communication. The result of these activities is an intelligent and flexible software infrastructure which therefore is named AUTOSAR Adaptive Platform. The software platform runs on high-end computing hardware and supports parallel processing on many core systems and GPUs. Since AUTOSAR has its roots in the automotive field, the partnership’s prioritization of safety and security features is as self-evident as the compatibility to systems based on the AUTOSAR Classic Platform. A suitable software framework for safe and secure applications is now available.}
\field{booktitle}{Automatisiertes {Fahren} 2020}
\field{series}{Proceedings}
\field{title}{Progress on the {AUTOSAR} {Adaptive} {Platform} for {Intelligent} {Vehicles}}
\field{year}{2021}
\field{pages}{67\bibrangedash 75}
\range{pages}{9}
\verb{doi}
\verb 10.1007/978-3-658-34752-9_6
\endverb
\endentry
\entry{rotermund_requirements_2020}{inproceedings}{}
\name{author}{5}{}{%
{{hash=9264b906b471c0004091cd704aea1bdd}{%
family={Rotermund},
familyi={R\bibinitperiod},
given={Randolf},
giveni={R\bibinitperiod}}}%
{{hash=7d5244e13d35b4779475faae95c4a804}{%
family={Häckel},
familyi={H\bibinitperiod},
given={Timo},
giveni={T\bibinitperiod}}}%
{{hash=7e1797520731ac393c1c4744f26517d5}{%
family={Meyer},
familyi={M\bibinitperiod},
given={Philipp},
giveni={P\bibinitperiod}}}%
{{hash=bbfff937ccfb8e2eddbd84e0baff8880}{%
family={Korf},
familyi={K\bibinitperiod},
given={Franz},
giveni={F\bibinitperiod}}}%
{{hash=c834dc8a5cb0646371794a22957a5130}{%
family={Schmidt},
familyi={S\bibinitperiod},
given={Thomas\bibnamedelima C.},
giveni={T\bibinitperiod\bibinitdelim C\bibinitperiod}}}%
}
\strng{namehash}{9cae365a0b68062babe84745d5acdf42}
\strng{fullhash}{b08b37d5de3a96a4061dd586d724ace0}
\strng{bibnamehash}{b08b37d5de3a96a4061dd586d724ace0}
\strng{authorbibnamehash}{b08b37d5de3a96a4061dd586d724ace0}
\strng{authornamehash}{9cae365a0b68062babe84745d5acdf42}
\strng{authorfullhash}{b08b37d5de3a96a4061dd586d724ace0}
\field{sortinit}{R}
\field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Future vehicles will be more connected than ever leading to increased dynamics in vehicle on-board networks. Software-Defined Networking (SDN) is a promising technology to meet the emerging needs for flexibility and security in future automotive use cases. Although SDN controllers have been evaluated in data center networks, to the best of our knowledge there is a lack of an analysis and performance evaluation of SDN controllers for automotive use cases. In this work we provide a detailed requirements analysis for the use of SDN controllers in cars. Based on this requirements analysis we choose existing controller implementations for a performance analysis. Finally, we analyze automotive specific use cases for SDN controllers with controller application examples and show how these can fulfill additional requirements. Our evaluation provides a helpful basis for the design and development of SDN controllers that can be used in vehicles.}
\field{booktitle}{2020 {IEEE} {Vehicular} {Networking} {Conference} ({VNC})}
\field{month}{12}
\field{title}{Requirements {Analysis} and {Performance} {Evaluation} of {SDN} {Controllers} for {Automotive} {Use} {Cases}}
\field{year}{2020}
\field{pages}{1\bibrangedash 8}
\range{pages}{8}
\endentry
\entry{rumez_overview_2020}{article}{}
\name{author}{4}{}{%
{{hash=e2c39d30320d3b2a26fb29f656a4ebff}{%
family={Rumez},
familyi={R\bibinitperiod},
given={Marcel},
giveni={M\bibinitperiod}}}%
{{hash=fdd4d400e8fc9792ad73d30d044b75eb}{%
family={Grimm},
familyi={G\bibinitperiod},
given={Daniel},
giveni={D\bibinitperiod}}}%
{{hash=cb4227ad1625e038fb7be64acfec5ec4}{%
family={Kriesten},
familyi={K\bibinitperiod},
given={Reiner},
giveni={R\bibinitperiod}}}%
{{hash=f6edc406efe2f0b7f0ce15869e359764}{%
family={Sax},
familyi={S\bibinitperiod},
given={Eric},
giveni={E\bibinitperiod}}}%
}
\strng{namehash}{e23a98f72c979946f82edfe48f24a762}
\strng{fullhash}{1d21f06927fbd590cbb575e103a27a37}
\strng{bibnamehash}{1d21f06927fbd590cbb575e103a27a37}
\strng{authorbibnamehash}{1d21f06927fbd590cbb575e103a27a37}
\strng{authornamehash}{e23a98f72c979946f82edfe48f24a762}
\strng{authorfullhash}{1d21f06927fbd590cbb575e103a27a37}
\field{sortinit}{R}
\field{sortinithash}{5e1c39a9d46ffb6bebd8f801023a9486}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{New requirements from the customers' and manufacturers' point of view such as adding new software functions during the product life cycle require a transformed architecture design for future vehicles. The paradigm of signal-oriented communication established for many years will increasingly be replaced by service-oriented approaches in order to increase the update and upgrade capability. In this article, we provide an overview of current protocols and communication patterns for automotive architectures based on the service-oriented architecture (SOA) paradigm and compare them with signal-oriented approaches. Resulting challenges and opportunities of SOAs with respect to information security are outlined and discussed. For this purpose, we explain different security countermeasures and present a state of the section of automotive approaches in the fields of firewalls, Intrusion Detection Systems (IDSs) and Identity and Access Management (IAM). Our final discussion is based on an exemplary hybrid architecture (signal- and service-oriented) and examines the adaptation of existing security measures as well as their specific security features.}
\field{journaltitle}{IEEE Access}
\field{title}{An {Overview} of {Automotive} {Service}-{Oriented} {Architectures} and {Implications} for {Security} {Countermeasures}}
\field{volume}{8}
\field{year}{2020}
\field{pages}{221852\bibrangedash 221870}
\range{pages}{19}
\endentry
\entry{schlosser_considering_2024}{inproceedings}{}
\name{author}{2}{}{%
{{hash=c64104fe58d23e1038efb975b3805f44}{%
family={Schlosser},
familyi={S\bibinitperiod},
given={Joachim},
giveni={J\bibinitperiod}}}%
{{hash=f1064af1eb1813c03a8655e40cbdbd5a}{%
family={Petersohn},
familyi={P\bibinitperiod},
given={Jens},
giveni={J\bibinitperiod}}}%
}
\name{editor}{1}{}{%
{{hash=ced7d2148a08b309d308181f9a423603}{%
family={Heintzel},
familyi={H\bibinitperiod},
given={Alexander},
giveni={A\bibinitperiod}}}%
}
\list{language}{1}{%
{de}%
}
\list{location}{1}{%
{Wiesbaden}%
}
\list{publisher}{1}{%
{Springer Fachmedien}%
}
\strng{namehash}{5c428d56ba5e9a1f6f99aa36d9ee0ffd}
\strng{fullhash}{86ae93ae82163347165d5cd390c090f3}
\strng{bibnamehash}{86ae93ae82163347165d5cd390c090f3}
\strng{authorbibnamehash}{86ae93ae82163347165d5cd390c090f3}
\strng{authornamehash}{5c428d56ba5e9a1f6f99aa36d9ee0ffd}
\strng{authorfullhash}{86ae93ae82163347165d5cd390c090f3}
\strng{editorbibnamehash}{ced7d2148a08b309d308181f9a423603}
\strng{editornamehash}{ced7d2148a08b309d308181f9a423603}
\strng{editorfullhash}{ced7d2148a08b309d308181f9a423603}
\field{sortinit}{S}
\field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{Developing safety-critical software components incurs significantly higher costs compared to non-safety ones, urging an emphasis on minimizing their number and complexity, as per safety standards. While GNU/Linux offers a rich set of features, its original design lacks a safety-centric focus. Ensuring safety in Linux-based systems poses challenges due to the kernel's diverse interaction capabilities, requiring meticulous attention to safety requirements. Addressing safety starts with defining the technology device's intended function, encompassing user experience and essential services like device maintenance. Functional safety extends beyond individual components, necessitating systemwide consideration, even for “safety elements out of context.” Integrating safetyrelated and non-safety software demands careful design to prevent adverse impacts on safety modules. Proposed solutions must address functional safety, cybersecurity, and long-term maintenance obligations, essential for compliance with regulations. This talk explores architectural considerations and necessary precautions for leveraging GNU/Linux in safety applications, facilitating robust software systems that meet stringent safety standards.}
\field{booktitle}{Automatisiertes {Fahren} 2024}
\field{isbn}{978-3-658-45196-7}
\field{shorttitle}{Considering {Linux} for functional safety relevant system architecture}
\field{title}{Considering {Linux} for functional safety relevant system architecture: {Pitfalls} and {Potential}}
\field{year}{2024}
\field{pages}{149\bibrangedash 160}
\range{pages}{12}
\verb{doi}
\verb 10.1007/978-3-658-45196-7_12
\endverb
\keyw{GNU/Linux,Safety-related applications,functional safety}
\endentry
\entry{serban_adapting_2022}{inproceedings}{}
\name{author}{2}{}{%
{{hash=50c4bcf42a1901c19dce6e80a4eb08e4}{%
family={Serban},
familyi={S\bibinitperiod},
given={Alex},
giveni={A\bibinitperiod}}}%
{{hash=911dc764b805261ce617fe06d80754e3}{%
family={Visser},
familyi={V\bibinitperiod},
given={Joost},
giveni={J\bibinitperiod}}}%
}
\strng{namehash}{9243aa7e889a5f95bbea2b0309809845}
\strng{fullhash}{3ce08524779dc922c814e913cfe986b3}
\strng{bibnamehash}{3ce08524779dc922c814e913cfe986b3}
\strng{authorbibnamehash}{3ce08524779dc922c814e913cfe986b3}
\strng{authornamehash}{9243aa7e889a5f95bbea2b0309809845}
\strng{authorfullhash}{3ce08524779dc922c814e913cfe986b3}
\field{sortinit}{S}
\field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Unique developmental and operational characteristics of machine learning (ML) components as well as their inherent uncertainty demand robust engineering principles are used to ensure their quality. We aim to determine how software systems can be (re-) architected to enable robust integration of ML components. Towards this goal, we conducted a mixed-methods empirical study consisting of (i) a systematic literature review to identify the challenges and their solutions in software architecture for ML, (ii) semi-structured interviews with practitioners to qualitatively complement the initial findings and (iii) a survey to quantitatively validate the challenges and their solutions. We compiled and validated twenty challenges and solutions for (re-) architecting systems with ML components. Our results indicate, for example, that traditional software architecture challenges (e.g., component coupling) also play an important role when using ML components; along with new ML specific challenges (e.g., the need for continuous retraining). Moreover, the results indicate that ML heightened decision drivers, such as privacy, play a marginal role compared to traditional decision drivers, such as scalability. Using the survey we were able to establish a link between architectural solutions and software quality attributes, which enabled us to provide twenty architectural tactics used to satisfy individual quality requirements of systems with ML components. Altogether, the results of the study can be interpreted as an empirical framework that supports the process of (re-) architecting software systems with ML components.}
\field{booktitle}{2022 {IEEE} {International} {Conference} on {Software} {Analysis}, {Evolution} and {Reengineering} ({SANER})}
\field{month}{3}
\field{title}{Adapting {Software} {Architectures} to {Machine} {Learning} {Challenges}}
\field{year}{2022}
\field{pages}{152\bibrangedash 163}
\range{pages}{12}
\keyw{AI Enabling Architectures Overview}
\endentry
\entry{staschulat_rclc_2020}{inproceedings}{}
\name{author}{3}{}{%
{{hash=d0283c98bae23f290d03947fb405c1db}{%
family={Staschulat},
familyi={S\bibinitperiod},
given={Jan},
giveni={J\bibinitperiod}}}%
{{hash=dcc41435f3f456ea017efa87fc66cdba}{%
family={Lütkebohle},
familyi={L\bibinitperiod},
given={Ingo},
giveni={I\bibinitperiod}}}%
{{hash=58a9a1cbfa2e11afc37418a4ef2109cc}{%
family={Lange},
familyi={L\bibinitperiod},
given={Ralph},
giveni={R\bibinitperiod}}}%
}
\list{publisher}{1}{%
{IEEE}%
}
\strng{namehash}{6f0ab407ec9b36cf1aa8c5ad656bd2e4}
\strng{fullhash}{1e23ff3e81b56b1d95aed2ea73ccecd2}
\strng{bibnamehash}{1e23ff3e81b56b1d95aed2ea73ccecd2}
\strng{authorbibnamehash}{1e23ff3e81b56b1d95aed2ea73ccecd2}
\strng{authornamehash}{6f0ab407ec9b36cf1aa8c5ad656bd2e4}
\strng{authorfullhash}{1e23ff3e81b56b1d95aed2ea73ccecd2}
\field{sortinit}{S}
\field{sortinithash}{b164b07b29984b41daf1e85279fbc5ab}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{booktitle}{2020 {International} {Conference} on {Embedded} {Software} ({EMSOFT})}
\field{shorttitle}{The rclc {Executor}}
\field{title}{The rclc {Executor}: {Domain}-specific deterministic scheduling mechanisms for {ROS} applications on microcontrollers: work-in-progress}
\field{year}{2020}
\field{pages}{18\bibrangedash 19}
\range{pages}{2}
\endentry
\entry{vetter_development_2020}{inproceedings}{}
\name{author}{6}{}{%
{{hash=a0f7bc0f1d4c79298d7bfd1c357c8efc}{%
family={Vetter},
familyi={V\bibinitperiod},
given={Andreas},
giveni={A\bibinitperiod}}}%
{{hash=7d59f8d425e238b037f40ce0e85311ea}{%
family={Obergfell},
familyi={O\bibinitperiod},
given={Philipp},
giveni={P\bibinitperiod}}}%
{{hash=1941e59ce6236cf3e1ef97fef5ce431b}{%
family={Guissouma},
familyi={G\bibinitperiod},
given={Houssem},
giveni={H\bibinitperiod}}}%
{{hash=fdd4d400e8fc9792ad73d30d044b75eb}{%
family={Grimm},
familyi={G\bibinitperiod},
given={Daniel},
giveni={D\bibinitperiod}}}%
{{hash=e2c39d30320d3b2a26fb29f656a4ebff}{%
family={Rumez},
familyi={R\bibinitperiod},
given={Marcel},
giveni={M\bibinitperiod}}}%
{{hash=f6edc406efe2f0b7f0ce15869e359764}{%
family={Sax},
familyi={S\bibinitperiod},
given={Eric},
giveni={E\bibinitperiod}}}%
}
\strng{namehash}{3dc2c34808f98d75bf1f7fafa8c3c37e}
\strng{fullhash}{b83ef21b90380cd24b30aa20fab0b692}
\strng{bibnamehash}{b83ef21b90380cd24b30aa20fab0b692}
\strng{authorbibnamehash}{b83ef21b90380cd24b30aa20fab0b692}
\strng{authornamehash}{3dc2c34808f98d75bf1f7fafa8c3c37e}
\strng{authorfullhash}{b83ef21b90380cd24b30aa20fab0b692}
\field{sortinit}{V}
\field{sortinithash}{afb52128e5b4dc4b843768c0113d673b}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{“The car is the ultimate mobile device” [1] and with its connectivity and a large number [2] of sensors and actuators an example for a cyber-physical system. The advantages of a service-oriented architecture (SOA) are shown in comparison to the classic signal-oriented design. A hybrid architecture which contains both static signal- and dynamic service-oriented elements is introduced. With an example we show how the benefits of a SOA can be achieved, even without migrating the whole vehicle away from the current static communication schemes. The “SuperTuxKart” application integrated into the Mercedes CLA as presented by Daimler on the Mobile World Congress 2019 [3] is an additional customer value application and used as our showcase. Its development and implementation can be greatly simplified if the target vehicle has an electric/electronic architecture, which is service-oriented. We introduce a new process to develop an application within a service-oriented vehicle and use software over the air (SOTA) updates to deploy it. The process is illustrated using a fictive, service-based application.}
\field{booktitle}{2020 9th {Mediterranean} {Conference} on {Embedded} {Computing} ({MECO})}
\field{month}{6}
\field{title}{Development {Processes} in {Automotive} {Service}-oriented {Architectures}}
\field{year}{2020}
\field{pages}{1\bibrangedash 7}
\range{pages}{7}
\keyw{Hybrid Architecture,Network Design,Service-oriented Architecture,Software Over The Air}
\endentry
\entry{vilches_sros2_2022}{misc}{}
\name{author}{4}{}{%
{{hash=13d71f79639b672ffa29e311e3217d76}{%
family={Vilches},
familyi={V\bibinitperiod},
given={Victor\bibnamedelima Mayoral},
giveni={V\bibinitperiod\bibinitdelim M\bibinitperiod}}}%
{{hash=8e3530875bb75f3e6564d0fe162ed981}{%
family={White},
familyi={W\bibinitperiod},
given={Ruffin},
giveni={R\bibinitperiod}}}%
{{hash=5a55d00b3cae60db66837a1045173071}{%
family={Caiazza},
familyi={C\bibinitperiod},
given={Gianluca},
giveni={G\bibinitperiod}}}%
{{hash=9b500c83e403abff6f802dd1c44eefa8}{%
family={Arguedas},
familyi={A\bibinitperiod},
given={Mikael},
giveni={M\bibinitperiod}}}%
}
\list{publisher}{1}{%
{arXiv}%
}
\strng{namehash}{1562dac27c00dc237430863d64132605}
\strng{fullhash}{9b2a5aa1727e62447495667bd20af749}
\strng{bibnamehash}{9b2a5aa1727e62447495667bd20af749}
\strng{authorbibnamehash}{9b2a5aa1727e62447495667bd20af749}
\strng{authornamehash}{1562dac27c00dc237430863d64132605}
\strng{authorfullhash}{9b2a5aa1727e62447495667bd20af749}
\field{sortinit}{V}
\field{sortinithash}{afb52128e5b4dc4b843768c0113d673b}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{ROS 2 is rapidly becoming a standard in the robotics industry. Built upon DDS as its default communication middleware and used in safety-critical scenarios, adding security to robots and ROS computational graphs is increasingly becoming a concern. The present work introduces SROS2, a series of developer tools and libraries that facilitate adding security to ROS 2 graphs. Focusing on a usability-centric approach in SROS2, we present a methodology for securing graphs systematically while following the DevSecOps model. We also demonstrate the use of our security tools by presenting an application case study that considers securing a graph using the popular Navigation2 and SLAM Toolbox stacks applied in a TurtleBot3 robot. We analyse the current capabilities of SROS2 and discuss the shortcomings, which provides insights for future contributions and extensions. Ultimately, we present SROS2 as usable security tools for ROS 2 and argue that without usability, security in robotics will be greatly impaired.}
\field{month}{8}
\field{note}{arXiv:2208.02615 [cs]}
\field{shorttitle}{{SROS2}}
\field{title}{{SROS2}: {Usable} {Cyber} {Security} {Tools} for {ROS} 2}
\field{year}{2022}
\keyw{Computer Science - Cryptography and Security,Computer Science - Distributed,Parallel,and Cluster Computing,Computer Science - Networking and Internet Architecture,Computer Science - Robotics,Computer Science - Software Engineering}
\endentry
\entry{wang_review_2024}{article}{}
\name{author}{6}{}{%
{{hash=659243ba2046a6bc36d6c1cf3dbe5040}{%
family={Wang},
familyi={W\bibinitperiod},
given={Wenwei},
giveni={W\bibinitperiod}}}%
{{hash=6d3e365fa8942ba07ed13f223bbba432}{%
family={Guo},
familyi={G\bibinitperiod},
given={Kaidi},
giveni={K\bibinitperiod}}}%
{{hash=6b6a63a758096bbe61879cb0d031cd57}{%
family={Cao},
familyi={C\bibinitperiod},
given={Wanke},
giveni={W\bibinitperiod}}}%
{{hash=1eb36ac7379f97ac09ccce4580f50db2}{%
family={Zhu},
familyi={Z\bibinitperiod},
given={Hailong},
giveni={H\bibinitperiod}}}%
{{hash=e3433aa5c73a7975bb21a3bbc7f3b2a1}{%
family={Nan},
familyi={N\bibinitperiod},
given={Jinrui},
giveni={J\bibinitperiod}}}%
{{hash=2c466f963663fac7a97926815c50fa18}{%
family={Yu},
familyi={Y\bibinitperiod},
given={Lei},
giveni={L\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{30dea2d073218c102cf213ab311d2bdb}
\strng{fullhash}{22b897ecc72cfafac92da74f9539703b}
\strng{bibnamehash}{22b897ecc72cfafac92da74f9539703b}
\strng{authorbibnamehash}{22b897ecc72cfafac92da74f9539703b}
\strng{authornamehash}{30dea2d073218c102cf213ab311d2bdb}
\strng{authorfullhash}{22b897ecc72cfafac92da74f9539703b}
\field{sortinit}{W}
\field{sortinithash}{4315d78024d0cea9b57a0c6f0e35ed0d}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{With the rapid development of autonomous vehicles, more and more functions and computing requirements have led to the continuous centralization in the topology of electrical and electronic (E/E) architectures. While certain Tier1 suppliers, such as BOSCH, have previously proposed a serial roadmap for E/E architecture development, implemented since 2015 with significant contributions to the automotive industry, lingering misconceptions and queries persist in actual engineering processes. Notably, there are concerns regarding the perspective of zone-oriented E/E architectures, characterized by zonal concentration, as successors to domain-oriented E/E architectures, known for functional concentration. Addressing these misconceptions and queries, this study introduces a novel parallel roadmap for E/E architecture development, concurrently evaluating domain-oriented and zone-oriented schemes. Furthermore, the study explores hybrid E/E architectures, amalgamating features from both paradigms. To align with the evolution of E/E architectures, networking technologies must adapt correspondingly. The networking mechanisms pivotal in E/E architecture design are comprehensively discussed. Additionally, the study delves into modeling and verification tools pertinent to E/E architecture topologies. In conclusion, the paper outlines existing challenges and unresolved queries in this domain.}
\field{journaltitle}{Automotive Innovation}
\field{month}{2}
\field{number}{1}
\field{shorttitle}{Review of {Electrical} and {Electronic} {Architectures} for {Autonomous} {Vehicles}}
\field{title}{Review of {Electrical} and {Electronic} {Architectures} for {Autonomous} {Vehicles}: {Topologies}, {Networking} and {Simulators}}
\field{volume}{7}
\field{year}{2024}
\field{pages}{82\bibrangedash 101}
\range{pages}{20}
\keyw{Autonomous vehicles,Domain-oriented,Electrical and electronic architectures,Networking,Topology,Zone-oriented}
\endentry
\entry{woopen_unicaragil_2018}{inproceedings}{}
\name{author}{35}{}{%
{{hash=1d00af3fa66e604c3d645d94053a530e}{%
family={Woopen},
familyi={W\bibinitperiod},
given={T.},
giveni={T\bibinitperiod}}}%
{{hash=61286c35c21251aa7a781e8682a555c9}{%
family={Lampe},
familyi={L\bibinitperiod},
given={B.},
giveni={B\bibinitperiod}}}%
{{hash=4a13d1f9feab170bc3dafd9ce436889c}{%
family={Böddeker},
familyi={B\bibinitperiod},
given={T.},
giveni={T\bibinitperiod}}}%
{{hash=fcdc1fbca1cceb39ea927618651e4110}{%
family={Eckstein},
familyi={E\bibinitperiod},
given={L.},
giveni={L\bibinitperiod}}}%
{{hash=e51489c41eeb36590577a2192f5bbb6f}{%
family={Kampmann},
familyi={K\bibinitperiod},
given={A.},
giveni={A\bibinitperiod}}}%
{{hash=7c271b8501c4a13d7d870db148fc5d93}{%
family={Alrifaee},
familyi={A\bibinitperiod},
given={B.},
giveni={B\bibinitperiod}}}%
{{hash=ecd711ac5a64785f5f9810ecf7a4d93f}{%
family={Kowalewski},
familyi={K\bibinitperiod},
given={S.},
giveni={S\bibinitperiod}}}%
{{hash=5308d138df54b48c789797c834ecaf01}{%
family={Moormann},
familyi={M\bibinitperiod},
given={D.},
giveni={D\bibinitperiod}}}%
{{hash=ed3a49a61f85054cd630bd26b5a461e3}{%
family={Stolte},
familyi={S\bibinitperiod},
given={T.},
giveni={T\bibinitperiod}}}%
{{hash=3d78a375b2cc60230e15e9310e43d011}{%
family={Jatzkowski},
familyi={J\bibinitperiod},
given={I.},
giveni={I\bibinitperiod}}}%
{{hash=4b83a4ce6bdbbfcce6eb3f15e26d2a94}{%
family={Maurer},
familyi={M\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=6fbc51bf5464885de5e9a0149ed016a0}{%
family={Möstl},
familyi={M\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=c1c2069e9ab634c0d6c618fa8392c9d9}{%
family={Ernst},
familyi={E\bibinitperiod},
given={R.},
giveni={R\bibinitperiod}}}%
{{hash=0dab4808d7045479741d0221b32eef0d}{%
family={Ackermann},
familyi={A\bibinitperiod},
given={S.},
giveni={S\bibinitperiod}}}%
{{hash=b00ab02e345a3f081c86dc250e92ac80}{%
family={Amersbach},
familyi={A\bibinitperiod},
given={C.},
giveni={C\bibinitperiod}}}%
{{hash=b3ccdcf2d5e564433a1a31f68e9990cf}{%
family={Leinen},
familyi={L\bibinitperiod},
given={S.},
giveni={S\bibinitperiod}}}%
{{hash=42a71f3e14e26002d1d2dabe72e2906e}{%
family={Winner},
familyi={W\bibinitperiod},
given={H.},
giveni={H\bibinitperiod}}}%
{{hash=fa37c3180f6bb34cb53dfd6d18ea73df}{%
family={Püllen},
familyi={P\bibinitperiod},
given={D.},
giveni={D\bibinitperiod}}}%
{{hash=77525f34b8760c14c69b51370652b5e9}{%
family={Katzenbeisser},
familyi={K\bibinitperiod},
given={S.},
giveni={S\bibinitperiod}}}%
{{hash=ba7ae79869a864a171fcc42ab3fe3e1c}{%
family={Becker},
familyi={B\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=9dee3559bb84e64b240c89d115d18779}{%
family={Stiller},
familyi={S\bibinitperiod},
given={C.},
giveni={C\bibinitperiod}}}%
{{hash=846e804d909812d5e2b31f34b624f55b}{%
family={Furmans},
familyi={F\bibinitperiod},
given={K.},
giveni={K\bibinitperiod}}}%
{{hash=6eec00f1e951c3bb1fcda8c561887f6e}{%
family={Bengler},
familyi={B\bibinitperiod},
given={K.},
giveni={K\bibinitperiod}}}%
{{hash=7a4487af0634fb80cd5da6af5087ddb3}{%
family={Diermeyer},
familyi={D\bibinitperiod},
given={F.},
giveni={F\bibinitperiod}}}%
{{hash=db41bb052a7f42bbe30902df35680304}{%
family={Lienkamp},
familyi={L\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=0acf0557b9e93251b9bb3c10ade70740}{%
family={Keilhoff},
familyi={K\bibinitperiod},
given={D.},
giveni={D\bibinitperiod}}}%
{{hash=3e6de9c854b60784f8c6e40b85c52f32}{%
family={Reuss},
familyi={R\bibinitperiod},
given={H.\bibnamedelimi C.},
giveni={H\bibinitperiod\bibinitdelim C\bibinitperiod}}}%
{{hash=d3305b02401880dc50d064fb60aac34e}{%
family={Buchholz},
familyi={B\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=4d973361688b488dad7d6603db5aab95}{%
family={Dietmayer},
familyi={D\bibinitperiod},
given={K.},
giveni={K\bibinitperiod}}}%
{{hash=fe401ea3cfbab839a48917b9a137b87d}{%
family={Lategahn},
familyi={L\bibinitperiod},
given={H.},
giveni={H\bibinitperiod}}}%
{{hash=68eafe63d40120e73d79f34de5dc550c}{%
family={Siepenkötter},
familyi={S\bibinitperiod},
given={N.},
giveni={N\bibinitperiod}}}%
{{hash=a29f6668ae1cde43ad1fdbeef26cce4d}{%
family={Elbs},
familyi={E\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=b8d65d53572c0bf269d49d3f359a61e2}{%
family={Hinüber},
familyi={H\bibinitperiod},
given={E.},
giveni={E\bibinitperiod},
prefix={v.},
prefixi={v\bibinitperiod}}}%
{{hash=1d55529eeebe0dbf89332a6e7a00838f}{%
family={Dupuis},
familyi={D\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=7bb69e5d6dc92cee2e101896f9ab1e72}{%
family={Hecker},
familyi={H\bibinitperiod},
given={C.},
giveni={C\bibinitperiod}}}%
}
\list{location}{1}{%
{Aachen, Germany}%
}
\strng{namehash}{c38b9e9649a2af4bb0c4fd09b4ebff5f}
\strng{fullhash}{2d4cb76eebe68ba7f462ab9ea1e26191}
\strng{bibnamehash}{77e9a5ebeb86b3cebf88d54cfb751936}
\strng{authorbibnamehash}{77e9a5ebeb86b3cebf88d54cfb751936}
\strng{authornamehash}{c38b9e9649a2af4bb0c4fd09b4ebff5f}
\strng{authorfullhash}{2d4cb76eebe68ba7f462ab9ea1e26191}
\field{sortinit}{W}
\field{sortinithash}{4315d78024d0cea9b57a0c6f0e35ed0d}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{booktitle}{Aachen {Colloquium}}
\field{title}{{UNICARagil} - {Disruptive} {Modular} {Architectures} for {Agile}, {Automated} {Vehicle} {Concepts}}
\field{year}{2018}
\verb{doi}
\verb 10.18154/RWTH-2018-229909
\endverb
\endentry
\entry{wu_oops_2021}{article}{}
\name{author}{7}{}{%
{{hash=a5c344dd4bee9b92447f9a8f5f8e94a4}{%
family={Wu},
familyi={W\bibinitperiod},
given={Tianze},
giveni={T\bibinitperiod}}}%
{{hash=8f99e6bdf4cc60822269dd6c96f95372}{%
family={Wu},
familyi={W\bibinitperiod},
given={Baofu},
giveni={B\bibinitperiod}}}%
{{hash=b62a6122a73a05f74ce5d8db3c6a30af}{%
family={Wang},
familyi={W\bibinitperiod},
given={Sa},
giveni={S\bibinitperiod}}}%
{{hash=e649bbf69db3c34cfecf2d1c6068a113}{%
family={Liu},
familyi={L\bibinitperiod},
given={Liangkai},
giveni={L\bibinitperiod}}}%
{{hash=b92d60f46947317a2bffd0ee2a844c9c}{%
family={Liu},
familyi={L\bibinitperiod},
given={Shaoshan},
giveni={S\bibinitperiod}}}%
{{hash=f4067fd3dd29cc51d65bc5248563341a}{%
family={Bao},
familyi={B\bibinitperiod},
given={Yungang},
giveni={Y\bibinitperiod}}}%
{{hash=f41bbc46c4cca943fa2a0c3bf70c8a04}{%
family={Shi},
familyi={S\bibinitperiod},
given={Weisong},
giveni={W\bibinitperiod}}}%
}
\strng{namehash}{86985d27df3377ceeb4f76edada598ce}
\strng{fullhash}{40be39d5fa9e90b1bfe9c0162270208a}
\strng{bibnamehash}{86bba990d10b52e043d851aba7500496}
\strng{authorbibnamehash}{86bba990d10b52e043d851aba7500496}
\strng{authornamehash}{86985d27df3377ceeb4f76edada598ce}
\strng{authorfullhash}{40be39d5fa9e90b1bfe9c0162270208a}
\field{sortinit}{W}
\field{sortinithash}{4315d78024d0cea9b57a0c6f0e35ed0d}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{Autonomous Driving (AD) has entered a period of rapid development in recent years. With the amount of sensors and control logics installed increasing tremendously to guarantee robustness, a big challenge is posed for AD middleware. Both the academia and the industry are eager for an investigation of the performance of middlewares in Autonomous Driving Vehicles (AVs). To fill this gap, we summarize typical communication scenarios of AVs and evaluate different communication mechanisms of three popular open-source middlewares comprehensively. Besides, we construct a benchmark pack named ComP which consists of a perception communication scenario and a group of real AD applications for researchers to assess middleware performance. Our findings provide useful guidelines for researchers and insightful optimization advice for designing middlewares.}
\field{issn}{2377-3766}
\field{journaltitle}{IEEE Robotics and Automation Letters}
\field{month}{10}
\field{note}{Conference Name: IEEE Robotics and Automation Letters}
\field{number}{4}
\field{title}{Oops! {It}'s {Too} {Late}. {Your} {Autonomous} {Driving} {System} {Needs} a {Faster} {Middleware}}
\field{volume}{6}
\field{year}{2021}
\field{pages}{7301\bibrangedash 7308}
\range{pages}{8}
\verb{doi}
\verb 10.1109/LRA.2021.3097439
\endverb
\keyw{Data processing,Embedded systems for robotic and automation,Laser radar,Middleware,Open source software,Optimization,Real-time systems,Task analysis,distributed robot systems,software architecture for robotic and automation}
\endentry
\entry{zeng_qos-aware_2004}{article}{}
\name{author}{6}{}{%
{{hash=41647e2d8a77dbbd1fd97c7efec8e944}{%
family={Zeng},
familyi={Z\bibinitperiod},
given={Liangzhao},
giveni={L\bibinitperiod}}}%
{{hash=27d8d645f0c1e8dcd04e1602a8a7f3b7}{%
family={Benatallah},
familyi={B\bibinitperiod},
given={B.},
giveni={B\bibinitperiod}}}%
{{hash=50596f4e4d18ef367d14c8e6274a8cb6}{%
family={Ngu},
familyi={N\bibinitperiod},
given={A.H.H.},
giveni={A\bibinitperiod}}}%
{{hash=790b2cdb34aa7f59bbe21130331b362b}{%
family={Dumas},
familyi={D\bibinitperiod},
given={M.},
giveni={M\bibinitperiod}}}%
{{hash=8351f8dd3b139df79e8877ee2fcf7fae}{%
family={Kalagnanam},
familyi={K\bibinitperiod},
given={J.},
giveni={J\bibinitperiod}}}%
{{hash=701500fa4f83c75c8ce39152916ce4e4}{%
family={Chang},
familyi={C\bibinitperiod},
given={H.},
giveni={H\bibinitperiod}}}%
}
\strng{namehash}{7a09561a172101f09a2086b8c93361e5}
\strng{fullhash}{72471ab521ce71dc4a6e668d72576d97}
\strng{bibnamehash}{72471ab521ce71dc4a6e668d72576d97}
\strng{authorbibnamehash}{72471ab521ce71dc4a6e668d72576d97}
\strng{authornamehash}{7a09561a172101f09a2086b8c93361e5}
\strng{authorfullhash}{72471ab521ce71dc4a6e668d72576d97}
\field{sortinit}{Z}
\field{sortinithash}{96892c0b0a36bb8557c40c49813d48b3}
\field{labelnamesource}{author}
\field{labeltitlesource}{title}
\field{abstract}{The paradigmatic shift from a Web of manual interactions to a Web of programmatic interactions driven by Web services is creating unprecedented opportunities for the formation of online business-to-business (B2B) collaborations. In particular, the creation of value-added services by composition of existing ones is gaining a significant momentum. Since many available Web services provide overlapping or identical functionality, albeit with different quality of service (QoS), a choice needs to be made to determine which services are to participate in a given composite service. This paper presents a middleware platform which addresses the issue of selecting Web services for the purpose of their composition in a way that maximizes user satisfaction expressed as utility functions over QoS attributes, while satisfying the constraints set by the user and by the structure of the composite service. Two selection approaches are described and compared: one based on local (task-level) selection of services and the other based on global allocation of tasks to services using integer programming.}
\field{journaltitle}{IEEE Transactions on Software Engineering}
\field{month}{5}
\field{note}{Conference Name: IEEE Transactions on Software Engineering}
\field{number}{5}
\field{title}{{QoS}-aware middleware for {Web} services composition}
\field{volume}{30}
\field{year}{2004}
\field{pages}{311\bibrangedash 327}
\range{pages}{17}
\keyw{Availability,Computer Society,Computer science,Financial management,Linear programming,Middleware,Online Communities/Technical Collaboration,Quality of service,Web and internet services,Web services,integer programming.,quality of service,service composition}
\endentry
\entry{zhu_requirements-driven_2021}{article}{}
\name{author}{5}{}{%
{{hash=1eb36ac7379f97ac09ccce4580f50db2}{%
family={Zhu},
familyi={Z\bibinitperiod},
given={Hailong},
giveni={H\bibinitperiod}}}%
{{hash=c7905d3683e86c148202145e4b6e5b7c}{%
family={Zhou},
familyi={Z\bibinitperiod},
given={Wei},
giveni={W\bibinitperiod}}}%
{{hash=dc40c686a2e9f19af8ca6ef4bded007a}{%
family={Li},
familyi={L\bibinitperiod},
given={Zhiheng},
giveni={Z\bibinitperiod}}}%
{{hash=502de95c3193f5c283f4ef712520a97e}{%
family={Li},
familyi={L\bibinitperiod},
given={Li},
giveni={L\bibinitperiod}}}%
{{hash=f39d73c2040236ebf9896a42646cfa06}{%
family={Huang},
familyi={H\bibinitperiod},
given={Tao},
giveni={T\bibinitperiod}}}%
}
\list{language}{1}{%
{en}%
}
\strng{namehash}{f1c36c593462cc4d3e33a83515a9151e}
\strng{fullhash}{54a9c926549ede4a2c71f10df5bafe06}
\strng{bibnamehash}{54a9c926549ede4a2c71f10df5bafe06}
\strng{authorbibnamehash}{54a9c926549ede4a2c71f10df5bafe06}
\strng{authornamehash}{f1c36c593462cc4d3e33a83515a9151e}
\strng{authorfullhash}{54a9c926549ede4a2c71f10df5bafe06}
\field{sortinit}{Z}
\field{sortinithash}{96892c0b0a36bb8557c40c49813d48b3}
\field{labelnamesource}{author}
\field{labeltitlesource}{shorttitle}
\field{abstract}{The automotive E/E architecture has undergone a paradigm shift in the past century. Particularly, the new requirements of automated driving are severely challenging the existing architecture, which has led to ongoing revolutionary innovation in E/E architecture. In this paper, we reviewed the evolution of E/E architecture and outlined the requirements-driven developments. We illustrated the state-of-the-art E/E architecture, including network topology, standards, simulator and software platform. We also discussed the next generation of E/E architecture from the perspective of different OEMs and suppliers. The analysis shows that software-defined, hierarchical, reconfigurable and customized E/E architecture is universally accepted. Furthermore, the automotive industry has been experiencing several transitions related to OEMs and suppliers. With the emergence and maturation of automated driving, we analyzed the new requirements on E/E architecture and proposed prospective development trends.}
\field{issn}{2169-3536}
\field{journaltitle}{IEEE Access}
\field{shorttitle}{Requirements-{Driven} {Automotive} {Electrical}/{Electronic} {Architecture}}
\field{title}{Requirements-{Driven} {Automotive} {Electrical}/{Electronic} {Architecture}: {A} {Survey} and {Prospective} {Trends}}
\field{volume}{9}
\field{year}{2021}
\endentry
\enddatalist
\endrefsection
\endinput