Method for generating odx file from dbc file and electronic device

Abstract

The application provides a method for generating an ODX file from a DBC file and an electronic device. The method comprises: screening diagnosis-related parameters from parameters obtained by parsing a DBC file, and filtering the remaining parameters; building an ODX hierarchy according to a hierarchical structure of an ODX standard, and mapping communication timing parameters and network layer parameters in the DBC file to communication parameter references mounted on a protocol layer in the ODX hierarchy; establishing a mapping of the diagnosis-related parameters to diagnosis data objects in the ODX hierarchy below the protocol layer, and enabling the diagnosis data objects to share communication timing parameters and network layer parameters carried by the communication parameter references; performing compliance verification on the ODX hierarchy after the mapping is established, and outputting an ODX file if the compliance verification is passed. The method can convert the DBC file into an ODX file that conforms to the ODX standard and is consistent with the DBC file, and improves the reliability of diagnosis development.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic data processing technology, specifically to a method and electronic device for generating ODX files from DBC files. Background Technology

[0002] In the diagnostic development of automotive electronic control units, bus communication messages and signals are typically defined using DBC files, while diagnostic equipment and testing tools parse diagnostic data based on a different diagnostic data description file. To enable diagnostic equipment to parse diagnostic data on the bus, the diagnostic-related content defined in the DBC file needs to be converted into a format conforming to the standard of this diagnostic data description file.

[0003] During the aforementioned conversion process, the parameter organization method used in the DBC file is inconsistent with the hierarchical structure, field definitions, and parameter expression methods required by the diagnostic data description file standard. Differences exist in the expression of signal bit fields, the carrying of communication parameters, and the description of numerical conversions. Furthermore, there is a lack of a unified method to verify whether the conversion result conforms to the standard and is consistent with the DBC file. In this situation, the resulting diagnostic data description file may not correspond to the original definition of the DBC file or may not conform to the diagnostic data description file standard, leading to deviations in the diagnostic equipment's interpretation of the diagnostic data and affecting the reliability of diagnostic development. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method and electronic device for generating ODX files from DBC files, so that DBC files are converted into ODX files that conform to the ODX standard and are consistent with DBC files, thereby improving the reliability of diagnostic development.

[0005] The first aspect of this application provides a method for generating an ODX file from a DBC file, including: From the parameters parsed from the DBC file, select the diagnostic-related parameters and filter out the remaining parameters; The ODX layer is constructed according to the hierarchical structure of the ODX standard, and the communication timing parameters and network layer parameters in the DBC file are mapped to the communication parameter references mounted on the protocol layer in the ODX layer. Below the protocol layer, a mapping is established between the diagnostic-related parameters and the diagnostic data objects in the ODX layer, and the diagnostic data objects share the communication timing parameters and network layer parameters carried by the communication parameter references; Perform compliance verification on the ODX level after the mapping is established, and output the ODX file if the compliance verification passes.

[0006] In one embodiment, the step of selecting diagnostic-related parameters from the parameters parsed from the DBC file and filtering the remaining parameters includes: Based on the configurable diagnostic whitelist, from the message objects, signal objects, custom attribute objects, and node objects obtained by parsing the DBC file, the diagnostic-related parameters that match the diagnostic whitelist are retained, and the parameters that do not match the diagnostic whitelist are filtered out.

[0007] In one embodiment, the diagnostic whitelist includes independent functional addressing identifiers and physical addressing identifiers, wherein the functional addressing identifier and the physical addressing identifier are different addresses; the filtering further includes: The message object carrying the functional addressing identifier and the message object carrying the physical addressing identifier are respectively retained as functional addressing parameters and physical addressing parameters.

[0008] In one embodiment, the filtering further includes: Based on the length of the diagnostic payload and the transmission protocol followed by the network layer parameters in the DBC file, the message object is determined to be a single frame or multiple frames, and the corresponding frame type is marked for the message object.

[0009] In one embodiment, mapping the communication timing parameters and network layer parameters in the DBC file to communication parameter references mounted at the protocol layer in the ODX layer includes: The communication parameter reference is mounted below the protocol layer, so that the diagnostic services below the protocol layer can share the communication timing parameters and the network layer parameters through the communication parameter reference.

[0010] In one embodiment, the diagnostic-related parameters include signals, and establishing the mapping of the diagnostic-related parameters to diagnostic data objects in the ODX hierarchy includes: Based on the byte order of the signal, the start bit of the signal is normalized, and the normalized start bit is mapped to the position parameter of the diagnostic data object.

[0011] In one embodiment, the diagnostic-related parameters include signals, and the step of establishing a mapping of the diagnostic-related parameters to diagnostic data objects in the ODX hierarchy further includes: The signal factors are mapped to scaling factors in the conversion method for the diagnostic data object, and the signal offset is mapped to an offset amount in the conversion method, so that the physical values ​​of the diagnostic data object are calculated according to... Sure; Where PhysValue is the physical value, RawValue is the original value, Scale is the scaling factor, and Offset is the offset.

