CN114895935A

CN114895935A - Method and device for flashing vehicle ECU, electronic equipment and storage medium

Info

Publication number: CN114895935A
Application number: CN202210438798.2A
Authority: CN
Inventors: 刘均; 樊球
Original assignee: Shenzhen Launch Technology Co Ltd
Current assignee: Shenzhen Launch Technology Co Ltd
Priority date: 2022-04-25
Filing date: 2022-04-25
Publication date: 2022-08-12

Abstract

The application is applicable to the technical field of automotive electronics, and provides a method and a device for flashing a vehicle ECU, electronic equipment and a storage medium. The method comprises the following steps: acquiring a flash data packet corresponding to a target vehicle, wherein the flash data packet comprises an ODX data packet and a flash JAR packet; acquiring a flash file of a target ECU; and calling the flash JAR packet, and executing a flash flow based on the ODX data packet and the flash file to realize flash of the target ECU. The technical scheme provided by the application can improve the safety of the core data of the automobile manufacturer and is convenient for maintaining the flashing function.

Description

Method and device for flashing vehicle ECU, electronic equipment and storage medium

Technical Field

The application belongs to the technical field of automotive electronics, and particularly relates to a method and device for flashing an ECU (electronic control unit) of a vehicle, electronic equipment and a storage medium.

Background

With the continuous development of automobile electronic technology, automobile ECUs are continuously increased, and the requirements on automobile diagnostic technology are higher and higher, particularly the flash function of the automobile ECUs. At present, a method for flashing a vehicle ECU is to provide a flashing protocol and a flow from an automobile manufacturer, and integrate and develop a flashing code in a diagnosis client by a third-party company. When the ECU of the vehicle needs to be refreshed, the user downloads the refresh file to the local for ECU refresh upgrading. The flash protocol and the flow need to be sent out by a third party company, so that core data leakage is easily caused; on the other hand, the flash module is integrated into the diagnosis client, the flash function needs to be modified subsequently, and the code of the diagnosis client needs to be changed, which is very inconvenient.

Disclosure of Invention

The embodiment of the application provides a method and a device for flashing a vehicle ECU, electronic equipment and a storage medium, so that the safety of core data of an automobile manufacturer is improved, and the flashing function is convenient to maintain.

In a first aspect, an embodiment of the present application provides a method for flashing a vehicle ECU, which is applied to a diagnostic client, and the method includes:

acquiring a flash data packet corresponding to a target vehicle; the flash data packet comprises an ODX data packet and a flash JAR packet;

acquiring a flash file of a target ECU;

and calling the flash JAR packet, and executing a flash process based on the ODX data packet and the flash file to realize flash of the target ECU.

According to the technical scheme, the flash data packet corresponding to the target vehicle is obtained, wherein the flash data packet comprises an ODX data packet and a flash JAR packet; acquiring a flash file of a target ECU; and calling the flash JAR packet, and executing a flash flow based on the ODX data packet and the flash file to realize flash of the target ECU. On one hand, the flash data packet corresponding to the vehicle is provided by the vehicle manufacturer, so that the core data provided by the vehicle manufacturer can be prevented from leaking, and the data safety is improved; on the other hand, by calling the flash JAR packet and executing the flash process based on the ODX data packet and the flash file, the flash function is required to be modified subsequently, and the code of the diagnosis client does not need to be changed, so that the flash function is convenient to maintain.

Optionally, the obtaining of the flash data packet corresponding to the target vehicle includes:

acquiring a target vehicle identification code and uploading the target vehicle identification code to a server;

and downloading the flash data packet corresponding to the target vehicle identification code from the server.

Optionally, the invoking the flash JAR package, and executing a flash process based on the ODX data package and the flash file to implement the flash of the target ECU includes:

analyzing the ODX data packet to obtain the flash priority of at least one flash file corresponding to the target ECU;

and calling the flash JAR packet, and executing a flash process based on the ODX data packet, at least one flash file and the flash priority so as to realize that the target ECU is flashed in sequence according to the flash file based on the flash priority.

