Software Building Blocks for AV Systems

Elektrobit’s unique software framework is designed to smooth development of automated driving functions.

August 1, 2018

Sebastian Klass

Automated valet parking is an example of a practical application of the software framework. (Credit: Elektrobit)

When the development of ADAS functions or even automated driving up to SAE Level 4 strives for increased functionality, it also increases the complexity of the software environment — and the related development processes. Why?

Typically, the number of involved ECUs is growing. Existing functional and system architectures were in many cases not defined with Level 3 or 4 automation in mind. Although functions targeted at different automation levels basically need the same or very similar features, a reuse is often difficult or even impossible.

Similar problems arise when existing software modules should be reused over multiple generations of models of vehicles. Elements like sensors, actuators or components for fusion, function, and control, need to be incorporated from a hardware as well as from a software perspective. All of this leads to a non-linear growth in the functional complexity of such projects.

There are additional obstacles. For example, when multiple partners are involved in the development, the necessary interfacing and coordination causes additional overhead. Consider also the strategic aspect: Automated driving requires software components like an environment model and a highly precise positioning function. But both only allow for a relatively low degree of differentiation over competitors. The actual driver assistance systems and their handling may differ between OEMs, but the underlying basics such as the environment model and the positioning do not.

Still, efforts to bring these components to perfection tie up resources that could otherwise enable development of components that allow for much more differentiation, such as the HMI. This poses a dilemma, especially as the HMI’s functions are of increasing importance in cars with Level 3 or Level 4 automation because the driver will actually spend more time with these functions when handing over the driving task to the vehicle.

But the environment model or positioning functions play an important role for the safety and reliability of automated vehicles — aspects for which the OEMs are directly responsible. So, functional safety as well as security must be respected with an extremely high commitment.

Speeding development within a framework

Fig. 2 — Overall architecture of the EB robinos framework for automated driving. (Credit: Elektrobit)

All described parameters speak clearly in favor of using a software framework in the development of automated driving functions. Such a framework can be viewed as a set of building blocks for system design and development. The typical architecture of such a framework, shown in Fig. 2, is known as EB robinos.

The reference architecture shown supports all automation levels from SAE Levels 1 to 4. The according concepts will also play an important role in developing future Level 5 solutions. However, for full Level 5 solutions questions like system and software architecture might need heavy changes and the number of highly dynamic situations will substantially increase. Additional technologies must then be refined and facilitated before such projects can become a reality.

The framework is characterized by a consistent modular design which extensively supports reusability and scalability. Standardized modules and clearly defined interfaces also help to reduce the overhead of complex development projects. As these modules are designed to be hardware- and sensor-agnostic, they can be easily and quickly adapted to an OEM’s chosen hardware platform.

Independently from the actual hardware, the software will support necessary functions such as sensor fusion. This standardized and modular approach defines a functional architecture and open interfaces between software components as well as to external interfaces. This again can greatly reduce complexity, effort, and costs.

In addition to off-the-shelf modules like the environment model, sensor fusion, and positioning, the framework typically includes diagnostic components such as a safety monitor that will constantly check the sensors and software modules and ensure that they are functional and deliver sensible values. Also, a supervisor module can provide and control algorithmic redundancy and oversee the execution of vital functions — for example checking planned trajectories for freedom of collision or checking the correct operation of motion management.

Software building blocks for AVs can be distinguished between differentiating and non-differentiating functionalities. For the former, OEMs will most likely leverage in-house know-how and their specific look and feel. On the other hand, non-differentiating software elements such as parts of the environment model can greatly profit from standardization and scaling factors. New components can be rapid prototyped on a PC and subsequently be run in environments such as Adaptive AUTOSAR or Linux.

Also, components can be added or removed depending on customers’ needs. This makes the reuse of software building blocks possible, while minimizing development, application and testing efforts.

Building blocks for developers

An overview of some typical functional modules will provide a better understanding of the functional scope and interworking of the particular building blocks.

Fig. 3 — The environment model consists of four main components: Object fusion, freespace and obstacle fusion, road fusion, and traffic-rules fusion. (Credit: Elektrobit)

