# Software Defined Vehicles for Development of Deterministic Services††thanks:
Financial support from the National Science and Technology Foundation within
grant FCT.2023.04459.BD.

Pedro V. Teixeira, Student Member, IEEE, Duarte Raposo, Member, IEEE,
Rui Eduardo Lopes, Student Member, IEEE, Susana Sargento, Senior Member, IEEE
Pedro V. Teixeira, Rui Lopes and Susana Sargento are with the Instituto de
Telecomunicações and Universidade de Aveiro, Aveiro, Portugal. Duarte Raposo
is with the Instituto de Telecomunicações, Aveiro, Portugal.

###### Abstract

With modern vehicles evolving with more features, services, complex systems,
with more sensors, actuators, and processing units, it is essential to think
about vehicles not only as means of transportation that may tend towards full
autonomy, but also as adaptive objects, that suit themselves to the needs of
occupants. Vehicular services can be developed to support these adaptations.
However, the increasing complexity of vehicular service development, even with
current standardizations and best practices and guidelines, are insufficient
to tackle the high complexity of development, with expectations of up to 1
(U.S.) billion lines of code for a fully (level 5) autonomous vehicle.
Within this survey, the paradigm of Deterministic Software Defined Vehicles is
explored towards increasing the quality and easiness of the development of
services for automotive.
Towards this, a proposed vision with four pillars is also provided: the
deterministic network configurator, the data layer configurator, and the
hypervisor configurator and the vehicle abstraction layer, all coordinated by
a software orchestrator.

###### Index Terms:

Software-Defined Vehicles, Connected Vehicles, Vehicular Applications,
Vehicular Services, Intelligent Transportation Systems, Deterministic
Networks, Time Sensitive Networks

3GPP

    Third Generation Partnership Project
5QI

    5G QoS Identifier
AADL

    Architecture Analysis and Design Language
ABS

    Anti-lock Braking System
ACM

    Association for Computing Machinery
ADAS

    Advanced Driving Assistance System
ANACOM

    Autoridade Nacional de Comunicações
AP

    Access Point
API

    Application Programming Interface
AR

    Augmented Reality
ASIC

    Application-Specific Integrated Circuit
ASIL

    Automotive Safety Integrity Level
ASN.1

    Abstract Syntax Notation One interface description language
ATCLL

    Aveiro Tech City Living Lab
ATS

    Asynchronous Traffic Shaping
AUTOSAR

    Automotive Open System Architecture
AVB

    Audio Video Bridging
Bosch

    Bosch Car Multimédia Portugal
Bosch Ovar

    Bosch Security Systems, S.A
BSM

    Basic Safety Message
CAM

    Cooperative Awareness Message
CAN

    Controller Area Network bus
CAN-FD

    CAN Flexible Data Rate
CAV

    Connected Autonomous Vehicle
CBS

    Credit Based Shaper
CCU

    Central Control Unit
CNC

    Centralized Network Controller
CNI

    Container Network Interface
CoAP

    Constrained Application Protocol
COVESA

    Connected Vehicle Systems Alliance
CPM

    Collective Perception Message
CPS

    Collective Perception Service
CPU

    Central Processing Unit
CSMA-CA

    CSMA-Collision Avoidance
CSMA

    Carrier-Sense Multiple Access
CUC

    Centralized User Configuration
CUDA

    Compute Unified Device Architecture
C-V2X

    Cellular Vehicle-to-Everything
DC-GBR

    Delay Critical GBR
DCU

    Data Collection Unit
SDP

    Simple Discovery Protocol
DDS

    Data Distribution Service
DENM

    Decentralized Environmental Notification Message
DetNet

    Deterministic Networking
DL

    Deep Learning
DoS

    Denial of Service
DPDK

    Data Plane Development Kit
DRY

    Don’t repeat yourself
DSL

    Domain-Specific Language
DSP

    Digital Signal Processor
DSRC

    Dedicated Short Range Communications
eBPF

    extended Berkeley Packet Filter
ECU

    Electronic Control Unit
E/E

    Electrical/Electronic
ELK

    Elasticsearch-Logstash-Kibana
ETSI

    European Telecommunications Standards Institute
EVA

    Emergency Vehicle Alert
eVTOL

    electrical Vertical Take Off and Landing
FACE

    Future Architecture for Computing Environment
FDMA

    Frequency-Division Multiple Access
FPGA

    Field-Programmable Gate Array
FRER

    Frame Replication and Elimination for Reliability
GBR

    Guaranteed Bit Rate
GDA

    Geographical Destination Area
GNSS

    Global Navigation Satellite System
GPRS

    General Packet Radio Service
GPS

    Global Positioning System
GPU

    Graphical Processing Unit
gRPC

    Google RPC
HMD

    Head Mounted Display
HPC

    High Performance Computer
HTTP

    Hypertext Transfer Protocol
HUD

    Heads-Up Display
I2X

    Infrastructure to Everything
IC

    Integrated Circuit
ICA

    Intersection Collision Announcement
IEEE

    Institute of Electrical and Electronics Engineers
IETF

    Internet Engineering Task Force
IMU

    Inertial Measurement Unit
I/O

    Input/Output
IoT

    Internet of Things
IoU

    Intersection over Union
IP

    Internet Protocol
IPFS

    InterPlanetary File System
IT-Aveiro

    Institute of Telecommunications of Aveiro
ITS-S

    Intelligent Transport System Station
ITS

    Intelligent Transport System
JDL

    U.S. Joint Directors of Laboratories
JSON

    JavaScript Object Notation
KPI

    Key Performance Indicator
KVM

    Kernel-based Virtual Machine
Lidar

    LIght Detection And Ranging
LIN

    Local Interconnect Network bus
LoRaWAN

    Long Range Wide-Area Network
LPWAN

    Low-Power Wide-Area Network
LTE

    Long Term Evolution
LTE-A

    Long Term Evolution Advanced
M2M

    Machine to Machine
MAC

    Media Access Control
MANET

    Mobile Ad-hoc Network
MCM

    Manoeuvre Coordination Message
MEC

    Multi-access Edge Computing
MISRA

    Motor Industry Software Reliability Association
ML

    Machine Learning
MOST

    Media Oriented Systems Transport
MPLS

    Multiprotocol Label Switching
MQTT

    Message Queuing Telemetry Transport
MTBF

    Mean Time Between Failures
MTU

    Maximum Transmission Unit
NAP

    Network Architectures and Protocols
NB-IoT

    Narrowband IoT
NETCONF

    Network Configuration Protocol
NFC

    Near Field Communication
NGSIv2

    Next Generation Service Interfaces version 2
NIC

    Network Interface Controller/Card
NOMA

    Non-orthogonal Multiple Access
NTP

    Network Time Protocol
OASIS

    Organization for the Advancement of Structured Information Standards
OATD

    Open Access Theses and Dissertations
OBD2

    OnBoard Diagnostic v2
OBU

    On-Board Unit
OEM

    Original Equipment Manufacturer
OFDMA

    Orthogonal FDMA
OMG

    Object Management Group
OOP

    Object Oriented Programming
OS

    Operating System
OSAL

    Operating system abstraction layer
OSI

    Open Systems Interconnection
OTA

    Over-the-air
P2I

    Pedestrian to Infrastructure
P2P

    Pedestrian to Pedestrian
P2V

    Pedestrian to Vehicle
P2X

    Pedestrian to Everything
PCP

    Priority Code Point
PER

    Packet Error Rate
POSIX

    Portable Operating System Interface
PPS

    Pulse Per Second
PSM

    Personal Safety Message
PTP

    Precision Time Protocol
QoS

    Quality of Service
Radar

    RAdio Detection And Ranging
RAP

    Resource Allocation Protocol
RAT

    Radio Access Technology
RDMA

    Remote Direct Memory Access
REST

    Representational State Transfer
RESTCONF

    NETCONF through REST
RFC

    Request for Comments
ROI

    Region of Interest
ROS

    Robotic Operating System
RPC

    Remote Procedure Call
RSU

    Road Side Unit
RTE

    Run Time Environment
RTOS

    Real-Time Operating System
RTPS

    Real-Time Publish/Subscribe Protocol
RTT

    Round Trip Time
rTWT

    restricted Target Wake Time
SAE

    Society of Automotive Engineers
SCS

    Stream Classification Service
SDK

    Software Development Kit
SDN

    Software-Defined Network
SDR

    Software-Defined Radio
SDV

    Software-Defined Vehicle
SDVC

    Software-Defined Vehicular Cloud
SIP

    Session Initiation Protocol
SLA

    Service Level Agreement
SOA

    Service Oriented Architecture
SOAFEE

    Scalable Open Architecture for Embedded Edge
SoC

    System-on-chip
SOME/IP

    Scalable service-Oriented MiddlewarE over IP
SPICE

    Automotive Software Process Improvement and Capability Determination
SPoF

    Single Point of Failure
SRP

    Stream Reservation Protocol
TAS

    Time Aware Shaper
TCP

    Transmission Control Protocol
TDD

    Test Driven Development
TDMA

    Time-Division Multiple Access
TIM

    Traveler Information Message
TSF

    Timing Synchronization Function
TSN

    Time Sensitive Network
TTC

    Time To Collision
TTEthernet

    Time-Triggered Ethernet
TTL

    Time To Live
DETI/UA

    Department of Electronics, Telecommunications and Informatics, University of Aveiro
UC

    Use Case
UDP

    User Datagram Protocol
UE

    User Equipment
UI

    User Interface
UPF

    User Plane Function
U.S.

    United States of America
USB

    Universal Serial Bus
UTP

    Unshielded Twisted Pair cable
V2I

    Vehicle to Infrastructure
V2P

    Vehicle to Pedestrian
V2V

    Vehicle to Vehicle
V2X

    Vehicle to Everything
VAL

    Vehicle Abstraction Layer
VAM

    Vulnerable Road User Awareness Message
VANET

    Vehicular Ad-hoc Network
VCU

    Vehicle Control Unit
VM

    Virtual Machine
VPN

    Virtual Private Network
VRU

    Vulnerable Road User
VXCAN

    Virtual CAN tunnel
WAN

    Wide Area Network
WAVE

    IEEE 802.11p WAVE
WPAN

    Wireless Personal Area Network
WGS84

    EPSG:4326/World Geodetic System 1984
WSGI

    Web Server Gateway Interface
XDP

    eXpress Data Path
XML

    eXtended Markup Language
YANG

    Yet Another Next Generation
YOLO

    You Only Look Once real-time object detection system

##  I Introduction

We are living in an ever more connected world, which is not very safe nor
designed for everyone. This is particularly true within vehicular scenarios,
where autonomous next generation vehicles are designed solely to remove the
need of a driver without much consideration for occupants and other road
users’ specific needs. This is even more substantial in a more and more
elderly society, where impairments are unavoidable.

Even if vehicle will tend to become driver-less, autonomous vehicles may also
take decades to be fully on the roads and starting now, they will coexist with
manual-driven cars. As such, autonomous vehicles do not take on the needs of
the other occupants. Examples of such needs would be the vehicle recognizing
them or potential health issues and providing personalized profiles and
automatic adjustments on seating, cooling systems, driving profiles but also
other vehicular subsystems that may support some sort of impairment.

It is therefore essential to think about vehicles not only as means of
transportation that may tend towards not requiring drivers, but also as
adaptive objects, that suit themselves to the needs of occupants. But this
adaptation must be carried out flawlessly, since any failure can mean harm to
someone, or even death. The context of deterministic — i.e. where the result
is exactly what was intended in the exact moment it was intended — critical
vehicular services — pieces of software that carry out something within the
vehicle or its environment — within Software-Defined Vehicle can provide a
solution to this problem.

Figure 1: Evolution of complexity in vehicular architectures [1].

With the introduction of computational systems into vehicles in late 1980s,
the complexity — i.e. , the amount of systems that need to be choreographed,
developed, tested and that have to communicate — of vehicles exploded, as well
as the possibilities of something going wrong [2, 3]. Product compliance in
the automotive industry already have to deal with more than 100 million source
lines of code [4] and will have to deal with more than 300 million lines of
code by 2030, to take into account more than 500 thousand regulations and
requirements (80% of them focused on safety) [5]. With fully autonomous
driver-less cards, Original Equipment Manufacturers estimations are even more
problematic, with expectations of up to 1 billion lines of code [4].

Current vehicular systems are extremely complex, with many Electronic Control
Units (at least around 100111Described in www.fortunebusinessinsights.com.),
sensors, and actuators scattered throughout the vehicle and more than 100
million lines of code222More than in a military or commercial aircraft (F-35,
787 Dreamliner) [6]., with perspective of reaching 500 million to 1 billion
with level 5 autonomous vehicles [6]. This is part of an ever-growing tendency
of increasing complexity in vehicular architectures, as depicted in fig. 1.

This growing code base is becoming unmanageable to vehicle manufacturers and
developers of vehicular services. As described in fig. 2, automakers will tend
to leave unchecked, unverified and poorly tested software go into production
vehicles if the growth trend of the code base continues — with potentially
deadly results333Unverified logic and deadly effects on Tesla’s autopilot
www.washingtonpost.com.. The overall intra-vehicular systems as developed
following legacy standards and practices are deemed too complex and static —
and thus costly to maintain, update and keep safe — by vehicle manufacturers,
with the reduction of the overall complexity (both in software and hardware
terms, in particular wiring harness weight savings) becoming a major goal in
order to reduce operational costs and decrease potential security issues from
unchecked, poorly tested code [7].

