Method and system for automatically generating vehicle-mounted ECU communication parameter configuration document to ODX-C file

Abstract

The invention discloses a method and system for automatically generating a vehicle-mounted ECU communication parameter configuration document to an ODX-C file, and the method comprises the steps: configuring a key communication parameter information table and a protocol configuration table based on a protocol knowledge base, and extracting key communication parameters and corresponding protocol configurations from the vehicle-mounted ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm, filling a key communication parameter information table with the key communication parameters to obtain a filled key communication parameter information table, filling a protocol configuration table with the key communication parameters and corresponding protocol configurations to obtain a filled protocol configuration table, and constructing an XML structure based on diagnosis service to obtain a diagnosis service; and filling the information in the filled key communication parameter information table and the filled protocol configuration table into the XML structure to generate an ODX-C file. According to the method, the key communication parameters and the corresponding protocol configuration can be automatically extracted from the vehicle-mounted ECU communication parameter configuration document, the ODX-C file is generated, and manual intervention is not needed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile diagnosis development, and particularly relates to a method and system for automatically generating an ODX-C file from a vehicle-mounted ECU communication parameter configuration document. BACKGROUND

[0002] In the development process of an automobile electronic diagnosis system, an ODX-C file is a standard configuration file of diagnosis communication parameters, and its generation process currently mainly relies on manual operation. An engineer needs to extract communication parameters from multiple scattered documents, including CAN channel configuration, baud rate setting, physical / functional addressing ID, timing parameters (N_As, N_Bs, N_Cr, etc.), protocol type and other information, and then manually write an XML format file conforming to the ASAM standard.

[0003] However, the existing ODX-C file generation has the following problems: The communication parameters are scattered in ECU technical specifications, network design documents, test reports and other multiple files, and the engineer needs to spend a lot of time on data collection and arrangement.

[0004] And the ODX-C file with configuration errors can only be found in the diagnosis test stage, resulting in project rework and schedule delay. SUMMARY

[0005] In view of the problems in the prior art, the present application provides a method and system for automatically generating an ODX-C file from a vehicle-mounted ECU communication parameter configuration document, which can automatically extract key communication parameters and corresponding protocol configurations from the vehicle-mounted ECU communication parameter configuration document without manual intervention.

[0006] Other characteristics and advantages of the present application will become apparent from the following detailed description, or will be learned by practice of the present application.

[0007] According to a first aspect of the present application, a method for automatically generating an ODX-C file from a vehicle-mounted ECU communication parameter configuration document is provided, comprising: configuring a key communication parameter information table and a protocol configuration table based on a protocol knowledge base; extracting key communication parameters and corresponding protocol configurations from the vehicle-mounted ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm; filling the key communication parameters in the key communication parameter information table to obtain a filled key communication parameter information table, and filling the key communication parameters and corresponding protocol configurations in the protocol configuration table to obtain a filled protocol configuration table; constructing an XML structure based on a diagnosis service; Fill the information in the filled key communication parameter information table and the filled protocol configuration table in the XML structure to generate an ODX-C file.

[0008] In some embodiments of the present application, based on the foregoing scheme, the protocol knowledge base is used to configure the key communication parameter information table and the protocol configuration table, which comprises: The protocol knowledge base is used to configure the key communication parameter information table, which comprises key communication parameters, data types, allowed values, mandatory, optional, applicable protocol types and descriptions. The protocol knowledge base is used to configure the protocol configuration table, which comprises key communication parameters and corresponding protocol configuration values.

[0009] In some embodiments of the present application, based on the foregoing scheme, the multi-dimensional parameter identification algorithm is used to extract key communication parameters and corresponding protocol configurations from the vehicle ECU communication parameter configuration document, which comprises: The vehicle ECU communication parameter configuration document is obtained. The vehicle ECU communication parameter configuration document is standardized, which comprises removing blank lines and comment lines, unifying unit formats, converting special formats into standard formats, and generating a standardized internal data structure. The key communication parameter position in the standardized internal data structure is located based on keyword matching, and the initial key communication parameters and protocol types are obtained, which comprise ECU basic information, CAN parameters and timing parameters. The ECU basic information, CAN parameters and timing parameters are corrected based on the parameter dependency graph to obtain the corrected key communication parameters. The matching degree of the protocol type and the corrected key communication parameters is confirmed, and the corrected key communication parameters are supplemented according to the matching degree to obtain the final key communication parameters.

