Off-line diagnosis method, diagnosis system and terminal equipment

Abstract

The invention relates to the technical field of diagnosis, in particular to an offline diagnosis method, a diagnosis system and terminal equipment. The method comprises the following steps: when a target device is offline, in response to a diagnosis request, obtaining a plurality of byte code instructions included in a diagnosis script in the target device; and on the basis of the arrangement sequence of all byte code instructions in the diagnosis script, obtaining each byte code instruction and performing grammar semantic structure analysis, and generating and executing a diagnosis logic code of a target diagnosis function so as to realize an offline diagnosis operation on the target equipment. Therefore, under the condition of not depending on an upper computer and a network, the lower computer with limited resources can realize a diagnosis function.

Description

An offline diagnostic method, diagnostic system, and terminal device Technical Field

[0001] This application relates to the field of diagnostic technology, and in particular to an offline diagnostic method, diagnostic system and terminal device. Background Technology

[0002] Currently, most terminal products on the market require the cooperation of a host computer and a slave computer to complete a diagnostic function. Specifically, the slave computer is responsible for the underlying communication protocol driver functions, while the host computer is responsible for the processing logic, data parsing, and result display of the diagnostic function. Without a host computer and / or without a communication network (the host computer depends on the network), the diagnostic function cannot be implemented. Summary of the Invention

[0003] In view of this, embodiments of this application provide an offline diagnostic method, diagnostic system, and terminal device, which can effectively solve the problem of excessive reliance on host computers and communication networks for product diagnostic functions in the prior art.

[0004] In a first aspect, embodiments of this application provide an offline diagnostic method, comprising: when a target device is offline, in response to a diagnostic request, obtaining multiple bytecode instructions included in a diagnostic script in the target device; based on the arrangement order of all bytecode instructions in the diagnostic script, obtaining each bytecode instruction and performing syntactic and semantic structure parsing, generating and executing diagnostic logic code for the target diagnostic function, so as to realize offline diagnostic operation on the target device.

[0005] In some embodiments, the bytecode instruction includes multiple binary fields combined in a preset structural order; the step of obtaining each bytecode instruction and performing syntactic and semantic structure parsing to generate and execute diagnostic logic code for the target diagnostic function includes: for each bytecode instruction, generating diagnostic logic code for the target diagnostic function according to the structural order of each binary field in the bytecode instruction and the obtained generation module mapping relationship.

[0006] In some embodiments, generating diagnostic logic code for the target diagnostic function based on the structural order of the binary fields within the bytecode instruction and the obtained generation module mapping relationship includes: obtaining binary fields corresponding to the instruction type and at least one auxiliary parameter from the bytecode instruction according to the structural order, to obtain an instruction type field and at least one auxiliary parameter field; determining a target generation module from the generation module mapping relationship based on the instruction type field; and generating diagnostic logic code for the target diagnostic function using the target generation module based on at least one of the auxiliary parameter fields.

[0007] In some embodiments, the at least one auxiliary parameter field includes at least one of the following: instruction position (arrangement sequence number), instruction parameter name of the bytecode instruction to be executed, instruction parameter value, and parameter type; the bytecode instruction to be executed includes the current bytecode instruction or the target bytecode instruction to which to jump; the generation module mapping relationship includes at least one of the following: a mapping relationship between the first field value and the data initialization module, a mapping relationship between the second field value and the function call module, and a mapping relationship between the third field value and the flow control module; the step of determining the target generation module from the generation module mapping relationship based on the instruction type field, and generating diagnostic logic code for the target diagnostic function based on at least one of the auxiliary parameter fields using the target generation module includes at least one of the following three items: First item: if the instruction type field is the first field value, then the target generation module is determined to be the data initialization module based on the generation module mapping relationship; using the data initialization module and the instruction parameter name field, instruction parameter value field, and parameter type included in the at least one auxiliary parameter field. The first item: The first auxiliary parameter generates an initialization statement in a preset high-level programming language. The second item: The at least one auxiliary parameter includes: instruction parameter name, instruction parameter value, and parameter type. If the instruction type field is a second field value, the target generation module is determined to be a function call module based on the generation module mapping relationship. Using the function call module, a function call statement in a preset high-level programming language is generated based on at least one of the instruction parameter name field, the instruction parameter value field, and the parameter type field, and a secondary instruction type determined based on the instruction type. The third item: The at least one auxiliary parameter includes: instruction parameter name, instruction parameter value, and parameter type. If the instruction type field is a third field value, the target generation module is determined to be a flow control module based on the generation module mapping relationship. Using the flow control module, a flow control function in a preset high-level programming language is generated based on at least one of the instruction parameter name field, the instruction parameter value field, and the parameter type field, and a secondary instruction type determined based on the instruction type field.