[0012] In one embodiment, before performing compliance verification on the ODX level after the mapping is established, the method further includes: Based on the framing rules of the transmission protocol followed by the network layer parameters in the DBC file, verify whether the diagnostic payload can be carried by the first frame and consecutive frames; The amount of data that each frame can carry is determined according to the number of bytes occupied by the protocol control information of that frame. If the diagnostic payload exceeds the amount of data that can be carried, it is determined that the parameters are invalid.

[0013] In one embodiment, the compliance verification of the ODX level after mapping includes: The integrity of the enumeration values ​​and parameters in the ODX level, as well as the consistency of the parameters before and after mapping, are verified. If the enumeration values ​​are compliant, the parameters are complete, and the parameters before and after mapping are consistent, the compliance verification is deemed to have passed.

[0014] A second aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. When the processor executes the computer program, it implements the method for generating an ODX file from a DBC file as provided in the first aspect of this application.

[0015] A third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for generating an ODX file from a DBC file as provided in the first aspect of this application.

[0016] A fourth aspect of this application provides a computer program product including a computer program that, when run, causes the method described in the first aspect of this application to be performed.

[0017] The method for generating an ODX file from a DBC file provided in the first aspect of this application involves filtering out diagnostic-related parameters and other parameters from the parameters parsed from the DBC file, constructing an ODX layer according to the hierarchical structure of the ODX standard, and mounting the communication timing parameters and network layer parameters in the DBC file on the protocol layer of the ODX layer via communication parameter references. This establishes a mapping between the diagnostic-related parameters and diagnostic data objects in the ODX layer. The mapped ODX layer then undergoes compliance verification, and an ODX file is output if the compliance verification passes. Since the communication timing parameters and network layer parameters are centrally carried and mounted on the protocol layer via communication parameter references, diagnostic data objects below the protocol layer do not need to repeatedly configure communication parameters to share the same set of communication parameters. This converts the DBC file into an ODX file that conforms to the ODX standard and is consistent with the DBC file, enabling diagnostic devices to parse diagnostic data based on the ODX file and improving the reliability of diagnostic development.

[0018] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0020] Figure 1 This is a schematic flowchart of a method for generating an ODX file from a DBC file according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the screening of diagnostic-related parameters according to an embodiment of this application; Figure 3 This is a schematic diagram illustrating the mapping of a DBC signal to a diagnostic data object according to an embodiment of this application; Figure 4 This is a schematic diagram of a multi-frame bearer capability verification provided in an embodiment of this application; Figure 5 This is a schematic diagram of a three-layer compliance verification process provided in one embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] The method for generating ODX files from DBC files provided in this application can be applied to scenarios in vehicle diagnostic development where a DBC bus database is automatically converted into a diagnostic data description file conforming to the ASAM ODX standard. It is particularly suitable for batch and losslessly converting diagnostic-specific DBC files into ODX files that can be directly parsed by third-party diagnostic equipment and testing tools. It can be executed by electronic devices with file parsing and processing capabilities when running the corresponding computer program.

[0027] To facilitate understanding, the terminology involved in this method is illustrated below using a typical application scenario. In this scenario, the DBC file is a diagnostic-specific file defined according to standard DBC syntax and extended by engineering conventions to carry diagnostic semantics. Its native objects include BO_message objects carrying messages, SG_signal objects carrying signals, BA_attribute objects carrying custom attributes, BU_node objects carrying nodes, and CM_annotation objects carrying annotations. This DBC file carries diagnostic addressing and ISO 15765-2 network layer parameters through the custom attribute BA_ and the agreed message identifier. The ODX hierarchy is a hierarchical structure defined according to the XSD Schema of the ASAM ODX2.2.0 standard, which includes the VEHICLE-INFO hierarchy carrying vehicle and variant information, the ECU node carrying electronic control unit information, the DIAG-DATA-DICTIONARY as a global parameter container, the DIAG-COMM node carrying diagnostic services, and the DOP as the basic unit for describing diagnostic data. Diagnostic-related parameters are the communication, signal, and fault parameters related to UDS diagnosis in the DBC file, which are distinct from ordinary CAN messages, periodic signals, and event signals. The above scenario is merely an example; this method does not restrict the specific source of the DBC file or the specific purpose of the ODX file.

[0028] like Figure 1 As shown in the embodiments of this application, the method for generating an ODX file from a DBC file includes the following steps S101 to S104: Step S101: Select diagnostic-related parameters from the parameters obtained by parsing the DBC file and filter out the remaining parameters; In application, the electronic device first uses standard DBC syntax to segment and parse the DBC file, parsing line by line to extract five types of native objects: BO_message objects, SG_signal objects, BA_custom attribute objects, BU_node objects, and CM_annotation objects. The source parameters required for conversion all originate from these native objects. After parsing, a whitelist is used for filtering, retaining only bus parameters related to UDS diagnosis, while filtering out ordinary CAN messages, periodic signals, and event signals, thus distinguishing diagnostic-related parameters from the mixed bus data. During extraction, corresponding parameters are extracted for each object: from BO_message objects, message identifier, message data length, message transmission direction, and frame type are extracted; from SG_signal objects, signal name, start bit, bit length, byte order, value type, factor, offset, physical minimum value, physical maximum value, and unit are extracted; from BA_attribute objects, bus type, protocol type, communication timing, and network layer parameters are extracted; from BU_node objects, diagnostic nodes are extracted; and from CM_annotation objects, annotations corresponding to messages, signals, or nodes are extracted. The above parameters are stored in categories such as communication identifier, bit field parameters, timing parameters and text parameters, and a unique index is created for each source parameter to avoid parameter misalignment, mixing or loss. This ensures that the parameters used in each step are consistent and can be used uniformly when building the hierarchy and establishing the mapping.

