An automated verification and repair method for data type definition tables oriented towards the SOME / IP protocol

Abstract

This application discloses an automated verification and repair method for data type definition tables for the SOME / IP protocol, relating to the field of vehicle system development. The method includes: S1, table reading and merging region parsing: reading the Excel data type definition table to be verified, parsing the topological relationship of merged cells in the table, identifying the merging region corresponding to each logical structure, and the starting and ending rows of the logical structure in the table; assigning all rows within the merging region to the corresponding logical structure; S2, structure member naming conflict verification and repair: traversing all member rows of each logical structure, collecting member names and performing uniqueness checks; if duplicate member names exist within the same logical structure, referring to the preset Member Position sequence number field in the table, uniquely renaming the duplicate member names with a sequence mark; also including synchronously recording the conflict location, original name, and new name of the renaming.

Description

Technical Field

[0001] This application relates to the field of vehicle system development, and in particular to an automated verification and repair method for data type definition tables for the SOME / IP protocol, an automated verification and repair system for data type definition tables for the SOME / IP protocol, electronic devices, storage media, and vehicle development platforms. Background Technology

[0002] In the current development of intelligent connected vehicle electronic and electrical architectures, SOME / IP (Scalable Service-Oriented Middleware over IP) is the mainstream in-vehicle service communication protocol. Its service interface relies on a strictly defined data type definition. This model is usually provided by controller vendors or software institutes in the form of an Excel spreadsheet, containing complex nested relationships such as structs, basic types, and arrays. It often uses merged cells to represent logical parent-child structures (such as a "RadarObject" struct containing multiple member fields).

[0003] However, in actual project integration, such Excel spreadsheets have the following serious problems:

[0004] 1. Manual maintenance is prone to errors: Data type names or member fields may be defined repeatedly (for example, the same signal may be defined twice in different locations), which is difficult to detect during manual review;

[0005] 2. Poor toolchain compatibility: Downstream code generation tools (such as DaVinci and vCDT) are sensitive to input formats. If there are duplicate or conflicting definitions, the generated protocol stack code may be misaligned with the message structure issued by the controller.

[0006] 3. Delayed problem exposure: Such errors are often only discovered during the actual vehicle testing phase, resulting in high investigation costs and long cycles.

[0007] Typical Case:

[0008] During the integration of a certain version of CSC, due to the upgrade of the protocol stack to OTS5_V1.2, the newly added radar signals were defined twice in the data type definition table. Since the matrix table is indexed by the model, the protocol stack could not automatically deduplicate, resulting in a mismatch between the radar messages sent by the controller and the protocol stack's parsing structure. This ultimately manifested as: when the vehicle encounters an obstacle while moving forward / reversing, the radar does not emit an alarm sound, and the instrument panel does not display a colored block, posing a serious functional safety risk. Although this issue was eventually addressed, it was severely delayed due to the actual release of the version; that is, it only became apparent during real-vehicle testing, causing project delays and rework.

[0009] In summary, existing technologies lack an automated, structure-aware, and vehicle-oriented data type definition table verification mechanism, which cannot effectively intercept such "semantic-level" model conflicts before integration. Summary of the Invention

[0010] The purpose of this invention is to provide an automated verification and repair method for data type definition tables for the SOME / IP protocol, an automated verification and repair system for data type definition tables for the SOME / IP protocol, an electronic device, a storage medium, and a vehicle development platform, thereby solving at least one of a number of technical problems.

[0011] In actual project integration, Excel spreadsheets have the following problems: manual maintenance is prone to errors, toolchain compatibility is poor, and problem exposure is delayed.

[0012] This invention provides the following solution:

[0013] According to a first aspect of the present invention, an automated verification and repair method for data type definition tables oriented towards the SOME / IP protocol is provided, comprising:

[0014] S1, Table reading and merged region parsing:

[0015] Read the Excel data type definition table to be verified, parse the topological relationship of merged cells in the table, identify the merged area corresponding to each logical structure, and the start and end rows of the logical structure in the table;

[0016] All rows within the merged area are assigned to the corresponding logical structure;

[0017] S2, Structure member naming conflict verification and repair:

[0018] Traverse all member rows of each logical structure, collect member names and perform uniqueness checks;

[0019] If there are duplicate member names in the same logical structure, the duplicate member names will be renamed with a serial number mark, referring to the pre-defined MemberPosition sequence number field in the table.

[0020] It also includes synchronously recording the conflict location, original name, and new name of the renaming;

[0021] S3, Unified handling of data type reference logic:

[0022] Extract reference information for each data type in the table;

[0023] A multi-source priority decision mechanism is adopted to standardize data type reference information, and all Boolean type related information is simultaneously standardized and mapped.

[0024] S4, Identification and Deletion of Duplicate Data Types:

[0025] Perform an operation on an Excel spreadsheet to unmerge all cells, so that each row explicitly carries the full data type name;

