A standardized parsing method and system for multi-format ECU data

Abstract

The application discloses a kind of multi-format ECU data standardization analysis method and system, it is related to automobile electronic control technical field, method includes: parsing A2L file, the meta-information of ECU variable is extracted, the meta-information includes variable name, storage address, data type, conversion rule, physical unit, effective range and dimension information;Parsing HEX file, construct segmented continuous storage image, the storage image is formed by multiple continuous data segments, and each data segment contains segment start address and continuous byte array;The address and data type of variable are extracted by A2L analysis module, and the original data of the corresponding position in HEX file is read automatically, which replaces the traditional manual search mode, and the single-variable analysis time is shortened from minute level to millisecond level, and the address misplacement, byte sequence error and other problems of manual search are avoided.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control technology, specifically to a standardized parsing method and system for multi-format ECU data. Background Technology

[0002] In ECU calibration and software development, data exists in various engineering formats, mainly including: A2L (ASAMMCD-2MC, describing ECU parameter addresses, types, and conversion rules), HEX (IntelHEX, storing programming data), and DCM (calibration data container). Although existing ECU toolchains (such as INCA and MDA) can support reading and editing multiple formats such as A2L, HEX, and DCM, data standardization conversion between different format files, cross-project batch processing, and automatic inverse derivation of nonlinear conversion rules still heavily rely on manual operation and lack a unified automated parsing mechanism, resulting in the following problems: 1. Format conversion and parsing are highly dependent on experience and specialized tools, making them difficult to reuse across projects; 2. The nonlinear transformation function cannot be automatically inverted, resulting in a lack of direct correspondence between physical values ​​and stored values; 3. The lack of a unified parameter expression model means that subsequent verification or analysis steps require repeated parsing, resulting in low efficiency; 4. The parsing process is not traceable and cannot meet the functional safety (ISO26262) requirements for toolchain trustworthiness. Summary of the Invention

[0003] The purpose of this invention is to provide a standardized parsing method and system for multi-format ECU data to address the aforementioned shortcomings in the prior art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a standardized parsing method for multi-format ECU data, comprising the following steps: Parse the A2L file to extract the metadata of the ECU variables. The metadata includes the variable name, storage address, data type, conversion rule, physical unit, effective range, and dimension information. Parse the HEX file and construct a segmented contiguous storage image. The storage image consists of multiple contiguous data segments, each of which contains a segment start address and a contiguous byte array. Based on the variable storage address and data type parsed by A2L, the original data of the corresponding variable is read from the HEX segmented contiguous storage image; Based on the conversion rules parsed by A2L, the original data is converted into physical values; The physical values ​​are recombined according to the variable type to generate a standardized parametric model, where the scalar output is a single physical value, the curve output is an array of physical values ​​along the X-axis and the Y-axis, and the MAP output is an array of physical values ​​along the X-axis, the Y-axis, and the Z-matrix. Output the standardized parameter model.

[0005] Furthermore, the method also includes generating a parsing process traceability record, comprising the following steps: The traceability record is based on variables and includes the original A2L block content and start and end line numbers, A2L parsing status, data segment number where the variable address is located, byte offset of the variable in its data segment, original byte sequence read from the HEX storage image, complete parameters of the conversion rule, intermediate process records of the conversion calculation, valid range verification results, and timestamp of the completion of complete variable parsing. The corresponding traceability fields are added in real time to generate traceability records that are independently saved in JSON format and output together with the standardized parameter model.

[0006] Furthermore, the parsing of the A2L file specifically includes: The system scans A2L files line by line, initiating block content collection upon encountering the / begin keyword and ending collection upon encountering a matching / end keyword; The list of block content lines is passed to the built-in tokenizer based on regular expressions for tokenization of special characters in the string parameters in A2L. Based on the ASAMMCD-2MC open standard specification, at least one of the following structures, CHARACTERISTIC, AXIS_PTS, COMPU_METHOD, RECORD_LAYOUT and UNIT, is parsed and the corresponding parameters are extracted. A tolerant failure strategy is adopted to handle exceptions in a tiered manner, including: skipping the block when the block type is not supported and counting the number of occurrences; recording the error information and skipping the block when a single block is parsed incorrectly; skipping only the field and retaining other fields when a single field is parsed incorrectly; and terminating the parsing task and logging the exception when a file-level exception occurs.

[0007] Furthermore, the process of parsing the HEX file to construct a segmented contiguous storage image includes: The HEX file is scanned line by line. Each time a type 04 record is encountered, 2 bytes of the data field are extracted, shifted left by 16 bits, and the current base address is updated. When a type 00 record is encountered, the absolute address is calculated using the base address and the 16-bit offset address of the record, and the data bytes in the record are written to the corresponding position. Address holes in the ECU firmware address space where no type 00 record appears are not allocated storage, and the HEX file is parsed into several segments consisting of the absolute address of the segment start and a continuous byte array of the segment.