[0008] In some embodiments, the types of function call statements include: calling an internal method, calling an external method, and internal call naming conversion; the types of flow control functions include loop start, loop end, exit, branch judgment, and logical judgment.

[0009] In some embodiments, obtaining multiple bytecode instructions included in the diagnostic script of the target device includes: obtaining multiple bytecode instructions included in the diagnostic script and storing them in a preset instruction list according to the arrangement order; obtaining each bytecode instruction based on the arrangement order of all bytecode instructions in the diagnostic script includes: using a preset identifier to record the instruction position corresponding to the generated and processed bytecode instructions in the preset instruction list; obtaining the current bytecode instruction according to the arrangement order and the instruction position.

[0010] In some embodiments, the step of acquiring each bytecode instruction and parsing its syntax and semantic structure to generate and execute diagnostic logic code for the target diagnostic function includes: constructing a structure-based call stack, where each stack frame contains an instruction address, return value, variable name, and current nesting level; acquiring the current bytecode instruction based on the arrangement order; if the instruction type field of the bytecode instruction is the second field value, pushing the instruction address, return value, received variable name, and current nesting level of the current bytecode instruction onto the call stack, and jumping to the instruction position of the target bytecode instruction; if the instruction type field of the bytecode instruction is an exit type, acquiring the instruction address, return value, and received variable name from the top of the call stack, writing the return value into the corresponding variable space, and setting the instruction pointer to the instruction address; if the call stack is empty, determining that the diagnostic script has been executed.

[0011] In some embodiments, the diagnostic script is generated by the following method: parsing the diagnostic logic source code of the target diagnostic function obtained from the host computer using a preset semantic parsing method to obtain a custom instruction set; parsing each custom instruction in the custom instruction set using a preset syntax structure parsing method to obtain the corresponding bytecode instruction; and arranging the bytecode instructions according to the arrangement order to obtain the diagnostic script.

[0012] Secondly, embodiments of this application provide an offline diagnostic system, which includes a lower-level machine; the lower-level machine is used to communicate with a higher-level machine; when communicating with the higher-level machine, it receives and stores diagnostic scripts sent by the higher-level machine; when the communication connection with the higher-level machine is disconnected, it uses a diagnostic method as provided in the first aspect of this application to perform target diagnostic functions on the target device.

[0013] Thirdly, embodiments of this application provide a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement a diagnostic method provided in the first aspect of this application.

[0014] The embodiments of this application have the following beneficial effects: When the target device is offline, in response to a diagnostic request, this application obtains multiple bytecode instructions included in the diagnostic script of the target device; based on the arrangement order of all bytecode instructions in the diagnostic script, it obtains each bytecode instruction and performs syntactic and semantic structure parsing to generate and execute diagnostic logic code for the target diagnostic function, thereby realizing offline diagnostic operations on the target device. Therefore, this application can enable resource-limited lower-level devices to implement diagnostic functions without relying on a host computer and network, while ensuring the availability of the function, optimizing the experience in complex scenarios, and improving user satisfaction. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 shows an application scenario of the offline diagnostic system according to an embodiment of this application; Figure 2 shows a flowchart of the offline script generation method according to an embodiment of this application; Figure 3 shows a flowchart of the offline diagnostic method according to an embodiment of this application; Figure 4 shows a flowchart of the diagnostic logic code that executes the target diagnostic function in the offline diagnostic method according to an embodiment of this application.

[0017] Explanation of key component symbols: 100 - Lower-level machine; 200 - Upper-level machine. Detailed Implementation

[0018] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0019] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0022] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0023] This application provides an offline diagnostic system, exemplary as shown in FIG1. ​​The offline diagnostic system includes a lower-level machine 100; the lower-level machine 100 is used for communication connection with a higher-level machine 200; exemplaryly, when the lower-level machine 100 and the higher-level machine 200 are communication connected, the lower-level machine 100 receives and stores diagnostic scripts sent by the higher-level machine 200. For example, the higher-level machine 200 sends the diagnostic scripts to the lower-level machine 100 via wired or wireless communication. To improve transmission efficiency, the diagnostic scripts are in binary format, and the lower-level machine 100 saves the binary files to local storage.

[0024] Furthermore, when the communication connection between the lower-level machine 100 and the upper-level machine 200 is disconnected, the offline diagnostic method provided in this application is used to perform offline diagnostic operations on the target device.

[0025] It is understood that before performing offline diagnosis, this application needs to generate an offline diagnosis script and save it in the lower-level machine 100 so that the diagnosis operation can be performed in the offline state of the lower-level machine 100. In one embodiment, as shown in FIG2, the offline script generation method includes: S110, parsing the source code of the diagnosis logic of the target diagnosis function obtained from the upper-level machine 200 through a preset semantic parsing method to obtain a custom instruction set.