[0026] Iterate through all rows of the table, construct a set of known data type names, and compare the current data type name and its associated member field set with the known data types.

[0027] If the name already exists and the set of member fields is the same or highly similar, it is considered a duplicate definition;

[0028] Perform a block deletion operation on logical structures that are determined to be duplicated from the bottom of the table upwards;

[0029] S5, standard format output:

[0030] Generate a new Excel worksheet based on the verified and repaired table data;

[0031] The worksheet format is set to conform to the AUTOSAR toolchain input specification to ensure that it can be directly imported into downstream code generation tools for generating SOME / IP service interface code.

[0032] Furthermore, including:

[0033] In step S1, the logical structure includes complex nested data types composed of basic types and array types;

[0034] Merged cells are:

[0035] In Excel, merged cells are used to represent the parent-child relationship between data type names and subordinate member fields.

[0036] Furthermore, including:

[0037] In step S2, the rule for unique renaming is:

[0038] Add an underscore and the corresponding number of the Member Position after the repeated original member name;

[0039] The repair log is generated based on the relevant records of the renaming operation and output along with a standard format worksheet.

[0040] Furthermore, including:

[0041] In step S3, the priorities included in the multi-source priority decision-making mechanism, from high to low, are as follows:

[0042] The table can contain basic data types directly entered, custom member reference types, and types deduced from array element reference types.

[0043] Boolean type normalization mapping is as follows:

[0044] Map different Boolean type description texts to the AUTOSAR platform standard uint8 type.

[0045] Furthermore, including:

[0046] In step S4, the comparison dimensions of the member field set include member name, member data type, and member MemberPosition number;

[0047] The criterion for determining high similarity is: differences exist only in annotations and notes.

[0048] Furthermore, including:

[0049] In step S4, before performing the deletion operation, the original Excel spreadsheet and the duplicate data to be deleted are backed up.

[0050] Furthermore, including:

[0051] In step S5, the standard format conforming to the AUTOSAR toolchain input specification is as follows:

[0052] The table header uses the standard English field names: DatatypeName, Category, MemberName, DatatypeReference, and ArraySize.

[0053] This also includes re-performing the vertical cell merging operation for consecutive columns with the same DatatypeName;

[0054] It also includes adding borders to table data areas and setting column widths according to engineering specifications.

[0055] According to a second aspect of the present invention, an automated verification and repair system for data type definition tables oriented towards the SOME / IP protocol is provided, comprising:

[0056] Table parsing module: Used to read the Excel data type definition table to be verified, parse the topological relationship of merged cells in the table, identify the merged area of ​​each logical structure and the corresponding start and end rows, and realize the conversion of visual grouping into machine-recognizable logical units;

[0057] Naming conflict repair module: Communicates with the table parsing module to traverse the member rows of each logical structure, check the uniqueness of member names, rename duplicate member names with serial numbers by referring to the Member Position field, and record renaming related information.

[0058] Type Reference Unification Module: Communicates with the table parsing module to extract data type reference information, standardizes type references through a multi-source priority decision mechanism, and performs standardized mapping processing for Boolean types and non-standard basic types;

[0059] The duplicate definition deletion module communicates with the table parsing module and is used to remove all merged cells in the table, construct a set of known data type names, identify redundant duplicate definitions by comparing the data type name union member field set, and delete the entire logical structure of duplicate definitions from the bottom of the table upwards.

[0060] Standard format output module: It communicates with the naming conflict repair module, type reference unification module, and duplicate definition deletion module respectively, and is used to generate a new Excel worksheet that conforms to the AUTOSAR toolchain input specification based on the data after verification and repair;

[0061] Log generation module: It communicates with the naming conflict repair module, type reference unification module, and duplicate definition deletion module respectively. It is used to record the fault type, location, method and time of all repair operations, and generate and output the associated global repair log.

[0062] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0063] The memory stores a computer program that, when executed by a processor, causes the processor to perform steps such as automated verification and repair methods for data type definition tables oriented towards the SOME / IP protocol.

[0064] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs steps such as an automated verification and repair method for a data type definition table oriented towards the SOME / IP protocol.

[0065] According to a fifth aspect of the present invention, a vehicle development platform is provided, comprising:

[0066] Electronic devices for implementing automated verification and repair methods for data type definition tables oriented towards the SOME / IP protocol;

[0067] The processor runs programs, and when the programs are running, they execute steps such as automated verification and repair methods based on data type definition tables for the SOME / IP protocol, based on the data output from the electronic device.

[0068] Storage medium used to store programs that, when running, perform steps such as automated verification and repair of data types defined in tables oriented towards the SOME / IP protocol on data output from electronic devices.

[0069] The above solution achieves the following beneficial technical effects:

[0070] This application automatically identifies and fixes data model conflicts before code generation and version integration, avoiding abnormal vehicle functions and intercepting fatal defects in advance.