Standardization of best practices and development guidelines for intra
vehicular software gained traction during the early 2000s [8], they are
insufficient to tackle such complexity of development. While programming
methodologies444Such as static code analysis, Test Driven Development (TDD)
and equivalent methodologies. and guidelines555Such as the Automotive Safety
Integrity Levels within ISO 26262 or Motor Industry Software Reliability
Association (MISRA)-C, a set of guidelines for safety-related systems, such as
automotive vehicles. Details at synopsys.com, misra.org.uk and synopsys.com.
are critical and cannot be disregarded, they are no longer enough to tackle
this complexity.

In this article, we propose that _the quality and easiness of the development
of services for automotive can be improved using the paradigm of Deterministic
Software Defined Vehicles_. The main contributions of this tutorial are as
follows:

  1. 1.

Demonstrate the suitability and relevance of the software defined vehicles for
an sustainable development of vehicular services.

  2. 2.

Improve the state-of-the-art on Software Defined Vehicle concept and its main
building blocks.

  3. 3.

Propose an integration of Time-Aware and Deterministic Networks concepts and
solutions within a Software Defined Vehicle.

  4. 4.

Definition of a set of potential use cases that aim to frame the proposed
integration not only in the foreseeable future, but in a long-term
perspective.

  5. 5.

Survey of hardware and software alternatives for validation of the proposed
integration.

The remaining of this document is organized into four sections. Section II:
Software Defined Vehicles — introduces the background concepts, defining
vehicular services and their characteristics and the concept of Software-
Defined Vehicle (SDV) and additional information on the industrial landscape
and how automakers or suppliers are facing the SDV paradigm. Next, section
III: Main building blocks of Software Defined Vehicles — presents the main
building blocks for a SDV based vehicle (and vehicular services) development,
and section IV: Open challenges — discusses on the main challenges.

Section V: Potential use cases — follows with the main use cases and
requirements that can be drawn from them, while Section VI: Proposed vision —
considers those requirements for a proposed architecture, as well as a
proposal of how the evaluation process to validate the work may be considered,
with considerations on required hardware and software for results obtained
both through simulation or real-world testing. Finally, conclusions are
provided in section VII: Conclusions.

Figure 2: Average complexity of individual software projects grown by 300
percent over the past decade, creating an unsustainable gap between software
complexity and the productivity of software developers [6, 9].

##  II Software Defined Vehicles

This section presents the concept of vehicular services, software defined
vehicles and the efforts in the framework of the industry landscape.

###  II-A Vehicular Services

The desired transition from fossil-fueled vehicles towards clean-energy
Intelligent Transport System (ITS) requires the introduction of more advanced
systems and services. Such services are required to support the necessary
auxiliary electrical systems, increase overall range while decreasing the
environmental impact, but also to improve the overall quality of life for
passengers and drivers and support (semi)autonomous driving. Vehicular
services can be drawn a parallelism to personal computing applications: some
services are critical, others are less critical, some require vast computing
resources, either in terms of Central Processing Unit (CPU), memory, storage,
or graphical resources [10], and can broadly be classified in terms of real-
time guarantee levels in [11] either hard real-time services (where deadline
failure means a system failure with potential catastrophic consequences),
weakly hard real-time (where some tasks can be skipped, while keeping the
deadline fulfillment) or soft real-time (where a specific number of deadlines
can be missed).

Critical services such as safety services (e.g. emergency braking) can be
considered within the SDV as well as services related to the occupants [12].
Main requirements of most of those services include high interoperability,
reliability, availability, safety, security, performance, scalability,
extensibility, adaptability and testability [13]. During the overall
definition and characterization of a vehicular service it is essential to
formulate the service and characterize its tasks in terms of those
requirements, with particular emphasis on characteristics such as the priority
of the service, data specifications — such as format, size and real time
guarantee requirements (periodicity or deadline for receiving/sending data) —
expected computing location (vehicle edge vs smart city cloud) [11, 14]. Non
functional characteristics such as cost minimization, efficient use of
available resources, maintainability and scalability, high flexibility to add
new services (without custom hardware and software stacks), and redundancy at
network and computing level, while keeping backwards compatibility with older
vehicles shall also be taken into account [14].

These characteristics can be seen as the Service Level Agreement (SLA) of the
service. Such SLAs can and should be defined by the developer of each
vehicular service and could be ensured/enforced by a distributed configurator
through a set of Quality of Service (QoS) tools and policies, including [11]:

  * •

Network and resource monitoring and discovery.

  * •

Dynamic, intelligent task scheduling and resource estimation, provisioning and
allocation, including the offloading to other layers of communication (fog and
cloud), if the overall end to end communication latency is capable of
supporting such offloading while fulfilling deterministic well defined
deadlines.

  * •

Federation of multiple physical wireless and wired access layers in order to
obtain a multi-homing solution.

  * •

Slicing of the multi-homing communication solution to support different levels
of QoS specified by the service descriptors.

  * •

Management of the high mobility, for example through the management of
reactive and proactive handovers through Software-Defined Network (SDN) [15]
based solutions.

  * •

Prediction of the overall resource usage while considering heterogeneity of
the nodes. For example, a system that, through the service descriptor and
usage trends of eacfh/all ECUs, analyzes the likelihood of such service of
being resource starved or not, can be a good first estimation666Author
proposal.. This can be further improved by defining an overall cost of each
node [16], or by introducing reinforcement learning techniques into the
scheduling of the tasks [17].

  * •

Estimation and prediction of the mobility of a certain service deployment
based on trends of resource usage and prediction of the mobility of the
vehicle [18].

While considering specifics of the vehicular domain, such as the mobility of
vehicular nodes, communication and node failures, heterogeneity of the nodes
hardware specifications, overall low specification and communication
techniques and overall security threats.

###  II-B Concept

Automotive vehicles need to evolve to a new concept of SDV since in-vehicle
services must be dynamic, and should be able to adapt over the vehicle life-
cycle. At the same time, in-vehicle services need to interact with the
vehicle’s systems, sensors, and the surrounding infrastructure within a well-
defined time-frame. Therefore, systems must also be interconnected with a
high-performance, high-precision, reliable set of networks and protocols with
time guarantees.

SDV aims to improve cars along their life-cycle [19], while potentially
mitigating the increased unmanaged complexity of modern vehicular software,
hardware, and communications. The paradigm states that vehicles manage their
operations, add functionality, and enable new features primarily or entirely
through software777More details at https://blackberry.qnx.com/en/ultimate-
guides/software-defined-vehicle.. Since vehicles evolve over their lifetime,
with more features, solutions that may require remote control or remote
updates, main features being delivered by software adds flexibility and
reduces the overhead.The shift towards SDV signifies new features can be
pushed to existing and new vehicles, which are now more defined through
software than through hardware or mechanical systems as in the past [6]. To
support this new paradigm, computational architectures within vehicles are
going from fully distributed ECUs scattered throughout the vehicle towards a
more centralized solution, with zone-based architectures, i.e. ECUs positioned
in specific parts of the vehicle responsible for certain types of actions
[20]. ECUs are now responsible for more functions, thus being more powerful,
powered with tailor made System-on-chips with more cores and Digital Signal
Processors, Graphical Processing Units and Ethernet capability [6] with
partnerships with Integrated Circuits manufacturers [21].

SDV support not just the improvement of the development of vehicular services
but also helps towards a decrease in hardware complexity (with decreased
number of ECUs, cables and the cost and weight savings which follow), with
more uniform software code-base (and the reduction of the costs and complexity
of the development process which follow) and greater adaptability888This
adaptability is essential specially if the future of the car ownership is car
sharing [22]. towards the future, with the possibility of new or updated
features as over the air updates during the vehicle’s lifetime. This
adaptability also supports a greater capability to process higher volumes of
data while fulfilling the overall performance requirements — essential in
Connected Autonomous Vehicles.

Vehicles in the past added new features at the cost of new specialized ECUs
close to the sensors and actuators and connected to them through CAN or other
equivalent bus (more details at section III-D. This tendency created an
upwards trend in the number of ECUs and connecting wiring.

The new Electrical/Electronic (E/E) architectures within a vehicle follow the
principle of aggregation of ECUs into a small subset of more powerful ECU,
interconnected through a high performance bus, such as Ethernet [23]. Figure 3
provides an overview of this evolution.

Figure 3: Legacy, current, and future SDV paradigm on the topology of ECUs
within a vehicle.

Intra vehicular computational architectures have evolved from the original
distributed approach, where custom isolated ECUs implement a dedicated very
specific function towards interconnected ECUs with various degrees of
aggregation of function. With the introduction of ECUs during the 1980s, as in
fig. 3 (a), ECUs did very specific functions in an isolated manner and
connected only to specific sensors and actuators through Controller Area
Network bus (CAN) or equivalent. With the explosion of features in vehicles,
specially luxury cars, during the 1990s, ECUs became interconnected. By 2000s,
the high complexity of intra vehicular systems became subject to de facto
standards such as Automotive Open System Architecture (AUTOSAR) [2, 3] and
buses such as FlexRay aimed at mitigating some of the shortcomings of CAN.

Decentralized architectures were the norm within intra vehicular systems,
allowing a better decoupling, separation of concerns and higher tolerance to
equipment failure. However, the scalability of the deployment of services to
multiple ECUs (specially considering all the possible ECU variations), the
performance of communications and the overall cost in bulky wiring harnesses
and several ECUs created a trend towards a more centralized architecture, with
more centralization of processing in less computing units. This follows
previous trends within other industries, in particular the aviation industry
[14].

While distributed architectures tend to ensure high reliability in the event
of equipment failure and each ECU is simpler, cheaper, and with a very
specific purpose (and thus easier to outsource its manufacturing), the overall
architecture is not designed for scalability, flexibility and changeability.
By 2010s, domain architectures were a first step towards mitigating those
issues through the aggregation of functions per domain. However, the
integration of multiple domains required by systems such as Advanced Driving
Assistance System (ADAS) require coordination between different domains [2,
3].

A fully centralized architecture aims at mitigating that issue while
potentiating reduction of costs in the number of ECUs and the higher software
reusability, while allowing greater flexibility. In a centralized
architecture, high performance microprocessor999Microcontroller based ECUs are
only for very specific safety real-time subsystems. based ECUs are
interconnected through a high performance bus [2, 3]. Centralization within
the intra-vehicular systems can thus be achieved at a domain, cross domain or
zone/vehicle centralized way [14]:

  * •

Domain oriented solution: In a domain-oriented solution, the clustering is
done by vehicle function, which requires heavy interaction between ECUs for
complex systems such as ADAS.

  * •

Cross domain solution: In a cross-domain solution, functions of several
domains are consolidated within more powerful ECUs. This minimizes, without
removing, the high bandwidth required to transfer between ECUs.

  * •

Zone-oriented architecture: In a zone-oriented architecture, ECUs in each zone
of the vehicle collect and forward information to a much more powerful central
ECU, or even offloads to the cloud. Bosch reported on achieving a 15–20%
reduction in wiring harness weight when using a zone-oriented architecture
instead of a domain-oriented architecture.

Since functions are now centralized in less ECUs, each one must be more
powerful, with multi core CPUs, GPUs, DSPs, and potentially Field-Programmable
Gate Arrays. To ensure optimal usage of ECUs, with concurrent execution of
different services with different criticality, partitioning of scheduling of
each core per service(s) is required. Virtualization of resources, either
memory, buses (e.g. CAN) and CPU allows both isolation of services within
virtual machines while allowing migration and reusage of legacy software (by
installing legacy stacks on top of the virtual machines) [14]. Some ECUs can
also be dedicated to computing intensive tasks, including Machine Learning
(ML) and Deep Learning (DL) workloads supporting ADAS systems [13].

###  II-C Industrial landscape

Vehicular manufacturers are aware of the necessary changes in thinking. The
industry, while already aware for the need of such solutions, the transition
from the previous mentality of closed source, customized solutions for each
model of vehicle towards a more extendable, interoperable, architecture. In
particular, the Renault, Volvo/Polestar and Volkswagen group seems to be ahead
in terms of a more interoperable architecture based on ECUs interconnected
through Ethernet that run Android and well-known versions of chipsets. It is
however not possible to ignore efforts from other vehicle manufacturers that
may be developing equivalent solutions but have not, at the time of this
survey, announced their efforts. The opacity of the vehicular industry —
expected within a competitive market — while partially mitigated through the
research of gray literature, remains and will remain a threat to any related
work, including this work.

After the landscape changing forced by Tesla, automakers such as BMW [24]; the
Renault group through the Renault Software Factory101010More details on
www.reuters.com.; Volvo; Kia and Hyundai111111More details on
www.carscoops.com.; and the Volkswagen group through the CARIAD121212Available
at cariad.technology., supported by companies such as Vector [25] and VXworks,
are shifting towards a software-first development of the vehicles, based on
novel hardware and communication paradigms. The next phases of automotive
software development should also have a deep integration with cloud and follow
the best practices of software development (CI/CD) [26]. Figure 4 provides an
overview of the efforts of automakers on adoption the main aspects related to
SDV, with table I providing further detail per associated areas.

Y5.0e0]ptPrimitivevehiclesystemY5.0e0]ptExplosionofvehiclesystemsY9.0e0]ptAUTOSARClassicY5.0e0]ptAUTOSARAdaptiveY2.0e0]ptCARIADBMWY3.0e0]ptRenaultVolvoY6.0e0]ptOpportunity?Y8.0e0]ptTeslaMore
featuresMore versatileMore standardMore open Figure 4: Positioning of main
automakers and frameworks over the overall industrial landscape. TABLE I:
Overview of the manufacturers effort on SDV.

