At the end of 2022, the AUTOSAR alliance released the latest version of standard R22-11.

　　On March 14-16, 2023, at the 4th Software Definition Automotive Forum and AUTOSAR China Day, AUTOSAR China Technical Officer Qian Jiamin introduced the three new parts of R22-11. Including Timing technology; Technical specifications for remote diagnosis of V2X and SOVD; Relevant specifications for communication standards and protocols in the vehicle. Qian Jiamin stated that this update has allocated and completed a total of 2029 standard development tasks, including 334618 lines of AP platform demo code, aiming to define a unified E/E system architecture for future intelligent driving.

　　Qian Jiamin | AUTOSAR China Technical Officer

　　The following is a summary of the speech content:

　　The following figure covers the new technologies of R22-11, which can be summarized into three main parts: the first part is Timing timing technology, which is a new fundamental direction highlighted by AUTOSAR; The second part is about the technical specifications for V2X and remote diagnosis; The third part focuses on communication standards and protocol specifications related to in car communication.

　　Source: AUTOSAR China

　　Timing timing technology

　　For people, time is a very important factor, and it is also true for cars. Especially in the direction of electronic and electrical development oriented towards domain fusion, a single function originally distributed in various ECUs will be integrated into a regional controller. How to ensure the real-time, deterministic, and correct execution of so many functions, timing technology is very important.

　　The tool group responsible for the development of temporal technical standards within AUTOSAR is called the Resource Working Group. The WG-RES Working Group focuses resources on both time and computational resources. Timing technology, like functional security and information security, runs through the entire lifecycle of ECU software development. It is indispensable from the initial system architecture design to the software implementation in the middle, and finally to the verification and testing of the system. In the R22-11 version, AUTOSAR focuses on supplementing the normative information about timing in red.

　　Source: AUTOSAR China

　　Source: AUTOSAR China

　　The information specifications related to time series are mainly divided into three parts:

　　The first part, we call it TAD. This involves the two ends of the development lifecycle - system design and system verification. With the help of existing timing tools on the market today, it supports the simulation of system timing in the early stage and the measurement and analysis of timing in the later stage.

　　The second part, the TIMEX specification that already exists in AUTOSAR 4.0, mainly focuses on the specification of time series modeling in AUTOSAR. We know that modeling not only defines patterns, but also temporal related parameters, which will be described in the specification.

　　The third part is mainly about the specifications for timing recording and reading. We need to stamp the timing and record it by calling APIs. On CP, we mainly use the DLT module, and on AP, we mainly use Log&Trace. Additionally, how the recorded timing data is transmitted externally, and how timing tools are read and displayed are all defined in the ARTI specification.

　　Source: AUTOSAR China

　　For example, in terms of timing technology, the process of electric vehicles from stepping down the accelerator pedal to the final torque output by the motor requires a response time of less than 150 milliseconds in terms of system functional requirements. How to design the timing of system requirements? I am very familiar with system architecture design. The first step is to define the architecture and develop a virtual functional bus. We will decompose the process of the 150 millisecond system function into three software functions: one is the sensing input, which specifically collects accelerator pedal signals; The second is functional processing and calculation; The third is the output of the actuator. Each function can be decomposed into multiple Runnables.

　　But on complex multi-core systems, the split Runnable will run on different cores and may also run on different SOC. How do I ensure that each Runnable is executed in the order I expected, and how do I ensure that the entire system functionality is completed within the required time? We must establish the entire sequence relationship and event chain according to the specifications, and define the time resources for each Runnable after completion. After defining, the first step of TAD is to use tools to simulate the entire system function; After the simulation is passed, the software is implemented. During the implementation process, each part needs to call the API in AUTOSAR to record the timestamp. There are fixed modules in AP and CP to record the timestamp, and ARTI description files can be input into the tool to measure the timing of the entire system. Finally, the running process in the form of Gantt chart is displayed in the tool, so that you can easily analyze whether the whole system timing runs correctly, and whether it is the same as the original design. This is the whole timing design process. When designing timing technology from the source, it is necessary to consider using tools for simulation and measurement to better address the challenges of complex system operation.

