Level 4 product architecture for software and toolchain related to L3+ intelligent driving support.

Author: Xiao Meng

Welcome to follow the series of articles “Software Architecture and Implementation for Intelligent Driving Domain Controllers”. This article will describe the product architecture associated with the overall software architecture and define the four levels of product architecture. It will also discuss the necessity of product division and the roadmap for multi-level product collaboration.

The Importance of Product Division and Product Architecture

The architecture of autonomous driving software involves a variety of technologies from different fields, such as algorithm design, algorithm acceleration, communication, image processing, and so on. Each of these fields can be a company’s dedicated product.

We need a way to sort out the complex and diverse related products involved in the product architecture. Clarify the structural hierarchy and the interdependence between different products. In this way, when we discuss a related product, we can clearly understand its role and position in the overall product architecture.

Different products involve vastly different professional fields, and no one can master all of them. Distinguishing different products can focus individual products on specific areas. They can be defined by suitable product managers and developed and tested by R&D teams with appropriate skills.

There are interdependencies between different products. For example, Product A will be delivered to customers, but its development requires support from Products B and C. Product B will also be delivered to customers, but not Product C.

Clarifying these dependencies can help us know which products need to be developed first, which ones need to be developed later, and which ones can be developed in parallel by different teams and integrated later. The division of products at the product level can also clarify which products can be purchased and which must be self-developed.

Different products have different development cycles. If Product A depends on Product B, but the development cycle of Product B is long, we need to find a way to provide a simulation solution to temporarily eliminate this dependence and ensure that Product A is completed on time. All of these need to be considered as a whole, provided that there is a clear boundary between different products.

There are many ways to logically divide products, such as:

  1. Divide according to specific professional domain clustering relationships
  2. Divide according to the hierarchy from hardware to application layer
  3. Divide according to vertical functional aspects
  4. Divide according to whether they are runtime components or development support toolchains

Product Architecture and Product Line

2.1 Four-Level Product Architecture

Four-Level Product Architecture

The figure above shows the hierarchical relationship of the four-level product architecture, namely PA1~PA4. This division is actually based on the development of the intelligent driving software framework and basic components (L.FW).The “Intelligent Driving Software Framework and Basic Components (L.FW)” itself is the boundary of the third level (PA3) product. PA2 above PA3 includes all software running in the intelligent driving domain controller. PA4 below PA3 contains various autonomous driving function software packages, which are developed based on the component interface provided by L.FW.

PA1 also includes all the toolchains and support systems used for PA2 development outside of PA2.

The product architecture of PA1-PA4 is a containment relationship.

Each PA level can also include multiple product lines, and a product line can include multiple related products. Product lines are divided according to the relevance of the products.

For example, in addition to PA2, the products in PA1 can be divided into several major product lines:

  • Software testing

  • Data acquisition and management platform

  • Truth system

  • Algorithm development support

  • Simulation testing

2.2 Product Structure of PA2 Level

Product Architecture of PA2 (Domain Controller)

The products at the PA2 level (D.P + L.OS) mainly select embedded computer operating systems, commonly using Linux, QNX, or VxWorks.

Generally speaking, Linux is the main operating system in the intelligent driving field and has an open-source implementation. However, it is best to choose a commercial version with professional team support. On the one hand, this can provide accelerated porting and special optimization of Linux on the target board, including system trimming, boot optimization, etc. On the other hand, it can provide long-term professional technical support and keep up with the latest patch updates.

The products at the PA2 level (D.R + L.OS) can be a certain RTOS system. The chip developers usually provide microprocessor abstraction layers (MCal) at this position. RTOS can implement its own chip driver based on Mcal or can also do it independently. CP AutoSar can also be used directly, but CP AutoSar spans both the real-time domain L.OS and the basic software layer L.BSW.

The basic products at the PA2 level (D.P + L.BSW) area are vehicle controller basic software that supports performance domains, and the typical product is AP AutoSar. The product that is most similar to it is ROS2.

However, ROS2 only completes the communication part of AP AutoSar and does not have modules related to the vehicle controller. In addition, at the L.BSW layer, we also need a data synchronization mechanism between the real-time domain and the performance domain. If the third-party product selected at the L.BSW layer does not provide it, a custom module needs to be developed.

2.3 PA3, PA4, and Product StructureThe PA3 layer is essentially equivalent to the L.FW layer. Its internal products mainly consist of their respective operating frameworks.

The ENV environment modeling framework and the EPX-SA model execution framework are the two main ones.

In addition, there are platform-specific frameworks such as algorithm acceleration frameworks, video processing frameworks, 2D/3D rendering frameworks, and HMI engines, which also need to be developed, but require platform-specific SDK capabilities.

The L.FW layer also provides some basic EPX-SA components and some basic perceptual algorithms to make the entire framework run.

The PA4 product is designed to implement true intelligent driving functions based on PA3. It includes various components of perception algorithms and EPX-SA, and these algorithms and components are loaded into appropriate positions and executed in the L.FW layer. The collection of different algorithms and components forms a certain product.

About the Author

Xiao Meng, R&D VP of Beijing Wido Technology Co., Ltd. (Read the original article and follow the author on Zhihu)

About Wido Technology

Beijing Wido Technology Co., Ltd. was founded in 2014 and is an automotive intelligence technology enterprise. It focuses on creating high-precision perception algorithms for advanced level autonomous driving, high real-time and high reliability system software platforms, and heterogeneous computing engines. Wido Technology is committed to empowering OEMs to provide consumers with safer and more convenient driving experiences.

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.