[0010] In some embodiments of the present application, based on the foregoing scheme, the parameter dependency graph is used to correct the ECU basic information, CAN parameters and timing parameters to obtain the corrected key communication parameters, which comprises: A parameter dependency graph is established, which comprises nodes, edges and constraint rules, the nodes are the initial key communication parameters, the edges are the dependency relationships between the initial key communication parameters, and the constraint rules are the trigger conditions, legal value ranges and abnormal processing logic of the dependency relationships. The parameter dependency graph is detected for circular dependency and constraint conflict. If the circular dependency and / or constraint conflict causes the initial key communication parameters to be unable to resolve the conflict, the ECU basic information, CAN parameters and timing parameters are corrected to obtain the corrected key communication parameters.

[0011] In some embodiments of the present application, based on the foregoing scheme, the matching degree of the confirmation protocol type and the revised key communication parameter, according to the matching degree, the revised key communication parameter is supplemented to obtain the final key communication parameter, including: If the matching degree is greater than the second threshold value and less than or equal to the first threshold value, the missing revised key communication parameter is automatically supplemented with a default value; If the matching degree is greater than the third threshold value and less than or equal to the second threshold value, the missing revised key communication parameter is manually supplemented; If the matching degree is greater than the fourth threshold value and less than or equal to the third threshold value, the generation is stopped and a modification suggestion is given: If the matching degree is less than or equal to the fourth threshold value, it means that the protocol type is selected incorrectly, and it is suggested to replace the protocol type or refill the vehicle ECU communication parameter configuration document; wherein The first threshold value, the second threshold value, the third threshold value and the fourth threshold value decrease in turn.

[0012] In some embodiments of the present application, based on the foregoing scheme, when the protocol type is DoCAN protocol, the CAN parameter includes physical addressing ID and function addressing ID, and an association analysis method based on a communication matrix is used to separate the physical addressing ID and the function addressing ID, including: Read the vehicle ECU communication parameter configuration document as a communication matrix to obtain message ID, sending node and receiving node; Perform preliminary association analysis on the message ID, if the message ID is bound to the ECU node address and mapped to a single receiving node, the message ID is a physical addressing ID; if the message ID is not bound to the ECU node address and mapped to multiple receiving nodes, the message ID is a function addressing ID; Output the message ID that cannot be confirmed, and manually verify the message ID that cannot be confirmed as a physical addressing ID or a function addressing ID.

[0013] In some embodiments of the present application, based on the foregoing scheme, the XML structure based on the diagnostic service is constructed, including: Generate an ODX root node; Generate a diagnostic layer container for the root node; Generate an ECU configuration sub-node for the diagnostic layer container; Generate an ECU short name sub-node, an ECU long name sub-node and a protocol configuration sub-node for the ECU configuration sub-node; Generate a protocol type sub-node and a CAN parameter sub-node for the protocol configuration sub-node; generating a CAN parameter sub-node, a CAN channel sub-node, a baud rate sub-node, an ID format sub-node, a physical addressing ID sub-node, a functional addressing ID sub-node, a response ID sub-node, and a timing parameter sub-node for the CAN parameter sub-node; generating an application layer latency sub-node, a normal response timeout sub-node, and an enhanced response timeout sub-node for the timing parameter sub-node.

[0014] According to a second aspect of the present application, a system for automatically generating an ODX-C file from a vehicle-mounted ECU communication parameter configuration document is provided, and the system comprises: a configuration module configured to configure a key communication parameter information table and a protocol configuration table based on a protocol knowledge base; an extraction module configured to extract key communication parameters and corresponding protocol configurations from the vehicle-mounted ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm; a first filling module configured to fill the key communication parameters in the key communication parameter information table to obtain a filled key communication parameter information table, and fill the key communication parameters and the corresponding protocol configurations in the protocol configuration table to obtain a filled protocol configuration table; a construction module configured to construct an XML structure based on a diagnostic service; a second filling module configured to fill information in the filled key communication parameter information table and the filled protocol configuration table in the XML structure to generate the ODX-C file.