[0008] Furthermore, reading the raw data of the corresponding variable from the HEX segmented contiguous storage image includes: Based on the 32-bit absolute address of the variable, locate the corresponding data segment in the segmented contiguous storage image and calculate the offset within the segment; If the variable type is scalar, then a fixed number of bytes of raw data are read; If the variable type is curve, then read N × the number of bytes of data of the data type to form a one-dimensional original data array of length N; If the variable type is MAP, then the data is read in row-major order, X×Y×data type bytes, to form a two-dimensional original data matrix of Y rows × X columns; The read byte sequence is parsed into integer or floating-point values ​​according to little-endian byte order.

[0009] Furthermore, the process of converting the original data into physical values ​​according to the transformation rules parsed from A2L includes at least one of the following transformation types: Linear transformation is performed, and the physical value Y is calculated using the formula Y=a×X+b, where a and b are the slope coefficient and intercept coefficient extracted from A2L, and X is the original data; Polynomial transformation, using the formula Y=Σaᵢ×X 1 Calculate the physical value Y, where aᵢ is the coefficient array extracted from A2L; The table lookup and transformation utilizes the stored value axis and physical value axis defined in A2L to locate the interval of X through binary search and calculate the physical value Y using linear interpolation. No transformation is required; the original data X is directly output as the physical value Y.

[0010] Furthermore, it also includes a nonlinear transformation function inverse mechanism: The corresponding target stored value is calculated based on the target physical value, specifically including: The linear inverse solution is obtained by directly solving the inverse function X=(Yb) / a. The polynomial inverse solution is used to construct the zero-value equation and iteratively search for the zero point using the bisection method within the effective range defined by A2L until the search interval width is less than the preset precision threshold. The nearest integer value is then taken as the target storage value. The table is used to solve the problem by binary search in the physical value array to find the interval where the target value is located. After verifying the monotonicity of the physical value array, the target stored value is calculated by inverse linear interpolation. Piecewise linear inverse solution: First, locate the segmented intervals based on the target physical value, and then call the linear inverse solution formula for the corresponding interval; If the target physical value exceeds the domain of the transformation function, a warning log is recorded and the nearest boundary value is output as an approximate result without interrupting the overall process.

[0011] Furthermore, the generation of the standardized parameter model includes: Predefined unified parameter model structure; Using variable names as index keys, each variable corresponds to a structured record, which includes at least: variable name, variable type, 32-bit absolute address, data type, physical unit, lower / upper limit of valid range, conversion rule name and type, original value, physical value, X-axis physical value array and Y-axis physical value array; Iterate through all variables by variable name and fill the corresponding fields with the parsing results of each step; After the filling is completed, the physical values ​​are validated within the valid range. If they exceed the range, a validation flag is added to obtain the standardized parameter model. The standardized parameter model is then serialized and output in any of the following formats: JSON, XML, and Parquet.

[0012] A standardized parsing system for multi-format ECU data includes: The A2L parsing module is used to parse A2L files and extract variable names, storage addresses, data types, conversion rules, physical units, effective ranges, and dimension information. The HEX parsing module is used to parse HEX files to construct segmented contiguous storage images, and read the original data of corresponding variables from the storage images according to the addresses and data types parsed by A2L. It supports data reading of three variable types: scalar, curve, and MAP. The data conversion module is used to convert HEX raw data into physical values ​​according to the conversion rules parsed by A2L, and has a built-in inverse solution mechanism for nonlinear conversion functions; The standardized output module is used to reassemble physical values ​​according to variable type, generate and output standardized parameter models, where scalars output single physical values, curves output arrays of X-axis physical values ​​and arrays of Y-axis physical values, and MAP outputs arrays of X-axis physical values, arrays of Y-axis physical values ​​and Z-matrix physical values; it is also used to generate output analysis process traceability records.

[0013] Compared with existing technologies, the standardized parsing method and system for multi-format ECU data provided by this invention has the following advantages: (a) Implementing automated association and resolution between A2L and HEX This invention extracts the address and data type of variables through an A2L parsing module, automatically reading the original data from the corresponding location in the HEX file, replacing the traditional manual search method. The single-variable parsing time is reduced from minutes to milliseconds, and problems such as address misalignment and byte order errors encountered during manual searches are avoided.

[0014] (ii) Supports unified parsing and type-based combination of scalars, curves, and MAPs. This invention employs a unified processing flow for variables of three types: scalar, curve, and MAP. It automatically identifies the variable type, reads data in the corresponding format, converts physical values, and combines them for output. Engineers do not need to write different processing codes for different types; the axis information of curves and MAPs is automatically associated with the data matrix for output.

[0015] (iii) Output a standardized unified parameter model This invention converts all parsing results into a unified JSON / XML / Parquet format, containing complete variable metadata (name, physical value, unit, original value, conversion rule, valid range) as well as complete axis information and data matrix of the curve / MAP. Downstream systems (such as ECU data verification systems and calibration tools) can directly read these results without repeated parsing.

[0016] (iv) Built-in nonlinear transformation function inverse solution capability This invention incorporates a nonlinear transformation function inverse solution mechanism, supporting automatic inverse solution for various transformation types such as linear, polynomial, lookup table, and piecewise linear transformations. Engineers do not need to manually solve equations, thus avoiding errors caused by manual calculation.