[0029] Step S102: Build the ODX layer according to the hierarchical structure of the ODX standard, and map the communication timing parameters and network layer parameters in the DBC file to the communication parameter references mounted on the protocol layer in the ODX layer; In application, electronic devices strictly adhere to the fixed-level ODX hierarchy defined by the XSD Schema of the ASAM ODX2.2.0 standard, prohibiting custom hierarchies and cross-hierarchy mounting, thereby ensuring that the constructed ODX hierarchy can pass the official schema verification.

[0030] Specifically, in the VEHICLE-INFO level, electronic devices map vehicle and variant information, mapping custom attribute values ​​of DBC file versions to the top-level version information, mapping DBC file names to the short names of the base variants, and fixing the model version of the root element to 2.2.0. In the ECU node, electronic control unit information is mapped, mapping the BU_ node name to the short name of the ECU and the corresponding CM_ annotation to the long name of the ECU. DIAG-DATA-DICTIONARY is used as a globally unique parameter container, ensuring that all diagnostic data objects generated by diagnostic signals are uniformly mounted under it without any free parameters. The DIAG-COMM node is identified by the UDS protocol, and the REQUEST for bearer request messages and the RESPONSE for bearer response messages are initialized under it. The constructed ODX level has a fixed hierarchical structure and a unique mounting position; diagnostic-related parameters are then mapped to this structure.

[0031] Step S103: Below the protocol layer, establish a mapping between the diagnostic-related parameters and the diagnostic data objects in the ODX layer, and make the diagnostic data objects share the communication timing parameters and network layer parameters carried by the communication parameter references; In application, electronic devices use diagnostic data objects as the basic unit for describing diagnostic data, and map the filtered diagnostic-related parameters to the diagnostic data objects in the ODX level one by one, so that the mapped parameters can be reversed to restore the original configuration of the DBC file.

[0032] Specifically, electronic devices map signal names to short names of diagnostic data objects, signal bit-field parameters to position and length parameters of diagnostic data objects, signal byte order to encoded byte order of diagnostic data objects, signal value types to data types of diagnostic data objects, signal factors and offsets to conversion methods of diagnostic data objects, and signal physical minimum and maximum values ​​to value constraints of diagnostic data objects. Each diagnostic data object is uniformly mounted under DIAG-DATA-DICTIONARY, and then associated with it through references in request and response parameters, thereby enabling diagnostic-related parameters to obtain a complete and traceable corresponding description at the ODX level.

[0033] Step S104: Perform compliance verification on the ODX level after the mapping is established, and output the ODX file if the compliance verification passes; In application, after establishing the mapping but before outputting the file, the electronic device performs compliance verification on the ODX level to ensure that the generated file conforms to the ODX standard and is consistent with the original configuration of the DBC file. If the verification passes, the electronic device assembles a complete extensible markup language structure according to the ASAM ODX2.2.0 standard to generate a standardized ODX file. If the verification fails, the electronic device marks the error as an anomaly and outputs a log without generating a file, thus preventing non-compliant or biased files from entering the subsequent diagnostic development process. The generated ODX file is compatible with mainstream diagnostic devices and testing tools.

[0034] In this embodiment, the four stages of screening, hierarchical construction, mapping, and compliance verification share the same set of diagnostic-related parameters. These parameters are categorized, stored, and indexed during the parsing phase, ensuring consistent values ​​for each subsequent stage and preventing the same parameter from being interpreted differently in different stages. Screening separates diagnostic-related parameters from the mixed bus data. Hierarchical construction provides these parameters with ODX-compliant locations, centrally carrying communication timing parameters and network layer parameters at the protocol layer via communication parameter references. Mapping fills parameters into their corresponding locations and maintains a traceable correspondence, allowing diagnostic data objects below the protocol layer to share the communication parameters carried by communication parameter references without requiring repeated configuration. Compliance verification is performed before file output. These four stages are interconnected, enabling DBC files to be converted into ASAM ODX-compliant diagnostic files without manual intervention.

[0035] In one embodiment, the step of selecting diagnostic-related parameters from the parameters parsed from the DBC file and filtering the remaining parameters includes: Based on the configurable diagnostic whitelist, from the message objects, signal objects, custom attribute objects, and node objects obtained by parsing the DBC file, the diagnostic-related parameters that match the diagnostic whitelist are retained, and the parameters that do not match the diagnostic whitelist are filtered out.

