Through SDV hierarchical decoupling and service-oriented, achieve LEGO style development and rapid vehicle model adaptation. Meanwhile, SOA and layered design can maximize software and hardware decoupling and reduce development complexity.

　　On May 9-10, 2023, at the 2023 Jietu Automotive Electronic Architecture and Intelligent Driving Forum hosted by Jietu Motors and hosted by Geshi Motors, He Lang, Director of Architecture Design for Huawei Intelligent Vehicle Control Solutions, stated that through SDV hierarchical decoupling and service-oriented development, LEGO style development and fast vehicle adaptation can be achieved. Meanwhile, SOA and layered design can maximize software and hardware decoupling and reduce development complexity.

　　At the same time, he also summarized three experiences that Huawei has summarized in practice: introducing true event mechanisms in human-computer interaction applications to replace periodic mechanisms; Aggregating multiple upper layer packets in the SoAd layer, and adding ETH packets for sending after the aggregation meets the triggering conditions; Asynchronous calls reduce CPU usage and latency when multitasking.

　　He Lang | Huawei Intelligent Vehicle Control Solution Architecture Design Director

　　The following is a summary of the speech content:

　　Thinking and Design of SOA Architecture

　　In recent years, during the implementation of SOA service-oriented technology, the architecture has been continuously adjusted with the development of the business. In this process, some thoughts and solutions have been shared with everyone. Firstly, returning to the topic of software definition, in the face of increasingly complex scenarios, the increase in intelligent components will bring related network security and privacy requirements. And the landing process in the software development process is also increasingly complex, so it needs to be adjusted and changed.

　　We have put into practice and implemented engineering solutions on many car models, including conducting many beneficial explorations with our industry's ecological partners. Overall, the software needs to be divided into three layers to adapt to the cyclical pressures and requirements in the automotive iteration process, the increase in ecological partners, and the continuous enrichment of ecological operations, and to solve various complex problems in the application layer.

　　In the physical layer, with the introduction of intelligent components, the adjustment of the communication and electronic information architecture has undergone tremendous changes. However, in order to keep the overall software architecture stable, the service layer has been introduced and is currently in the process of construction. For the design of software architecture, there are the following countermeasures. In terms of hierarchical design, three layers are designed, so that the traditional cross ECU development in the middle can be decoupled to the middle platform through the software architecture. This layer contains device abstraction. In short, solidifying the software through experience into a standard library for direct invocation allows developers to have more energy for consumer oriented differentiated innovation.

　　During the decoupling process, it was found that the physical layer to the application layer varied with the electronic signal of the vehicle, and the differentiation of corresponding electronic devices would lead to the need for adaptation work. In the software architecture, two layers of equipment abstraction and atomic services are introduced to fully decouple software and hardware. The mission of equipment abstraction is to shield the interface differences between different hardware suppliers of the same type of hardware or between different models of suppliers. Atomic services abstract the basic atomic capabilities into standardized interfaces. These capabilities will also be fixed with the change of vehicle models, and form assets that can be quickly reused through experience accumulation.

　　In the practical process, the introduction of new sensors will also put forward higher requirements for intelligence, such as the introduction of sensor cameras and radar signals. How to provide more capabilities upward is also a business innovation area that consumers are interested in. Through some practice, we can atomically encapsulate the external capabilities of new sensors, and also utilize the already encapsulated capabilities to form new businesses.

　　In the architecture of software defining automotive SOA, I think a more valuable design principle is to shield the ability of different hardware through software differences, solve the coupling between different atomic services, form a way to avoid two-way dependency, and reduce the complexity of interaction between signals. And forward compatibility with service interfaces to avoid new architectural changes caused by changes in upper level software and lower level hardware.

　　Performance Challenges and Practices in Implementing SOA Development

　　The main challenge encountered during the implementation of SOA is how to achieve software Onetrack. Due to the increasing scale and complexity of software, the division of labor is also becoming increasingly refined. In this situation, how to achieve cross vehicle and platform integration of a large amount of software engineering, and even how to introduce a new supplier to quickly integrate into the current architecture, has become a major issue.

　　For example, in the actual implementation process, the deployment and invocation relationships between the service layer, abstract layer, and corresponding apps are very complex, which inevitably leads to not only compatibility with many functions, but also performance testing. On the premise of ensuring the stability and flexible deployment of the service layer, it is conducive to the rapid migration and synchronization of new functions.

