Simulink model normalization automatic checking method and device

Abstract

The invention discloses a Simulink model normativity automatic inspection method and device, and the method comprises the steps: creating an independent configuration file containing rule information, a judgment condition and a violation template for each inspection rule, and synchronously developing inspection functions corresponding to the independent configuration files one by one; analyzing the to-be-checked Simulink model, extracting module attributes, signal line connection relationships and global data, and caching the module attributes, the signal line connection relationships and the global data into an information set; sequentially executing each check function according to a predefined priority sequence, loading and verifying the independent configuration file corresponding to each check function, matching a target object from the information set, performing compliance judgment, and generating a check result containing hierarchical paths, rule numbers and reasons if the judgment is illegal; according to the method, all inspection results are stored in a standardized structural body, and an inspection report containing model names, duration and Simulink locatable click links is generated through summarization, so that the defect that an existing tool is low in integration level is overcome, the enterprise-level CI / CD process can be seamlessly connected, and the development quality and efficiency of embedded software are guaranteed.

Description

Technical Field

[0001] This invention belongs to the field of computer software technology, specifically relating to a method and apparatus for automatic checking of Simulink model conformity. Background Technology

[0002] Model-based design (MBD) has become the mainstream approach in safety-critical fields such as automotive electronics and aerospace. As a core modeling tool, Simulink's model quality directly affects the safety, reliability, and development efficiency of embedded software, making model compliance checks crucial.

[0003] Existing automated Simulink model checking technologies have significant shortcomings. On the one hand, commercial built-in tools (such as Model Advisor) have poor rule customization, insufficient collaboration capabilities, and low integration, making them unable to adapt to specific enterprise needs and CI / CD processes. On the other hand, while custom script development is flexible, rule development is inefficient and inconsistent, and complex model checks suffer from poor performance due to repetitive I / O operations.

[0004] There is an urgent need to address the challenges of developing large-scale customized inspection rules and the low efficiency of inspecting complex models. Therefore, there is a pressing need in this field for an automated inspection method for customized Simulink models that can improve development efficiency, optimize execution performance, and ensure maintainability. Summary of the Invention

[0005] The purpose of this invention is to provide a Simulink model specification automatic checking method and apparatus. On the one hand, it solves the problem that the existing checking tools are difficult to adapt to personalized specifications and cannot meet the specific needs of enterprises. On the other hand, it solves the technical defects of low development efficiency, poor consistency and excessive time consumption when dealing with complex models when customized checking solutions are developed.

[0006] The technical solution adopted in this invention is as follows: The first aspect of this application provides an automatic Simulink model canonicality check method, including: When creating an independent configuration file containing rule information, judgment conditions, and violation templates for each inspection rule, inspection functions corresponding to each independent configuration file are developed simultaneously. The Simulink model to be inspected is parsed to extract module attributes, signal line connection relationships and global data, and cached as an information set. Each of the aforementioned inspection functions is executed sequentially according to a predefined priority order. After loading and verifying the independent configuration files corresponding to each inspection function, the target object is matched from the information set and compliance is determined. If a violation occurs, an inspection result containing hierarchical path, rule number, and reason is generated. The inspection results are stored in a standardized structure and then compiled to generate an inspection report containing the model name, duration, and a Simulink-locatable clickable link.

[0007] In one optional embodiment, the rule information in the independent configuration file includes a rule identifier, a rule description, and a rule priority; the violation template predefines two types of information formats: error and warning, each corresponding to a different violation level.

[0008] In one alternative embodiment, all the checking functions follow a unified input / output architecture and parameter parsing standard; The input-output architecture includes input parameters and output parameters. The input parameters are the model information set and the corresponding independent configuration file data, and the output parameters are the standardized compliance judgment results.

[0009] In an alternative embodiment, after caching the information set, the method further includes: Construct a structured database and cache the information set in the structured database; The information set supports fast retrieval based on module ID and signal line name, and the structured database includes a module information database, a signal line information database, and a global data information database.

[0010] In an optional embodiment, loading the independent configuration files corresponding to the verification and each check function specifically includes: Determine the validity of the independent configuration file format and whether it fully contains the rule information, judgment conditions, and violation template. If the verification fails, exit the current inspection function and execute the next one.

