A fault diagnosis function version iteration method, device, equipment and storage medium

Abstract

The application discloses a fault diagnosis function version iteration method and device, equipment and storage medium. The method comprises the following steps: acquiring current fault diagnosis code corresponding to a current fault diagnosis function version; comparing and processing the current fault diagnosis code with historical fault diagnosis code corresponding to a historical fault diagnosis function version, so as to determine whether the underlying software code and the application diagnosis code are changed; in the case that the underlying software code is changed and the application diagnosis code is not changed, based on an automatic cutting script executor, the target fault diagnosis function version is determined according to the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code, so that the target fault diagnosis function version is automatically iterated and determined in the case that the underlying software code is changed and the application diagnosis code is not changed, the operation process is simplified, and the overall development iteration efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of software function development technology, and in particular to a method, apparatus, device and storage medium for version iteration of fault diagnosis function. Background Technology

[0002] In recent years, with the rapid development of automotive intelligence and connectivity, the number of Electronic Control Units (ECUs), the core of an automotive electronic control system, has exploded. In practical system application development, diagnostic systems can diagnose faults in the control system to determine the cause of the fault, enabling maintenance personnel to accurately resolve the problem.

[0003] In the current intelligent vehicle architecture, the fault diagnosis version has evolved from an initial stage of independent controllers for underlying software and application software functions to a final, prototype testing stage where the entire vehicle's functions are fully developed. During this development and iteration process, the fault diagnosis function is not perfect; it is gradually developed and completed with each iteration of the fault diagnosis version. Currently, application software developers typically use traditional iterative methods to iterate and verify the stability of the application functions during the development and iteration of the fault diagnosis function.

[0004] However, traditional iterative methods are cumbersome and complex. During controller version development and iteration, changes to the underlying software code may occur frequently. Even if the application diagnostic code remains unchanged, developers need to re-integrate the saved diagnostic data files using host computer tools. However, this integration process suffers from problems such as a limited number of host computer tools, cumbersome operation, incompatibility between host computer tool hardware and software versions, and the need for extensive communication between underlying developers, application developers, and third-party vendors. This results in low software function iteration efficiency, high iteration costs, and poor accuracy, which are the pain points of current technologies. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and storage medium for iterating the version of a fault diagnosis function, so as to automatically iterate and determine the target fault diagnosis function version when the underlying software code changes but the application diagnosis code remains unchanged, thereby simplifying the operation process and improving the overall development iteration efficiency.

[0006] According to one aspect of the present invention, a method for version iteration of a fault diagnosis function is provided. The method includes:

[0007] Obtain the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnosis code;

[0008] The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed.

[0009] If the underlying software code changes but the application diagnostic code does not, the target fault diagnosis function version is determined based on the automatic script cutter, according to the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code.

[0010] According to another aspect of the present invention, a fault diagnosis function version iteration apparatus is provided. The apparatus includes:

[0011] The current fault diagnosis code acquisition module is used to acquire the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnosis code;

[0012] The fault diagnosis code comparison module is used to compare the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version, so as to determine whether the underlying software code and the application diagnosis code have changed respectively.

[0013] The target fault diagnosis function version determination module is used to determine the target fault diagnosis function version based on the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code, when the underlying software code has changed but the application diagnosis code has not changed, using an automatic script cutter.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the fault diagnosis function version iteration method according to any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the fault diagnosis function version iteration method according to any embodiment of the present invention.

[0019] The technical solution of this invention obtains the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnostic code. The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnostic code have changed. If the underlying software code has changed but the application diagnostic code has not, an automatic script executor determines the target fault diagnosis function version based on the historical fault diagnosis code and the current fault diagnosis code. This solves the problems of low software function iteration efficiency, high iteration costs, and excessive reliance on host computer tools when the underlying software code changes but the application diagnostic code remains unchanged. It enables automatic iteration and determination of the target fault diagnosis function version, simplifies the operation process, and improves overall development iteration efficiency.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a fault diagnosis function version iteration method provided in Embodiment 1 of the present invention;

[0023] Figure 2 This is a flowchart of a fault diagnosis function version iteration method provided in Embodiment 2 of the present invention.

[0024] Figure 3 This is a schematic diagram of the structure of a fault diagnosis function version iteration device provided in Embodiment 3 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of an electronic device that implements the fault diagnosis function version iteration method of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] Example 1

