OTA software update data transmission method and system

Abstract

The present application provides an OTA software update data transmission method and system. In the vehicle-mounted OTA software update data transmission system, the H2PU receives the software update instruction pushed by the cloud server, and forwards the software update instruction and the software update file carried by the software update instruction to the SOC; the software update file includes: at least one target controller identifier, a software update package corresponding to each target controller identifier, and a flash process configuration file; for each target controller identifier, the SOC transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier and the update link corresponding to the target controller identifier, so that the target controller performs a software version update. The present application can realize multi-point simultaneous upgrade package transmission and OTA upgrade, improve the upgrade package transmission rate, and improve the OTA upgrade efficiency.

Description

Technical Field

[0001] The present application relates to the field of intelligent driving technology, and in particular to an OTA software update data transmission method and system. Background Art

[0002] With the rapid development of the autonomous driving and Internet of Vehicles industries, and the explosive growth of automotive electronic systems and software, software updates are rapid to meet new functions and new needs. The autonomous driving domain involves a variety of devices such as millimeter-wave radars, lidars, IMU inertial measurement units, ADU autonomous driving domain controllers, and H2PU high-precision positioning units. The ADU autonomous driving domain controller serves as the main control unit in the autonomous driving domain and also as the main node for OTA over-the-air download upgrades in the autonomous driving domain. Therefore, ADU requires a more efficient and convenient way to transmit upgrade packages to adapt to multi-channel sensor upgrades and other component upgrades in the domain.

[0003] In the existing technology, the upgrade package transmission and OTA upgrade are often carried out in a point-to-point manner throughout the entire autonomous driving domain, resulting in low transmission rate and complex upgrade communication interaction links. Currently, there is no reliable and complete OTA network architecture communication link system. Summary of the invention

[0004] The purpose of the present application is to provide an OTA software update data transmission method and system, based on the target controller identifier contained in the software update file, the software update package corresponding to the target controller identifier and the flashing process configuration file, through the update link corresponding to the target controller, it is possible to realize multi-point simultaneous upgrade package transmission and OTA upgrade, thereby improving the upgrade package transmission rate and the OTA upgrade efficiency.

[0005] In a first aspect, an embodiment of the present application provides an OTA software update data transmission method, which is applied to an OTA software update data transmission system; the system includes: an autonomous driving domain controller ADU, a positioning controller H2PU, a driving monitoring system DMS and an environmental monitoring controller; wherein the ADU includes: a system-level controller SOC and a microcontroller MCU; the H2PU is connected to the SOC and the DMS respectively; the SOC is also connected to the MCU and the environmental monitoring controller respectively; the MCU is also connected to the environmental monitoring controller; the method includes: the H2PU receives a software update instruction pushed by a cloud server, and forwards the software update instruction and the software update file carried by the software update instruction to the SOC; the software update file includes: at least one target controller identifier, a software update package corresponding to each target controller identifier, and a flash process configuration file; the SOC, for each target controller identifier, according to the flash process configuration file corresponding to the target controller identifier, according to the update link corresponding to the target controller identifier, transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier, so that the target controller performs a software version update.

[0006] In the second aspect, an embodiment of the present application also provides an OTA software update data transmission system, the OTA software update data transmission system includes: an autonomous driving domain controller ADU, a positioning controller H2PU, a driving monitoring system DMS and an environmental monitoring controller; wherein, the ADU includes: a system-level controller SOC and a microcontroller MCU; the H2PU is connected to the SOC and the DMS respectively; the SOC is also connected to the MCU and the environmental monitoring controller respectively; the MCU is also connected to the environmental monitoring controller; the OTA software update data transmission system is used to execute the method described in the first aspect.

[0007] In the OTA software update data transmission method and system provided in the embodiment of the present application, the method is applied to the OTA software update data transmission system; the system includes: an autonomous driving domain controller ADU, a positioning controller H2PU, a driving monitoring system DMS and an environmental monitoring controller; wherein the ADU includes: a system-level controller SOC and a microcontroller MCU; the H2PU is connected to the SOC and the DMS respectively; the SOC is also connected to the MCU and the environmental monitoring controller respectively; the MCU is also connected to the environmental monitoring controller; the method includes: the H2PU receives the software update instruction pushed by the cloud server, and forwards the software update instruction and the software update file carried by the software update instruction to the SOC; the software update file includes: at least one target controller identifier, a software update package corresponding to each target controller identifier, and a flash process configuration file; the SOC transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier and the update link corresponding to the target controller identifier for each target controller identifier, so that the target controller performs a software version update. In an embodiment of the present application, based on the target controller identifier contained in the software update file, the software update package corresponding to the target controller identifier and the flashing process configuration file, through the update link corresponding to the target controller, it is possible to realize multi-point simultaneous upgrade package transmission and OTA upgrade, thereby improving the upgrade package transmission rate and the OTA upgrade efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0009] Figure 1 A schematic diagram of the architecture of an OTA software update data transmission system provided in an embodiment of the present application;

[0010] Figure 2 A schematic diagram of the architecture of another OTA software update data transmission system provided in an embodiment of the present application;

[0011] Figure 3 A software architecture diagram for upgrading the master node ADU-SOC provided in an embodiment of the present application;

[0012] Figure 4 A schematic diagram of an update link of a LIADR laser radar provided in an embodiment of the present application;

[0013] Figure 5A schematic diagram of a DMS update link provided in an embodiment of the present application;

[0014] Figure 6 A schematic diagram of an update link on an MCU side provided in an embodiment of the present application;

[0015] Figure 7 A schematic diagram of an update link of a multifunctional camera provided in an embodiment of the present application;

[0016] Figure 8 A state switching diagram of the Transfer component of the OtaEngine module provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] The technical solution of the present application will be described clearly and completely below in conjunction with the embodiments. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0018] In the prior art, the following problems often exist during the transmission of software update packages:

[0019] 1. The existing OTA technology only supports single-point software update package transmission and single-point OTA upgrade interaction (at the same time, only one data transmission or upgrade interaction is supported), which results in a long upgrade time, further affecting the user's car experience.

[0020] 2. In the existing OTA technology, it is impossible to adapt the upgrade of components efficiently and quickly, and it often takes a lot of time and effort to develop and debug the upgrade module software of the component.

[0021] 3. In the existing OTA technology, since the components in the domain use their own flashing specifications, in the traditional upgrade plan, they often implement their own software update functions according to the flashing specifications of their respective manufacturers. This makes the software full of redundant codes, greatly increasing the complexity of the software.

[0022] 4. In the existing OTA technology, due to differences in communication types and operating system platforms, such as CAN, LIN, and ETH, it is impossible for only one node to serve as the upgrade master node, so it is impossible to achieve unified management and control of the upgrade process and version number information.

[0023] 5. In existing OTA technologies, due to differences in communication types, receiving and forwarding data at the application layer often requires a lot of CPU running time.

[0024] 6. In the existing OTA technology, in multi-link transmission communication, if the communication is abnormal, it is impossible to quickly and efficiently locate the path status between the modules.

[0025] 7. In the existing OTA technology, the executable file upgrade package file must have continuous addresses, and additional padding is required.

[0026] Based on this, the embodiments of the present application provide an OTA software update data transmission method and system to solve the following problems:

[0027] 1. Use multi-point software update package transmission and multi-point OTA upgrade interaction (support multi-channel data transmission and upgrade interaction at the same time) to shorten the upgrade time and improve the user experience.

[0028] 2. Design a general component flashing specification OtaEngine configuration file, and based on this file, design and implement a general upgrade engine module to efficiently and quickly adapt to component upgrades, greatly shortening the time and effort spent on component upgrade module software development and debugging.

[0029] 3. Adopt a universal and template-like general software architecture, and adapt to the upgrade of different components through different flashing specifications OtaEngine, which greatly reduces redundant code in the software and greatly reduces the complexity of the software.

[0030] 4. In the autonomous driving domain, using ADU as the main upgrade control node can achieve unified control of version number information, greatly facilitate the control of the upgrade process, and reduce the complexity of OTA upgrades.

[0031] 5. The Doip Gateway method is used to shorten the CPU overhead during forwarding. If the communication link is abnormal, the abnormal communication link point can be quickly located based on the Doip ACK response mechanism.

[0032] 6. The upgrade engine of the invention implements an automatic filling mechanism for discontinuous addresses in the ECU upgrade package, which greatly facilitates the production of the upgrade package and reduces the upgrade package filling action.

[0033] 7. The invention supports dynamic changes in the flashing process of components, reduces software development and debugging caused by process changes, and greatly shortens the software update iteration cycle.

[0034] 8. The invention supports dynamically increasing or decreasing the number of component upgrades within the autonomous driving domain, thereby reducing the additional development and debugging tasks caused by the upgrade of new components.

[0035] To facilitate understanding of this embodiment, an OTA software update data transmission system disclosed in an embodiment of the present application is first introduced in detail.

[0036] Figure 1 The schematic diagram of the architecture of an OTA software update data transmission system provided in the embodiment of the present application includes: an autonomous driving domain controller ADU, a positioning controller H2PU, a driving monitoring system DMS and an environmental monitoring controller; wherein the ADU includes: a system-level controller SOC and a microcontroller MCU; the H2PU is connected to the SOC and the DMS respectively; the SOC is also connected to the MCU and the environmental monitoring controller respectively; the MCU is also connected to the environmental monitoring controller. Based on the above system architecture, the steps of the OTA software update data transmission method provided in the embodiment of the present application include:

[0037] (1) The H2PU receives the software update instruction pushed by the cloud server, and forwards the software update instruction and the software update file carried by the software update instruction to the SOC; the software update file includes: at least one target controller identifier, a software update package corresponding to each target controller identifier, and a flashing process configuration file;

[0038] (2) The SOC transmits, for each target controller identifier, a software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier and the update link corresponding to the target controller identifier, so that the target controller performs a software version update.

[0039] In the autonomous driving domain, ADU includes MCU and SOC. The MCU microcontroller is equipped with the real-time operating system AutosarOs, and the SOC high-performance controller is equipped with the QNX system. In the autonomous driving domain, ADU connects almost all controllers on the vehicle, so ADU plays a vital role in OTA upgrades. In the embodiment of the present application, ADU is used as the Master node for upgrading all components in the domain, responsible for the signature verification, data transmission, upgrade package version information management, and upgrade process management of all sensors and controllers in the domain. Therefore, ADU needs to have the flashing specifications and processes for all sensors and controllers in the domain. Due to the differences in flashing specifications and flashing file formats among manufacturers, ADU needs a set of general software upgrade software architecture that can quickly and efficiently adapt to the flashing specifications of each controller. For this reason, the embodiment of the present application provides an efficient and convenient upgrade interaction process software architecture and network link to enable the upgrade of controllers in the domain to be carried out quickly and efficiently.

[0040] See also Figure 2 As shown, overall it is mainly composed of the cloud-side vehicle cloud and the vehicle-side autonomous driving domain.

[0041] The vehicle cloud is a cloud server responsible for pushing software update packages, visually displaying the vehicle's operating status, and remote control and remote diagnosis. The vehicle-side autonomous driving domain mainly includes: H2PU, ADU, DMS, Radar, Lidar, MultiFunctionCamera and other controllers, including:

[0042] H2PU uses the HTTP protocol to transmit and interact with the cloud through the 4G / 5G module, and forwards or transparently transmits vehicle operation status information, software update status, vehicle diagnosis, vehicle control and other results to the cloud. At the same time, H2PU will also forward or transparently transmit remote control, remote diagnosis, software update and other instructions issued by the cloud to the ADU end in the autonomous driving domain. Figure 2 It can be seen that H2PU mainly interacts with ADU and DMS, where H2PU uses UDSonIP protocol to communicate with ADU and uses UDSonCAN protocol to communicate with DMS.

[0043] ADU is the main control unit in the autonomous driving domain, and has direct or indirect connections with all controllers in the domain. ADU contains two controller units, the SOC high-performance controller and the MCU microcontroller. The SOC is responsible for external communications based on UDSONIP, and the MCU is responsible for external communications based on CAN, CANFD, LIN, J1939, etc. It is responsible for upgrading almost all upgradeable components in the autonomous driving domain, including: upgrading software data packet transmission, upgrading process management, upgrading software version management, responsible for the summary and reporting of fault information in autonomous driving, and supports processing and receiving remote diagnosis functions initiated by the cloud. ADU supports online diagnosis of other components in the domain, that is, remote diagnosis, and supports remote interaction. It is responsible for reporting information such as the vehicle status of the autonomous driving system, vehicle control information, and camera raw data. It also interacts with the HMI human-computer interaction interface to provide real-time feedback on the operating status of each module or component in the intelligent driving domain.

[0044] Lidar_Front_MidRange is responsible for detecting the distance, position, height, posture and other related information of the surrounding environment targets in the intelligent driving system. It communicates with ADU through Ethernet. The upgrade and data interaction adopt the UDSonIP protocol based on Ethernet.

[0045] Radar detects targets in the surrounding environment, including the target's angle, distance, relative speed, etc. Figure 2 As shown in the figure, a four-way medium-length millimeter-wave radar is used, which is connected to the ADU MCU via CAN / CANFD, and its upgrade interaction mainly adopts the UdsOnCan protocol.

[0046] MultiFunctionCamera is a multifunctional camera used for lane line recognition, traffic signal recognition, and traffic light recognition, such as Figure 2 As shown, the multi-function camera is connected to the ADU via one CAN, and the upgrade interaction adopts the UdsOnCan protocol for interaction.

[0047] The DMS driving monitoring system is responsible for driver status monitoring and is connected to the H2PU via CAN. During the communication interaction process, the DMS interacts with the ADU indirectly via the H2PU, where the H2PU acts as a DOIP-GATEWAY gateway, routing the communication interaction data between the ADU and the DMS.

[0048] In an embodiment of the present application, based on the target controller identifier contained in the software update file, the software update package corresponding to the target controller identifier and the flashing process configuration file, through the update link corresponding to the target controller, it is possible to realize multi-point simultaneous upgrade package transmission and OTA upgrade, thereby improving the upgrade package transmission rate and the OTA upgrade efficiency.

[0049] The following first demonstrates the upgrade data transmission link between each controller based on the overall system network architecture of the upgrade link within the ADU domain.

[0050] The above-mentioned target controller is a first-class controller; the first-class controller includes a laser radar in an H2PU or an environmental monitoring controller, and the update link corresponding to the target controller is: SOC-first-class controller; the SOC transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the update link corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier, including: in a preferred embodiment of the present application, the above-mentioned target controller is a DMS; the update link corresponding to the target controller is: SOC-H2PU-DMS; the SOC transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier, including: the SOC verifies the signature of the DMS software update package corresponding to the DMS, and sends the DMS software update package to the H2PU according to the DMS flash process configuration file corresponding to the DMS, so that the H2PU acts as a DOIP gateway to forward the DMS software update package to the DMS.

[0051] In a preferred embodiment of the present application, the above-mentioned target controller is a second-class controller; the second-class controller includes a millimeter-wave radar or a multi-function camera in an environmental monitoring controller, and the update link corresponding to the target controller is: SOC-MCU-second-class controller; the SOC transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the update link corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier, including: the SOC verifies the second software update package corresponding to the second-class controller, and sends the second software update package to the MCU according to the second flash process configuration file corresponding to the second-class controller, so that the MCU acts as a DOIP gateway to forward the second software update package to the second-class controller.

[0052] (1) The first upgrade link: the target controller is a first-class controller; the first-class controller includes a laser radar in an H2PU or an environmental monitoring controller, and the update link corresponding to the target controller is: SOC-first-class controller; the SOC verifies the signature of the first software update package corresponding to the first-class controller, and transmits the first software update package to the first-class controller according to the flash process configuration file corresponding to the first-class controller.

[0053] First, we need to understand the software architecture of the ADU-SOC master node in the ADU domain. Figure 3 shown.

[0054] As the main control unit in OTA and the upgrade software update package center, it not only needs to implement upgrade process control and software update package transmission, but also needs to inspect and sign the software update package, control the version of the controller in the domain, report the upgrade status to the cloud, and provide real-time feedback on the current status of the HMI. In this embodiment, the SOC adopts the DOIP transmission protocol and is responsible for the communication and interaction between various components. The internal data transmission link of the SOC is as follows: Figure 3 As shown by the arrow in the middle, the functions of each module will be introduced in detail below.

[0055] TCP / IP: Transmission Control Protocol and Internet Protocol, which regulates all communication devices on the network, especially the format and transmission method of data exchange between one host and another. Defines the communication method of the transport layer.

[0056] DOIP: DoIP (Diagnostic communication over Internet Protocol) is based on the diagnosis of in-vehicle Ethernet. 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, such as OTA software upgrades on vehicles.

[0057] DM: diagnostic management implements diagnostic communication management, diagnostic session control, diagnostic service analysis and distribution, fault information management, fault information storage, etc.