[0015] According to a third aspect of the present application, a computer readable storage medium having a computer program stored thereon is provided, and the computer program comprises executable instructions which, when executed by a processor, implement the method described above.

[0016] According to a fourth aspect of the present application, an electronic device is provided, and the electronic device comprises: one or more processors; a memory configured to store executable instructions of the processor, and when the executable instructions are executed by the one or more processors, the one or more processors implement the method described above.

[0017] The beneficial effects of the present application are as follows: (1) The vehicle-mounted ECU communication parameter configuration document to ODX-C file automatic generation method and system provided by the application, first, the key communication parameter information table and the protocol configuration table are configured based on the protocol knowledge base, which is used to organize the key communication parameters and the corresponding protocol configuration, second, the key communication parameters and the corresponding protocol configuration are automatically extracted from the vehicle-mounted ECU communication parameter configuration document, third, the key communication parameters are filled in the key communication parameter information table to obtain the filled key communication parameter information table, and the key communication parameters and the corresponding protocol configuration are filled in the protocol configuration table to obtain the filled protocol configuration table, and finally the information in the filled key communication parameter information table and the filled protocol configuration table is filled in the XML structure to generate the ODX-C file, without manual intervention, automatic generation eliminates human error, the configuration accuracy is significantly improved, and the communication parameter configuration accuracy is greatly improved.

[0018] (2) The vehicle-mounted ECU communication parameter configuration document to ODX-C file automatic generation method and system provided by the application has strong protocol compatibility, supports multiple diagnostic protocols, and adapts to the needs of different vehicle platforms and ECU suppliers; the parameter logic integrity, the built-in verification mechanism ensures that all parameters meet the communication protocol specification; the efficiency is greatly improved, the original 2-3 days of manual configuration work is shortened to 5 minutes; the quality is reliable and stable, the generated ODX-C file does not need to be repeatedly modified; the technical threshold is reduced, the engineer does not need to deeply master the details of the ODX-C file format to generate a standard file; the cost is significantly saved, the debugging time and manpower investment are reduced, and the project development efficiency is improved.

[0019] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the application. BRIEF DESCRIPTION OF DRAWINGS

[0020] The drawings described herein are used to provide further understanding of the application, and form a part of the application. The illustrative embodiments of the application and their descriptions are used to explain the application, and do not constitute an improper limitation on the application. In the drawings: Figure 1 It is a schematic diagram of the vehicle-mounted ECU communication parameter configuration document to ODX-C file automatic generation method of the application; Figure 2 It is a schematic diagram of the XML structure; Figure 3 It is a generation interface diagram of ODC-C; Figure 4 It is a schematic diagram of the vehicle-mounted ECU communication parameter configuration document to ODX-C file automatic generation system of the application; Figure 5 It is a schematic diagram of an electronic device. DETAILED DESCRIPTION

[0021] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0022] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0023] According to the first aspect of this application, Figure 1 As shown, this embodiment provides a method for automatically generating ODX-C files from vehicle ECU communication parameter configuration documents, including: Step S101: Configure the key communication parameter information table and protocol configuration table based on the protocol knowledge base.

[0024] In some implementations of this embodiment, a key communication parameter information table is configured based on a protocol knowledge base. The key communication parameter information table includes key communication parameters, data types, allowed values, required values, optional values, applicable protocol types, and descriptions, as shown in Table 1. In Table 1, the meaning of each header name is the corresponding description.

[0025] Table 1 Key Communication Parameter Information

[0026] In some implementations of this embodiment, a protocol configuration table is configured based on a protocol knowledge base. The protocol configuration table includes key communication parameters and corresponding protocol configuration values, as shown in Table 2, which contains DoCAN protocol configuration values; and as shown in Table 3, which contains DoIP protocol configuration values.

[0027] Table 2 DoCAN Protocol Configuration Values