[0029] Figure 1 This is a flowchart illustrating a method for iterative updates of a fault diagnosis function according to Embodiment 1 of the present invention. This embodiment is applicable to situations involving iterative updates of the fault diagnosis function, particularly when the underlying software code changes but the application diagnosis code remains unchanged. This method can be executed by a fault diagnosis function version iteration device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0030] S101. Obtain the current fault diagnosis code corresponding to the current fault diagnosis function version.

[0031] Here, "current fault diagnosis function version" can refer to the diagnosis version corresponding to the fault diagnosis function to be iterated or updated. "Current fault diagnosis code" can refer to the fault diagnosis code in the current fault diagnosis function version. The current fault diagnosis code can include underlying software code and application diagnostic code.

[0032] For example, the underlying software code can be developed by the underlying developers to create the basic modules, and then permissions can be released to the application layer developers after development is complete. Once the application developers have access to the underlying software, they can then develop relevant functions such as fault diagnosis or data processing for the application layer based on this underlying software.

[0033] Specifically, by using conventional techniques such as code lookup or automated scripts, the current fault diagnosis code corresponding to the current fault diagnosis function version is determined from the current fault diagnosis function version.

[0034] S102. The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed.

[0035] Here, "historical fault diagnosis function version" can refer to the previous fault diagnosis function version. Correspondingly, "historical fault diagnosis code" can refer to the fault diagnosis code in the previous fault diagnosis function version.

[0036] Specifically, the current fault diagnosis code is compared with the historical fault diagnosis code obtained from the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code in the current fault diagnosis code have changed.

[0037] For example, changes to the underlying software code and the application diagnostic code in the current fault diagnosis code may occur in the following ways: both the underlying software code and the application diagnostic code have changed; the underlying software code has changed but the application diagnostic code has not changed; the underlying software code has not changed but the application diagnostic code has changed; and neither the underlying software code nor the application diagnostic code has changed.

[0038] S103. If the underlying software code has changed but the application diagnostic code has not changed, the target fault diagnosis function version is determined based on the automatic cut script executor, according to the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code.

[0039] Here, the automatic cut script executor can refer to a pre-implemented batch file script. The target fault diagnosis function version can refer to the final version that iterates on the fault diagnosis function.

[0040] Specifically, when the underlying software code changes but the application diagnostic code remains unchanged, the code information of the historical fault diagnosis function version corresponding to the historical fault diagnosis function version is cut and pasted by the automatic cut script executor, thereby obtaining the target fault diagnosis function version.

[0041] For example, determining the target fault diagnosis function version based on the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code, using an automatic script cutter, includes: generating a current executable file based on the underlying software code corresponding to the current fault diagnosis code; and determining the target fault diagnosis function version based on the historical executable file corresponding to the historical fault diagnosis function version and the current executable file, using an automatic script cutter.

[0042] The current executable file can refer to the compiled code file corresponding to the current fault diagnosis code. For example, the executable file may include an ELF file and / or a HEX file. It should be noted that the executable file can be obtained by compiling the fault diagnosis code using a corresponding compiler. For example, the current executable file can be obtained by compiling the current fault diagnosis code using the compiler corresponding to the current executable file, and historical executable files can be obtained by compiling historical fault diagnosis code using the compiler corresponding to historical executable files.

[0043] Specifically, the automatic cut script executor cuts the fault diagnosis data in the historical executable file corresponding to the historical fault diagnosis function version, and pastes it into the current executable file to obtain the target fault diagnosis function version.

[0044] For example, determining the target fault diagnosis function version based on the automatic script cutter executor and the historical executable file corresponding to the historical fault diagnosis function version and the current executable file includes: determining the first fault diagnosis data address information in the historical executable file based on the automatic script cutter executor and the historical executable file; and determining the target fault diagnosis function version based on the automatic script cutter executor, the current executable file, and the first fault diagnosis data address information.

[0045] The first fault diagnosis data address information can refer to the storage address information of the fault diagnosis data in the storage space of the historical executable file.

[0046] Specifically, the historical executable file is cut using an automatic cut script executor to determine the address information of the first fault diagnosis data in the historical executable file. The first fault diagnosis data address information is then pasted into the current executable file using the automatic cut script executor, thereby determining the version of the target fault diagnosis function.

[0047] For example, determining the first fault diagnosis data address information in the historical executable file based on the automatic cut script executor and the historical executable file includes: determining the first data storage area corresponding to the first fault diagnosis data address information in the historical executable file; and performing cut processing on the first data storage area corresponding to the historical executable file based on the cut function in the automatic cut script executor to obtain the first fault diagnosis data address information corresponding to the historical executable file.