[0026] The diagnostic logic code is generated based on a pre-defined high-level programming language.

[0027] Further, in step S110, the diagnostic logic source code of the target diagnostic function obtained from the host computer 200 is parsed using a preset semantic parsing method to obtain a custom instruction set, including: S111, dividing the diagnostic logic code into multiple diagnostic logic code segments according to the programming order based on a preset granularity. The preset granularity includes, but is not limited to, division by statement, preset object (function, object attribute), etc. For example, dividing the diagnostic logic code into diagnostic logic code segments corresponding to initialization statements, attributes, functions, etc., according to the programming order.

[0028] S112, Obtain the target diagnostic logic code fragment, and break down the target diagnostic logic code fragment into multiple programming elements based on semantic information. These programming elements are language construction units with clear syntactic structures and semantic meanings in a programming language, including keywords, identifiers, operators, literals, and control structures in high-level programming languages.

[0029] S113 converts each programming element into a corresponding semantic constituent element based on a preset semantic element mapping relationship.

[0030] The semantic element mapping relationship includes the mapping relationship between programming elements and semantic constituent elements; programming elements include keywords, identifiers, operators, literals, and control structures of high-level programming languages. Semantic constituent elements include keywords and at least one user-defined parameter.

[0031] S114 combines multiple semantic components to obtain a custom instruction.

[0032] The custom instruction includes its keyword, a preset separator, and at least one auxiliary parameter. The auxiliary parameter includes parameters from a high-level programming language, attribute names, the location of the custom instruction within the diagnostic script, parameter types, attribute types, and attribute values.

[0033] S115 arranges multiple custom instructions according to the programming order to obtain a custom instruction set.

[0034] The semantic element mapping relationships include: the mapping relationship between at least one of the keywords, control structures, and operators of a high-level programming language and the user-defined instruction keywords; and the mapping relationship between identifiers, literals, and auxiliary parameters.

[0035] For example, in the embodiments of this application, the preset separator is square brackets ("[]"). Then, int k2=1 is converted into MOV k2[1:Uint32T], and the semantic element mapping relationship is shown in Table 1.

[0036] Table 1 Semantic Element Mapping Relationship

[0037] Specifically, the custom instruction set includes custom instructions of various instruction types. The auxiliary parameters within the custom instructions also include parameters of various instruction parameter types. The custom instructions include the MOV instruction, used to initialize variable data; the CALL_IN instruction, used to call the preset function within the lower-level machine 100; the CALL_OUT instruction, used to call the external device interface to obtain response data; the CHECK instruction, used to jump to the instruction address of a specified line number based on a condition; the LOOP_START and LOOP_END instructions, used to implement loop control structures; and the exit instruction (RET instruction), used to return the current function execution result and restore the calling context. The custom instructions and their function descriptions are shown in Table 2. The binary fields of the instruction parameter types use 0x0A to represent a ByteArray, 0x0E to represent a String, 0x10 to represent a StringArray, and 0x11 to represent a Uint32T unsigned integer. The specific instruction parameter types for the auxiliary parameters within the custom instructions are shown in Table 3.

[0038] Table 2. Description of Custom Commands and Functions

[0039] Table 3. Command parameter types for custom auxiliary parameters within commands.

[0040] S120 parses each custom instruction in the custom instruction set using a preset syntax structure parsing method to obtain the corresponding bytecode instruction.

[0041] Further, in step S120, each custom instruction in the custom instruction set is parsed using a preset syntax structure parsing method to obtain bytecode instructions, including: S121, mapping each semantic component included in the custom instruction to obtain a corresponding binary field according to the field mapping relationship; determining the structural order of the custom instruction based on the position of each semantic component in the custom instruction.

[0042] Semantic components include instruction type, instruction parameter type, and instruction parameters.

[0043] The structure of a bytecode instruction includes an instruction type, an instruction parameter type, and the corresponding binary fields of the instruction parameters. In step S121, each semantic component included in the custom instruction is mapped to its corresponding binary field according to the field mapping relationship. This includes: if the semantic component is an instruction type, then the field value of the binary field corresponding to the semantic component is determined according to the mapping relationship between the instruction type and the opcode. For example, in Table 1 above, if the instruction type is MOV, then the mapped opcode is 0x01; if the instruction type is CALL_IN, then the mapped opcode is 0x02.

[0044] If the semantic constituent element is an instruction parameter type, the field value of the binary field corresponding to each instruction parameter type is determined according to the mapping relationship between parameter type and type code.

[0045] As shown in Table 2 above, if the instruction parameter type is name, the mapping type code is 0x01; if the instruction parameter type is line, the mapping type code is 0x03.

[0046] If the semantic components are instruction parameters, the field value of the binary field corresponding to each instruction parameter is determined according to the mapping relationship between instruction parameters and parameter codes.