[t]  Entity State of integration Ethernet TSN Zonal ECUs SOA SDV Open Standard
AUTOSAR Classic $\times$ $\times$ $\times$ $\times$ $\times$ $\times$ ✓
AUTOSAR Adaptive ✓ $\times$ $\times$ ✓- ✓- $\times$ ✓ BMW ✓ ✓ ✓ ✓ ✓ ✓ $\times$
Renaulta ✓ ✓ ✓ ✓ ✓ ✓- ✓- Volvo ✓ ✓ ✓ ✓ ✓ ✓-c $\times$ Volkswagen groupb ✓? ✓?
✓? ✓? ✓ $\times$ $\times$ NVIDIA ✓ ✓ $\times$ ✓ $\times$ $\times$ $\times$
Tesla ✓ ✓ ✓ ✓ ✓ ✓ ✓- Eclipse ✓ ✓ ✓ ✓ ✓ ✓ $\times$

  * a

Renault software factory

  * b

CARIAD

  * c

Partial access through Volvo Application Programming Interfaces.

The Tesla company is probably the most well-known example of application of
the SDV paradigm principles. Within their vehicles the ECUs — such as the
Autopilot Control Unit, the Media Control Unit, and several Body Control Units
— are interconnected through Ethernet and are much less than the usual within
vehicles up to that point.

The Volkswagen group take on SDV is based on creating and controlling the
whole platform — cloud (Volkswagen Automotive Cloud VW.AC), hardware and
software (VW. Operating System (OS)) [27], affecting interoperability with
other automakers and hardware providers. While in initial stages, it was not
possible to obtain documentation on APIs or Software Development Kits that
should be used to developed vehicular services using the CARIAD ecosystem,
highlighting a possible tendency towards a close proprietary SDV paradigm. A
notable exception is the Roobadge131313Product description available at
https://www.volkswagen.com.au/en/ roobadge.html., a solution to avoid
collisions with kangaroos — very common in Australia — by adding, through a
front badge or license plate holder sensors to detect the kangaroos. This
solution not only showcases a real example of the potential of SDV, since new
features are added to an existing vehicle through a new deployed service, but
is also compatible with other brand’s vehicles, showcasing a real SDV example
that considers brand interoperability.

The Renault group considers a backbone of ECUs interconnected with Ethernet,
with gateways to bridge the Ethernet connected ECUs with legacy sensors or
actuators interconnected by CAN [19, 28]. These ECUs run Android and are based
on Qualcomm chipsets, supporting an interoperable, open SDV
architecture141414More details at www.qualcomm.com.. Volvo and Polestar have a
similar approach, with zone controllers — high performance controllers in
specific zones of the vehicle — interconnected and connected to a central
master Vehicle Control Unit (VCU) with an Ethernet backbone [29]. The Zone
Controllers can also act as a bridge to legacy buses, like CAN and Local
Interconnect Network bus (LIN). Volvo within their SDV efforts also published
OpenAPI specifications for their CAVs [30].

The BMW group also aims to go from signal oriented to unified vehicle wide
layered Service Oriented Architecture (SOA) architecture with providers and
consumers [24, 31]. This also requires latencies, configurations and bandwidth
options encoded in the system.

The Stellantis group aims at supporting sustainability and user experience use
cases through service oriented solutions. SOA can provide the necessary
scalability previous service development paradigms could not — namely 1
application per ECU — while allowing a firm contract between services [32].

General Motors is also working towards their SDV efforts through the uServices
solution, a set of APIs for developers and Ultifi, a end-to-end software
platform that “will enable Over-the-air (OTA) updates and in-car subscription
services” [33].

Non automakers are also working towards providing automakers with new tools.
Nvidia is also entering the market with a clear AI first
approach151515Developer documentation available at
https://developer.nvidia.com/drive. — the Nvidia DRIVE OS, which includes a
embedded Real-Time Operating System (RTOS), a hypervisor, Compute Unified
Device Architecture (CUDA) libraries and TensorRT, and features such as secure
boot, security services, firewall, and OTA updates161616Developer
documentation available at https://developer.nvidia.com/drive/drive-sdk..
Vector171717Available at https://www.vector.com/ within its ecosystem propose
tools to support development of vehicles with ECUs interconnected by Ethernet
with TSN and of services using AUTOSAR within SOA architectures.

MotionWise [34] proposes a middleware for safe orchestration of vehicle
software across ECUs for automated driving platforms, with support for AUTOSAR
classic and adaptive, Robotic Operating System (ROS), and Data Distribution
Service (DDS) support.

The Eclipse Foundation, within its SDV working group, is also working within
incubating initiatives to define orchestrators and virtualization managers
(Ankaios, Velocitas), vehicle abstraction models (Chariott), a development
platform (Kuksa), an abstraction layer for communication between nodes (eCAL)
and operation system (MoEc.OS) with support for DDS and integration with
environments such as the SUMO and CARLA simulators (further details in section
VI-B). While in an initial development phase, these projects can be a good
future basis for anyone entering the SDV.

Continental, with the Amazon Internet of Things (IoT) for Automotive181818More
details at https://catalog.workshops.aws/awsiotforautomotive/en-US. support,
is also working towards a “a modular multi-tenant hardware and software
framework that connects the vehicle to the cloud”191919More details at
https://aws.amazon.com/pt/blogs/architecture/developing-a-platform-for-
software-defined-vehicles-with-continental-automotive-edge-caedge/..

Autoware, through its Open AD Kit, the first Scalable Open Architecture for
Embedded Edge (SOAFEE) blueprint, enables cloud-native DevOps of autonomous
driving solutions for SDV202020Developer documentation at
https://autowarefoundation.github.io/open-ad-kit-docs/latest/version-2.0/..

Hardware companies such as Renesas propose the AosCloud212121More details at
https://www.renesas.com/us/en/software-tool/aosedge-platform., a solution to
support OEMs and service providers from seamless software installation to
operation in the vehicle, and implement various new services and functional
enhancements simply.

These individual initiatives are being target towards a cooperation. By 2024,
at CES 2024, AUTOSAR, Connected Vehicle Systems Alliance (COVESA), Eclipse
SDV, and SOAFEE announced a “collaboration of collaborations” to “align
efforts in the SDV ecosystem and create a joint SDV vision clear and unified
definition of what constitutes an SDV”, which points towards a brighter future
in SDV with greater interoperability [35].

Figure 5: Overview of the topics involved in modern vehicular development to
be referred, lightly based on [36].

##  III Main building blocks of Software Defined Vehicles

Developing a vehicle within the SDV paradigm (  a ) requires considerations on
several verticals within the context provided by fig. 5:

  * •

Service Oriented Architectures (  b , section III-A): how vehicular services
are developed and communicate between one another and abstractions for the
vehicular service development and for transferring data between services.

  * •

Virtualization techniques and operating systems (  c ,  d , sections III-B and
III-C): how vehicular services are deployed within each ECU, including the
software stack within each ECU and virtualization techniques..

  * •

Intra and inter vehicular communication architectures, protocols and physical
layers (  e , section III-D): how vehicular ECUs communicate with each other —
intra-vehicular communications — and with ECUs on other vehicles — inter-
vehicular and deterministic communications (  f , section III-E): how to
ensure those communications always happen and within the necessary reliability
and timing requirements.

Existing automakers were not agile enough within the development of their
vehicular services [37], which lead to the rise of new automakers, such as
Tesla, in very software-intensive tasks such as autonomous driving.

The SDV paradigm main ideas are not new. Prior to the advent of SDVs, the
automotive industry focus on software was mostly restricted to connectivity
between vehicles and the user’s smartphones to provide basic insights into the
state of the vehicle [38]. By 1998, [39] considered intelligent vehicles as
essential to autonomous transportation, designing a proposal of a vehicle
capable of communicating with a centralized management control system. Also in
1998, [40] proposes that smart vehicles are a junction of communication
architectures, system architecture, sensors, tasks, kinematics and man-machine
interface. The authors propose a communication architecture in a producer-
distributor-consumer pattern with buses such as RS232 and CAN, where time
coherence is necessary. By 2001, a reference model architecture for
intelligent vehicles [41] considered the vehicle as having intelligent control
systems with each layer with one or more computational nodes interconnected
and connected to sensors.

###  III-A Service-Oriented Architecture

With vehicular E/E architectures getting more complex, standards were required
in order to model both the ECUs hardware and the software. The AUTOSAR is a
initiative of vehicle manufacturers based on design by contract [8, 42] for
the development and modeling of vehicular applications through Object Oriented
Programming (OOP) concepts. During the 2000s this initiative aimed at defining
the whole vehicular software stack with support to running several
applications and communication with other services through several buses —
either CAN, LIN or even Ethernet — through an abstraction of the several
hardware possibilities into a Run Time Environment (RTE) [8].

While a very mature _de facto_ standard with the support from vehicle
manufacturers and vendors, AUTOSAR is a highly complex ecosystem, with more
than 100 modules and its documentation reaching more than 21 000 pages [8].
Development through the original Classic Platform is also very hard-coded to
the vehicle and its E/E architecture [43]. AUTOSAR has two different types of
platforms as depicted in fig. 6: the already mentioned Classic, for
traditional hard real-time systems based on micro-controllers with a static
configuration, and set of pre-compiled monolithic binaries; but also a newer
Adaptive platform, for high performance services and ECUs, with greater
flexibility and adaptability to new or changed services. The Classic Platform
is aimed at safety critical systems with hard real-time requirements with a
stated linkage between services and CPU cores, while the Adaptive is aimed at
high performance ECUs [14] and is capable of considering heterogeneous ECUs
and departs from legacy buses like CAN towards a SOA communication
architecture with Ethernet based on Scalable service-Oriented MiddlewarE over
IP (SOME/IP) as bus protocol [44] and is overall more dynamic but less time
predictable [45, 29], essential within critical vehicular systems.

Figure 6: AUTOSAR Classic VS Adaptive.

The SOAFEE222222Available at https://www.soafee.io/. More details at
https://www.arm.com/blogs/blueprint/cloud-native-automotive-development
presents a cloud-native alternative with an architecture enhanced for mixed-
criticality automotive applications with corresponding open-source reference
implementations to enable commercial and non-commercial offerings.

Each ECU can now part of a SOA, where distributed services interact with one
another based on some remote access protocol. In this context, and as defined
by [46], a service is “a mechanism to enable access to one or more
capabilities, where the access is provided using a prescribed interface and is
exercised consistent with constraints and policies as specified by the service
description”. Figure 7 presents an overview of the SOA paradigm.

Figure 7: SOA as perceived by the Renault Group automaker (adapted). Services
are the basic unit of vehicular applications, from simple services that
directly interact with sensors and actuators, up to more complex services —
deployed either in vehicle or in a cloud — that integrate simpler service.
Services communicate with one another via one or more message bus [19].

Service Oriented Architectures are a software architectural pattern where each
component provide and consume services — a discrete unit of functionality —
over a predefined protocol over a network. It can be considered an
architecture following the main definitions of the Actor Model computational
model, since components are decoupled from how the communication is achieved,
allowing asynchronous communication [47]. SOA, when implemented on a vehicle,
on a more reduced set of zonal ECUs, bring benefits such as the decoupling of
hardware and software, increased modularity and separation of concerns, and
contribute towards the overall decrease in hardware complexity. [48]:

At the cost of increased complexity in maintaining contracts between services
and ensuring availability and discovery of the services [48]. This is
particularly complex within a vehicular context, with a SOA supporting at most
60 to 80 services [24], not addressing situations where there are hundreds or
thousands of micro-services.

Within SOA based architectures, data layers can abstract the physical medium
of services by providing a unified way of exchanging and accessing data
between services on different components/ECUs [49]. Three main design
paradigms can be considered for implementing a data layer [50] a) a fully
periodic publisher-subscriber based, b) a fully event triggered client-server
based, or c) a mixed model, with periodic model for non time-critical chains
and event-triggered for time-critical chains.

Information from vehicle sensors can be fed from/to services leveraging the
ECUs and their communication paradigm through data layer solutions like
DDS232323Available at https://www.dds-foundation.org/. middleware, SOME/IP,
Constrained Application Protocol (CoAP) or Message Queuing Telemetry Transport
(MQTT) [29].

Publish/subscribe paradigms — with protocols such as MQTT, DDS or SOME/IP —
can respond to a data centric paradigm, when the data sending is event
triggered, unlike solutions such as Hypertext Transfer Protocol (HTTP) or CoAP
based on the request/response paradigm [25].

Table II provides a summary on some of the main possible solutions for SOA
data middleware.

TABLE II: Qualitative comparison of IoT standards (partially based on [51, 52,
53]).

[t]  Standard MQTT DDS SOME/IP Zenoh HTTP Transport UDP (in MQTT-SN), TCP UDP,
TCP IP UDP, TCP, QUIC TCP, QUIC Paradigm Pub / Sub Pub / Sub Pub / Sub Pub /
Sub Data storage Request / Reply Node Discovery No Yes (SDP and alternatives)
Yes Yes No Fault Tolerance Broker is SPoF Yes, fully distributed by default
Yes Yes, can be fully distributed. Client and server are SPoF Data Schema None
Required Required Only encoding is required Optionalc QoS Policies At delivery
level At multiple entitiesa N/A At 2 levelsb N/A

  * a

For delivery, presentation, transport, availability, cache, resource
management.

  * b

For reliability and fragmentation level.

  * c

Based for example on the Content-Type.

While all these solutions can ensure delivery of data, there is a tendency to
consider DDS and Zenoh the best performant solutions since they provide better
flexibility and performance. According to [54], which compared performance of
MQTT, DDS, and Zenoh, the latter shows (for multi-machine scenarios, more
realistic in zonal vehicular architectures) a double increase on the
throughput of DDS and 50 times of MQTT, while DDS usually provides the best
latency and better flexibility with more QoS levels.

###  III-B Virtualization and orchestration techniques

Considering the need for flexibility but also real-time constraints, ECUs can
leverage virtualization principles to support multiple operating systems, both
real-time and general purpose OSs, through virtualization.

