Technical Architecture

Beside the functional architecture, a technical architecture is specified in the system design. The technical architecture defines a set of hardware components, e.g., sensors, actuators, and ECUs, which are required for the execution of the functional components. The technical architecture of the lane change assistant integrates a sensor configuration (cf. Section 3.3.2.1) with a execution platform for the system’s functional components (cf. Section 3.3.2.2).

3.3.2.1. Sensor Configuration

The lane change assistant has to sufficiently perceive the vehicle’s environment in order to make safe decisions about lane changes. While an ACC solely considers preceding vehicles in the same lane, the lane change assistant has to consider vehicles positioned all around the automated ego vehicle in near and far distances.

Following the functional architecture (cf. Fig. 3.3), one sensor might be sufficient to fully perceive the automated vehicle’s environment. LIDAR sensors exist, e.g., Velodyne HDL-64E (cf. [MS11]), which are able to provide a 360◦ horizontal view around the automated vehicle (cf. Fig. 3.14a). In Fig. 3.14, each sensor unit is represented as a rectangle or circle for its position in the vehicle and its occupancy of the vehicle’s environment — range of view — is depicted as a colored cone. Cones of multiple sensors may overlap representing the overlapping of their perception fields. The view around the vehicle is only limited in the vertical direction by the aperture of these sensors. For the

3.3. System Design

Velodyne HDL-64E sensor the vertical field of view ranges from +2◦ to −24.9◦. Such sensors can detect all vehicles in the vehicle’s vicinity.

Another approach for perceiving the environment of the vehicle is the installation of multiple sensor modules around the vehicle with limited fields of view (cf. Fig. 3.14b). A single sensor module with limit fields of view is incapable of perceiving the complete vicinity of the automated ego vehicle. An aggregation of data from limited sensor modules all around the vehicle enables the generation of a complete view of the vehicle environment. The aggregation of data from multiple sensor modules requires to identify and relate the incidences of environmental objects in the fields of view of multiple sensors — especially for sensors with overlapping fields of view (cf. Fig. 3.14b). LIDAR sensors are not only able to detect large dynamic objects, e.g., other vehicles, but also smaller objects, e.g., road markings. Therefore, LIDAR sensors allow the detection of the road and its driving lanes (cf. [Zei13]) necessary for the planning of lane changes. Other prevalent sensors for the perception of the vehicle environment are RADAR, ultrasonics, and camera sensors.

The data generated by sensors for a 360◦ view around the automated ego vehicle is enormous. With the increasing level of automation (cf. Fig. 2.4), more diverse sets of sensors have to be deployed in order to perceive the complete vicinity of automated ego vehicles consistently. Additional ECUs have to be introduced in automated vehicles for processing requirements of the increasing sensor data (cf. environment perception in Fig. 3.3) and their complex analyses by automation functions. The following section describes the architecture of such an execution platform for automated vehicles.

3.3.2.2. Execution Platform

Prior to ADAS, E/E architectures of vehicles were subject to different vehicle subsystems (domains), e.g., powertrain, bodywork, chassis, or HMI (cf. [SZ13]). Each subsystem has been developed independently from the other subsystems. These architecture emerged with the introduction of stabilization functions, e.g., ABS and ESC. These E/E archi- tectures distributed the vehicle functions over more than 80 ECUs in vehicles. ECUs are robust processing units for embedded systems which withstand large temperature differences but offer only limited processing and data storage capabilities. The vehicle functions are common their ECUs are highly optimized in order to save costs. For the exchange of data, ECUs of subsystems are connected with each other by communication bus systems (cf.[Bro03]), e.g., CAN, media oriented systems transport (MOST), or FlexRay (cf. [Fle05]). Gateways, which can be seen as specialized ECUs, interconnect the different subsystems and organize the message transfer between of their sub-networks (cf. [Kim+08]).

Figure 3.15a (cf. [SZ13]) shows the basic structure of such E/E architectures. Blocks denote hardware components, e.g., ECU or sensor units, while lines between blocks represent physical connections between hardware components. We do not restrict the data flow directions between hardware components over physical connections and do not differentiate the type of physical connections — if they are proprietary direct connections or standard bus systems, e.g., CAN or MOST. In case the type of physical connection is

Powertrain Bodywork Chassis HMI Central Gateway Powertrain DCU ECU ECU ECU ECU Bodywork DCU ECUl ECU ECU ECU Chassis DCU ECU ECU ECU ECU ECU ECU ECU ECU ECU

(a) Execution platform aligned by vehicle subsystems.

Powertrain Bodywork Chassis HMI External Gateway Powertrain DCU ECU ECU ECU ECU Bodywork DCU ECU ECU ECU ECU Chassis DCU ECU ECU ECU ECU HMI DCU ECU ECU ECU ECU Backbone Bus