　　In this process, it will be found that the flexibility of services will inevitably bring about communication pressure. Specifically, first, through the original information architecture to the service-oriented architecture, a large number of messages will be introduced in order to maintain flexibility. The independence of the interfaces of each server will bring about a huge increase in communication pressure; Secondly, when traditional MCU processes these messages, due to the need to deal with uncertain messages, the penalty mechanism for messages was not constrained during the first SOA, so a large number of messages were introduced in a short period of time, which also posed a significant challenge to the CPU load.

　　In response to these two manifestations, we have made attempts on many car models and summarized six experiences in service deployment, such as those with high functional safety (ASIL-B or above), deployed on MCUs, multiple CPs, and if there is uneven resource distribution, priority should be given to deploying on the nodes with the most abundant CP resources. At the same time, it is also necessary to take into account the aggregation of developer capabilities and the real-time requirements for consumer experience, and deploy human-computer interaction applications or related services to the corresponding VIU or cockpit controller nearby. For example, taking the feature of manually opening the tailgate as an example, the application for opening the door is deployed on the VIU closest to the tailgate. At the same time, in order to respond faster, the corresponding application is deployed on the cockpit, and is deployed together with the physical button atomic service nearby.

　　Image source: Speaker materials

　　After meeting the performance requirements for flexible deployment, we found that the same function would be dispersed across different regional controllers and central controller systems, and multiple interactions and corresponding communication costs would generate a large number of packet impacts. In such a situation, in order to maintain the flexibility of vehicle domain communication, the message granularity will decrease, resulting in a large number of messages and bringing pressure to communication transmission.

　　We draw on the communication experience in ICT, such as the method of solving information storms or SMS congestion in 2G, introducing true event mechanism to replace the default periodic mechanism, and configuring periodic messages through the operating system and tool chain to allow them to aggregate. The cycle is extended by default when there are no changes, but when there are changes, the report is immediately triggered. By using the periodic event mechanism, over 20000 messages are generated per second, while by using the update on change mechanism, fewer than 1000 messages are generated per second, reducing the number of processed messages by more than 20 times, greatly reducing CPU processing overhead.

　　The biggest change in the way Ethernet replaces CAN communication is the introduction of a large amount of message load. By introducing NPDU, messages are divided into different types and prioritized, taking into account real-time and communication efficiency requirements. If the message is not very urgent, it can be accumulated and reported for a certain time, which can significantly reduce the load.

　　Asynchronous calls break traditional communication mechanisms

　　The traditional communication method is very mature for the Autosar standard protocol, the message mechanism is relatively stable, and its load is processed uniformly through the underlying layer. In the form of SOA, there will be a large number of blocking issues, specifically due to a service approach similar to RPC, as its principle is to wait for feedback results before processing subsequent actions. After the service-oriented approach, it will be found that it is a scenario where multiple tasks are sent simultaneously at high frequencies. If each processed task needs to wait for subsequent tasks before proceeding further, it will inevitably lead to a lengthy queue.

　　In response to this situation, the asynchronous call mechanism is used to convert a closed-loop message into two closed-loop messages. After sending the task to the called party for the first time, there is no need to wait for the callback result to process other tasks in parallel, which can turn many serial tasks into parallel. For example, position lights may be deployed in controllers in different areas of the car, which may block waiting due to other concurrent tasks. However, through asynchronous invocation, the application itself can complete the process within 60 milliseconds, which can also solve the problems caused by service-oriented services.

　　Servitization itself faces many challenges due to Ethernet's focus on in vehicle and functional safety applications. To coordinate the application of car lights or doors in various places, it is necessary to consider some countermeasures in the future to address issues such as delay and synchronization. Overall, by standardizing the architecture and aligning various languages in the industry chain, different atomic service combinations can reflect vehicle model differences, and configuration adaptation can enable upper level applications to reuse across vehicle models. At the same time, through device abstraction, hardware differentiation can be shielded, and software and hardware decoupling can make software more flexible to transplant in different vehicle models, even without perception.

　　We need to find ways to achieve flexible deployment of the entire vehicle and standardization of corresponding interfaces, so that the new OTA functions can be launched and the changes and OTA scope can be controlled within a certain controller. At the same time, for other applications, we can try to be as unaware as possible. In terms of performance, Ethernet communication breaks the traditional CAN cycle processing approach, optimizes its processing performance, improves reliability, and accelerates transformation. At present, the biggest issues are communication congestion, call issues, and queue issues. Through asynchronous calls, flexibility in message triggering, and corresponding aggregation, performance can be gradually improved.

　　(The above content is from the keynote speech titled "Software Defined Automotive Performance Challenges" delivered by He Lang, Director of Huawei's Intelligent Vehicle Control Solution Architecture Design, at the 2023 Jietu Automotive Electronic Architecture and Intelligent Driving Forum hosted by Geshi Automotive on May 9-10, 2023.)