[0011] In one optional embodiment, after storing each inspection result into a standardized structure, the system also records whether the inspection passed, the number of warnings, the number of errors, and non-run information. The inspection report also includes an overview of the inspection results.

[0012] A second aspect of this application provides an automatic Simulink model canonicality checking system, comprising: The configuration and function construction module is used to create an independent configuration file for each inspection rule, containing rule information, judgment conditions and violation templates, and to simultaneously develop inspection functions that correspond one-to-one with the configuration file; The model parsing and caching module is used to parse the Simulink model to be inspected, extract module attributes, signal line connection relationships and global data, and cache them as an information set. The inspection execution module is used to execute each inspection function in the order of priority defined in the configuration file. After loading the verification configuration file, it matches the target object and makes a compliance judgment. If a violation is found, it generates a result containing the hierarchical path, rule number and reason. The results processing and output module is used to store each inspection result into a standardized structure and generate an inspection report containing the model name, inspection duration, and Simulink clickable links.

[0013] A third aspect of this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the steps of the method described above.

[0014] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described above.

[0015] A fifth aspect of this application provides a computer program product including computer instructions that instruct a computing device to perform operations corresponding to the methods described above.

[0016] Compared with the prior art, the present invention has the following beneficial effects: By configuring independent configuration files for each inspection rule and developing corresponding inspection functions that follow a unified architecture, the separation of inspection logic and execution code is achieved. This not only breaks free from the limitations of fixed rules in commercial built-in tools, enabling flexible adaptation to the specific specification requirements of different enterprises and projects, but also solves the problems of inconsistent architecture and high maintenance costs in custom script development, significantly reducing the difficulty of rule iteration and upgrades, while facilitating knowledge accumulation and sharing in team collaboration. Secondly, by adopting a one-time parsing and caching method for structured model information, the repetitive I / O operations caused by each inspection rule independently traversing the model are avoided, significantly reducing the inspection time of complex models. Furthermore, the execution of inspection functions based on the priority defined in the configuration file can prioritize high-weight compliance requirements, further improving the targeting and execution efficiency of the inspection process. Finally, the inspection results are stored in a standardized structure, generating a violation report containing violation links that can be directly located in the Simulink environment, enabling rapid tracing and rectification of violations. The standardized output format also solves the shortcomings of low integration in existing tools, enabling seamless integration with enterprise-level CI / CD processes, helping model inspection to be integrated into the automated development system, and ensuring the development quality and efficiency of embedded software in safety-critical areas. Attached Figure Description

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

[0018] Figure 1 A flowchart of an automatic Simulink model specification checking method provided by the present invention; Figure 2 A schematic diagram of a model specification check report provided by the present invention in an automatic Simulink model specification check system; Figure 3 This is a schematic diagram of a standardized warning message for Rule 1 in an automatic Simulink model specification checking system provided by the present invention. Figure 4 This is a schematic diagram of the standardized error information for Rule Instance 2 in an automatic Simulink model specification checking system provided by the present invention. Figure 5 This invention provides a schematic diagram of the standardized error information for rule instance 3 in an automatic Simulink model specification checking system. Figure 6 This invention provides a schematic diagram of a rule instance specification check report in an automatic specification check system for Simulink models. Figure 7 This invention provides a schematic diagram of an automatic Simulink model specification checking system. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0020] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0021] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0022] To address the technical deficiencies mentioned in the background section, the present invention will now be described in further detail with reference to the accompanying drawings: like Figure 1 As shown, in a first aspect of this application, a method for automatic canonical checking of Simulink models is provided, comprising: S101. When creating an independent configuration file containing rule information, judgment conditions and violation templates for each inspection rule, simultaneously develop inspection functions that correspond one-to-one with the independent configuration file. For example, during the development phase, an independent configuration file is created for each rule of the Simulink model specification check. Each independent configuration file contains at least the basic information of the rule, the judgment conditions of the check logic, and the violation information template for errors or warnings. The rule information in the independent configuration file includes the rule identifier, rule description, and rule priority. The violation template needs to predefine two types of information formats: error and warning, and make the error and warning information formats correspond to different violation levels. In this way, the specific content of the check rule is separated from the program code of the execution script, thereby reducing unexpected code errors and flexibly adapting to business needs.

