Distributed design of multi-core SoC domain controller based on AUTOSAR AP

AUTOSAR CP solves the specification problems of multiple ECU development from the perspective of overall development of automotive electronics. However, with the rapid changes in the industry, the volume of cross-domain and inter-domain data transmission has increased dramatically, the complexity of software has increased, and new specifications such as information security have emerged. Introduced into the automotive field...the above problems have exceeded the scope of AUTOSAR CP, and AUTOSAR AP came into being.

On March 14-16, 2023, at the 2023 Fourth Software-Defined Automotive Forum and AUTOSAR China Day, Freetech senior engineer You Xinxin pointed out: “AUTOSAR AP is the AUTOSAR organization’s response to the lack of suitable middleware for high-performance computing platforms. To solve the problem, a new architecture is introduced. On the one hand, it adopts the object-oriented SOA architecture and aims to provide a flexible software development platform for upper-layer applications; on the other hand, it fully draws on the experience and advantages of the former automotive industry to make automotive software It can continuously iterate while improving quality and achieve mass production quickly.”

You Xinxin | Senior Engineer, Freetech

The following is a summary of the speech content:

This speech is mainly divided into three parts: first, it will introduce the origin and history of AUTOSAR AP; the second part is the advantages and challenges of deploying AUTOSAR AP on domain controllers; the third part is the distributed expansion of AUTOSAR AP, in view of the above mentioned Challenges, what efforts have we made to expand AUTOSAR AP in a distributed manner.

The origin and history of AUTOSAR AP

The emergence of AUTOSAR is inseparable from the evolution of automotive electronic and electrical architecture. As we all know, the automotive electronic and electrical architecture is evolving from distributed to centralized. The overall trend in the future is one or more unified central computing platforms, but it is still evolving. The current trend is to divide the vehicle into several major domains, and each domain has its own domain controller to reduce the number of ECUs. The emergence of domain controllers has put forward higher requirements for software and posed the following challenges to the software carrier - software middleware platform:

First, Ethernet has gradually become the backbone network of automobiles. As the data transmission throughput between domain controllers becomes larger and larger, and the latency requirements become lower and lower, the emergence of Ethernet makes the AUTOSAR CP traditional protocol stack unable to support project development. Although the CP protocol stack also supports Ethernet, it still uses a traditional signal-oriented communication architecture and cannot take full advantage of Ethernet.

Second, as the computing power of SOC increases, we will integrate more software. Although the number of ECUs has decreased, software complexity has increased. We cannot develop a set of software after defining the requirements and use it until it is scrapped as we did in the past - this is unthinkable now. Today's software requirements include agile development, continuous iteration and upgrades, as well as good portability and reusability. This is why the service-oriented SOA architecture is so popular.

Third, no matter how complex the software and hardware platform is, it must meet information security and functional safety requirements during mass production, and be compatible with existing industry specifications (such as time synchronization and other functions). Some excellent software middleware can flexibly support autonomous driving software development, but they do not consider information security and functional safety requirements, and are not specifically made for the automotive industry, so they are not suitable for mass production.

Based on the current situation, AUTOSAR launched a new AUTOSAR platform in 2017 - commonly known as AUTOSAR AP. The emergence of AUTOSAR AP is to fill the gap in the lack of easy-to-use middleware on high-performance computing platforms. It adopts an object-oriented SOA architecture and aims to provide a flexible software development platform for upper-layer applications. At the same time, it uses the experience and advantages of the automotive industry to make all cars The software can continue to iterate and be put into mass production faster and better.

It has been 6 years since the first version of the AUTOSAR standard was proposed in 2017. Next, let’s talk about the benefits and difficulties of deploying AUTOSAR AP on domain controllers in real projects.

Advantages and challenges of deploying AUTOSAR AP on domain controllers