The environment model (Fig. 3) consists of four main components. Object fusion combines objects recognized by the radar and lidar sensors as well as the cameras and possibly additional sensors based on tracked bounding box models. It outputs modelled objects with their relative position, size, movement, a classification (for example other cars, cyclists, and pedestrians), and additional information.

Freespace and obstacle fusion describes the free space as well as static obstacles such as guard rails or traffic signs around the car based on a polygon curve. For this purpose, this module works with the raw data and modelled objects of the environment sensors and extracts information about where the car could drive. Road fusion extracts a road or lane geometry both from the camera signals (identifying lane markings) as well as from the road “furniture” delivered by the freespace and obstacle fusion. It combines this information with the trajectories of dynamic objects on the road as well as data coming from digital maps in order to deliver an overall representation of the road and lane geometry.

Traffic-rules fusion takes care of traffic-rules-related information like traffic signs, traffic lights, or pedestrian crosswalks recognized by the camera(s) or available from digital maps. It outputs rule-based information such as speed limits, no passing, or right-of-way rules.

Fig.4 — The framework also allows to upgrade from Level 1 functions up to the more advanced Level 3 or 4 functions. (Credit: Elektrobit)

As the environment model is modular and upgradeable, its implementations can be adapted from Level 1 functions up to the more advanced Level 3 or 4 functions (Fig. 4). However, regardless of the supported automation level, it can be used mostly off-the-shelf — this model requires only few adaptions to specific hardware such as sensors as well as other elements of the system.

The positioning module works closely together with the environment model. It provides highly accurate information about the vehicle’s position based on odometry, gyroscope, accelerometer, and GPS signals. It outputs the local position of the car and trajectory information and thus is the base of all geo-referenced functions such as lane following, path planning, and automated parking. This module also delivers the required positioning information for other applications such as vehicle to vehicle communication, eCall, or navigation.

An extrapolation component is another important part of the positioning module. It estimates a position in the near future based on the current vehicle movement. This position can be used to compensate for delays in the fusion itself as well as in the application. These basic functions can additionally be complemented by an electronic horizon which provides highly accurate and up-to-date information about the road ahead for predictive driver assistance functions. This allows the integration of features like curve-speed warnings, adaptive curve lights, traffic-sign display, range determination, lane keeping, or fuel-efficient driving and provides useful information for SAE Levels 3 and 4 functions.

The described software modules of the framework will typically run on a vehicle network architecture that is based on multi-processing controllers. Elektrobit’s EB corbos software suite combines essential elements for running multi-processing controllers enabling safe high performant computing. Further, these elements provide a runtime environment, software capabilities, and embedded security. It consists of a hypervisor that permits running multiple operating systems such as the AUTOSAR Runtime for Adaptive Applications (AUTOSAR Adaptive) and a high-performance Linux based operating system.

Evolutionary levels and standardization

In order to facilitate an easy integration into existing or newly designed system architectures, the EB robinos software framework for automated driving includes a software toolchain. It permits the easy configuration and adaption of its software blocks in various development and testing stages including research, pre-development or concept work, the development process, and mass production.

The centralized functional architecture of the framework supports service oriented and security-supporting development, as well as training of the development staff. With its modular and functional design focusing on the increasing automation levels starting at Level 1 and currently extending to Level 4, the framework also distinctly supports the evolution of functions and designs in the same or multiple generations of vehicle models over time.

Another important aspect of providing easy integration mechanisms and interfaces is the formation of industry-wide standards of interfaces between the functional models of a software framework as well as with external components.

Currently, several standardization initiatives in the automotive industry are targeted at establishing and defining these interfaces and specifications. Elektrobit intensively supports these efforts and participates in the according standardization bodies and organizations.

The further spread of software frameworks will help developers and OEMs to reduce time to market, enable scaling factors for non-differentiating components of automated driving, greatly reduce complexity, effort, and costs, and allows higher competitiveness and thus better functions for the consumer while enabling Level 5 driving capability.

Sebastian Klass is Product Manager EB robinos, Elektrobit Automotive GmbH.