[0023] Then, check functions corresponding to each rule are developed simultaneously. All check functions follow a unified input-output architecture and parameter parsing standard. The input-output architecture includes input parameters and output parameters. The input parameters are the model information set and the corresponding independent configuration file data, and the output parameters are the standardized compliance judgment results.

[0024] S102. Parse the Simulink model to be inspected, extract module attributes, signal line connection relationships and global data, and cache them as an information set; For example, the Simulink model to be inspected is parsed to obtain its structured information. Module attributes, signal line connection relationships, and global data are extracted in one go to form an information set. Subsequently, a structured database is constructed, which includes a module information database, a signal line information database, and a global data information database. The aforementioned information set is cached in this structured database. The cached information set supports fast retrieval based on module ID and signal line name, providing efficient data query support for subsequent inspections.

[0025] S103. Execute each of the aforementioned check functions in sequence according to a predefined priority order. After loading and verifying the independent configuration files corresponding to each check function, match the target object from the information set and make a compliance judgment. If there is a violation, generate a result containing hierarchical path, rule number and reason. For example, each check function is executed sequentially according to a predefined priority order. During the execution of each check function, the completeness and validity of the corresponding independent configuration file are first loaded and verified. Specifically, loading and verifying the independent configuration file includes judging the validity of the independent configuration file format and whether it completely contains the rule information, judgment conditions, and violation template. If the loading and verification of the independent configuration file is successful, the target object to be checked is obtained based on the information set. The target object is a module, signal line, or model attribute, and compliance judgment is completed according to the judgment conditions in the independent configuration file. If a violation is determined, an inspection result containing the hierarchical path of the violating object in the model, the violation rule number, and the reason is generated based on the violation information template.

[0026] If the standalone configuration file to be loaded and verified does not exist or the standalone configuration file format is invalid, then exit the current check function and continue to execute the next check function.

[0027] S104. Store each inspection result into a standardized structure and generate an inspection report containing the model name, duration, and Simulink clickable links.

[0028] For example, after storing each inspection result in a standardized structure, the standardized structure records the inspection status, violation level, and detailed information. Then, all inspection results are summarized to generate an inspection report. The inspection report includes the model name, inspection duration, and a clickable violation link that conforms to the Simulink model path format. The link allows direct location of the violation object in the Simulink environment. It is worth noting that the standardized structure also records whether the inspection passed, the number of warnings, the number of errors, and non-run information. The inspection report also includes an overview of the inspection results.

[0029] In the operations of steps S101-S104 above, this embodiment achieves "datafication" encapsulation of inspection rules through independent configuration files. When adding or modifying rules, no changes are required to the core code; only addition, deletion, or modification operations are needed in the independent configuration files. This significantly reduces the technical threshold and error risk of system maintenance, while facilitating unified management and team collaboration and sharing of rules. Furthermore, due to the innovative adoption of the "preloading-caching-querying" model, the redundant process of "each rule independently traversing the model" in traditional methods is abandoned. Instead, the model is parsed once and a memory snapshot is generated, with all rules quickly queried based on the snapshot. This optimizes the inspection time from a positive correlation of "number of rules × model complexity" to an approximately linear correlation of "number of rules + model complexity." When dealing with large-scale complex models, the inspection speed can be improved by orders of magnitude. Finally, the inspection results output by the method adopt a standardized structured format, which can be directly called and parsed by various systems such as Web platforms and CI / CD tools without additional format conversion. This achieves seamless integration with enterprise-level technology toolchains, providing key support for the construction of automated development processes.

