Method and apparatus for device diagnosis based on driving function

Abstract

The application discloses a device diagnosis method and device based on a driving function, and the method comprises the following steps: when a diagnosis service request about a target device sent by a client is detected, at least one driving file matched with the diagnosis service request is loaded from a dynamic link library corresponding to a device server, each driving file comprises at least one driving function; a service corresponding to each driving function is executed to diagnose the target device, and a diagnosis result corresponding to the diagnosis service request is obtained. It can be seen that the driving function used for diagnosing the device can be written in the dynamic link library, the diagnosis service request is received, the driving file in the dynamic link library is called to the device server, and the driving function in the driving file is directly executed in the device server to meet the diagnosis requirement of the device, so that the development difficulty of the diagnosis program is reduced, and the calling efficiency of the diagnosis function is improved.

Description

Technical Field

[0001] This invention relates to the field of equipment fault diagnosis technology, and in particular to a method and apparatus for equipment diagnosis based on driving functions. Background Technology

[0002] In the field of equipment diagnostics, diagnostic functions within pre-written diagnostic programs are typically used to analyze collected equipment data to diagnose the equipment. However, writing all necessary diagnostic functions within a single program leads to significant code complexity. Furthermore, developing new functionalities requires developers to understand the content of each function and their logical relationships, increasing development difficulty, reducing efficiency, and hindering the expansion of diagnostic capabilities.

[0003] To reduce the development complexity of diagnostic programs, different diagnostic functions can be written as separate diagnostic programs. Inter-process communication (IPC) or network protocol communication (RPC, etc.) can then be used to call these functions within different programs. For example, diagnostic program A collects device data and transmits it to diagnostic program B via a network protocol interface. Diagnostic program B then analyzes the device data to obtain diagnostic results. However, in practice, it has been found that the number of processes involved in mutual calls between diagnostic functions within different programs is relatively large. Especially when the programming languages ​​of different diagnostic programs are incompatible, this further increases the difficulty of calling the diagnostic functions, thereby reducing their efficiency.

[0004] Therefore, it is particularly important to improve the calling efficiency of diagnostic functions while reducing the development difficulty of diagnostic programs. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a device diagnosis method and apparatus based on driver functions, which can improve the calling efficiency of diagnostic functions while reducing the development difficulty of diagnostic programs.

[0006] To address the aforementioned technical problems, the first aspect of this invention discloses a device diagnosis method based on a driver function, the method being applied to a device server, the method comprising:

[0007] When a diagnostic service request for the target device is detected from a client, at least one driver file matching the diagnostic service request is loaded from the dynamic link library corresponding to the device server. Each driver file includes at least one driver function.

[0008] Execute the service corresponding to each of the aforementioned driver functions to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request.

[0009] As an optional implementation, in the first aspect of the present invention, the method further includes:

[0010] Determine the main diagnostic process corresponding to the diagnostic service request and one or more sub-processes corresponding to the main diagnostic process;

[0011] From all the described subprocesses, determine the target subprocess that needs to be started;

[0012] Loading at least one driver file matching the diagnostic service request from the dynamic link library corresponding to the device server includes:

[0013] Load at least one driver file that matches the target subprocess from the dynamic link library corresponding to the device server.

[0014] As an optional implementation, in the first aspect of the present invention, the method further includes:

[0015] After the main diagnostic process and at least one of the child processes are started, for each of the started child processes, when the main diagnostic process initiates data communication to the child process, the corresponding feedback detection operation of the child process is executed to obtain the detection result. The feedback detection operation is used to detect whether the process processing result returned by the child process is received.

[0016] For each of the started child processes, when the detection result indicates that no process processing result has been received from the child process, it is determined whether the interval between the execution time of the latest feedback detection operation and the current time is greater than or equal to the preset polling listening period corresponding to the child process. If the determination result is yes, the feedback detection operation corresponding to the child process is re-executed until the process processing result returned by the child process is obtained.

[0017] As an optional implementation, in the first aspect of the present invention, loading at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server includes:

[0018] Based on the function calling tool corresponding to the device server, at least one driver file matching the target subprocess is loaded from the dynamic link library corresponding to the device server. The function calling tool is used for interaction between the device server and the dynamic link library written in any programming language.

[0019] Furthermore, the method further includes:

[0020] In the class library corresponding to the function calling tool, each driver function is mapped to a mapping function of a preset type.

[0021] Each driver function is updated to a mapping function mapped from that driver function, and the execution of the service corresponding to each driver function is triggered to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request.

[0022] As an optional implementation, in the first aspect of the present invention, loading at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server based on the function call tool corresponding to the device server includes:

[0023] Identify all driver files that the target subprocess needs to call;

[0024] When all the driver files include at least one independent driver file, the independent driver file is loaded from the dynamic link library based on the function call tool corresponding to the device server and the pre-determined path address of the independent driver file in the dynamic link library. The independent driver file is a driver file that has no association with any of the other driver files; and / or,

[0025] When all the driver files include at least one driver file combination, based on the function call tool corresponding to the device server and the environment variables corresponding to the driver file combination that are predetermined, all driver files in the driver file combination are loaded from the dynamic link library. The driver file combination includes at least two driver files that are related. The environment variables are used to point to the path address of the target folder corresponding to the driver file combination in the dynamic link library. The target folder is a folder that contains all the driver files in the driver file combination.

[0026] As an optional implementation, in the first aspect of the present invention, mapping each driver function to a mapping function of a preset type in the class library corresponding to the function calling tool includes:

[0027] Determine the function attributes that need to be retained in each of the aforementioned driving functions;

[0028] Based on the function attributes that need to be retained in each driver function, the driver function is mapped to a mapping function of a preset type in the class library corresponding to the function calling tool. The function attributes of the mapping function mapped from each driver function match the function attributes that need to be retained by the driver function.

[0029] As an optional implementation, in the first aspect of the present invention, the step of mapping the driver function to a mapping function of a preset type in the class library corresponding to the function calling tool according to the function attributes to be retained in each driver function includes:

[0030] For each driver function, based on the function attributes that the driver function needs to retain, attribute declaration code corresponding to the driver function is generated in the class library corresponding to the function calling tool. Then, based on the attribute declaration code, the mapping function generated by the driver function is mapped in the class library to a mapping function of a preset type; or...

[0031] For each of the driving functions, the driving function is mapped to an initial mapping function of a preset type in the class library corresponding to the function calling tool, and the attribute declaration code corresponding to the driving function is inserted into the initial mapping function to obtain the mapping function mapped by the driving function. The attribute declaration code corresponding to each driving function is used to declare the function attributes that the driving function needs to retain.

[0032] As an optional implementation, in the first aspect of the present invention, all the driving functions include one or more of the following: a first type of driving function for starting communication services, a second type of driving function for collecting diagnostic data, and a third type of driving function for analyzing diagnostic data.

[0033] The execution of the service corresponding to each of the driver functions to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request includes:

[0034] When all the aforementioned driver functions include the first type of driver function, based on the first type of driver function, the communication device between the device server and the target device is invoked. The communication device is used to implement the interaction between the device server and the target device to obtain the diagnostic result corresponding to the diagnostic service request; and / or

[0035] When all the aforementioned driver functions include the second type of driver function, based on the communication device between the device server and the target device and the second type of driver function, diagnostic data matching the second type of driver function in the device data of the target device is collected and sent to the device server as the diagnostic result corresponding to the diagnostic service request; and / or,

[0036] When all the driving functions include the third type of driving function, the diagnostic data collected from the target device is analyzed based on the third type of driving function to obtain the analysis result, which is used as the diagnostic result corresponding to the diagnostic service request.

[0037] A second aspect of the present invention discloses a device diagnostic apparatus based on a driver function, the apparatus being applied to a device server, the apparatus comprising:

[0038] A function loading module is used to load at least one driver file matching the diagnostic service request from the dynamic link library corresponding to the device server when a diagnostic service request for the target device is detected by the client. Each driver file includes at least one driver function.

[0039] The diagnostic module is used to execute the service corresponding to each of the driving functions to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request.

[0040] As an optional implementation, in a second aspect of the invention, the apparatus further includes:

[0041] The determination module is used to determine the diagnostic main process corresponding to the diagnostic service request and one or more sub-processes corresponding to the diagnostic main process, and to determine the target sub-process that needs to be started from all the sub-processes.

[0042] The specific method by which the function loading module loads at least one driver file matching the diagnostic service request from the dynamic link library corresponding to the device server includes:

[0043] Load at least one driver file that matches the target subprocess from the dynamic link library corresponding to the device server.

[0044] As an optional implementation, in the second aspect of the present invention, a polling monitoring module is used to, after the diagnostic main process and at least one of the child processes are started, execute a feedback detection operation corresponding to each of the started child processes when the diagnostic main process initiates data communication to the child process, and obtain a detection result. The feedback detection operation is used to detect whether the process processing result returned by the child process is received.

[0045] The judgment module is used to determine, for each of the started child processes, whether the interval between the execution time of the latest feedback detection operation and the current time is greater than or equal to the preset polling listening period corresponding to the child process when the detection result indicates that no process processing result has been received from the child process. When the judgment result is yes, the polling listening module is triggered to re-execute the feedback detection operation corresponding to the child process until the process processing result returned by the child process is obtained.

[0046] As an optional implementation, in the second aspect of the present invention, the specific method by which the function loading module loads at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server includes:

[0047] Based on the function calling tool corresponding to the device server, at least one driver file matching the target subprocess is loaded from the dynamic link library corresponding to the device server. The function calling tool is used for interaction between the device server and the dynamic link library written in any programming language.

[0048] The device also includes:

[0049] The function mapping module is used to map each driver function to a mapping function of a preset type in the class library corresponding to the function calling tool;

[0050] The update module is used to update each of the driver functions to a mapping function mapped from the driver function, and to trigger the diagnostic module to execute the service corresponding to each of the driver functions in order to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request.

[0051] As an optional implementation, in the second aspect of the present invention, the specific method by which the function loading module loads at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server based on the function calling tool corresponding to the device server includes:

[0052] Identify all driver files that the target subprocess needs to call;

[0053] When all the driver files include at least one independent driver file, the independent driver file is loaded from the dynamic link library based on the function call tool corresponding to the device server and the pre-determined path address of the independent driver file in the dynamic link library. The independent driver file is a driver file that has no association with any of the other driver files; and / or,

[0054] When all the driver files include at least one driver file combination, based on the function call tool corresponding to the device server and the environment variables corresponding to the driver file combination that are predetermined, all driver files in the driver file combination are loaded from the dynamic link library. The driver file combination includes at least two driver files that are related. The environment variables are used to point to the path address of the target folder corresponding to the driver file combination in the dynamic link library. The target folder is a folder that contains all the driver files in the driver file combination.

[0055] As an optional implementation, in the second aspect of the present invention, the specific method by which the function mapping module maps each driver function to a mapping function of a preset type in the class library corresponding to the function calling tool includes:

[0056] Determine the function attributes that need to be retained in each of the aforementioned driving functions;

[0057] Based on the function attributes that need to be retained in each driver function, the driver function is mapped to a mapping function of a preset type in the class library corresponding to the function calling tool. The function attributes of the mapping function mapped from each driver function match the function attributes that need to be retained by the driver function.

[0058] As an optional implementation, in the second aspect of the present invention, the function mapping module maps the driver function into a mapping function of a preset type in the class library corresponding to the function calling tool according to the function attributes that need to be retained in each driver function. The specific method includes:

[0059] For each driver function, based on the function attributes that the driver function needs to retain, attribute declaration code corresponding to the driver function is generated in the class library corresponding to the function calling tool. Then, based on the attribute declaration code, the mapping function generated by the driver function is mapped in the class library to a mapping function of a preset type; or...

[0060] For each of the driving functions, the driving function is mapped to an initial mapping function of a preset type in the class library corresponding to the function calling tool, and the attribute declaration code corresponding to the driving function is inserted into the initial mapping function to obtain the mapping function mapped by the driving function. The attribute declaration code corresponding to each driving function is used to declare the function attributes that the driving function needs to retain.

[0061] As an optional implementation, in the second aspect of the present invention, all the driving functions include one or more of the following: a first type of driving function for starting communication services, a second type of driving function for collecting diagnostic data, and a third type of driving function for analyzing diagnostic data.

[0062] The diagnostic module executes the service corresponding to each of the driver functions to diagnose the target device, and the specific methods for obtaining the diagnostic results corresponding to the diagnostic service request include:

[0063] When all the aforementioned driver functions include the first type of driver function, based on the first type of driver function, the communication device between the device server and the target device is invoked. The communication device is used to implement the interaction between the device server and the target device to obtain the diagnostic result corresponding to the diagnostic service request; and / or

[0064] When all the aforementioned driver functions include the second type of driver function, based on the communication device between the device server and the target device and the second type of driver function, diagnostic data matching the second type of driver function in the device data of the target device is collected and sent to the device server as the diagnostic result corresponding to the diagnostic service request; and / or,

[0065] When all the driving functions include the third type of driving function, the diagnostic data collected from the target device is analyzed based on the third type of driving function to obtain the analysis result, which is used as the diagnostic result corresponding to the diagnostic service request.

[0066] A third aspect of the present invention discloses another device diagnostic apparatus based on a driving function, the apparatus comprising:

[0067] Memory containing executable program code;

[0068] A processor coupled to the memory;

[0069] The processor calls the executable program code stored in the memory to execute the device diagnostic method based on driver functions disclosed in the first aspect of the present invention.

[0070] The fourth aspect of the present invention discloses a computer storage medium storing computer instructions, which, when invoked, are used to execute the device diagnostic method based on driver functions disclosed in the first aspect of the present invention.