Virtualization provides support for running multiple OSs on the same hardware.
It is an essential concept in the context of vehicular systems, since in zonal
architectures the number of ECUs will tend to be much less than the number of
services and required OSs.

Virtualization allows hardware to be shared and not uniquely assigned to one
operating system, while achieving the necessary isolation automakers require
between critical and non-critical services. Within the responsibilities of the
virtualization layer is the abstraction of hardware and of network topologies
[55]. Virtualization also allows to deploy services in heterogeneous platforms
and ECUs [56].

Virtualization creates a number of challenges, including:

  * •

Orchestration: how to distribute resources (both location and quantity) of the
virtualization continuum across virtual machines.

  * •

Shared I/O: how to distribute input and output devices, such as Universal
Serial Bus (USB) or Ethernet buses, across virtual machines. Allowing
virtualized services to use and share the same Ethernet port for example
requires a scheduler that is capable of communicating with the different
virtual machines and the deterministic network configurator. This
communication can be achieved through hypercalls, the equivalent of syscalls
but to invoke a hypervisor [57]. This may impact however the overall frame
transmission delays.

  * •

Virtualization with real-time performance: since schedulability at hypervisor
level is not deterministic [14].

When virtualization is considered, having the scheduler of the traffic can be
at either application level, virtual machine level or hypervisor level [56].
At applicational level, since there’s one scheduler per application, there are
going to be race conditions between each scheduler, with non-deterministic
behaviors and therefore providing results with high jitter. At virtual machine
level, for example leveraging the Linux Traffic Control subsystem, while the
necessary configurations are transparent to the applications, the hypervisor
will not be aware of the special traffic. Working at the hypervisor level
solves the previous issue through special Hypercalls invoked by the middleware
within the Hypervisor level. Hypercalls242424Similarly to syscalls concept,
hypercalls provide an interface between a guest OS and the hypervisor. may be
used within the middleware to support deterministic networkng within
virtualized intra vehicular services [57].

Vehicular OSs such as Android Automotive provides full support for
virtualization through  Kernel-based Virtual Machine (KVM) and
virtIO252525Developer documentation available at
https://wiki.libvirt.org/Virtio.html devices, allowing support at the Virtual
Machine (VM) side for sensors, graphics, storage, network (including Wi-Fi
through virtio-net and VirtWifi262626Developer documentation available at
https://source.android.com/docs/devices/automotive/
virtualization/architecture.) and with support for communicating with the
vehicle through Google RPC (gRPC)272727Details available at ..

Generic Linux-based OSs also support virtualization through containerization.
Containerized services have advantages over hypervisor virtualization such as
the reduced overhead and reduced storage space usage [13].

Eclipse, within the SDV foundation proposes Eclipse Ankaios282828Developer
documentation available at
https://projects.eclipse.org/projects/automotive.ankaios to “manage multiple
nodes and virtual machines with a single unique API in order to start, stop,
configure, and update containers and workloads”. Ankaios is tailored towards
automotive applications and developed for automotive ECUs and provides a
central place to manage automotive applications, supporting:

  * •

Management of multiple nodes and virtual machines with a single unique API.

  * •

Various container runtimes like Podman and also native applications.

  * •

Automotive Automotive Software Process Improvement and Capability
Determination (SPICE) process with requirement tracing.

  * •

Existing communication frameworks like SOME/IP, DDS or Representational State
Transfer (REST) API can be used with Ankaios workloads.

Kubernetes292929Available at https://kubernetes.io/., as a container
orchestration tool mainly designed for datacenters, can also be consider to
manage vehicular workloads. The work of [58] proposes vehicles as nodes of a
Kubernetes cluster.

Apart from its inherent advantages as container orchestration and scheduler,
Kubernetes is very flexible in networking terms. Networking between containers
can be changed through Container Network Interfaces303030Project available at
https://github.com/containernetworking/cni., a specification for configuring
network interfaces in containers. This allows considering deterministic
networking concepts — further discussed in section III-E — in container
scenarios. For example the work of [59] proposes support for deterministic
networking within Kubernetes containers without modifying the application
binaries — essential to ensure compatibility with existing vehicle services
but also to simplify the development process of new services — through a side
car container that exposes the standard Portable Operating System Interface
(POSIX) socket interface to other containers and redirects traffic to
deterministic configured network interfaces in the host computer. Integration
with cloud infrastructure is also possible. For example, within [60] is
proposed a full-fledged dynamic interference-aware cloud scheduling
architecture for latency-sensitive workloads.

###  III-C Vehicular operating systems

ECUs within a vehicle run services that require deterministic scheduling from
the OS. Failure to have a deterministic real-time scheduling can lead to
services being dispatched too soon or too late to the OS, with dramatic effect
on the services behavior. Therefore, Real-Time Operating System are a need
within vehicular computing domains to ensure services are dispatched in a
determined specific order and time-frame. While many OSs can support real-time
constraints — including any generic Linux kernel based OS with
`PREEMPT_RT`313131Available at https://wiki.linuxfoundation.org/realtime/.
patches [61], some solutions are heavily automotive focused, such as Android
Automotive, Nvidia Drive OS and QNX.

Android Automotive323232Developer documentation available at
https://source.android.com/docs/devices/automotive. Not to be confused with
Android Auto, a platform to use a smartphone as a infotainment alternative.
and its extensions such as SnapOS333333Available at
https://www.snappautomotive.io/snappos provide an OS and a platform that is
based on Android — and can therefore leverage the existing application
ecosystem — while supporting specific characteristics of vehicles, including
the support for the creation of a vehicle abstraction layer required to
abstract the vehicle’s specific/proprietary components, UI support for setting
vehicle’s settings and OTA updates.

Nvidia Drive OS343434Developer documentation available at
https://developer.nvidia.com/drive/driveos is the “reference operating system
and associated software stack designed specifically for developing and
deploying autonomous vehicle applications on DRIVE AGX-based hardware”. It is
in fact a custom RTOS with a Nvidia Hypervisor and necessary CUDA and TensorRT
libraries to fully utilize the hardware (graphical) potential.

Yocto353535Available at https://www.yoctoproject.org/-based OSs are also a
possibility. Yocto supports the creation of custom OS based on Linux, allowing
adding custom layers to embedded systems. Yocto based Wind River
Linux363636Available at https://www.windriver.com/products/linux. is an
example of such family of OS, providing support for multiple board support
packages in both x86 and Arm hardware. Automotive Grade Linux373737Available
at https://docs.automotivelinux.org/, https://github.com/nxp-auto-
linux/auto_yocto_bsp. is another example of a Yocto based OS and a industry
supported initiative to develop software for the “infotainment, instrument
cluster, Heads-Up Display (HUD), telematics, connected car, ADAS, functional
safety, and autonomous driving” [62].

Alternative OSs include the VxWorks383838Available at
https://www.windriver.com/products/vxworks [63], a RTOS for mission critical
embedded systems. While usually considered in spacial scenarios, automotive
are also supported for example through the integration with AUTOSAR Adaptive
Platform. The QNX393939Available at https://blackberry.qnx.com. is another
alternative as a micro-kernel RTOS with extensive foothold in the automotive
sector installed in more than 215 million vehicles. Another open source
initiative, albeit in initial stages (launched by January 2024), is the
Eclipse ThreadX404040Previously Azure RTOS. Available at https://threadx.io/,
with developer documentation at
https://projects.eclipse.org/proposals/eclipse-threadx., an open-source,
vendor neutral RTOS.

Vehicular services should be developed independently of the RTOS and thus an
isolation between the services and the RTOS is desired. Initiatives such as
Operating system abstraction layer (OSAL) from IBM414141Developer
documentation at https://www.ibm.com/docs/en/engineering-lifecycle-management-
suite/design-rhapsody/9.0.2?topic=references-operating-system-abstraction-
layer-osal. or NASA consider “isolates embedded application software from a
RTOS” by providing “a well-defined, generic interface to RTOS
services”424242More information at
https://opensource.gsfc.nasa.gov/projects/osal/. and can, therefore,
contribute to the necessary portability of services between RTOS.

These operating systems, being mostly RTOS or RTOS-like, can be evaluated
through the worst-case execution time for each task, modularity, response time
or jitter [64]. At the time of writing, no comparison between some or all of
the aforementioned OSs was found, with the choice of OS mostly related to the
associated ecosystem (such as already available applications or SDKs).

###  III-D Inter- and intra-vehicular communication

Vehicular systems need to communicate both with other systems within and
outside the vehicle. While most intra-vehicular communication is expected to
be through wired physical layers, this does not have to be the norm. It is
impractical to consider wired physical layer for inter-vehicular contexts.

Within inter-vehicular contexts, the Vehicle to Everything (V2X) paradigm, is
of increasing importance considering the advent of both Vehicle to Vehicle
(V2V) scenarios and smart cities.

The usage of cloud infrastructure is also an integrated part of the SDV
paradigm, requiring Vehicle to Infrastructure (V2I) wireless communications.
For example, CARIAD, the initiative from the Volkswagen group towards SDVs,
launched an uniform application store for all brands within the Volkswagen
group [27], that indicates a strong cloud presence within its ecosystem.

While intra-vehicular systems tend to be interconnected with CAN, LIN,
FlexRay, or Media Oriented Systems Transport (MOST), they are unsuitable to
the higher volume of data and interconnections of centralized architectures.
Therefore, existing solutions, such as Ethernet, if associated with
determinism mechanisms (further discussed in section III-E), can provide the
required time-critical high throughput to both Input/Output (I/O) and control
data streams [14].

TABLE III: Overall comparison of main intra vehicular wired buses [14].

[t]  Characteristic / Bus LIN CAN FlexRay Ethernet Media 1 wire UTP 2/4 wires
UTP Topology Bus Bus Star, bus Star Access control Master-slave Priority-based
messages TDMA Switched point-to-point link Max. Baud Rate 19.2 Kb/s 1 Mb/s, up
16 Mb/sa(XL) 10 Mb/s 10 Mb/s, 100 Mb/s, 1000+ Mb/s MTU (Bytes) 8 8/64 254 1472
(UDP), 1460 (TCP), 9000 (Jumbo) Max nodes 16 (1 master) 16 (500 Kb/s) 22
(bus), 22/64 (star), 64 (mixed) 256 to theoretically limited Security Modules
None SecOC SecOC MACsec, IPsec, TLS/DTLS, SecOC

  * a

If disregarding recommenced maximum data-rates [4].

CAN has a limitation of 1 megabit per second of date rate, while CAN Flexible
Data Rate (CAN-FD) raises the practical maximum date to 6 megabits per second
with a higher 64 byte data field, while keeping the limitations on number of
nodes and cable length [14].

While legacy buses like CAN or LIN can and will continue to be on edge intra
vehicular systems, such as smaller more specific ECUs, sensors and actuators,
the long term objective is the edges nodes to be also connected through
Ethernet [65]. In the meantime, automakers aim at integrating legacy CAN or
LIN based components by integrating in zonal ECUs CAN controllers or gateways
[66].

While these limitations could be overcome in the past with a static analysis
of the overall vehicular systems and ECUs, the growing number of features,
specially data-intensive features related to (semi) autonomous driving,
required an increase in the volume of the overall wiring warness both in terms
of number of wires and of complexity (with heavy at least 40-50
kg434343Source: https://semiengineering.com/shedding-pounds-in-automotive-
electronics/.) now commonplace).

Current LIN bus based solutions also limit the overall system and the number
of devices. The BMW group, for example, is working towards an SOA to support
for example new solutions of in vehicle ambient lighting [65]. Other buses,
such as CAN can support more LEDs, but Ethernet — in conjunction with Time
Sensitive Network (TSN) can better support an accurate 20 LED update deadline
without jitter and necessary synchronizations to support multi LED lighting
animations.

In addition, the CAN — and its variations, such as LIN444444Lower cost bus
with just 2 wires (including ground) at the cost of lower throughput. — is
based on broadcasting messages. This contributes towards the biggest flaw of
the CAN — its fragility to the injection of counterfeit messages454545Example
at https://kentindell.github.io/2023/04/03/can-injection/.. While filtering of
messages (at the receiver level) is a possibility, it requires additional
implementation on software (increasing the overall development complexity),
and does not guarantee the CAN bus capability of handling and delivery other,
genuine, messages is not affected [4].

Ethernet, within the context of vehicular networks, is being more and more
considered as the backbone connection between high performance ECUs, with
gateways to legacy buses like CAN. Several physical layer specifications can
be considered, including IEEE 100BASE-T1, 1000BASE-T1, and 1000BASE-RH [67,
68]. Possible Ethernet backbone upgrades to ensure future scalability are also
being explored, including 10BASE-T1S or multi-Gb links.

As depicted in fig. 8, there are multiple iterations of Ethernet standards,
i.e. there’s not a single cable and solution for all scenarios. Automakers
shall take into consideration the characteristics of the cables (such as
width, weight or resistance to heat and vibrations)— and not only the
theoretical bandwidth — in order to choose the best ones to interconnect
vehicular ECUs.

Figure 8: Evolution of Ethernet data rate and standards over time [68]

Common to all the alternatives, Ethernet presents several advantages,
including longer payloads, higher bandwidth, the possibility to support QoS or
multiple protocol layers [66]. Ethernet is capable of greater bandwidth
(compared to 1 / 16 of the CAN / CAN-FD baud-rate) and can transmit data with
low latency and jitter [68]. The work of [69] proves the overall better
performance of Ethernet than FlexRay in the end-to-end latency for the tested
use case (a simulated Electronic Stability Control module).

To this goal, major automakers and their providers have created the OPEN
Alliance (One-Pair Ether-Net)464646Available at https://www.opensig.org/.
initiative. Canonical also defends E/E architectures which combines and
consolidates ECUs and interconnects them using an Ethernet network [6]. Such
solutions could also benefit from industry grade protocols, such as
PROFINET474747Details at https://www.profibus.com/technology/profinet/..

