A line flash service method and server based on SOVD protocol

Abstract

This application discloses a wire-brush service method and server based on the SOVD protocol. The wire-brush service method runs on a wire-brush server in an HPC, receives a wire-brush compressed package uploaded by a client through a first SOVD API, and determines the ID of the wire-brush compressed package; receives a wire-brush request sent by a client through the first SOVD API; in response to the wire-brush request, calls an unpacking tool, uses the unpacking tool to parse the wire-brush compressed package, and obtains a wire-brush file and a wire-brush sequence file; the wire-brush file includes a wire-brush object, the type of the wire-brush compressed package, and at least one compressed firmware; the wire-brush sequence file includes a wire-brush sequence for each compressed firmware; uses the unpacking tool to perform verification based on the ID, wire-brush file, and / or wire-brush sequence file; if the verification passes, the wire-brush sequence for each compressed firmware is performed. This application can flexibly select the flash object and flash type, and perform wire-brush according to the flash sequence, ensuring the orderliness and correctness of the flash process.

Description

Technical Field

[0001] The present application belongs to the technical field of smart electric vehicle upgrades, and specifically relates to a wire-flash service method and server based on the SOVD protocol. Background Art

[0002] With the advancement of smart electric vehicle technology, their domain controllers (HPCs) will utilize CPUs with multi-core processor architectures (A-core and M-core) to centrally control the powertrain, chassis, body, cabin, and autonomous driving domains. In vehicles, HPC typically refers to a high-performance computer (HPC). It is a core component of modern automotive electrical and electronic architectures, playing a particularly important role in advanced automated driving (ADAS) and advanced smart electric vehicles. HPC consolidates functions traditionally distributed across multiple electronic control units (ECUs) into a single high-performance computing unit. In traditional automotive architectures, independent ECUs handle functions such as the engine, braking, and air conditioning systems. However, as vehicle functionality increases, this distributed architecture becomes inefficient. HPC utilizes a centralized architecture, consolidating the logical functions of numerous ECUs onto a single HPC. The HPC integrates high-performance ARM Cortex A-core processors (A-cortex) and ARM Cortex M-core processors (M-cortex) to process the data flows from these numerous ECUs. This not only improves system efficiency but also reduces overall vehicle hardware complexity and cost.

[0003] SOVD (Scalable Service-Oriented Vehicle Diagnostics) is a service-oriented diagnostics architecture for future vehicles launched by the Association for Standardization of Automation and Measuring Systems (ASAM), designed to address evolving vehicle diagnostic needs. The SOVD updates API, one of SOVD's standardized diagnostic service interfaces, manages vehicle software and firmware updates, ensuring that updates can be received and installed to improve functionality, fix vulnerabilities, or optimize performance. Updates can be received over-the-air (OTA) or locally.

[0004] The wire-flash solution for the ECU in the electronic and electrical architecture of traditional automobiles mostly uses the UDS protocol to flash the ECU. The flash sequence is single and does not support flashing software and firmware for multi-core processors, nor does it support multiple flash package types. Summary of the Invention

[0005] One of the technical purposes of this application is to address the technical problem that the wire-flash solution for the electronic and electrical architecture ECU in traditional automobiles mostly uses the UDS protocol to flash the ECU, has a single flash sequence, does not support the flashing of software and firmware for multi-core processors, and does not support multiple flash package types. A wire-flash service method and server based on the SOVD protocol are provided.

[0006] In order to achieve the above technical objectives, this application adopts the following technical solutions.

[0007] In a first aspect, an embodiment of the present application provides a line refresh service method based on the SOVD protocol, wherein the line refresh service method runs on a line refresh server based on the SOVD protocol in an HPC, and the line refresh service method includes:

[0008] Receive a line brush compressed package uploaded by a client through a first SOVD API, and determine an ID of the line brush compressed package;