[0036] In applications, since DBC files are natively used to describe the application-layer CAN signal layout, they contain both diagnostic-related parameters and a large number of ordinary CAN messages, periodic signals, and event signals unrelated to diagnosis. Electronic devices distinguish between these two types of signals using a configurable diagnostic whitelist. This diagnostic whitelist can be provided by an engineering configuration table, which records the conditions used to determine diagnostic-related parameters, including the value range of the diagnostic message identifier, custom attributes used to mark diagnostic purposes, and naming conventions used to identify diagnostic signals. After parsing the message object, signal object, custom attribute object, and node object, the electronic device matches each object against the diagnostic whitelist. Objects matching the whitelist are retained as diagnostic-related parameters and sent to subsequent layer construction and mapping; objects not matching the whitelist are filtered out as non-diagnostic parameters and discarded. Because the diagnostic whitelist is configurable, when the identifier allocation or naming convention of diagnostic messages changes, only the configuration table needs to be adjusted for adaptation, without modifying the conversion process itself.

[0037] Figure 2 This is a schematic diagram of a diagnostic-related parameter screening method provided in an embodiment of this application. Figure 2 The process for filtering diagnostic-related parameters is illustrated: After word segmentation and parsing, the DBC file yields message objects, signal objects, custom attribute objects, and node objects, forming a set of parameters to be filtered. The electronic device sequentially sends each object in this parameter set to a configurable diagnostic whitelist for matching. The diagnostic whitelist includes three filtering conditions: diagnostic message identifier range, diagnostic purpose custom attributes, and diagnostic signal naming conventions. For objects that match any of the above filtering conditions, the electronic device retains them as diagnostic-related parameters and sends them to the subsequent hierarchical construction and mapping stages. For objects that do not match any filtering conditions, they are filtered out and discarded as non-diagnostic parameters, thus completing the separation of diagnostic-related parameters from non-diagnostic parameters. Figure 2 It is evident that the screening of diagnostic parameters does not require manual judgment item by item; it can be completed by matching the whitelist conditions once. Furthermore, when the diagnostic message identifier allocation or signal naming convention changes, only the whitelist configuration needs to be adjusted to adapt, and the screening process itself remains unchanged.

[0038] In this embodiment, the diagnostic whitelist addresses the following issue: diagnostic parameters are mixed with ordinary CAN messages, periodic signals, and event signals in the DBC file. Manual screening is inefficient and prone to omissions. Matching via the whitelist retains matched items and discards those that don't, achieving differentiation in a single process. Subsequent processing only requires diagnostic-related parameters; non-diagnostic parameters do not enter the ODX level. The advantage of making the whitelist configurable is that diagnostic message identifier allocation and signal naming conventions often differ between projects. When encountering such differences, only the configuration table needs adjustment, without modifying the conversion process itself.

[0039] In one embodiment, the diagnostic whitelist includes independent functional addressing identifiers and physical addressing identifiers, wherein the functional addressing identifier and the physical addressing identifier are different addresses; the filtering further includes: The message object carrying the functional addressing identifier and the message object carrying the physical addressing identifier are respectively retained as functional addressing parameters and physical addressing parameters.

[0040] In application, functional addressing in diagnostic communication is used for vehicle-wide broadcast diagnostics, while physical addressing is used for point-to-point diagnostics targeting individual electronic control units (ECUs). These two methods are address-independent. In the diagnostic whitelist, the functional addressing identifier is a pre-defined broadcast address, such as 0x7DF, and the physical addressing identifier is a single-node address assigned to each ECU, such as 0x7E0. These are different addresses and cannot have the same value. During filtering, the electronic device retains the message object carrying the functional addressing identifier as a functional addressing parameter and the message object carrying the physical addressing identifier as a physical addressing parameter, thus distinguishing the broadcast diagnostic channel from the point-to-point diagnostic channel at the source. The physical addressing parameter also includes paired physical request and physical response addresses, for example, a physical request address of 0x7E0 and a physical response address of 0x7E8, which are bound together to form a bidirectional diagnostic link. After the functional and physical addressing parameters are retained separately, they are written into the independent functional addressing communication parameters and physical addressing communication parameters at the ODX level in subsequent mappings.

[0041] In this embodiment, functional addressing is used for vehicle-wide broadcast diagnostics, while physical addressing is used for point-to-point diagnostics; these are inherently different addresses. By defining them as distinct addresses and retaining them separately as functional addressing parameters and physical addressing parameters during filtering, the broadcast channel and point-to-point channel are effectively separated at the very beginning of the conversion process. This avoids incorrect communication addressing configuration in subsequent stages due to treating functional addressing and physical addressing as the same address. The two sets of parameters are written into independent communication parameters during mapping, ensuring that broadcast diagnostics and point-to-point diagnostics in the final generated ODX file use independent addressing and do not interfere with each other.

[0042] In one embodiment, the filtering further includes: Based on the length of the diagnostic payload and the transmission protocol followed by the network layer parameters in the DBC file, the message object is determined to be a single frame or multiple frames, and the corresponding frame type is marked for the message object.