Optionally, the invoking the flush JAR packet, and executing the flush flow based on the ODX data packet and the flush file to implement the flush of the target ECU includes:

loading a Java virtual machine, executing the flash JAR package through the Java virtual machine, and flashing a target ECU (electronic control unit) based on the ODX data package and the flash file in the process of executing the flash JAR package; and the flash JAR package encapsulates the flash flow corresponding to the target vehicle.

Optionally, the method further includes loading a JWRAP dynamic link library, receiving an execution result of the flush JAR packet returned by the JWRAP dynamic link library, and monitoring the execution result of the flush JAR packet by the JWRAP dynamic link library through a target interface in the flush JAR packet.

Optionally, the flashing flow encapsulated by the flashing JAR packet at least includes two flashing stages; the receiving of the execution result of the flashing JAR packet returned by the JWRAP dynamic link library includes:

receiving an execution result of the current flash stage returned by the JWRAP dynamic link library;

if the execution is successful, the next flash stage is continuously executed;

and if the execution fails, displaying corresponding prompt information.

Optionally, the obtaining the flash file of the target ECU includes:

when an ECU (electronic control unit) flashing command is detected, flashing options corresponding to at least two ECUs respectively are displayed;

based on the selection of a user for a target ECU, downloading a second aspect of a flash file corresponding to the target ECU, an embodiment of the present application provides an apparatus for flashing a vehicle ECU, which is applied to a diagnostic client, and the apparatus includes:

the first acquisition module is used for acquiring a flash data packet corresponding to a target vehicle; the flash data packet comprises an ODX data packet and a flash JAR packet;

the second acquisition module is used for acquiring the flash file of the target ECU;

and the flash module is used for calling the flash JAR packet, executing a flash process based on the ODX data packet and the flash file, and realizing flash of the target ECU.

In a third aspect, an embodiment of the present application provides an electronic device, including:

a memory, a processor and a computer program stored in the memory and executable on the processor, the computer program, when executed by the processor, implementing the method steps of the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, including: the computer readable storage medium stores a computer program which, when executed by a processor, performs the method steps of the first aspect described above.

In a fifth aspect, embodiments of the present application provide a computer program product, which, when run on an electronic device, causes the electronic device to perform the method steps of the first aspect.

It is understood that the beneficial effects of the second aspect to the fifth aspect can be referred to the related description of the first aspect, and are not described herein again.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

FIG. 1 is a schematic flow chart diagram illustrating a method for flashing a vehicle ECU according to an embodiment of the present application;

FIG. 2 is a schematic flow chart diagram illustrating a method for flashing a vehicle ECU in accordance with another embodiment of the present application;

FIG. 3 is a schematic structural diagram of an apparatus for flashing an ECU of a vehicle according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to" determining "or" in response to detecting ". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather mean "one or more but not all embodiments" unless specifically stated otherwise. The terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

At present, with the continuous development of automobile electronic technology, automobile ECUs are continuously increased, and the requirements on automobile diagnosis technology are higher and higher, particularly the flash function of the automobile ECUs. At present, a method for flashing a vehicle ECU is to provide a flashing protocol and a flow from an automobile manufacturer, and integrate and develop a flashing code in a diagnosis client by a third-party company. When the ECU of the vehicle needs to be refreshed, the vehicle manufacturer downloads the refresh file to the local for ECU refresh upgrading. The flash protocol and the flow need to be sent out by a third party company, so that core data leakage is easily caused; on the other hand, the flash module is integrated into the diagnosis client, the flash function needs to be modified subsequently, and the code of the diagnosis client needs to be changed, which is very inconvenient.

In view of this, the present application provides a method, an apparatus, an electronic device, and a storage medium for flashing a vehicle ECU to improve security of core data of an automobile manufacturer and facilitate maintenance of a flashing function.

Fig. 1 illustrates a method for flashing a vehicle ECU, which is applicable to a diagnostic client and mainly includes steps S101 to S103, and is described in detail as follows:

step S101: and acquiring a flash data packet corresponding to the target vehicle, wherein the flash data packet comprises an ODX data packet and a flash JAR packet.