[0071] This application improves development efficiency by automating the process from manual Excel review, which originally required several person-days, to minutes.

[0072] This application improves compatibility with the AUTOSAR toolchain and enhances model robustness by renaming members to ensure uniqueness and standardizing Boolean types.

[0073] This application is implemented through scripting and can be used as a mandatory access control check item in version releases, supporting CI / CD integration.

[0074] This application records the location of conflicts and the actions taken to resolve them by outputting detailed logs, which facilitates quality auditing and provides strong traceability. Attached Figure Description

[0075] Figure 1 This is a flowchart of an automated verification and repair method for a data type definition table for the SOME / IP protocol, provided by one or more embodiments of the present invention.

[0076] Figure 2 This is a structural diagram of an automated verification and repair system for data type definition tables oriented towards the SOME / IP protocol, provided by one or more embodiments of the present invention.

[0077] Figure 3 This is a block diagram of an electronic device structure for an automated verification and repair method of data type definition tables for the SOME / IP protocol, provided by one or more embodiments of the present invention. Detailed Implementation

[0078] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0079] Figure 1 This is a flowchart of an automatic code generation method for SOME / IP data types provided by one or more embodiments of the present invention.

[0080] like Figure 1 The automated verification and repair method for data type definition tables for the SOME / IP protocol, as shown, is applied to the development scenario of SOME / IP in-vehicle service communication protocols for intelligent connected vehicles. It processes SOME / IP data type definition tables maintained in Excel spreadsheet format, containing merged cells representing logical parent-child structures, including:

[0081] S1, Table reading and merged region parsing:

[0082] Read the Excel data type definition table to be verified, parse the topological relationship of merged cells in the table, identify the merged area corresponding to each logical structure, and determine the start and end rows of each logical structure in the table;

[0083] All rows within the merged area are assigned to the corresponding logical structure, thus realizing the transformation of visual table grouping into machine-recognizable logical units;

[0084] S2, Structure member naming conflict verification and repair:

[0085] Traverse all member rows of each logical structure, collect member names and perform uniqueness checks;

[0086] If duplicate member names are found within the same logical structure, refer to the MemberPosition sequence number field in the table to uniquely rename the duplicate member names with a sequence number.

[0087] It also includes synchronously recording the conflict location, original name, and new name of the renaming;

[0088] S3, Unified handling of data type reference logic:

[0089] Extract reference information for each data type in the table;

[0090] A multi-source priority decision mechanism is adopted to standardize data type references, and all descriptive texts related to Boolean types are simultaneously standardized and mapped.

[0091] S4, Identification and Deletion of Duplicate Data Types:

[0092] Perform an operation to unmerge all cells in an Excel spreadsheet, so that each row explicitly carries the full data type name;

[0093] Iterate through all rows of the table, construct a set of known data type names, and compare the current data type name and its associated member field set with the known types;

[0094] If the name already exists and the set of member fields is the same or highly similar, it is considered a redundant and duplicate definition;

[0095] Perform a block deletion operation on logical structures that are determined to be duplicated from the bottom of the table upwards to avoid accidental deletion caused by changes in row numbers;

[0096] S5, standard format output:

[0097] Generate a new Excel worksheet based on the verified and repaired table data;

[0098] The worksheet format is set to conform to the AUTOSAR toolchain input specification to ensure that it can be directly imported into downstream code generation tools for generating SOME / IP service interface code.

[0099] In step S1 of this embodiment, the logical structure includes a complex nested data type composed of basic types and array types;

[0100] Merged cells are:

[0101] In Excel, merged cells are used to represent the parent-child relationship between data type names and subordinate member fields.

[0102] In step S2 of this embodiment, the rule for unique renaming is as follows:

[0103] Add an underscore and the corresponding number of the Member Position after the duplicate original member name, and the relevant records of the renaming operation are formed into a repair log, which is output together with the final generated standard format worksheet.

[0104] In step S3 of this embodiment, the priorities of the multi-source priority decision-making mechanism, from high to low, are as follows:

[0105] The table can contain basic data types directly entered, custom member reference types, and types deduced from array element reference types.

[0106] Boolean type normalization mapping is as follows:

[0107] The description texts of different Boolean types such as bool, boolean, and Bool are uniformly mapped to the uint8 type of the AUTOSAR platform standard.

[0108] In step S4 of this embodiment, the comparison dimensions of the member field set include member name, member data type, and member position number;

[0109] The criteria for determining high similarity are: the core comparison dimensions of the member field sets are completely identical, and only non-core information such as comments and remarks differs.

[0110] In step S4 of this embodiment, before performing the deletion operation, the original Excel spreadsheet and the duplicate definition data to be deleted are backed up to retain the original basis for data traceability.

[0111] In step S5 of this embodiment, the standard format conforming to the AUTOSAR toolchain input specification is specifically as follows:

[0112] The table header uses the standard English field names: DatatypeName, Category, MemberName, DatatypeReference, and ArraySize.

[0113] For consecutive columns with the same DatatypeName, re-execute the vertical cell merge operation;

[0114] Add borders to the table data area and set the column widths according to engineering specifications.

[0115] In this embodiment, it includes:

[0116] Downstream code generation tools include DaVinci and vCDT. The generated Excel worksheets do not require manual adjustments and can be directly imported into the tools to complete the generation of SOME / IP protocol stack code.

[0117] This embodiment also includes a global repair log generation step. After each repair operation in steps S2 to S4 is completed, the fault type, fault location, repair method, and repair time are recorded in real time. The final generated global repair log is in text format and is output in association with a standard format Excel worksheet. The log content supports quality auditing and problem tracing.

[0118] This embodiment supports the verification and repair of multi-layer nested logical structures. When parsing the merged region in step S1, the nested sub-structures are identified hierarchically to form a structure hierarchy table.

[0119] Steps S2 to S4 are performed sequentially from the innermost substructure to the outermost main structure, according to the structure hierarchy table, to resolve naming conflicts, unify type references, and delete duplicate definitions.

[0120] In this embodiment, the implementation is scripted and can be integrated into the CI / CD process of intelligent connected vehicle development as a mandatory access control check item before the release of the SOME / IP protocol version, thereby achieving automated verification and interception of version release.

[0121] In step S3 of this embodiment, the standardization process for non-standard basic data types is also included, which converts the vendor-defined non-standard basic type descriptions such as INT16, UINT32, and float into the AUTOSAR platform specification's basic data type representation with suffixes.

[0122] Figure 2 This is a structural diagram of an automated verification and repair system for data type definition tables oriented towards the SOME / IP protocol, provided by one or more embodiments of the present invention.

[0123] like Figure 2 The automated verification and repair system for data type definitions for the SOME / IP protocol, as shown, is applied to the development scenario of the SOME / IP in-vehicle service communication protocol for intelligent connected vehicles, including:

[0124] Table parsing module: Used to read the Excel data type definition table to be verified, parse the topological relationship of merged cells in the table, identify the merged area of ​​each logical structure and the corresponding start and end rows, and realize the conversion of visual grouping into machine-recognizable logical units;

[0125] Naming conflict repair module: Communicates with the table parsing module to traverse the member rows of each logical structure, check the uniqueness of member names, rename duplicate member names with serial numbers by referring to the Member Position field, and record renaming related information.

[0126] Type Reference Unification Module: Communicates with the table parsing module to extract data type reference information, standardizes type references through a multi-source priority decision mechanism, and performs standardized mapping processing for Boolean types and non-standard basic types;

[0127] Duplicate Definition Deletion Module: Communicates with the table parsing module to remove all merged cells in the table, construct a set of known data type names, identify redundant duplicate definitions by comparing data type names and member field sets, and delete the entire logical structure of duplicate definitions from the bottom of the table upwards;

[0128] Standard format output module: It communicates with the naming conflict repair module, type reference unification module, and duplicate definition deletion module respectively, and is used to generate a new Excel worksheet that conforms to the AUTOSAR toolchain input specification based on the data after verification and repair;

[0129] Log generation module: It communicates with the naming conflict repair module, type reference unification module, and duplicate definition deletion module respectively. It is used to record the fault type, location, method and time of all repair operations, and generate and output the associated global repair log.

[0130] In this embodiment, the duplicate definition deletion module further includes a data backup unit, which is used to back up and store the original Excel spreadsheet and the duplicate definition data to be deleted before performing the deletion operation.

[0131] In this embodiment, the table parsing module also includes a hierarchy recognition unit, which is used to identify the hierarchy relationship of multi-layer nested logical structures, generate a hierarchy relationship table of structures, and provide a hierarchy traversal basis for subsequent verification and repair steps.

[0132] In this embodiment, a CI / CD integration module is also included, which is communicatively connected to the standard format output module. The CI / CD integration module provides a standardized script calling interface, enabling the system to be integrated as a mandatory access control check item into the CI / CD automation process developed for intelligent connected vehicles.

[0133] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0134] In one specific embodiment, an automated verification and repair strategy for data type definition tables of the SOME / IP protocol is disclosed. This strategy aims to solve the technical problem of SOME / IP protocol stack parsing misalignment caused by issues such as duplicate definitions, member naming conflicts, and ambiguous type references in the data type definition table, which in turn lead to the failure of in-vehicle functions (such as radar alarms and instrument displays). This embodiment specifically includes:

[0135] 1. Restore the logical structure in the table

[0136] In engineering practice, complex data types (such as a "radar target list") typically consist of multiple member fields (such as target ID, distance, speed, status, etc.). For ease of reading, this type of structure is often presented in Excel using a "merged cells" format: the data type name is displayed only in the first row, with several rows below listing each member field, and the corresponding "data type name" column for these rows is blank (because they are merged).