[0009] receiving a flash request from the client via the first SOVD API; in response to the flash request, invoking a decompression tool, parsing the flash compressed package using the decompression tool to obtain a flash file and a flash sequence file; the flash file includes a flash object, a flash compressed package type, and at least one compressed firmware; the flash sequence file includes a flash sequence for each compressed firmware;

[0010] Using the unpacking tool to perform verification based on the ID, line brush file and / or line brush sequence file;

[0011] If the unpacking tool passes the verification, the flashing is performed according to the flashing sequence of each compressed firmware based on the flashing object, the requested flashing type and the compressed firmware.

[0012] In a second aspect, an embodiment of the present application provides a line brush server based on the SOVD protocol, wherein the line brush server runs in an HPC, and the server includes:

[0013] The SOVD servlet library is configured to receive a line-brush compressed package uploaded by a client through a first SOVD API and determine the ID of the line-brush compressed package; receive a line-brush request sent by the client through the first SOVD API; and call a decompression tool in response to the line-brush request;

[0014] The unpacking tool is used to parse the line brush compressed package to obtain a line brush file and a line brush sequence file; the line brush file includes a line brush object, a line brush compressed package type and at least one compressed firmware; the line brush sequence file includes a line brush sequence of each compressed firmware; verification is performed based on the ID, line brush file and / or line brush sequence file;

[0015] A wire flash tool is used to flash the compressed firmware according to the wire flash sequence based on the wire flash object, the requested wire flash type and the compressed firmware if the unpacking tool passes the verification.

[0016] Compared with the existing technology, the line flash service method based on the SOVD protocol provided in the embodiment of the present application has the following beneficial technical effects: utilizing the characteristics of the RESTful API, the line flash compressed package transmission between the client and the HPC can be realized in a standardized and concise manner; the user of the client only needs to simply use the SOVD API to realize the line flash of the HPC, and does not need to care about the complex flashing process and logic of the HPC underlying multi-core; when responding to the line flash request, it can be based on the line flash object, the requested line flash type and the compressed firmware, and the flash can be performed according to the line flash sequence of the compressed firmware. This method can flexibly select the flash object and flash type according to different requests and actual conditions, and strictly operate according to the preset line flash sequence, which ensures the orderliness and correctness of the flash process, improves the success rate and efficiency of the flash, and reduces equipment abnormalities caused by problems such as incorrect flash sequence.

[0017] The line refresh server based on the SOVD protocol provided in the embodiment of the present application has the same beneficial technical effects as the above-mentioned line refresh service method based on the SOVD protocol, which will not be elaborated on. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are for illustrative purposes only and are not intended to limit the scope of the present application in any way. In addition, the shapes and proportional dimensions of the components in the drawings are only schematic and are used to help understand the present application. They do not specifically limit the shapes and proportional dimensions of the components of the present application. Those skilled in the art can select various possible shapes and proportional dimensions to implement the present application according to the specific circumstances under the guidance of the present application. In the drawings:

[0019] Figure 1 A flowchart of a line brushing service method based on the SOVD protocol provided in an embodiment of the present application;

[0020] Figure 2 This is a schematic diagram of the HPC structure where the online refresh server is located in the embodiment of this application;

[0021] Figure 3 Schematic diagram of multiple HPC application scenarios in the embodiments of this application;

[0022] Figure 4 This is a flow chart of the interaction between the online brush server and the client in the embodiment of the present application;

[0023] Figure 5 A schematic diagram of the structure of a line-brush server based on the SOVD protocol provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0025] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more features.

[0026] This embodiment provides a line brush service method based on the SOVD protocol, which runs on a line brush server based on the SOVD protocol in HPC. Figure 1 As shown, the line brushing service method includes the following steps:

[0027] Step S1: receiving a line-brush compressed package uploaded by a client through a first SOVD API, and determining the ID of the line-brush compressed package;

[0028] Step S2: Receive a flash request from the client via the first SOVD API; in response to the flash request, call an unpacking tool to parse the flash compressed package to obtain a flash file and a flash sequence file; the flash file includes a flash object, a flash compressed package type, and at least one compressed firmware; the flash sequence file includes a flash sequence for each compressed firmware;