[0028] Table 3 DoCAN Protocol Configuration Values

[0029] In this embodiment, in Table 2, the Chinese meanings of ECU-Name, ECU-FullName, Protocol, CAN Channe, CAN Baudrate, Addressing method, CAN Physical Request ID, CAN Response ID, and CAN Functional Request ID are electronic control unit name, electronic control unit full name, protocol type, CAN channel, baud rate, addressing method, physical request ID, response ID, and function ID, respectively.

[0030] In this embodiment, in Table 3, the Chinese meanings of ECU-Name, ECU-Full Name, Protocol, IP-ADDRESS, PORT, LOGICAL-TESTER-ADDRESS, LOGICAL-FUNCTIONAL-ADDRESS, LOGICAL-ECU-ADDRESS, N_As, N_Ar, N_Bs, and N_Cr are electronic control unit name, electronic control unit full name, protocol type, IP address, port, logical tester address, function address, logical ECU address, sender timeout, receiver timeout, sender timeout after flow control, and receiver continuous frame timeout, respectively.

[0031] In some embodiments of this embodiment, the key communication parameter information table and the protocol configuration table are configured based on ASAM ODX (template technology of the automotive open system architecture standard), to ensure that the generated ODX-C file completely conforms to the industry specifications. The output file contains complete DIAG LAYER CONTAINER (diagnostic layer container), ECU CONFIG (electronic control unit configuration), PROTOCOL (protocol) definitions, and protocol-specific parameter settings.

[0032] In this way, by configuring the key communication parameter information table and the protocol configuration table based on the protocol knowledge base, the key communication parameters and the corresponding protocol configurations are sorted out.

[0033] Step S102: Extracting key communication parameters and corresponding protocol configurations from the vehicle-mounted ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm.

[0034] In this embodiment, the vehicle-mounted ECU communication parameter configuration document includes ECU technical specifications, network design documents, test reports, and other files, which are not limited in this embodiment.

[0035] In some embodiments of this embodiment, the extracting of the key communication parameters and the corresponding protocol configurations from the vehicle-mounted ECU communication parameter configuration document based on the multi-dimensional parameter recognition algorithm includes: Obtain a vehicle-mounted ECU communication parameter configuration document; Standardize the vehicle-mounted ECU communication parameter configuration document, the standardization process including removing empty lines and comment lines, unifying unit formats, converting special formats into standard formats, and generating a standardized internal data structure; Locate the positions of key communication parameters in the standardized internal data structure based on keyword matching, obtain initial key communication parameters including ECU basic information, CAN parameters, and timing parameters, and protocol types; Correct the ECU basic information, CAN parameters, and timing parameters based on a parameter dependency graph to obtain corrected key communication parameters; Confirm the matching degree of the protocol type and the corrected key communication parameters, and then supplement the corrected key communication parameters according to the matching degree to obtain final key communication parameters.

[0036] In the traditional configuration manual configuration process, empty lines, comment lines, special formats, and timing parameter units are easily confused, leading to failed diagnostic communication. The embodiment standardizes the vehicle-mounted ECU communication parameter configuration document, the standardization process including removing empty lines and comment lines, unifying unit formats, converting special formats into standard formats, and generating a standardized internal data structure, to ensure successful diagnostic communication.

[0037] In some embodiments of the embodiment, the ECU basic information includes ECU name, hardware version, and software version; the protocol type includes DoCAN, DoIP, and addressing mode; the CAN parameters include channel, baud rate, ID format, physical addressing ID, and functional addressing ID; and the timing parameters include N_As, N_Bs, N_Cr, P2, P2*, and S3.

[0038] In some embodiments of the embodiment, different ECU suppliers use different communication protocols (DoCAN, DoIP, etc.), and the configuration rules differ greatly, so engineers need to have professional knowledge of multiple protocols. Therefore, the embodiment also classifies and processes protocol types as DoCAN protocol or DoIP protocol.