[0137] This method first parses the merged area topology in Excel, identifying the start and end rows of each logical structure. For example, if "A5:A8" is a merged area containing "RadarObjectList", the system will consider rows 5 to 8 as the entire definition range of this structure, even if column A in rows 6–8 is empty, it will automatically be included under "RadarObjectList".

[0138] Technical significance: This step transforms "visual grouping" into "machine-recognizable logical units," providing a structural foundation for subsequent member management and deduplication.

[0139] II. Resolving member naming conflicts within a structure

[0140] Within a structure, all member field names must be unique; otherwise, it will lead to variable name conflicts or serialization misalignments during code generation. However, in manually maintained tables, copying and pasting or version merging often results in fields with the same name (such as two "status" fields).

[0141] The strategy in this embodiment includes traversing all member rows of each structure and collecting their "member names". If duplicates are found, the "Member Position" field is further referenced—this field is usually numbered sequentially by the supplier (e.g., 1, 2, 3…) to identify the field's order in the message. Based on this, the system performs a unique, numbered renaming of the duplicate names, for example, changing the second "status" to "status_2".

[0142] Meanwhile, the system records such modifications and outputs logs for engineers to review. This ensures both the correctness of the model and maintains traceability.

[0143] Technical value: Avoiding underlying memory layout errors caused by field name conflicts, a classic problem that existed in the CAN / LIN era, and the risk is even higher in the complex nested structure of SOME / IP.

[0144] III. Unified Data Type Reference Logic

[0145] Different suppliers may describe the same data type in different ways:

[0146] Some directly fill in the basic type (such as uint16); some reference a custom type (such as VehicleSpeedType); and some fill in the "array element type" in the array scenario.

[0147] In addition, the Boolean type has multiple notations such as bool, boolean, and Bool, while most AUTOSAR platforms require the uniform representation of uint8.

[0148] Accordingly, this embodiment also discloses a multi-source priority decision mechanism: "basic data type" is preferred (because it is the most direct in data retrieval); if not, "member reference type" is used; if still not, it is attempted to derive from "array element reference type"; at the same time, Boolean keywords are standardized and mapped (bool / boolean → uint8).

[0149] Engineering significance: It ensures compatibility with the delivery habits of different vendors, while forcing the output to conform to the specification type required by the target platform (such as QNX + SOME / IP stack), thus eliminating deserialization failures caused by type ambiguity.

[0150] IV. Accurately identify and delete duplicate data type definitions (the core innovation of this application)

[0151] This step is the most critical part of this application, directly addressing the root cause of the failure in the project mentioned in the technical background.

[0152] When the same data type (such as RadarObjectList) is fully defined twice in a table, traditional tools only perform string matching and may not be able to determine whether it is "semantically duplicated"; while manual review is very easy to miss, especially when the two definitions are distributed in different areas of the table.

[0153] This method employs a structure-aware deduplication strategy:

[0154] First, unmerge all cells to ensure each row explicitly carries the complete "data type name". Then, iterate through all rows to build a set of "seen type names". If a name is found to already exist and its member field set is the same as (or highly similar to) the previous one, it is considered a redundant definition. Delete all rows with the duplicate structure (instead of deleting only one row) to ensure model integrity. Delete operations from the bottom of the table upwards to avoid accidental deletion due to row number changes.

[0155] This application achieves the following technical effect: As the provided problem report shows, the duplicate definition of RadarObjectList caused the protocol stack to generate two sets of parsing logic, while the controller only sent messages according to one format, resulting in "misaligned parsing". This application eliminates this misalignment by deduplicating at the structural level, ensuring that each type exists only once in the final model.

[0156] V. Output in a standard format that conforms to the requirements of the AUTOSAR toolchain.

[0157] After the above steps are completed, the system will generate a new Excel worksheet (e.g., named "DataTypes"), whose format strictly follows industry-standard specifications.

[0158] The table header uses standard English field names (such as DatatypeName, Category, MemberName, DatatypeReference, ArraySize); consecutive identical DatatypeName cells are merged again to maintain readability; borders are added to the entire data area and column widths are set to improve the quality of project delivery.

[0159] The output can be directly imported into tools such as DaVinci and vCDT to generate SOME / IP service interface code without the need for manual secondary adjustments.

[0160] In another specific embodiment, it is disclosed that preventative measures are taken in advance based on potential risks during the project implementation process.

[0161] 1. There is a strong dependence on the original Excel format, and there is no mechanism for formatting error tolerance and exception checking.

[0162] This application currently uses the default Excel original table format specification (such as merged cells only used to represent parent-child relationships in a structure, complete header fields, and valid Member / Position fields), without mentioning any formatting error tolerance or exception checking mechanism. If the following situations occur, the solution will directly fail to parse or fix the error:

[0163] For example, improper use of merged cells: such as non-structured rows being incorrectly merged, merged cells of structured cells being broken, and cross-column merging causing confusion in structure recognition;

[0164] Missing / Incorrect Core Fields: For example, missing core fields such as DatatypeName, Member Position, and DatatypeReference, or duplicate, skipped, or non-numeric numbers in the Member Position field;

[0165] Inconsistent header format: For example, the header field names of tables delivered by different suppliers are inconsistent (e.g., "Member Name" is written as "Field Name"), which makes it impossible for the system to recognize the core data.

[0166] Based on the aforementioned risks, a format-related fault tolerance and anomaly verification mechanism is set up.

[0167] 2. The criteria for judgment of duplicate definitions are singular, which easily leads to missed judgments / false judgments.

[0168] Currently, this application determines duplicate definitions by using "data type name + member field set". However, in actual engineering, the "semantic repetition / difference" of data type definitions presents more complex scenarios, and a single judgment criterion is prone to causing problems.

[0169] Missed detection: If two data types have different names but completely identical member field sets and semantics (e.g., "RadarObjectList" and "RadarTargetList" are actually the same type), the system cannot recognize them as semantic duplicates, which will still lead to definition redundancy;

[0170] Misjudgment: If two data types have the same name, but their member fields have minor differences (such as different comments, different member order, or different field precision), but their semantics are different, the system may misjudge them as duplicates and delete the entire block, resulting in the loss of a valid definition;

[0171] The lack of a clear threshold for determining "high similarity" of member fields, such as what similarity rate is required to classify a duplicate, and the absence of quantitative standards, can easily lead to inconsistent system judgments.

[0172] Based on the aforementioned risks, judgment criteria are set for more specific scenarios to increase redundancy against missed or false judgments.

[0173] 3. The strategy for resolving naming conflicts is fixed and singular, with insufficient alternatives.

[0174] The only strategy for resolving member naming conflicts in this application is to rename members by adding a sequence number to the Member Position field. However, this strategy is highly dependent on the validity of this field. The fix will fail if the following conditions occur:

[0175] Member Position field missing / incorrect: If the supplier has not filled in this field, the number is duplicated, or the number is skipped, the system cannot add the serial number in sequence, resulting in renaming failure;

[0176] Naming conflicts in multi-level nested structures are not considered: if the inner members of a nested structure have the same name as the members of the outer structure, the system only resolves conflicts within a single level of the structure and cannot identify cross-level naming conflicts, which may lead to duplicate variable names in subsequent code generation.

[0177] Based on the aforementioned risks, a pre-standardization procedure for supplier information was developed, and the information was filtered before being incorporated into this application.

[0178] 4. The precedence mechanism for data type references has no room for customization, resulting in limited adaptability.

[0179] This application designs a fixed priority for "basic data types → member reference types → array element reference types," but in actual engineering, different companies / projects / suppliers may have different type referencing specifications.

[0180] Some projects may prioritize using "custom reference types" rather than basic data types to ensure consistency in type definitions;

[0181] In the definition tables delivered by some suppliers, "array element reference type" is the core type, and basic data types are only supplementary.

[0182] A fixed priority mechanism cannot adapt to these personalized needs, which may lead to conflicts between the unified type references in the system and the project specifications, requiring manual adjustments.

[0183] Based on the aforementioned risks, personalized needs are identified and then separated, and then guided to be processed in other solutions, or translated into rules compatible with the rules of this application.

[0184] 5. The parsing and validation of multi-layered nested / complex structures are not clearly defined, resulting in parsing vulnerabilities.

[0185] This application mentions support for complex nested structures, but it does not explicitly address the parsing and validation capabilities for complex scenarios such as multi-level nesting and nested arrays / enumerations of structures, thus presenting potential parsing vulnerabilities.

[0186] If there are three or more nested structures (such as structure A containing structure B, and structure B containing structure C), it is unclear in the documentation whether the system can perform deep traversal to identify internal naming conflicts / duplicate definitions of structures B and C.

[0187] If the members of a struct are arrays / enumerations, and these arrays / enumerations have duplicate definitions / naming conflicts, it is unclear in the documentation whether the system can perform correlation checks.

[0188] The handling of empty structures and excessively long structures is not considered. If such edge scenarios occur, the system may fail to parse or generate invalid definitions.

[0189] Based on the aforementioned risks, the data processing objects are pre-defined, and a nesting level identification mechanism is set. Only after the nesting level meets the preset level requirement is the data imported into the solution of this application for processing.

[0190] 6. The repair operation lacks reversibility and has no backup or rollback mechanism.

[0191] The solution uses a "delete entire block" strategy to repair duplicate definitions and a "rename directly" strategy to handle naming conflicts, but it does not include any backup, rollback, or manual review mechanisms.

[0192] After the system deletes duplicate definitions, there is no backup of the original data. If a valid definition is mistakenly deleted, engineers cannot quickly restore the original data and can only re-import the original table, which affects development efficiency.