[0047] If the instruction parameter (parameter value) is 1, it is mapped to binary 0x01; if the instruction parameter (parameter value) is 16, it is mapped to binary 0x10 (hexadecimal).

[0048] S122 combines the binary fields according to the structural order to obtain the corresponding bytecode instructions.

[0049] For example, the structure of a bytecode instruction includes instruction length, instruction type, parameter length, parameter type, auxiliary parameters, etc., and its structural order is shown in Table 4. The first binary field is the instruction length, and the last binary field is the auxiliary parameter.

[0050] Table 4. Structure of bytecode instructions

[0051] S130: Arrange the bytecode instructions according to the layout order to obtain a diagnostic script in a preset format.

[0052] As an example, the statement in the diagnostic logic source code is: CBinary bin221000("\x22\x10\x00", 3); / / This statement is used to define a character type byte array variable, where the array variable name is bin221000, and the byte array contains 3 values: 0x22, 0x10, and 0x00.

[0053] Then, the custom instruction is converted to: MOV [K1][34, 16, 0]:ByteArray; where MOV+ByteArray is mapped by CBinary; k1, replacing bin221000; [34, 16, 0] as ("0x22\0x10\0x00", 3).

[0054] Furthermore, MOV [K1][[34, 16, 0]:ByteArray] is transformed into "00 0C 01 00 03 01 0001 00 04 0A 22 10 00", where MOV is mapped to "00 01", [34, 16, 0] is mapped to "22 10 00", and ByteArray is mapped to "0A".

[0055] Therefore, a diagnostic script for offline diagnosis can be obtained. Based on the obtained diagnostic script, the offline diagnosis method will be described below with reference to some specific embodiments.

[0056] Figure 3 shows a flowchart of an offline diagnostic method according to an embodiment of this application. This offline diagnostic method is applicable to a lower-level machine 100, which includes, but is not limited to, automotive diagnostic equipment. Exemplarily, the offline diagnostic method includes the following steps: S210, when the target device is offline, in response to a diagnostic request, obtaining multiple bytecode instructions included in the diagnostic script of the target device.

[0057] In other words, when the communication connection between the host computer 200 and the slave computer 100 is lost, the slave computer 100 retrieves the locally stored diagnostic script, receives diagnostic requests, and retrieves bytecode instructions from the diagnostic script.

[0058] Bytecode instructions are an intermediate representation between high-level programming languages ​​and native machine code, typically existing in binary format. In other words, bytecode instructions are machine-readable but not directly executable binary-encoded instructions.

[0059] S220, based on the arrangement order of all bytecode instructions in the diagnostic script, obtains each bytecode instruction and performs syntactic and semantic structure parsing, generates and executes the diagnostic logic code for the target diagnostic function, so as to realize offline diagnostic operations on the target device.

[0060] Each bytecode instruction is parsed for its syntax and semantic structure, and diagnostic logic code for the target diagnostic function is generated.

[0061] For example, the target diagnostic functions include at least one of vehicle OBD fault code reading, battery status detection, sensor self-test, or multi-node communication test.

[0062] In this embodiment, the diagnostic logic source code of the host computer 200 is converted into a binary file in a custom format. The host computer 200 converts the diagnostic logic source code, written in a high-level programming language (such as C / C++, Python, or JavaScript), into an intermediate representation consisting of a set of structured instructions. The intermediate representation uses a custom instruction set architecture. Subsequently, the binary diagnostic script (binary file) is transmitted and stored to the slave computer 100. The slave computer 100 loads and parses the binary file.

[0063] In one implementation, the bytecode instruction includes multiple binary fields combined in a preset structural order; in other words, the binary fields within the bytecode instruction are arranged in a structural order. This structural order is shown in Table 4 above, where the first binary field is the instruction length and the last binary field is an auxiliary parameter.

[0064] For example, the encoding structure of each bytecode instruction includes: the first two bytes represent the total length of the instruction; the third byte represents the instruction type (opcode); followed by one or more parameter segments, each of which includes: two bytes for instruction parameter length, one byte for instruction parameter type, and N bytes for instruction parameter value.

[0065] In step S220, each bytecode instruction is obtained and its syntax and semantic structure is parsed to generate and execute the diagnostic logic code for the target diagnostic function, including: S221, for each bytecode instruction, the diagnostic logic code for the target diagnostic function is generated according to the structural order of each binary field in the bytecode instruction and the obtained generation module mapping relationship.

[0066] Further, in step S221, diagnostic logic code for the target diagnostic function is generated according to the structural order of each binary field in the bytecode instruction and the obtained generation module mapping relationship, including: S2211, obtaining the binary fields corresponding to the instruction type and at least one auxiliary parameter respectively from the bytecode instruction according to the structural order, to obtain the instruction type field and at least one auxiliary parameter field.