[0048] The first data storage area may refer to the storage address of the first fault diagnosis data address information in the historical executable file.

[0049] Specifically, the first data storage area corresponding to the first fault diagnosis data address information in the historical executable file is determined, and the first data storage area is cut based on the cut function in the automatic cut script executor, thereby obtaining the first fault diagnosis data address information corresponding to the historical executable file.

[0050] For example, determining the target fault diagnosis function version based on the automatic cut script executor, the current executable file, and the first fault diagnosis data address information includes: determining the second data storage area corresponding to the second fault diagnosis data address information in the current executable file; pasting the first fault diagnosis data address information into the second data storage area corresponding to the current executable file based on the paste function in the automatic cut script executor, so that the first fault diagnosis data address information covers the second fault diagnosis data address information, thereby obtaining the target executable file; and determining the target fault diagnosis function version based on the target executable file.

[0051] Here, the second fault diagnosis data address information can refer to the storage address information of the fault diagnosis data in the current executable file within the storage space. The second data storage area can refer to the storage address of the second fault diagnosis data address information in the current executable file. The target executable file can refer to the first fault diagnosis data address information that is overwritten by the fault diagnosis data address information.

[0052] Specifically, the second data storage area corresponding to the second fault diagnosis data address information in the current executable file is determined. Using the paste function in the automatic cut script executor, the first fault diagnosis data address information is pasted into the second data storage area corresponding to the current executable file, so that the first fault diagnosis data address information overwrites the second fault diagnosis data address information, i.e., the fault diagnosis data address information in the current executable file is modified, thereby obtaining the target executable file. By adding necessary information (such as identification information) to the target executable file, the target fault diagnosis function version can be obtained.

[0053] The technical solution of this invention obtains the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnostic code. The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnostic code have changed. If the underlying software code has changed but the application diagnostic code has not, an automatic script executor determines the target fault diagnosis function version based on the historical fault diagnosis code and the current fault diagnosis code. This solves the problems of low software function iteration efficiency, high iteration costs, and excessive reliance on host computer tools when the underlying software code changes but the application diagnostic code remains unchanged. It enables automatic iteration and determination of the target fault diagnosis function version, simplifies the operation process, and improves overall development iteration efficiency.

[0054] Based on the above embodiments, the step of comparing the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed includes: if both the underlying software code and the application diagnosis code have changed, or if the underlying software code has not changed but the application diagnosis code has changed, the current fault diagnosis code is sequentially compiled, burned, configured, and integrated and saved to obtain the target fault diagnosis function version.

[0055] It should be noted that since the diagnostic data is all located in the calibrated memory storage space, if both the underlying software code and the application diagnostic code are changed, or if the underlying software code is unchanged but the application diagnostic code is changed, the change in the underlying software code will not change the storage address of the fault diagnostic code. However, if the application diagnostic code is changed, the fault diagnostic code may change, that is, the storage address of the fault diagnostic code data in memory will change. Therefore, the overwrite method cannot be used to simplify the iteration process. Only the traditional iteration method can be used to process it, that is, the current fault diagnostic code is sequentially compiled, burned, configured, and integrated and saved to finally form the target fault diagnostic function version.