[0030] A second aspect of this application provides an automatic Simulink model canonicality checking system, such as... Figure 7 As shown, it includes: The configuration and function construction module is used to create an independent configuration file for each inspection rule, containing rule information, judgment conditions and violation templates, and to simultaneously develop inspection functions that correspond one-to-one with the independent configuration files; The model parsing and caching module is used to parse the Simulink model to be inspected, extract module attributes, signal line connection relationships and global data, and cache them as an information set. The inspection execution module is used to execute each inspection function in a predefined priority order, load and verify the independent configuration file corresponding to each inspection function, match the target object from the information set and make a compliance judgment. If a violation is determined, a result containing hierarchical path, rule number and reason is generated. The results processing and output module is used to store each inspection result into a standardized structure and generate an inspection report containing the model name, inspection duration, and Simulink clickable links.

[0031] Next, the implementation process of the system of the present invention will be described in detail with specific examples. This case selects a Simulink model specification set containing 90 inspection rules as the basis. The rules cover multiple core inspection scenarios, including: naming standardization inspection of modules, subsystems and various parameters in the Simulink model, configuration and usage compliance inspection of module parameters, and Stateflow parameter setting and usage logic inspection, etc. The present invention method performs automated standardization inspection on the target Simulink model and finally outputs a complete and accurate inspection report, clearly presenting the model compliance status.

[0032] Specifically, during the development phase, for each of the 90 inspection rules in the selected Simulink model specification set, an independent rule configuration file is created. Each independent configuration file uniformly contains three core contents, including rule information, inspection logic judgment conditions, and violation templates.

[0033] The rule information includes key attributes such as rule identifier, rule name, rule description, and rule priority; the inspection logic judgment conditions clearly define the inspection target, the parameters to be verified, and the compliance judgment standards. The violation template includes predefined error message templates or warning message templates, which are used to generate standardized violation prompts.

[0034] Based on the above 90 rules, corresponding check functions were developed one by one, and all check functions followed a unified function architecture. Figure 1 Standardized development is carried out to ensure consistency between function calls and execution logic.

[0035] After the inspection process is started, the initialization support function is called first. This function extracts all the structured information of the target Simulink model (including the module information library, signal line information library and model global data information library) in one go by calling the Simulink API, integrates them to form the target model information set, and caches it in global variables to provide an efficient and reusable data foundation for subsequent inspection processes.

[0036] Next, each check function will be executed sequentially according to a unified and standardized process, as follows: Process 1: When executing each check function, first load its corresponding independent rule configuration file and verify the file's validity. Check whether the independent configuration file completely contains the rule information, check logic judgment conditions, and violation version mentioned above. If the independent configuration file does not exist, has a syntax error, or is missing core content, exit the current check function and execute the next one. If the verification passes, proceed to the next process.

[0037] Step 2: Extract the target object of the rule (such as "Goto" type module, "From" type module) from the loaded rule independent configuration file. Based on the above cached target model information set, retrieve and obtain all modules, signal lines or global model data that match the target object.

[0038] If the search result is not empty, proceed to the next step; if the search result is empty, exit the current checking function and execute the next step.

[0039] Step 3: Extract the corresponding inspection parameters and compliance judgment conditions from the loaded independent rule configuration file. Based on these, conduct compliance verification on all target inspection objects obtained in Step 2. If non-compliant objects are found, proceed to the next step.

[0040] Step 4: Retrieve the error or warning message template corresponding to the rule from the loaded rule configuration file, and generate standardized error / warning messages containing the non-compliant object, violation type, and reason for each non-compliant object identified in Step 3.

[0041] Based on the 90 rules in the selected Simulink model specification set, after executing the corresponding check function for each rule, the check result of that rule is stored in the standardization result structure. Once all 90 check functions for the 90 rules have been executed, the execution results of all check functions are summarized, and a standardization check report for the target Simulink model is generated (see report section). Figure 2 ).

[0042] The inspection report covers core information from multiple dimensions. First, it includes basic information such as the name of the inspected model and the total inspection time. Second, it provides an overview of the inspection results, presenting the overall compliance status intuitively. Third, it provides detailed information on errors and warnings, including specific violations, reasons for violations, and the path of the violating object in the model. All paths are encapsulated as clickable location links, allowing users to quickly jump to the model path where the violating object is located by clicking the link, thus achieving accurate location and tracing of the problem.