[0067] S2212, determine the target generation module from the generation module mapping relationship according to the instruction type field, and use the target generation module to generate the diagnostic logic code of the target diagnostic function based on at least one auxiliary parameter field.

[0068] Further, at least one auxiliary parameter field includes at least one of the following: instruction location, instruction parameter name of the bytecode instruction to be executed, instruction parameter value, and parameter type; the bytecode instruction to be executed includes the current bytecode instruction or the target bytecode instruction to which to jump; the generation module mapping relationship includes at least one of the following: the mapping relationship between the first field value and the data initialization module, the mapping relationship between the second field value and the function call module, and the mapping relationship between the third field value and the flow control module; the target generation module is determined from the generation module mapping relationship based on the instruction type field, and the diagnostic logic code of the target diagnostic function is generated using the target generation module based on at least one auxiliary parameter field, including: if the instruction type field is the first field value, then the target generation module is determined to be the data initialization module based on the generation module mapping relationship; the data initialization module is used to declare and assign values ​​to variables.

[0069] As an example, the target generation module includes, but is not limited to, the use of code generation functions. Types of code generation functions include data initialization generation functions.

[0070] The system utilizes a data initialization module and at least one auxiliary parameter field, including an instruction parameter name field, an instruction parameter value field, and a parameter type field, to generate initialization statements in a preset high-level programming language. In other words, it calls a data initialization generation function, which takes the instruction parameter name field, instruction parameter value field, and parameter type field as parameters and generates initialization statements based on its internal generation logic. The data initialization generation function is a pre-edited functional logic function for generating initialization functions. The parameter type field uses different preset binary encodings to represent different parameter types, including ByteArray, String, Uint32T, and StringArray.

[0071] For example, the data initialization generation function is used to generate the binary bytecode instruction "00 0C 01 00 03 01 0001 00 04 0A 22 10 00" into the initialization statement "CBinary bin221000("\x22\x10\x00", 3)" edited in a high-level programming language from the binary bytecode instruction "00 0C 01 00 03 ... The following explanations of each field, arranged from left to right, illustrate the following: "00 0C" indicates the instruction length, the number of bytes in the entire bytecode instruction (occupying two bytes), with 00 0C representing a bytecode length of 12 bytes; "01" indicates the instruction type (CBinary); "00 03" indicates the instruction parameter length, including the instruction parameter type and length (e.g., variable name and parameter type); "01" indicates the instruction parameter type, signifying the instruction parameter identifier, with the following two bytes being the variable name; "00 01" indicates the instruction parameter, with 00 01 representing the variable name, here representing bin221000; "00 04" indicates the parameter length, including the instruction parameter type and length (e.g., parameter type and variable value); "OA" indicates the instruction parameter type, where OA represents a byte array, indicating the following three bytes are the byte array variable value; "22 10 00" indicates the instruction parameter, with "22 10" representing the instruction parameter. "00" indicates that there are 3 instruction parameters, which are variable values, corresponding to 34, 16 and 0 in decimal respectively.

[0072] The target generation module is determined from the generation module mapping relationship based on the instruction type field. The target generation module generates diagnostic logic code for the target diagnostic function based on at least one auxiliary parameter field, including: at least one auxiliary parameter including: instruction parameter name, instruction parameter value and parameter type; if the instruction type field is the value of the second field, the target generation module is determined to be a function call module based on the generation module mapping relationship; the function call module calls the internal processing function (calls the internal method) or the external device interface (calls the external method).

[0073] Using the function call module, based on at least one of the instruction parameter name field, instruction parameter value field, and parameter type field, and the secondary instruction type determined by the instruction type, a function call statement represented in a preset high-level programming language is generated. The types of function call statements include: calling internal methods, calling external methods, and internal call naming conversion. Understandably, the function call module is further divided into generated functions corresponding to calling internal methods, calling external methods, and internal call naming conversion according to the secondary instruction type.

[0074] For example, if the range of binary field values ​​0x02-0x04 corresponds to a function call module, then 0x02-0x04 corresponds in order to the generated functions corresponding to calling internal methods, calling external methods, and internal call naming conversion.

[0075] The target generation module is determined from the generation module mapping relationship based on the instruction type field. The target generation module generates diagnostic logic code for the target diagnostic function based on at least one auxiliary parameter field, including: at least one auxiliary parameter including: instruction parameter name, instruction parameter value, and parameter type; if the instruction type field is a third field value, the target generation module is determined to be a flow control module based on the generation module mapping relationship; the flow control module is used to implement condition judgment, loop control, and return logic functions; wherein, the opcodes of various instructions corresponding to the flow control module are represented by single-byte encoding.

[0076] Using the flow control module, a flow control function represented in a preset high-level programming language is generated based on at least one of the fields of instruction parameter name, instruction parameter value, and parameter type, and the secondary instruction type determined by the instruction type field.