[0017] (v) The analysis process is traceable This invention can completely record the parsing path of each variable: the standard parameters extracted from A2L, the original address and data read from HEX, and the application process of the conversion rules, meeting the functional safety (ISO26262) requirements for toolchain trustworthiness. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below.

[0019] Example embodiments will be described more fully below, but these example embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of this disclosure.

[0020] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0021] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0022] A standardized parsing method for multi-format ECU data includes the following steps: Step S1: Load the A2L file The user inputs an A2L file, which the system loads and parses. The A2L file is a "dictionary" of ECU parameters, defining the standards and parameters for all variables.

[0023] Step S2: Parse A2L and extract the criteria and parameters of the variables. The system is based on the ASAMMCD-2MC open standard specification (which defines the meaning and syntax of fields of various structures in A2L files), and has developed its own structure parsing algorithm. It scans A2L files line by line, identifies block types, extracts meta-information of the same structures in batches, and finally stores the parsing results in the form of structured data for subsequent modules to call. I. Basis for Analysis The parsing in this step consists of three parts: the ASAMMCD-2MC open standard, which defines nine core structures and their field meanings in the open specification document, forming the syntactic basis of A2L files; a self-developed structure parsing algorithm, with a built-in A2L-specific word segmenter implemented based on Python regular expressions to solve the problem of word segmentation when strings contain special characters in A2L; and a dataclass mapping, with nine built-in data classes that correspond one-to-one with the structures in the A2L standard, serving as memory containers for structure information.

[0024] II. Parameter Extraction Methods (with Examples) The following uses the CHARACTERISTIC block of the MAP type variable Variable_A in an A2L file as an example to illustrate the extraction process of each parameter: 2.1. Scan line by line, start block collection when encountering / begin, end when encountering a match / end → entire A2L segment → block content line list → block boundary identification; 2.2. Call the tokenizer to perform word segmentation on the block content → string → token list → string field processing; 2.3. Take the first non-empty token as the variable name → Variable_A"" → Variable_A → variable name; 2.4. Take the fourth token as the address, convert it from hexadecimal to decimal → 0x80100000 → 2147614720 → storage address; 2.5. Reference the RECORD_LAYOUT name, look up the table to get the number of bytes → RSM_Pa 2.6. Take the COMPU_METHOD name and map it to the conversion type enumeration → COMPU_METHOD_TORQUE → LINEAR → conversion rule; 2.7. Take the UNIT name and map it to the unit display field → NM → Nm → physical unit; 2.8. Take the two tokens lower_limit and upper_limit and convert them to floating-point numbers → -3276.8 3276.7 → -3276.8, 3276.7 → valid range; 2.9. Recursively parse the AXIS_DESCR sub-block → sub-block → AxisDescr object → X-axis points, X-axis range; 2.10. Process the second AXIS_DESCR sub-block in the same way → sub-block → AxisDescr object → Y-axis points, Y-axis range.

[0025] Encapsulation result: After extraction, all information is encapsulated and stored in a Characteristic object.

[0026] III. File Error Handling Methods During A2L file parsing, the system employs a fail-soft approach, handling four types of exceptions in a tiered manner to ensure that no single point of failure interrupts the parsing of the entire file. The first tier is for unsupported block types (current block only): if a block type not included in the `StructType` enumeration occurs, the block is skipped, and the occurrence count is recorded. The second tier is for single-block parsing errors (current block only): if there are insufficient parameters or type conversion failures, the error message is recorded, and the block is skipped. The third tier is for single-field parsing errors (current block only): if a specific parameter fails to parse, only that field is skipped, while other fields are retained. The fourth tier is for file-level exceptions (entire task): if there are path errors, insufficient permissions, or encoding errors, the parsing task is terminated, and the error is logged.

[0027] Step S3: Load the HEX file The user inputs a HEX file, and the system scans it line by line and parses it into a segmented continuous storage image.

[0028] The HEX file adopts the Intel HEX format, which is an ASCII-encoded text. Each line is a record, sequentially composed of a start identifier ":", a data byte count LL, a 16-bit offset address AAAA, a record type TT, data bytes DD...DD, and a checksum CC. The system focuses on processing the following two types of records: Type 04 record (Extended Linear Address Record): Extract 2 bytes from the record data field, shift them left by 16 bits, and update the current base address (BA). For example, if the record data is 0x8000, then BA=0x80000000. The BA is refreshed every time a Type 04 record is encountered, for the absolute address calculation of subsequent data records.

[0029] Type 00 record (Data Record): Calculate the 32-bit absolute address as BA | the 16-bit offset address of the record, and write the data bytes in the record to the corresponding positions.

[0030] Since there are unprogrammed address holes in the ECU firmware address space (i.e., address ranges with no corresponding Type 00 records in the HEX file), the system does not allocate storage for the holes, but parses the HEX file into a number of segments. Each segment consists of the segment start absolute address (seg_start) and the continuous byte array of this segment (seg_data), which together form the segmented continuous storage image for subsequent steps to query by address.