Ethernet can be integrated with CAN for example through the CAN-XL protocol.
This is done by mapping an Ethernet frame into a CAN-XL frame. Since CAN-XL
provides 2048 data bytes, Q-tagged or enveloped Ethernet frames fit into a
CAN-XL frame [70]. Examples of gatewaying strategies from CAN to Ethernet has
been presented by [71], including FPGA based gateways with suitable latency,
routing mechanisms between Ethernet and CAN or FlexRay, with the authors
proposing a gatewaying up to the application layer — SOME/IP in this case
through a SOME/IP service and a RTOS program that read the CAN messages.

Other alternatives Unlike CAN, FlexRay manages the medium with Time-Division
Multiple Access (TDMA). FlexRay has a communication cycle with an explicit
stage (the Network Idle Time) necessary to maintain synchronization between
node clocks.

FlexRay has the unique ability to sync up nodes on a network without an
external synchronization clock signal. To do so, it uses two special types of
frames: Startup Frames, and Sync Frames. Like CAN, if not properly configured,
may create starvation for some slots of data [72]. This protocol considers a
eXtended Markup Language (XML) file format, the FIeld Bus EXchange, which
contains configuration details on a network, including signal definitions,
bit-level encoding of signals, information on network topology (e.g.
information on the ECUs) and configurations (such as baud rates and timings).

MOST is an alternative. The MOST specification defines “the protocol, hardware
and software layers necessary to allow for the efficient and low-cost
transport of control, real-time and packet data” using “different physical
layers (fiber optic, UTP, coax)” and supporting 25, 50 and 150 Mbps data
transfer speeds [73].

Vehicular nodes can use different wireless access technologies to communicate
with other road elements, including vehicles (V2V), pedestrians ( Vehicle to
Pedestrian (V2P)), and infrastructure (V2I), creating a Vehicular Ad-hoc
Network (VANET), a sub-type of a Mobile Ad-hoc Networks. These technologies
can be classified based on their communication range [74], with a summary of
the main characteristics of the most used access technologies described in
table IV.

TABLE IV: Example of wireless vehicular communications access technologies and
main characteristics.

[t]  Technology Data Ratea Range Latency Cellular (LTE) [75] 100/50 Long ($>$
1) 10-100 Cellular (LTE-A) [75] 3/1.5 Long ($>$ 1) 10 Cellular (5G) [75, 76]
20/10 Long ($>$ 1) $\leq$ 4 Wi-Fi (IEEE 802.11be)c $\leq$ 40 b Short ($<$ 90
in 2.4) 10 [77] Li-Fi (IEEE 802.11bb) [78] 10 up to 9.6 Short (few meters)d
Lowe Third Generation Partnership Project (3GPP) C-V2X [79] $\leq$ 26 [80]f
Short to Long Low ITS - G5 (IEEE 802.11p) [79] $\leq$ 3 up to 27 [80] Short
($<$ 1) Low IEEE 802.11bd [81]g $2\times$ IEEE 802.11p $2\times$ IEEE 802.11p
Low

  * a

Downlink / uplink.

  * b

Theoretical.

  * c

Details at https://standards.ieee.org/beyond-standards/the-evolution-of-wi-fi-
technology-and-standards/.

  * d

As described at https://spectrum.ieee.org/li-fi-better-than-wi-fi.

  * e

Up to 1 as claimed by https://emag.directindustry.com/2021/07/20/li-fi-shines-
as-the-future-of-short-range-communications-light-led-microchip-radio-
waveband/.

  * f

Considering Long Term Evolution (LTE) based C-V2X and as claimed by
https://eu.mouser.com/applications/new-v2x-architectures.

  * g

Theoretical values.

Cellular based solutions, either through LTE, Long Term Evolution Advanced
(LTE-A) or 5G, can provide connection to other vehicles and infrastructure,
with high coverage and medium latency at a high monetary cost [79].

Wi-Fi, including its latest iteration (Wi-Fi 7 / IEEE 802.11be), can also
theoretically provide connectivity to and from vehicles, as well as IEEE
802.11bb / Li-Fi. Li-Fi adapts the Media Access Control (MAC) layer of 802.11
while supporting light (visible or infrared) based physical layers in order to
overcome interference in dense deployments (which Wi-Fi is particularly
susceptible to) and restrictions or inefficiencies of radio frequencies -
potentially increasing the maximum. An evolution of the original infrared
physical layer proposed in 1999 for IEEE 802.11, it is targeted at the
industrial markets [82]. However, both solutions fail to consider the high
mobility of vehicular nodes, which means frequent handovers between access
points.

Vehicular targeted standards exist. Cellular Vehicle-to-Everything (C-V2X) is
cellular based and aims at integrating cellular technologies within V2V
scenarios. Based on cellular standards (5.9 GHz band), it also allows direct
device-to-device (ad-hoc) communication with low latency and high reliability,
but in short ranges (±1 km), with low cost/free of cost. C-V2X also support
device-to-network, enabling cloud services to be part and parcel of the end-
to-end solution.

ITS-G5 is based on IEEE 802.11p for physical and MAC layer. It requires
existence of road infrastructure — Road Side Units — and that vehicles are
equipped with On-Board Units. It suffers from problems on handling handovers
and scaling to many nodes simultaneously. It is also vulnerable to packet
collisions due to concurrent transmissions, and packet collisions due to
hidden vehicular nodes.

Existing literature shows that C-V2X offers performance advantages over ITS-G5
in terms of its additional link budget, higher resilience to interference, and
better non-line-of-sight capabilities [83].

Radio Access Technology (RAT) evolutions, such as the IEEE 802.11bd and New
Radio for C-V2X can supplement today’s vehicular networks in supporting higher
bandwidth and QoS wireless communications. IEEE 802.11bd are more suitable for
supporting more V2X applications efficiently, with better throughput and low
transmission latency. IEEE 802.11bd adapts the physical and MAC layer
techniques introduced in IEEE 802.11n/ac/ax, while ensuring interoperability
and backwards compatibility with 802.11p. This implies that 802.11bd and
802.11p devices must be able to communicate with each other while operating on
the same channel [84]. IEEE 802.11bd also considers re-transmissions, Dual
Carrier Modulation and operates also in the mmWave spectrum.

Both ITS-G5 and C-V2X can reliably support safety applications that demand an
end-to-end latency of around 100 as long as the vehicular density is not very
high [85]. However, as the quality of service requirements of V2X use-cases
become more stringent, which is the case in many advanced V2X applications
[86], the two current RAT fall short of providing the desired performance,
since some use-cases require the end-to-end latency to be as low as 3 with a
reliability of 99.999 [84].

###  III-E Deterministic inter- and intra-vehicular communication

The usage of deterministic communications and networks that support such
communications is vital when considering vehicular services that are somehow
critical. Determinism “is the quality or state of being
determined”484848Definition per Merriam-Webster dictionary, available at
https://www.merriam-webster.com/dictionary/determinism., i.e. the quality of
being firmly resolved. Within networks this concept can be regarded as the
delivery of units of information — either abstracted in frames or packets or
other abstraction — in a fully resolved manner in several domains, such as
temporal or reliability, in all the steps of the frame/packet from the
producer to the consumer(s) of information.

Regarding the temporal determinism, within the exchange of a unit of data
between two network entities one may consider the main steps of a packet
switching as presented in fig. 9.

Figure 9: Main steps of a packet switching. Partially adapted from [87].

Each step introduces delay that, if the network is not properly configured,
can be unbounded and potentially even random. Even if high bandwidth is a
possibility, transmission, and queuing delays still exist, affecting end-to-
end delay [83, 85].

High performance and high precision of services running through a
communication network should consider not only techniques to decrease the
overall end-to-end latency of data from/to services — for example by
leveragging the edge computing concept [88, 89] — but also techniques to
ensure the latency requirements and real-time hard constraints are followed.
Sets of standards such as TSN494949Details at https://1.ieee802.org/tsn/. and
Deterministic Networks505050Details at
https://datatracker.ietf.org/wg/detnet/about/. can ensure that any critical
messages from/to services arrive with high reliability and that arrive at the
exact supposed moment [90].

Current solutions to tackle these issues within the TSN and Deterministic
Networks are further presented in section III-E. The next subsections present
the state-of-the-art on the main initiatives and sets of standards towards
determinism in networks in lower Open Systems Interconnection (OSI) layers.
These initiatives started for wired mediums such as Ethernet but can also be
extended to wireless contexts.

####  III-E1 In wired context

Methods towards achieving deterministic communications within a wired context
— such as the connectivity between vehicular ECUs — are being standardised,
with two major initiatives to be considered: the Institute of Electrical and
Electronics Engineers (IEEE) TSN set of standards, operating at OSI layer 2;
and Internet Engineering Task Force (IETF) Deterministic Networking (DetNet)
operating at OSI layer 3. The next subsections will focus on both initiatives
that shall be seen not as competitors but as complementary initiatives.

Deterministic Networking (IETF DetNet) The IETF Deterministic Networking set
of standards aim at defining deterministic — i.e. with bounded latency, loss
and jitter — paths for the packets [91]. Those standards operate at layer 3 on
a SDN approach, where one or more controllers are responsible for defining the
nodes behavior, to warrant [92]:

  * •

Explicit routes: to ensure deterministic routing. This may be achieved for
example through the usage of Multiprotocol Label Switching (MPLS), a routing
technique based not on network addresses but labels.

  * •

Resource allocation: to ensure protection against congestion, resources (such
as bandwidth) is allocated.

  * •

Service paths: to ensure protection against equipment and medium failures
packets are replicated through disjoint paths.

Table V provides an overview on the Request for Comments (RFC) standards and
documents that define the goals, use cases and building blocks behavior.

TABLE V: Main DetNet standards, specifications and documents.

Document |  Goal |  Importance
---|---|---
RFC 8557 |  Problem statement |  Contextualizes the need for DetNet with the need for a deterministic forwarding of packets.
RFC 8578 |  Use cases |  Validates self-driving vehicles as examples of use cases that can be addressable by DetNet techniques.
RFC 8655 |  Architecture |  Defines the main building blocks of DetNet.
RFC 8938, 8939, 8964, 9023, 9024, 9025, 9037, 9056 |  Data Plane |  Defines how building blocks may be implemented and metadata that packets require. Includes information of integration with TSN and MPLS for explicit routing.
RFC 9016 YANG model (draft [93]) |  Flow information model |  Modelling of the configuration information for configuration of DetNet building blocks.
RFC 9055 |  Security |  Considerations on security, including challenges posed by replication of packets and spoofing.
RFC 9320 |  Bounded Latency |  Provides mathematical modelling of the bounded latency values for a DetNet architecture.

The DetNet building blocks operate at the Internet Protocol (IP) layer and use
lower-layer technologies such as MPLS and TSN (further discussed in section
III-E1). These building blocks can and should be controlled based on
observable metrics (hops, their state, and end-to-end latency), and on fault
detection/prediction and identification [92].

Two open questions remain: (1) whether DetNet protocols will include a way for
an application to communicate expectations regarding such timing properties to
the network and (2) if so, whether those properties would likely have a
material effect on network performance as a result [94].

Time Sensitive Networking (IEEE TSN) The Time Sensitive Network group presents
an effort to solve transmission, and queuing delays issues, by adding to
Ethernet time characteristics, performance, reliability, and security.
Mechanisms include time synchronization (gPTP [86]), replication and
elimination for reliability (e.g. Frame Replication and Elimination for
Reliability (FRER)) [95], and bounded low latency (such as credit-based [96]
or time aware shaping algorithms [97]) that can provide the necessary real-
time performance and bounding of the latencies [98, 99, 100].

Table VI provides an overview on the IEEE standards and documents that define
the goals, use cases and building blocks behavior. The TSN standards are an
evolution of existing standards, the Audio Video Bridging (AVB) standards,
dedicated to extending the Ethernet standards to provide guaranteed quality of
service by ensuring high precision time synchronization between nodes, bounded
latency of high throughput streams (at $\mathrm{\SIUnitSymbolMicro s}$ scale)
and reservation of bandwidth within audio and video scenarios. The TSN toolbox
of standards add reliability concerns, more accurate clock synchronization,
bounded low latency even for real-time streams (at $\mathrm{\SIUnitSymbolMicro
s}$ scale) and security concerns [101]. As a comparison, “the design goal of
the AVB was a maximum latency of 2 over 7 hops in a 100 network for audio and
video traffic”, while TSN standards set “the goal to set the maximum latency
to 100 over 5 hops” [102]. Through the IEEE 802.1Q standard three types of
traffic classes for such traffic are defined — Scheduled Traffic (with precise
scheduling), Stream Reservation (which needs to be configured in order to
ensure fairness) and Best Effort [56].

TABLE VI: Main TSN standards [103] (partially adapted).

Document |  Goal |  Importance
---|---|---
802.1Qca |  Path control and reservation |  Define mechanisms to allocate resources to transmit frames.
802.1Qbv |  Time-aware scheduling |  Defining when and what frames are sent by the emissor.
802.1Qbu, 802.3br |  Frame preemption |  Defines the possibility of higher priority frames interrupting lower priority, essential in ensuring precise transmission time for higher priority flows.
802.1Qcc |  Central configuration model |  Defines the need for coordination nodes (the CUC and CNC). Updates on the SRP protocol.
802.1Qci |  Filtering and policing |  Defines mechanisms to count and filter frames and detect and mitigate disruptive flows of frames.
802.1CB |  Redundancy through frame replication and elimination |  Defines mechanisms to replicate frames and manage the repeated frames to increase reliability of the network and avoid equipment failure impacting PER and similar metrics.
1588, 802.1AS |  Precise ($ns$ level) time synchronization between nodes |  Defines mechanisms for a nanosecond synchronization between clocks of several network nodes.
P802.1DG (draft) |  TSN profile for automotive in-vehicle Ethernet communications. |  Recommendations for TSN implementation within vehicular architectures.