[0056] Specifically, when both the underlying software code and the application diagnostic code have changed, or when the underlying software code has not changed but the application diagnostic code has changed, the application specialist locates the current fault diagnostic code using data locators (a C language data location method that fixes the data's address at compile time in a pre-reserved memory address area). Based on the model architecture type, the appropriate compiler is selected to compile the C language file of the current fault diagnostic code into an ELF executable file and a HEX file. The ELF or HEX file is then burned into the ECU using a debugger, enabling the ECU to run normally under power. The development board and calibration CAN bus harness are connected and connected to the power supply, ensuring the development board can operate under constant power and high voltage, and that the calibration CAN bus is powered. The wiring harness of the calibration host computer tool CANAPE is connected to the ECU, and the channel is configured in the CANAPE software to ensure a correct link connection. After the ECU is powered on, the host computer tool and the slave computer can establish a normal handshake connection. In the CANAPE project, select the ELF file running inside the ECU, add the current fault diagnosis code data to the CANAPE project for configuration, and then add the configured current fault diagnosis code data to the calibration main window for calibration preparation. Export the calibration DCM file (a file in quantitative index format). In the CANAPE software tool interface (calibration data offline storage mode), integrate and save the DCM file and the target executable file, and determine the target fault diagnosis function version based on the target executable file.

[0057] Based on the above embodiments, the step of comparing the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed includes: if the underlying software code has not changed and the application diagnosis code has not changed, the current fault diagnosis function version is determined as the target fault diagnosis function version.

[0058] Specifically, if the underlying software code and the application diagnostic code have not changed, it indicates that there is no need for iterative processing, and the current fault diagnosis function version can be directly determined as the target fault diagnosis function version.

[0059] Example 2

[0060] Figure 2 This is a flowchart of a fault diagnosis function version iteration method provided in Embodiment 2 of the present invention. This embodiment discloses a preferred implementation scheme based on the embodiments described above. Figure 2 As shown, the method includes:

[0061] S201. Obtain the current fault diagnosis code corresponding to the current fault diagnosis function version.

[0062] S202. The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed.

[0063] S203. If the underlying software code has changed but the application diagnostic code has not changed, proceed to step S204; if both the underlying software code and the application diagnostic code have changed, or if the underlying software code has not changed but the application diagnostic code has changed, proceed to step S205; if neither the underlying software code nor the application diagnostic code has changed, proceed to step S206.

[0064] S204. Based on the automatic cut script executor, determine the target fault diagnosis function version according to the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code.

[0065] S205. The current fault diagnosis code is sequentially compiled, burned, configured, and integrated and saved to obtain the target fault diagnosis function version.

[0066] S206. Set the current fault diagnosis function version as the target fault diagnosis function version.

[0067] Example 3

[0068] Figure 3 This is a schematic diagram of a fault diagnosis function version iteration device provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes: a current fault diagnosis code acquisition module 301, a fault diagnosis code comparison module 302, and a target fault diagnosis function version determination module 303. Among them,

[0069] The current fault diagnosis code acquisition module 301 is used to acquire the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnosis code.

[0070] The fault diagnosis code comparison module 302 is used to compare the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version, so as to determine whether the underlying software code and the application diagnosis code have changed respectively.

[0071] The target fault diagnosis function version determination module 303 is used to determine the target fault diagnosis function version based on the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code, when the underlying software code has changed but the application diagnosis code has not changed, using an automatic script cutter.

[0072] The technical solution of this invention obtains the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnostic code. The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnostic code have changed. If the underlying software code has changed but the application diagnostic code has not, an automatic script executor determines the target fault diagnosis function version based on the historical fault diagnosis code and the current fault diagnosis code. This solves the problems of low software function iteration efficiency, high iteration costs, and excessive reliance on host computer tools when the underlying software code changes but the application diagnostic code remains unchanged. It enables automatic iteration and determination of the target fault diagnosis function version, simplifies the operation process, and improves overall development iteration efficiency.

[0073] Optionally, the target fault diagnosis function version determination module 303 includes: a current executable file generation unit and a diagnosis function version unit. Wherein,

[0074] The current executable file generation unit is used to generate a current executable file based on the underlying software code corresponding to the current fault diagnosis code;

[0075] The diagnostic function version unit is used to determine the target fault diagnosis function version based on the historical executable file corresponding to the historical fault diagnosis function version and the current executable file, using an automatic cut script executor.

[0076] Optionally, the diagnostic function version unit includes an address information determination subunit and a diagnostic function version determination subunit. Wherein,

[0077] The address information determination subunit is used to determine the address information of the first fault diagnosis data in the historical executable file based on the automatic cut script executor and the historical executable file;

[0078] The diagnostic function version determination subunit is used to determine the target fault diagnosis function version based on the automatic cut script executor, the current executable file, and the first fault diagnosis data address information.

[0079] Optionally, the address information determining the subunit can be specifically used for:

[0080] Determine the first data storage area corresponding to the first fault diagnosis data address information in the historical executable file;

[0081] Based on the cut function in the automatic cut script executor, the first data storage area corresponding to the historical executable file is cut to obtain the first fault diagnosis data address information corresponding to the historical executable file.

[0082] Optionally, the diagnostic function version determination subunit can be specifically used for:

[0083] Determine the second data storage area corresponding to the second fault diagnosis data address information in the current executable file;

[0084] Based on the paste function in the automatic cut script executor, the first fault diagnosis data address information is pasted into the second data storage area corresponding to the current executable file, so that the first fault diagnosis data address information covers the second fault diagnosis data address information, thereby obtaining the target executable file;

[0085] Based on the target executable file, determine the version of the target fault diagnosis function.

[0086] Optionally, the target fault diagnosis function version determination module 303 can be specifically used for:

[0087] If both the underlying software code and the application diagnostic code are changed, or if the underlying software code is unchanged but the application diagnostic code is changed, the current fault diagnosis code is sequentially compiled, burned, configured, and integrated and saved to obtain the target fault diagnosis function version.

[0088] Optionally, the target fault diagnosis function version determination module 303 can be specifically used for:

[0089] If the underlying software code and the application diagnostic code remain unchanged, the current fault diagnosis function version will be determined as the target fault diagnosis function version.

[0090] The fault diagnosis function version iteration device provided in the embodiments of the present invention can execute the fault diagnosis function version iteration method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0091] Example 4