[0043] In applications, the transmission of diagnostic messages on the bus must adhere to the ISO 15765-2 network layer protocol. When the diagnostic payload can be carried in a single frame, it is transmitted as a single frame; when the diagnostic payload exceeds the capacity of a single frame, it is divided into a first frame and subsequent frames for multi-frame transmission. When filtering message objects, the electronic device determines the frame type of the message object based on the length of the diagnostic payload and the transmission protocol followed by the network layer parameters in the DBC file: when the diagnostic payload can be carried in a single frame, the message object is marked as a single frame; when the diagnostic payload cannot be carried in a single frame, the message object is marked as a multi-frame. In classic CAN, after deducting protocol control information, the data available to carry the diagnostic payload in a single frame is seven bytes. In CAN FD, the first frame's carrying rules differ from classic CAN; therefore, the frame type determination is based on the length of the diagnostic payload and the framing rules of the transmission protocol, not on whether the message data length is greater than eight bytes. After the electronic device marks the message object with the corresponding frame type, this frame type is used to subsequently verify the carrying capacity of multi-frame messages.

[0044] In this embodiment, whether the frame type is single-frame or multi-frame depends on whether the diagnostic payload can be carried by a single frame, rather than whether the message data length exceeds eight bytes. The latter determination method, while seemingly simple, ignores factors such as the need to deduct protocol control information from each frame, the fact that a classic CAN single frame actually only has seven usable bytes, and the separate calculation rules for the first frame in CAN FD. Determining the frame type based on this will lead to errors. This method determines the frame type based on the diagnostic payload length and the framing rules of the transmission protocol. The marked frame type matches the actual transmission method of the diagnostic message on the bus, thus providing a reliable frame type basis for subsequent multi-frame carrying capacity verification.

[0045] In one embodiment, after constructing the ODX hierarchy according to the hierarchical structure of the ODX standard, the method further includes: The communication timing parameters and network layer parameters in the DBC file are carried by the communication parameter reference in the ODX layer, and the communication parameter reference is attached to the protocol layer of the ODX layer.

[0046] In applications, the communication timing parameters and network layer parameters in the DBC file describe the timing and multi-frame transmission behavior of diagnostic communication. After the electronic device builds the ODX layer, it carries these two types of parameters through the communication parameter reference in the ODX layer, rather than mapping them as diagnostic data objects.

[0047] Specifically, the communication timing parameters include the server's maximum response time and extended response time, which the electronic device assigns to the corresponding communication parameter references. The network layer parameters include the block size for controlling the number of consecutive frame blocks and the minimum interval time for constraining the transmission interval of consecutive frames; these are also assigned to the corresponding communication parameter references by the electronic device. The electronic device mounts the communication parameter references carrying these parameters to the protocol layer of the ODX layer, binding them to the protocol and making them communication parameters under that protocol. This allows for the complete carrying of communication timing and multi-frame transmission configuration without disrupting the diagnostic data object layer. The communication addressing parameters are also carried in the form of communication parameter references. The physical request address, physical response address, and function address are converted from their hexadecimal original values ​​to integers and written to their corresponding communication parameter references. The physical request address and physical response address are paired. These communication parameter references are read-only mapped to parameters in the DBC file. When there is no corresponding parameter in the DBC file, the corresponding communication parameter reference retains its standard default value or is left blank and logged.

[0048] In this embodiment, the communication timing parameters and network layer parameters describe communication timing and multi-frame transmission behavior. Essentially, they are not data descriptions of a specific signal, and mapping them as diagnostic data objects is inappropriate. This method carries these two types of parameters via communication parameter references and mounts them at the protocol layer, providing them with a standard-recognized carrying location without affecting the layer at which the diagnostic data object resides. After mounting at the protocol layer, these communication timing and multi-frame transmission configurations take effect along with the protocol, and the carrying location and activation timing of the parameters are both determined.

[0049] In one embodiment, the diagnostic-related parameters include signals, and establishing the mapping of the diagnostic-related parameters to diagnostic data objects in the ODX hierarchy includes: Based on the byte order of the signal, the start bit of the signal is normalized, and the normalized start bit is mapped to the position parameter of the diagnostic data object.

[0050] In applications, the start bit counting method for a signal within a CAN data frame is related to byte order. The start bit count at the same physical location differs between little-endian and big-endian byte orders. Direct mapping without conversion would cause bit field misalignment. During mapping, the electronic device normalizes the start bit of the signal based on its byte order. This means converting start bits from different byte orders to the bit position reference used at the ODX level, and then mapping the normalized start bit to the position parameter of the diagnostic data object. Specifically, in little-endian, the least significant byte in the ODX level's encoded byte order is placed last, while in big-endian, the most significant byte is placed first. The electronic device determines the normalization conversion method accordingly. Correspondingly, the electronic device also maps the signal's bit length to the length parameter of the diagnostic data object. The position parameter and length parameter together define the complete bit field range of the signal within the diagnostic data object. Since the length of the diagnostic data frame differs between classic CAN and CAN FD, the range of position parameters varies with the frame length. In CAN FD, the longest data field of a frame is sixty-four bytes, and the corresponding bit positions can reach a larger value. Therefore, electronic devices do not fix the range of position parameters to a certain narrow interval.