[0039] In some possible embodiments, when the protocol type is DoCAN protocol, the method further includes: CAN parameter processing: verifying CAN ID format (such as 11bit / 29bit) and value range, checking baud rate standard value (125k, 250k, 500k, 1M, 2M), and configuring flow control parameters (BS, STmin); Timing parameter processing: converting the time unit of the timing parameters to milliseconds, verifying the logical relationship of the timing parameters, and setting default values and boundary conditions (such as maximum and minimum values); Addressing configuration: A correlation analysis method based on the communication matrix is ​​adopted to separate the physical addressing ID and the functional addressing ID, and to verify the uniqueness of the address and detect conflicts.

[0040] In some implementations of this embodiment, a correlation analysis method based on the communication matrix is ​​used to separate the physical addressing ID and the functional addressing ID, including: Read the vehicle ECU communication parameter configuration document as a communication matrix to obtain message ID, sending node and receiving node; A preliminary correlation analysis is performed on the message ID. If the message ID is bound to the ECU node address and mapped to a single receiving node, then the message ID is a physical addressing ID; if the message ID is not bound to the ECU node address and mapped to multiple receiving nodes, then the message ID is a functional addressing ID. Output the message ID that cannot be confirmed. Manually verify whether the message ID that cannot be confirmed is a physical addressing ID or a functional addressing ID.

[0041] In some possible implementations, if the protocol type is DoIP, it also includes: Ethernet parameter processing: Assign and authenticate function address IDs, configure vehicle discovery parameters, and set network activation timeout handling schemes.

[0042] Security mechanism configuration: Key communication parameters are encrypted using secure algorithm parameters.

[0043] Thus, this embodiment supports multiple mainstream diagnostic protocols such as DoCAN and DoIP, and can automatically generate the corresponding XML structure according to the protocol type. For the DoCAN protocol, the system fully handles CAN ID allocation, timing parameter configuration, flow control parameters, etc.; for the DoIP protocol, it handles function addressing ID, vehicle discovery parameters, etc.

[0044] In some embodiments of this example, the step of correcting the ECU basic information, CAN parameters, and timing parameters based on the parameter dependency graph to obtain the corrected key communication parameters includes: A parameter dependency graph is established, which includes nodes, edges, and constraint rules. The nodes are the initial key communication parameters, the edges are the dependencies between each pair of initial key communication parameters, and the constraint rules are the triggering conditions, legal value ranges, and exception handling logic for the dependencies. Circular dependencies and constraint conflicts are detected in the parameter dependency graph. If a circular dependency and / or constraint conflict causes the initial key communication parameters to be unresolved, the ECU basic information, CAN parameters, and timing parameters are corrected to obtain the corrected key communication parameters.

[0045] In some embodiments of the present embodiment, the matching degree of the confirmation protocol type with the ECU basic information, the CAN parameters and the timing parameters is used to supplement the ECU basic information, the CAN parameters and the timing parameters, including: If the matching degree is greater than the second threshold (90 points) and less than or equal to the first threshold (99 points), it is indicated that the required parameters are complete, and a few optional parameters are missing (such as padding bytes), a note is generated, and default values are automatically supplemented for the missing modified key communication parameters; If the matching degree is greater than the third threshold (69 points) and less than or equal to the second threshold (90 points), it is indicated that 1-2 required parameters are missing (such as missing physical request ID), a file with a

to be supplemented

[0046] The first threshold, the second threshold, the third threshold and the fourth threshold decrease in turn.

[0047] In some embodiments of the present embodiment, when the protocol type is DoCAN protocol, the CAN parameters include physical addressing ID and function addressing ID, and a correlation analysis method based on a communication matrix is used to separate the physical addressing ID and the function addressing ID, including: The vehicle ECU communication parameter configuration document is read as a communication matrix to obtain message ID, sending node and receiving node; The message ID is subjected to preliminary correlation analysis, if the message ID is bound with the ECU node address and mapped to a single receiving node, the message ID is a physical addressing ID; if the message ID is not bound with the ECU node address and mapped to multiple receiving nodes, the message ID is a function addressing ID; The message ID that cannot be confirmed is output, and manual verification is used to confirm whether the message ID that cannot be confirmed is a physical addressing ID or a function addressing ID.

