A Standard Driven Software Architecture for Fully Autonomous Vehicles

Abstract

The development of self-driving vehicles is often regarded as adding a layer of intelligence on top of classic vehicle platforms. However, the amount of software needed to reach autonomy will exceed the software deployed for operation of normal vehicles. As complexity increases, the demand for proper structure also increases. Moreover, the shift from open, deterministic components to more opaque, probabilistic software components raises new challenges for system designers. In this paper we introduce a functional software architecture for fully autonomous vehicles aimed to standardise and ease the development process. Existing literature presents past experiments with autonomous driving or implementations specific to limited domains (e.g. winning a competition). The architectural solutions are often an after-math of building or evolving an autonomous vehicle and not the 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, it is often difficult to adopt the proposals. 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.

Towards Using Probabilistic Models to Design Software Systems with Inherent Uncertainty

“…Throughout the paper we use an example from autonomous driving, inspired by [1,10] -the design of a perception system for scene understanding. The system performs three tasks: (1) object detection, which aims to identify the location of all objects in an image, (2) semantic segmentation, which assigns each pixel in an image to a predefined class, and (3) depth estimation, which determines the position of obstacles or the road surface.…”

“…In Fig. 1a and b we present two architecture candidates inspired by [10] and [1]. The relevant functional components are illustrated using circles while the input coming from the camera is depicted with a rectangle.…”

“…The first figure illustrates the end-to-end paradigm, where all components of the system are jointly trained to form a representation relevant to planning. This corresponds to the recommendation in [10]. The components share a base network for feature extraction and have independent layers to decode the features for each task.…”

Effects of Automation and Fatigue on Drivers from Various Age Groups

“…In addition to the impairing influence of drowsiness in manual driving, monitoring the drivers' state and their ability to control the car is one of the main requirements of the third level of automated vehicles [5]. At this automated level, the driver will still be responsible for the car's performance and they should act safely and promptly in case of automated system faults or complex traffic scenarios [6,7]. Notwithstanding research findings [8] showing that learning can interact with fatigue, leading to shorter reaction times, most previous studies demonstrated that drowsiness has a significant influence to increase drivers' reaction time for braking or steering maneuvers in risky situations to prevent accidents [9][10][11].…”

Safety first: User needs analysis of advanced driver assistance systems (ADAS) to determine learning preferences

“…Figure 1. SAE J3106 Levels of Automation in Automotive Vehicles* * (Serban, Poll, & Visser, 2020) ADAS includes a range of features, including adaptive cruise control (ACC), lane keep assist (LKA), forward emergency braking (FEB), etc. While the intention may be to improve passenger and pedestrian safety and enhance the driving experience, the driver must assimilate a lot of new information to properly use the advanced features.…”