In conjunction to DetNet, but operating at OSI layer 2 — and originally on top
of wired Ethernet networks — the IEEE 802.1 Time Sensitive Network set of
standards provide mechanisms for [103]:

  * •

Time synchronization: applications and other network mechanisms require a
precise (down to nanosecond accuracy) synchronization between the nodes of the
network. Protocols such as Precision Time Protocol (PTP) [86] can provide such
precision within wired and wireless networks. Synchronization should have into
mind the physical layer latencies and their variations since they can affect
the propagation delay measurement and the overall sync time accuracy. IEEE
802.3cx proposes a mechanism to report the physical layer delays in a dynamic
way [104].

  * •

Replication and elimination for reliability: improve the reliability by
ensuring frames of information are replicated and sent through disjoint paths.
This replication needs additional mechanisms to ensure repeated frames are
ignored. Protocols such as FRER [95] can manage this replication.

  * •

Resource management: Mechanisms to ensure the configuration of TSN talker,
listener and of equipment between both.

  * •

Bounded latency or bandwidth: ensure the bandwidth or latency and its jitter
is deterministic by ensuring transmission happens at a specific time. Traffic
shaping can provide the necessary real-time performance and bounding of the
latencies or bandwidth [98, 99, 100], with shapers such as:

    * –

Credit Based Shaper (CBS) [96] based on regulating the transmission rate of
frames to smooth out traffic, reduce bursts and ensure bandwidth for certain
traffic classes, by delaying the transmission of some frames. When the queue
contains a frane to be transmitted, a credit counter is checked and the frame
is only transmitted if the counter is non-negative (and if it is, is held back
until is non-negative). This counter accumulates credits when the transmission
queue is idle, and consumes credits when frames are transmitted, with the rate
of accumulation and consumption configurable via parameters (idle slope and
send slope)515151More details at
https://inet.omnetpp.org/docs/showcases/tsn/trafficshaping/
creditbasedshaper/doc/index.html..

    * –

Time Aware Shaper (TAS) [97] that works by associating the data to traffic
classes and the traffic classes to gates that open and close at specific times
and for specific intervals of time, ensuring no unwanted competition between
traffic classes that should not compete for transmission, therefore
eliminating the jitter associated with that competition [105].

    * –

Asynchronous Traffic Shaping (ATS), which is based on the leaky bucket
principle, with transmission allowed when credit is greater than the size of
the frame [102].

How the network should be configured is also addressed through the IEEE
802.1Qcc standard, which describes three possible models [106]:

  * •

A fully distributed model where all the end stations communicate their
requirements — through protocols such as Stream Reservation Protocol (SRP) or
Resource Allocation Protocol (RAP).

  * •

A centralized network/distributed user model, where the Centralized Network
Controller (CNC) gather the network capabilities.

  * •

A fully centralized model, where the CNC is helped by the Centralized User
Configuration (CUC) to ensure proper network equipment configuration.

These three models are based on the existence of two entities — the CNC and
the CUC. The CNC defines the overall network schedule and is the main
controller of the network within the network bridges, dispatching
configuration with protocols such as Network Configuration Protocol (NETCONF).
The CUC mediates the requests between end devices and their applications
[107], collects all user requirements and interacts with the CNC to decide the
topology and scheduling of the network. Figure 10 provides an overview of
these interactions.

Figure 10: Interaction between CUC, CNC and the remaining TSN topology [107].

TSN is not however the only standard at layer 2 for deterministic
communications. Time-Triggered Ethernet (TTEthernet), a standard for
industrial and avionics applications improved from the Avionics Full Duplex
Switched Ethernet, can be a standard to consider [14]. While the concepts of
deterministic timing of the transmission of frames is inherently the same,
both differ in a number of aspects [108, 109]. TSN is a set of standards while
TTEthernet is a specific Society of Automotive Engineers (SAE) AS6802
standard. In the former, the schedule is on entire traffic classes, while in
latter is on individual frames. In addition, TSN supports lower-priority
traffic using non-used bandwidth, while TTEthernet blocks other traffic even
when there are no time-scheduled frames to transmit results in efficient use
of bandwidth.

####  III-E2 In wireless context

While wired network access mediums have well defined / bounded error rates,
based essentially on the electromagnetic noise ratio, wireless mediums are
prone to the creation of unpredictable non-stochastic jitter and packet losses
through additional issues and challenges, including [103]:

  * •

Fading of the transmission: based on distance between nodes, changes in the
propagation environment or node mobility.

  * •

Interference from other devices communicating on the same spectrum
frequencies. This issue is more pronounced when unlicensed spectrum (e.g. 2.4
GHz) is used since its usage is uncontrolled and prone to additional noise
from other uncontrollable entities.

  * •

Shadowing and attenuation from other physical obstacles and phenomena (e.g.
reflection, absorption, diffraction) [110].

  * •

Random channel access latency: the randomness associated with existing listen-
before-talk procedures for multiple access to the wireless channels
contributes to non-stochastic delays.

  * •

Integration of synchronization mechanisms: while considering the differences
in propagation time in wireless communications.

  * •

Bounding an end-to-end latency or its jitter by integrating scheduling on
transmission by each Access Point (AP).

  * •

Integration of reliability techniques while considering and taking maximum
advantage of the main different channel characteristics.

  * •

Resource management: including the usage of several APs for reliability or the
dynamic management of the spectrum used at a given moment, which remain open
challenges.

Achieving determinism within a wireless communication requires that all these
challenges are properly addressed.

While fading, interference, shadowing and attenuation are mostly unavoidable
without changes to the physical environment, interference can be minimised.
The usage of other parts of the spectrum, possibly licensed, with wider
channels, and frequencies in multiple links working in conjunction (multi link
operation) can further decrease the overall noise within the physical layer
and therefore decrease the jitter of latencies, and increase the determinism
of the communications [103]. In addition, a periodic analysis of the spectrum
usage can support a decision on the best frequencies to be used.

Regarding the unpredictable time to access the wireless medium, existing
listen-before-talk solutions such as Carrier-Sense Multiple Access (CSMA)
consider that in the event of a collision, before re-transmission a random
amount of time shall be waited. This creates an unpredictable, non-
deterministic jitter on the transmission of information. Other channel access
solutions must be considered in order to achieve higher determinism on the
transmission of the frames through both a wired or wireless medium, such as
dividing the channel per frequency, time or both — Frequency-Division Multiple
Access (FDMA), TDMA and Orthogonal FDMA (OFDMA), respectively — or adding
scheduling algorithms to listen-before-talk solutions [111] — CSMA-Collision
Avoidance (CSMA-CA). In alternative, solutions that consider collisions to be
solved at the receptor side — e.g. Non-orthogonal Multiple Access (NOMA) — can
also be considered.

Another promising solution is a coordination and scheduling of the access to
the wireless medium to ensure not fairness or throughput — the usual concerns
— but the fulfillment of a specific time of transmission, ensuring more
determinism than the previous approaches [103].

Within wireless mediums, the usage of the IEEE 802.11be (Wi-Fi 7) concept of
restricted Target Wake Time (rTWT) — originally introduced for power saving —
can further decrease conflicts during transmission. By defining when a certain
station cannot transmit — and therefore any transmission ends before the start
of this time — it is possible to further decrease collisions between critical
and less critical frames being transmitted simultaneously.

Projects such as PREDICT-6G [112] and DETERMINISTIC-6G [113] defend that,
since the wireless environment has a non-stochastic jitter that is unavoidable
(at the very least because of fading, interference, shadowing and
attenuation), any system should adapt to those variations. Such adaptation can
be done through online (in runtime) prediction of the variability of latency
and jitter through monitoring of the system and prediction on Key Performance
Indicators (e.g. instantaneous availability) to then act on resource
allocation and schedules. To support this prediction, models of the channel
behaviour can be considered to model the performance of the channel based on
the medium conditions, transmission power, an angle or distance between nodes.
Such models are not a one size fits all solution, with each different
environment requiring a different analysis [103].

Regarding the integration of synchronization mechanisms, the IEEE 802.11
standards provides time synchronization capabilities through a mechanism named
Timing Synchronization Function (TSF) that supports a low precision
synchronization with a maximum of 1 second of accuracy [114]. The TSN standard
for high precision synchronization, the IEEE 802.1AS (PTP) defines a profile
for 802.11 mediums [103] that considers within the synchronization of the
clocks an estimation of the propagation delay and based on the number of
neighbours of the nodes.

Regarding the bounding of end-to-end latency and jitter, the integration of
shaping techniques, namely TAS/802.11Qbv or ATS is possible. Solutions for
integration include mapping the scheduling policies to each transmission queue
within an AP and by adding to each frame fields with the flow identification
and characteristics (delay bound, maximum packet size) to map the scheduling
policies to the 802.11be MAC. The overall scheduling requires a full knowledge
of the network topology.

Regarding reliability, including FRER (TSN standard IEEE 802.1CB) through
redundant wireless links and channels is possible. The usage of several APs,
with the necessary seamless predictive handover between APs, remains however
an open challenge [114]. In addition, management of the transmission power can
further improve the reliability by decreasing the impact of interference and
obstructions in the transmission.

Finally, regarding the resource management, the need for some sort of
centralization in decision making for the configuration of the network nodes —
APs and switches — is supported both by TSN and DetNet standards. TSN IEEE
802.1Qcc standard define that 2 entities — the CUC and CNC — are responsible
for monitoring and defining resource allocation and configurations [114],
while the DetNet Reference Architecture [92] considers the existence of a
Controller Plane responsible for “topology discovery and maintenance, packet
route selection and instantiation or path fail-over mechanisms” [115]. An
architecture should therefore consider the existence at least of a controller
that configures and monitors the network nodes and the information flow.

All the previous points can benefit from more flexibility and performance with
a deployment using FPGAs [116]. FPGAs, by allowing the reconfiguration of the
hardware to fit the needs of the application(s), can support the deployment of
new wireless APs that combine the previous techniques accelerated by hardware.
Such acceleration is essential to ensure the processing times are sufficiently
small to allow determinism in the overall communication.

Examples of such hardware assisted solutions is the openwifi525252Source code
available at https://github.com/open-sdr/openwifi. stack or the work in [117],
which introduces a custom 802.11 and TSN inspired solution that allows ultra
low control cycles (within 100), reduced jitter (within the $\mathrm{ns}$
barrier) and low Packet Error Rate (PER) (less than $<10^{-7}$ for distances
to the AP between 6 and 12 and $5\times 10^{-6}$ for distances greater than
23) through a FPGA implemented solution for APs. Each node contains several
modules implemented in a FPGA:

  * •

Timer: used by the scheduler, is synchronized by an external Pulse Per Second
(PPS) signal.

  * •

Scheduler: operating at level 2, decides which frames should be sent and when
are they due.

  * •

Custom MAC: contains information for controlling frames, with changes from the
original 802.11 access scheme to avoid collision between real-time and non-
real-time frames and support the synchronization between clocks.

  * •

Physical layer: The encoder/decoder and additional hardware modules required
for modulation features.

A promising solution that however lacks full testing in mobility scenarios,
integration with TSN and integration with other wireless standards such as
5G-NR. Such integration with cellular communication technologies is possible.
3GPP Releases 16-18 defends that, ensuring ultra reliable and low latency
communications start at the radio level. TSN standards should be added to the
overall architecture, with parts of the 5G core acting as TSN bridges [114],
one per 5G User Plane Function (UPF) [118]. This allows a transparent
integration of 5G systems with a TSN system but require a set of translators
between the 5G control plane and TSN standards [119].

The configuration of the TSN network is based on the 5G configuration, with
the mapping between the TSN network configurations [120] — such as priorities
or TAS gate opening times — and 5G QoS parameters — such as the 5G QoS
Identifier (5QI), a scalar that represents characteristics such as [118, 121]:

  * •

Resource Type: Guaranteed Bit Rate (GBR), Delay Critical GBR (DC-GBR) or non-
GBR, where the first two can pre-allocate resources.

  * •

Priority Level: indicates a priority in scheduling resources. Can be used to
prioritize the allocation of resources to certain flows.

  * •

Delay Budget: an upper bound of the time a packet can spend inside a 5G system
(between the User Equipment (UE) and a UPF) without being dropped.

  * •

Packet Error Rate: a ratio between the number of received packets and the
number of transmitted packets.

The algorithms for mapping the TSN configurations to 5G configuration values
are current research topics.The work of [122] proposed mapping the default
priority value of a 5G frame to the Priority Code Point (PCP). Other work by
[123] consider that TSN frames shall be considered DC-GBR, while [121] propose
the mapping of TSN traffic into 5G QoS 5QI characteristics. For example, the
resource type characteristic is derived from the type of TSN flow: deadline
constrained, jitter constrained or bandwidth constrained, per the truth table
in table VII, with similar analysis for the other characteristics within 5QI.

TABLE VII: Mapping between TSN flow characteristics and 5QI values by [121]. Deadline | Jitter | Bandwith | GBR | DC-GBR | Non-GBR
---|---|---|---|---|---
0 | 0 | X | 0 | 0 | 1
0 | 1 | 0 | 1 | 0 | 0
0 | 1 | 1 | 0 | 1 | 0
1 | 0 | 0 | 1 | 0 | 0
1 | 0 | 1 | 0 | 1 | 0
1 | 1 | 0 | 1 | 0 | 0
1 | 1 | 1 | 0 | 1 | 0