[0077] Flow control functions include loop start, loop end, exit, branch judgment, and logical judgment types. Understandingly, the flow control module is further divided into generation functions corresponding to loop start, loop end, exit, branch judgment, and logical judgment based on secondary instruction types. Logical judgments include determining whether two values ​​are equal, determining whether the left-hand side equals the right-hand side, etc.

[0078] For example, the range of binary field values ​​0x05-0x0B corresponds to the flow control module. Then, 0x05-0x0B corresponds in sequence to the generation functions for loop start, loop end, exit, branch judgment, whether two values ​​are equal, whether two values ​​are equal, and whether the left value is equal to the right value.

[0079] Furthermore, at least one auxiliary parameter includes the instruction position, the instruction parameter name, instruction parameter value, and parameter type of the next bytecode instruction; if the instruction type field is the value of the second field, then the target generation module is determined to be the function jump module according to the generation module mapping relationship; the function jump module obtains the target diagnostic statement represented by the next bytecode instruction in a preset high-level programming language based on the instruction position; and generates a jump statement represented by the preset high-level programming language based on the instruction type of the next bytecode instruction and at least two of the instruction parameter name, instruction parameter value, and parameter type.

[0080] In one implementation, to facilitate the management of multiple bytecode instructions within a diagnostic script, the method involves obtaining multiple bytecode instructions included in the diagnostic script from the target device, including: S211, obtaining multiple bytecode instructions included in the diagnostic script and storing them in a preset instruction list according to their arrangement order. Memory space is allocated for caching the preset instruction list.

[0081] In step S220, each bytecode instruction is obtained based on the arrangement order of all bytecode instructions in the diagnostic script, including: using a preset identifier to record the instruction position corresponding to the generated and processed bytecode instructions in the preset instruction list; and obtaining the current bytecode instruction according to the arrangement order and instruction position.

[0082] In one implementation, as shown in Figure 4, step S220 involves obtaining each bytecode instruction and parsing its syntax and semantic structure to generate and execute diagnostic logic code for the target diagnostic function. This includes: S2201, constructing a structure-based call stack, where each stack frame contains the instruction address, return value, variable name, and current nesting level.

[0083] S2202: Obtain the current bytecode instruction based on the arrangement order. If the instruction type field of the bytecode instruction is the value of the second field, push the instruction address, return value, name of the received variable, and current nesting level of the current bytecode instruction onto the call stack, and jump to the instruction position of the target bytecode instruction.

[0084] S2203, if the instruction type field of the bytecode instruction is an exit type (RET type), obtain the instruction address and return value from the top of the call stack, receive the variable name, write the return value into the corresponding variable space, and set the instruction pointer to the instruction address.

[0085] S2204. If the call stack is empty, the diagnostic script is considered to have completed execution.

[0086] The embodiments of this application are illustrated by way of specific examples, including the following steps: S301, allocating space to store a variable list of instructions; defining an instruction pointer to track the instruction address of the current bytecode instruction (the instruction being parsed); Instruction Pointer (IP): pointing to the instruction address of the current bytecode instruction, such as the sequence number of the current bytecode instruction in the binary file.

[0087] S302 defines a call stack for an instruction pointer, used to save and restore the state of the currently executing instruction; the call stack is a structure array used to save the function call context, and each stack frame contains: nesting level, return address (original IP value), return value variable name, etc.

[0088] The lower-level machine 100 executes instructions cyclically according to the following process: S303, reads the first two bytes of the bytecode instruction at the current IP address to obtain the instruction length of the current bytecode instruction; reads the complete content of the current bytecode instruction according to the instruction length; parses the instruction type field to determine the code generation function to be called; S304, parses each auxiliary parameter in structural order to extract the instruction parameter type and instruction parameter value; calls the corresponding code generation function to implement the generation logic and obtains the statement edited based on the high-level programming language; S305, updates the IP address to point to the instruction address of the next bytecode instruction; S306, if the instruction type (secondary instruction type) of the current bytecode instruction is a call to an internal method or a call to an external method (CALL_IN / CALL_OUT), then pushes the instruction address, return value, name of the receiving variable, and current nesting level of the current bytecode instruction onto the call stack to save the context; S307, if the instruction type (secondary instruction type) of the current bytecode instruction is an exit instruction (RET or return instruction), then pops the stack to restore the IP address and assigns the return value to the specified receiving variable; if the call stack is empty and the RET instruction has been executed, then the entire diagnostic process ends.

[0089] Taking the engine self-test function of an on-board OBD module as an example for diagnosis: Suppose an on-board OBD device needs to automatically perform an engine health check after ignition. Traditionally, a mobile app is required to view the results. This embodiment of the application can perform a self-test even without a mobile phone.