[0048] In some embodiments of the present embodiment, further comprising: Syntax and format checking, specifically including XML structure pre-verification, tag nesting relationship checking, attribute value format verification (hexadecimal, decimal, string), naming specification checking (ECU name, parameter naming).

[0049] Business logic verification specifically includes parameter range verification, CANID range (e.g., 0x0000x7FF for 11 bits, 0x000000000x1FFFFFFF for 29 bits), reasonable range of timing parameters (N_As: 101000ms, N_Bs: 505000ms, etc.), and whether the baud rate standard value matches within the standard range.

[0050] Logical relationship verification specifically includes the correlation between request ID and response ID, and consistency of physical / functional addressing configuration. Session mode (e.g., 0x100x01, 0x100x02, 0x100x03, 0x100x04) matches security level (e.g., 0x270x01, 0x270x02, 0x270x03, 0x270x04).

[0051] Conflict detection and resolution specifically include ID conflict detection: ID uniqueness check within the same channel, ID conflict detection across ECUs, and if IDs are duplicated, suggestions for ID reallocation are provided so that engineers can quickly make corrections.

[0052] Step S103: Fill the key communication parameters into the key communication parameter information table to obtain the filled key communication parameter information table, and fill the key communication parameters and corresponding protocol configurations into the protocol configuration table to obtain the filled protocol configuration table.

[0053] Step S104: Construct an XML structure based on the diagnostic service.

[0054] In some implementations of this embodiment, such as Figure 2 The diagram shows an XML structure. Constructing an XML structure based on diagnostic services includes: Generate the ODX root node; A diagnostic layer container is generated for the root node; Generate an ECU configuration sub-node for the diagnostic layer container; Generate ECU short name sub-node, ECU long name sub-node, and protocol configuration sub-node for the ECU configuration sub-node; Generate a protocol type sub-node and a CAN parameter sub-node for the protocol configuration sub-node; Generate CAN parameter sub-nodes, CAN channel sub-nodes, baud rate sub-nodes, ID format sub-nodes, physical addressing ID sub-nodes, functional addressing ID sub-nodes, response ID sub-nodes, and timing parameter sub-nodes for the CAN parameter sub-nodes; For the timing parameter sub-node, generate application layer wait time sub-node, normal response timeout sub-node, and enhanced response timeout sub-node.

[0055] Step S105: filling the filled key communication parameter information table and the filled protocol configuration table into the XML structure to generate an ODX-C file.

[0056] Specifically, the information in the filled key communication parameter information table and the filled protocol configuration table is filled into respective sub-nodes in the XML structure, as shown in FIG. 5, which is a generation interface diagram of the ODC-C. Figure 3

[0057] In this way, automatic integration from a dispersed vehicle-mounted ECU communication parameter configuration document to a unified configuration is achieved, the problems of incomplete parameter collection and non-uniform format in the traditional mode are solved, the generation strategy and output structure are automatically adjusted according to the protocol type, parameter configuration problems are found in real time during the generation process, the traditional post-validation mode is changed, preventive quality control is achieved, the configuration experience of senior engineers is converted into system rules, standardization and reusability of expert experience are achieved, the user operation process is greatly simplified, and the complex technical work of automatic generation of the ODX-C file becomes simple and easy to use.

[0058] According to a second aspect of the present application, as shown in FIG. 6, the embodiment provides a vehicle-mounted ECU communication parameter configuration document to ODX-C file automatic generation system, which comprises: Figure 4 A configuration module 401 configured to configure a key communication parameter information table and a protocol configuration table based on a protocol knowledge base; An extraction module 402 configured to extract key communication parameters and corresponding protocol configurations from a vehicle-mounted ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm; A first filling module 403 configured to fill the key communication parameters into the key communication parameter information table to obtain a filled key communication parameter information table, and fill the key communication parameters and the corresponding protocol configurations into the protocol configuration table to obtain a filled protocol configuration table; A construction module 404 configured to construct an XML structure based on a diagnostic service; A second filling module 405 configured to fill the information in the filled key communication parameter information table and the filled protocol configuration table into the XML structure to generate an ODX-C file. Specifically, the embodiment corresponds to the above method embodiment one by one, and the functions of each module have been described in detail in the corresponding method embodiment, and thus will not be described one by one.