In the embodiment of the application, the diagnosis client is an application program or diagnosis software installed in the vehicle diagnosis device, and the flash data packet corresponding to the target vehicle is developed and maintained by a software developer or an after-sales technician of a manufacturer of the target vehicle and is uploaded to the server. Here, the flush packet includes an ODX packet and a flush JAR packet, where the ODX packet, which is a packet of Open Diagnostic data eXchange (ODX), is an XML data format for describing vehicle Diagnostic related data, i.e., exchanging Diagnostic data between a vehicle OEM and its supplier, and the JAR packet (JAR is an english abbreviation of Java Archive), which is a compressed packet of Java at the time of application development using Java language, and may also be considered as a set of class (class) files, and when a certain JAR packet is used in a project, a path of the JAR packet needs to be set in a related parameter (typically, a class parameter) for specifying a class loading path, and the class included in the JAR packet can be dynamically loaded by the Java virtual machine at runtime. In the embodiment of the application, when the ECU flash of the vehicle is needed, the flash data packet which is made by the vehicle manufacturer and corresponds to the vehicle can be directly obtained from the server.

Step S102: and acquiring a flash file of the target ECU.

In the embodiment of the application, the flash file corresponds to the ECU, and is a file which is downloaded by the client after the client selects the specific ECU needing flash according to the user. The flash files of each ECU can also be stored in the server in advance for downloading by the client.

Step S103: and calling the flash JAR packet, and executing a flash flow based on the ODX data packet and the flash file to realize flash of the target ECU.

Because the diagnosis client supports the ODX standard, the diagnosis client can analyze the ODX data packet and the flash JAR packet to obtain the data required by flash. Parameters in the ODX data packet are data that needs to be used in the flashing process, such as baud rate of communication, communication pins, diagnostic services, and the like, and the flashing JAR packet is an encapsulated executable process, that is, a flashing process, for example, the first step is sending 1003 to enter an expansion mode, and the second step is sending 8502 and the like. The flush file is data to be flushed into the ECU, and is a binary file. Therefore, the diagnosis client executes the flashing process by calling the flashing JAR packet and executing the flashing process based on the ODX data packet and the flashing file, so that the flashing of the target ECU is realized.

Specifically, as an embodiment of the present application, the obtaining of the flash file of the target ECU may be: when an ECU (electronic control unit) flashing instruction is detected, flashing options corresponding to at least two ECUs respectively are displayed; and downloading the flash file corresponding to the target ECU based on the selection of the user for the target ECU. The flash files are distinguished according to different ECUs and stored in a server, and the flash files required by the ECUs can be downloaded by detecting a selection instruction of a user.

Specifically, as an embodiment of the present application, the step S103 of invoking the refresh JAR package, executing the refresh process based on the ODX data package and the refresh file, and implementing the refresh to the target ECU may include:

It should be noted that the ODX data packet includes various diagnostic parameters and data required in the diagnostic process, including the ECU list included in the vehicle, and the refresh session and priority of each ECU. The refresh session is a refresh session, and the refresh priority of each refresh file corresponding to the ECU can be queried. Therefore, by parsing the ODX packet, the flush priority of the at least one flush file corresponding to the target ECU can be obtained. And then, executing a brushing flow by calling the brushing JAR packet, and sequentially brushing each brushing file into the ECU according to the priority of the brushing file. In the embodiment of the application, numerical values can be used for representing the brushing priority size of each ECU brushing file of the ECU brushing files of the target vehicle, and the smaller the numerical value is, the higher the priority the ECU brushing file is to the ECU is to be brushed.

As another embodiment of the present application, invoking a flush JAR package, and executing a flush flow based on the ODX data package and the flush file, the implementation of the flush to the target ECU may be:

loading a Java virtual machine, executing a flash JAR package through the Java virtual machine, and flashing a target ECU based on an ODX data package and a flash file in the process of executing the flash JAR package, wherein the flash JAR package encapsulates a flash flow corresponding to a target vehicle.