[0058] DMS: diagnostic management server implements diagnostic services and application layer, including security access algorithms, data transmission, diagnostic data acquisition, file transmission, data verification, data signature verification, etc.

[0059] OTAM air upgrade management, to initiate the upgrade process, obtain the upgrade progress to HMI and the cloud, and control the overall upgrade process (software update package reception, software update package signature verification, software update package decompression, and initiating upgrades through the manifest list).

[0060] OTAE over-the-air upgrade engine implements a universal software update package transmission architecture, realizes the management and control of the upgrade process, upgrade package software parsing, provides a standard upgrade progress interface to OTM, implements the standardized process of flashing components, realizes UDS services, communication timeout monitoring, abnormality monitoring, etc., and passes the DMC standard UDS service interface.

[0061] DMS diagnostic management client initiates standard UDS services and supports session management, secure access management, response timeout monitoring, etc.

[0062] The following is a detailed introduction to the SOC upgrade link and the general data transmission process. On the SOC side, the laser radar and H2PU are connected. The laser radar uses the high performance and high computing power of the SOC to process the big data of target information in real time. The H2PU and SOC have frequent data interactions, such as remote diagnosis, remote interaction, OTA software update package transmission, etc. The upgrade interaction between H2PU and LIDAR is basically the same. Here, the LIADR laser radar is taken as an example to explain the communication link. Figure 4 shown.

[0063] The SOC is responsible for the signature verification and storage of the laser software update package. The SOC divides the software update package into data blocks of specified size according to the receiving capability of the LIADR through UDSONIP, and sends it to the lidar through data transmission or file transmission (the 2020 version of ISO14229 adds the new UDS service 0x38 to request file transfer). The lidar stores the data in real time and verifies the data integrity. According to the LIDAR flash specification, specify OtaEngine_LidarUpdate.json for flashing and upgrading.

[0064] In terms of interactive links, H2PU and LIDAR are basically the same, the only difference is that they will be sent to the diagnostic path of the specified H2PU according to the H2PU target address and IP address. In terms of the flashing process, H2PU and LIDAR each follow their own flashing specifications.

[0065] (2) The second upgrade link: the target controller is DMS; the update link corresponding to the target controller is: SOC-H2PU-DMS; SOC verifies the signature of the DMS software update package corresponding to DMS, and sends the DMS software update package to H2PU according to the DMS flash process configuration file corresponding to DMS, so that H2PU forwards the DMS software update package to DMS as a DOIP gateway.

[0066] See also Figure 5 As shown, DMS is directly connected to H2PU, so H2PU plays the role of DOIP Gateway in the communication link of DMS upgrade interaction, and needs to forward and route the upgrade interaction data of ADU to DMS. Note that the IP address of SOC initiating DOIP diagnosis is set to H2PU IP address, but the target address in DOIP message needs to be set to the target address of DMS link, and the value of the target address needs to be coordinated with H2PU. The SOC will specify OtaEngine_DMSUpdate.json file according to DMS flash specification to initiate flash upgrade interaction.

[0067] (3) The third upgrade link: the target controller is a second-type controller; the second-type controller includes a millimeter-wave radar or a multi-function camera in an environmental monitoring controller, and the update link corresponding to the target controller is: SOC-MCU-second-type controller; the SOC verifies the signature of the second software update package corresponding to the second-type controller, and sends the second software update package to the MCU according to the second flash process configuration file corresponding to the second-type controller, so that the MCU, as a DOIP gateway, forwards the second software update package to the second-type controller.

[0068] First understand the software architecture of the MCU, such as Figure 6 Figure 1 shows the software architecture of the MCU-side diagnostic communication link. In the software update interactive link, the MCU uses the standard AUTOSAR diagnostic communication protocol stack, such as Figure 6As shown in the figure, it mainly realizes the conversion between the diagnostic message based on Ethernet and the diagnostic message based on CAN bus (i.e. DOIP to CANTP). Considering the difference in the communication rate between the vehicle Ethernet and the CAN bus, the MCU needs to implement flow control and set the shared buffer mode to achieve the transmission needs. It also supports the conversion between the diagnostic message based on Ethernet and the diagnostic message based on CANFD bus and the conversion between the diagnostic message based on Ethernet and the diagnostic message based on LIN bus.

[0069] In the ADU domain upgrade interactive link, the 4-channel millimeter-wave radar upgrade interactive link is basically the same as the multi-function camera. The only difference is that the MCU will send it to the diagnostic path of the specified millimeter-wave radar according to the target address when routing. Since there are four millimeter-wave radars, it should be noted that the target address of each channel is different to distinguish the respective upgrade links.

[0070] In the flashing process, the 4-way millimeter wave radar upgrade interactive link and the multi-function camera each follow their own flashing specifications, so the flashing process is different. The present invention defines the flashing specifications in their respective manifest lists, which are uniformly managed by the SOC and are currently distinguished according to the models of various components. The following will introduce the component upgrade specification manifest list of the present invention in detail.

[0071] The following takes the multi-function camera upgrade interaction as an example to explain the upgrade communication link.

[0072] Since the MCU in the ADU has a wealth of standard protocol communication interfaces, such as LIN interface, CAN interface, CANFD interface, and J1939 interface, it is mainly responsible for the communication of components such as the protocol bus, and for upgrading data transmission. In this invention, it can be seen from the system architecture that the current upgrade interaction on the MCU side is mainly 4-channel millimeter-wave radar and 1-channel multi-function camera. The 4-channel millimeter-wave radar uses the upgrade interaction protocol UDSONCAN, and the multi-function camera uses the upgrade interaction protocol UDSONCANFD. Taking the upgrade of the multi-function camera as an example, the upgrade communication link is as follows: Figure 7 As shown:

[0073] The SOC is responsible for the signature verification and storage of the multi-function camera software update package. The SOC divides the software update package into data blocks of specified size according to the receiving capability of the MFC through UDSONIP and sends it to the MCU. The MCU distinguishes the routing link of the diagnostic message according to the target address of the received DOIP diagnostic message (set to the target address of the multi-function camera). When the DOIP diagnostic message reaches the MCU doip layer, the doip header will be parsed, and the sender will be identified whether it is in its whitelist according to the source address and destination address in the data field. Otherwise, the message will be discarded and a negative Ack response will be sent. If the source address of the sender is identified as consistent, the ack will be responded to in the affirmative. Then, the destination address will be determined at the upper layer. According to the configured link, the content of the Doip diagnostic message data field will be sent to the diagnostic communication link of the multi-function camera, that is, the CAN transport layer corresponding to the multi-function camera. CanTp is responsible for packet assembly and unpacking, and is assembled and sent according to the iso15765-2 protocol, and finally sent to the CAN communication link of the multi-function camera.

[0074] The flashing specifications for multi-function cameras have been developed in OtaEngine_MFC_Update.json, which can adapt to the upgrade of MFC standards.

[0075] In a preferred embodiment of the present application, the SOC is also used to divide the software update package into data blocks of a specified size according to the data volume receiving capacity of the target controller, and send it to the target controller through data transmission or file transmission. The generation process of the flash process configuration file corresponding to each target controller is as follows: for each target controller, obtain the flash process configuration parameters corresponding to the target controller; import the flash process configuration parameters into the preset OTA software flash configuration template to generate the flash process configuration file corresponding to the controller.

[0076] The flash process configuration files corresponding to each of the above target controllers include: general configuration information, communication protocol configuration information, data file transmission configuration information, and process service configuration information. The above SOC is installed with an OTA engine; the SOC executes the software version update steps corresponding to at least one target controller through the OTA engine. The above OTA engine includes: a configuration file parsing component, an update package file parsing component, a UDS service component, a data transmission component, and an upgrade management component.

[0077] The following will specifically introduce the upgraded data transmission master node OtaEngine and its configuration file provided in an embodiment of the present application.

[0078] Combined with the situation in the autonomous driving domain, a standard and universal OtaEngine component flash process configuration file is provided in the embodiment of the present application. The file adopts the json file format, which is used to maintain the software update specifications of each component in the autonomous driving domain, and a set of universal software flash architecture is developed based on the file and named OtaEngine. Its function is similar to that of a template. By importing different OtaEngine component flash configuration files, the flash process specifications of the controller can be quickly formulated. In this embodiment, the OtaEngine module maintains the OtaEngine configuration files of each component. The file defines: general configuration, Doip bus configuration, DataTransfer / FileTransfer configuration, process service configuration parameters, etc. It includes a controller upgrade file list (application upgrade package data, calibration area data, flash driver data, etc.), a communication parameter list, an upgrade service process flow, etc. Each controller in the domain corresponds to its own OtaEngine configuration file. The configuration file mapping relationship in the embodiment of the present application is roughly as shown in Table 1:

[0079] Table 1

[0080]

[0081] The following will first introduce the OtaEngine configuration file, and then introduce the detailed design of the OtaEngine module. The OtaEngine configuration file of the present invention mainly includes: general configuration, Doip communication configuration, DataTransfer / FileTransfer configuration, and process service configuration parameters. The specific field design and description are as follows:

[0082] ·General configuration, the present invention is designed as a general configuration including: manifest protocol version information, file transfer type, controller ID, file type, number of files, data transfer verification method, security access mask, etc. As shown in Table 2:

[0083] Table 2

[0084]

[0085] ·File list (DataTransfer / FileTransfer configuration), designed as follows:

[0086] Different transmission types are divided into data transmission and file transmission, where data transmission is in the form of binary stream, specifying the data transmission storage address, data transmission size, etc. For example: 0x34 service in UDS service, requesting data transmission, as shown below:

[0087] Currently, based on the data transmission file list, the identifier field "RequestDataTransferPara" is used to indicate that the data transmission file list supports multiple data transmissions. The current definition of this field is shown in Table 3:

[0088] Table 3

[0089]

[0090] File transfer is performed in units of files, specifying the file name and file path, file size, file compression type, etc. For example: In the UDS service, the 0x38 service requests file transfer, and the json format in the manifest is as follows:

[0091] Currently, the file list based on the file transfer method uses the identifier field "RequestFileTransferPara" to indicate the file transfer file list. Currently, multiple file transfers are supported. The current definition of this field is shown in Table 4:

[0092] Table 4

[0093]

[0094] Doip communication configuration, the design method of the present invention is:

[0095] DMC reads its communication configuration parameters and establishes Doip communication. The communication parameter design is shown in Table 5 below:

[0096] Table 5

[0097] Field Name describe IPAddress UDS Server IP address LogicalAddress Destination address of the UDS Server node SourceAddress UDS Client source address FunctionAddress UDS Server Function Addressing Address

[0098] The flashing specification process is displayed in the form of a Uds service list. The format designed in the embodiment of the present application is shown in Table 6:

[0099]

[0100] The core module OtaEngine in this embodiment is introduced below, which implements OtaEngine configuration file parsing, software update package parsing, upgrade process control, software update package software version management, upgrade exception error handling mechanism, upgrade state machine, etc. Its software architecture mainly includes: JsonParse, UpdateFileParse, UdsService, DataTransfer, UpdateManage and other components, which correspond to configuration file parsing component, update package file parsing component, UDS service component, data transmission component, and upgrade management component respectively. The role played by each module and the functions implemented will be introduced in detail below.

[0101] JsonParse component: implements the reading and parsing of Json configuration files and provides a standard Reader interface.

[0102] FileParse component: implements the parsing of Upgrade Packet upgrade package files, supports the parsing of upgrade package file formats such as S19, Hex, and Bin on the MCU platform, and supports the parsing of binary stream files of upgrade package files on the SOC platform.

