Today, developing automated driving (AD) systems means providing truly unique features to customers. For OEMs, this means offering features that no one else can, or at least being the first to show a function in a stock vehicle. These features are often developed in a research and development (R&D) or pre-series department using rapid prototyping methods, shown to management, and then forwarded to the engineering department to be included in the product. This may sound straightforward, but often it turns out to be a very difficult, time-consuming process. Management may find it hard to believe that a feature they’ve already experienced in a demonstration vehicle is not available to a customer on short notice. This results in tough discussions about realistic expectations for mass production.

Is there a way to facilitate the process of adding new AD functionality to a vehicle? This article will outline a process to help your development move from R&D to mass production. This will be followed by requirements for execution environments for different development states and will conclude with an example of a development-ready software kit for automated driving.

Splitting the Development Process

In addition to having different quality and functionality goals, one big difference between R&D/pre-series and mass production projects lies in the use of different application environments and development philosophies. Would it help to use the same philosophy in all phases? I wouldn’t recommend it, as this would result in using an unproven environment in mass production projects or slowing innovative projects down due to the limitations coming from mass production environments. Either result is not very economical.

A better solution to this problem is to introduce a step in between the development philosophies (Figure 1). In the first step, the projects follow the classical R&D approach of using rapid prototyping methods and making it work by any means necessary. These projects use PC-based systems running high-end operating systems like Microsoft Windows or Linux. When they accomplish their goals, the projects proceed to the next development phase—rapid embedding. In this step, the software moves onto a more embedded-like system. These systems are built on high-power standard development boards available from many leading vendors. They are characterized by providing a high amount of CPU power compared to a traditional embedded system. Usually, they run embedded Linux or other POSIX-based operating systems. In this step, the developer focuses on reducing dependencies to operating systems or to libraries that are not available or not applicable. Moreover, a rapid embedding project aims to raise the system functionality to a higher level, so that the gap to an end-customer system gets smaller and smaller.

For the last development phase, called automotive-grade software, the input is a software component that runs directly on an embedded system. This step uses specialized hardware designed for the concrete use case in an individual car project. The focus now lies on optimization, cost reduction, and the adaptation to mass production-related capabilities like networking, diagnostics, or adapting the functionality to the exact function requirements.

Attributes of a runtime environment

A module from any development phase should be able to be easily moved to any other development phase, but in different runtime environments, certain requirements need to be fulfilled. Every runtime environment supports its own special features and has functionalities that it does best compared to other runtime environments. However, to really run a software component, it comes down to very few basic features. These features can be roughly split into three different categories: system assembly, communication, and runtime triggering.

System Assembly

An AD system consists of several different components serving different tasks, from environmental perception, to decision making, to control systems. These modules need to be instantiated, their interfaces need to be defined, the communication channels need to be described, and the parameters of each component have to be set.

Communication

Communication between the AD software components and sensors and actuators is a key feature for a runtime environment. A communication channel between two software components can have various attributes. However, comparing communication principles, it comes down to sending and receiving data streams (asynchronous communication) and call interfaces (synchronous communication). These two communication paradigms need to be available on an intra- as well as on an inter-ECU level to aid system deployment in later development phases.

Runtime Triggering

After defining a system and providing different types of communication channels, the system needs to be booted up and the software components need to be triggered to execute their tasks. There are two ways a software component can be triggered: cyclic triggering and event-based triggering. Cyclic triggering starts a task after a certain time period has passed. Depending on the cycle time and the runtime of a task, this can be difficult and needs to be supported by a hard real-time operating system. Event-based triggering is used every time something happens in the AD system. This begins during the start-up process, occurs also when communication takes place (e.g. when receiving data), and is finalized during the shutdown of the system.

Defining runtime environments for EB robinos

Now, we’ll look at the EB robinos Development Kit as an example of an AD development framework. It supports AD systems up to SAE Level 5 (fully autonomous) and provides various state-of-the-art software components to host any AD application. This kit supports all three development phases starting from rapid prototyping, up to full mass production development.

Created as a flexible tool, it supports rapid prototyping environments in different operating systems. A developer can decide to use the EB Assist ADTF implementation on Microsoft Windows to get a familiar system providing tools for system assembly, different kinds of communication, and runtime triggering. Using EB robinos in a Linux environment is managed by a light-weight embedded Linux software framework. It is capable of assembling and configuring EB robinos software components and triggering the needed tasks. This embedded Linux framework is also one solution for the rapid embedding stage. However, EB robinos will also provide support for the Adaptive AUTOAR standard. The Adaptive AUTOSAR integration is also the runtime environment of choice for mass production projects.

Conclusion

Running an AD software applications on different hardware systems requires the software components to be developed in a hardware-agnostic way. The most important abstraction layers are the operating system and the application runtime environment. The attributes of a runtime environment can be rendered down to a few important requirements that need to be fulfilled by the runtime system.

With the EB robinos Development Kit, Elektrobit provides a hardware agnostic software framework for automated driving systems. It covers all necessary software algorithms along the sense-plan-act processing chain. Depending on the targeted development stage, EB robinos is able to run the same software components in different runtime environments from rapid prototyping systems, over embedded Linux up to Adaptive AUTOSAR.