[0051] In this embodiment, the counting method of the start bit is related to the byte order: for the same physical location, the start bit counted under little-endian and big-endian byte orders are not the same. Direct mapping without conversion will lead to bit field misalignment. This method first normalizes the start bit to the reference used by ODX according to the byte order, and then maps it to the position parameter, thereby eliminating the bit field misalignment problem in the mapping stage. The position parameter represents the start position of the signal in the data frame, and the length parameter represents the bit field length of the signal. The two together define the complete bit field of the signal. In addition, the data field of CAN FD is up to 64 bytes, and the corresponding bit position can have a large range of values. Therefore, the value range of the position parameter varies with the frame length, and this method does not fix it to a certain narrow interval.

[0052] In one embodiment, the diagnostic-related parameters include signals, and the step of establishing a mapping of the diagnostic-related parameters to diagnostic data objects in the ODX hierarchy further includes: The signal factors are mapped to scaling factors in the conversion method for the diagnostic data object, and the signal offset is mapped to an offset amount in the conversion method, so that the physical values ​​of the diagnostic data object are calculated according to... Determine, where PhysValue is the physical value, RawValue is the original value, Scale is the scaling factor, and Offset is the offset.

[0053] In applications, the raw value of a signal needs to undergo linear transformation to obtain a physically meaningful physical value. This transformation is determined by factors and offsets. During mapping, the electronic device maps the signal's factors to scaling factors in the transformation method for the diagnostic data object, and maps the signal's offset to an offset amount in the same transformation method, ensuring that the physical value of the diagnostic data object follows the specified values. It is confirmed that the conversion relationship is completely consistent with the signal conversion relationship in the DBC file, thus ensuring that the physical values ​​remain unchanged before and after the conversion. Specifically, when no factor is given for the signal, the scaling factor takes the default value of 1.0; when no offset is given for the signal, the offset takes the default value of 0.0. The electronic device also maps the physical minimum and maximum values ​​of the signal to the value constraints of the diagnostic data object to limit the valid parsing range of the diagnostic data, ensuring that the converted physical values ​​fall within the agreed valid range. This conversion method works in conjunction with the aforementioned position parameters. The electronic device first extracts the original signal value from the data frame based on the position and length parameters, and then converts the original value into a physical value according to the conversion method.

[0054] Figure 3 This is a schematic diagram of a DBC signal mapping to a diagnostic data object provided in an embodiment of this application. Figure 3 This illustrates the process of mapping signals from a DBC file to diagnostic data objects in the ODX layer: Signals in the DBC file are described by parameters such as start bit, bit length, byte order, factor, and offset. During mapping, the electronic device first normalizes the start bit according to the signal's byte order, mapping the normalized start bit to the position parameter of the diagnostic data object, and mapping the bit length to the length parameter. The position and length parameters together determine the bit range of the signal in the diagnostic data object. Next, the signal's byte order is mapped to the encoded byte order of the diagnostic data object, and the factor and offset are mapped to the conversion method of the diagnostic data object, allowing the diagnostic data object to convert the original value to a physical value according to this conversion method. Figure 3 As can be seen, the signal's bit-domain positioning information and numerical conversion information are mapped to the corresponding parameters of the diagnostic data object. The mapped diagnostic data object retains both the complete bit-domain of the signal and the conversion relationship consistent with the DBC file, thus enabling the reverse reconstruction of the original configuration of the signal.

[0055] In this embodiment, the factor and offset determine how the original value is converted into a physical value. This method maps the factor to a scaling factor and the offset to an offset amount, ensuring that the conversion relationship is consistent with the conversion relationship in the DBC file. The physical value remains unchanged before and after the conversion, and the same original value will not yield different physical quantities due to the conversion. The conversion and bit-domain positioning work together: first, the original value is extracted from the data frame based on the position and length parameters, and then it is converted into a physical value according to the conversion method. The two steps of value extraction and conversion are linked to each other, ensuring that the parsing result is consistent with the DBC file.

[0056] In one embodiment, before performing compliance verification on the ODX level after the mapping is established, the method further includes: Based on the framing rules of the transmission protocol followed by the network layer parameters in the DBC file, it is verified whether the diagnostic payload can be carried by the first frame and consecutive frames. The amount of data that each frame can carry is determined according to the number of bytes occupied by the protocol control information of that frame. If the diagnostic payload exceeds the amount of data that can be carried, it is determined that the parameters are invalid.

[0057] In applications, for messages marked as multi-frames, the diagnostic payload needs to be transmitted in two parts: a first frame and several consecutive frames. Before compliance verification, the electronic device checks whether the diagnostic payload can be carried by the first frame and consecutive frames, based on the framing rules of the transmission protocol followed by the network layer parameters in the DBC file. Specifically, each frame needs to occupy several bytes in the data field to carry protocol control information. The number of bytes of protocol control information occupied by the first frame and consecutive frames is different, so the amount of data that can be used to carry the diagnostic payload is also different. The electronic device determines the amount of data that a frame can carry based on the number of bytes occupied by the protocol control information in each frame, and then calculates the total amount of data that the first frame and all consecutive frames can carry. When the length of the diagnostic payload does not exceed the total amount of data that can be carried, the network layer parameters of the multi-frame message are deemed feasible; when the length of the diagnostic payload exceeds the total amount of data that can be carried, the parameters are deemed invalid, and an anomaly is marked and a log is output. Among these, the block size in the network layer parameters is used to constrain the number of consecutive frames in a single round, and the minimum interval time is used to constrain the transmission interval of consecutive frames. Both of these directly inherit the configuration of the DBC file.