[0090] First, the host computer 200 prepares a diagnostic script. For example, the host computer 200 writes the following diagnostic logic code (pseudocode): / / Define the data packet to send (CBinary) send_data("221000", 3); / / Request to read (DTCCBinary) recv_data = can_send_receive(send_data); / / Send and receive the response / / Determine if it is successful if (recv_data[0] == 0x7F){return "Communication failed";} else {return "Normal";} The above functional logic code is converted into a custom instruction set, as shown in Table 5.

[0091] Table 5 Examples of Custom Instruction Sets

[0092] (Then encoded into binary bytecode instructions, omitting the detailed hexadecimal sequence).

[0093] The lower-level machine 100 deploys and executes bytecode instructions within the diagnostic script (binary file).

[0094] Specifically, the binary file is written to the Flash area of ​​the OBD module via Bluetooth OTA; after ignition, the main program detects the "self-test" flag and triggers the offline diagnostic process; the binary file is loaded and stored in the preset instruction list, and IP is initialized to the instruction address of the first bytecode instruction; an empty stack is created and the loop of the preset instruction list is started; the first instruction is executed: byte array K1 is created; the second instruction is executed: the external CAN interface is called, parameter K1 is passed, and the result is stored in K2; the third instruction is executed: whether K2[0] is equal to 0x7F, if it is true, it jumps to the fifth instruction; otherwise, the fourth instruction is executed and "normal" is returned; finally, the green LED light is always on to indicate "normal", and the red LED light flashes to indicate "communication failure".

[0095] This application embodiment also includes a function call and return mechanism. Specifically, when CALL_IN check_battery() is executed: the current IP is pushed onto the top of the stack; the nesting level is incremented by 1; the new IP is set as the starting address of the target function; execution of the sub-function instruction continues; when `RET value` is encountered: the record at the top of the stack is popped; the original IP is restored; the value is assigned to the preset receiving variable; the nesting level is decremented by 1; if the stack is empty at this time, the entire diagnosis ends.

[0096] Conditional branching is implemented, for example, using `CHECK` and `BEQ / BNE` instructions to implement Boolean judgments: assemblyCHECK flag_valid yes_line=10 no_line=20. If flag_valid is true, jump to line 10; otherwise, jump to line 20. This embodiment eliminates the dependence of the host computer 200 on the network: the slave computer 100 can autonomously complete diagnostic tasks in a completely offline state, suitable for complex environments such as network outages, mobile, and remote areas; this embodiment improves system reliability and response speed: no need to wait for remote response, low diagnostic latency, suitable for emergency fault handling; this embodiment enhances data security and privacy protection: sensitive diagnostic data does not need to be transmitted externally, avoiding information leakage; this embodiment reduces operation and maintenance costs and deployment difficulty: diagnostic logic is updated in the form of scripts, without the need to re-burn firmware; this embodiment has strong compatibility and good scalability: different devices and diagnostic needs can be adapted by adding or removing instruction sets; this embodiment has low resource consumption: the instruction code is compact, the parsing engine is lightweight, and it can run stably on low-power MCUs.

[0097] This application also provides a schematic diagram of an offline diagnostic device. Exemplarily, the offline diagnostic device includes: when the target device is offline, in response to a diagnostic request, acquiring multiple bytecode instructions included in a diagnostic script within the target device; based on the arrangement order of all bytecode instructions in the diagnostic script, acquiring each bytecode instruction and performing syntactic and semantic structure parsing, generating and executing diagnostic logic code for the target diagnostic function, thereby realizing offline diagnostic operations on the target device.

[0098] It is understood that the device in this embodiment corresponds to the offline diagnostic method in the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0099] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described offline diagnostic method or offline diagnostic device.

[0100] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0101] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0102] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0104] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0105] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0106] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An offline diagnostic method, characterized in that, include: When the target device is offline, in response to a diagnostic request, multiple bytecode instructions included in the diagnostic script of the target device are obtained; Based on the arrangement order of all bytecode instructions in the diagnostic script, each bytecode instruction is obtained and its syntax and semantic structure is parsed to generate and execute the diagnostic logic code for the target diagnostic function, so as to realize the offline diagnostic operation of the target device.

2. The offline diagnostic method according to claim 1, characterized in that, The bytecode instruction includes multiple binary fields combined in a preset structural order; the step of obtaining each bytecode instruction and performing syntactic and semantic structure parsing to generate and execute diagnostic logic code for the target diagnostic function includes: for each bytecode instruction, generating diagnostic logic code for the target diagnostic function based on the structural order of each binary field in the bytecode instruction and the obtained generation module mapping relationship.