[0031] Step S4: Obtain raw data from the HEX according to A2L parsing parameters For each variable parsed in step S2, the system reads the corresponding raw data from the storage image of step S3 according to the following process: (1) Locate the data segment where the target address is located Each variable record in the A2L parsing result has a 32-bit absolute address. The system traverses the segment list constructed in step S3, finds the data segment that satisfies seg_start≤variable_address<seg_start+len(seg_data), and proceeds with subsequent operations after confirming that the variable address is valid; if the target address does not fall within any data segment (belonging to an address hole or an unprogrammed area), an exception log is recorded and this variable is skipped without interrupting the overall process.

[0032] (2) Calculate the intra-segment offset Subtract the start address of the affiliated data segment from the variable absolute address to obtain the offset of the variable in the byte array of this segment: offset=variable_address−seg_start.

[0033] (3) Read bytes according to the variable type  Scalar (VALUE): Determine the number of bytes based on the data type parsed in step S2 (e.g., SWORD corresponds to 2 bytes, ULONG corresponds to 4 bytes), and read byte_count bytes continuously from the offset position to form the original byte sequence.

[0034] Curve: A curve contains N axis points, each stored consecutively in the address space with the same data type. Starting from the offset position, N×byte_count bytes are read consecutively to form a one-dimensional array of raw values ​​of length N.

[0035] MAP (Two-dimensional graph): A MAP contains X×Y data points, which are stored consecutively in the address space in row-major order. Starting from the offset position, X×Y×byte_count bytes are read consecutively and parsed row by row to form a two-dimensional original value matrix of Y rows × X columns.

[0036] (4) Parse into numerical values ​​according to byte order The read byte sequence is parsed into integer or floating-point values ​​according to the byte order rules corresponding to the data types in A2L. This system is designed for ECU platforms using little-endian byte order, and the parsing rules for each data type are shown in the table below:

[0037] For curves and MAPs, each element in the byte sequence is parsed one by one according to the rules in the table above, and the original values ​​in the form of a one-dimensional array or a two-dimensional matrix are finally obtained for use in step S5 to convert physical values.

[0038] Step S5: Convert to physical value according to the conversion rules For each raw value (or each element in the array) read in step S4, the system calculates the corresponding physical value according to the conversion rules parsed in step S2: (a) Linear transformation (LINEAR) Formula: Y=a×X+b Symbol meaning: X: The original integer value (stored value) read in step S4 is obtained by parsing the HEX file in byte order and is dimensionless; a: Slope coefficient (floating-point number), extracted from the COEFF_LINEAR field of the COMPU_METHOD block in A2L, for example, 0.100000; b: Intercept coefficient (floating-point number), extracted from the COEFF_LINEAR field of the same block in A2L, for example -3276.800000; Y: The converted physical value, which has physical units defined in A2L (such as Nm, kPa, ℃).

[0039] Implementation logic: The system reads the COMPU_METHOD object associated with the variables from the parsing result of step S2, extracts the coefficients a and b from it, and substitutes the original value X obtained in step S4 into the formula to calculate Y. For curves and MAPs, each element in the array is substituted one by one for calculation.

[0040] Polynomial transformation Formula: Y = a0 + a1·X + a2·X² + ... + a n ·Xⁿ (where the exponent of X ranges from 0 to n (n≥1), and there are (n+1) coefficients in total).

[0041] Symbol meaning: X: The original integer value (stored value) read in step S4; a0: Coefficient of the constant term, corresponding to X 0 The coefficient of the term; a1: The coefficient of the linear term, corresponding to the coefficient of the X¹ term; a2: coefficient of the quadratic term, corresponding to the coefficient of the X² term; n: the highest degree of the polynomial; Y: The converted physical value.

[0042] Implementation logic: The system extracts the coefficient array [a0, a1, a2, ..., a] from the A2L parsing results. n For a given original value X, Y = Σaᵢ×X 1 The physical value Y is obtained by summing the terms (i from 0 to n). The system does not limit the highest degree of the polynomial, and the length of the coefficient array (i.e., n+1) is determined by the actual definition in the A2L file.

[0043] (ii) Polynomial Transformation Formula: Y = a0 + a1·X + a2·X² + ... + a n ·Xⁿ (where the exponent of X ranges from 0 to n (n≥1), and there are (n+1) coefficients in total).

[0044] Symbol meaning: X: The original integer value (stored value) read in step S4; a0: Coefficient of the constant term, corresponding to X 0 The coefficient of the term; a1: The coefficient of the linear term, corresponding to the coefficient of the X¹ term; a2: coefficient of the quadratic term, corresponding to the coefficient of the X² term; n: the highest degree of the polynomial; Y: The converted physical value.

[0045] Implementation logic: The system extracts the coefficient array [a0, a1, a2, ..., a] from the A2L parsing results. n For a given original value X, Y = Σaᵢ×X 1 The physical value Y is obtained by summing the terms (i from 0 to n). The system does not limit the highest degree of the polynomial, and the length of the coefficient array (i.e., n+1) is determined by the actual definition in the A2L file.

[0046] (iii) Table lookup and transformation (TABLE_LOOKUP) This system uses linear interpolation and supports both forward and reverse table lookup.

[0047] Symbol meaning: X: The original integer value (stored value) read in step S4; axis[i]: The original value axis array defined in A2L, with K discrete points, arranged in strictly ascending order; Column: axis[0] <axis[1]<…<axis[K-1]; value[i]: An array of physical values ​​defined in A2L, corresponding one-to-one with axis; K: Total number of discrete points in the table lookup.

