Journal of Automotive Software Engineering

Vol. 00(0), Month (2020), pp. 1–14

DOI: https://doi.org/10.2991/jase.d.200212.001; ISSN: 2589-2258
https://www.atlantis-press.com/journals/jase/

A Standard Driven Software Architecture for Fully

Autonomous Vehicles
Alex Serban1,* , Erik Poll1 , Joost Visser2
1
Radboud University Nijmegen, The Netherlands
2
Leiden University Leiden, The Netherlands

ARTICLE INFO ABSTRACT

Article History The development of self-driving vehicles is often regarded as adding a layer of intelligence on top of classic vehicle platforms.
Received 27 Sep 2018 However, the amount of software needed to reach autonomy will exceed the software deployed for operation of normal vehicles.
Accepted 12 Feb 2020 As complexity increases, the demand for proper structure also increases. Moreover, the shift from open, deterministic compo-
nents to more opaque, probabilistic software components raises new challenges for system designers. In this paper we introduce
Keywords a functional software architecture for fully autonomous vehicles aimed to standardise and ease the development process. Exist-
Intelligent vehicles ing literature presents past experiments with autonomous driving or implementations specific to limited domains (e.g. winning
Autonomous vehicles a competition). The architectural solutions are often an after-math of building or evolving an autonomous vehicle and not the
Robotics result of a clear software development life-cycle. A major issue of this approach is that requirements cannot be traced with respect
Software architecture to functional components and several components group most functionality. Therefore, it is often difficult to adopt the propos-
als. In this paper we take a prescriptive approach starting with requirements from a widely adopted automotive standard. We
follow a clear software engineering process, specific to the automotive industry. During the design process, we make extensive
use of robotic architectures – which seem to be often ignored by automotive software engineers – to support standard driven
requirements.

© 2020 The Authors. Published by Atlantis Press SARL.