(b) Execution platform with domain controller units.

Figure 3.15.: Evolution of E/E architectures.

defined and important, we label the corresponding connection with its type. In reality, E/E architectures vary between car manufacturers and are more complex then presented in Fig. 3.15a (cf. [Wed16]).

The lane change assistant is more processing-intensive than vehicle functions for the vehicle stabilization, e.g., ABS and ESC, and require information from all vehicle subsystems and even external sources, e.g., road infrastructure or Internet services (cf. [Ben+14; Ger+14]). Recent E/E architectures in the automotive domain introduce domain control units (DCUs) in subsystems for the execution of today’s and future complex vehicle functions, e.g., the lane change assistant (LCA) (cf. Fig. 3.15b) (cf. [Som+13]) DCUs address the requirements for high computational power and large storage capabilities under reasonable costs by incorporating hardware components from customer electronics, e.g., ARM central processing units (CPUs) or Ethernet networks.

Each DCU is connected to the existing ECUs and sensors of its subsystem via the existing bus networks. The DCU acts as the master of its subsystem and gathers, e.g., sensor data, and forwards this data to other functions within its subsystem or other subsystems. The DCUs of different subsystems exchange their data via a high speed backbone, e.g., Ethernet (cf. Fig. 3.15b). The lane change assistant is executed on the DCU in the chassis resp. safety subsystem but has access to all required data for the processing of its environment representation and decision making (cf. Fig. 3.3). The result of its decision making is transmitted for execution to the other subsystems via the high-speed network. The idea of centralization within automotive E/E architectures can be evolved to the integration of multiple subsystems on one single DCU or to an architecture with only one

3.3. System Design PC 1 PC 2 Engine Control Stereo Camera Ethernet Gateway

Figure 3.16.: Processing network of the prototype vehicle.

large vehicle control unit which integrates and processes all complex and cross-cutting functions of one vehicle. Furthermore, functions are envisaged to communicate and share data with Internet services outside the vehicles (cf. [Ger+14]).

None of the prototype vehicles (cf. Fig. 3.16) in the case study incorporate one of the presented E/E architectures (cf. Fig. 3.15). Instead, the original hardware equipment of a production vehicle is extended by two customer computers, a gateway computer, and an Ethernet bus. The original hardware components of the production vehicle, e.g., ECUs and CAN buses, process the original vehicle functions of the prototype vehicle, like ESC or automatic parking assistant. The two customer computers are introduced as the execution platform for the software implementation of the highway pilot and lane change assistant (cf. Fig. 3.16). The environment perception of the lane change assistant is executed on the first computer while the situation assessment and behavior planning of the lane change assistant and other ADAS, e.g., ACC and LKAS, are executed on the second computer (cf. PC 1 and PC 2 of Fig. 3.16).

The two computers are connected via an Ethernet network with each other for the exchange of function internal data, e.g., the scene, and with the gateway computer for the communication with vehicle sensors and actuators, e.g., ultrasonic sensor, steering, brakes, and engine (cf. Fig. 3.16). The gateway connects the execution platform of the lane change assistant with the existing communication systems of the vehicle, e.g., CAN and FlexRay. Sensors, which have been installed particularly for the lane change assistant, are also connected to the gateway computer. Sensor data is received from the vehicle sensor and converted by the gateway into the appropriate data format for the processing of environment perception. Actions by the lane change assistant are transferred via the gateway to the vehicle actuators as their inputs.

The execution platform of the prototype vehicle for the lane change assistant does not focus on sustainability but adaptability and changeability in order to enable efficient evaluation, adaption, and improvement of the system and its algorithms early in the development. The customer computers allow fast development iterations of the lane change assistant without flashing its software code for every new version. Flashing ECUs is a time consuming and costly task — especially under consideration of the typical high frequency of changes to functional components in the early stages of system development.

As the necessity for changes of the lane change assistant decreases in later stages of the development, the hardware platform of the new prototype vehicles may converge to the final hardware used in production vehicles.

The interaction of the lane change assistant with its environment imposes potential risks for itself, its passenger, and all objects and persons in its vicinity. Therefore, it is necessary to address the correct implementation of safe system behavior in order to mitigate these risks. The presented lane change assistant has been straightforwardly designed. The presented sensor configuration and execution platform are not applicable for automated driving under consideration of safety aspects (cf Definition 2.2). Especially for higher level of automation (cf. Fig. 2.4), a single sensor configuration (cf. Fig. 3.14a) would represents a single point of failure for a complete loss of the environment perception. Potential failures and risks have to be identified and mitigated for the lane change assistant in order to ensure the safety of the lane change assistant during operation in the real world (cf Definition 2.2). The safety analysis is exemplarily performed in the following section on the presented system design concept for the lane change assistant.