While most current work is towards exploring future industrial integration
between 5G and TSN [119], real applicability remains limited. This is
partially due to the lack of interoperability between 5G and TSN-capable
equipment, with configuration usually considering propriety mechanisms or at
least standard mechanisms with exceptions [106]. In fact, according to [106],
no tool has been contributed within the TSN-5G interaction, with most work
regarding high precision synchronization support — which 5G network support
through IEEE 802.1AS with a time error limited to 900 [119] — and proof-of-
concept architectures and mathematical analysis. A notable exception is the
work by [124] which presents “a prototype 5G system integrated with a TSN
network for a typical industrial mobile robotics use case”. The prototype is
based on commercial solutions for a 5G system and TSN switches for
deterministic communications between an application in the factory cloud and a
mobile robot for a factory floor environment. Results of such integration were
promising, with end-to-end latency below 0.8 and, more importantly, with a
99.9% reliability and jitter in the order of 500.

The integration of deterministic communications is not exclusive to TSN
standards. DetNet standards can be used in conjunction with TSN standards to
provide both upper and lower latency boundaries (while TSN can only ensure an
upper bound), better scalability and interoperability with existing IP
infrastructure (since it acts on OSI layer 3) [125]. Both sets of standards
can act simultaneously, with [125] proposing that each TSN domain would be
mapped into a subnet (or a tunnel) of a DetNet network, as depicted in fig.
11.

Figure 11: Examples of integration of TSN and DetNet may be considered within
a 5G system [125].

####  III-E3 In vehicular context

Solutions to adopt TSNs within the vehicle’s systems are sparse and moreless
recent, with some of the oldest integration within vehicular systems in 2016
[126], and further integration in recent years [127, 128], including with 5G
[129, 130]. In addition to 5G, both wired and wireless technologies based on
IEEE 802.11p or IEEE 802.11bd should be considered within these networks,
ensuring that service(s) can communicate with the vehicle’s systems and
surroundings with reliability and redundancy.

The challenges on TSNs within vehicular contexts are two-fold: for one, the
automotive use case is a critical scenario, which requires well defined
latencies, ordering and high level reliability; on the other side, the high
dynamism of the intra and inter vehicular topology — each vehicle may have a
different set of sensors and actuators, creates the need for a more
automatized TSN configuration that can be adapted to different streams.

The work of [131] discusses how to characterize the traffic — frame size,
period, deadline constrains, priority, proportion of streams and how to
analyze efficiency — overload analysis, scheduling analysis, and spacial
complexity/memory usage. This can be a basis for a TSN configurator to decide
the mapping between the streams within the vehicular network and the necessary
TSN shapers configurations.

Not only TSN has to be properly configured, but interoperability with other
protocols must be assured. Ethernet with TSN must coexist and be interoperable
between with other wired and wireless access technologies, including legacy
automotive standards such as CAN. The synchronization strategies between the
vehicular Ethernet backbone and CAN sync is current investigation by [19, 71],
with three strategies to consider:

  * •

Periodic snapshot: periodically all original frames are mapped unto 1 or more
frames of the destination bus. Within this solution, the main challenge is the
computation of the period of snapshot, specially in asynchronous traffic.

  * •

1:1 Packing: in this solution, 1 frame from the original bus is mapped onto 1+
frame of the destination bus. This may mean unused space in a frame,
particularly in the direction CAN to Ethernet, since the maximum size of a CAN
frame is 108535353Considering standard CAN as described in
https://www.ti.com/lit/an/sloa101b/sloa101b.pdfl. vs 1500 for the Ethernet
Maximum Transmission Unit (MTU).

  * •

All packing: in this solution, all CAN frames up to a point (functionally
defined) are grouped into 1 Ethernet frame. This solution optimizes the usage
of MTU of Ethernet vs the 1:1 packing solution.

Figure 12: Examples of CAN from and to Ethernet Gatewaying Strategies [19].

##  IV Open challenges

Per the current state-of-the-art, it is essential to create tools to support a
more agile service development, that considers the services requirements in
terms of bandwidth, safety, criticality and timing of delivery of its
information, while ensuring a interoperability and modularity to support
(almost) any vehicle. These tools shall take into account not only the
orchestration of those services throughout the vehicular zonal E/E
architecture and its ECUs but also the network interconnecting those ECUs and
connecting the vehicle to other elements on the smart city road. Therefore,
determinism communications and its standards, tendentially and historically
thought for static well-known environments, need to be able to be dynamically
configured to support the highly dynamic environment within vehicles and their
equally dynamic surroundings.

The previous subsections focused on specific parts of the vehicular stack -
either middleware, Operating System and virtualization techniques. All these
parts need to be configured properly in a holistic way to ensure the services
are deployed properly. The work of [32] emphasizes the need for configurations
and reconfigurations of the whole vehicular stack to be dynamic, from the
subjacent bus (such as Ethernet), up to the configuration of the ECUs and
services. Such reconfigurations require the integration of multiple levels of
configuration — from deterministic networking standards to the appropriated
SOA protocols to higher level as described in fig. 13.

Figure 13: OSI layers to have into consideration for an automated
configuration of the whole vehicular stack [32].

Other challenges include:

  1. 1.

Agility of service development: simplify and harmonize vehicular development
processes — (almost) everything as software and software processes.

  2. 2.

Data driven: vehicular architectures should be data driven in order to process
great quantities of data from camera/lidar/sensors streams in use cases like
autonomous driving [132].

  3. 3.

Safety issues: following zero trust policies is essential.

  4. 4.

Resource orchestration: leverage the unused resources — but not necessarily on
a in-vehicle point of view, while considering costs and capabilities (CPU
bound, I/O bound) from the hardware into the scheduling and orchestration.

  5. 5.

Interoperability: multi-vendor, multi-hardware and multi vehicle
interoperability.

  6. 6.

Modularity: towards a more manageable stack where automakers don’t do
everything.

  7. 7.

Next-gen storage: consider cloud storage and solutions such as InterPlanetary
File System (IPFS) towards use cases such as OTA updates.

  8. 8.

Clustering: support the clustering of ECUs and the deployment of vehicular
services across clusters, with reinforcement learning to choose the best node
affinity.

  9. 9.

Automatic generation of design architectures: computer generated architectures
for zonal vehicular ECUs

  10. 10.

Legacy compatibility: solutions to integrate ECUs interconnected with
deterministic communications in a zonal SOA architecture.

  11. 11.

Virtualization and automatic scheduling: reallocate workloads depending of
resources with general purpose hardware and virtualized infrastructure.

  12. 12.

Digital twin: standardize the vehicle state representation [32].

Considering the current state-of-the-art, the main challenges of TSN and
deterministic networks within vehicular contexts include:

  1. 1.

Easy to use/plug and play: Auto-configuration of parameters for TSN shapers
based on the number, characteristics of ECUs and workloads.For example [57]
propose a TSN platform abstraction layer and set of API for applications to
send/receive frames. The API was responsible for managing flow registration,
transmit and receive Ethernet frames, creating the Ethernet frames,
configuring the Ethernet port and scheduling frames to the appropriate queue.

  2. 2.

Integration of TSN within wireless networks: Some efforts are being done, but
it is current work as discussed in section III-E2 [133].

  3. 3.

Built-in time awareness: at the link layer — at the applicational level is
more resource intensive, while at link layer could even be accelerated by
FPGAs.

  4. 4.

TSN shaper automatic selection and configuration: automatic generation of
necessary configurations, with reinforcement learning as a possibility to
choose the best configurations.

The next sections will focus on discussing potential use cases that may
benefit from such solution and strategies, while also discussing the proposed
solution for a more agile service development, and tools for its evaluation.

##  V Potential use cases

Vehicular services within an SDV context can benefit both intra-vehicular
functions and occupants — both driver and passenger — as well as other
vehicles and the overall smart city environment. Figure 14 lays out the main
areas of use cases where the SDV paradigm may be useful.

Figure 14: Overview of the potential use cases.

With the SDV paradigm, the vehicle may send the information about its occupant
to other subsystems, or vehicles through communications, which must be
deterministic in order to ensure the information is obtained not too soon nor
too late, therefore risking lives.

In all described use cases, the SDV paradigm supports some adaptability of the
vehicle to the occupants’ characteristics and state to support some automated
action (instead of a manual process). The occupants, either driving or
passengers, can greatly benefit from services for customization of vehicular
functions, protection, monitoring, and companionship.

When considering areas of use cases for SDV, one can consider both the drivers
— for which most use cases, including autonomous driving, tend to focus on —
and occupants. Both can benefit from vehicular technology that adapts to each
occupant while increasing their autonomy and fostering their dignity.
Software-Defined Vehicle can use the existing sensors and actuators on
vehicles to support new services to support drivers and occupants in
situations automakers could not predict during their design phase.

The following subsections present some use cases that are envisioned as
possibilities to validate the system(s) to be researched — intra and inter-
vehicle deterministic use cases and critical non-active safety use cases that
require adaptability — both at software level but also at the network level
(while ensuring reliability and bounded latency).

Table VIII provides an overview of the main requirements envisioned for the
use cases. Use cases can be characterized by several types of requirements.
The work of [134] define several vehicular use cases and their characteristics
in terms of deadline (soft/hard and interval), data complexity (simple/complex
and large) and pattern (discrete/continuous).

TABLE VIII: Main requirements for the possible use cases (based on [135], with
adaptations)

[t]  Use Case Range Information size Latency Reliability Velocity Node density
Positioning Pattern Cross Traffic Left Turn Assist 350 m 1000 bytes / messagea
10 ms 99.9% 33.(3) m/sb 1500 /$km^{2}$ 1 m for lane accuracy Discrete Software
Update <100 m (V2V) <10 GB / day <10 GB / hour (urgent) None / 30 s (V2V) 99%
25 m/sc, 70 m/sd <1500/$km^{2}$ 30 m for street/road accuracy Discrete Remote
Vehicle Health (e.g. predictive maintenance) N/A <1 KB <30 s 99.99% 70 m/se
15000/$km^{2}$f 1 m for lane accuracy Continuous Speed Harmonisationg <150 mh
<500 bytes/ messagei 1400 msj $\sim$80% 69.4 / 33.3 / 19.4k <15000/$km^{2}$ 1
m for lane accuracy Continuous Context aware maneuvering) 100 m 100 per
messageo 50 ms 99% 33.(3) m/sl <15000/$km^{2}$m 1 m for lane accuracy
Continuous (10)n

  *   * a

ETSI CAM size with extras

  * b

considering maximum velocity of 120 km/h

  * c

maximum non highway speed of 90 km/h

  * d

urgent, during a vehicle top speed at certain highways

  * e

during a vehicle top speed at certain highways

  * f

heavy traffic around the vehicle

  * g

worst case scenario, with human reaction

  * h

majorant of the provided values

  * i

speed, location and additional information

  * j

minorant of the provided values

  * k

highway / rural / urban

  * l

maximum velocity of 120 km/h

  * m

considering in an urban situation

  * n

worst case scenario in possible range of frequency of transmission of
Manoeuvre Coordination Message (MCM), per [136]

  * o

maximum size of the message [136]

The classification of vehicular services based on their required level of
abstraction (from signal processing up to behavior decisions), temporal layer
(from cycles of 1 to 50) and spatial layer (from communication between sensors
up to global communication scenarios) is proposed by [137]. These criteria can
be used within a descriptor file for the service to support selecting the best
technologies/stacks.

All these use cases require $N$ time critical services and $K$ services,
allowing to prove the need for orchestration and schedulability of intra- and
inter-vehicular services. In all these use cases, a certain vehicular service
can either be fully deployed on one or more node or divided through multiple
nodes / cluster of vehicles, with both scenarios considering the cloud as an
option.

Also common to all use cases is their need for time criticality. While the use
cases do not necessarily focus on controlling the critical systems intra-
vehicle such as power-train and braking subsystems, the are essential for
other passive safety functionalities. For example, the systems to be
researched are not going to actuate on the brakes for collision avoidance, but
might want to warn cars behind to slow down because there is a disabled person
in the car.

###  V-A Towards autonomous driving for all road situations

While autonomous driving is a current and future trend with great focus from
automakers, its adaptability to all road and traffic situations is an open
problem. Current solutions can handle open road or highway contexts, but
higher density (e.g. urban) contexts require a more cooperative approach to
autonomous driving, with vehicles sharing all the information they possess and
coordinating manoeuvres.

Context Aware Maneuvering Vehicles may consider cooperative manoeuvres between
non-autonomous vehicles and/or autonomous vehicles to ensure complex
manoeuvres are done with no harm.

For example, within the context of the cooperation between public and private
transportation, a service can be considered to give priority to bus, ambulance
or other public transportation to enter a certain crossroad instead of a
privately owned vehicle. This service shall be dynamic and consider several
potential alternatives, including scenarios where the proprietary vehicle must
in fact stop in order to prevent an accident. The service(s) to decide each
vehicle’s action require a minimized bounded latency to receive information on
the road situation and to send information with the proposed action to other
vehicle(s).

When considering the air mobility paradigm, in particular electrical Vertical
Take Off and Landing (eVTOL) vehicles, the cooperation between vehicles gain
an additional importance. New scenarios shall be considered, including
cooperation between vehicles and between the eVTOL and the road infrastructure
— such as landing pads [9] — to ensure no accident occurs during take off or
landing, even in bad visibility (by occlusion or lack of lighting). In these
scenarios coordination between vehicles and infrastructure can avoid a
catastrophic air accident between the vehicles or a crash on top of property
or people.

Considering the importance of working towards autonomous driving for everyone,
it is vital to ensure that each autonomous driving vehicle is capable of
creating the best possible decision not only for itself, but for other
vehicles, and road occupants as well. This requires leveraging the concept of
cooperation between vehicles and others. While standardization work, for
example through European Telecommunications Standards Institute (ETSI) MCMs
are under way, the cooperation between vehicles, particularly for autonomous
driving is in its initial stages.

