SOVD protocol-based line brush service method and server

Abstract

The invention discloses a line brush service method and server based on an SOVD protocol, the line brush service method is operated in a line brush server in an HPC, a line brush compressed package uploaded by a client is received through a first SOVD API, and the ID of the line brush compressed package is determined; receiving a line brushing request sent by the client through the first SOVD API; in response to the line brush request, calling an unpacking tool, and analyzing the line brush compressed package by using the unpacking tool to obtain a line brush file and a line brush sequence file; the line brush file comprises a line brush object, the type of a line brush compressed package and at least one compressed firmware; the line brush sequence file comprises a line brush sequence of each compressed firmware; the unpacking tool is used for verification according to the ID, the line brush file and / or the line brush sequence file; and if yes, flashing according to the line brush sequence of each compressed firmware. According to the method and the device, the flashing object and the flashing type can be flexibly selected, and line brushing is performed according to the line brushing sequence, so that the orderliness and correctness of the flashing process are ensured.

Description

Technical Field

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

[0002] With the development of smart electric vehicle technology, the domain controller HPC of smart electric vehicles will use a multi-core processor architecture CPU (A core and M core) to centrally control the power domain, chassis domain, body domain, cockpit domain, and autonomous driving domain. HPC in vehicles usually refers to High-Performance Computer, which is a core component in modern automotive electronic and electrical architecture, especially in advanced autonomous driving (ADAS) and advanced smart electric vehicles. HPC integrates the functions that are traditionally scattered in multiple electronic control units ECU into a high-performance computing unit. In traditional automotive architecture, the engine system, braking system, air conditioning system, etc. are handled by independent ECUs, but with the increase in vehicle function complexity, the traditional distributed architecture becomes somewhat inefficient. HPC adopts a centralized architecture to integrate the logical functions of a large number of ECUs into one HPC, which integrates high-performance arm cortex A core processors (A cortex) and arm cortexM core processors (M cortex) to process the data streams of a large number of ECUs. This not only improves system efficiency, but also reduces the hardware complexity and cost of the entire vehicle.

[0003] SOVD (Scalable service-oriented vehicle diagnostics) is a service-oriented diagnostic architecture for future vehicles launched by ASAM (Association for Standardisation of Automation and Measuring Systems) to cope with changes in vehicle diagnostic requirements. SOVD updates API is one of the standardized diagnostic service interfaces of SOVD, which involves the update management of vehicle software and firmware, ensuring that the vehicle can pass and install updates to improve functionality, fix vulnerabilities or optimize performance. Receive OTA or local mode.

[0004] Most of the wire-flash solutions for ECUs in the electronic and electrical architecture of traditional cars use the UDS protocol to flash the ECU. The flashing sequence is single and does not support flashing of software and firmware for multi-core processors or multiple flashing package types. Summary of the invention

[0005] One of the technical purposes of the present application is to provide a wire-flash service method and server based on the SOVD protocol for the electronic and electrical architecture ECU of traditional automobiles, which mostly uses the UDS protocol to flash the ECU with a single flash sequence and does not support the flashing of software and firmware for multi-core processors or a variety of flash package types.