[0059] According to a third aspect of the present application, the embodiment provides a computer readable storage medium having a computer program stored thereon, the computer program comprising executable instructions, when the executable instructions are executed by a processor, the above method is implemented.

[0060]

[0061] ​​The present application implements all or part of the above method, which can also be completed by a computer program instructing related hardware. The computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of the above method embodiments can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or system that can carry computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content of the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0062] According to a fourth aspect of the present application, as shown in Figure 5 there is provided an electronic device, comprising: one or more processors; a memory for storing executable instructions of the processor, when the executable instructions are executed by the one or more processors, causing the one or more processors to implement the above method.

[0063] The electronic device is in the form of a general-purpose computing device. The components of the electronic device can include but are not limited to the above at least one processor, the above at least one memory, a bus connecting different system components including the memory and the processor.

[0064] The processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), ready programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the computer system, which connects all parts of the computer system through various interfaces and lines.

[0065] The memory can be used to store computer programs and / or modules, and the processor realizes various functions of the computer system by running or executing the computer programs and / or modules stored in the memory, and calling data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.); and the data storage area can store data created according to the use of the mobile phone (such as audio data, video data, etc.). In addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state memory devices.

[0066] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, a server or a computer program product. Therefore, the present application can adopt a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage and memory, etc.) containing computer usable program codes.

[0067] The present application is described with reference to flowcharts and / or block diagrams of methods, devices (systems), servers and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device that implements the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 a system that realizes the functions specified in one or more flows or blocks.

[0068] These computer program instructions can also be stored in a computer readable memory capable of guiding a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction system, which realizes the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 a system that realizes the functions specified in one or more flows or blocks.

[0069] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 Figure 1

[0070] It should be understood that the sequence of the steps in the above-described embodiments does not mean the order of execution, and the execution order of the processes should be determined according to the functions and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0071] In the above-described embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in a certain embodiment can be referred to the relevant description of other embodiments.

[0072] The above, the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit it; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.​​

Claims

1. A method for automatically generating ODX-C files from vehicle ECU communication parameter configuration documents, characterized in that, include: Configure key communication parameter information tables and protocol configuration tables based on the protocol knowledge base; Key communication parameters and corresponding protocol configurations are extracted from the vehicle ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm. Fill the key communication parameters into the key communication parameter information table to obtain the filled key communication parameter information table, and fill the key communication parameters and corresponding protocol configurations into the protocol configuration table to obtain the filled protocol configuration table. Construct an XML structure based on diagnostic services; Fill the information from the filled key communication parameter information table and the filled protocol configuration table into an XML structure to generate an ODX-C file.

2. The method according to claim 1, characterized in that, The configuration of the key communication parameter information table and protocol configuration table based on the protocol knowledge base includes: The key communication parameter information table is configured based on the protocol knowledge base. The key communication parameter information table includes key communication parameters, data types, allowed values, required values, optional values, applicable protocol types, and descriptions. The protocol configuration table is configured based on the protocol knowledge base. The protocol configuration table includes key communication parameters and their corresponding protocol configuration values.

3. The method according to claim 1, characterized in that, The multi-dimensional parameter recognition algorithm extracts key communication parameters and corresponding protocol configurations from the vehicle ECU communication parameter configuration document, including: Obtain the vehicle ECU communication parameter configuration document; The vehicle ECU communication parameter configuration document is standardized. The standardization process includes removing blank lines and comment lines, unifying unit format, converting special formats into standard formats, and generating a standardized internal data structure. Based on keyword matching, the location of key communication parameters in the standardized internal data structure is located, and the initial key communication parameters and protocol type are obtained. The initial key communication parameters include ECU basic information, CAN parameters and timing parameters. Based on the parameter dependency graph, the ECU basic information, CAN parameters and timing parameters are corrected to obtain the corrected key communication parameters; Confirm the matching degree between the protocol type and the revised key communication parameters. Based on the matching degree, supplement the revised key communication parameters to obtain the final key communication parameters.