[0048] Forward conversion implementation logic: The system extracts the `axis` array (storing the value axis) and `value` array (physical value axis) from the A2L parsing results. For a given raw value X, the following operations are performed: Boundary judgment: If X≤axis[0], return value[0] directly; if X≥axis[K-1], return value[K-1] directly.

[0049] Interval positioning: Binary search determines that X falls between axis[i] and axis[i+1] (i.e., axis[i]≤X≤axis[i+1]), and locates index i.

[0050] Linear interpolation calculation: Y=value[i]+(value[i+1]−value[i])×(X−axis[i]) / (axis[i+1]−axis[i]) Its meaning is: the linear proportion of X between axis[i] and axis[i+1], correspondingly linearly mapped to the range between value[i] and value[i+1].

[0051] For curves and MAPs, perform the above table lookup calculation for each element in the array one by one.

[0052] (iv) No conversion (NO_COMPU_METHOD) Formula: Y=X This means that the original value is directly output as the physical value. It is suitable for variables whose data type itself is a physical quantity that is directly stored.

[0053] Symbol meaning: X: The original integer value (stored value) read in step S4 is obtained by parsing the HEX file in byte order and is dimensionless; Y: The converted physical value, which is numerically the same as X.

[0054] Step S6: Reorganize according to variable type The system will recombine the converted data according to variable type: Scalar: Outputs a single numerical value directly. Curve: Output X-axis array + Y-axis array (physical values) MAP: Outputs an X-axis array, a Y-axis array, and a Z-matrix (physical values).

[0055] Step S7: Output the standardized parameter model The system fills the output with the analysis results of all variables according to the predefined unified parameter model structure.

[0056] Predefined parameter model structure This invention predefines a unified parameter model structure during the system initialization phase, serving as a standard container for the parsing results of all variables. The parameter model uses variable names as index keys, with each variable corresponding to a structured record containing the following fixed fields:

[0057] Filling implementation logic: The system iterates through all the variable names parsed in step S2 and performs the following operations in sequence: 1. Locate predefined records by variable name: Locate the corresponding structured record in the parametric model by using the variable name as the key.

[0058] 2. Field-by-field filling: Write the parsing results from each step S2 to S6 into the corresponding positions according to the field names. For records with variable types CURVE or MAP, fill the corresponding fields with the complete axis array (x_axis, y_axis) and data matrix (physical_value) output from step S6; for scalar records with variable type VALUE, leave the axis fields empty.

[0059] 3. Valid range verification: After filling, the system compares the physical value of each variable with lower_limit / upper_limit. If the physical value exceeds the valid range, a verification mark is added to the record, which does not affect the overall output.

[0060] 4. Serialization Output: After all variable records are filled in, the system serializes and outputs the complete parameter model in the specified format (JSON / XML / Parquet) for downstream systems (such as ECU data verification systems and calibration tools) to read directly without repeated parsing.

[0061] Step S8: Generate parsing process traceability record To meet the functional safety (ISO 26262) requirements for toolchain reliability, the system generates a complete traceability record of the parsing process while outputting the parameter model. The traceability record is stored on a variable-by-variable basis, completely preserving the end-to-end information of each variable from A2L parsing to physical value output, making the parsing process auditable, reproducible, and traceable.

[0062] Based on the parametric model, the traceability records are appended to each variable with the following traceability fields:

[0063] Implementation logic for traceability record generation During each step of the system's execution, variable names are written to the traceability field in real time, and finally output together with the parameter model. The specific implementation is as follows: 1. A2L Layer Traceability: After step S2 completes the parsing of each variable, the system records the start and end line numbers of the original block in the A2L file and the block text content, as well as the parsing status (success / field missing / skipped). If a variable is skipped due to a missing field, the reason for skipping is retained in the traceability record to ensure that the anomaly can be traced.

[0064] 2. HEX layer traceability: After step S4 completes the data reading of each variable, the system records the data segment number where the variable address is located, the byte offset within the segment, and the original byte sequence read from the HEX storage image (recorded in hexadecimal text format, such as 0x03E8), so that the original data can be independently verified.

[0065] 3. Transformation layer traceability: After step S5 completes the physical value transformation of each variable, the system records the transformation type used (LINEAR, POLYNOMIAL, TABLE_LOOKUP, NO_COMPU_METHOD), transformation parameters (coefficient values, axis arrays or lookup key-value pairs), and intermediate transformation calculation processes (such as the calculation results of polynomial terms), so that the derivation link between physical values ​​and original values ​​is completely preserved.

[0066] 4. Traceability Record Output Format: Traceability records are output as a separate parsing log file in JSON format (same name as the parameter model file, but different extension), arranged by variable name. Each record fully contains all traceability fields from the table above. Engineers or third-party auditing tools can read the traceability record file to step-by-step verify the parsing process of any variable.

[0067] Step S9: End Once the parsing task is complete, the system releases the memory resources occupied by the HEX storage image, disables the A2L parsing cache, and records the task completion status and completion timestamp to the runtime log.

