Related design solutions for intelligent driving systems and software upgrades

Author | Jessie

Produced | Yan Zhi

Zhiquan | To enter the "Computing Platform Group", please add WeChat yanzhi-6, remark calculation

Due to the trend of smart car centralization, the network connection has been upgraded from the traditional low-bandwidth Can network to a high-bandwidth Ethernet network. In order to improve the vehicle upgrade capability and provide car owners with continuous and high-quality experience and services, it is necessary to build on the existing system foundation (from the original upgrade of the traditional ECU on the vehicle to the process of incremental Ethernet upgrade) Develop a new OTA service system that is compatible with existing OTA systems to achieve OTA upgrade capabilities for vehicle software, firmware, and services, thereby ultimately improving user experience and service experience.

Two major areas involved in software upgrade-FOTA/SOTA

Vehicle software upgrade is through OTA technology, which is an upgrade of application software such as in-vehicle entertainment, navigation, human-computer interaction, and firmware such as steering, braking, and body control. The vehicle OTA upgrade package is composed of upgrade packages that can upgrade the ECU in the upgrade object. For vehicle OTA types, they are mainly divided into two categories, FOTA (Firmware-over-the-air) and SOTA (Software-over-the-air). Both are areas that OEMs focus on and are gradually implementing. They can be adapted to OTA needs in different scenarios.

FOTA (also known as mobile terminal over-the-air software upgrade technology) achieves a complete upgrade and update of system functions by downloading and installing a complete firmware image to the vehicle controller. FOTA involves a complete systematic update of the core functions of the controller's related strategies, which has a greater impact on vehicle performance. The upgrade process has extremely high requirements on timing, stability, and safety. At the same time, the prerequisites for the upgrade include gear, power, and vehicle speed. and other requirements, the upgrade process generally does not support ignition vehicles.

FOTA achieves a complete upgrade and update of system functions by downloading and installing a complete firmware image for the vehicle controller. For example, upgrading the vehicle's smart driving system allows drivers to enjoy more and more auxiliary driving functions; upgrading the vehicle's cockpit system to improve the accuracy of driver fatigue detection; upgrading the vehicle's braking system to improve the vehicle's braking performance.

SOTA can actually be seen as the core requirement of a software sales strategy. It implements an "incremental" update of the controller function by installing an "incremental package" on the vehicle controller. It is generally used in entertainment systems and smart driving systems. . For example, when changing the multimedia system operating interface, optimizing the dashboard display style, and updating the map program in the entertainment console, SOTA upgrade methods are used. SOTA involves a small-scale partial update of functions at the controller application layer, which has little impact on vehicle performance and requires low upgrade prerequisites. SOTA's incremental update strategy can significantly reduce the size of the upgrade package file, thereby saving network traffic and storage space.

Here we give examples to illustrate how FOTA and SOTA can be effectively defined in intelligent driving upgrades.

For example, upgrading a smart driving car system, in order to allow drivers to enjoy more and more assisted driving functions; the continuous update and iteration of phased functions (including from low-level functions to high-level functions) are usually determined based on the difficulty and length of function development. level of software replacement). At the same time, the vehicle's cockpit system needs to be upgraded during the process to improve the accuracy of driver fatigue detection; the associated subsystems of intelligent driving vehicles (such as braking, steering system and other modules) need to be upgraded to improve the vehicle's braking performance.

Software upgrade architecture in intelligent driving system

For the entire OTA upgrade, it mainly includes the following three aspects from bottom to top: upgrade object, OTA manager, and OTA cloud service platform. The autonomous driving domain controller and the cockpit domain controller are connected through Ethernet, and the upgrade protocol is generally the commonly used DoIP. In addition to the domain controller itself, the upgrade process also includes high-precision positioning module upgrades and sensor upgrades. For cameras connected by Ethernet, the upgrade process is mainly through the entire integrated program installed on the main domain controller. In other words, for pure camera sensors, there is no separate program upgrade process. For the millimeter wave/ultrasonic radar equipped with CANFD, since it has its own controller, the upgrade process mainly involves connecting the controller through CANFD. The domain control is connected to the public CAN through CANFD, and the cockpit domain is responsible for flashing the CANFD domain control. The transmitter forwards the message to each radar controller.

As shown in the figure above, the OTA cloud service platform mainly manages and delivers OTA upgrade packages, and completes the configuration, scheduling and tracking of upgrade tasks. The OTA manager mainly completes the downloading, decryption, signature verification, differential package reconstruction and other functions of the upgrade package, and finally sends the upgrade package to the corresponding upgrade object. The upgrade object is composed of one or more ECUs. After the upgrade object receives the upgrade package, it sends the corresponding ECU upgrade package to the corresponding ECU, and the ECU completes the flashing of the upgrade package.