[0103] UdsService component: implements standard UDS services and provides standard service interfaces, capable of registering callback functions such as service response, service response timeout, and service exception response.

[0104] DataTransfer component: implements the standard UDS flashing process, realizes upgrade package segmented transmission, upgrade package filling, upgrade package transmission flow control, multi-file transfer management, transfer status management, transfer exception management, etc.

[0105] UpdateManage component: implements upgrade process management, such as initiating upgrade requests, monitoring upgrade progress, and handling upgrade exceptions.

[0106] The following is a detailed description of the functional implementation of each component of OtaEngine:

[0107] The JsonParse component is used to parse the OtaEngine_Update_Config.json file and provides a variety of reader interfaces, such as DoipReader, CommonReader, UdsServiceTableReader, RequestDataTransferReader, etc.

[0108] DoipReader parses and obtains Doip communication parameters and provides a read interface;

[0109] CommonReader parses and obtains common configuration parameters and provides a read interface;

[0110] RequestDataTransferReader parses and obtains data transmission related parameters and provides a read interface;

[0111] UdsServiceTableReader parses and obtains the controller's flash process service list and provides a read interface.

[0112] The FileParse component is used to implement the parsing of software update packages (software update packages are executable files compiled and generated by the microcontroller embedded platform). Currently, the embodiments of the present invention support the parsing of multiple file types, such as: ASCII text files (S19 files) composed of Motorola S19 file format, ASCII text files (HEX files) composed of texts in Intel HEX file format, ASCII text files (bin files) composed of texts in binary file format, and executable files compiled and generated by the system-on-chip embedded Linux platform, such as ASCII text files (bin files) composed of texts in binary file format, which basically cover all upgrade file formats.

[0113] The UdsService component is used to implement standard UDS service sending and receiving interfaces and service distribution functions. The UdsService component mainly includes: Commucation (providing standard UDS service sending and receiving interfaces), ExceptionHandler (Uds service response timeout processing, Uds negative response processing), DiagMsgHandler (filling the corresponding fields of the Uds service message according to the OtaEngine configuration file, and checking whether the Uds response message complies with the specification), and DiagServiceDispatcher (distributing and processing diagnostic services).

[0114] The UpdateManage component is used to implement OtaEngine's external interaction (reporting current progress, obtaining vehicle status, etc.), retrieve components that need to be upgraded, initiate the upgrade process, monitor the upgrade progress, handle upgrade exceptions, maintain the OtaEngine component flash specification json file, etc. Among them, UpdateManage is designed as a factory class, which can flexibly add and delete the upgrade of a certain component. It obtains the current upgrade item through the OtaEngine_Update.json file and initiates the upgrade accordingly. The present invention currently supports the upgrade of almost all upgradeable components in the autonomous driving domain, such as ADUUpdate (ADU itself upgrades MCU and SOC), LidarUpdate, RadarUpdate, etc.

[0115] In this embodiment, the OtaEngine upgrade file management is roughly as follows:

[0116] .├──bin

[0117] │├──ADU_MCU_UpgradePacket

[0118] │├──FF_Radar_UpgradePacket

[0119] │├──Front_Radar_UpgradePacket

[0120] │├──FR_Radar_UpgradePacket

[0121] │├──H2PU_MCU_UpgradePacket

[0122] │├──H2PU_SOC_UpgradePacket

[0123] │├──Lidar_UpgradePacket

[0124] │├──RL_Radar_UpgradePacket

[0125] │└──RR_Radar_UpgradePacket

[0126] ├──etc

[0127] │├──otaEngine_ADU_MCUUpdate.json

[0128] │├──otaEngine_FF_RadarUpdate.json

[0129] │├──otaEngine_Front_RadarUpdate.json

[0130] │├──otaEngine_FR_RadarUpdate.json

[0131] │├──otaEngine_H2PU_MCUUpdate.json

[0132] │├──otaEngine_H2PU_SOCUpdate.json

[0133] │├──otaEngine_LidarUpdate.json

[0134] │├──otaEngine_RL_RadarUpdate.json

[0135] │└──otaEngine_RR_RadarUpdate.json

[0136] └──manifest

[0137] The decryption and signature verification of the software update package will not be explained here. The Manifest file records which components in the current upgrade package can be upgraded and the corresponding version number. The bin folder includes the upgrade package files of the currently upgradeable components, and the etc folder stores the upgrade-related configuration files. The Manifest file and the bin folder are mainly obtained by decompression and signature verification from the cloud. The Etc file can be stored in a fixed location in the ADU or sent from the cloud. Considering that the current component models are basically unchanged and the flashing process remains unchanged, the Etc file can be fixedly stored in a specified location in the ADU. Among them, the unique configuration file OtaEngine_Update.json of this module defines the mapping relationship between components and flashing specification json files, component version information, etc. This file is obtained by retrieving the ECUid of the upgradeable components in the manifest. ECUid is the unique identifier of each component, and the mapping relationship between the flashing specification json file is established through ECUID.

[0138] The following will introduce the DataTransfer implementation process and its state machine in detail

[0139] The DataTransfer implementation process is as follows:

[0140] The SOC is equipped with an OTA engine; the OTA engine includes: a configuration file parsing component, an update package file parsing component, a UDS service component, a data transmission component, and an upgrade management component; the SOC transmits the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier and the update link corresponding to the target controller identifier for each target controller identifier, including:

[0141] (1) triggering an upgrade request corresponding to the target controller through the upgrade management component;

[0142] (2) Obtain the Doip communication connection parameters of the target controller, obtain the UDS service parameters, and the UDS flash process list through the configuration file parsing component; for example, obtain the Doip communication parameters according to the DoipReader interface of the JsonParse component, and obtain the UDS service parameters and the UDS flash process list according to the UdsServiceTableReader interface of the JsonParse component.