[0068] A standardized parsing system for multi-format ECU data includes: A2L parsing module This system is used to parse A2L files and extract variable names, storage addresses, data types, conversion rules, physical units, effective ranges, and dimensional information, serving as the data entry point for this invention. The system is based on the ASAMMCD-2MC open standard specification and employs a self-developed structure parsing algorithm.

[0069] ① Parsing object The core structures defining ECU parameters in the A2L file include CHARACTERISTIC (MAP and curve variable definitions), AXIS_PTS (axis point data), COMPU_METHOD (conversion rules), RECORD_LAYOUT (data type definitions), UNIT (physical units), etc., all of which are fully parsed by the system.

[0070] ②Analysis process The system scans the A2L file line by line, initiating block content collection upon encountering the ` / begin` keyword and ending collection upon encountering a matching ` / end` keyword. The list of block content lines is then passed to the built-in tokenizer for processing. The tokenizer is implemented based on regular expressions and specifically addresses segmentation ambiguities caused by special symbols (such as quotation marks and commas) within string parameters in A2L files.

[0071] ③ Parameter extraction methods Taking the CHARACTERISTIC block as an example: take the first non-empty token as the variable name (e.g., Variable_A); take the fourth token and convert it from hexadecimal to decimal to obtain the storage address (e.g., 0x80100000→2147614720); refer to the RECORD_LAYOUT name to look up the table to obtain the data type and number of bytes; take the COMPU_METHOD name and map it to the conversion type enumeration (LINEAR / POLYNOMIAL / TABLE_LOOKUP / NO_COMPU_METHOD); take the UNIT name and map it to the physical unit display field; take lower_limit and upper_limit and convert them to floating-point numbers to obtain the valid range; recursively parse the AXIS_DESCR sub-block to obtain the number of axis points and axis range.

[0072] ④ Abnormal handling The system employs a failure-tolerant strategy, handling four types of exceptions in a tiered manner: When a block type is not supported, the block is skipped and its occurrence count is recorded; when a single block parsing error occurs, the error message is recorded and the block is skipped; when a single field parsing error occurs, only that field is skipped, while other fields are retained; and when a file-level exception (path error, encoding error) occurs, the parsing task is terminated and logged. Any single point of failure will not interrupt the parsing of the entire file.

[0073] ⑤ Output All parsing results are stored in memory as instances of structured data classes (Characteristic, CompuMethod, RecordLayout, etc.) for subsequent modules to call.

[0074] HEX parsing module It is used to parse HEX files to construct segmented contiguous storage images, and read the original data of corresponding variables from the storage images according to the addresses and data types parsed by A2L. It supports data reading of three variable types: scalar, curve and MAP.

[0075] ①HEX file parsed as segmented contiguous storage image The HEX file uses the IntelHEX format, with each line representing an ASCII-encoded record. The system scans line by line, extracting the 2 bytes of the data field from type 04 records to update the 32-bit base address (BA). For type 00 records, the system calculates the absolute address using BA|16-bit offset and writes it to the corresponding location. Because there are unburned address gaps in the ECU firmware address space, the system does not allocate storage for these gaps. Instead, it parses the HEX file into several segments, each containing the segment's starting absolute address and a contiguous array of bytes, forming a segmented contiguous storage image.

[0076] ② Retrieve raw data by address For each variable parsed by A2L, the system locates its corresponding data segment in the segment list based on its 32-bit absolute address, calculates the offset within the segment, and then reads bytes according to variable type: scalar variables read a fixed number of bytes; curve variables read N × the number of bytes of the data type to form a one-dimensional array of length N; MAP variables read X × Y × the number of bytes of the data type, forming a two-dimensional matrix of Y rows × X columns in row-major order. The read byte sequence is parsed into integer or floating-point values ​​according to little-endian byte order for use by the data conversion module.

[0077] ③ Exception handling If the variable address does not fall within any data segment (belonging to an address gap or unburned area), an exception log is recorded and the variable is skipped without interrupting the overall process.

[0078] Data conversion module It is used to convert HEX raw data into physical values ​​according to the conversion rules parsed by A2L, and has a built-in inverse solution mechanism for nonlinear conversion functions.

[0079] ① Positive conversion The system performs the conversion based on the conversion type defined in the COMPU_METHOD block of A2L: Linear transformation: Y = a × X + b. Extract the slope coefficient a and intercept coefficient b from A2L and substitute them into the original value X to calculate the physical value Y.

[0080] Polynomial transformation: Y = Σaᵢ × X 1 (i ranges from 0 to n), extract the coefficient array from A2L and calculate it by adding each item.

[0081] Table lookup and transformation: Perform a binary search on the discrete storage value axis and the physical value axis defined in A2L to locate the interval, and calculate the physical value using linear interpolation Y=value[i]+(value[i+1]−value[i])×(X−axis[i]) / (axis[i+1]−axis[i]).

[0082] No conversion: The physical value is directly equal to the original value, which is suitable for variables that are themselves stored as physical quantities.

[0083] For curves and MAPs, perform the above transformations one by one on each element of the array or matrix.