[0092] Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0093] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0094] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0095] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as method fault diagnosis function version iteration.

[0096] In some embodiments, the method fault diagnosis function version iteration may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method fault diagnosis function version iteration described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the method fault diagnosis function version iteration by any other suitable means (e.g., by means of firmware).

[0097] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0098] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0099] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0100] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0101] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0102] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0103] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0104] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for version iteration of fault diagnosis function, characterized in that, include: Obtain the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnosis code; The current fault diagnosis code is compared with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed. If the underlying software code changes but the application diagnostic code does not, the target fault diagnosis function version is determined based on the automatic script cutter, according to the historical fault diagnosis function version corresponding to the historical fault diagnosis function version and the current fault diagnosis code. The automatic script executor determines the target fault diagnosis function version based on the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code, including: Generate the current executable file based on the underlying software code corresponding to the current fault diagnosis code; Based on the automatic script executor, the target fault diagnosis function version is determined according to the historical executable file corresponding to the historical fault diagnosis function version and the current executable file; The automatic script executor determines the target fault diagnosis function version based on the historical executable file corresponding to the historical fault diagnosis function version and the current executable file, including: The automatic cut script executor performs cut processing on the historical executable file to determine the address information of the first fault diagnosis data in the historical executable file; Based on the automatic cut script executor and the first fault diagnosis data address information, the current executable file is pasted and overwritten to obtain the target executable file and determine the target fault diagnosis function version.

2. The method according to claim 1, characterized in that, The step of cutting the historical executable file based on the automatic cut script executor and determining the address information of the first fault diagnosis data in the historical executable file includes: Determine the first data storage area corresponding to the first fault diagnosis data address information in the historical executable file; Based on the cut function in the automatic cut script executor, the first data storage area corresponding to the historical executable file is cut to obtain the first fault diagnosis data address information corresponding to the historical executable file.

3. The method according to claim 1, characterized in that, The step of pasting and overwriting the current executable file based on the automatic cut script executor and the first fault diagnosis data address information to obtain the target executable file and determine the target fault diagnosis function version includes: Determine the second data storage area corresponding to the second fault diagnosis data address information in the current executable file; Based on the paste function in the automatic cut script executor, the first fault diagnosis data address information is pasted into the second data storage area corresponding to the current executable file, so that the first fault diagnosis data address information covers the second fault diagnosis data address information, thereby obtaining the target executable file; Based on the target executable file, determine the version of the target fault diagnosis function.

4. The method according to claim 1, characterized in that, The step of comparing the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed includes: If both the underlying software code and the application diagnostic code are changed, or if the underlying software code is unchanged but the application diagnostic code is changed, the current fault diagnosis code is sequentially compiled, burned, configured, and integrated and saved to obtain the target fault diagnosis function version.

5. The method according to claim 1, characterized in that, The step of comparing the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version to determine whether the underlying software code and the application diagnosis code have changed includes: If the underlying software code and the application diagnostic code remain unchanged, the current fault diagnosis function version will be determined as the target fault diagnosis function version.

6. A fault diagnosis function version iteration device, characterized in that, The apparatus, applied to the fault diagnosis function version iteration method as described in claim 1, comprises: The current fault diagnosis code acquisition module is used to acquire the current fault diagnosis code corresponding to the current fault diagnosis function version, wherein the current fault diagnosis code includes underlying software code and application diagnosis code; The fault diagnosis code comparison module is used to compare the current fault diagnosis code with the historical fault diagnosis code corresponding to the historical fault diagnosis function version, so as to determine whether the underlying software code and the application diagnosis code have changed respectively. The target fault diagnosis function version determination module is used to determine the target fault diagnosis function version based on the historical fault diagnosis code corresponding to the historical fault diagnosis function version and the current fault diagnosis code, when the underlying software code has changed but the application diagnosis code has not changed, using an automatic script cutter.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the fault diagnosis function version iteration method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the fault diagnosis function version iteration method according to any one of claims 1-5.

Images