The principle of the upgrade process in the intelligent driving system

The current upgrade method is mainly silent upgrade. That is, it includes sensible upgrades in normal mode and unconscious upgrades in abnormal mode. The normal mode is actually in the factory mode. After the multimedia receives the upgrade command, it downloads the upgrade package when the upgrade conditions are met, and performs automated vehicle upgrades. During the upgrade process, if after receiving the signal of unlocking/opening the door/pressing the start button/unlocking the cloud service, the vehicle display will not display the OTA upgrade, and the vehicle will be in a silent state during the regular upgrade process.

Perform silent upgrades in non-factory mode, and perform upgrades without users being aware of them as a reserved solution. Due to restrictions by relevant national laws, the implementation of this solution requires all modules of intelligent driving to meet the two-sided partition upgrade strategy. The two-sided distinction here refers to the A/B double-sided upgrade process. That is to say, two storage spaces A/B are opened for the SOC in the domain controller. Each storage space is installed with a system. When one system is in active use, the other system will be in standby state. When upgrading the system, you can upgrade the standby system in the activated system. After the upgrade is completed, restart and switch to the newly upgraded system. Therefore, the upgrade process in the SOC of smart driving domain control can be described as when the operating area is area A, then upgrade area B. After the upgrade is completed, restart from area B. After startup, synchronize area B to area A at the right time. . And when the SOC upgrade fails, enabled driving is not allowed.

In addition, for MCU flashing in domain control, it is best to use a dual APP mechanism. That is, the MCU adopts a bootloader single-zone + app dual-zone deployment method, and the bootloader generally does not need to be upgraded. Therefore, the MCU upgrade process only needs to be performed on APPs deployed in dual zones.

During the entire upgrade process, you need to complete the following upgrade tasks:

1) Judgment of upgrade preconditions:

Obtain the vehicle's current status check through in-vehicle networks such as Ethernet and CAN, and customize it according to the actual needs of the project, including but not limited to battery power, engine speed, vehicle speed, vehicle gear, handbrake status, seat sensor status, door status, and lock status wait. Before the upgrade starts, the cockpit domain controller needs to perform a status check on the upgraded vehicle and then continue with subsequent actions. Check items for its current status include: remaining internal storage space of the module, module hardware version, module firmware version, and module software version. Normally, during the upgrade process, it is necessary to determine whether the vehicle is stationary, whether the gear is in P position, and whether the SOC power of the domain controller is greater than a certain threshold. Under appropriate circumstances, the scheduled upgrade or immediate upgrade instructions will pop up on the central control interface/electrical inspection computer display. There are two situations that will trigger the upgrade: power-on and power-off self-test and user-initiated triggering. The upgrade condition is triggered. If the trigger is successful, proceed to the next step. Otherwise, exit the upgrade process.

2) Download the upgrade package:

During the process of delivering the cloud upgrade strategy and upgrade package, the cloud needs to detect whether the version number has been updated. The OTA upgrade server delivers the upgrade strategy package to the cockpit domain controller. Users will not be aware of this process. The cockpit domain controller supports conventional flash upgrade methods, DoIP and CAN flash.

Software flashing based on CAN protocol

The CAN programming process is actually a programming process based on specifications (the specifications are mainly based on ISO 14229). During the programming process, you need to specify and refer to the following types of different steps for effective addressing and service access:

Standard steps are mandatory steps that require clients and servers to act in accordance with the regulations under any circumstances. Recommended steps are optional, require the use of a specific diagnostic service identifier, and contain recommendations on how to perform actions. This alternative only requires that the client and server behave as specified when using the specified functionality. OEM implementation step: Its use and content (e.g. diagnostic service identifiers used) are at the discretion of the vehicle manufacturer and may of course be an optional step.

CAN software flashing is mainly divided into three stages: pre-programming stage, programming stage and end stage. The corresponding business processes required at each stage are shown in the figure below:

Detailed explanation of software flashing based on DoIP protocol

DoIP (Diagnostic communication over Internet Protocol), as a diagnosis based on automotive Ethernet, mainly exists in the transport layer of the OSI seven-layer model. DoIP is a transmission protocol for transmitting UDS diagnostic data on the Ethernet network. DoIP has high bandwidth and is suitable for scenarios where large amounts of data are transmitted, making it very suitable for OTA software upgrades in vehicles. Compared with CAN, DoIP mainly optimizes data transmission and improves the speed at the physical layer and transport layer. In the application layer and diagnostic service links, the implementation of CAN and DoIP is based on the 14229 protocol. In the ODX database part, except for adding DoIP protocol communication parameters and related controllers, generally no additional adjustments are required, which greatly saves diagnostic data development time and cost.