[0084] ② Inverse mechanism of nonlinear transformation function The inverse kinematics mechanism enables the system to automatically calculate the corresponding target stored value based on the target physical value: Linear inverse solution: Solve directly using the analytical inverse function X=(Y−b) / a.

[0085] Inverse polynomial solution: Construct the zero-valued equation f(X) = Σaᵢ·X 1With -Y_target=0, within the valid range defined by A2L, a binary search is used iteratively to search for the zero point until the search interval width is less than the preset accuracy threshold. The nearest integer value is then taken as the target storage value. After the search is completed, the result is substituted into the forward formula to verify the accuracy.

[0086] Inverse lookup solution: Use binary search in the physical value array to find the interval where the target value is located. After verifying the monotonicity of the physical value array, calculate the target stored value using inverse linear interpolation X=axis[i]+(axis[i+1]−axis[i])×(Y_target−value[i]) / (value[i+1]−value[i]).

[0087] Piecewise linear inverse solution: First, locate the segmented intervals using the target physical value, and then call the linear inverse solution formula for the corresponding interval.

[0088] ③ Exception handling If the target physical value exceeds the domain of the transformation function (e.g., exceeds the lookup table axis range or the polynomial inverse solution search interval), the system records a warning log and outputs the nearest boundary value as an approximate result without interrupting the overall process.

[0089] Standardized output module It is used to reassemble physical values ​​according to variable type, generate and output standardized parameter models, where scalars output single physical values, curves output arrays of X-axis physical values ​​and arrays of Y-axis physical values, and MAP outputs arrays of X-axis physical values, arrays of Y-axis physical values ​​and Z-matrix physical values; it is also used to generate output analysis process traceability records.

[0090] ① Predefined parameter model structure During the initialization phase, the system predefines a unified parameter model, using variable names as index keys. Each variable corresponds to a structured record containing fixed fields: variable name (name), variable type (VALUE / CURVE / MAP), 32-bit absolute address (address), data type (data_type), physical unit (unit), lower limit / upper limit of valid range (lower_limit / upper_limit), conversion rule name and type (compu_method), raw value (raw_value), physical value (physical_value), X-axis physical value array (x_axis, curves only / MAP), and Y-axis physical value array (y_axis, MAP only).

[0091] ② Filling logic The system iterates through all variable names parsed in step S2, locates the corresponding records in the parameter model by variable name, and writes the parsing results of each step field by field. For curves and MAPs, the complete axis array and data matrix output from step S6 are filled into the corresponding fields; for scalars, the axis fields are left empty. After filling, the physical values ​​are validated for their valid range; if they exceed the range, a validation flag is added but the output is not affected.

[0092] ③ Output format The parameter model is serialized and output in JSON / XML / Parquet formats. Simultaneously, a parsing process traceability record is generated and independently saved in JSON format, recording the A2L original block content and line number for each variable, the A2L parsing status, the HEX data segment number and offset within the segment, the original byte sequence (hexadecimal representation), the complete parameters of the transformation rule, the intermediate transformation calculation process, the valid range verification result, and the parsing completion timestamp. Downstream systems can directly read the parameter model without repeated parsing.

[0093] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above description is illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A standardized parsing method for multi-format ECU data, characterized in that, Includes the following steps: Parse the A2L file to extract the metadata of the ECU variables. The metadata includes the variable name, storage address, data type, conversion rule, physical unit, effective range, and dimension information. Parse the HEX file and construct a segmented contiguous storage image. The storage image consists of multiple contiguous data segments, each of which contains a segment start address and a contiguous byte array. Based on the variable storage address and data type parsed by A2L, the original data of the corresponding variable is read from the HEX segmented contiguous storage image; Based on the conversion rules parsed by A2L, the original data is converted into physical values; The physical values ​​are recombined according to the variable type to generate a standardized parametric model, where the scalar output is a single physical value, the curve output is an array of physical values ​​along the X-axis and the Y-axis, and the MAP output is an array of physical values ​​along the X-axis, the Y-axis, and the Z-matrix. Output the standardized parameter model.

2. The standardized parsing method for multi-format ECU data according to claim 1, characterized in that, The method also includes generating a parsing process traceability record, comprising the following steps: The traceability record is based on variables and includes the original A2L block content and start and end line numbers, A2L parsing status, data segment number where the variable address is located, byte offset of the variable in its data segment, original byte sequence read from the HEX storage image, complete parameters of the conversion rule, intermediate process records of the conversion calculation, valid range verification results, and timestamp of the completion of complete variable parsing. The corresponding traceability fields are added in real time to generate traceability records that are independently saved in JSON format and output together with the standardized parameter model.

3. The standardized parsing method for multi-format ECU data according to claim 1, characterized in that, The parsing of A2L files specifically includes: The system scans A2L files line by line, initiating block content collection upon encountering the / begin keyword and ending collection upon encountering a matching / end keyword; The list of block content lines is passed to the built-in tokenizer based on regular expressions for tokenization of special characters in the string parameters in A2L. Based on the ASAMMCD-2MC open standard specification, at least one of the following structures, CHARACTERISTIC, AXIS_PTS, COMPU_METHOD, RECORD_LAYOUT and UNIT, is parsed and the corresponding parameters are extracted. A tolerant failure strategy is adopted to handle exceptions in a tiered manner, including: skipping the block when the block type is not supported and counting the number of occurrences; recording the error information and skipping the block when a single block is parsed incorrectly; skipping only the field and retaining other fields when a single field is parsed incorrectly; and terminating the parsing task and logging the exception when a file-level exception occurs.