Autoware, an open source framework considered to be state-of-the-art for
autonomous driving545454Apart from closed source solutions from automakers
(more details on section II-C), where it is not possible to fully understand
the scope of the cooperation between vehicles and its interoperability with
other brands., considers several services to ensure an autonomous driving —
albeit in previously mapped environments — to support manoeuvres such as curb-
to-curb, lane following, lane merging, parking or reaction to traffic lights
and dynamic entities (e.g. Vulnerable Road Users).

To produce plans that eventually become decisions and actuation to the
engines, braking and other vehicular subsystems, Autoware relies on
information of the vehicle itself and on a model of the environment. All this
planning is therefore very local, with cooperation from other vehicles and
road entities proving essential not only to improve Autoware’s vision of the
world (in a cooperative sensing solution such as the one defined by ETSI
Collective Perception Service (CPS)), but also to coordinate the manoeuvre
that each vehicle will do, ensuring that a safe manoeuvre for one vehicle does
not possess danger to another.

When the planning becomes cooperative and not only local, a new problem
arises. Information from and to each vehicle must be sent and must be sent
within a well defined time-frame that is compatible with Autoware producing a
decision and actuating on the vehicle’s subsystems. If the information arrives
after this defined time-frame, the decision will not be correct, while if it
arrives before this defined time-frame, the decision might be unnecessary —
but also potentially dangerous555555For example, a vehicle would end up
braking before being necessary, becoming vulnerable to being hit in the back..

This rational defines the currently considered use case: cooperative
deterministic manoeuvreing, where vehicles receive information from other
entities and use them as part of the planning.

As an example scenario, one may consider coordinating lane merging manoeuvre
between an ambulance and a private vehicle. This use case requires the
development of services depicted in fig. 15, namely a) a message creator and
producer to support exchanging data between Autoware instances in different
vehicles, and b) a parser and injector of such information into Autoware
planning. The data format would follow ETSI MCM standards and it would be
periodic, with deadline insurance requirements — and therefore both a minimum
and bounded latency requirement — with no tolerance to failures of delivery
and with a variable size with an upper bounds corresponding to the maximum
size of the MCM message.

Figure 15: Overview of the Context Aware Maneuvering use case.

The integration of Autoware with cooperative manoeuvreing is considered in
[138]565656Additional details at https://tlab-
wide.github.io/AutowareV2X/pr-48/design/use-cases/.. However, it fails to
consider the deterministic communications requirements or the need for
orchestrating the overall deployment in vehicles’ ECUs in a more automated
approach.

Vehicle malfunction situations Even when full autonomy of a vehicle is not
only a reality but also legal, vehicles can still have unexpected issues that
endanger their occupants and surroundings. Examples include a flat tire, a
tire explosion, failed waterproofing of the batteries (in the case of electric
vehicles), or a failure on the valve timing (in the case of internal
combustion engines). In these scenarios, services to analyze, monitor and warn
others about the situation should be deployed in a bounded minimal time and
the information to other vehicles shall be sent with both minimized, and
bounded latency.

When considering Connected Autonomous Vehicles, services that monitor and
react when sensors are malfunctioning are critical and their information must
also be bounded in time and transmitted reliably. Without such services, the
CAVs cannot react to a malfunctioning or occluded camera, LIght Detection And
Ranging (Lidar) or equivalent and can wrongly assume their information is
correct, with potentially deadly consequences.

###  V-B Towards vehicles tailored for everyone

While the future of mobility is inherently more autonomous and more feature-
packed, less concern is given to occupants, including children or occupants
who may have some sort of physical or cognitive restriction. Restrictions
considered here may include some minor impairment, vision or hearing issues,
concentration issues, and others, that restrict the occupants’ capability of
reacting to the environment in the same way.

The following situations are examples where a vehicle has an occupant with
some issue/limitation who can greatly benefit from a SDV paradigm. In this
paradigm, the vehicle can deploy services tailored for the people’s specific
needs for customization of vehicular functions, protection, monitoring, and
companionship. In all situations, the services to be deployed shall have their
data delivered in a bounded time — so the services are not left in an
inconsistent state.

Automatic vehicle configuration based on occupants characteristics Information
on the occupants’ characteristics and vital parameters can be obtained by
intra-vehicular subsystems that allow the vehicle to adapt interior functions
(e.g. lighting, sound, infotainment) to the best comfort of the occupants,
therefore creating a set of customizations tailored to each occupant’s
characteristics.

Not only the services can adapt but warn if there is an issue (like a non-
fixed wheelchair or baby seat). Such warnings can be sent both to the
vehicle’s infotainment systems but also to other vehicles. Vehicles can then
use such information, as well as information about the occupants’
characteristics, to deploy services to adapt the vehicle driving — e.g. to
increase cruise control following distances, reduce throttle response, or warn
other smart city infrastructures.

These services can greatly benefit the healthcare industry in particular.
Consider a scenario where an ambulance is transporting a patient. Vehicular
services can support scenarios such as this:k

  * •

Ambulance: I have a person in risk of life.

  * •

Other vehicles: OK, I need to slow down.

  * •

Cloud: I’ll provide you with specific applications (e.g. to control
acceleration profiles or climate control settings). I’ll deploy an application
for monitoring impaired people that will run on a cluster of $X$ vehicles.

Adapting the vehicle’s subsystems to impaired occupants Consider a situation
where, in order to transport impaired people in a wheelchair, a healthcare
provider must575757From an informal interview with a specialist nurse in
medical-surgical nursing:

  1. 1.

Get the wheel chair up a moving ramp or lift, per depicted in footnote
59585858Another example of such ramps and lifts in
https://www.gilaniengineering.com.au/product/hydraulic-wheelchair-platform-
accessible-lift-hoist-for-cars-and-vans/.

  2. 2.

Attach the wheelchair to the vehicle through a set of several belts fixed to
specific points within the vehicle, as depicted in footnote 60.

(a) Example of ramp where wheelchairs need to be pushed manually by the
healthcare provider (courtesy of Tripod Mobility595959More details at
https://www.tripodmobility.com/en/products/wheelchair-accesible-
vehicles/upfront/.).

(b) Example of expected attachment points within a vehicle for a wheelchair
(courtesy of BraunAbility606060Available at
https://www.braunability.eu/en/products/tie-downs-and-seatbelts/wtors/.).

Figure 16: Detail view on the main steps for transporting impaired people on a
vehicle.

The healthcare provider must do such manually, multiple times (for multiple
people) and in a short time-frame and without little to no feedback if the
person and the chair is actually fixed properly. Mistakes include fixing
outside of the fixing point, twisting the straps and/or simply not fixing the
person and/or chair. In addition to that, specific formation is required to do
such tasks.

A vehicular services (or set of services) that is capable of communicating
with other in vehicle systems (e.g. infotainment), but also with the
healthcare provider registry systems, would greatly decrease the potential
human errors of the current solution, and since it would minimize the
dependency on humans could even support an increase on the patient’s privacy.
One could even consider a more intelligent connected wheelchair directly
coordinating with the vehicle all the necessary movements. Such systems would
not require a minimized latency but guarantees of delivery of the information
within well-known time bounds and with low jitter in order to ensure no
unwanted movements of the wheelchair that may harm the person.

Other situations include:

  * •

Monitoring a baby that is ill or very restless and provide such information
directly to a hospital.

  * •

Decrease the brightness of other vehicle’s lightning in order to protect the
eyes of a newly operated occupant.

Personal assistants While the SDV paradigm is parallel to the advent of
autonomous vehicles, vehicles can include humans in new ways within the
driving experience. The unparalleled amount of information and sensing the
vehicle can obtain from its environment, driver and occupants, can be used to
support personal assistants that give occupants the sensation of being in
control — even if the vehicle is self-driving.

Such assistants can be developed as a set of subscribing services within the
vehicle’s ECUs dedicated to infotainment subsystems and, if using speech or
touch interaction modalities, can greatly benefit from a well defined timely
delivery of information which decreases the overall jitter visible to the end
users.

###  V-C Towards assisted fleet management and maintenance

Remote vehicle health and predictive maintenance Constant monitoring of the
main vital parameters of a vehicle state — such as tire condition, brake
system condition, engine cooling system status (in the case of internal
combustion engines) or the power delivery subsystems (in the case of electric
vehicles) — requires not only a reduced latency but also, in case the vehicle
detects an issue, a guarantee of delivery in a bounded time so at the very
least other vehicles are aware of the problem before it has impact on the
road. In the case of emergency scenarios — as previously described in fig. 15,
the latency shall also be minimized.

Predictive maintenance scenarios, while not necessarily requiring a bounded
latency within its communication, still require a dynamic deployment of
services that considers the vehicular ECUs.

Fleet management Fleet management scenarios and remote services, such as the
one presented at fig. 17616161More details at https://www.autowiz.in/fleet-
features.html., are other examples of use cases that can benefit from a set of
services deployed across multiple vehicles. Considering a set of services
containing the logic required to monitor, in real-time, the status (_e.g.
location or number of hours the vehicle is driven)_ of a vehicle within a
fleet. This set of services, if orchestrated throughout a cluster of vehicles,
can support systems for enterprises managing a vehicular fleet, homologating
it, or even for state entities to perform the routine inspection. Information
from/to those services, while do not necessarily require an extremely low
latency, must be delivered within known time bounds and with low jitter.

Figure 17: Example of vehicle fleet management system (courtesy of AutoWiz).

Over-the-air updates and real-time homologation Changes in the vehicles’
software — either via OTA updates, through the addition of new services or
after a vehicle is sold to ensure no changes — should, in an automated way, be
reflected in a re-homologation process. This process, while not requiring a
minimized latency, shall be done in a bounded timely manner, with a guarantee
of reliability, otherwise, vehicles may be driving on public roads with an
unwanted, unsafe state [5].

##  VI Proposed vision

In order to support a dynamic management of the services several layers must
be considered as depicted in fig. 18. These layers should act at least in the
following domains [32]:

  * •

Orchestration of the services: where they should be run and policies to decide
the node(s) and the number of replicas.

  * •

Virtualization and management of the network: including automatic
configuration of routing and TSN shapers and reliability processes (e.g.
FRER).

  * •

Virtualization of the hardware in order to support better resource usage and
decoupling of services and operating systems from each ECU.

Figure 18: Overall layered view of the architecture main modules.

Figure 19 presents the overview of an initial proposal of architecture. This
architecture supports a cloud computing approach on vehicles to see them as a
data center on wheels [32] in order to support service scheduling, redundancy,
and healing based on the vehicles’ computing capabilities.

Figure 19: Overall high level architecture of the proposed solution.

The Orchestrator vertical (in yellow) is the main entry-point of the system to
be researched and ensures the first aforementioned layer. Through user-defined
and system-defined metrics within a Service Descriptor, decides the amount of
resources and the placement of those resources throughout the computing
continuum and the different vehicles throughout the smart city, while
considering possible handovers and optimal usage of the computing and network
resources. The orchestrator is responsible for controlling 4 other verticals.

The first vertical, the Deterministic Network (in blue), ensures that messages
– either control messages to actuate or status messages containing information
from vehicles and the smart city – are delivered in a well-specified time
bound and with fault-proof reliability. Research topics here include, but are
not limited to, integrating clock synchronization mechanisms into wireless
vehicular networks and mechanisms towards dynamic automatic definition, and
optimal configuration of flows of packets, their queue priorities and
characteristics. The module within the architecture, the Deterministic Network
Configurator, is responsible for creating the necessary traffic flows, their
parameters and configuring the necessary hardware, namely the Network
Interface Controller/Card (NIC) within each ECU and the TSN capable Ethernet
switches interconnecting them. It is expected at least 3 traffic classes to be
configured: a) system control messages with maximum criticality; b) high size
(non) periodic streams of data and c) periodic or non periodic service
messages.

The Data Layer vertical (in green) is responsible for ensuring the data is
exchanged between the vehicular services in the most appropriated set of SOA
protocols — such as SOME/IP, MQTT or DDS.

The Hypervisor vertical (in red) is responsible for ensuring the deployment of
the services, either within a Kubernetes worker node, within a virtual machine
managed for example by KVM or through a containerd or equivalent container
runtime.

These 3 verticals dispatch orders to the  Vehicle Abstraction Layer (VAL) (in
purple) of each ECU, which abstracts different types and models of vehicles’
ECUs – both simulators and real vehicles – their actuators, sensors, and ECUs
through the abstraction of existing frameworks, such as AUTOSAR, Autoware or
others. Conceptually, the VAL is no different to the standardized abstractions
operating systems created during the mid 1980s and 1990s to abstract the
hardware from the remaining kernel, with [10] proposing an extension of such a
paradigm into the vehicular paradigm, as depicted in fig. 20.

Figure 20: The VAL based architecture for vehicles as described by [10].

The research on the VAL may also consider the creation of a digital twin of
the vehicle and the research of the impact of sensors and services on the
vehicle networks.

###  VI-A Overall end-to-end interaction

Figure 21 provides an overview of the end-to-end interaction of the system
proposal, from the features the end-user (developer of vehicular services) can
expect to see up to the configuration of the necessary hardware for the
services to be run while fulfilling their requirements.

Figure 21: Overall end-to-end interaction model of the proposed solution.

The system to be researched orchestrate the service deployment, execution and
evaluation of intra- and inter- vehicular services. Services can be associated
with domains, that define not only requirements but the universe of
information the service can subscribe. Service developers define a service
descriptor (an example is detailed in 1) to describe the main service
characteristics. This set of requirements is used by the orchestrator to
configure and dispatch the services to the appropriated hypervisor in the