[0071] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0072] In this embodiment of the invention, when a diagnostic service request for a target device is detected from a client, at least one driver file matching the diagnostic service request is loaded from the dynamic link library corresponding to the device server. Each driver file includes at least one driver function. The service corresponding to each driver function is executed to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request. Therefore, implementing this invention allows the driver functions for diagnosing devices to be written in a dynamic link library. When a diagnostic service request is received, the driver file in the dynamic link library is called to the device server, and the driver function in the driver file is directly executed on the device server to meet the device's diagnostic needs. This reduces the need to write all complex driver functions into the same diagnostic program or to write multiple driver functions into multiple diagnostic programs, thereby reducing the development difficulty of the diagnostic program while improving the calling efficiency of the diagnostic function. Attached Figure Description

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

[0074] Figure 1 This is a flowchart illustrating a device diagnostic method based on a driving function disclosed in an embodiment of the present invention;

[0075] Figure 2 This is a flowchart illustrating another device diagnostic method based on a driving function disclosed in an embodiment of the present invention;

[0076] Figure 3 This is a schematic diagram of the structure of a device diagnostic device based on a driving function disclosed in an embodiment of the present invention;

[0077] Figure 4 This is a schematic diagram of another device diagnostic device based on a driving function disclosed in an embodiment of the present invention;

[0078] Figure 5 This is a schematic diagram of another device diagnostic device based on a driving function disclosed in an embodiment of the present invention. Detailed Implementation

[0079] 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 are within the scope of protection of the present invention.

[0080] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or end that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or ends.

[0081] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0082] This invention discloses a device diagnostic method and apparatus based on driver functions. It enables the driver functions for device diagnosis to be written in a dynamic link library. Upon receiving a diagnostic service request, the driver file in the dynamic link library is called to the device server, and the driver functions in the driver file are directly executed on the device server to meet the device's diagnostic needs. This reduces the need to write all the complex driver functions into the same diagnostic program or to write multiple driver functions into multiple diagnostic programs, thereby reducing the development difficulty of the diagnostic program while improving the calling efficiency of the diagnostic functions. Detailed explanations follow.

[0083] Example 1

[0084] Please see Figure 1 , Figure 1 This is a flowchart illustrating a device diagnostic method based on a driving function disclosed in an embodiment of the present invention. Figure 1The described device diagnostic method based on driver functions can be applied to a device server, which can be used to diagnose devices. This device server can include a local server, such as an OBD (On-Board Diagnostic) diagnostic tool for vehicles, or a cloud server; this embodiment of the invention does not impose limitations. Figure 1 As shown, this device diagnostic method based on driver functions may include the following operations:

[0085] 101. When a diagnostic service request for the target device is detected from the client, at least one driver file matching the diagnostic service request is loaded from the dynamic link library corresponding to the device server. Each driver file includes at least one driver function.

[0086] Optionally, the client may include a terminal with browser functionality (such as IE, Chrome, or other web browsers) and / or a terminal with application functionality (such as an API). The diagnostic service request may include the client sending a diagnostic service request about the target device to the device server via a browser or application. Preferably, the client sends the diagnostic service request about the target device to the device server via a browser. Further optionally, the client sending the diagnostic service request about the target device to the device server via a browser may include: the client sending the diagnostic service request about the target device to the device server on the corresponding page of the device server based on the browser and the access identifier and / or the service request identifier corresponding to the device server. It is evident that this allows for device diagnosis through a browser architecture, improving the development efficiency and maintenance convenience of the diagnostic program. It eliminates the need for user downloads, improving user operation convenience and facilitating cross-platform services, reducing the occurrence of poor user experience due to the need to download diagnostic programs.

[0087] Optionally, the target device can include any hardware device, such as a vehicle. Optionally, for vehicles, a diagnostic service request can be used to request at least one of the following vehicle system diagnostic services, programming services, repair guidance services, and ECU flashing services; further optionally, the vehicle system may include one or more of the following: airbag control system, alarm control system, antenna control system, automatic control system, body control system, cabin heater control system, central control system, charging control system, communication control system, door control system, electronic braking control system, HVAC (Heating, Ventilation and Air Conditioning) system, electronic throttle control system, parking assist control system, power mirror control system, power seat control system, radiator fan control system, seat heater control system, steering column control system, steering control system, steering mount control system, sunroof control system, transfer case control system, general electronic control system, sunroof control system, suspension control system, tire pressure control system, traction control system, and trailer light control system; still further optionally, diagnostic services may include reading version information, reading fault codes, clearing fault codes, reading data streams, freezing frames, action testing, battery matching, maintenance reset, brake pad replacement, throttle matching, steering angle reset, and ABS (Anti-lock Braking)... System (Anti-lock Braking System) exhaust, DPF (Diesel Particulate Filter) regeneration, airbag reset, suspension matching, tire pressure reset, transmission matching, injector coding, gear learning, transport mode deactivation, headlight matching, sunroof initialization, seat calibration, door and window calibration, start-stop settings, ERG (Exhaust Gas Recirculation) self-learning, odometer tuning, language settings, tire modification, A / F tuning, electronic water pump activation, NOx (nitrogen oxides) reset, urea reset, turbine blade learning, cylinder balance testing, etc. Programming and / or ECU program flashing services are used to import, update, clear, and repair at least one of the following vehicle system programs to meet the functional requirements of the vehicle system, such as seat preference settings, fog light settings, automatic window closing, etc. This enriches the diagnostic functions provided by the equipment server to meet the diverse equipment diagnostic needs of users, such as vehicle diagnostic needs.

[0088] Optionally, the device server may include one or more of the following: server loading unit, data communication unit, main process unit, sub-process unit, driver calling unit, communication device driver unit, and diagnostic unit. Optionally, the server loading unit can be used to uniformly manage one or more of the following: the application programming interface corresponding to the device server, the main diagnostic process and its child processes corresponding to diagnostic business requests, data communication, service startup, and port mapping. The server loading unit can be built based on Node.js. The data communication unit can be used to manage data transmission and reception between the main process and child processes, and data transmission and reception between the main process and the page corresponding to the device server. The main process unit can be used to manage all child processes corresponding to the diagnostic main process, such as starting child processes and listening to diagnostic data returned by child processes. It can also be used to provide one or more of the following: API interface for the page corresponding to the device server, event sending and receiving, and data communication with the data communication unit. The child process unit can be used to call the driver calling unit to call the driver function, and can also be used to return diagnostic data to the main process unit. The driver calling unit can be used to call the driver file in the dynamic link library and then call the driver function, and can also be used to map the driver function to the required mapping function. The diagnostic unit is used to diagnose the device based on the driver function. The communication device driver unit is used to call the communication device between the device server and the target device, so that the device server can send instructions to the target device, and the target device can send diagnostic data back to the device server. This decouples different functions on the device server, further reducing the difficulty of developing diagnostic programs and improving the accuracy and reliability of the device diagnostic process, as well as the traceability of the device diagnostic process.

[0089] Optionally, the operation in step 101 can be performed by the aforementioned driver calling unit.