[0058] Figure 4 This is a schematic diagram of a multi-frame bearer capability verification provided in an embodiment of this application. Figure 4 The process of verifying the carrying capacity of multi-frame messages is illustrated: For a message marked as multi-frame, its diagnostic payload needs to be allocated to the first frame and several consecutive frames according to the framing rules of the transmission protocol. Each frame needs to occupy several bytes in the data field to carry protocol control information, and the number of bytes of protocol control information occupied by the first frame and consecutive frames is not the same, so the number of bytes available to carry diagnostic data is also different. The electronic device determines the amount of data that a frame can carry based on the number of bytes occupied by the protocol control information in each frame, and calculates the total amount of data that the first frame and all consecutive frames can carry based on this. Then, the length of the diagnostic payload is compared with the total amount of data that can be carried. If the length of the diagnostic payload does not exceed the total amount of data that can be carried, it is considered feasible; otherwise, it is considered an invalid parameter. Figure 4 As can be seen, since the protocol control information overhead of the first frame and the subsequent frames are included separately, the resulting carrying capacity is consistent with the actual transmission capacity of multi-frame messages on the bus, thus enabling the interception of multi-frame configurations that cannot be transmitted before file output.

[0059] In this embodiment, multi-frame messages need to be transmitted in two parts: a first frame and several consecutive frames. Whether the transmission can be completed needs to be determined by calculation. This method calculates the available capacity based on framing rules and the actual number of protocol control information bytes occupied by each frame, and then determines whether the diagnostic payload can accommodate it. If it cannot accommodate the payload, it is determined that the parameters are illegal and the frame is blocked to avoid generating multi-frame configurations that cannot be transmitted. The key is that the protocol control information overhead of the first frame and the consecutive frames is not considered to be the same. They are different. The capacity obtained after separately accounting for them matches the actual capacity of multi-frame transmission, and only then can the verification conclusion be valid.

[0060] In one embodiment, the compliance verification of the ODX level after mapping includes: The integrity of the enumeration values ​​and parameters in the ODX level, as well as the consistency of the parameters before and after mapping, are verified. If the enumeration values ​​are compliant, the parameters are complete, and the parameters before and after mapping are consistent, the compliance verification is deemed to have passed.

[0061] In application, the electronic device performs three layers of verification on the mapped ODX layer: enumeration value verification, parameter integrity verification, and data consistency verification. In the enumeration value verification, the electronic device checks whether the encoded byte order, data type, and protocol identifier in the ODX layer are all enumeration values ​​allowed by the ODX standard; any non-compliant custom enumeration values ​​are rejected. In the parameter integrity verification, the electronic device checks whether the request and response channels exist in pairs, and whether each referenced diagnostic data object has non-empty position and length parameters, etc., core bit field parameters; any missing channels or empty core parameters result in a rejection. In the data consistency verification, the electronic device compares the bit field positions, data lengths, conversion relationships, communication addressing identifiers, and communication timing and network layer parameters in the ODX layer item by item with the corresponding original values ​​in the DBC file; any discrepancies result in a rejection. When the enumeration values ​​are compliant, the parameters are complete, and the parameters before and after mapping are consistent, the electronic device determines that the compliance verification has passed, and then assembles and outputs the ODX file.

[0062] Figure 5 This is a schematic diagram of a three-layer compliance verification process provided in one embodiment of this application. Figure 5This illustrates the process of performing three layers of verification sequentially on the mapped ODX layer: First, the electronic device performs enumeration value verification, checking whether the encoded byte order, data type, and protocol identifier are all enumerated values ​​allowed by the ODX standard. After this verification passes, parameter integrity verification is performed, checking whether request and response channels exist in pairs and whether all referenced diagnostic data objects have non-empty core bit field parameters. After this verification passes, data consistency verification is performed, comparing bit field positions, data lengths, conversion relationships, communication addressing identifiers, and communication timing and network layer parameters item by item with the corresponding original values ​​in the DBC file. These three layers of verification are progressively more stringent. If any layer fails, the electronic device marks an anomaly and outputs a log without generating a file; only when all three layers pass does the electronic device assemble and output the ODX file. Figure 5 As can be seen, the three-layer verification checks the ODX level from three aspects: enumeration compliance, parameter integrity, and data consistency. This ensures that cases with non-compliant enumeration, missing channels or core parameters, or deviations from the original DBC values ​​cannot be included in the final output ODX file.