[0043] Furthermore, the following three types of typical inspection rules are selected as examples to illustrate the specific workflow of the normative inspection system of this model: Rule Example 1: To verify the label matching between "Goto" and "From" modules in a Simulink model, each "Goto" module must be associated with at least one matching "From" module. If a "Goto" module's label name is misspelled, or the corresponding "From" module is accidentally deleted, the signal connection will be interrupted, leading to abnormal model functionality.

[0044] Rule Example 2: Check if there are any unconnected signal lines in the model. Unconnected signal lines can easily cause simulation errors, code generation failures, and other problems, and must be strictly checked.

[0045] Rule Example 3: Control the uniqueness of data names in the control model workspace and data dictionary (sldd), and prohibit duplicate data names between the two.

[0046] Based on the above three rule implementation examples, the working steps of the model standardization check system are discussed in detail.

[0047] For the aforementioned three rule implementation examples, an independent rule configuration file is created for each rule. Taking rule implementation example 1 as an example, its independent rule configuration file contains the following core content: (1) Rule information: Rule identifier: misra_slsf_018_d; Rule Name: Usage Guidelines for the "From" and "Goto" Modules; Rule description: Each Goto module must be associated with at least one matching From module; Rule priority: Mandatory.

[0048] (2) Check the logical judgment conditions Inspect the target object: Goto type modules and From type modules; Check the parameter: tag name (parameter identifier is "GotoTag"); Compliance requirements: Any Goto module must have at least one From module in the global scope of the model, and the "GotoTag" parameter value of the From module must be exactly the same as the "GotoTag" parameter value of the Goto module.

[0049] (3) Violation template: "[Warning]: The tag '{tag}' of the Goto module {block_path} does not match the corresponding From module."

[0050] The rule configuration file for Rule Example 2 contains the following core content: (1) Rule information: Rule identifier: db_0081_a; Rule Name: Control of Unconnected Signal Cables; Rule description: Unconnected signal lines are prohibited in the model; Rule priority: Recommended.

[0051] (2) Check the logical judgment conditions Target object to be inspected: signal line; Check parameters: signal line source end, target end; Compliance requirements: Both the source and destination ends of each signal line must be non-empty and exist simultaneously. If this condition is met, the line is considered compliant; if either the source or destination end is empty, the line is considered non-compliant.

[0052] (3) Violation template: Template 1: "Both ends of the signal line (signal line handle: {line_handle}) in the system {block_path} are not connected"; Template 2: "[Error]: [Violation of rule db_0081_a] There is an unconnected signal line in module {block_path}".

[0053] The rule configuration file for rule example 3 contains the following core content: (1) Rule information: Rule identifier: jc_0791_c; Rule Name: Uniqueness Control of Data Names in Model Workspace and Data Dictionary; Rule description: Data names defined in the model workspace must not be duplicated with data names in the data dictionary (sldd); Rule priority: Mandatory.

[0054] (2) Check the logical judgment conditions: The target objects to be examined are: data in the model workspace and data in the data dictionary (sldd). Check parameters: Data name; Compliance requirements: No data name in the model workspace has a corresponding data name in the data dictionary (sldd); if data with the same name exists in both the model workspace and the data dictionary, it is considered a violation.

[0055] (3) Violation template: "[Error]: [Violation of rule jc_0791_c] The variable {parameter} exists in both the DataDictionary and the ModelWorkspace."

[0056] For each of the three rule implementation examples mentioned above, a corresponding check function was developed, and all check functions follow a unified function architecture. Figure 1 Standardized development should be carried out to ensure that the input and output, execution logic and error handling mechanisms of functions remain consistent.

[0057] After the inspection process is started, the system automatically calls the initialization support function. This function extracts all the structured information of the target Simulink model at once by calling the Simulink API interface. Specifically, it covers the module information library, signal line information library and model global data information library, integrates them to form the target model information set, and caches it in global variables, providing an efficient and reusable unified data foundation for the execution of subsequent inspection functions.

[0058] The following is the execution flow of the check function in Rule Example 1: Load the rule configuration file corresponding to rule example 1, and verify whether the file completely contains the rule information, check logic judgment conditions and violation templates described above.

[0059] If the configuration file is valid (exists, has correct syntax, and complete core content), proceed to the next step; if the configuration file does not exist, has a syntax error, or is missing core content, exit the current checking function and execute the checking function corresponding to rule example 2.