[0029] Step S3: Use the unpacking tool to verify according to the ID, line brush file and / or line brush sequence file;

[0030] Step S4: If the unpacking tool passes the verification, the flashing sequence of each compressed firmware is performed based on the flashing object, the requested flashing type and the compressed firmware.

[0031] In some embodiments, as Figure 2As shown in the figure, the line flash server based on the SOVD protocol (hereinafter referred to as the "line flash server") is set on the HPC. A single HPC has two CPUs: an A core (A cortex) and an M core (M cortex). The Acortex runs AutoSar AP related applications, and the M cortex runs AutoSar CP related applications. The line flash server runs on the A cortex as an application of AutoSar AP. Figure 2 As shown, the online flash server can integrate the SOVD servlet library, unpacking tools and flashing tools (which can include M cortex flashing tools and A cortex firmware / AutoSar AP application flashing tools).

[0032] In some embodiments, the line flash server also includes a version acquisition tool, specifically including an M cortex version acquisition tool and an A cortex firmware / AutoSar AP application version acquisition tool.

[0033] In some embodiments, the line brushing object includes line brushing the M core, line brushing the A core, or line brushing the M core and the A core at the same time. Figure 2 Lock, HPC is connected to ECU, and the wire flash object also includes wire flashing of ECU.

[0034] In this embodiment, A cortex operates in a primary and backup partition mode. Each partition includes a boot partition, a rootfs partition, and a dedicated partition for the AusoSar AP software platform. When the HPC is running, only one of these partitions is active. The flash server runs on an active partition in the primary and backup partitions. By integrating the SOVD servlet library, a flash server is implemented.

[0035] The restful API provided by the line refresh server to the outside world may include: the first SOVD API, which is a public SOVD API that provides SOVD updates. The defined methods include GET or POST / updates. The GET method is used by the (SOVD http) client to obtain the ID (update-package-id) of the line refresh compressed package to be updated. The POST method is used to upload the line refresh compressed package to be updated to the line refresh server. The PUT method is used to execute the line refresh task.

[0036] In some embodiments, the restful API provided by the online refresh server also includes a second SOVD API, which is a public SOVD API that provides running status. The defined method includes GET / {entity-path} / data / alive_status, which is used to determine whether the online refresh server is online.

[0037] As an example, before receiving the line-brush compressed package uploaded by the client through the first SOVD API, it also includes: receiving the line-brush server status detection request sent by the client through the second SOVD API, and returning the line-brush server status in response to the line-brush server status detection request, so that the client uploads the line-brush compressed package when the line-brush server is online.

[0038] Some embodiments also include a third SOVD API, which is used to provide a public RESTful API for obtaining the HPC / ECU firmware version. The defined methods include: GET and PUT / {entity-path} / current_versions. The PUT method is used to transmit the configuration information of the firmware version to the flash server, and the GET method obtains the HPC / ECU firmware version from the SOVD http server.

[0039] As an example, the line flash service method also includes receiving a client request through a third SOVD API: / {entity-path} / current_versions, sending an HPC / ECU version information response to the client, and storing the configuration information; receiving a program version information request sent by the client through the third SOVD API, responding to the program version information request, obtaining the program version information according to the configuration information, and returning the program version information to the client, so that the client determines the line flash compressed package that needs to be uploaded according to the program version information.

[0040] Some embodiments further include a fourth SOVD API, which is a public SOVD API for obtaining software update logs, and the defined methods include: GET / {entity-path} / logs / entries?severity=error, which is used to obtain log information with a log level of error from a line flash server based on the SOVD protocol.

[0041] Some embodiments further include a fifth SOVD API, which is a public SOVD API for providing a reboot status, and the defined methods include: GET / {entity-path} / data / reboot, for notifying the SOVD client that the HPC has executed a reboot operation.