[0090] In this embodiment of the invention, optionally, the driver function in the driver file is used to drive the data transmission and function response between the device server and the hardware device to realize the diagnostic services of the target device. The hardware device includes the target device and the communication device between the device server and the target device.

[0091] 102. Execute the business corresponding to each driver function to diagnose the target device and obtain the diagnostic results corresponding to the diagnostic business request.

[0092] Optionally, all driver functions may include one or more of the following: a first type of driver function for starting communication services, a second type of driver function for collecting diagnostic data, and a third type of driver function for analyzing diagnostic data.

[0093] As an optional implementation, executing the service corresponding to each driver function to diagnose the target device and obtain the diagnostic results corresponding to the diagnostic service request may include:

[0094] When all driver functions include a first-type driver function, based on the first-type driver function, the communication device between the device server and the target device is invoked. This communication device is used to enable interaction between the device server and the target device to obtain the diagnostic results corresponding to the diagnostic service request; and / or,

[0095] When all driver functions include the second type of driver function, based on the communication device between the device server and the target device and the second type of driver function, diagnostic data matching the second type of driver function in the target device's device data is collected and sent to the device server as the diagnostic result corresponding to the diagnostic service request; and / or,

[0096] When all driver functions include a third type of driver function, the diagnostic data collected from the target device is analyzed based on the third type of driver function to obtain the analysis results, which are used as the diagnostic results corresponding to the diagnostic service request.

[0097] In this optional implementation, preferably, the communication device may include a device for connecting the device server and the target device based on wireless communication methods (such as Bluetooth, GPRS, WIFI, Zigbee, etc.). When the target device is a vehicle, preferably, the communication device may be a VCI communication device.

[0098] It is evident that implementing this optional implementation method can perform different driving operations based on different types of driving functions. The diversity of driving functions improves the diversity and flexibility of device diagnosis based on driving functions. Furthermore, by unifying the management and operation of the driving functions that call the communication device with the driving functions of the diagnostic service, the number of modules required to develop the communication device calling function can be reduced, the device server can be simplified, and the development difficulty of the diagnostic program can be reduced.

[0099] In this embodiment of the invention, optionally, the diagnostic unit and / or communication device driver unit in the device server can perform the relevant operations of step 102. Specifically, when the driver function includes a first type of driver function, the communication device driver unit performs the operation related to the first driver function to call the communication device. When the driver function includes a second type of driver function and / or a third type of driver function, the diagnostic unit performs the operation related to the second driver function and / or the third driver function.

[0100] As can be seen, implementing the embodiments of the present invention enables the driver functions for diagnosing devices to be written in a dynamic link library. When a diagnostic service request is received, the driver file in the dynamic link library is called to the device server, and the driver function in the driver file is directly executed on the device server to meet the diagnostic requirements of the device. This reduces the occurrence of writing all the complex driver functions in the same diagnostic program or writing multiple driver functions in multiple diagnostic programs, so as to improve the calling efficiency of diagnostic functions while reducing the development difficulty of diagnostic programs.

[0101] In an optional embodiment, the method may further include:

[0102] Based on the data interface between the device server and the client, the diagnostic results and / or the diagnostic instructions corresponding to the diagnostic results are output to the page corresponding to the device server. The client can access the page corresponding to the device server through the access identifier corresponding to the device server.

[0103] As can be seen, implementing this optional embodiment can display the diagnostic results on a page accessible to the client via an access identifier, thus improving the convenience of displaying the diagnostic results.

[0104] Example 2

[0105] Please see Figure 2 , Figure 2 This is a flowchart illustrating another device diagnostic method based on a driving function disclosed in an embodiment of the present invention. Figure 2 The described device diagnostic method based on driver functions can be applied to a device server, which can be used to diagnose devices. This device server can include a local server, such as an OBD (On-Board Diagnostic) diagnostic tool for vehicles, or a cloud server; this embodiment of the invention does not impose limitations. Figure 2 As shown, this device diagnostic method based on driver functions may include the following operations:

[0106] 201. When a diagnostic service request for the target device is detected from the client, determine the main diagnostic process corresponding to the diagnostic service request and one or more sub-processes corresponding to the main diagnostic process.

[0107] Optionally, step 201 can be performed by the main process unit described in Embodiment 1.

[0108] As an optional implementation, determining the diagnostic main process corresponding to the diagnostic service request and one or more child processes corresponding to the diagnostic main process may include:

[0109] Determine the main diagnostic process corresponding to the diagnostic service request and one or more preset subprocesses corresponding to the pre-defined main diagnostic process;

[0110] Determine whether there is at least one unnecessary subprocess among all preset subprocesses that does not meet the diagnostic conditions;

[0111] When the judgment result is yes, unnecessary child processes are deleted from all preset child processes, resulting in one or more child processes corresponding to the diagnostic main process.

[0112] It is evident that implementing this optional implementation method can reduce the number of unnecessary processes, improve device diagnostic efficiency, and reduce the load on the device server.

[0113] In this optional implementation, determining whether there is at least one unnecessary subprocess among all preset subprocesses that does not meet the diagnostic conditions may include:

[0114] For each preset subprocess, determine whether the process type of the preset subprocess matches the device type of the target device. If the result is negative, determine that at least one unnecessary subprocess exists among all preset subprocesses; and / or,

[0115] For each preset subprocess, determine whether the device server stores the corresponding valid diagnostic result of the preset subprocess. If the result is yes, determine that there is at least one unnecessary subprocess among all preset subprocesses.

[0116] As can be seen, implementing this optional implementation method can filter unnecessary subprocesses based on the process type of the preset subprocess and the effective diagnostic results corresponding to the preset subprocess, thereby improving the accuracy and reliability of determining whether there are unnecessary subprocesses.

[0117] 202. Determine the target subprocess that needs to be started from all subprocesses.

[0118] In this embodiment of the invention, optionally, multiple subprocesses can be running simultaneously. That is, the number of target subprocesses to be started can be equal to 1 or greater than 1. This embodiment of the invention does not limit this.

[0119] Optionally, step 202 can be executed by the main process unit or the subprocess unit described in Embodiment 1.

[0120] 203. Load at least one driver file that matches the target subprocess from the dynamic link library corresponding to the device server. Each driver file includes at least one driver function.

[0121] Optionally, step 203 can be executed by the driver calling unit described in Embodiment 1. Specifically, the subprocess unit can call the driver calling unit, and then the driver calling unit can execute step 203.

[0122] As an optional implementation, loading at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server may include:

[0123] Based on the function call tool corresponding to the device server, at least one driver file matching the target subprocess is loaded from the dynamic link library corresponding to the device server.