This is an open access article distributed under the CC BY-NC 4.0 license (http://creativecommons.org/licenses/by-nc/4.0/).

1. INTRODUCTION Basic vehicles already run large amounts of software with tight con-
straints concerning real-time processing, failure rate, maintainabil-
Autonomous driving is no longer a lab experiment. As manufactur- ity and safety. In order to avoid design flaws or an unbalanced
ers compete to raise the level of vehicle automation, cars become representation of requirements in the final product, the software’s
highly complex systems. Driving task automation is often regarded evolution towards autonomy must be well managed. Since adding
as adding a layer of cognitive intelligence on top of basic vehicle cognitive intelligence to vehicles leads to new software components
platforms [1]. While traditional mechanical components become deployed on existing platforms, a clear mapping between functional
a commodity [2] and planning algorithms become responsible for goals and software components is needed.
critical decisions, software emerges as the lead innovation driver.
Recent trends forecast an increase in traffic safety and efficiency Software architecture was introduced as a means to manage com-
by minimising human involvement and error. The transfer of total plexity in software systems and help assess functional and non-
control from humans to machines is classified by the Society of functional attributes, before the build phase. A good architecture
Automotive Engineers (SAE) as a stepwise process on a scale from 0 is known to help ensure that a system satisfies key requirements
to 5, where 0 involves no automation and 5 means full-time perfor- in areas such as functional suitability, performance, reliability or
mance by an automated driving system of all driving aspects, under interoperability [5].
all roadway and environmental conditions [3]. Since the amount of The goal of this paper is to design a functional software architecture
software grows, there is a need to use advanced software engineer- for fully autonomous vehicles. Existing literature takes a descrip-
ing methods and tools to handle its complexity, size and criticality. tive approach and presents past experiments with autonomous driv-
Software systems are difficult to understand because of their non- ing or implementations specific to limited domains (e.g. winning
linear nature – a one bit error can bring an entire system down, or a competition). The architectural solutions are therefore an after-
a much larger error may do nothing. Moreover, many errors come math of building or evolving an autonomous vehicle and not the
from design flaws or requirements (mis-) specifications [4]. result of a clear software development life-cycle. A major issue of
this approach is that requirements cannot be traced with respect
to functional components and several components group most
functionality. Therefore, without inside knowledge, it is often not
*
Q1 Corresponding author. Email: a.serban@cs.ru.nl straight forward to adopt the proposals.
2 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

In this paper we take a prescriptive approach driven by standard deployment between distributed components. We are hereby con-
requirements. We use requirements from the SAE J3016 standard, cerned with designing functional software components which are
which defines multiple levels of driving automation and includes deployed on ECU and are required to exchange information over
functional definitions for each level. The goal of SAE J3016 is to one or many communication buses. Standardised interfaces (such
provide a complete taxonomy for driving automation features and as the ones defined in AUTOSAR) help ease the development and
the underlying principles used to evolve from none to full driving communication between software components, however, they do
automation. At the moment of writing this paper, it is the only stan- not have a big impact on their core functionality.
dard recommended practice for building autonomous vehicles. We
As mentioned in Section 1, SAE J3016 is a standard that defines
provide an extensive discussion on the design decisions in the form
multiple levels of automation, sketching an incremental evolution
of trade-off analysis, which naturally leads to a body of easily acces-
from no automation to fully autonomous vehicles. The purpose of
sible distilled knowledge. The current proposal is an extension of
the standard is to be descriptive and broad about this evolution,
our prior work [6].
but it does not provide strict requirements for it. However, at the
The term functional architecture is used analogous to the term func- moment, it is the most comprehensive, widely adopted, document
tional concept described in the ISO 26262 automotive standard that drives this evolution. Given its wide adoption, we use it as a
[1,7]: a specification of intended functions and necessary interac- baseline for our approach: vehicles should satisfy at least the func-
tions in order to achieve desired behaviours. Moreover, it is equiva- tions described by this standard in order to qualify for automation
lent to functional views in software architecture descriptions; which levels. With the goal of understanding the vehicle automation pro-
provide the architects with the possibility to cluster functions and cess, we first introduce the most important terms as defined by SAE
distribute them to the right teams to develop and to reason about J3016 [3]:
them [4]. Functional architecture design corresponds to the second
step in the V-model [7,8], a software development life cycle imposed • Dynamic Driving Task (DDT) – real-time operational and
by the mandatory compliance to ISO 26262 automotive standard. tactical functions required to operate a vehicle, excluding
strategic functions such as trip scheduling or route planning.
We follow the methodology described by Wieringa [9] as the design
DDT is analogous to driving a car on a predefined route and
cycle; a subset of the engineering cycle which precedes the solution
includes actuator control (e.g. steering or braking) and tactical
implementation and implementation evaluation. The design cycle
planning such as generating and following a trajectory, keeping
includes designing and validating a solution for given requirements.
the vehicle within the lanes, maintaining distance from other
The rest of the paper is organised as follows. In Section 2 we intro- vehicles, etc.
duce background information. In Section 3 we infer the require-
• Driving automation system – hardware and software systems
ments from the SAE J3016 standard. In Section 4 we present the
collectively capable of performing some parts or all of the DDT
reasoning process that lead to a solution domain. The functional
on a sustained basis. Driving automation systems are usually
components are introduced in Section 5, followed by component
composed of design-specific functionality called features (e.g.
interaction patterns in Section 6 and a general trade-off analysis
automated parking, lane keep assistance, etc.). The interplay
in Section 7. A discussion follows in Section 8. In Section 9 we
between hardware and software was described earlier. We are
compare the proposal with related work and conclude with future
currently interested in the interplay between software
research in Section 10.
components in order to design driving automation systems
capable to achieve full autonomy.
2. BACKGROUND • Operational Design Domains (ODD) – the specific conditions
under which a given driving automation system or feature is
The development of automotive systems is distributed between
designed to function. Defining an operational domain is an
vehicle manufacturers, called Original Equipment Manufacturers
important task during the design phase, as the requirements
(OEM), and various component suppliers – leading to a distributed
change in relation to it. For example, a vehicle which should
software development life cycle where the OEM play the role of
operate in sunny weather in a limited area of a city has different
technology integrators. This development process allows OEM
requirements than a vehicle which should operate in winter
to delegate responsibility for development, standardisation and
conditions, on mountain roads. As will be discussed later, full
certification to their component suppliers. The same distributed
autonomy requires a vehicle to operate without intervention in
paradigm preserves, at the moment, for component distribution
all weather and traffic conditions.
and deployment inside a vehicle; where no central exists.
• DDT fall-back – the response by the user or by an Automated
Instead, embedded systems called Electronic Control Units (ECU)
Driving System (ADS) to either perform the DDT task or
are deployed on vehicles in order to enforce digital control of func-
achieve a safety state after occurrence of a DDT
tional aspects such as steering or brakes. Many features require
performance-relevant system failure or upon leaving the
interactions and communications across several ECUs. For exam-
designated ODD.
ple, cruise control needs to command both the breaking and
the steering system based on the presence of other traffic par- • DDT fall-back-ready user – the user of a vehicle equipped with
ticipants. In order to increase component reuse across systems, an engaged ADS feature who is able to operate the vehicle and
manufacturers and vendors developed a number of standardised is receptive to ADS-issued requests to intervene and to perform
communication buses (e.g. CAN, FlexRay) and software tech- any if not all of the DDT tasks during a system failure or when
nology platforms (e.g. AUTOSAR) that ease communication and an automated vehicle requests it.
 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14 3

• DDT feature – a design-specific functionality at a specific level • If the driving automation system performs the entire DDT, but a
of driving automation with a particular ODD. A feature can be DDT fall-back ready user is expected to take over when a system
seen as a specific hardware or software component that is failure occurs, then the division of roles corresponds to level 3.
performs a driving automation task in a predefined domain. We
• If a driving automation system can perform the entire DDT
may think of lane assistance in sunny weather as a DDT feature.
and fall-back within a prescribed ODD or in all
driver-manageable driving situation (unlimited ODD), then
Besides hardware constraints, full vehicle automation involves the
the division of roles corresponds to levels 4 and 5.
automation of the DDT in all ODD, by developing a driving
automation system. Recursively, driving automation systems are
composed of design-specific features. In this sense, complete vehi-
3. REQUIREMENTS INFERENCE
cle automation is seen as developing, deploying and orchestrating
enough DDT features in order to satisfy all conditions (ODDs) in The process of functional architecture design starts by developing a
which a human driver can operate a vehicle (safely). list of functional components and their dependencies [4]. Towards
The SAE classification of driving automation for on-road vehicles, this end, SAE J3016 defines three classes of components:
showcased in Figure 1, is meant to clarify the role of a human driver,
if any, during vehicle operation. The first discriminant condition is • Operational – basic vehicle control,
the environmental monitoring agent. In the case of no automation • Tactical – planning and execution for event or object avoidance
up to partial automation (levels 0-2), the environment is monitored and expedited route following and
by a human driver, while for higher degrees of automation (levels
3-5), the vehicle becomes responsible for environmental • Strategic – destination and general route planning.
monitoring.
Each class of components has an incremental role in a hierarchical
Another discriminant criteria is the responsibility for DDT fall- control structure which starts from low level control, through the
back mechanisms. Intelligent driving automation systems (levels operational class and finishes with a high level overview through the
4-5) embed the responsibility for automation fall-back constrained strategic class of components. In between, the tactical components
or not by operational domains, while for low levels of automation handle trajectory planning and response to traffic events. This hier-
(levels 0-3) a human driver is fully responsible. archical view upon increasing the level of vehicle automation is an
According to SAE: important decision driver in architecture design.
Later, the SAE definition for DDT specifies, for each class, the func-
• If the driving automation system performs the longitudinal tionality that must be automated in order to reach full autonomy
and/or lateral vehicle control, while the driver is expected to (level 5):
complete the DDT, the division of roles corresponds to levels
1 and 2. • Lateral vehicle motion control via steering (operational).
• Longitudinal vehicle control via acceleration and deceleration
(operational).
• Monitoring of the driving environment via object and event
detection, recognition, classification and response preparation
(operational and tactical).
• Object and event response execution (operational and tactical).
• Manoeuvre planning (tactical).
• Enhanced conspicuity via lighting, signalling and gesturing,
etc. (tactical).

Moreover, a level 5 vehicle must ensure DDT fall-back and must

implement strategic functions, not specified in the DDT definition.
The latter consists of destination planning between two points pro-
vided by a human user or received from an operational centre.
An overview of the hierarchical class of components defined is illus-
trated in Figure 2. The level of complexity increases from left to
right – from operational to strategic functions.
Although not exhaustive, the list of components and their intended
behaviour, as specified by SAE J3016, represents a good set of ini-
tial requirements. It is the choice of each OEM how any of the
intended functionality will be implemented. For example, different
Figure 1 SAE J3016 levels of driving automation. algorithms or software systems could be used to implement object
4 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

developments in the field of robotics and select the best choices for
the automotive domain.
For a long time, the dominant view in the AI community was that a
control system for autonomous robots should be composed of three
functional elements: a sensing system, a planning system and an
execution system [18]. This view led to the ubiquitous sense-plan-
act (SPA) paradigm. For planning, a system typically maintains an
internal state representation, which allows it to position itself in the
environment and plan next actions. Because this model has to be
up-to-date and accurately reflect the environment in which a robot
operates, it might require a lot of information. As the operational
Figure 2 Functional component classification according to SAE environment becomes more complex, the complexity of the inter-
J3016 [3]. nal representation also increases, increasing the time needed to plan
the next steps. Therefore, in fast changing environments, new plans
may be obsolete before they are deployed. Moreover, unexpected
detection, recognition and classification. This choice can impact the
outcomes from the execution of a plan stem may cause the next plan
final set of functional components because one OEM can choose to
steps to be executed in an appropriate context and lead to unex-
use multiple sensors and powerful sensor fusion algorithms, while
pected outcomes.
other OEM can build a single component that can handle all tasks.
In this paper, we strive to divide each function into atomic compo- One question that naturally stood up from these shortcomings is
nents. If any of these pieces will be combined in higher level com- “how important is the internal state modelling?” In order to answer
ponents, it won’t have any impact on this proposal. An in-depth this question, several definitions meant to achieve similar goals
analysis of such trade-offs, often driven by the distributed software were proposed. Maes [11] first distinguishes between behaviour and
development life-cycle, is presented in Section 7. knowledge based systems – where knowledge-based systems main-
tain an internal state of the environment, while behaviour-based
We briefly remind that the automation of any task is a control loop
systems do not [11]. Similarly, the literature distinguishes between
which receives input from sensors, performs some reasoning and
deliberative and reactive systems, where deliberative systems rea-
acts upon the environment (possibly through actuators) [10]. The
son upon an internal representation of the environment and reac-
automation of complex tasks requires a deeper (semantic) under-
tive system fulfil goals through reflexive reactions to environment
standing of sensor data in order to generate higher order decisions
changes [13–16]. Reactive or behaviour based systems are able to
or plans. However, the loop behaviour is preserved. This analogy
react faster to a changing environment, but reason less about it.
holds for the SAE classification of functional components illus-
trated in Figure 2. Each class of components can be implemented as We find both definitions to answer the same questions – “how will a
a control loop which receives input from sensors and acts accord- system plan its decisions?” Through reasoning on complex seman-
ingly. From left to right – from operational to strategic functions – tic information extracted from its sensors or by simple reactions to
the level of semantic knowledge needed in order to make a decision simple inputs? Deciding on this is an initial trade-off between speed
increases. Moreover, as we move further from left to right, the com- of computation and the amount of environmental understanding a
ponents do not control actuators anymore, but other components. system can have.
For example, tactical components will send commands to oper-
When considering the development of autonomous vehicles
ational components. Similarly, strategic functions cannot directly
through these lenses, we can see that vehicles require both reactive
act upon actuators, but communicate with tactical functions, which
and deliberative components. Maintaining a pre-defined trajectory
will later command operational functions.
and distance from the objects around a vehicle is an example of a
Thus we can regard each class of components as a big loop – illus- reactive system, which should operate with high frequency and be
trated in Figure 2 – and each component in each class as a smaller as fast as possible in order to overcome any environmental change.
loop because each component will require certain semantic infor- In this case, maintaining a complex representation of the surround-
mation and not all the information available at class level. We will ing environment is futile.
exploit this behaviour in the following section.
However, a decision making mechanism responsible, for example,
to overtake the vehicle in front is an example of a deliberative sys-
tem. In this case maintaining a complex world model can help the
4. RATIONALE system to take a better decision.
Software architecture design for autonomous vehicles is analogous For example, one can not only judge the distances to the surround-
to the design of a real-time, intelligent, control system – or a robot. ing objects, but also the relevance of the decision in achieving the
Although we can find considerably literature concerning soft- goal. Is it worth to overtake the car in front if the vehicle must
ware architecture in the field of robotics and artificial intelligence turn right in a relatively short distance after the overtake? In order
[11–17], these proposals seem to be overlooked by automotive to answer this question a complex world model that must com-
software engineers. Therefore, many reference architectures for bine semantic information about the overall goal, future states and
autonomous vehicles miss developments and trade-offs explored in nearby objects is needed. Processing this amount of information
the field of robotics – as we will shall see in Section 9. We aim to will naturally take a longer time. However, since the result can only
bridge this gap in this section, by discussing the most important impact the passengers comfort (assuming that driving behind a
 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14 5

slow car for a long time is un-comfortable) the system can assume the car and the inputs it receives from the acceleration pedal. For
this processing time. complex tasks, such as destination planning, the world model must
include complex information such as the maps for an operational
Gat and Bonnasso [13] first debate the role of internal state and
domain, real-time traffic information, etc.
establish a balance between reactive and deliberative components
inside a system. In their proposal, the functional components are Sensory processing performs the functions of windowing, group-
classified based on their memory and knowledge about the inter- ing, computation, estimation and classification on input from
nal state in: no knowledge, knowledge of the past, or knowledge of sensors. World modelling can also maintain static knowledge
the future – thus resulting in three layers of functional components. in the form of images, maps, events or relationships between
However, their model does not specify how, or if, the knowledge them. Value judgment provides criteria for decision making, while
can be shared between the layers. Moreover, it is not clear how and behaviour generation is responsible for planning and execution of
if any components incorporate knowledge about past, future and behaviours [12].
other static data.
Albus proposed the design for a node in a hierarchical control struc-
A better proposal, that bridges the gap between reactive and delib- ture, where lower level nodes can generate inputs for higher level
erative components, is the NIST Real Time Control Systems (RCS) nodes, thus increasing the level of abstraction and cognition. There-
reference architecture introduced by Albus [12]. This architecture fore, nodes lower in a hierarchy can have a very simplistic world
does not separate components based on memory, but builds a hier- model and behaviour generation functions and can easily imple-
archy based on semantical knowledge. ment reactive components. In order to keep in line with the example
above, we consider the case of maintaining a distance from an object
Thus, components lower in the hierarchy have limited semantic
in front. A node implementing this functionality will only have to
understanding and can generate inputs for higher components,
keep in the world model block the distance from the vehicle in front,
deepening their semantic knowledge and understanding. More-
the reference distance and the vehicle’s velocity. The behaviour gen-
over, RCS has no temporal limitations for a component’s knowl-
eration block will decide to issue a braking command whenever the
edge. One can hold static or dynamic information about past,
distance will be too close or whenever it predicts (using the velocity
present or future. Although all components maintain a wold model,
of the vehicle) that the distance will decrease.
this can be as simple as reference values, to which the input must be
compared. Higher nodes, representing deliberative components, can easily be
described with the same architecture. Their world model block will
We find this proposal a good fit for automotive requirements and
process more semantic information and generate more complex
for the functional classification presented in Section 3 because it
behaviours (such as the decision to overtake the vehicle in front in
allows a balanced representation of reactive and deliberative com-
order to increase the overall ride comfort and optimise the goal).
ponents and it allows hierarchical semantic processing – one of the
requirements given by the classification of functional components In this hierarchy, higher nodes consume semantic information
proposed earlier. Further on, we introduce more details about it and extracted by lower nodes. However, this may not always the case
illustrate it in Figure 3. with autonomous vehicles where several nodes, at different hierar-
chical levels, can consume the same information. For example, the
At the heart of the control loop for an RCS node is a representa-
distance from the vehicle in front can be used by both the reac-
tion of the external world – the world model – which provides a site
tive and the deliberative components introduced earlier. Moreover,
for data fusion, acts as a buffer between perception and behaviour,
several components at the same hierarchical layer can interact, as a
and supports both sensory processing and behaviour generation.
sequential process.
Depending on the complexity of the task a node is responsible
for, the complexity of the world model increases. For the simplest From an architectural point of view, a sequential processing stream
tasks, the world model can be very simple, such as in the case of a which follows different, individual, processing steps is represented
throttle system which only has knowledge about the velocity of through a pipes and filters pattern [20]. The pattern divides a process
in several sequential steps, connected by the data flow – the output
data of a step is the input to the subsequent step. Each processing
step is implemented by a filter component [20].
In its pure form, the pipes and filters pattern can only represent
sequential processes. For hierarchical structures, a variant of the
pattern called tee and join pipeline systems is used [20]. In this
paradigm, the input from sensors is passed either to a low level
pipeline corresponding to a low level control loop, to a higher level
pipeline or both.
An example is shown in Figure 4: the input from sensors is fed to
different processing pipes. At a low level of abstraction, pipeline 1
only executes simple operations and sends the result to actuators.
At higher levels of abstraction, pipeline 2 processes more sen-
sor data and generates manoeuvre plans which are translated to
actuator language. A priority condition will decide which input to
Figure 3 Real time intelligent control systems reference architecture [19]. send to the actuators. Alternatives to this patterns will be further
6 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

discussed in Sections 6 and 7. At the moment, we concentrate on corresponds to SAE tactical functions, and the behaviour generation
the functional decomposition, which will suggest the nodes in the class maps to both strategic and planning class of functions.
future architecture.
Two orthogonal classes, corresponding to data management and
system and safety management, are depicted because they repre-
sent cross-cutting concerns: data management components imple-
5. FUNCTIONAL DECOMPOSITION ment long term data storage and retrieval, while system and safety
management components act in parallel of normal control loops
We start by introducing the functional components and, in and represent DDT fall-back mechanisms or other safety concerns.
Section 6, discuss interaction patterns. Figure 5 depicts the func-
In the following subsections each class of filters is discussed together
tional components that satisfy SAE J3016 requirements for fully
with its components. The last sub-section discusses the relation
autonomous vehicles. The data flows from left to right; from the
with middle-ware solutions and AUTOSAR.
sensors abstraction to actuator interfaces, simulating a closed con-
trol loop. The figure represents three types of entities: functional
components (blue boxes), classes of components (light grey boxes)
and sub-classes of components (dark grey boxes). 5.1. Sensor Abstractions
The proposal maps onto the SAE classification of functional com- Sensor abstractions provide software interfaces to hardware sen-
ponents, introduced in Section 2, in the following way: vehicle sors, possible adapters and conversion functionality needed to
control and actuators interface class of components correspond interpret the data. We distinguish two classes of sensors and, respec-
to SAE operational functions, the planning class of components tively, of abstractions: (1) sensors that monitor the internal vehicle
state or dynamic attributes (e.g. inertial measurements, speed, etc.)
and (2) sensors that monitor the external environment as required
by the SAE requirements.
Environmental monitoring can be based on RADAR, LIDAR and
camera technologies. In the case of cooperative driving, communi-
cation with other traffic participants is realised through vehicle-to-
everything (V2X). Global positioning (GPS) is required to localise
the vehicle in a map environment or to generate global routes and
is therefore represented as a separated functional component.
All abstractions concerning the internal vehicle state are grouped
into one functional component, because the choice is specific to
Figure 4 Tee and join pipelines architectural pattern. each OEM.

Figure 5 Proposed functional architecture, part I: functional components.

 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14 7

5.2. Sensor Fusion is consistent: at first a number of alternative behaviours are gener-
ated, then one is selected using an objective function (or policy).
Multi-sensor environments generate large volumes of data with
different resolutions. These are often corrupted by a variety of A vehicle’s goal is to reach a given destination without any incident.
noise and clutter conditions which continually change because of When the destination changes (through a Human Machine Inter-
temporal changes in the environment. Sensor fusion combines action (HMI) input), the global routing component will change the
data from different, heterogeneous, sources to increase accuracy of goal and trigger new behaviour generation. These components cor-
measurements. respond to the SAE strategic functions.

The functional components are chosen with respect to SAE require-

ments for object and event detection, recognition and classification. 5.5. Planning
We distinguish between static and dynamic objects (e.g. a barrier,
The planning class determines each manoeuvre an autonomous
pedestrians) and road objects (e.g. traffic lights) because they have
vehicle must execute in order to satisfy a chosen behaviour. The
different semantic meaning. Moreover, local positioning is needed
path planning and monitoring component generates an obstacle
to position the vehicle relative to the identified objects and GPS is
free trajectory and composes the trajectory implementation plan
needed for strategic functionality.
from composition functions deployed on the vehicle. It acts like a
Through sensor fusion, a processing pipeline gathering information supervisor which decomposes tasks, chooses alternative methods
from various sensors such as RADAR and camera can be defined in for achieving them, and monitors the execution. The need to re-use
order to classify an object, determine its speed, and add other prop- components across vehicles or outsource the development leads the
erties to its description. The distinction mentioned earlier between path to compositional functions. These functions can be thought as
the external environment and the internal state of a vehicle is pre- DDT features, described in Section 2. Examples of such functions
served in Figure 5: the first four components process data related to are: lane keeping systems or automated parking systems (all, com-
the external environment, while the internal state is represented by mercial of-the-shelf deployed products).
the last functional component.
Compositional functions represent an instantiation of the RCS
architecture; they receive data input from sensor fusion or world
modelling through data sinks, judge its value and act accordingly,
5.3. World Model sending the outputs to vehicle control. Path planning and monitor-
ing acts as an orchestrator which decide which functions are needed
The world model represents the complete picture of the external
to complete the trajectory and coordinate them until the goal is
environment as perceived by the vehicle, together with its internal
fulfilled or a new objective arrives. For vehicles up and including
state. Data coming from sensor fusion is used together with stored
level 4, which cannot satisfy full autonomous driving in all driving
data (e.g. maps) in order to create a complete representation of the
conditions, the control of the vehicle must be handed to a trained
world.
driver in case a goal cannot be fulfilled. Therefore, this class includes
As in RCS architecture, the world model acts as a buffer between a driving alert HMI component.
sensor processing and behaviour generation. Components in this
class maintain knowledge about images, maps, entities and events,
5.6. Vehicle Control
but also relationships between them. World modelling stores and
uses historical information (from past processing loops) and pro- Vehicle control is essential for guiding a car along the planned tra-
vides interfaces to query and filter its content for other components. jectory. The general control task is divided into lateral and lon-
These interfaces, called data sinks, filter content or group data for gitudinal control, reflecting the SAE requirements for operational
different consumers in order to reveal different insights. One exam- functions. This allows the control system to independently deal
ple heavily used in the automotive industry is the bird’s eye view. with vehicle characteristics (such as maximum allowable tire forces,
However, the deployed data sinks remain OEM-specific. maximum steering angles, etc.) and with safety-comfort trade-off
analysis. The trajectory control block takes a trajectory (generated at
the path planning and monitoring level) as input and controls the
5.4. Behaviour Generation lateral and longitudinal modules. The trajectory represents a future
desired state given by one of the path planning compositional func-
Behaviour generation is the highest cognitive class of functions in tions. For example, if a lane-change is needed, the trajectory will
the architecture. Here, the system generates predictions about the represent the desired position in terms of coordinates and orienta-
environment and the vehicle’s behaviour. According to the vehicle’s tion, without any information about how the acceleration, steering
goals, it develops multiple behaviour options (through behaviour or braking will be performed. The longitudinal control algorithm
generation) and selects the best one (behaviour selection). Often, the receives the target longitudinal state (such as brake until 40 km/h)
vehicle’s behaviour is analogously to a Finite State Machine (FSM) or and decides if the action will be performed by accelerating, brak-
a Markov Decision Process (MDP). The behaviour generation mod- ing, reducing throttle or using the transmission module (i.e. engine
ule develops a number of possible state sequences from the current braking). The lateral control algorithm computes the target steering
state and the behaviour reasoning module selects the best alterna- angle given the dynamic properties of a vehicle and the target trajec-
tive. Complex algorithms from Reinforcement Learning (RL) use tory. If the trajectory includes a change that requires signalling, the
driving policies stored in the knowledge database to reason and gen- communication mechanisms will be triggered through the inten-
erate a sequence of future states. Nevertheless, the functional loop tion communication module.
8 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

5.7. Actuator Interfaces components can be specified through AUTOSAR’s standardised

interface definitions. At the moment, the level of abstraction pre-
The actuator interface modules transform data coming from vehi- sented in this paper does not include software interface.
cle control layer to actuator commands. The blocks in Figure 5 rep-
resent the basic interfaces for longitudinal and lateral control.

6. INTERACTIONS BETWEEN
5.8. Data Management COMPONENTS
Data will at the centre of autonomous vehicles [21]. In spite of As mentioned in Section 4, the components in Figure 5 act as a hier-
the fact that most data requires real-time processing, persistence is archical control structure, where the level of abstraction and cog-
also needed. These concerns are represented using the data man- nition increases with the hierarchical level, mapping on the SAE
agement class of components. Global localisation features require classification of functional components. Components lower in the
internal maps storage; intelligent decision and pattern recogni- hierarchy handle less complex tasks such as operational functions,
tion algorithms require trained models (knowledge database); inter- while higher components handle planning and strategic objectives
nal state reporting requires advanced logging mechanisms (logging (e.g. global routing or trajectory planning).
database). The logging-report databases are also used to store data We propose the use of pipe-and-filter pattern for component inter-
needed to later tune and improve intelligent algorithms. Moreover, actions in flat control structures (same hierarchical level) and the
an audit database keeps authoritative logs (similar to black boxes in use of tee-and-join pipelines to represent the hierarchy. In a hier-
planes) that can be used to solve liability issues. In order to allow archical design, lower level components offer services to adjacent
dynamic deployable configurations and any change in reference upper level components. However, the data inputs are often the
variables (e.g. a calibration or a decisional variable) a value reference same. A high level representation of the system, through the tee-
database is included. and-join pipelines pattern is illustrated in Figure 6. The grey boxes
represent processing pipelines and the blue ones represent compo-
nents classes.
5.9. System and Safety Management
For each component class, a process is analogous to a pipeline.
The system and safety management block handles functional safety As example, once a user communicates a final destination, the
mechanisms (fault detection and management) and traffic safety behaviour generation process starts. This example is illustrated in
concerns. It is an instantiation of the separated safety pattern
[22] where the division criteria split the control system from the
safety operations. Figure 5 only depicts components that spot
malfunctions and trigger safety behaviour (internal state monitor,
equivalent to a watch dog), but not redundancy mechanisms. The
latter implement partial or full replication of functional compo-
nents. Moreover, safety specific functions deployed by the OEM to
increase traffic safety are distinctly represented. At this moment
they are an independent choice of each OEM.
As the level of automation increases, it is necessary to take com-
plex safety decisions. Starting with level 3, the vehicle becomes
fully responsible for traffic safety. Therefore, algorithms capable of
full safety reasoning and casualty minimisation are expected to be
deployed. While it is not yet clear how safety reasoning will be stan-
dardised and implemented in future vehicles, such components will
soon be mandatory [23]. An overview of future safety challenges
autonomous vehicles face is illustrated in [24]. With respect to the
separated safety pattern, in Figure 5 safety reasoning components
are separated from behaviour generation.

5.10. AUTOSAR Context

AUTOSAR is a consortium between OEM and component suppli-
ers which supports standardisation of the software infrastructure
needed to integrate and run automotive software. This paper does
not advocate for or against AUTOSAR. The adoption and use of this
standard is the choice of each OEM. However, due to its popular-
ity, we consider mandatory to position the work in the standard’s
context. Given AUTOSAR, the functional components in Figure 5 Figure 6 Proposed functional architecture, part II: hierarchical control
represent AUTOSAR software components. The interfaces between structure using tee-and-join pipelines pattern.
 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14 9

Figure 7, where upon receiving a destination at the HMI input fil- to represent both types of components, this reference architecture
ter, the global routing filter forwards a route to the behaviour gen- can be sometimes too complex for simple nodes.
eration filter. This filter breaks down the route in actions that have
In order to properly represent simple functions, from the opera-
to be taken by the vehicle in order to reach the destination. The
tional class, one does not need a complex world model or behaviour
actions are analogous to states in a FSM. Often, there are several
generator modules. In some components they might miss alto-
paths between two states. Further on, the behaviour selection com-
gether. However, the architecture does not impose any constraints
ponent will select the best path between two states and forward it to
on the complexity of the world model. Thus, with limited world
the planning process.
modelling or behaviour generation module the architecture can
Moreover, messages received at component level have to be pri- easily represent very simple control loops such as value compara-
oritised. For example, an actuator interface can receive commands tors. Moreover, when compared to other proposals, this reference
from the longitudinal control component or a safety specific func- model allows each individual nodes to have a level of reasoning –
tion (e.g. emergency braking). In order to decide which command while in other only components higher in a hierarchy are respon-
to execute first, the messages must contain a priority flag. Since this sible for planning. This comes as a benefit for the automotive
functionality is dependent on the component’s interface and spe- software development life-cycle and for the compositional func-
cific to OEM, this discussion is limited. tions we represented in the architecture.
Various alternatives to the chosen interaction patterns will be dis- We expect OEM to maintain their status of technology integrators
cussed in the next section. and outsource more complex functionality to their suppliers – such
as complete lane keeping or collision avoidance systems. These sys-
tems can easily be implemented as RCS nodes and integrated in the
7. TRADE-OFF ANALYSIS overall architecture.

Software architecture design is often not deterministic. Given a set We find the RCS model broad enough to allow the development of
of requirements, different architects might come to different results. complex functionality, but sometimes too complex for simple func-
The process of weighting alternatives and selecting the most appro- tions – a trade-off that can be easily overcome by simplifying each
priate decisions is called trade-off analysis. Several decisions in block of the architecture in the latter case. A more expressive alter-
this paper could be taken differently. Therefore, in this section we native would be to propose RCS nodes of different complexity –
present several alternatives to our decisions and weight their advan- with lower level nodes that can replace world modelling only with
tages and disadvantages. value judgement. This decision must be weighted independently, as
it might add clutter and other trade-offs when deciding which type
We will start from the underlying assumption of this paper – that we of node should one choose for each component.
can derive a set of valid requirements from the SAE J3016 automo-
tive standard. As mentioned in Section 2, the purpose of this stan- A third trade-off clearly regards the functional decomposition.
dard is not to provide a complete definition of autonomy, but rather Although we aim to atomically decompose every function and rep-
a minimal illustration of the functions needed in order to achieve resent each sub-component individually, there is no way to prove
it. It is meant to guide the process, and not exhaustively describe it. this is the correct way. New market trends foresee the adoption
However, we find this information sufficient for our goals, because of system-on-a-chip circuits that integrate more and more com-
any functionality on top of the minimal requirements remains the ponents. Technologies such as MobilEye [25] aim to group several
choice of each OEM. functions on a dedicated chip. In such scenarios, sensor abstrac-
tions and fusion layers could be merged. However, the functions
The second decision to be questioned is the use of NIST RCS archi- implemented by such circuits will still resemble our proposal. For
tecture as a reference architecture for our work. An in-depth com- example, even though the sensor abstraction layer compresses to
parison with other works was presented in Section 4, however, we one component, all the functionality at the sensor fusion layer still
hereby present the trade-offs that come with choosing this refer- have to be implemented because static, dynamic or road objects
ence architecture. Although it has the power to clearly discriminate detection is absolutely mandatory for autonomous driving. There-
between reactive and deductive components and is general enough fore, our atomic decomposition is able to represent these evolutions.
A fourth trade-off to be considered concerns the choice for com-
ponent interaction patterns. Several alternatives to the tee and join
pipelines pattern have been considered. One clear alternative is to
use a layered architecture – where the functional components are
grouped in a hierarchy and function calls can be made from higher
layers to lower ones [4]. However, this choice will constrain the pos-
sible interactions between components, thus limiting the design. At
first, because each layer will encapsulate some components, it will
be impossible to re-use or re-orchestrate them in other processes.
Secondly, because the function calls at lower layers are required to
come from upper layers, thus limiting even more the design.
Another alternative is to use a component based architecture, where
Figure 7 Proposed functional architecture, part III: component all the components rest at the same hierarchical layer and any com-
interaction at class level. The behaviour generation process. ponent can communicate with all others. This pattern seems a
10 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

better fit for the automotive domain, where different components most cases, the updates will target the knowledge or value reference
are deployed on various ECU and they communicate through a bus. databases.
However, it is unable to represent hierarchical reasoning.
We argue that the tee and join pattern is equivalent to the compo- 8.2. Functional Safety
nent based architecture, but has the ability to represent hierarchical
processes. This is because from a component, one can easily begin The automotive industry has high functional safety constraints
a new pipeline with any other components. If only the pipes and fil- imposed by the mandatory adherence to ISO 26262 [7]. The objec-
ter pattern was considered, than the design would be much limited. tive of functional safety is to avoid any injuries or malfunctions
However, by giving the ability to re-orchestrate filters in different of components in response to inputs, hardware or environmental
pipelines, the tee and join pipelines pattern can easily represent any changes. Error detection and duplication of safety critical compo-
kind of processes, either flat or hierarchical. nents are mechanisms suggested by ISO 26262. In this proposal,
we represent the functional component specific to error detec-
In this scenario one can define flat processes, similar to component tion, however, omit to represent any redundancy or duplicated
based orchestration, but also hierarchical processes (similar to the components.
hierarchical functional classes introduced in Section 3). The only
thing to consider is a processing priority – which defines which We also aim to fulfil a gap in the ISO 26262 standard, with regards
pipelines should execute first. to autonomous vehicles: safety reasoning [24]. To this moment it
is not clear how autonomous vehicles will behave in case an acci-
dent cannot be avoided and which risk to minimise. However, it
8. DISCUSSION is expected for future safety standards to include specification for
safety behaviour.
Software architects evaluate both the functional suitability of an
architecture and non-functional properties such as performance
or maintainability [26]. In this paper we are only interested in 9. RELATED WORK
functional suitability and completeness with respect to SAE J3016
requirements. However, we find of interest to discuss two other As mentioned in Section 4, the transition to automated and
important aspects: the position of the proposed architecture with autonomous vehicles lies at the intersection between two research
respect to (1) the automotive software development life cycle and fields with a rich history in software engineering and architecture:
(2) the ISO 26262 standard that regulates functional safety. Later, autonomous systems and automotive. The basis of the first field
in Section 9, we provide a comparison with existing literature. were laid in Section 4, although we expect many aspects of its evo-
lution to influence the autonomous vehicles field. The pervasive-
ness of cloud computing and communication that inspired cloud
8.1. Incremental Development and robotics [27] is highly relevant for the automotive field. As vehi-
Component Reuse cles begin to communicate and even distributively organise [28,29],
software architecture plays an important role in satisfying quality
The SAE classification presented in Section 2 shows an incre- constraints. New architectural paradigms, such as service orienta-
mental transition from partially automated to fully autonomous tion [30] are already explored for some aspects in automotive [31],
vehicles. The functional division of software components should with little ties to the field of robotics. Moreover, recent trends in
respect this incremental transition. Moreover, the OEM software robotic architecture adaptation [32] are expected to follow in the
development life-cycle and preference for outsourcing must be field of automotive.
taken into account.
Communication brings new constraints related to security and
As mentioned in Section 2, DDT automation is analogous to trustworthiness, which have a direct impact on automotive software
deploying and orchestrating enough driving automation features in architecture [33]. Although security is well studied in computer
order to satisfy all driving conditions (ODD) in which a human can science, specialised techniques have been proposed in the field of
drive. This assumption employs two development paths: robotics [34–37], which can be further extended to autonomous
vehicles.
1. The deployment of new software components specific to new
On a different tack, the field of automotive engineering benefits
DDT features or
from a rich history in designing, developing and deploying safety
2. Updating a driving feature with enhanced functionality. critical systems able to operate for a long period of time with-
out major interventions. Software engineering in the automotive
In Figure 5, new DDT features represent new compositional func- domain has been recognised very early as playing an important
tions specific to path planning. The use of composition functions role [2,38,39]. From there on, each stage of the software develop-
enables incremental and distributed development at the cost of ment life-cycle has been studied and naturally supported the evolu-
increased complexity for path planning and monitor. These com- tion of automotive systems; ranging from requirements engineering
ponents can be commercial-of-the-shelf products that can easily be [40–42] to software assurance [43,44] or software testing [45].
outsourced to tier one suppliers.
Software architecture design and system modelling plays a cen-
Behaviour generation improvements are solved through knowledge tral role in the development process. Research in this direction
database updates. The V2X component interfaces with the external focused on developing tools to support architecture design,
world, therefore, updates can be pushed through this component. In such as architectural description languages [46,47], architecture
 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14 11

views [48,49], architectural standards [50] and even standard- Nevertheless, the initial architectures used in the competition bear
isation of architectural styles and interfaces, as in the case of similarities with modern architectures for autonomous vehicles.
AUTOSAR [51]. The winning vehicle used a layer-based architecture as described in
Section 4 [13], with hierarchical increasing complexity from sen-
Moreover, automotive engineering has strong ties with model-
sor interfaces to perception (understanding the environment) and
driven engineering [52]; in developing [53], maintaining [54] and
planning [66]. We find a good representation of the SAE J3016
testing models [55–57]. The impact of tight safety requirements on
classes of components mentioned in Section 2, although there is a
software architecture has also been analysed in literature [58,59].
large overlap between strategic and tactical components (a normal
However, the software needed to increase the level of autonomy is consequence of the low complexity of the environment).
expected to have a big impact on all disciplines of automotive soft-
An interesting (and unique) architectural choice is to explicitly rep-
ware engineering. At first, the shift from purely deterministic soft-
resent the components responsible for data logging and storage, to
ware components to probabilistic ones where classical verification
emphasise the need to think about data and treat data and software
methods do not scale will have a big impact in the way software
as the main innovation driver. This early choice recognises the need
is designed [60]. Moreover, well known vulnerabilities of machine
to separate the constraints related to data storage from the func-
learning algorithms have to be considered early in the design
tional components that may log the data; a perspective often missed
phase [61,62]. Next generation automotive architectures take into
in later architectures.
consideration moving to more centralised models, with high
band Ethernet communication and networks closer to computer Given the constrained environment, the proposal was not con-
networks [63]. cerned with destination routing or any driving assistance or safety
features, such as lane assist or emergency braking. Therefore, the
We further focus on literature proposing functional and reference
DDT features presented are limited, constraining the architecture’s
architectures starting with level 3, since level 2 vehicles only auto-
suitability to more complex environments. Nonetheless, the work
mate lateral and longitudinal control. A historical review of level 2
shows a high level of maturity when reasoning about processing
systems is presented in [64].
pipelines and task distribution.
Behere et al. introduce a functional reference architecture intended
The second competition, the DARPA Urban Challenge, saw
to level 5 vehicles [1]. In this proposal, the authors make a clear
increased interest in computer vision based perception algorithms,
distinction between cognitive and vehicle platform functionality,
but also a better representation of behaviour generation functions
similar to the classification in tactical and operational SAE classes.
[67–70]. Moreover, an increase in computing power and centrali-
However, the functional representation groups several different
sation can be observed in all proposals.
functions in common components. For example, longitudinal and
latitudinal control of the vehicle, equivalent to acceleration, break- Building on the same architecture from the grand challenge [66],
ing and steering are grouped in only one component, although they Montemerlo et al. [69] increased the abstraction of the perception
represent different concerns and are typically deployed differently. layer to a fusion layer similar to the one represented in Figure 5.
Static and dynamic obstacle tracking (although constrained to a list
The decision and control block [1] responsible for trajectory rea-
by the complexity of the operational domain) are now first class
soning, selection and implementation is equivalent to the behaviour
citizens of the architecture. Similarly, since the vehicle operates in
generation and planning class of components from Figure 5. How-
normal road environments, the importance of local positioning is
ever, the authors only define trajectory generation as a separate
recognised.
component, leading to a rough representation of functional com-
ponents. It is not clear how this block handles all functionality and Several teams focused heavily on computer vision and threat such
what type of decisions it makes; strategic or tactic. For example, algorithms at a different layer [70,71], although use fusion as an
will the same component be responsible for deciding if a vehicle intermediary layer between perception and reasoning. The archi-
should turn left at the first road-cross, over-take the car up front tecture presented by Patz et al. [70] provide a clear distinction
and generate a trajectory for executing all manoeuvers? These hier- between strategic and functional components (through the intelli-
archical decisions correspond to a transition from strategic to tacti- gence and planning layers) and represents a good fit for the SAE
cal functions (as indicated by SAE) and should be awarded separate class of components. Other architectures, such as [68] or [71] have
components. Moreover, important components responsible for an entangled representation between strategic and tactical compo-
interactions, such as HMI, or for environmental understanding, nents because they focus on task-specific components. However, if
such as object detection, are ignored from the proposal [1]. we abstract from task-specific components, we can find a balanced
representation of the components suggested by the SAE standard.
A proliferation of competitions in constrained or unconstrained
What misses is a clear distinction between the hierarchical levels of
environments resulted in different designs of autonomous vehi-
abstractions, corresponding to the semantic understanding of the
cles. The most popular one, the DARPA Grand Challenge, started
environment needed to perform a task.
with autonomous vehicles operating in desert conditions and later
evolved to urban environments (through the DARPA Urban Chal- For another autonomous vehicles competition held in Korea, Jo
lenge). During the first competition, although the environment was et al. [72,73] introduce a more complex architecture. The pro-
challenging, the behaviour of the vehicle was relatively simple and posal comes one step closer to a general architecture, given broader
could be modelled as a simple state machine [65]. This is in con- competition goals. The model contains sensor abstractions, fusion,
trast to challenges posed by real life traffic scenarios, in which behaviour and path planning, vehicle control and actuator inter-
the environment has higher variability and requires more complex faces. In this regard, it represents similar concerns to Figure 5, with-
behaviours. out world modelling and HMI route inputs. Instead, the behaviour
 12 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

planning component integrates data coming from sensors in order standard which defines multiple levels of driving automation and
to generate an execution plan. Since the goal of the competition was includes functional definitions for each level.
limited, both localisation and behaviour reasoning components are
During the architecture design, we aim to respect the incremental
restricted (an FSM with only eight possible states that can stop for a
development process of autonomous vehicles and the distributed
barrier, detect split road, etc.). The artefact successfully represents
software development process specific to the automotive industry.
operational and tactical functions. Moreover, Jo et al. divide, for the
The final artefact represents an automotive specific instantiation of
first time, the concerns from behaviour and from path planning,
the NIST RCS reference architecture for real-time, intelligent, con-
thus obtaining several levels of cognition and control. The study
trol systems. We use the pipe-and-filter architectural pattern for
also reveals important details for in-vehicle ECU deployment and a
component interaction and the tee-and-join pipeline pattern to rep-
mapping to AUTOSAR.
resent a hierarchical control structure. Several trade-offs and alter-
In a different competition, called the Grand Cooperative Driving native decisions are discussed within the paper.
Challenge, teams raced to develop vehicles that can successfully
Future work might include refinement through expert opinion.
Q2 exchange information and form platoons [74–78]. Although the
Later steps consider component interface design, a choice for hard-
environmental monitoring requires less semantic understanding,
ware architecture, functional component distribution across ECUs
the representation of tactical and operational function across the
and component distribution inside local networks in order to sat-
proposed architectures is similar to the division made by SAE J3016.
isfy security requirements. Q3
In particular, the architecture presented in [78] uses the tee-and-
join pipelines patter introduced above.
An important contribution from industry research is the work of REFERENCES
Ziegler et al. [79] at Mercedes Benz, later evolved to cooperative
[1] Behere, S, Törngren, M. A functional reference architecture for
driving [77]. Although it has a descriptive purpose, the system
autonomous driving. Inf Softw Technol 2016;73;136–50.
overview is the most similar to the SAE suggestion and the proposal
[2] Broy, M. Challenges in automotive software engineering. In Inter-
introduced in this paper. It features a clear distinction between
national Conference on Software Engineering (ICSE’06), ACM;
object recognition, localisation, motion planning and vehicle con-
2006, pp. 33–42, Q4
trol, analogous to sensor fusion, behaviour generation, planning
[3] Society of Automotive Engineers (SAE). SAE international taxon-
and vehicle control in Figure 5. Another important contribution is
omy and definitions for terms related to on-road motor vehicle
the representation of data storage functionality for digital maps and
automated driving systems, levels of driving automation, 2014. Q5 Q6
reactive components such as emergency braking.
[4] Staron, M. Automotive software architectures. Springer Interna-
Overall, we observe two approaches in the literature: (1) a high tional Publishing; 2017, p. 1. Q7
level overview of system components where the functionality is [5] Garlan, D. Software architecture: a roadmap. In Conference
not clearly divided and (2) proofs-of-concept from experiments on The Future of Software Engineering (ICSE’00), ACM; 2000,
with autonomous features or competition with limited operational pp. 91–101.
domain. The lessons learned from participating in different com- [6] Serban, A, Poll, E, Visser, J. A standard driven software archi-
petitions are very valuable. Most architectures considered here tecture for fully autonomous vehicles. In Proceedings of WASA
have a large overlap with the SAE J3016 description and classes of Workshop; 2018.
functions, with the current proposal and between themselves. The [7] International Organization for Standardization (ISO). ISO stan-
overlap between themselves reveals an intrinsic set of components dard 26262:2011 Road vehicles – Functional safety; 2011.
without which autonomy will not be possible. They represent the [8] Ruparelia, NB. Software development lifecycle models. ACM SIG-
least can be done to automate some functions. The disadvantage SOFT Softw Eng Notes 2010;35;8–13.
of developing with concrete scenarios in mind is the lower level of [9] Wieringa, R. Design science methodology: principles and prac-
abstraction needed to develop a reference architecture. tice. In International Conference on Software Engineering
(ICSE’10), ACM; 2010, pp. 493–4.
In this paper we try to overcome this advantage using a standard
[10] Horowitz, R, Varaiya, P. Control design of an automated highway
driven and more fine-grained functional decomposition. Several
system. Proc IEEE 2000;88;913–25.
other constraints, such as the automotive software development
[11] Maes, P. Behavior-based artificial intelligence. In Proceedings of
life-cycle or the role of the OEMs are taken into account, leading
the Fifteenth Annual Meeting of the Cognitive Science Society;
to a more general proposal. Moreover, since the ultimate goal is to
1993, pp. 74–83.
achieve level 5 autonomy, the functional decomposition takes into
[12] Albus, JS. The NIST real-time control system (RCS): an approach
account the semantics of the information consumed, which natu-
to intelligent systems research. J Exp Theor Artif Intell 1997;9;
rally leads to incremental, hierarchical, abstractions.
2–3.
[13] Gat E, Bonnasso, RP. On three-layer architectures. Artif Intell
Mobile Robot 1998;195;210.
10. CONCLUSIONS AND FUTURE [14] Muscettola, N, Dorais, GA, Fry, C, Levinson, R, Plaunt, C. Idea:
RESEARCH planning at the core of autonomous reactive agents. In NASA
Workshop on Planning and Scheduling for Space; 2002.
We introduce a functional software architecture for fully auto- [15] Konolige, K, Myers, K, Ruspini, E, Saffiotti, A. The Saphira archi-
nomous vehicles. Since the automotive industry is highly standard- tecture: a design for autonomy. J Exp Theor Artif Intell 1997;9;
ised, we follow the functional requirements from an automotive 2–3.
 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14 13

[16] Volpe, R, Nesnas, I, Estlin, T, Mutz, D, Petras, R, Das, H. The [36] Dieber, B, Breiling, B. Security considerations in modular mobile
CLARAty architecture for robotic autonomy. IEEE Aerosp Conf manipulation. In 2019 Third IEEE International Conference on
2001;1;121–32. Robotic Computing (IRC), IEEE; 2019, pp. 70–7.
[17] An architectural blueprint for autonomic computing. 4th ed., [37] Priyadarshini, I. Cyber security risks in robotics. In: Cyber secu-
Q8 Technical Report, IBM; 2006. White paper. rity and threats: concepts, methodologies, tools, and applications,
[18] Nilsson, NJ. Principles of artificial intelligence. Morgan Kauf- IGI Global; 2018, pp. 1235–50.
mann; 2014. [38] Broy, M, Kruger, IH, Pretschner, A, Salzmann, C. Engineering
[19] Albus, JS, Rippey, W. RCS: a reference model architecture for automotive software. Proc IEEE 2007;95;356–73.
intelligent control. In From Perception to Action Conference [39] Pretschner, A, Broy, M, Kruger, IH, Stauner, T. Software engi-
Conference, 1994, IEEE; 1994, pp. 218–29. neering for automotive systems: a roadmap. In Future of Software
[20] Buschmann, F, Henney, K, Schmidt, DC. Pattern-oriented soft- Engineering (FOSE’07), IEEE; 2007, pp. 55–71.
ware architecture. Vol. 5, John Wiley & Sons; 2007. [40] Weber, M, Weisbrod, J. Requirements engineering in automotive
[21] Johanson, M, Belenki, S, Jalminger, J, Fant, M, Gjertz, M. Big development-experiences and challenges. In Proceedings IEEE
automotive data: leveraging large volumes of data for knowledge- Joint International Conference on Requirements Engineering,
driven product development. In 2014 IEEE International Confer- IEEE; 2002, pp. 331–40.
ence on Big Data (Big Data), IEEE; 2014, pp. 736–41. [41] Vogelsang, A, Fuhrmann, S. Why feature dependencies challenge
[22] Rauhamäki, J, Vepsäläinen, T, Kuikka, S. Functional safety system the requirements engineering of automotive systems: an empirical
patterns. In Proceedings of VikingPLoP, Tampere University of study. In 2013 21st IEEE International Requirements Engineering
Technology; 2012. Conference (RE), IEEE; 2013, pp. 267–72.
[23] Bonnefon, JF, Shariff, A, Rahwan, I. The social dilemma of [42] Staron, M. Requirements engineering for automotive embed-
autonomous vehicles. Science 2016;352;1573–6. ded systems. In: Automotive systems and software engineering,
[24] Serban, A, Poll, E, Visser, J. Tactical safety reasoning. a case for Springer; 2019, pp. 11–28.
autonomous vehicles. Proceedings of Ca2V Workshop; 2018. [43] Luo, Y, Van den Brand, M, Engelen, L, Klabbers, M. A mod-
[25] Mobileye, N. Introduces EyeQ vision system-on-a-chip high per- eling approach to support safety assurance in the automotive
formance. In Low Cost Breakthrough for Driver Assistance Sys- domain. In: Progress in Systems Engineering, Springer; 2015,
tems, Detroit, Michigan; 2004. pp. 339–45.
[26] Dobrica, L, Niemela, E. A survey on software architecture analysis [44] Fung, NL, Kokaly, S, Di Sandro, A, Salay, R, Chechik, M. MMINT-
methods. IEEE Trans Softw Eng 2002;28;638–53. A: a tool for automated change impact assessment on assurance
[27] Hu, G, Tay, WP, Wen, Y. Cloud robotics: architecture, challenges cases. In International Conference on Computer Safety, Reliabil-
and applications. IEEE Netw 2012;26;21–8. ity, and Security, Springer; 2018, pp. 60–70.
[28] Serban, AC, Poll, E, Visser, J. A security analysis of the ETSI its [45] Markthaler, M, Kriebel, S, Salman, KS, Greifenberg, T,
vehicular communications. In International Conference on Com- Hillemacher, S, Rumpe, B, Schulze, C, Wortmann, A, Orth, P,
puter Safety, Reliability, and Security, Springer; 2018, pp. 365–73. Richenhagen, J. Improving model-based testing in automotive
[29] García, S, Menghi, C, Pelliccione, P, Berger, T, Wohlrab, R. An software engineering. In 2018 IEEE/ACM 40th International
architecture for decentralized, collaborative, and autonomous Conference on Software Engineering: Software Engineering in
robots. In 2018 IEEE International Conference on Software Archi- Practice Track (ICSE-SEIP), IEEE; 2018, pp. 172–80.
tecture (ICSA), IEEE; 2018, pp. 75–7509. [46] Debruyne, V, Simonot-Lion, F, Trinquet, Y. EAST-ADL: an archi-
[30] Koubaa, A. Service-oriented software architecture for cloud tecture description language. In IFIP World Computer Congress,
robotics. arXiv preprint arXiv:1901.08173; 2019. TC 2, Springer; 2004, pp. 181–95.
[31] Kugele, S, Hettler, D, Peter, J. Data-centric communication and [47] Dajsuren, Y, van den Brand, M, Serebrenik, A, Huisman, R. Auto-
containerization for future automotive software architectures. In motive ADLs: a study on enforcing consistency through multi-
2018 IEEE International Conference on Software Architecture ple architectural levels. In Proceedings of the 8th International
(ICSA), IEEE; 2018, pp. 65–6509. ACM SIGSOFT Conference on Quality of Software Architectures,
[32] Aldrich, J, Garlan, D, Kästner, C, Le Goues, C, Mohseni-Kabir, A, ACM; 2012, pp. 71–80.
Ruchkin, I, Samuel, S, Schmerl, B, Timperley, CS, Veloso, M. [48] Grönninger, H, Hartmann, J, Krahn, H, Kriebel, S, Rothhart, L,
Model-based adaptation for robotics software. IEEE Software Rumpe, B. Modelling automotive function nets with views for
2019;36;83–90. features, variants, and modes. arXiv preprint arXiv:1409.6628;
[33] Ferrandez, R, Dajsuren,Y, Karkhanis, P, Fünfrocken, M, 2014.
Pillado, M. Modeling the C-ITS architectures: C-mobile case [49] Dajsuren, Y, Gerpheide, CM, Serebrenik, A, Wijs, A, Vasilescu, B,
study. In ITS World Congress; 2018. van den Brand, MG. Formalizing correspondence rules for
[34] Vilches, VM, Kirschgens, LA, Calvo, AB, Cordero, AH, Pisón, automotive architecture views. In Proceedings of the 10th
RI, Vilches, DM, Rosas, AM, Mendia, GO, Juan, LUS, Ugarte, IZ. International ACM Sigsoft Conference on Quality of Software
Introducing the Robot Security Framework (RSF), a standardized Architectures, ACM; 2014, pp. 129–38.
methodology to perform security assessments in robotics. arXiv [50] Broy, M, Gleirscher, M, Merenda, S, Wild, D, Kluge, P,
preprint arXiv:1806.04042; 2018. Krenzer, W. Toward a holistic and standardized automotive archi-
[35] Vilches, VM, Gil-Uriarte, E, Ugarte, IZ, Mendia, GO, Pisón, RI, tecture description. Computer 2009;42;98–101.
Kirschgens, LA, Calvo, AB, Cordero, AH, Apa, L, Cerrudo, C. [51] Fürst, S, Mössinger, J, Bunzel, S, Weber, T, Kirschke-Biller, F,
Towards an open standard for assessing the severity of robot Heitkämper, P, Kinkelin, G, Nishikawa, K, Lange, K. AUTOSAR –
security vulnerabilities, the Robot Vulnerability Scoring System a worldwide standard is on the road. In 14th International VDI
(RVSS). arXiv preprint arXiv:1807.10357; 2018. Congress Electronic Systems for Vehicles, Baden-Baden; 2009.
14 A. Serban et al. / Journal of Automotive Software Engineering 00(0) 1–14

[52] Hutchinson, J, Rouncefield, M, Whittle, J. Model-driven engi- the robot that won the DARPA Grand Challenge. J Field Robot
neering practices in industry. In Proceedings of the 33rd Inter- 2006;23;661–92.
national Conference on Software Engineering, ACM; 2011, [67] Urmson, C, Baker, C, Dolan, J, Rybski, P, Salesky, B, Whittaker, W,
pp. 633–42. Ferguson, D, Darms, M. Autonomous driving in traffic: boss and
[53] Wan, J, Canedo, A, Al, MA. Functional model-based design the urban challenge. AI Mag 2009;30;17.
methodology for automotive cyber-physical systems. IEEE Syst J [68] Kammel, S, Ziegler, J, Pitzer, B, Werling, M, Gindele, T,
2015;11;2028–39. Jagzent, D, Schröder, J, Thuy, M, Goebl, M, Hundelshausen,
[54] Völter, M, Stahl, T, Bettin, J, Haase, A, Helsen, S. Model-driven FV. Team AnnieWAY’s autonomous system for the 2007 DARPA
software development: technology, engineering, management. Urban Challenge. J Field Robot 2008;25;615–39.
John Wiley & Sons; 2013. [69] Montemerlo, M, Becker, J, Bhat, S. Junior: the Stanford entry in
[55] Dajsuren, Y, Van Den Brand, MG, Serebrenik, A, Roubtsov, S. the urban challenge. J Field Robot 2008;25;569–97.
Simulink models are also software: modularity assessment. In [70] Patz, BJ, Papelis, Y, Pillat, R, Stein, G, Harper, D. A practical
Proceedings of the 9th International ACM Sigsoft Conference on approach to robotic design for the darpa urban challenge. J Field
Quality of Software Architectures, ACM; 2013, pp. 99–106. Robot 2008;25;528–66.
[56] Bringmann, E, Krämer, A. Model-based testing of automotive sys- [71] Bacha, A, Bauman, C, Faruque, R, Fleming, M, Terwelp, C,
tems. In 2008 1st International Conference on Software Testing, Reinholtz, C, Hong, D, Wicks, A, Alberi, T, Anderson, D. Odin:
Verification, and Validation, IEEE; 2008, pp. 485–93. team VictorTango’s entry in the DARPA Urban Challenge. J Field
[57] Petrenko, A, Timo, ON, Ramesh, S. Model-based testing of auto- Robot 2008;25;467–92.
motive software: some challenges and solutions. In Proceedings [72] Jo, K, Kim, J, Kim, D, Jang, C, Sunwoo, M. Development of
of the 52nd Annual Design Automation Conference, ACM; 2015, autonomous car – part I. IEEE Trans Ind Electron 2014;61;
p. 118. 7131–40.
[58] Saberi, AK, Luo, Y, Cichosz, FP, van den Brand, M, Jansen, S. [73] Jo, K, Kim, J, Kim, D, Jang, C, Sunwoo, M. Development of
An approach for functional safety improvement of an existing autonomous car – part II. IEEE Trans Ind Electron 2015;62;
automotive system. In 2015 Annual IEEE Systems Conference 5119–32.
(SysCon) Proceedings, IEEE; 2015, pp. 277–82. [74] Geiger, A, Lauer, M, Moosmann, F, Ranft, B, Rapp, H, Stiller, C,
[59] Saberi, AK, Barbier, E, Benders, F, Van Den Brand, M. On func- Ziegler, J. Team AnnieWAY’s entry to the 2011 grand cooperative
tional safety methods: a system of systems approach. In 2018 driving challenge. IEEE Trans Intell Transp Syst 2012;13;1008–17.
Annual IEEE International Systems Conference (SysCon), IEEE; [75] Guvenc, L, Uygan, IMC, Kahraman, K, Karaahmetoglu, R,
2018, pp. 1–6. Altay, I, Senturk, M, Emirler, MT, Karci, AEH, Guvenc, BA,
[60] Serban, AC. Designing safety critical software systems to man- Altug,E. Cooperative adaptive cruise control implementation of
age inherent uncertainty. In 2019 IEEE International Confer- team mekar at the grand cooperative driving challenge. IEEE
ence on Software Architecture Companion (ICSA-C), IEEE; 2019, Trans Intell Transp Syst 2012;12;1062–74.
pp. 246–9. [76] Kianfar, R, Augusto, B, Ebadighajari, A, Hakeem, U,
[61] Serban, AC, Poll, E, Visser, J. Adversarial examples-a com- Nilsson, J, Raza, A, Tabar, RS, Irukulapati, NV, Englund, C,
plete characterisation of the phenomenon. arXiv preprint Falcone, P. Design and experimental validation of a cooperative
arXiv:1810.01185; 2018. driving system in the grand cooperative driving challenge. IEEE
[62] Ray, S. Safety, security, and reliability: the automotive robust- Trans Intell Transp Syst 2012;13;994–1007.
ness problem and an architectural solution. In 2019 IEEE Interna- [77] Taş, ÖS, Salscheider, NO, Poggenhans, F, Wirges, S,
tional Conference on Consumer Electronics (ICCE), IEEE; 2019, Bandera, C, Zofka, MR, Strauss, T, Zöllner, JM, Stiller, C. Mak-
pp. 1–4. ing Bertha cooperate-team AnnieWAYs entry to the 2016 grand
[63] Zheng, B, Liang, H, Zhu, Q, Yu, H, Lin, CW. Next generation auto- cooperative driving challenge. IEEE Trans Intell Transp Syst
motive architecture modeling and exploration for autonomous 2017;19;1262–76.
driving. In 2016 IEEE Computer Society Annual Symposium on [78] Hult, R, Sancar, FE, Jalalmaab, M, Vijayan, A, Severinson, A,
VLSI (ISVLSI), IEEE; 2016, pp. 53–8. Di Vaio, M, Falcone, P, Fidan, B, Santini, S. Design and experi-
[64] Khodayari, A, Ghaffari, A, Ameli, S, Flahatgar, J. A historical mental validation of a cooperative driving control architecture for
review on lateral and longitudinal control of autonomous vehicle the grand cooperative driving challenge 2016. IEEE Trans Intell
motions. In ICMET; 2010, pp. 421–9. Transp Syst 2018;19;1290–301.
[65] Chen, Q, Ozguner, U, Redmill, K. Ohio state university at the 2004 [79] Ziegler, J, Bender, P, Schreiber, M, Lategahn, H, Strauss, T,
DARPA Grand Challenge: developing a completely autonomous Stiller, C, Dang, T, Franke, U, Appenrodt, N, Keller, CG. Making
vehicle. IEEE Intell Syst 2004;19;8–11. Bertha drive – an autonomous journey on a historic route. IEEE
[66] Thrun, S, Montemerlo, M, Dahlkamp, H, Stavens, D, Aron, A, Mag 2014;6;8–20.
Diebel, J, Fong, P, Gale, J, Halpenny, M, Hoffmann, G. Stanley:
Queries:

Q1: AU: Please confirm whether inserted corresponding author details is appropriate.
Q2: AU: References have been renumbered in ordered to maintain sequential order. Please confirm.
Q3: AU: Please provide “Conflict of Interest,” “Author Contributions,” “Funding Statement” and ”Acknowledgments”
Q4: AU: Please provide conference location for Refs. [2, 5–7, 9, 11, 14, 19, 21, 22, 24, 29, 30, 33, 36, 39–41, 44–47, 49, 52, 56–60, 62–64].
Q5: Publisher Query: Please provide DOI number for Refs. [3, 7, 11, 13, 14, 16–20, 22, 25, 30, 33–35, 40, 45, 48, 51, 54, 58, 61].
Q6: AU: Please provide complete reference details for Refs. [3, 7].
Q7: AU: Please provide publisher location for Refs. [4, 18, 54].
Q8: AU: Please provide author name and publisher location for Ref. [17, 37, 42, 43].