[0042] As an example, the online flash service method further includes sending a log message of the flash failure to the client through the fourth SOVD API if the flash fails, otherwise returning to the client whether the HPC is restarted after the flash is successful through the fifth SOVD API.

[0043] In some embodiments, the request line refresh type of the line refresh request includes a first line refresh request and a second line refresh request. The first line refresh request includes an execute automatic line refresh request, and the second refresh request message includes a prepare manual line refresh request and an execute manual line refresh request sent successively.

[0044] As an example, the first SOVD API provides two update methods: automatic and manual. The defined methods include: automatic update method (PUT / updates / {update-package-id} / automated); manual update method (PUT / updates / {update-package-id} / prepare); and execution method (PUT / updates / {update-package-id} / execute).

[0045] In some embodiments, the intelligent vehicle system may have multiple HPCs, and the wired flash servers may be distributed across the multiple HPCs. Each HPC has two CPUs, and the wired flash servers on each HPC are identical.

[0046] Take the example of the line flash server distributed on two HPCs. Figure 3 and Figure 4 For example, Figure 3 The example client shown is a Windows PC host computer, which is connected to the smart car through the OBD interface.

[0047] Reference Figure 3 and Figure 4 The process of the line flash service method based on the SOVD protocol is as follows:

[0048] (1) The client configures key parameter information such as line flash object, line flash sequence and compressed firmware. The client configures the IP and port of multiple HPCs to be flashed (such as: base_url: http: / / HPC_IP:Port The online flash server can initiate a request to obtain the secure partition directory from the HPC where it is located and obtain a secure partition directory response.

[0049] The client executes GET / {entity-path} / data / alive_status (for example, GET / {base_url} / acos / v1 / apps / ac_updater / data / alive_status) to check whether the flash server used for flashing on different HPCs is running online. If so, proceed to the next step. Otherwise, it is considered offline and exits. You need to troubleshoot the cause of the connection failure at the network and hardware layers.

[0050] (2) The client executes PUT / {entity-path} / current_versions to send the configuration information required to obtain the program (firmware and software) version information of A cortex, Mcortex or ECU to the flash server. After receiving the request, the flash server parses the configuration information and stores it in the current memory. The client then executes GET / {entity-path} / current_versions to obtain the program version information request for specific program version information. After receiving the program version information request, the flash server uses the previously obtained configuration information to call the A cortex version acquisition tool to obtain the firmware version information of the primary and backup partitions on A cortex, call the A cortex version acquisition tool to obtain the software version information of the AutoSar AP running on A cortex, and call the Mc cortex version acquisition tool to obtain the firmware version information of Mc cortex and ECU. If the acquisition is successful, the acquired program version information is returned to the client and the next step is executed. Otherwise, the server exits and needs to troubleshoot the cause of the failure to obtain the A cortex firmware version information from the hardware layer.

[0051] (3) The client selects the package to be flashed online, calls the flash package packaging tool, packages it into a flash compression package of a predefined type (FOTA type package, Single UDS type package, Single ACP type package, FOTA_FULL type package or Zip UDS type package), and calls POST / updates (such as POST / {base_url} / acos / v1 / ac_updater / updates) to upload a packaged flash compression package to the flash server. If the upload is successful, proceed to the next step, otherwise exit and check the reason why the flash cannot be uploaded from the hardware layer.

[0052] (4) After receiving the request, the online flash server saves the online flash compressed package in a secure storage partition. If the upload is successful, the user can proceed to the next step, otherwise, exit.

[0053] (5) The client executes GET / updates?origin=proximity to obtain the ID of the compressed package just uploaded, which is recorded as {update_package_id}.

[0054] If the client wants to execute the SOVD automatic flash mode, execute PUT / updates / {update-package-id} / automated (such as PUT / / updates / {base_url} / acos / v1 / ac_updater / updates / {update_package_id} / automated). After the flash server receives the automatic flash request, it calls the unpacking tool to decompress the uploaded flash package, checks the ID of the actual flash package, the flash file, and / or the flash sequence file (manifest file) to see if they exist, and checks whether the actual flash file is complete. If any information is incorrect, it exits. If all information is correct, the flash server parses the contents of the flash sequence file. If it fails, it exits without flashing, and the client can execute / {entity-path} / logs / entries?severity=error to obtain the failure log. Otherwise, the flash server calls the unpacking tool to parse the flash sequence file to determine the type of the flash package. If it is FOTA type, it executes Acortex flash. If it is single If the UDS type is used, the M Cortex or ECU is flashed according to the configuration. If the zip UDS type is used, the flashing is performed in sequence according to the configuration. If the flashing fails, execute GET / {entity-path} / logs / entries?severity=error to obtain the flashing failure log. Otherwise, the client executes GET / {entity-path} / data / reboot to determine whether the HPC is restarted after the flashing is successful, and then proceed to the next step.

[0055] If the client wants to execute the SOVD manual flash mode, it first sends a prepare request (PUT / updates / {update-package-id} / prepare) and then sends a execute request (PUT / updates / {update-package-id} / execute). After receiving the / updates / {update-package-id} / prepare request, the flash server calls the decompression tool to decompress the uploaded flash package, checks the existence of the actual flash file and the flash sequence file, and checks the integrity of the actual flash file. If any information is incorrect, the server exits. If all information is correct, the flash server parses the contents of the flash sequence file. If the verification fails, the server exits without flashing. The client executes / {entity-path} / logs / entries?severity=error to obtain the failure log. Otherwise, the verification is successful, and the flash server receives PUT / updates / {update-package-id} / execute. The flash server uses the unpacking tool to parse the flash sequence file content to determine the type of the flash compression package. If it is FOTA type, it executes the flash of A cortex. If it is single UDS type, it flashes M cortex or ECU according to the configuration. If it is zip UDS type, it flashes in sequence according to the configuration. If the flash fails, it executes GET / {entity-path} / logs / entries?severity=error to obtain the flash failure log. Otherwise, if the flash is successful, the status result is reported as completed and the progress is 100. Otherwise, the status result is reported as failed and the progress is 100. If the flash is successful, the flash server sets the restart flag in the response of {base_url} / acos / v1 / ac_updater / data / reboot to true, and the HPC calls the reboot command to restart. If the flash fails, the online flash server sets the reboot flag in the response to {base_url} / acos / v1 / apps / ac_updater / data / reboot to false, and the HPC does not reboot.

[0056] (6) The client executes GET / updates / {update_package_id} / status to obtain the flashing progress of the online flashing server. If the flashing is successful, the online flashing server sets the flashing status to completed, the flashing progress to 100, and returns the flashing response and progress response to the client. Otherwise, it is a failure. If successful, the client then executes GET {entity-path} / data / reboot to obtain the restart status of the HPC / ECU. The online flashing server executes the restart HPC / ECU operation. If the execution is successful, the restart flag of the request response returned to the client is true, then the flashing is considered successful, otherwise it is a failure.

[0057] In a specific embodiment, the SOVD protocol-based line flash service method can support the following packet types:

[0058] FOTA type package, used to flash A cortex firmware.

[0059] Single UDS type package, used to flash the M cortex and ECU single firmware.

[0060] Single ACP type package, used to flash the A cortex AutoSar AP application software.

[0061] FOTA_FULL type package, used to flash A cortex and M cortex firmware.

[0062] Zip UDS type package, used to flash multiple firmware of M cortex and ECU.

[0063] Supported line brush mode types

[0064] In the automatic online flash mode based on SOVD, execute PUT / updates / {update-package-id} / automated to flash.

[0065] In manual online flash mode based on SOVD, execute the PUT / updates / {update-package-id} / prepare operation successfully before executing the PUT / updates / {update-package-id} / execute operation to flash the package.

[0066] The SOVD protocol-based online flashing service method provided in this application embodiment has multiple flashing strategies. It supports not only flashing traditional ECUs, but also flashing HPC A cortex and M cortex software and firmware. Users of this method only need to use the SOVD API to flash the HPC and ECU online, thereby upgrading the relevant firmware or software versions. This method implements the online flashing function through an online flashing server running on the HPC.

[0067] In some embodiments, the wire flash server runs distributedly on multiple HPCs in the vehicle, and a wire flash server backend program runs on each HPC. With the help of OBD (On-Board Diagnostics, the full Chinese name is vehicle automatic diagnostic system), users use the SOVD API to connect to multiple HPCs in the vehicle to flash devices in batches. Compared with existing traditional wire flash solutions, this method reduces the difficulty of flashing and improves the efficiency of flashing.

[0068] Based on the same inventive concept as the line brushing service method based on the SOVD protocol provided in the above embodiment, the embodiment of the present application also provides a line brushing server based on the SOVD protocol, such as Figure 5 As shown, the wire-brush server runs in the HPC, and the server includes the SOVD servlet library, the unpacking tool, and the wire-brush tool.

[0069] The SOVD servlet library is used to receive the line brush compressed package uploaded by the client through the first SOVD API, determine the ID of the line brush compressed package; receive the line brush request sent by the client through the first SOVD API; and call the unpacking tool in response to the line brush request.

[0070] The unpacking tool is used to parse the flash compression package to obtain the flash file and flash sequence file; the flash file includes the flash object, the type of the flash compression package and at least one compressed firmware; the flash sequence file includes the flash sequence of each compressed firmware; verification is performed based on the ID, flash file and / or flash sequence file.

[0071] The wire flash tool is used to flash the compressed firmware according to the wire flash sequence based on the wire flash object, requested wire flash type and compressed firmware if the unpacking tool passes the verification.

[0072] Furthermore, the line flash server also includes a version acquisition tool; the SOVD servlet library is also used to receive configuration information sent by the client through the third SOVDAPI and store the configuration information; receive a program version information request sent by the client through the third SOVD API; the version acquisition tool is used to respond to the program version information request and obtain the program version information according to the configuration information; the SOVD servlet library is also used to return the program version information to the client, so that the client can determine the line flash compressed package that needs to be uploaded based on the program version information.

[0073] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0074] Based on the current electronic and electrical architecture of electric vehicle HPC, the line flash server based on the SOVD protocol provided in the embodiment of this application is adopted. Users only need to simply use the SOVDl API to realize the line flash of HPC, without having to worry about the complex flashing process and logic of the HPC underlying A cortex and M cortex.

