Architectural Concepts for Autonomous Driving applications

Advanced Driver Assistance Systems

In the past years, the automobile industry has been dramatically improving the features implemented in vehicles aimed at assisting the driver in many different traffic situations. Commonly named Advanced Driver Assistance System (ADAS), those features range from parking to highway Lane Keeping Assistance (LKA) even involving more complex functions such Advanced Cruise Control (ACC).Such functions only require a limited number of sensors. The architecture depicted in Fig.1 represents a possible design to implement features like the LKA and the ACC.

Figure 1: A typical Software architecture for ADAS functions

Assuming the LKA and ACC features have been implemented according to the guidelines given in the ISO-26262 standard, such an architecture can be brought to keep the ego vehicle in a safe state. Nevertheless, the expectations for autonomous driving (AD) are much higher and bring a significantly higher level of complexity into the system.

The explosion in complexity

To apprehend increasingly complex AD tasks, the application needs to create a more elaborate and accurate representation of the traffic situation through the involvement of an increasing number of sensors, such as Radars, Cameras, GPS positioning and high-density maps (refer to Fig. 2).An architecture as the one depicted in Fig. 1 inherently suffers from several major drawbacks.

Figure 2: While Advanced Driver Assistance Systems only require a subset of those sensors, Level 4 and L5 make intensive usage of combining sensors to capture the traffic situation.

Firstly, this architecture shows weak configurability capabilities. Secondly, it also requires the exchange of an amount of data between components that is increasing with the number of sensors, increasingthe communication bandwidth and hence can decrease the scalability of the solution. With the increasing complexity, more functions will have to be added to Decision and Planning layers, decreasing the modularity. It is also worth mentioning that such aspects speak against the recommendations expressed in the ISO-26262 standard.

Figure 3: A configurable, modular and scalable architecture for implementing Autonomous Driving Application

A more suitable architecture is depicted in Fig. 3. This architecture also allows the implementation of the example of the LKA/ACC mentioned above, depicted in the dark blue boxes. Also, the integration of new AD functions can be made in a scalable and easier way. Functions like LCA or Minimum Risk Maneuver (MRM) can be added without impacting the LCA/ACC module

Figure 4: Overtaking on the highway

It is also worth noting that from the functional safety point of view, this architecture allows for coherent partitioning of the different modules so that a high cohesion is reached while keeping the interfaces between components as narrow as possible.

Safe overtaking on the highway

The use case of overtaking the lead vehicle on a three lanes highway is one of the most common situations (refer to Fig. 4). For the AD application, the maneuver consists in shifting from the LKA/ACC modus to the Lane Change Assist (LCA). For functional safety reasons, the minimal risk maneuver component is also activated so that a safe state can be maintained in all situations including all errors that can occur at every instant. It is worth mentioning that for such a task, the AD application is only exercising driving skills.

Highway exit handling

Getting higher in the levels of autonomous requires the application to handle more complex situations such as an approaching highway exit, as depicted on Fig.5. The ego vehicle, in red, is approaching the exit it must take. Now, the hazard is related to a more abstract notion: hazardous driving. It is expressed at a higher level of abstraction and cannot be mixed with the traffic situation hazards. To cope with this situation, the AD application needs include situation analysis skills.

Figure 5: Highway exit handling.

More specifically, the architecture in Fig. 3 does not exhibit any mechanisms that allow to address the question whether the overtaking of the leading vehicle(s) can be performed in a safe manner.Such an architecture is depicted in Fig. 6.

Depicted in blue, the architecture from fig.3 can be recognized. Fig. 6 also depicts an additional layer, in yellow. As inputs, this layer uses information such as the position given by the GPS and High Definition (HD) maps of the surroundings of the vehicle.

The underlying concept to such an approach can be summarized with the notion of safe statesand safe segment. A safe segment consists of a continuous sequence of safe states between crucial action points such as highway exists. On those segments, all driving decisions can be left to the lower layer where the AD application uses its driving skills. On the other hand, in the neighborhood of the crucial points, some of the driving skills related actions need to be mitigated by situation analysis skills.

Figure 6: A hierarchical approach of the Autonomous driving application

Full autonomous driving

The concept presented in the previous section can be extended. Indeed, the goal of the driver and the passengers of the vehicle is to go from point A to point B. The path that the vehicle will follow is a collection of segments separated by changes in direction at some special points. This kind of trip also usually has some time constraint, even if very soft. The selection of the safe path needs to be made depending on it. Hazardous situations can arise with a wrong selection.

Therefore, considering a safe trip being a collection of safe segments seems to be the right extension to the concept exposed in the previous section. Most important is the stability of the definition of the safe trip. In many cases, the traffic situation evolves within the duration of the trip in a manner that could not have been anticipated.It is worth noticing that the handling of the notion of a safe trip is again at another conceptual level but also level in the nature of the hazards it handles.

It seems natural to create another layer of control to the architecture described in the previous section. The goal of this layer is to implement the planning skills of the AD application and hence to transform the planned trip into a sequence of safe segments and secondly to dynamically generate a set of alternate routes and associated segments when necessary.

Concluding remarks

With simple ADAS functionalities such as LKA and ACC, the underlying architecture can remain in a very simple flat layout. Addressing more complex situations such as taking a highway exit requires to elevate architectural concepts.

Reaching the ultimate level of autonomous driving requires the AD application to be capable of selecting a safe trip,consisting of a collection of safe segments, dynamically computed. With a hierarchical approach, the vehicle can move on a safe trip without any intervention of the driver, indeed at the level 5 of autonomous driving.