　　V2X and SOVD standards

　　Regarding V2X, AUTOSAR standardization faces two main challenges.

　　One is that different countries and regions have different regulations and related agreements for V2X, which poses great challenges due to differences in protocols.

　　The second is the difference in ECU functions between different antennas. At present, antenna ECUs on the market can be divided into two types. The first type is remote antenna ECUs, which are only responsible for sending and receiving message data between cars and the cloud. They can use various protocols, such as MQTP, but are not responsible for filtering messages or extracting signals. The second type is the active antenna ECU, which has relatively powerful functions. In addition to data transmission and reception with the cloud, it also supports data filtering, signal extraction in messages, and packaging. So the allocation of ECU functions for different antennas is also an important challenge for AUTOSAR to standardize V2X.

　　To address two main challenges, AUTOSAR has developed a new V2X remote antenna ECU specification in R22-11. In the remote antenna ECU, different manufacturers have completely different protocols for data transmission and reception between the remote V2X ECU and the cloud. It is quite troublesome to hand over data packets of different protocols to the ECU in the car for processing. For this scenario, AUTOSAR has developed a V2xRAL layer specifically to process the messages between the V2X cloud and convert them into AUTOSAR standard format specifications for internal Ethernet transmission, In the future, the development of other ECUs will receive AUTOSAR V2X messages in a unified and standardized format.

　　Source: AUTOSAR China

　　The second main module is the V2X Data Manager module, which is used to mask differences in protocols and signal standards between different V2X countries and regions.

　　Source: AUTOSAR China

　　Switching back to the remote diagnosis section, SOVD is a service-oriented vehicle diagnosis function. It is a standard for cooperation between AUTOSAR and ASAM organizations to expand communication between vehicles and the cloud.

　　How does AUTOSAR support the landing of SOVD on AUTOSAR? R22-11 mainly updated the DM in AUTOSAR AP. This module is mainly responsible for diagnostic management and specifically supports SOVD remote diagnostic services. Through this modification, the entire AUTOSAR AP can support SOVD technology.

　　Source: AUTOSAR China

　　In-Vehicle Communication Standards

　　Just now we talked about car cloud communication. Next, let's take a look at in car communication.

　　Firstly, the changes to the AUTOSAR R22-11 in the car communication section are related to the SD of SAME/IP. In the previous version, there were descriptions in both AP and FO, but there were conflicting descriptions between the two. Therefore, the R22-11 version was unified to make the two protocols more consistent.

　　Secondly, the explanatory API documentation for ara:: com has been released, which is very helpful for everyone to understand and use.

　　Thirdly, information security is a very important field. AUTOSAR has added this MACSec section in R22-11, and the protocol released is still the draft version.

　　The following other upgrades include CAN XL, CP platform support for DDS, and deterministic TSN on CP platform, with more consideration for timed and periodic transmission, as well as priority communication.

　　Source: AUTOSAR China

　　Overall, AUTOSAR has invested a lot of effort in the release of the new version of R22-11, sharing some important figures with everyone.

　　In 2029, AUTOSAR allocated a total of 2029 versions to release the entire R22-11;

　　1440 ", 1440 changes were recorded during task development;

　　The release of the entire R22-11 version involves the participation of 182 AUTOSAR partners and requires collective efforts;

　　334618 "represents a total of 334618 lines of AP platform demo code;

　　'13' represents that we have 13 new technological concepts and publish them as the final standard;

　　As everyone knows, we have two main product lines;

　　'1' is our vision, and the entire automotive industry has a unified and standardized E/E system architecture.

　　(The above content is from the keynote speech "R22-11 Technical Information Interpretation" delivered by Qian Jiamin, AUTOSAR China Technical Officer, at the 4th Software Defined Automotive Forum and AUTOSAR China Day on March 14-16, 2023.)