[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 brushing service method based on the SOVD protocol, wherein the line brushing service method runs on a line brushing server based on the SOVD protocol in the HPC, and the line brushing service method includes: Receiving a line-brush compressed package uploaded by a client through a first SOVD API, and determining an ID of the line-brush compressed package; Receiving a wire brush request sent by the client through the first SOVD API; in response to the wire brush request, calling an unpacking tool, using the unpacking tool to parse the wire brush compressed package to obtain a wire brush file and a wire brush sequence file; the wire brush file includes a wire brush object, a wire brush compressed package type and at least one compressed firmware; the wire brush sequence file includes a wire brush sequence of each compressed firmware; Using the unpacking tool to perform verification according to the ID, the line brush file and / or the 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.

[0008] 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 the HPC, and the server includes: The SOVD servlet library is used to receive the line brushing compressed package uploaded by the client through the first SOVD API, determine the ID of the line brushing compressed package; receive the line brushing request sent by the client through the first SOVD API; and call the unpacking tool in response to the line brushing request; The unpacking tool is used to parse the line brush compressed package to obtain the line brush file and the line brush sequence file; the line brush file includes the line brush object, the type of the line brush compressed package and at least one compressed firmware; the line brush sequence file includes the line brush sequence of each compressed firmware; verification is performed according to the ID, the line brush file and / or the line brush sequence file; 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.

[0009] Compared with the prior art, the wire-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 wire-flash compressed package transmission between the client and the HPC can be realized in a standardized and concise manner; the client user only needs to simply use the SOVD API to realize the wire-flash of the HPC, without having to worry about the complex flashing process and logic of the HPC underlying multi-core; when responding to a wire-flash request, it can be based on the wire-flash object, the requested wire-flash type and the compressed firmware, and the wire-flash sequence of the compressed firmware can be used for flashing. This method can flexibly select the flashing object and the flashing type according to different requests and actual conditions, and strictly operate according to the preset wire-flash sequence, thereby ensuring the orderliness and correctness of the flashing process, improving the success rate and efficiency of the flashing, and reducing equipment abnormalities caused by problems such as incorrect flashing sequence.

[0010] 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

[0011] The drawings described herein are for explanation 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 for illustration purposes 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. Under the guidance of the present application, those skilled in the art can select various possible shapes and proportional dimensions to implement the present application according to specific circumstances. In the drawings: Figure 1 A schematic diagram of the process flow of the line brushing service method based on the SOVD protocol provided in an embodiment of the present application; Figure 2 This is a schematic diagram of the HPC structure where the online refresh server is located in the embodiment of the present application; Figure 3 Schematic diagram of multiple HPC application scenarios in the embodiments of this application; 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; 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

[0012] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only 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 this field without creative work should fall within the scope of protection of this application.

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

[0014] This embodiment provides a line refresh service method based on the SOVD protocol, and the line refresh service method runs on a line refresh server based on the SOVD protocol in the HPC. Figure 1 As shown, the line brushing service method includes the following steps: Step S1: receiving a line-brush compressed package uploaded by a client through a first SOVD API, and determining an ID of the line-brush compressed package; Step S2: receiving a line brush request sent by a client through a first SOVD API; in response to the line brush request, calling an unpacking tool, parsing the line brush compressed package using the unpacking tool, and obtaining a line brush file and a line brush sequence file; the line brush file includes a line brush object, a type of the line brush compressed package, and at least one compressed firmware; the line brush sequence file includes a line brush sequence of each compressed firmware; Step S3: Use the unpacking tool to verify according to the ID, line brush file and / or line brush sequence file; Step S4: If the unpacking tool passes the verification, the flashing sequence of each compressed firmware is used to flash the compressed firmware based on the flashing object, the requested flashing type and the compressed firmware.

[0015] In some embodiments, Figure 2 As 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. There are two CPUs in a single HPC: 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 2As shown, the line 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).

[0016] 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.

[0017] In an embodiment, 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.

[0018] In the embodiment, A cortex runs in the main and backup partition mode, each partition includes a boot partition, a rootfs partition and a partition dedicated to the AusoSar AP software platform. When the HPC is running, only one of the partitions will be run, and the line flash server runs on an active partition in the main and backup partitions. By integrating the SOVD servlet library, a line flash server is realized.

[0019] 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.

[0020] 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 the running status. The defined method includes GET / {entity-path} / data / alive_status, which is used to determine whether the online refresh server is online.

[0021] As an example, before receiving the line refresh compressed package uploaded by the client through the first SOVD API, it also includes: receiving the line refresh server status detection request sent by the client through the second SOVD API, and returning 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 in an online state.

[0022] 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 line flash server, and the GET method obtains the HPC / ECU firmware version from the SOVD http server.

[0023] 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 compression package that needs to be uploaded according to the program version information.

[0024] 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.

[0025] 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, which is used to notify the SOVD client that the HPC has executed a reboot operation.

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

[0027] 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.

[0028] As an example, the first SOVD API provides two update methods: automatic line brush and manual line brush. The defined methods include: automatic line brush update method PUT / updates / {update-package-id} / automated. Manual line brush update method: PUT / updates / {update-package-id} / prepare prepares manual line brush update, executes manual line brush update: PUT / updates / {update-package-id} / execute executes update.