[0124] In this optional embodiment, the function call tool can be used for interaction between the device server and dynamic link libraries written in any programming language, or it can be used only for interaction between the device server and dynamic link libraries written in a specific programming language. This embodiment of the invention does not impose any limitations. Further optionally, the function call tool may include a function call plugin and / or a language interaction interface. Preferably, the function call plugin is compatible with the device server's setup environment. For example, when the device server is a server built on Node.js, the function call plugin can be a Node.js FFI plugin, such as the Node.js FFI plugin. This enables function calls between different programs with mismatched programming languages. For example, the FFI plugin can call driver functions from a dynamic link library written in C++ to a device server written in Java. Furthermore, the aforementioned function call tool can reduce the occurrence of multiple mappings of driver functions, alleviate the load on the device server, and improve the efficiency of device diagnostics.

[0125] As can be seen, implementing this optional implementation method can call the driver file through the function call tool, thereby reducing the occurrence of situations where the driver file cannot be loaded due to the mismatch between the programming language of the dynamic link library and the programming language of the device server, and improving the probability and reliability of successfully loading the driver file.

[0126] In this optional implementation, optionally, loading at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server, based on the function calling tool corresponding to the device server, may include:

[0127] Identify all driver files that the target child process needs to call;

[0128] When all driver files include at least one independent driver file, the independent driver file is loaded from the dynamic link library based on the function call tool corresponding to the device server and the pre-determined path address of the independent driver file in the dynamic link library. Here, the independent driver file is a driver file that has no association with any other driver file among all driver files; and / or,

[0129] When all driver files include at least one driver file combination, based on the function call tool corresponding to the device server and the environment variables corresponding to the pre-determined driver file combination, all driver files in the driver file combination are loaded from the dynamic link library. The driver file combination includes at least two driver files that are related. The environment variables are used to point to the path address of the target folder corresponding to the driver file combination in the dynamic link library. The target folder is the folder containing all driver files in the driver file combination.

[0130] In this optional implementation, the association may further include the dependency relationship between driving functions. Optionally, the existence of a dependency relationship between any two driving functions means that a certain first parameter of one driving function is dependent on a certain second parameter of the other driving function. That is, when one of the first parameter and the second parameter changes, the other parameter changes accordingly. Optionally, the first parameter and the second parameter can be the same parameter or different parameters. This embodiment of the invention does not limit the specific parameters.

[0131] As can be seen, implementing this optional implementation method can directly load the driver file through its path address when there is no association between the driver file and other driver files, reducing unnecessary files loaded to the device server and improving the accuracy of driver file loading. When there is an association between the driver file and other driver files, the driver file is loaded according to the environment variables corresponding to all the associated driver files, reducing the occurrence of missing variable parameter information in the driver file due to splitting the loading of associated driver files, and improving the comprehensiveness and reliability of driver file loading.

[0132] 204. Execute the service corresponding to each driver function to diagnose the target device and obtain the diagnostic results corresponding to the diagnostic service request.

[0133] For further descriptions of step 204 in this embodiment of the invention, please refer to the detailed description of step 102 in Embodiment 1. These descriptions will not be repeated in this embodiment of the invention.

[0134] As can be seen, implementing the embodiments of the present invention allows the driver functions for diagnosing devices to be written in a dynamic link library. When a diagnostic service request is received, the driver file in the dynamic link library is called to the device server, and the driver function in the driver file is directly executed on the device server to meet the device's diagnostic needs. This reduces the occurrence of writing all complex driver functions in the same diagnostic program or writing multiple driver functions in multiple diagnostic programs, thereby reducing the development difficulty of the diagnostic program while improving the calling efficiency of the diagnostic function. In addition, determining the target subprocess to be executed from all subprocesses corresponding to the diagnostic main process corresponding to the diagnostic service request and loading the driver function matching the target subprocess can improve the orderliness and accuracy of the diagnostic service process processing and reduce the occurrence of congestion in the driver function loading channel.

[0135] In an optional embodiment, the method may further include:

[0136] After the diagnostic main process and at least one child process are started, for each started child process, when the diagnostic main process initiates data communication to the child process, the corresponding feedback detection operation of the child process is executed to obtain the detection result. The feedback detection operation is used to detect whether the process processing result returned by the child process has been received.

[0137] For each started child process, when the detection result indicates that no process processing result has been received from the child process, it is determined whether the interval between the execution time of the latest feedback detection operation and the current time is greater than or equal to the preset polling monitoring period corresponding to the child process. If the determination result is yes, the feedback detection operation corresponding to the child process is re-executed until the process processing result returned by the child process is obtained. In this optional embodiment, the method may further include:

[0138] For each started child process, when the process processing result returned by the child process is detected, the polling listening task corresponding to the child process is terminated.

[0139] As can be seen, implementing this optional embodiment can periodically monitor the process processing results returned by the child process through polling, thereby reducing the occurrence of process processing result reception failures that lead to the inability to determine the diagnostic results, and improving the accuracy and reliability of the diagnostic process processing.

[0140] In another alternative embodiment, the method may further include:

[0141] In the class library corresponding to the function call tool, each driver function is mapped to a mapping function of a preset type.

[0142] Each driver function is updated to a mapping function mapped from that driver function, and the above-mentioned execution of the business corresponding to each driver function is triggered to diagnose the target device and obtain the diagnostic results corresponding to the diagnostic business request.

[0143] As can be seen, by implementing this optional embodiment and mapping the driver function to the mapping function, the occurrence of situations where the driver function cannot be called due to incompatibility between the device server and the driver function can be reduced, thereby increasing the probability of successfully calling the driver function and improving the accuracy and reliability of calling the driver function.

[0144] In this optional embodiment, as an optional implementation, mapping each driver function to a mapping function of a preset type in the class library corresponding to the function call tool may include:

[0145] Determine the function attributes that need to be retained in each driver function;

[0146] Based on the function attributes that need to be retained in each driver function, the driver function is mapped to a mapping function of a preset type in the class library corresponding to the function calling tool. The function attributes of the mapping function mapped from each driver function match the function attributes that need to be retained by the driver function.

[0147] In this optional implementation, the function attributes that need to be retained in each driver function may include one or more of the following: function name, function type, variable type of input parameters (e.g., ref-napi), data array (e.g., ref-array-napi), structure type (e.g., ref-struct-napi), data queue, enumeration type, string type, etc., wherein the input parameters are used to represent the variable parameters required to execute the diagnostic business request.

[0148] In this optional implementation, the default type can be JS (JavaScript), and the mapping function can be a JS function.

[0149] As can be seen, implementing this optional implementation method can preserve the function attributes in the driver function when mapping the driver function, thereby preserving the functionality of the driver function while making the mapping function compatible with the device server, which is beneficial to improving the accuracy and reliability of diagnosing the device through the driver function.

[0150] In this optional implementation, optionally, based on the function attributes that need to be retained in each driver function, the driver function is mapped to a mapping function of a preset type in the class library corresponding to the function calling tool. This may include:

[0151] For each driver function, based on the function attributes that the driver function needs to retain, the corresponding attribute declaration code is generated in the class library corresponding to the function calling tool. Then, based on the attribute declaration code, the mapping function generated by the driver function is mapped in the class library to a mapping function of a preset type; or...