[0060] Extract the target objects (Goto type modules and From type modules) from the loaded configuration file, and retrieve all Goto type modules and From type modules in the model based on the cached target model information set.

[0061] If the search result is not empty, proceed to the next step; if the search result is empty, exit the current checking function and execute the checking function corresponding to Rule Example 2.

[0062] Extract the inspection parameters (tag name, parameter identifier is "GotoTag") and compliance judgment conditions from the configuration file (each Goto module must match at least one From module in the global scope of the model, and the "GotoTag" parameter values ​​of the two must be exactly the same). The specific judgment logic is as follows: For each Goto module (denoted as Goto_A) in the search results list, perform the following operations in sequence: a. Extract the "GotoTag" parameter value (i.e., the tag name) of Goto_A; b. Iterate through all From modules and compare the value of the "GotoTag" parameter with the tag name of Goto_A for each module. c. Result determination: If at least one matching From module exists, Goto_A is deemed compliant; if no match is found, Goto_A is deemed non-compliant.

[0063] Violation Information Generation: Retrieve the violation template corresponding to the rule from the configuration file, and generate standardized warning information (such as...) for each identified violation Goto module. Figure 3 (As shown).

[0064] The check function corresponding to Example 2 of the unified standardized process is executed as follows: Load the rule configuration file corresponding to rule example 2, and verify whether the file completely contains the rule information, check logic judgment conditions and violation templates described above.

[0065] If the configuration file is valid (exists, has correct syntax, and complete core content), proceed to the next step; if the configuration file does not exist, has a syntax error, or is missing core content, exit the current checking function and execute the checking function corresponding to rule example 3.

[0066] Extract the target object (signal line) to be inspected from the loaded configuration file, and retrieve and obtain all signal line handles in the model based on the signal line information library in the cached target model information set.

[0067] If the search result is not empty, proceed to the next step; if the search result is empty, exit the current checking function and execute the checking function corresponding to rule example 3.

[0068] Extract the inspection parameters (source end and destination end of the signal line) and compliance judgment conditions from the configuration file (both the source end and destination end of each signal line must be non-empty; if either is empty, it is judged as a violation). The specific judgment logic is as follows: For each signal line handle (denoted as signal line_A) in the search results list, perform the following operations in sequence: a. Extract information from the source and target ends of signal line _A; b. Compliance determination: If both the source and destination ends of signal line _A are not empty, the signal line is deemed compliant; if the source end is empty, the destination end is empty, or both ends are empty, the signal line is deemed non-compliant.

[0069] Violation template generation: Retrieve the two types of error message templates corresponding to this rule from the configuration file, and generate standardized error messages based on the violation type (see...). Figure 4 ): If both ends of signal line _A are empty, call violation template 1 to generate information; if only the source end or only the target end is empty, call violation template 2 to generate information.

[0070] The check function corresponding to Example 3 of the unified standardized process is executed as follows: Load the rule configuration file corresponding to rule example 3, and verify whether the file completely contains the rule information, check logic judgment conditions and error information templates described above.

[0071] If the configuration file is valid (exists, has correct syntax, and complete core content), proceed to the next step; if the configuration file does not exist, has a syntax error, or is missing core content, exit the current check function and execute the check function corresponding to the next rule.

[0072] Extract the target objects (model workspace data and data in the data dictionary (sldd)) from the loaded configuration file. Based on the global model data information library in the cached target model information set, retrieve and obtain all model workspace data and data in the data dictionary (sldd) of the model.

[0073] If the search result is not empty, proceed to the next step; if the search result is empty, exit the current checking function and execute the checking function corresponding to the next rule.

[0074] Extract the inspection parameters (data name) and compliance judgment conditions from the configuration file (any data name in the model workspace must not have a data with the same name in the data dictionary (sldd); if a data with the same name exists, it is judged as a violation). The specific judgment logic is as follows: For each model workspace data (denoted as data_A) in the search results list, perform the following operations in sequence: a. Extract the name of data_A; b. Traverse all data in the data dictionary (sldd) and compare each data with the name of data_A. If any matching data with the same name is found, immediately determine that data_A is in violation.