[0193] After the repair is completed, the system only outputs logs and does not have a manual review and confirmation process. If the repair is incorrect, the error definition table will directly enter the subsequent process, which may cause new problems.

[0194] Based on the aforementioned risks, a dedicated storage space is allocated to record modification logs, and the logs are invoked to complete the rollback mechanism.

[0195] 7. The validation requirements for multiple tables across files were not considered, resulting in global definition conflicts.

[0196] The current solution only verifies and repairs a single Excel file. However, in real-world automotive development projects, data type definition tables may be delivered by multiple suppliers and split into multiple Excel files (e.g., one for radar, one for cameras, and one for body control). Therefore, the current solution has significant limitations.

[0197] The inability to identify duplicate definitions / naming conflicts across files (such as the presence of the "ObjectList" data type in both the radar definition table and the camera definition table) leads to global definition redundancy, which may still cause protocol stack parsing problems.

[0198] It lacks the ability to batch process and merge multiple tables for validation. If there are dozens of definition tables in a project, engineers need to import and process them one by one, which greatly reduces efficiency.

[0199] Based on the aforementioned risks, a batch processing program was developed to first convert the data into a unified Excel format to avoid global definition conflicts, and then process it through this application.

[0200] 8. Incomplete coverage of non-standard data types and limited standardization capabilities.

[0201] The proposed solution only mentions standardizing common boolean types such as bool / boolean / Bool. However, in actual engineering projects, the definition tables delivered by vendors may contain many more non-standard data types, limiting the system's standardization capabilities.

[0202] Non-standard Boolean types: such as BOOL, BOOLEAN and other less common syntaxes, which the system may not be able to recognize, causing type standardization to fail;

[0203] Non-standard base types: such as vendor-defined "INT16", "UINT32" (uppercase), "float" (lowercase) do not match the platform requirements "int16_t", "uint32_t", "qs_float32_t", and the system does not specify whether full mapping can be achieved;

[0204] Custom composite types: If a supplier introduces a custom composite type, the system may skip it if it cannot recognize it, leading to ambiguity in type references.

[0205] Based on the aforementioned risks, a data type database is introduced to enhance the identification and coverage capabilities of non-standard data types.

[0206] 9. Insufficient customization capabilities for output formats, unable to adapt to the personalized needs of enterprises.

[0207] The solution only outputs the industry-standard AUTOSAR toolchain format. However, in actual projects, some companies have custom toolchain input formats (such as custom header fields, special cell formats, and additional notes columns), and the solution's output capabilities cannot adapt to these.

[0208] There is no custom configuration entry for output format, so engineers cannot adjust the format of table headers, column widths, borders, etc. according to enterprise specifications;

[0209] The compatibility with the company's self-developed toolchain has not been considered. If the project uses the self-developed SOME / IP code generation tool, the output standard format may not be directly imported and manual adjustment is required.

[0210] Based on the aforementioned risks, a separate compatibility module was developed for custom toolchain input formats.

[0211] 10. Performance optimization for large data volume scenarios is not mentioned, which may lead to a decrease in processing efficiency.

[0212] The proposal suggests reducing manual review to minutes, but it doesn't mention performance optimization strategies for large Excel spreadsheets.

[0213] If the Excel definition table contains thousands of rows of data and a large number of multi-level nested structures, the system's parsing, traversal, deduplication, and validation operations may take longer and cannot maintain a processing efficiency of minutes.

[0214] Without optimization mechanisms such as block processing and parallel processing, system lag and parsing timeouts may occur in scenarios with large amounts of data.

[0215] Based on the aforementioned risks, contingency plans have been developed to optimize Excel spreadsheets for handling large datasets.

[0216] Figure 3 This is a block diagram of an electronic device structure for an automated verification and repair method of data type definition tables for the SOME / IP protocol, provided by one or more embodiments of the present invention.

[0217] like Figure 3 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0218] The memory stores a computer program that, when executed by a processor, causes the processor to perform steps of an automated verification and repair method for a data type definition table oriented towards the SOME / IP protocol.

[0219] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of an automated verification and repair method for data type definition tables oriented towards the SOME / IP protocol.

[0220] This application also provides a vehicle development platform, including:

[0221] Electronic devices, for implementing automated verification and repair methods for data type definition tables oriented towards the SOME / IP protocol;

[0222] The processor runs a program, and when the program runs, it executes the steps of an automated verification and repair method based on the data type definition table of the SOME / IP protocol from the data output by the electronic device.

[0223] Storage medium used to store programs that, when running, execute automated verification and repair methods based on data type definition tables oriented towards the SOME / IP protocol for data output from electronic devices.