[0029] In some embodiments, the intelligent vehicle system may have multiple HPCs, and the line-flash servers may be distributed on the multiple HPCs. Each HPC has two CPUs. The line-flash servers on each HPC are the same.

[0030] 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.

[0031] Reference Figure 3 and Figure 4 The process of the line brush service method based on the SOVD protocol is as follows: (1) The client configures key parameter information such as the flash object, 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 to the HPC where it is located and obtain a secure partition directory response.

[0032] The client executes GET / {entity-path} / data / alive_status (such as GET / {base_url} / acos / v1 / apps / ac_updater / data / alive_status) to detect whether the online flash server used for online flashing on different HPCs is running online. If it is running, execute the next step. Otherwise, it is considered to be offline and exits. It is necessary to troubleshoot the cause of the connection failure from the network and hardware layers.

[0033] (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 Mcortex version acquisition tool to obtain the firmware version information of Mcortex and ECU. If the acquisition is successful, the acquired program version information is returned to the client and the next step is executed. Otherwise, it exits and needs to troubleshoot the cause of the failure to obtain the A cortex firmware version information from the hardware layer.

[0034] (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. It is necessary to troubleshoot the reason why the flash cannot be uploaded from the hardware layer.

[0035] (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.

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

[0037] If the client wants to execute the SOVD automatic line 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 line flash server receives the automatic line flash request, it calls the unpacking tool to decompress the uploaded line flash compressed package, checks the ID of the actual line flash compressed package, the line flash file, and / or the line flash sequence file (manifest file) to see if they exist, and checks whether the actual line flash file is complete. If one of the information is incorrect, it exits. If all the information is correct, the line flash server will parse the content of the line flash sequence file. If it fails, it exits without line flashing, and the client can execute / {entity-path} / logs / entries?severity=error to obtain the failure log. Otherwise, the line flash server calls the unpacking tool to parse the line flash sequence file to determine the type of the line flash compressed package. If it is FOTA type, Acortex line flash is executed. If it is single If it is a UDS type, the M cortex or ECU is flashed according to the configuration. If it is a zip UDS type, 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 log of the flashing failure. Otherwise, the client executes GET / {entity-path} / data / reboot to determine whether the HPC is restarted after the flashing is successful, and then execute the next step.

[0038] If the client wants to execute the SOVD manual line brush mode, it first sends a manual line brush preparation request PUT / updates / {update-package-id} / prepare, and then sends a manual line brush execution request PUT / updates / {update-package-id} / execute. After receiving the / updates / {update-package-id} / prepare request, the line brush server calls the unpacking tool to decompress the uploaded line brush compressed package, checks whether the actual line brush file and line brush sequence file exist, and checks whether the actual line brush file is complete. If one piece of information is incorrect, it exits. If all the information is correct, the line brush server will parse the content of the line brush sequence file. If the verification fails, it will exit without line brushing. 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, A cortex flash is executed. If it is single UDS type, M cortex or ECU is flashed according to the configuration. If it is zip UDS type, it is flashed in sequence according to the configuration. If the flash fails, GET / {entity-path} / logs / entries?severity=error is executed to obtain the log of the flash failure. 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 will set the restart flag in the response of {base_url} / acos / v1 / ac_updater / data / reboot to true, and HPC will call the reboot command to restart. If the flash fails, the online flash server sets the reboot flag in the response of {base_url} / acos / v1 / apps / ac_updater / data / reboot to false, and the HPC does not reboot.

[0039] (6) The client executes GET / updates / {update_package_id} / status to obtain the flash progress of the online flash server. If the flash is successful, the online flash server sets the flash status to completed, the flash progress to 100, and returns the flash 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 flash 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 flash is considered to be successful, otherwise it is a failure.

[0040] In a specific embodiment, the line brushing service method based on the SOVD protocol can support the following packet types: FOTA type package, used to flash A cortex firmware.

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

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

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

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

[0045] Supported line brush mode types Based on the automatic online flash mode of SOVD, execute PUT / updates / {update-package-id} / automated to flash.

[0046] In manual online flashing mode based on SOVD, execute PUT / updates / {update-package-id} / prepare successfully, and then execute PUT / updates / {update-package-id} / execute to flash.

[0047] The wire flash service method based on the SOVD protocol provided in the embodiment of the present application has multiple flash strategies, which not only supports the flashing of traditional ECUs, but also supports the flashing of HPC A cortex and M cortex software and firmware. In this method, users only need to use the SOVD API to perform wire flashing on HPC and ECU, thereby upgrading the relevant firmware or software version. The method implements the wire flash function through a wire flash server running on the HPC.

[0048] 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 name in Chinese is vehicle automatic diagnostic system), users use SOVD API to connect to multiple HPCs in the vehicle to batch flash devices. Compared with the existing traditional wire flash solutions, this method reduces the difficulty of flashing and improves the efficiency of flashing.

[0049] 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 a SOVD servlet library, an unpacking tool, and a wire-brush tool.

[0050] 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.

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

[0052] 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.

[0053] 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 a third SOVD API and store the configuration information; receive a program version information request sent by the client through a 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 according to the program version information.

[0054] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0055] Based on the current electronic and electrical architecture of electric vehicle HPC, by adopting the wire flash server based on the SOVD protocol provided in the embodiment of the present application, users only need to simply use the SOVDl API to realize the wire flash of HPC, without having to worry about the complex flashing process and logic of the HPC underlying A cortex and M cortex.

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

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

Claims

1. A line brushing service method based on SOVD protocol, characterized in that: The line brushing service method runs on a line brushing server based on the SOVD protocol in the HPC, and the line brushing service method includes: Receiving a line-brush compressed package uploaded by a client through a first SOVD API, and determining an ID of the line-brush compressed package; Receiving a wire brush request sent by the client through the first SOVD API; in response to the wire brush request, calling an unpacking tool, using the unpacking tool to parse the wire brush compressed package to obtain a wire brush file and a wire brush sequence file; the wire brush file includes a wire brush object, a wire brush compressed package type and at least one compressed firmware; the wire brush sequence file includes a wire brush sequence of each compressed firmware; Using the unpacking tool to perform verification according to the ID, the line brush file and / or the 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.

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 wire refresh server status detection request sent by the client is received through the second SOVD API, and the wire refresh server status is returned in response to the wire refresh server status detection request, so that the client uploads the wire refresh compressed package when the wire 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 the configuration information sent by the client through a third SOVD API, 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 a fourth SOVD API; otherwise, returning information to the client through a fifth SOVD API as to whether the HPC is restarted after the flashing succeeds.

5. The line brushing service method based on the SOVD protocol according to claim 1 is characterized in that: 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 execution automatic line refresh request, and the second refresh request message includes a prepare manual line refresh request and an execution manual line refresh request sent successively.

6. The line brushing service method based on the SOVD protocol according to claim 1 is characterized in that: The HPC includes an M core and an A core, and the line refresh object includes line refreshing the M core, line refreshing the A core, or line refreshing the M core and the A core at the same time.

7. The line brushing service method based on the SOVD protocol according to claim 6 is characterized in that: The HPC is connected to the ECU, and the wire-brush object further includes wire-brush the ECU.

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

9. A line brush server based on SOVD protocol, characterized in that: The line brush server runs in HPC, and the server includes: The SOVD servlet library is used to receive the line brushing compressed package uploaded by the client through the first SOVD API, determine the ID of the line brushing compressed package; receive the line brushing request sent by the client through the first SOVD API; and call the unpacking tool in response to the line brushing request; The unpacking tool is used to parse the line brush compressed package to obtain the line brush file and the line brush sequence file; the line brush file includes the line brush object, the type of the line brush compressed package and at least one compressed firmware; the line brush sequence file includes the line brush sequence of each compressed firmware; verification is performed according to the ID, the line brush file and / or the line brush sequence file; 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.

10. The line brush server based on SOVD protocol according to claim 9, characterized in that: The online flash server also includes a version acquisition tool; The SOVD servlet library is further used 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, used for acquiring program version information according to the configuration information in response to the program version information request; The SOVD servlet library is also used 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