Freetech has rich experience in domain controller development. Based on the Freetech ODIN 1.0 platform, there are two domain controllers - ADC15 and ADC20, which were mass-produced last year. These are small computing power domain control platforms that support Freetech's self-developed 5V5R/6V5R sensors run self-developed non-standard software middleware and can realize high-speed + parking integrated functions.

This year, Freetech will launch the more efficient ADC25, and will launch the ADC30 in the future based on the Freetech ODIN 2.0 platform. The ADC30 will develop a self-developed 12V5R sensor, paired with 1 to 3 Lidars, with the goal of supporting autonomous driving above L3. function to support high-level autonomous driving at high speeds + urban areas + parking. We chose AUTOSAR AP as the basis of domain control middleware, so we have a very clear understanding of the advantages and challenges of deploying AUTOSAR AP on domain controllers. He also has a very deep understanding of the capabilities boundaries of AUTOSAR AP.

The following is a simplified diagram I made based on a real project software platform deployment on a domain controller. Due to insufficient computing power of a single SOC and security redundancy, domain controller ECUs usually have multiple built-in SOCs for computing and performance domains, and multiple MCUs for security redundancy. In terms of software platform selection, AUTOSAR CP is basically chosen for the MCU part, which has become the de facto standard. Within the heterogeneous SOC, there are traditional computing cores (commonly known as A cores) and small cores. The small cores usually run software on non-AUTOSAR platforms.

Image source: Guest speech materials

There are several main advantages to choosing AUTOSAR AP as the middleware on the computing core. First of all, it supports C++, which allows us to use new algorithms faster and improve application development capabilities and speed. Secondly, it adopts service-oriented SOA architecture, which can improve software portability. Applications only care about the services used and provided, and do not care about the location of the service provider. This can greatly decouple hardware bindings and improve software reusability. Furthermore, AUTOSAR AP utilizes existing standards (such as UDS diagnostics, SOME/IP, etc.), so engineers do not need to relearn complex theories. In addition, AUTOSAR AP has complete methodology, independent functional components and configuration tool support for information security and functional safety. Finally, AUTOSAR AP supports agile software development and continuous iteration, and can update the software platform through OTA capabilities.

The above are the advantages of AUTOSAR AP deployed on the domain control platform, but in real projects, we also found some shortcomings and challenges.

The first is the issue of distributed communication management. The AUTOSAR AP communication management module is called the CM module. AUTOSAR has standardized two communication bindings (transmission layer): SOME/IP and DDS, both based on Ethernet transmission. For example, two SOCs are interconnected through high-speed Ethernet within a domain controller. At this time, the AUTOSAR AP can perfectly display its features and allow the applications between the two SOCs to run normally. But the problem is that not all ECU platforms support Ethernet communication. For example, some small cores in TI's TDA4 need to communicate with the computing core, but these parts do not support Ethernet. At this time, most algorithms run on the computing core. The small core is mainly responsible for sensor data collection (such as cameras and radars, etc.). If applications on the computing core need to obtain these sensor data, they usually need to use two methods.

One method is to write a forwarding APP to obtain sensor data through inter-core communication. The information will be converted into the AP system through the CM module of the AP. Although this method can complete the requirements, it has performance problems. Because each conversion will add a data copy, which has a serious impact on data performance. If transmission delay-sensitive data (such as camera data) or communication data is large, this approach may not meet project needs.

The second method is that the application in the computing domain not only uses AP, but also adds additional middleware specifically for inter-core communication. The inter-core communication middleware is used when the computing core communicates with the small core, and the AP is used when communicating with other SOCs that support Ethernet. This approach works without performance penalty, but affects software portability. Theoretically, software that only uses AP standard interfaces has strong portability and can be reused in multiple projects. However, if non-standard middleware is introduced, the software will be bound to the hardware platform, and the original software will no longer be reusable or reusable. Comply with the service-oriented characteristics of SOA architecture.

I don't think the above methods are the best way to solve the problem. If AUTOSAR AP wants to be deployed on complex multi-core heterogeneous SOC, it must support non-Ethernet communication.