[0075] By selectively connecting to one or more HPC line flash servers through the SOVD API, you can flash a single device or batches of devices. Compared with existing traditional line flash solutions, this solution reduces the difficulty of flashing and improves the efficiency of flashing.

[0076] The above is a detailed introduction to the line brush service and server based on the SOVD protocol provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the concept of this application and should not be understood as limiting the scope of protection of this application.

Claims

1. A line brushing service method based on SOVD protocol, characterized in that: The line flash service method runs on a line flash server based on the SOVD protocol in the HPC, the HPC includes an M core and an A core and is connected to the ECU, and the line flash service method includes: Receive the line-brush compressed package uploaded by the client through the first SOVD API, and determine the ID of the line-brush compressed package; the type of the line-brush compressed package includes FOTA type, Single UDS type, Single ACP type, FOTA_FULL type and Zip UDS type, among which the FOTA type is used to flash the A-core firmware, the Single UDS type is used to flash the M-core and ECU single firmware, and the Zip UDS type is used to flash multiple firmware of the M-core and ECU; receiving a flash request sent by the client via the first SOVD API; in response to the flash request, invoking a decompression tool, parsing the flash compressed package using the decompression tool to obtain a flash file and a flash sequence file; the flash file includes a flash object, a flash compressed package type, and at least one compressed firmware; the flash object includes flashing an M core, an A core, or an ECU; the flash sequence file includes a flash sequence for each compressed firmware; Using the unpacking tool to perform verification based on the ID, line brush file and / or line brush sequence file; If the unpacking tool passes the verification, the flashing is performed according to the flashing sequence of each compressed firmware based on the flashing object, the requested flashing type and the compressed firmware; the requested flashing type of the flashing request includes a first flashing request and a second flashing request, the first flashing request includes an automatic flashing request, and the second flashing request message includes a prepare manual flashing request and an execute manual flashing request sent successively.