[0143] (3) Obtain the data transmission parameters of the software update package corresponding to the target controller through the configuration file parsing component; obtain the file transfer parameters according to the RequestDataTransferReader interface of the JsonParse component, and obtain the upgrade package file path and file name and other data transmission parameters.

[0144] (4) The software update package corresponding to the data transmission parameters is parsed through the update package file parsing component, and the data with discontinuous addresses are filled; UpdateFileParse parses the upgrade package file through the upgrade package file path and file name, and fills the data with discontinuous addresses. The default filling is 0xFF. The data segment is obtained and sent through the data transmission service, and the data volume is adjusted according to the ECU response.

[0145] (5) A Doip communication connection is established with the target controller according to the Doip parameters through the data transmission component, and the parsed software update package is transmitted to the target controller through the UDS service component according to the UDS flashing process.

[0146] In a preferred embodiment of the present application, before the above-mentioned steps of obtaining the Doip communication connection parameters of the target controller, obtaining the UDS service parameters, and the UDS flash process list through the configuration file parsing component, the method also includes: detecting through the data transmission component whether the current state of the vehicle meets the upgrade conditions and data transmission conditions; if so, continuing to execute the steps of obtaining the Doip communication connection parameters of the target controller, obtaining the UDS service parameters, and the UDS flash process list through the configuration file parsing component.

[0147] In a preferred embodiment of the present application, during the transmission of the software update package, the method further includes: detecting the Socket connection status or the data transmission response time in real time through the data transmission component; when it is determined that the Socket connection status is disconnected or the data transmission response time has timed out, continuing to execute the step of establishing a Doip communication connection with the target controller.

[0148] The following will introduce the OtaEngine module Transfer component state machine in detail. Figure 8 The state switching diagram of the Transfer component of the OtaEngine module shown in the figure mainly includes: default state, sending state, waiting state, response state, failure state, success state, etc. The state machine is enabled when the upgrade request is triggered.

[0149] Default state: When an upgrade request is triggered, the initial state is this state, in which the upgrade conditions and data transmission will be periodically checked to see if they are met, such as vehicle gear, vehicle speed, vehicle status, network bandwidth, remaining storage space capacity, network throughput, etc.

[0150] Sending state: When the data transmission conditions are met, it switches to this state. In this state, the UDS service will be sent in sequence according to the flashing process formulated in the specification (configured in the OtaEngine Json configuration file), that is, according to the configuration parameters set in the json file, the UDS service type or format is configured and the UDS service is sent.

[0151] Waiting state: This state is only switched from the sending state. This state will monitor the response of the service overtime and resend the mechanism, and detect the socket connection state at the same time to determine whether Doip reconnection is required. The determination method of Doip reconnection in the present invention is shown in Table 7:

[0152] Table 7

[0153]

[0154]

[0155] Currently, only reset requests and jump requests involve Doip reconnection issues. When other services detect disconnection in the waiting state, it is judged as a data transmission failure and jumps directly to the failure state. If the current service is a reset request or a jump request, it is necessary to determine whether a reconnection is required according to the rules in the above table. The ResetBeforeResponse and whether Reconnect is required (EcuReset Reconnect, JumpToBootReConnect) fields are set in the Json file according to the flashing specifications of the components. The state of the state machine when reconnecting is determined according to ResetBeforeResponse. Determine whether a reconnection is required based on the EcuResetReconnect and JumpToBootReConnect fields. The Doip reconnection process requires not only the establishment of a Socket connection, but also the Doip routing activation process.

[0156] Currently, this software supports reconnection in the waiting state and response state. All the conditions in the above table are met. For example: in the waiting state, the socket connection is disconnected, the current ECU reset request, ResetBeforeResponse in json is set to true and EcuReset Reconnect is also set to true, and the reconnection operation will be performed. If ResetBeforeResponse is set to False, the communication connection is abnormally disconnected and the data transmission mode is exited.

[0157] ·Response status: When receiving a positive response to the service request or a pending response, switch to the current status. If it is a positive response, it is necessary to determine whether it is a data transmission service and whether the transmission is completed. If it is a data transmission service and the transmission is not completed, keep the current UDS service as a data transmission service and switch the status to the sending status. Otherwise, the subsequent services will continue to be executed in sequence according to the Uds Service Table. If the current response is a pending response, the pending timeout monitoring mechanism will be started. Switch to the waiting state. Wait for a positive response.

[0158] Failed state: When receiving a negative response to the service request or receiving a timeout or file parsing failure, switch to the current state. In the current state, it will exit the upgrade mode. Return to upgrade, data transmission failure.

[0159] Successful state: When all services in the Uds Service Table are executed, jump to the current state, indicating that the data transfer is completed and exit the upgrade mode.

[0160] Based on the above-mentioned vehicle-mounted OTA software update system, the embodiment of the present application also provides an OTA software update system, see Figure 2 As shown, the OTA software update system includes: a cloud server and the vehicle-mounted OTA software update system as described in the first aspect; the cloud server is connected to the H2PU in the vehicle-mounted OTA software update system; the cloud server is used to send software update instructions to the H2PU, so that the H2PU forwards the software update instructions to the SOC in the vehicle-mounted OTA software update system to perform a subsequent software version update of at least one controller.

[0161] The vehicle-mounted OTA software update system and the OTA software update system provided in the embodiments of the present application have the following advantages:

[0162] Design of network communication links for upgrade interaction between components and controllers in the autonomous driving domain. Design and use of standard and universal OTAengine configuration files greatly reduces the development and debugging cycle. Use of file transfer greatly facilitates the reliable and secure transmission of files for Linux or QNX embedded systems. Supports full domain controller upgrades and improves the software iteration update rate. It can quickly adapt to the upgrade of new components in the domain without software development. The modular design of OTAengine can adapt to multiple embedded platforms and has good portability. OTAengine supports simultaneous upgrades of multiple devices, greatly shortening the upgrade time. Due to the use of OTAEngine configuration files, it has excellent scalability. Supports extended multi-data and multi-file transfer. Supports multi-platform executable file format parsing and executable file address filling.

[0163] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An OTA software update data transmission method, characterized in that: The method is applied to an OTA software update data transmission system; the system comprises: an autonomous driving domain controller ADU, a positioning controller H2PU, a driving monitoring system DMS and an environment monitoring controller; wherein the ADU comprises: a system-level controller SOC and a microcontroller MCU; the H2PU is connected to the SOC and the DMS respectively; the SOC is also connected to the MCU and the environment monitoring controller respectively; the MCU is also connected to the environment monitoring controller; the method comprises: The H2PU receives the software update instruction pushed by the cloud server, and forwards the software update instruction and the software update file carried by the software update instruction to the SOC; the software update file includes: at least one target controller identifier, a software update package corresponding to each target controller identifier, and a flashing process configuration file; The SOC transmits, for each target controller identifier, a software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier and the update link corresponding to the target controller identifier, so that the target controller performs a software version update; The SOC is equipped with an OTA engine; the OTA engine includes: a configuration file parsing component, an update package file parsing component, a UDS service component, a data transmission component, and an upgrade management component; The step of transmitting, by the SOC, for each target controller identifier, a software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier according to the flash process configuration file corresponding to the target controller identifier and the update link corresponding to the target controller identifier, includes: An upgrade request corresponding to the target controller is triggered through the upgrade management component; the Doip communication connection parameters, UDS service parameters and UDS flash writing process list of the target controller are obtained through the configuration file parsing component; the data transmission parameters of the software update package corresponding to the target controller are obtained through the configuration file parsing component; the software update package corresponding to the data transmission parameters is parsed through the update package file parsing component, and the data with discontinuous addresses is filled; a Doip communication connection is established to the target controller according to the Doip parameters through the data transmission component, and the parsed software update package is transmitted to the target controller through the UDS service component according to the UDS flash writing process.

2. The method according to claim 1, characterized in that Before the step of obtaining the Doip communication connection parameters of the target controller, obtaining the UDS service parameters, and the UDS flashing process list through the configuration file parsing component, the method further includes: The data transmission component is used to detect whether the current state of the vehicle meets the upgrade conditions and data transmission conditions; if so, continue to execute the steps of obtaining the Doip communication connection parameters of the target controller, obtaining the UDS service parameters, and the UDS flashing process list through the configuration file parsing component.

3. The method according to claim 1, characterized in that During the software update package transmission process, the method further includes: The data transmission component is used to detect the Socket connection status or the data transmission response time in real time; when it is determined that the Socket connection status is disconnected or the data transmission response time has timed out, the step of performing Doip communication connection on the target controller is continued.

4. The method according to claim 1, characterized in that: The generation process of the flash process configuration file corresponding to each target controller is as follows: For each of the target controllers, obtain the flash process configuration parameters corresponding to the target controller; import the flash process configuration parameters into a preset OTA software flash configuration template to generate a flash process configuration file corresponding to the controller.

5. The method according to claim 1, characterized in that The flash process configuration file corresponding to each of the target controllers includes: general configuration information, communication protocol configuration information, data file transmission configuration information, and process service configuration information.

6. The method according to claim 1, characterized in that The target controller is a first-class controller; the first-class controller includes the H2PU or the laser radar in the environmental monitoring controller, and the update link corresponding to the target controller is: SOC-first-class controller; The step of transmitting, by the SOC according to the flash process configuration file corresponding to the target controller identifier and according to the update link corresponding to the target controller identifier, the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier includes: The SOC verifies the signature of the first software update package corresponding to the first type of controller, and transmits the first software update package to the first type of controller according to the flash process configuration file corresponding to the first type of controller.

7. The method according to claim 1, characterized in that The target controller is the DMS; the update link corresponding to the target controller is: SOC-H2PU-DMS; The step of transmitting, by the SOC according to the flash process configuration file corresponding to the target controller identifier and according to the update link corresponding to the target controller identifier, the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier includes: The SOC verifies the signature of the DMS software update package corresponding to the DMS, and sends the DMS software update package to the H2PU according to the DMS flash process configuration file corresponding to the DMS, so that the H2PU forwards the DMS software update package to the DMS as a DOIP gateway.

8. The method according to claim 1, characterized in that: The target controller is a second-class controller; the second-class controller includes a millimeter-wave radar or a multi-function camera in the environment monitoring controller, and the update link corresponding to the target controller is: SOC-MCU-second-class controller; The step of transmitting, by the SOC according to the flash process configuration file corresponding to the target controller identifier and according to the update link corresponding to the target controller identifier, the software update package corresponding to the target controller identifier to the target controller corresponding to the target controller identifier includes: The SOC verifies the signature of the second software update package corresponding to the second type of controller, and sends the second software update package to the MCU according to the second flash process configuration file corresponding to the second type of controller, so that the MCU acts as a DOIP gateway to forward the second software update package to the second type of controller.

9. An OTA software update data transmission system, characterized in that: The OTA software update data transmission system includes: an autonomous driving domain controller ADU, a positioning controller H2PU, a driving monitoring system DMS and an environmental monitoring controller; wherein, the ADU includes: a system-level controller SOC and a microcontroller MCU; the H2PU is connected to the SOC and DMS respectively; the SOC is also connected to the MCU and the environmental monitoring controller respectively; the MCU is also connected to the environmental monitoring controller; the OTA software update data transmission system is used to execute the method described in any one of claims 1-8.

Images