[0152] For each driver function, the driver function is mapped to an initial mapping function of a preset type in the class library corresponding to the function calling tool. The property declaration code corresponding to the driver function is inserted into the initial mapping function to obtain the mapping function mapped by the driver function. The property declaration code corresponding to each driver function is used to declare the function properties that the driver function needs to retain.

[0153] For example, the following property declaration code can be used to implement driver function mapping:

[0154] const ffi=require('ffi-napi');

[0155] const path=require('path');

[0156] var ref=require('ref-napi');

[0157] var rint = ref.types.int;

[0158] var dllpath = path.resolve(__dirname, '. / path to driver file');

[0159] var MyDellDemo=new ffi.Library(path.resolve(dllpath);

[0160] {PrintSum:['string',['int','int']],PrintSum:['string',[rint,rint]]};

[0161] Here, "var ref=require('ref-napi')" indicates that the input parameter ref-napi is imported in advance; "var rint=ref.types.int" indicates that the variable type of the input parameter is declared in advance; "var dllpath=path.resolve(__dirname,'. / path to driver file')" indicates that the DDL file is loaded directly without specifying the extension to map the functions in the DDL file to JS functions; "PrintSum" indicates that the function name of the mapped function is consistent with the function name defined in the driver function; "string" indicates that the function returning a string type is loaded; "['int','int']" indicates that the variable type of the input parameter defined in the driver file is of type int and must be consistent when mapped to the JS function; "{PrintSum:['string',['int','int']],PrintSum:['string',[rint,rint]]}" indicates that the previously declared variable type can be used directly, i.e., "var The variable type declared by "rint = ref.types.int" ensures that the input parameter of type int is consistent with the variable type in the driving function.

[0162] As can be seen, implementing this optional implementation method can also map the driving function based on the attribute declaration code used to declare the function attributes to be retained, or insert the attribute declaration code into the initial mapping function to obtain the mapping function, thereby improving the accuracy and versatility of mapping the driving function to the mapping function.

[0163] In this optional embodiment, as another optional implementation method, the method may further include:

[0164] Determine whether the target mapping function, which is mapped from all the driver functions in the target driver file, exists in the class library corresponding to the function call tool of the device server. If the determination result is negative, trigger the above operation of loading at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server. The target driver file includes a combination of driver files and / or independent driver files corresponding to the target subprocess.

[0165] As can be seen, implementing this optional implementation method loads the driver function only when there is no mapping function in the class library, reducing the occurrence of repeated loading of the driver function, which helps to reduce the load on the device server and improve the efficiency of device diagnosis.

[0166] In this optional implementation, the method may further include:

[0167] When it is determined that the target mapping function is formed by mapping all the driver functions in the target driver file in the class library, it is determined whether the target mapping function meets the pre-set conditions for maintaining validity based on the version information and / or the generation time of the target mapping function. If the determination result is negative, the operation of loading at least one driver file matching the target child process from the dynamic link library corresponding to the device server is triggered.

[0168] As can be seen, implementing this optional embodiment can reload the driver function when the mapping function stored in the class library is invalid, which can reduce the occurrence of situations where the device cannot be diagnosed or diagnostic errors occur due to invalid or expired mapping functions, and is beneficial to improving the accuracy and reliability of device diagnosis.

[0169] In another alternative embodiment, before determining the target subprocess to be started from all subprocesses, the method may further include:

[0170] Based on one or more of the following: device information of the target device, diagnostic service request, process type of each subprocess, and process information currently being processed by the device server, determine the startup order of each subprocess. Optionally, the startup order of each subprocess may overlap with the startup order of other subprocesses.

[0171] Furthermore, after determining the target subprocess to be launched from all subprocesses, the method may further include:

[0172] Determine if any of the remaining child processes are target child processes whose driver files are associated with the driver files of the target child process;

[0173] If the judgment result is negative, the remaining child process of the target is also identified as the target child process, and the above-mentioned operation of loading at least one driver file matching the target child process from the dynamic link library corresponding to the device server is triggered.

[0174] As can be seen, implementing this optional embodiment can determine the processing order of multiple sub-processes based on various information, improving the accuracy and reliability of the determined sub-process startup order. In addition, when there is a relationship between the driver files corresponding to different sub-processes, the driver functions corresponding to the above-mentioned sub-processes are loaded simultaneously, reducing the occurrence of situations where driver files lack variable parameter information or driver functions are loaded repeatedly due to splitting and loading driver files with relationships. This improves the comprehensiveness, reliability and efficiency of driver file loading, and helps to reduce unnecessary load on the device server.

[0175] Example 3

[0176] Please see Figure 3 , Figure 3This is a schematic diagram of a device diagnostic device based on a driving function disclosed in an embodiment of the present invention. Figure 3 The described device diagnostic apparatus based on driver functions can be applied to a device server, which can be used to diagnose devices. This device server can include a local server, such as an OBD (On-Board Diagnostic) diagnostic tool for vehicles, or a cloud server; this embodiment of the invention is not limited thereto. Figure 3 As shown, the device diagnostic apparatus based on the driving function may include:

[0177] The function loading module 301 is used to load at least one driver file matching the diagnostic service request from the dynamic link library corresponding to the device server when a diagnostic service request for the target device is detected by the client. Each driver file includes at least one driver function.

[0178] The diagnostic module 302 is used to execute the service corresponding to each driver function to diagnose the target device and obtain the diagnostic results corresponding to the diagnostic service request.

[0179] It is evident that implementation Figure 3 The described device can write the driver functions for diagnosing the device in a dynamic link library. When a diagnostic service request is received, the device server calls the driver file in the dynamic link library and directly executes the driver functions in the driver file to meet the device's diagnostic needs. This reduces the occurrence of writing all the complex driver functions in the same diagnostic program or writing multiple driver functions in multiple diagnostic programs, thereby reducing the development difficulty of the diagnostic program while improving the calling efficiency of the diagnostic functions.

[0180] In an optional embodiment, such as Figure 4 As shown, the device may further include:

[0181] The determination module 303 is used to determine the diagnostic main process corresponding to the diagnostic service request and one or more child processes corresponding to the diagnostic main process, and to determine the target child process that needs to be started from all child processes;

[0182] The specific method by which the function loading module 301 loads at least one driver file matching the diagnostic service request from the dynamic link library corresponding to the device server may include:

[0183] Load at least one driver file that matches the target child process from the dynamic link library corresponding to the device server.

[0184] It is evident that implementation Figure 4The described device can determine the target subprocess to be executed from all subprocesses corresponding to the main diagnostic process of the diagnostic service request and load the driver function that matches the target subprocess. This can improve the orderliness and accuracy of the diagnostic service process and reduce the occurrence of congestion in the driver function loading channel.

[0185] In another alternative embodiment, such as Figure 4 As shown, the device may further include:

[0186] The polling monitoring module 304 is used to, after the diagnostic main process and at least one child process are started, execute the corresponding feedback detection operation for each of the started child processes when the diagnostic main process initiates data communication to the child process, and obtain the detection result. The feedback detection operation is used to detect whether the process processing result returned by the child process has been received.

[0187] The judgment module 305 is used to determine, for each started child process, whether the interval between the execution time of the latest feedback detection operation and the current time is greater than or equal to the preset polling listening period corresponding to the child process when the detection result indicates that no process processing result has been received from the child process. If the judgment result is yes, the polling listening module 304 is triggered to re-execute the feedback detection operation corresponding to the child process until the process processing result returned by the child process is obtained.

[0188] It is evident that implementation Figure 4 The described device can also periodically monitor the process processing results returned by the child process through polling, thereby reducing the occurrence of process processing result reception failures that lead to inability to determine the diagnostic results, and improving the accuracy and reliability of diagnostic process processing.

[0189] In yet another alternative embodiment, such as Figure 4 As shown, the specific method by which the function loading module 301 loads at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server may include:

[0190] Based on the function call tool corresponding to the device server, at least one driver file matching the target subprocess is loaded from the dynamic link library corresponding to the device server. The function call tool is used for the interaction between the device server and the dynamic link library written in any programming language.

[0191] The device may also include:

[0192] The function mapping module 306 is used to map each driver function to a mapping function of a preset type in the class library corresponding to the function calling tool;

[0193] The update module 307 is used to update each driver function to the mapping function mapped from the driver function, and to trigger the diagnostic module 302 to execute the above-mentioned service corresponding to each driver function in order to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request.

[0194] It is evident that implementation Figure 4 The described device can also call driver files through function call tools, thereby reducing the occurrence of situations where driver files cannot be loaded due to incompatibility between the programming language of the dynamic link library and the programming language of the device server, and improving the probability and reliability of successfully loading driver files. In addition, by mapping driver functions to mapping functions, the occurrence of situations where driver functions cannot be called due to incompatibility between the device server and driver functions can be reduced, increasing the probability of successfully calling driver functions and improving the accuracy and reliability of calling driver functions.

[0195] In yet another alternative embodiment, such as Figure 4 As shown, the specific method by which the function loading module 301 loads at least one driver file matching the target subprocess from the dynamic link library corresponding to the device server based on the function calling tool on the device server may include:

[0196] Identify all driver files that the target child process needs to call;

[0197] When all driver files include at least one independent driver file, the independent driver file is loaded from the dynamic link library based on the function call tool corresponding to the device server and the pre-determined path address of the independent driver file in the dynamic link library. Here, the independent driver file is a driver file that has no association with any other driver file among all driver files; and / or,

[0198] When all driver files include at least one driver file combination, based on the function call tool corresponding to the device server and the environment variables corresponding to the pre-determined driver file combination, all driver files in the driver file combination are loaded from the dynamic link library. The driver file combination includes at least two driver files that are related. The environment variables are used to point to the path address of the target folder corresponding to the driver file combination in the dynamic link library. The target folder is the folder containing all driver files in the driver file combination.

[0199] It is evident that implementation Figure 4The described device can also load the driver file directly through its path address when there is no association between the driver file and other driver files, reducing unnecessary files that need to be loaded to the device server and improving the accuracy of driver file loading. When there is an association between the driver file and other driver files, the device loads the driver file based on the environment variables corresponding to all the associated driver files, reducing the occurrence of missing variable parameter information in the driver file due to splitting the loading of associated driver files, and improving the comprehensiveness and reliability of driver file loading.

[0200] In yet another alternative embodiment, such as Figure 4 As shown, the specific method by which the function mapping module 306 maps each driver function to a mapping function of a preset type in the class library corresponding to the function call tool may include:

[0201] Determine the function attributes that need to be retained in each driver function;

[0202] Based on the function attributes that need to be retained in each driver function, the driver function is mapped to a mapping function of a preset type in the class library corresponding to the function calling tool. The function attributes of the mapping function mapped from each driver function match the function attributes that need to be retained by the driver function.

[0203] It is evident that implementation Figure 4 The described device can also preserve the function attributes in the driver function when mapping the driver function, thereby preserving the functionality of the driver function while making the mapping function compatible with the device server, which helps to improve the accuracy and reliability of diagnosing the device through the driver function.

[0204] In yet another alternative embodiment, such as Figure 4 As shown, the function mapping module 306 maps each driver function to a mapping function of a preset type in the class library corresponding to the function calling tool, based on the function attributes that need to be retained in each driver function. The specific methods may include:

[0205] For each driver function, based on the function attributes that the driver function needs to retain, the corresponding attribute declaration code is generated in the class library corresponding to the function calling tool. Then, based on the attribute declaration code, the mapping function generated by the driver function is mapped in the class library to a mapping function of a preset type; or...

[0206] For each driver function, the driver function is mapped to an initial mapping function of a preset type in the class library corresponding to the function calling tool. The property declaration code corresponding to the driver function is inserted into the initial mapping function to obtain the mapping function mapped by the driver function. The property declaration code corresponding to each driver function is used to declare the function properties that the driver function needs to retain.

[0207] It is evident that implementation Figure 4 The described apparatus can also map driving functions based on property declaration codes used to declare function properties that need to be retained, or obtain mapping functions by inserting property declaration codes into the initial mapping function, thereby improving the accuracy and versatility of mapping driving functions to mapping functions.

[0208] In yet another alternative embodiment, such as Figure 4 As shown, all driver functions include one or more of the following: a first type of driver function for starting communication services, a second type of driver function for collecting diagnostic data, and a third type of driver function for analyzing diagnostic data.

[0209] The diagnostic module 302 executes the service corresponding to each driver function to diagnose the target device. The specific method for obtaining the diagnostic result corresponding to the diagnostic service request may include:

[0210] When all driver functions include a first-type driver function, based on the first-type driver function, the communication device between the device server and the target device is invoked. This communication device is used to enable interaction between the device server and the target device to obtain the diagnostic results corresponding to the diagnostic service request; and / or,

[0211] When all driver functions include the second type of driver function, based on the communication device between the device server and the target device and the second type of driver function, diagnostic data matching the second type of driver function in the target device's device data is collected and sent to the device server as the diagnostic result corresponding to the diagnostic service request; and / or,

[0212] When all driver functions include a third type of driver function, the diagnostic data collected from the target device is analyzed based on the third type of driver function to obtain the analysis results, which are used as the diagnostic results corresponding to the diagnostic service request.

[0213] It is evident that implementation Figure 4 The described device can also perform different driving operations based on different types of driving functions. The diversity of driving functions improves the diversity and flexibility of device diagnosis based on driving functions. Furthermore, by unifying the management and operation of the driving functions that call the communication device with the driving functions of the diagnostic business, the number of modules required to develop the communication device calling function can be reduced, the device server can be simplified, and the development difficulty of the diagnostic program can be reduced.

[0214] Example 4

[0215] Please see Figure 5 , Figure 5 This is a schematic diagram of another device diagnostic device based on a driving function disclosed in an embodiment of the present invention. For example... Figure 5 As shown, the device diagnostic apparatus based on the driving function may include:

[0216] Memory 401 storing executable program code;

[0217] Processor 402 coupled to memory 401;

[0218] The processor 402 calls the executable program code stored in the memory 401 to execute the steps in the device diagnosis method based on the driver function described in Embodiment 1 or Embodiment 2 of the present invention.

[0219] Example 5

[0220] This invention discloses a computer storage medium storing computer instructions. When these computer instructions are invoked, they are used to execute the steps in the device diagnostic method based on driver functions described in Embodiment 1 or Embodiment 2 of this invention.

[0221] Example 6

[0222] This invention discloses a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and the computer program is operable to cause a computer to perform the steps in the device diagnostic method based on drive functions described in Embodiment 1 or Embodiment 2.

[0223] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0224] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0225] Finally, it should be noted that the device diagnosis method and apparatus based on driving functions disclosed in the embodiments of the present invention are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method of device diagnostics based on a driving function, characterized by, The method is applied to a device server, and the method comprises: When detecting a diagnosis service request about a target device sent by a client, determining a diagnosis main process corresponding to the diagnosis service request and one or more sub-processes corresponding to the diagnosis main process; determining a target sub-process to be started currently from all the sub-processes; loading at least one drive file matched with the target sub-process from a dynamic link library corresponding to the device server based on a function calling tool corresponding to the device server, wherein the function calling tool is used for interaction between the device server and the dynamic link library written based on any writing language, and each drive file comprises at least one drive function; mapping each drive function into a mapping function of a preset type in a class library corresponding to the function calling tool; updating each drive function into a mapping function mapped from the drive function, and executing a service corresponding to each drive function to diagnose the target device, so as to obtain a diagnosis result corresponding to the diagnosis service request.