2. The line brushing service method based on the SOVD protocol according to claim 1 is characterized in that: Before receiving the line-brush compressed package uploaded by the client through the first SOVDAPI, the following steps are also included: The second SOVD API receives a line refresh server status detection request sent by the client, and returns the line refresh server status in response to the line refresh server status detection request, so that the client uploads the line refresh compressed package when the line refresh server is online.

3. The line brushing service method based on the SOVD protocol according to claim 2 is characterized in that: The method further comprises: receiving, through a third SOVD API, configuration information sent by the client, and storing the configuration information; The program version information request sent by the client is received through the third SOVD API, and in response to the program version information request, the program version information is obtained according to the configuration information, and the program version information is returned to the client, so that the client determines the line brush compressed package that needs to be uploaded according to the program version information.

4. The line brushing service method based on the SOVD protocol according to claim 1 is characterized in that: The method further includes: if the flashing fails, sending log information of the flashing failure to the client through the fourth SOVD API; otherwise, returning information to the client through the fifth SOVD API indicating whether the HPC is restarted after the flashing succeeds.

5. The line brushing service method based on SOVD protocol according to claim 1 is characterized in that: The FOTA type of line brush compression package is used to flash the A core firmware, the Single UDS type of line brush compression package is used to flash the M core and ECU single firmware, the Single ACP type of line brush compression package is used to flash the A core AutoSar AP application software, the FOTA_FULL type of line brush compression package is used to flash the A core and M core firmware, and the Zip UDS type of line brush compression package is used to flash the M core and multiple firmware of the ECU.