In the above embodiment, the Java virtual machine is a program environment in which C + + calls the JAR package, and the JAR package may be flashed by the Java virtual machine. The flashing process packaged by the flashing JAR packet at least comprises three flashing stages, namely a pre-flashing stage, a middle flashing stage and a post-flashing stage, wherein the pre-flashing stage is preprogramming JavaJob and comprises entering an expansion mode and safety verification, the middle flashing stage is programming JavaJob and comprises flashing data, the post-flashing stage of the target ECU flashing process comprises flashing result verification and target ECU resetting, the entering of the expansion mode refers to sending an instruction (for example, 1003 instruction) to an ECU to be flashed to enable the target ECU to enter the expansion mode, then sending another instruction (for example, 1003 instruction) to enter a safety verification mode, so that the target ECU can enter the middle flashing stage to flash the target ECU, namely data flashing is carried out on the target ECU, the flashing result verification refers to verifying the section of the flashing data after the target ECU is completely written each time, confirming whether the flashing is correct, and the resetting of the target ECU refers to the completion of the flashing, the diagnostic apparatus sends a reset instruction to the target ECU to reset the target ECU. Here, a Java Virtual Machine (JVM) is an abstract computer, and is realized by simulating various computer functions on an actual computer. The JVM may also be considered a specification for a computer device, and may be implemented in different ways (software or hardware). Compiling the instruction set of a virtual machine is very similar to compiling the instruction set of a microprocessor. The JVM has its own sophisticated hardware architecture, such as processor, stack, registers, etc., and has a corresponding instruction system. The Java virtual machine comprises a set of bytecode instruction set, a group of registers, a stack, a garbage collection heap and a storage method domain JVM which shields information related to a specific operating system platform, so that a Java program can run on various platforms without modification only by generating object codes running on the JVM.

In the above embodiment, the method further includes: loading a JWRAP dynamic link library, and receiving an execution result of the flashing JAR packet returned by the JWRAP dynamic link library, wherein the JWRAP dynamic link library monitors the execution result of the flashing JAR packet through a target interface in the flashing JAR packet.

Specifically, the refresh JAR package feeds back the execution result of each refresh stage to the JWRAP dynamic link library through a sendfinalresult interface in the package, and the JWRAP dynamic link library feeds back the execution result to the diagnostic client.

The execution result of receiving the flash JAR packet returned by the JWRAP dynamic link library may be: receiving an execution result of the current flash stage returned by the JWRAP dynamic link library; if the execution is successful, continuing to execute the next flashing stage; and if the execution fails, displaying corresponding prompt information.

For example, if the execution of the pre-flashing stage of the target ECU flashing process fails, the prompt information of the pre-flashing stage execution failure is fed back to the diagnostic equipment client through the JWRAP dynamic link library file; and if the execution of the brushing middle stage of the target ECU brushing flow fails, feeding back prompt information of the brushing middle stage execution failure to the diagnosis equipment client through the JWRAP dynamic link library file, and the like. In the above embodiment, the dynamic link library may support windows and Linux systems, and dll files are provided under a Window platform, and so files are provided under a Linux platform, which is mainly a way to implement a concept of sharing a function library. Dynamic linking provides a way for a process to call functions that do not belong to its executable code. The executable code for the functions is located in a dynamically linked library file containing one or more functions that have been compiled, linked and stored separately from the process in which they are used. Dynamically linked libraries also facilitate sharing of data and resources.

As can be known from the method for flashing the vehicle ECU illustrated in fig. 1, by acquiring a flash data packet corresponding to a target vehicle, the flash data packet includes an ODX data packet and a flash JAR packet; acquiring a flash file of a target ECU; and calling the flash JAR packet, and executing a flash flow based on the ODX data packet and the flash file to realize flash of the target ECU. On one hand, the flash data packet corresponding to the vehicle is provided by the vehicle manufacturer, so that the core data provided by the vehicle manufacturer can be prevented from leaking, and the data safety is improved; on the other hand, by calling the flash JAR packet and executing the flash process based on the ODX data packet and the flash file, the flash function is required to be modified subsequently, and the code of the diagnosis client does not need to be changed, so that the flash function is convenient to maintain.