2. The driving function based device diagnostic method of claim 1, wherein, The method further comprises: After starting the diagnosis main process and at least one sub-process, for each started sub-process, when the diagnosis main process initiates data communication to the sub-process, executing a feedback detection operation corresponding to the sub-process to obtain a detection result, wherein the feedback detection operation is used for detecting whether a process processing result returned by the sub-process is received; For each started sub-process, when the detection result indicates that the process processing result returned by the sub-process is not received, determining whether an interval time length between an execution time of the latest feedback detection operation and a current time is greater than or equal to a preset round-robin listening period corresponding to the sub-process, and when the determination result is yes, re-executing the feedback detection operation corresponding to the sub-process until the process processing result returned by the sub-process is obtained.

3. The driving function based device diagnostic method as set forth in claim 1, characterized by, The method of loading at least one drive file matched with the target sub-process from the dynamic link library corresponding to the device server based on the function calling tool corresponding to the device server comprises: determining all drive files to be called by the target sub-process; when at least one independent drive file is included in all the drive files, loading the independent drive file from the dynamic link library based on the function calling tool corresponding to the device server and a path address of the independent drive file in the dynamic link library, wherein the independent drive file is a drive file in all the drive files that has no association relationship with other drive files; and / or, When all the drive files include at least one drive file combination, all drive files in the drive file combination are loaded from the dynamic link library based on a function call tool corresponding to the device server and a predetermined environment variable corresponding to the drive file combination, wherein the drive file combination includes at least two drive files having a correlation relationship, the environment variable is used to point to a path address of a target folder corresponding to the drive file combination in the dynamic link library, and the target folder is a folder containing all drive files in the drive file combination.