[0075] Violation information generation: Retrieve the error message template corresponding to the rule from the configuration file, and generate standardized error messages for each violation data _A identified in process 3 (see...). Figure 5 ).

[0076] After completing the inspection process based on the aforementioned three rule implementation examples, the system stores the execution results of the inspection function corresponding to each rule into a standardized result structure for unified management. Once all the inspection functions for each rule have been executed, the system centrally summarizes and parses all the inspection results in the structure, ultimately generating a standardization inspection report for the target Simulink model (see partial screenshot of the report). Figure 6 The report clearly presents the inspection results, violation details, and location information for each rule, allowing users to directly view and analyze the model's compliance status and providing a clear basis for model rectification.

[0077] A third aspect of this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method described above.

[0078] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described above.

[0079] According to a fifth aspect of this application, a computer program product is provided, including computer instructions that instruct a computing device to perform operations corresponding to the above method.

[0080] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for automatic canonical checking of Simulink models, characterized in that, include: When creating an independent configuration file containing rule information, judgment conditions, and violation templates for each inspection rule, inspection functions corresponding to each independent configuration file are developed simultaneously. The Simulink model to be inspected is parsed to extract module attributes, signal line connection relationships and global data, and cached as an information set. Each of the aforementioned inspection functions is executed sequentially according to a predefined priority order. After loading and verifying the independent configuration files corresponding to each inspection function, the target object is matched from the information set and compliance is determined. If a violation is determined, an inspection result containing hierarchical path, rule number, and reason is generated. The inspection results are stored in a standardized structure and then compiled to generate an inspection report containing the model name, duration, and a Simulink-locatable clickable link.

2. The method for automatic checking of Simulink model conformity according to claim 1, characterized in that, The rule information in the independent configuration file includes rule identifier, rule description, and rule priority; The violation template predefines two types of information formats: error and warning. The error and warning information formats correspond to different violation levels.

3. The method for automatic verification of Simulink model conformity according to claim 1, characterized in that, All the aforementioned checking functions follow a unified input / output architecture and parameter parsing standard; The input-output architecture includes input parameters and output parameters. The input parameters are a set of information and corresponding independent configuration file data, and the output parameters are standardized compliance judgment results.

4. The method for automatic checking of Simulink model canonicity according to claim 1, characterized in that, After caching the information into a collection, it also includes: Construct a structured database and cache the information set in the structured database; The information set supports fast retrieval based on module ID and signal line name, and the structured database includes a module information database, a signal line information database, and a global data information database.

5. The method for automatic checking of Simulink model conformity according to claim 1, characterized in that, When loading the separate configuration files corresponding to the verification and each check function, the specific steps include: Determine the validity of the independent configuration file format and whether it fully contains the rule information, judgment conditions, and violation template. If the verification fails, exit the current inspection function and execute the next one.

6. The method for automatic checking of Simulink model canonicity according to claim 1, characterized in that, After storing each inspection result in a standardized structure, the system also records whether the inspection passed, the number of warnings, the number of errors, and information on non-running processes. The inspection report also includes an overview of the inspection results.

7. An automatic Simulink model specification checking system, characterized in that, include: The configuration and function construction module is used to create an independent configuration file for each inspection rule, containing rule information, judgment conditions and violation templates, and to simultaneously develop inspection functions that correspond one-to-one with the independent configuration files; The model parsing and caching module is used to parse the Simulink model to be inspected, extract module attributes, signal line connection relationships and global data, and cache them as an information set. The inspection execution module is used to execute each inspection function in a predefined priority order, load and verify the independent configuration file corresponding to each inspection function, match the target object from the information set and make a compliance judgment. If a violation is determined, an inspection result containing hierarchical path, rule number and reason is generated. The results processing and output module is used to store each inspection result into a standardized structure and generate an inspection report containing the model name, inspection duration, and Simulink clickable links.

8. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes a computer program, it implements the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When a computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-6.

10. A computer program product comprising computer instructions, characterized in that, The computer instructions instruct the computing device to perform the operation corresponding to the method described in any one of claims 1-6.

Images