Fig. 2 shows a method for flashing a vehicle ECU, which is applicable to a diagnostic device and mainly includes steps S201 to S204, and is described in detail as follows:

step S201: and reading the identification code VIN of the target vehicle and uploading the identification code VIN to the server.

Vehicle Identification Number (VIN) is a set of numbers assigned to a Vehicle by a manufacturer for Identification, and has unique Identification for the Vehicle, and thus may be referred to as a Vehicle id card. In an embodiment of the present application, the diagnostic device may be connected to the target vehicle, and then the diagnostic device client reads the target VIN and uploads the target VIN to the server.

Step S202: and downloading the flash data packet corresponding to the target vehicle identification code from the server.

After the server receives the target VIN, the server inquires the flash data packet of the target vehicle corresponding to the target VIN from the database of the target VIN according to the target VIN, and the diagnosis equipment downloads the flash data packet of the target vehicle corresponding to the target VIN from the server. It should be noted that the flash data packet of the target vehicle is developed and maintained by the software developer or after-market technician of the manufacturer of the target vehicle and uploaded to the server. And the vehicle manufacturer develops a corresponding flash data packet according to the vehicle type of the vehicle and uploads the flash data packet to the server. The client can obtain the corresponding flash data packet from the server through the vehicle VIN code.

Step S203: and acquiring a flash file of the target ECU.

Step S204: and calling the flash JAR packet, and executing a flash flow based on the ODX data packet and the flash file to realize flash of the target ECU.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Corresponding to the method for flashing the vehicle ECU shown in fig. 1, fig. 3 shows an apparatus for flashing the vehicle ECU, which may be applied to the diagnostic device and mainly includes a first obtaining module 301, a second obtaining module 302 and a flashing module 303, and the following is described in detail:

the first obtaining module 301 is configured to obtain a flash data packet corresponding to a target vehicle, where the flash data packet includes an ODX data packet and a flash JAR packet;

a second obtaining module 302, configured to obtain a flash file of a target ECU;

and the flash module 303 is configured to call a flash JAR packet, execute a flash process based on the ODX data packet and the flash file, and implement flash on the target ECU.

It is understood that various embodiments and combinations of the embodiments in the above embodiments and their advantages are also applicable to this embodiment, and are not described herein again.

Optionally, the first obtaining module 301 illustrated in fig. 3 may include an identification code obtaining unit and a first downloading unit, where:

the identification code acquisition unit is used for acquiring the identification code of the target vehicle and uploading the identification code to the server;

and the first downloading unit is used for downloading the flash data packet corresponding to the target vehicle identification code from the server.

Optionally, the aforementioned flash module 303 illustrated in fig. 3 may include a parsing unit and a calling unit, where:

the analysis unit is used for analyzing the ODX data packet and acquiring the flash priority of at least one flash file corresponding to the target ECU;

and the calling unit is used for calling the flash JAR packet and executing a flash process based on the ODX data packet, the at least one flash file and the flash priority so as to realize that the target ECU is flashed sequentially according to the flash files based on the flash priority.

Optionally, the flash module 303 illustrated in fig. 3 may include a virtual machine loading unit, configured to load a Java virtual machine, execute a flash JAR package through the Java virtual machine, and flash the target ECU based on the ODX data package and the flash file in a process of executing the flash JAR package, where the flash JAR package encapsulates a flash flow corresponding to the target vehicle.

Optionally, the apparatus illustrated in fig. 3 may further include a dynamic link library loading module, configured to load a JWRAP dynamic link library, receive an execution result of the flushing JAR packet returned by the JWRAP dynamic link library, where the JWRAP dynamic link library monitors the execution result of the flushing JAR packet through a target interface in the flushing JAR packet.

Optionally, the flash flow of the flash JAR package of the above example includes at least two flash stages, where the dynamically linked library loading module includes a receiving unit, a continuing execution unit, and a first display unit, where:

the receiving unit is used for receiving the execution result of the current flash stage returned by the JWRAP dynamic link library;

the continuous execution unit is used for continuously executing the next flash stage if the execution is successful;

and the first display unit is used for displaying corresponding prompt information if the execution fails.