4. The method according to claim 3, characterized in that, The parameter dependency graph is used to correct the ECU basic information, CAN parameters, and timing parameters to obtain the corrected key communication parameters, including: A parameter dependency graph is established, which includes nodes, edges, and constraint rules. The nodes are the initial key communication parameters, the edges are the dependencies between each pair of initial key communication parameters, and the constraint rules are the triggering conditions, legal value ranges, and exception handling logic for the dependencies. Circular dependencies and constraint conflicts are detected in the parameter dependency graph. If a circular dependency and / or constraint conflict causes the initial key communication parameters to be unresolved, the ECU basic information, CAN parameters, and timing parameters are corrected to obtain the corrected key communication parameters.

5. The method according to claim 3, characterized in that, The matching degree between the confirmed protocol type and the revised key communication parameters is then used to supplement the revised key communication parameters, resulting in the final key communication parameters, including: If the matching degree is greater than the second threshold and less than or equal to the first threshold, the missing corrected key communication parameters will be automatically supplemented with default values. If the matching degree is greater than the third threshold and less than or equal to the second threshold, the missing corrected key communication parameters are manually supplemented. If the matching degree is greater than the fourth threshold and less than or equal to the third threshold, stop generating and provide modification suggestions: If the matching degree is less than or equal to the fourth threshold, it indicates that the protocol type has been selected incorrectly. It is recommended to change the protocol type or re-enter the vehicle ECU communication parameter configuration document. The first threshold, the second threshold, the third threshold, and the fourth threshold decrease sequentially.

6. The method according to claim 3, characterized in that: When the protocol type is DoCAN, the CAN parameters include physical addressing ID and functional addressing ID. Using a correlation analysis method based on the communication matrix, the physical addressing ID and functional addressing ID are separated, including: Read the vehicle ECU communication parameter configuration document as a communication matrix to obtain message ID, sending node and receiving node; A preliminary correlation analysis is performed on the message ID. If the message ID is bound to the ECU node address and mapped to a single receiving node, then the message ID is a physical addressing ID; if the message ID is not bound to the ECU node address and mapped to multiple receiving nodes, then the message ID is a functional addressing ID. Output the message ID that cannot be confirmed. Manually verify whether the message ID that cannot be confirmed is a physical addressing ID or a functional addressing ID.

7. The method according to claim 1, characterized in that, The construction of the XML structure based on diagnostic services includes: Generate the ODX root node; A diagnostic layer container is generated for the root node; Generate an ECU configuration sub-node for the diagnostic layer container; Generate ECU short name sub-node, ECU long name sub-node, and protocol configuration sub-node for the ECU configuration sub-node; Generate a protocol type sub-node and a CAN parameter sub-node for the protocol configuration sub-node; Generate CAN parameter sub-nodes, CAN channel sub-nodes, baud rate sub-nodes, ID format sub-nodes, physical addressing ID sub-nodes, functional addressing ID sub-nodes, response ID sub-nodes, and timing parameter sub-nodes for the CAN parameter sub-nodes; For the timing parameter sub-node, generate application layer wait time sub-node, normal response timeout sub-node, and enhanced response timeout sub-node.

8. A system for automatically generating ODX-C files from vehicle ECU communication parameter configuration documents, characterized in that, include: The configuration module is used to configure key communication parameter information tables and protocol configuration tables based on the protocol knowledge base; The extraction module is used to extract key communication parameters and corresponding protocol configurations from the vehicle ECU communication parameter configuration document based on a multi-dimensional parameter recognition algorithm. The first filling module is used to fill the key communication parameters into the key communication parameter information table to obtain the filled key communication parameter information table, and to fill the key communication parameters and corresponding protocol configurations into the protocol configuration table to obtain the filled protocol configuration table. The building module is used to construct the XML structure based on diagnostic services; The second filling module is used to fill the information from the filled key communication parameter information table and the filled protocol configuration table into an XML structure to generate an ODX-C file.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program includes executable instructions that, when executed by a processor, implement the method of any one of claims 1-7.

10. An electronic device, characterized in that, include: One or more processors; A memory for storing executable instructions of the processor, which, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-7.

Images