4. The driving function based device diagnostic method of claim 1, wherein, The mapping of each drive function into a mapping function of a preset type in the class library corresponding to the function call tool includes: Determining function attributes to be retained in each drive function; According to the function attributes to be retained in each drive function, the drive function is mapped into a mapping function of a preset type in the class library corresponding to the function call tool, wherein the function attributes of the mapping function mapped from each drive function match the function attributes to be retained in the drive function.

5. The driving function based device diagnostic method of claim 4, wherein, The mapping of each drive function into a mapping function of a preset type in the class library corresponding to the function call tool includes: For each drive function, according to the function attributes to be retained in the drive function, the attribute declaration code corresponding to the drive function is generated in the class library corresponding to the function call tool, and based on the attribute declaration code, the mapping function mapped from the drive function is mapped into a mapping function of a preset type in the class library; or, For each drive function, the drive function is mapped into an initial mapping function of a preset type in the class library corresponding to the function call tool, and the attribute declaration code corresponding to the drive function is inserted into the initial mapping function to obtain the mapping function mapped from the drive function, wherein the attribute declaration code corresponding to each drive function is used to declare the function attributes to be retained in the drive function.

6. The driving function based device diagnostic method according to any one of claims 1 to 5, characterized in that, All the drive functions include one or more of a first type of drive function for starting a communication service, a second type of drive function for collecting diagnostic data, and a third type of drive function for analyzing diagnostic data; The execution of the service corresponding to each drive function to diagnose the target device to obtain a diagnostic result corresponding to the diagnostic service request includes: When all the drive functions include the first type of drive function, the communication device between the device server and the target device is called based on the first type of drive function, and the communication device is used to realize the interaction between the device server and the target device to obtain the diagnostic result corresponding to the diagnostic service request; and / or, When the second type of driver function is included in all the driver functions, based on a communication device between the device server and the target device and the second type of driver function, diagnostic data in device data of the target device that matches the second type of driver function is collected to the device server as a diagnostic result corresponding to the diagnostic service request; and / or, When the third type of driver function is included in all the driver functions, based on the third type of driver function, the diagnostic data collected from the target device is analyzed to obtain an analysis result as a diagnostic result corresponding to the diagnostic service request.

7. A driving function-based device diagnosis apparatus characterized by comprising: The device is applied to a device server, and the device comprises: A determination module is configured to determine a diagnostic main process corresponding to a diagnostic service request and one or more sub-processes corresponding to the diagnostic main process, and determine a target sub-process to be started currently from all the sub-processes; A function loading module is configured to, when detecting a diagnostic service request about a target device sent by a client, load at least one driver file matched with the target sub-process from a dynamic link library corresponding to the device server based on a function calling tool corresponding to the device server, wherein the function calling tool is used for interaction between the device server and the dynamic link library written based on any writing language, and each driver file comprises at least one driver function; A diagnosis module is configured to execute a service corresponding to each driver function to diagnose the target device and obtain a diagnostic result corresponding to the diagnostic service request; A function mapping module is configured to map each driver function into a mapping function of a preset type in a class library corresponding to the function calling tool; An update module is configured to update each driver function into a mapping function mapped from the driver function, and trigger the diagnosis module to execute the service corresponding to each driver function to diagnose the target device and obtain the diagnostic result corresponding to the diagnostic service request.

8. A driving function-based device diagnosis apparatus characterized by comprising: The device comprises: A memory storing executable program codes; A processor coupled with the memory; The processor calls the executable program codes stored in the memory to execute the device diagnosis method based on driver functions according to any one of claims 1-6.

Images