6. A line brush server based on SOVD protocol, characterized in that: The line flash server runs in the HPC, which includes an M core and an A core and is connected to the ECU. The server includes: The SOVD servlet library is configured to receive a flash compression package uploaded by a client through a first SOVD API, determine the ID of the flash compression package, and select a type of the flash compression package, including a FOTA type, a Single UDS type, a Single ACP type, a FOTA_FULL type, and a Zip UDS type. The FOTA type is used to flash the A-core firmware, the Single UDS type is used to flash the M-core and the ECU single firmware, and the Zip UDS type is used to flash multiple firmwares of the M-core and the ECU. The library receives a flash request from the client through the first SOVD API, and calls an unpacking tool in response to the flash request. The unpacking tool is used to parse the flash compression package to obtain a flash file and a flash sequence file; the flash file includes a flash object, a flash compression package type, and at least one compressed firmware; the flash object includes flashing an M core, an A core, or an ECU; the flash sequence file includes a flash sequence for each compressed firmware; verification is performed based on the ID, flash file, and / or flash sequence file; A flashing tool, configured to flash the compressed firmware according to the flashing sequence of each compressed firmware based on the flashing object, the requested flashing type, and the compressed firmware, if the unpacking tool passes verification; The request line refresh type of the line refresh request includes a first line refresh request and a second line refresh request, the first line refresh request includes an execute automatic line refresh request, and the second line refresh request message includes a prepare manual line refresh request and an execute manual line refresh request sent successively.

7. The line brush server based on SOVD protocol according to claim 6, characterized in that: The online flash server also includes a version acquisition tool; The SOVD servlet library is further configured to receive configuration information sent by the client through a third SOVD API and store the configuration information; receive a program version information request sent by the client through the third SOVD API; A version acquisition tool, configured to obtain program version information according to the configuration information in response to the program version information request; The SOVD servlet library is further configured to return the program version information to the client, so that the client can determine the line-brush compressed package that needs to be uploaded according to the program version information.

Images