[0224] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0225] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0226] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0227] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0228] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0229] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0230] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0231] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0232] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0233] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automated verification and repair of data type definition tables for the SOME / IP protocol, characterized in that, The automated verification and repair method for the data type definition table for the SOME / IP protocol includes: S1, Table reading and merged region parsing: Read the definition table to be verified, parse the topological relationship of the merged cells in the table, identify the merged area corresponding to each logical structure, and the start and end rows of the logical structure in the table; All rows within the merged area are assigned to the corresponding logical structure; S2, Structure member naming conflict verification and repair: Traverse the member rows of each logical structure, collect member names and perform uniqueness checks; If duplicate member names exist, refer to the number field in the table to uniquely rename the duplicate member names; S3, Unified handling of data type reference logic: Extract reference information for each data type in the table; Standardize data type reference information and simultaneously perform standardized mapping processing on all Boolean type related information; S4, Identification and Deletion of Duplicate Data Types: Perform an operation to unmerge all cells in the table, so that each row explicitly carries the full data type name; Iterate through all rows of the table, construct a set of known data type names, and compare the current data type name and its associated member field set with the known data types. If the name already exists and the set of member fields is the same or highly similar, it is considered a duplicate definition; Perform a block deletion operation on duplicate logical structures from the bottom up of the table; S5, standard format output: A new worksheet is generated based on the validated and repaired table data.

2. The automated verification and repair method for data type definition tables for the SOME / IP protocol according to claim 1, characterized in that, include: In step S1, the logical structure includes a complex nested data type composed of basic types and array types; The merged cells are: The vertically merged cells in the table used to represent the parent-child relationship between data type names and subordinate member fields.

3. The automated verification and repair method for data type definition tables for the SOME / IP protocol according to claim 1, characterized in that, include: In step S2, the rule for unique renaming is as follows: Add an underscore and the corresponding number of the preset Member Position after the original member name that is repeated; The repair log is generated based on the relevant records of the renaming operation and output along with a standard format worksheet.

4. The automated verification and repair method for data type definition tables for the SOME / IP protocol according to claim 1, characterized in that, include: In step S3, the priorities included in the multi-source priority decision-making mechanism, from high to low, are as follows: The table can contain basic data types directly entered, custom member reference types, and types deduced from array element reference types. The Boolean type normalization mapping process is as follows: Map different Boolean type description texts to the AUTOSAR platform standard uint8 type.

5. The automated verification and repair method for data type definition tables for the SOME / IP protocol according to claim 1, characterized in that, include: In step S4, the comparison dimensions of the member field set include member name, member data type, and member MemberPosition number; The criteria for determining high similarity are: only differences in annotations and notes are ignored.

6. The automated verification and repair method for data type definition tables for the SOME / IP protocol according to claim 1, characterized in that, include: In step S4, before performing the deletion operation, the original table and the duplicate definition data to be deleted are backed up.

7. The automated verification and repair method for data type definition tables for the SOME / IP protocol according to claim 1, characterized in that, include: In step S5, the standard format conforming to the AUTOSAR toolchain input specification is specifically as follows: The table header uses the standard English field names: DatatypeName, Category, MemberName, DatatypeReference, and ArraySize. This also includes re-performing the vertical cell merging operation for consecutive columns with the same DatatypeName; It also includes adding borders to table data areas and setting column widths according to engineering specifications.

8. An automated verification and repair system for data type definition tables oriented towards the SOME / IP protocol, characterized in that, The automated verification and repair system for the data type definition table of the SOME / IP protocol includes: Table parsing module: used to read the data type definition table of the table to be verified, parse the topological relationship of merged cells in the table, identify the merged area of ​​each logical structure and the corresponding start and end rows, and realize the conversion of visual grouping into machine-recognizable logical units; Naming conflict repair module: It communicates with the table parsing module and is used to traverse the member rows of each logical structure, check the uniqueness of member names, rename duplicate member names with serial numbers by referring to the Member Position field, and record the renaming information. Type Reference Unification Module: Communicates with the table parsing module to extract data type reference information, standardizes type references through a multi-source priority decision mechanism, and performs standardized mapping processing for Boolean types and non-standard basic types; Duplicate Definition Deletion Module: Communicates with the table parsing module to remove all merged cells in the table, construct a set of known data type names, identify redundant duplicate definitions by comparing the data type name union member field set, and delete the entire logical structure of duplicate definitions from the bottom of the table upwards; Standard format output module: It communicates with the naming conflict repair module, type reference unification module, and duplicate definition deletion module respectively, and is used to generate a new table worksheet that conforms to the toolchain input specification based on the data after verification and repair; Log generation module: It communicates with the naming conflict repair module, type reference unification module, and duplicate definition deletion module respectively. It is used to record the fault type, location, method and time of all repair operations, and generate and output the associated global repair log.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the automated verification and repair method for the data type definition table of the SOME / IP protocol as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the automated verification and repair method for data type definition tables for the SOME / IP protocol as described in any one of claims 1 to 7.

Images