Optionally, the second obtaining module 302 illustrated in fig. 3 may include a second display unit and a second downloading unit, where:

the second display unit is used for displaying the flash options corresponding to at least two ECUs respectively when the ECU flash instruction is detected;

and the second downloading unit is used for downloading the flash file corresponding to the target ECU based on the selection of the user for the target ECU.

Fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application, where the electronic device D10 includes: at least one processor D100 (only one is shown in fig. 4), a memory D101, and a computer program D102 stored in the memory D101 and operable on the at least one processor D100, wherein the processor D100 implements the steps of any of the method embodiments described above when executing the computer program D102. Alternatively, the processor D100, when executing the computer program D102, implements the functions of the modules/units in the above-mentioned device embodiments, such as the functions of the first obtaining module 301, the second obtaining module 302, and the writing module 303 shown in fig. 3.

The electronic device D10 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The electronic device may include, but is not limited to, a processor D100, a memory D101. Those skilled in the art will appreciate that fig. 4 is merely an example of the electronic device D10 and does not constitute a limitation of the electronic device D10, and may include more or fewer components than those shown, or some components in combination, or different components, such as input output devices, network access devices, etc.

Processor D100 may be a Central Processing Unit (CPU), and Processor D100 may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The storage D101 may be an internal storage unit of the electronic device D10 in some embodiments, such as a hard disk or a memory of the electronic device D10. In other embodiments, the memory D101 may also be an external storage device of the electronic device D10, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the electronic device D10. Further, the memory D101 may also include both an internal storage unit and an external storage device of the electronic device D10. The memory D101 is used for storing an operating system, an application program, a BootLoader (BootLoader), data, and other programs, such as program codes of the computer programs. The memory D101 may also be used to temporarily store data that has been output or is to be output.

It should be noted that, for the information interaction, execution process, and other contents between the above-mentioned devices/units, the specific functions and technical effects thereof are based on the same concept as those of the embodiment of the method of the present application, and specific reference may be made to the part of the embodiment of the method, which is not described herein again.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

The embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments may be implemented.

Embodiments of the present application provide a computer program product, which when executed on an electronic device, enables the electronic device to implement the steps in the above method embodiments.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium and can implement the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing apparatus/terminal apparatus, a recording medium, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signal, telecommunication signal, and software distribution medium. Such as a usb-disk, a removable hard disk, a magnetic or optical disk, etc. In certain jurisdictions, computer-readable media may not be an electrical carrier signal or a telecommunications signal in accordance with legislative and patent practice.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other ways. For example, the above-described apparatus/network device embodiments are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implementing, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A method for flashing a vehicle ECU is applied to a diagnosis client side, and is characterized by comprising the following steps:

acquiring a flash file of a target ECU;

2. The method of claim 1, wherein the obtaining of the flash data packet corresponding to the target vehicle comprises:

3. The method of claim 1, wherein the invoking the flash JAR package and performing a flash process based on the ODX data package and the flash file to implement the flash to the target ECU comprises:

4. The method of claim 1, wherein the invoking the flash JAR package and executing the flash flow based on the ODX data package and the flash file to implement the flash to the target ECU comprises:

5. The method of claim 4, further comprising loading a JWRAP dynamic link library, receiving an execution result of the flush JAR packet returned by the JWRAP dynamic link library, and the JWRAP dynamic link library snooping the execution result of the flush JAR packet through a target interface in the flush JAR packet.

6. The method of claim 5, wherein the flash flow of the flash JAR packet encapsulation includes at least two flash phases; the receiving of the execution result of the flashing JAR packet returned by the JWRAP dynamic link library includes:

if the execution is successful, continuing to execute the next flashing stage;

and if the execution fails, displaying corresponding prompt information.

7. The method of claim 1, wherein the obtaining the flash file for the target ECU comprises:

when an ECU (electronic control unit) flashing instruction is detected, flashing options corresponding to at least two ECUs respectively are displayed;

and downloading the flash file corresponding to the target ECU based on the selection of the user for the target ECU.

8. An apparatus for flashing a vehicle ECU, applied to a diagnostic client, comprising:

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 7.