4. The standardized parsing method for multi-format ECU data according to claim 1, characterized in that, The process of parsing HEX files to construct a segmented contiguous storage image includes: The HEX file is scanned line by line. Each time a type 04 record is encountered, 2 bytes of the data field are extracted, shifted left by 16 bits, and the current base address is updated. When a type 00 record is encountered, the absolute address is calculated using the base address and the 16-bit offset address of the record, and the data bytes in the record are written to the corresponding position. Address holes in the ECU firmware address space where no type 00 record appears are not allocated storage, and the HEX file is parsed into several segments consisting of the absolute address of the segment start and a continuous byte array of the segment.

5. The standardized parsing method for multi-format ECU data according to claim 1, characterized in that, The process of reading the original data corresponding to the variables from the HEX segmented contiguous storage image includes: Based on the 32-bit absolute address of the variable, locate the corresponding data segment in the segmented contiguous storage image and calculate the offset within the segment; If the variable type is scalar, then a fixed number of bytes of raw data are read; If the variable type is curve, then read N × the number of bytes of data of the data type to form a one-dimensional original data array of length N; If the variable type is MAP, then the data is read in row-major order, X×Y×data type bytes, to form a two-dimensional original data matrix of Y rows × X columns; The read byte sequence is parsed into integer or floating-point values ​​according to little-endian byte order.

6. The standardized parsing method for multi-format ECU data according to claim 1, characterized in that, The process of converting the original data into physical values ​​based on the transformation rules parsed from A2L includes at least one of the following transformation types: Linear transformation is performed, and the physical value Y is calculated using the formula Y=a×X+b, where a and b are the slope coefficient and intercept coefficient extracted from A2L, and X is the original data; Polynomial transformation, using the formula Y=Σaᵢ×X 1 Calculate the physical value Y, where aᵢ is the coefficient array extracted from A2L; The table lookup and transformation utilizes the stored value axis and physical value axis defined in A2L to locate the interval of X through binary search and calculate the physical value Y using linear interpolation. No transformation is required; the original data X is directly output as the physical value Y.

7. The standardized parsing method for multi-format ECU data according to claim 6, characterized in that, It also includes a nonlinear transformation function inverse mechanism: The corresponding target stored value is calculated based on the target physical value, specifically including: The linear inverse solution is obtained by directly solving the inverse function X=(Yb) / a. The polynomial inverse solution is used to construct the zero-value equation and iteratively search for the zero point using the bisection method within the effective range defined by A2L until the search interval width is less than the preset precision threshold. The nearest integer value is then taken as the target storage value. The table is used to solve the problem by binary search in the physical value array to find the interval where the target value is located. After verifying the monotonicity of the physical value array, the target stored value is calculated by inverse linear interpolation. Piecewise linear inverse solution: First, locate the segmented intervals based on the target physical value, and then call the linear inverse solution formula for the corresponding interval; If the target physical value exceeds the domain of the transformation function, a warning log is recorded and the nearest boundary value is output as an approximate result without interrupting the overall process.

8. The standardized parsing method for multi-format ECU data according to claim 1, characterized in that, The generated standardized parameter model includes: Predefined unified parameter model structure; Using variable names as index keys, each variable corresponds to a structured record, which includes at least: variable name, variable type, 32-bit absolute address, data type, physical unit, lower / upper limit of valid range, conversion rule name and type, original value, physical value, X-axis physical value array and Y-axis physical value array; Iterate through all variables by variable name and fill the corresponding fields with the parsing results of each step; After the filling is completed, the physical values ​​are validated within the valid range. If they exceed the range, a validation flag is added to obtain the standardized parameter model. The standardized parameter model is then serialized and output in any of the following formats: JSON, XML, and Parquet.

9. A system for standardizing and parsing multi-format ECU data, used to execute the method for standardizing and parsing multi-format ECU data according to any one of claims 1-8, characterized in that, include: The A2L parsing module is used to parse A2L files and extract variable names, storage addresses, data types, conversion rules, physical units, effective ranges, and dimension information. The HEX parsing module is used to parse HEX files to construct segmented contiguous storage images, and read the original data of corresponding variables from the storage images according to the addresses and data types parsed by A2L. It supports data reading of three variable types: scalar, curve, and MAP. The data conversion module is used to convert HEX raw data into physical values ​​according to the conversion rules parsed by A2L, and has a built-in inverse solution mechanism for nonlinear conversion functions; The standardized output module is used to reassemble physical values ​​according to variable type, generate and output standardized parameter models, where scalars output single physical values, curves output arrays of X-axis physical values ​​and arrays of Y-axis physical values, and MAP outputs arrays of X-axis physical values, arrays of Y-axis physical values ​​and Z-matrix physical values; it is also used to generate output analysis process traceability records.

Images