3. The offline diagnostic method according to claim 2, characterized in that, The step of generating diagnostic logic code for the target diagnostic function based on the structural order of the binary fields in the bytecode instruction and the obtained generation module mapping relationship includes: obtaining binary fields corresponding to the instruction type and at least one auxiliary parameter respectively from the bytecode instruction according to the structural order, to obtain an instruction type field and at least one auxiliary parameter field; determining the target generation module from the generation module mapping relationship according to the instruction type field; and using the target generation module to generate diagnostic logic code for the target diagnostic function based on at least one of the auxiliary parameter fields.

4. The offline diagnostic method according to claim 3, characterized in that, The at least one auxiliary parameter field includes at least one of the following: instruction location, instruction parameter name of the bytecode instruction to be executed, instruction parameter value, and parameter type; the bytecode instruction to be executed includes the current bytecode instruction or the target bytecode instruction to which to jump; the generation module mapping relationship includes at least one of the following: a mapping relationship between the first field value and the data initialization module, a mapping relationship between the second field value and the function call module, and a mapping relationship between the third field value and the flow control module; the step of determining the target generation module from the generation module mapping relationship based on the instruction type field, and generating diagnostic logic code for the target diagnostic function based on at least one of the auxiliary parameter fields using the target generation module includes at least one of the following three items: First item: if the instruction type field is the first field value, then the target generation module is determined to be the data initialization module based on the generation module mapping relationship; a preset advanced function is generated using the data initialization module and the instruction parameter name field, instruction parameter value field, and parameter type field included in the at least one auxiliary parameter field. The programming language initialization statement; the second item: the at least one auxiliary parameter includes: instruction parameter name, instruction parameter value, and parameter type; if the instruction type field is a second field value, then the target generation module is determined to be a function call module according to the generation module mapping relationship; using the function call module, based on at least one of the instruction parameter name field, the instruction parameter value field, and the parameter type field, and the secondary instruction type determined based on the instruction type, a function call statement expressed in a preset high-level programming language is generated; the third item: the at least one auxiliary parameter includes: instruction parameter name, instruction parameter value, and parameter type; if the instruction type field is a third field value, then the target generation module is determined to be a flow control module according to the generation module mapping relationship; using the flow control module, based on at least one of the instruction parameter name field, the instruction parameter value field, and the parameter type field, and the secondary instruction type determined based on the instruction type field, a flow control function expressed in a preset high-level programming language is generated.

5. The offline diagnostic method according to claim 4, characterized in that, The types of function call statements include: calling internal methods, calling external methods, and internal call naming conversion; the types of flow control functions include loop start, loop end, exit, branch judgment, and logical judgment.

6. The offline diagnostic method according to claim 4, characterized in that, The step of obtaining multiple bytecode instructions included in the diagnostic script of the target device includes: obtaining multiple bytecode instructions included in the diagnostic script and storing them in a preset instruction list according to the arrangement order; the step of obtaining each bytecode instruction based on the arrangement order of all bytecode instructions in the diagnostic script includes: using a preset identifier to record the instruction position corresponding to the generated and processed bytecode instructions in the preset instruction list; and obtaining the current bytecode instruction according to the arrangement order and the instruction position.

7. The offline diagnostic method according to claim 6, characterized in that, The process of acquiring each bytecode instruction, parsing its syntax and semantic structure, and generating and executing diagnostic logic code for the target diagnostic function includes: constructing a structure-based call stack, where each stack frame contains an instruction address, return value, variable name, and current nesting level; acquiring the current bytecode instruction based on the arrangement order; if the instruction type field of the bytecode instruction is the second field value, pushing the instruction address, return value, received variable name, and current nesting level of the current bytecode instruction onto the call stack, and jumping to the instruction position of the target bytecode instruction; if the instruction type field of the bytecode instruction is an exit type, acquiring the instruction address, return value, and received variable name from the top of the call stack, writing the return value into the corresponding variable space, and setting the instruction pointer to the instruction address; if the call stack is empty, determining that the diagnostic script has completed execution.

8. The offline diagnostic method according to claim 6, characterized in that, The diagnostic script is generated using the following method: the source code of the diagnostic logic of the target diagnostic function obtained from the host computer is parsed using a preset semantic parsing method to obtain a custom instruction set; each custom instruction in the custom instruction set is parsed using a preset syntax structure parsing method to obtain the corresponding bytecode instruction; and the bytecode instructions are arranged according to the arrangement order to obtain the diagnostic script.

9. An offline diagnostic system, characterized in that, The offline diagnostic system includes a lower-level machine; the lower-level machine is used to communicate with a higher-level machine; when communicating with the higher-level machine, the lower-level machine receives and stores diagnostic scripts sent by the higher-level machine; when the communication connection with the higher-level machine is disconnected, the lower-level machine uses the diagnostic method as described in any one of claims 1-8 to perform target diagnostic functions on the target device.

10. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the diagnostic method according to any one of claims 1-8.

Images