File flashing for DoIP mainly includes DoIP flashing without a file system controller and DoIP flashing with a file system controller. For the flashing of the file system controller, the overall scheme is similar to the CAN node flashing scheme. The multimedia host transmits by address, and the controller writes by address. For controllers with a file system, the multimedia host only needs to transmit the upgrade package to the controller (of course, it needs to be able to support breakpoint resumption during the process), and there are no other requirements.

Currently, the commonly used DoIP diagnostic connection methods are divided into two types: one is the Ethernet cable direct connection form: in the case of the entire vehicle, an OBD-Ethernet cable is made for direct connection; the other is compatible with CAN/CAN FD communication. And to meet production and after-sales needs, DoIP communication is realized by using the diagnostic VCI to integrate the Ethernet activation function. After the database is created, the vehicle flashing process can be realized using relevant diagnostic tools.

After receiving the vehicle factory mode automated upgrade command issued by the server, the cockpit domain control requests the server to automatically download the upgrade package if the upgrade conditions are met, and automatically upgrades the vehicle, supporting breakpoint resume and integrity verification. Storage space management and other functions.

3) Smart driving domain controller upgrade status feedback:

The smart driving domain controller reports the domain controller information to the cockpit domain controller to complete the precondition judgment for the upgrade. Only when the conditions are met can the OTA upgrade be entered. Upgrading this type of information needs to be uploaded to the OTA server. This type of information includes the software/hardware version number, serial number (SN), positioning information (GPS), etc. of each module of the domain controller.

4) Perform upgrade tasks:

The cockpit domain controller will perform OTA upgrades based on the upgrade package, upgrade strategy and other information issued by the server. If joint upgrade and flashing of multiple ECUs is required at the same time, it is necessary to send point-to-point upgrade interaction information to the corresponding controller according to the issued upgrade task sequence in order to complete the corresponding upgrade task.

5) Breakpoint continuation upgrade:

Breakpoint continuation upgrade refers to state machine-based management. During the upgrade process, the currently upgraded files or block devices are backed up and stored. If an interruption, power outage, or other interference occurs during the upgrade process, causing the file being upgraded to be damaged, then the controller will record the current upgrade status, and the controller will execute a certain verification algorithm the next time the program is restarted ( (such as hash verification) to evaluate whether the file has been damaged. If the program is intact, it will be upgraded directly in the order of programs that have not been marked for upgrade. If the file is corrupted, the backup storage is used to restore the upgrade.

The entire upgrade process generally requires several retry opportunities after flash failure. If there are dependencies on associated modules, all upgraded associated modules need to be rolled back.

6) Linked upgrade management:

For ECUs with related functions (for example, the upgrade of the front millimeter wave radar can be regarded as a linked upgrade of the same nature), the background can set up a linked upgrade, and can also set the upgrade sequence for the associated ECUs. The upgrade process is that when the cockpit domain controller obtains the upgrade task from the background, it will detect whether there is a linkage upgrade requirement in the upgrade command. If so, it will upgrade one by one in order and associate it with the ECU.

The cockpit domain controller will manage and continuously distribute upgrade packages during the entire upgrade process, monitor the entire upgrade process until all ECUs are upgraded, and then uniformly report the background upgrade results. When it is detected that any ECU upgrade fails and needs to be rolled back, the controller will link all associated ECUs to synchronize the version rollback. At the same time, the cockpit domain controller will effectively report which ECU upgrade failed resulting in rollback.

The corresponding software upgrade sequence diagram is as follows:

Based on the above description, the upgrade of each module of the vehicle can be summarized as follows: the upgrade strategy file is issued by the OTA server to determine the upgrade sequence, the strategy file is generated when the upgrade is configured on the server, and the cockpit domain control formulates the upgrade plan and sequence of each ECU based on the strategy file. The upgrade order of intelligent driving related modules is controlled according to the following priority order: CAN module -> DoIP module without file system -> DoIP with file system.

Compared with CAN, DoIP mainly optimizes data transmission and improves the speed at the physical layer and transport layer. In the application layer and diagnostic service links, the implementation of CAN and DoIP is based on the 14229 protocol.

Summarize

For intelligent driving systems, software upgrades have become an integral part. While providing customers with real-time online upgrade functions, domain controllers need to meet cloud secure communications, including protocol communication link management, upgrade instruction reception and upgrade status transmission, upgrade package download, upgrade package decryption, differential package reconstruction, and upgrade package verification. For legality verification, it also includes key certificate management services, data encryption services, digital signature services and other functions. It can be said that intelligent driving-level software upgrades are the driving force behind its continuous development.