[0063] In this embodiment, the three layers of verification each perform different verification duties: enumeration value verification checks whether the enumeration values, such as byte order, data type, and protocol identifier, are allowed by the ODX standard; parameter integrity verification checks whether request and response channels exist in pairs and whether the core bit field parameters of the referenced diagnostic data object are empty; and data consistency verification compares the bit field position, data length, conversion relationship, addressing identifier, communication timing, and network layer parameters item by item with the original DBC values. Only after all three verifications pass is the output file generated; if any verification fails, it is blocked. Therefore, cases of non-compliant enumerations, missing channels or core parameters, or inconsistencies with the DBC cannot enter the final file, and the output ODX not only passes the standard verification but also maintains consistency with the DBC file.

[0064] This application also provides an electronic device for performing the steps in the above-described method embodiment for generating ODX files from DBC files.

[0065] like Figure 6 As shown, the electronic device 200 provided in this application embodiment includes a memory 201, a processor 202, and a computer program 203 stored in the memory 201 and capable of running on the processor 202. When the processor 202 executes the computer program 203, it implements the steps in the above-described method embodiment for generating ODX files from DBC files.

[0066] In this embodiment, the memory is used to store the computer program and the DBC file, and the processor is used to run the computer program. The two communicate bidirectionally via a bus. During operation, the processor writes intermediate results back to the memory for temporary storage. After verification, the ODX file is output from the memory. The storage and processing work together to enable the entire method of generating an ODX file from a DBC file to be completed on a single electronic device.

[0067] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the above-described method embodiments.

[0068] This application provides a computer program product, including a computer program, which, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.

[0069] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0070] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating an ODX file from a DBC file, characterized in that, include: From the parameters parsed from the DBC file, select the diagnostic-related parameters and filter out the remaining parameters; The ODX layer is constructed according to the hierarchical structure of the ODX standard, and the communication timing parameters and network layer parameters in the DBC file are mapped to the communication parameter references mounted on the protocol layer in the ODX layer. Below the protocol layer, a mapping is established between the diagnostic-related parameters and the diagnostic data objects in the ODX layer, and the diagnostic data objects share the communication timing parameters and network layer parameters carried by the communication parameter references; Perform compliance verification on the ODX level after the mapping is established, and output the ODX file if the compliance verification passes.

2. The method according to claim 1, characterized in that, The process of selecting diagnostic-related parameters from the parameters parsed from the DBC file and filtering out the remaining parameters includes: Based on the configurable diagnostic whitelist, from the message objects, signal objects, custom attribute objects, and node objects obtained by parsing the DBC file, the diagnostic-related parameters that match the diagnostic whitelist are retained, and the parameters that do not match the diagnostic whitelist are filtered out.

3. The method according to claim 2, characterized in that, The diagnostic whitelist contains independent functional addressing identifiers and physical addressing identifiers, wherein the functional addressing identifier and the physical addressing identifier are different addresses; the filtering also includes: The message object carrying the functional addressing identifier and the message object carrying the physical addressing identifier are respectively retained as functional addressing parameters and physical addressing parameters.

4. The method according to claim 2, characterized in that, The screening also includes: Based on the length of the diagnostic payload and the transmission protocol followed by the network layer parameters in the DBC file, the message object is determined to be a single frame or multiple frames, and the corresponding frame type is marked for the message object.

5. The method according to claim 1, characterized in that, The step of mapping the communication timing parameters and network layer parameters in the DBC file to communication parameter references mounted at the protocol layer in the ODX layer includes: The communication parameter reference is mounted below the protocol layer, so that the diagnostic services below the protocol layer can share the communication timing parameters and the network layer parameters through the communication parameter reference.

6. The method according to claim 1, characterized in that, The diagnostic-related parameters include signals, and establishing the mapping of the diagnostic-related parameters to diagnostic data objects in the ODX level includes: Based on the byte order of the signal, the start bit of the signal is normalized, and the normalized start bit is mapped to the position parameter of the diagnostic data object.

7. The method according to claim 1, characterized in that, The diagnostic-related parameters include signals, and the step of establishing the mapping of the diagnostic-related parameters to diagnostic data objects in the ODX level further includes: The signal factors are mapped to scaling factors in the conversion method for the diagnostic data object, and the signal offset is mapped to an offset amount in the conversion method, so that the physical values ​​of the diagnostic data object are calculated according to... Sure; Where PhysValue is the physical value, RawValue is the original value, Scale is the scaling factor, and Offset is the offset.

8. The method according to claim 1, characterized in that, Before performing compliance verification on the ODX level after establishing the mapping, the process also includes: Based on the framing rules of the transmission protocol followed by the network layer parameters in the DBC file, verify whether the diagnostic payload can be carried by the first frame and consecutive frames; The amount of data that each frame can carry is determined according to the number of bytes occupied by the protocol control information of that frame. If the diagnostic payload exceeds the amount of data that can be carried, it is determined that the parameters are invalid.

9. The method according to claim 1, characterized in that, The compliance verification of the ODX level after the mapping is established includes: The integrity of the enumeration values ​​and parameters in the ODX level, as well as the consistency of the parameters before and after mapping, are verified. If the enumeration values ​​are compliant, the parameters are complete, and the parameters before and after mapping are consistent, the compliance verification is deemed to have passed.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.

Images