Method and system for building a simulink model framework

Abstract

The application discloses a quick building method of a Simulink model framework, and the method comprises the following steps: obtaining and analyzing a target DBC file, and extracting message and signal metadata; performing deterministic data type inference on each signal based on a three-section priority rule, and generating a target data type; generating a Bus element object according to a signal name, the target data type and unit information, and aggregating the Bus element object into a Simulink Bus object and saving the Simulink Bus object as a bus dictionary file; automatically creating a signal chain group containing Inport, Bus Selector, DataType Conversion, Bus Creator and Outport in Simulink according to a preset topological template; binding the Simulink Bus object to a port, and performing automatic wiring and layout optimization to generate a Simulink model file. Through automatic DBC analysis, deterministic type inference and standardized model framework generation, the method solves the problems of low efficiency, easy error and poor consistency in manual modeling, and realizes one-key quick building of a vehicle-mounted controller communication model.

Description

Technical Field

[0001] This application relates to the fields of vehicle controller development and Simulink modeling technology, specifically to a method and system for building a Simulink model framework. Background Technology

[0002] During the development of vehicle controller software, engineers typically need to manually create Bus objects corresponding to communication signals one by one in the Simulink environment based on the CAN communication matrix file (usually in DBC format), and configure the data type, dimension, physical range and other attributes of the signals. At the same time, they also need to manually build a model framework structure that includes modules such as Inport, Bus Selector, Data TypeConversion, Bus Creator and Outport.

[0003] The existing manual implementation method has the following technical drawbacks:

[0004] First, it is inefficient. In vehicle model or domain control projects, DBC files typically contain hundreds to thousands of signals. Engineers need to perform repetitive operations for each signal, such as creating Bus elements, setting data types, filling in dimensions and ranges, dragging and dropping modules, and manually connecting wires. This process often takes hours or even days, severely restricting software development efficiency.

[0005] Secondly, it is prone to errors. The selection of data types (such as int8, uint16, single, etc.), the filling in of units of measurement, and the configuration of minimum / maximum values ​​are highly dependent on the engineer's personal experience and attention to detail. Once the configuration is incorrect, it will lead to deviations in subsequent simulation results or difficulties in locating problems during the actual vehicle debugging stage.

[0006] Third, there is a lack of consistency. Different engineers have different understandings and habits regarding naming rules and layout, resulting in significant style differences between different models within the same project, which is not conducive to collaborative team development and the reuse of model results.

[0007] In addition, some existing automation solutions often only realize the one-way conversion from DBC to Bus objects, failing to cover the entire process from Bus generation to the construction of a complete model framework, and lack the ability to handle different versions of DBC files, thus limiting their versatility.

[0008] Therefore, there is an urgent need for an automated method that can automatically generate Simulink Bus definitions and standard model frameworks from DBC files, in order to improve modeling efficiency, reduce human error, and ensure the consistency and reusability of the generated results. Summary of the Invention

[0009] This application provides a method and system for rapidly building a Simulink model framework, aiming to solve the technical problems of low efficiency, error-proneness, and poor consistency in existing manual modeling methods. To achieve the above objectives, this application adopts the following technical solution.

[0010] In a first aspect, embodiments of this application provide a method for constructing a Simulink model framework, including:

[0011] Step S1: Obtain the target DBC file and parse the target DBC file to extract at least one message and a set of signal metadata corresponding to each message; the set of signal metadata includes signal name, numerical representation attribute, physical range attribute, and bit width and sign attribute;

[0012] Step S2: Based on the preset data type inference rules, determine the data type of each signal and generate the target data type corresponding to each signal; the data type inference rules are a rule for deterministic type selection based on the priority order of the signal's numerical representation attribute, physical range attribute, bit width, and sign attribute.

[0013] Step S3: Generate a Bus element object corresponding to each signal based on the signal name, the target data type, and the unit information in the physical range attribute; generate a Simulink Bus object corresponding to each message based on the Bus element object of each signal; and persist all the Simulink Bus objects as a bus dictionary file.

[0014] Step S4: Obtain the bus dictionary file and automatically create a signal chain group corresponding to each message in the Simulink environment according to the preset model topology template; the signal chain group includes at least an input port module, a signal selection module, a data type conversion module, a signal reassembly module, and an output port module;

[0015] Step S5: Bind the corresponding Simulink Bus objects in the bus dictionary file to the input port module and the output port module of each signal chain group, and perform automatic wiring and layout optimization on each module in all signal chain groups, and finally generate and save a Simulink model file containing a complete signal chain.

[0016] Furthermore, the data type inference rules in step S2 specifically include:

[0017] The floating-point determination branch is executed first. That is, when the factor or offset in the numerical representation attribute has non-integer characteristics, or the minimum and maximum values ​​in the physical range attribute have non-integer characteristics, the target data type is directly determined to be a floating-point type.

[0018] When the conditions of the floating-point determination branch are not met, the explicit range determination branch is executed, that is, based on the minimum and maximum values ​​in the physical range attribute, the integer type with the minimum bit width that can completely cover the physical range of the signal is selected as the target data type.

[0019] When the conditions of the explicit range determination branch are not met, the bit width sign catch-all branch is executed, that is, the corresponding integer type or floating-point type is selected as the target data type based on the bit width value and sign attribute inferred by fusing the bit width and sign attributes.

[0020] Furthermore, when generating the Bus element object in step S3, a range gating writing step is also included, specifically including:

[0021] Obtain the legal numerical limit range corresponding to the target data type;

[0022] Determine whether the minimum and maximum values ​​in the physical range attribute both fall within the legal numerical limit range;

[0023] If yes, then the minimum and maximum values ​​are assigned to the Min and Max properties of the Bus element object, respectively; otherwise, the Min and Max properties of the Bus element object remain unassigned.

[0024] Furthermore, in step S1, when parsing the target DBC file, a cross-version field compatibility parsing step is also included, specifically comprising:

[0025] For the target field to be extracted, a candidate list containing multiple candidate field names is established; the multiple candidate field names correspond to the same semantic field under different DBC versions or different parsing tools;

[0026] According to the order of the candidate list, find and obtain the value of the first existing candidate field in the signal metadata set, and use it as the parsing result of the target field;

[0027] If none of the candidate fields in the candidate list exist, then the target field is assigned a preset default value.

[0028] Furthermore, when generating the Simulink model file in step S5, a unique naming process is also included, specifically:

[0029] Set the initial name for the Simulink model file to be generated or the internal module of the model;

[0030] Detect whether a model or module with the same initial name exists in the current Simulink workspace;

[0031] If a conflict exists, a distinguishing identifier is added to the initial name according to the preset naming conflict resolution strategy to generate a new unique name, and the creation or saving operation is performed with the new name.

[0032] Furthermore, the automatic wiring and layout optimization in step S5 specifically includes:

[0033] For each of the signal chain groups, preset horizontal coordinates are assigned to the input port module, signal selection module, data type conversion module, signal reconstruction module, and output port module to form the main path of signal flow in the horizontal direction;

[0034] Based on the number of signals in the signal chain group, calculate the vertical arrangement step size of the signal selection module, data type conversion module, and signal reconstruction module, and arrange each module and its corresponding signal line in sequence according to the arrangement step size, so that the vertical spacing between each signal line is maintained.

[0035] The modules are connected using a linear routing method, and after connection, Simulink's automatic layout function is called to perform a global fine-tuning of the overall model framework.

[0036] Furthermore, prior to step S1, a configuration initialization step is included, specifically comprising:

[0037] Load the preset configuration file; the configuration file contains adjustable parameters for data type inference rules, model generation options, and style parameters for model topology templates;

[0038] Displays the currently loaded configuration information on the graphical user interface and provides an entry point for modifying the configuration;

[0039] In response to a user's configuration modification command on the graphical user interface, the configuration parameters of the current session are updated, and subsequent steps are performed based on the updated configuration parameters.

[0040] Furthermore, the signal metadata set parsed in step S1 and the Simulink Bus object generated in step S3 are both recorded and stored as structured intermediate data files; the construction method also includes:

[0041] In response to a user-triggered model generation command, the intermediate data file is read directly, skipping steps S1 to S3, and steps S4 and S5 are executed to generate a Simulink model file.

[0042] Secondly, embodiments of this application provide a system for building a Simulink model framework, including:

[0043] The DBC acquisition and parsing module is used to acquire the target DBC file and parse it to extract at least one message and the signal metadata set corresponding to each message;

[0044] The data type inference module is used to perform deterministic type selection of the numerical representation attribute, physical range attribute, bit width and sign attribute of each signal according to priority order, and generate the target data type of each signal;

[0045] The bus object generation module is used to generate Bus element objects corresponding to each signal based on the signal metadata set and the target data type, and aggregate them into Simulink Bus objects corresponding to each message.

[0046] The bus dictionary persistence module is used to save all the Simulink Bus objects as a bus dictionary file;

[0047] The model framework generation module is used to obtain the bus dictionary file and automatically create a signal chain group corresponding to each message in the Simulink environment according to the preset model topology template; the signal chain group includes at least an input port module, a signal selection module, a data type conversion module, a signal reassembly module, and an output port module;

[0048] The model optimization and output module is used to bind the Simulink Bus object to the port of the signal chain group, perform automatic wiring and layout optimization on each module in the signal chain group, and generate the final Simulink model file.

[0049] Thirdly, embodiments of this application provide an electronic device, including: one or more processors;

[0050] A memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are able to implement the steps in the construction method described in any of the preceding claims.

[0051] Fourthly, embodiments of this application provide a computer-readable medium storing a computer program, which, when executed by a processor, can implement the steps in the construction method described in any of the preceding claims.

[0052] This application discloses a method for rapidly building a Simulink model framework. The method includes: acquiring and parsing a target DBC file to extract message and signal metadata; performing deterministic data type inference for each signal based on a three-segment priority rule to generate a target data type; generating Bus element objects based on the signal name, target data type, and unit information, aggregating them into Simulink Bus objects, and saving them as a bus dictionary file; automatically creating signal chain groups containing Inport, Bus Selector, DataType Conversion, Bus Creator, and Outport in Simulink according to a preset topology template; binding the Simulink Bus objects to ports and performing automatic wiring and layout optimization to generate a Simulink model file. This application solves the problems of low efficiency, error-proneness, and poor consistency in manual modeling through automated DBC parsing, deterministic type inference, and standardized model framework generation, achieving one-click rapid construction of vehicle controller communication models. Attached Figure Description

[0053] Figure 1 The core flowchart of a method for building a Simulink model framework provided in the embodiments of this application;

[0054] Figure 2 A schematic diagram of the module structure of a Simulink model framework building system provided in an embodiment of this application;

[0055] Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0056] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below with reference to the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. Unless otherwise specified, the various embodiments of this application and the features within those embodiments can be combined with each other.

[0057] As used herein, the term "and / or" includes any and all combinations of one or more of the associated enumerated entries. The terminology used herein is for describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms "a" and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that when the terms "comprising" and / or "made of" are used herein, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as "connected" or "linked" are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0058] Unless otherwise specified, all terms used in this application (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this application.

[0059] The core concept of this application is to achieve one-click rapid generation of vehicle controller communication models by establishing an end-to-end automated pipeline from DBC file parsing, automatic signal data type inference, automatic Bus object generation to automatic Simulink model framework construction. Specifically, data type inference employs a deterministic three-stage priority rule to ensure the uniqueness and reproducibility of the inference results; model framework generation uses pre-defined topology templates and automatic layout strategies to guarantee the structural consistency and readability of the generated model. (Reference) Figure 1 One embodiment of this application proposes a method for building a Simulink model framework, which may specifically include the following steps.

[0060] Step S1: Obtain the target DBC file and parse the target DBC file to extract at least one message and the signal metadata set corresponding to each message; the signal metadata set includes signal name, numerical representation attribute, physical range attribute, and bit width and sign attribute.

[0061] Users first execute the tool entry command (e.g., "dbc2bus") in the MATLAB command window to start the automated modeling tool of this application. After the tool starts, it first initializes by loading the preset configuration file.

[0062] The tool then calls MATLAB's `uigetfile` function to display a file selection dialog box. The dialog box is titled "Please select a DBC file (.dbc)" and the file type filter is set to ".dbc". After the user browses and selects a target DBC file in the dialog box and clicks the "OK" button, the tool obtains the full path of the file.

[0063] If the user clicks the "Cancel" button, the uigetfile function returns 0. The tool detects this return value, terminates the process, and displays the message "User has canceled" in the command window.

[0064] After obtaining a valid DBC file path, the tool calls the canDatabase function in MATLAB's Vehicle Network Toolbox to read the DBC file. The canDatabase function parses the DBC file into a database object, which contains information about all the messages and signals defined in the DBC file.

[0065] The tool then iterates through each message in the database object. For the currently encountered message, it retrieves the message's name and identifier (ID) by accessing its messageInfo property. Simultaneously, the tool further iterates through each signal contained within the message, extracting the following metadata fields for each signal: Name, Factor, Offset, Min, Max, Unit, Length, Signed, and Comment.

[0066] The extraction of the above fields employs a cross-version field compatibility parsing strategy. Specifically, for the target field "signal bit width", a candidate list `candidateList={'Length','BitLength',` is created.

[0067] The list contains 'Dimensions' and 'Size'. During parsing, the tool checks the signal objects sequentially to see if the corresponding fields exist. The checking method is as follows: first, the `isstruct` function is used to determine if the signal object is a structure; if so, the `isfield` function is used to check the field's existence; if it's an object, the `hasFieldOrProp` function is used to check the property's existence. When the first existing field is found, its value is used as the parsed bit width. If all candidate fields are missing, the bit width is set to 32 by default.

[0068] For the target field "Signed attribute", the candidate list is {'Signed', 'IsSigned'}. The same search and retrieval process is used sequentially. If neither exists, the string content of the DataType field is further parsed using regular expression matching—for example, if DataType contains the prefix "unsigned" or "u" (e.g., "uint8"), it is determined to be unsigned; if it contains the prefix "signed" or "s" or the suffix "int" (e.g., "sint16"), it is determined to be signed. If all the above parsing attempts fail, the default signification is unsigned.

[0069] After extraction, the tool organizes all the parsed data according to the hierarchical structure of "message → signal" and temporarily stores it in memory, forming a signal metadata set. Each signal metadata in this set includes at least the signal name, numerical representation attributes (Factor, Offset), physical range attributes (Min, Max, Unit), and bit width and sign attributes (Length, Signed). Step S1 is now complete.

[0070] The above process realizes the functions of "acquiring the target DBC file" and "parseting the target DBC file to extract at least one message and the signal metadata set corresponding to each message". The signal metadata set includes the signal name, numerical representation attributes (Factor, Offset), physical range attributes (Min, Max, Unit), and bit width and sign attributes (Length, Signed).

[0071] In a specific instance of this application, assume the user selects a DBC file named "powertrain.dbc", which contains a message named "BMS" (ID 0x18FEEB00) containing a signal named "Voltage". The parsed metadata of the Voltage signal is: Name="Voltage", Factor=0.1, Offset=0, Min=0, Max=500, Unit="V", Length=16, Signed=0.

[0072] In another example, suppose we are parsing a DBC file generated by the Vector tool. Its signal structure uses a "BitLength" field to represent the bit width and an "IsSigned" field to represent the sign. Following a cross-version compatibility parsing strategy, the "Length" field does not exist, so we continue searching for the "BitLength" field—it exists, and its value is retrieved as the bit width. The "Signed" field does not exist, so we continue searching for the "IsSigned" field—it exists, and its logical value is retrieved as the sign. Parsing is successful.

[0073] Step S2: Based on the preset data type inference rule, determine the data type of each signal and generate the target data type corresponding to each signal; the data type inference rule is a rule for deterministic type selection based on the priority order of the signal's numerical representation attribute, physical range attribute, bit width, and sign attribute.

[0074] This section details the implementation of step S2, namely the three-stage deterministic data type inference algorithm. Continuing from the Voltage signal metadata in step S1, its Factor=0.1, Offset=0, Min=0, Max=500. The data type inference logic first enters the floating-point decision branch. The tolerance tol=10 is set. -9 For Factor = 0.1, we calculate |0.1 - round(0.1)| = |0.1 - 0| = 0.1. Since 0.1 > 10, -9 The Factor is determined to be a non-integer. Therefore, the Voltage signal triggers the floating-point decision branch, and the target data type is directly determined to be a floating-point type (default single). This determination result is consistent with engineering expectations—since the factor 0.1 is a non-integer, using a fixed-point number would introduce rounding errors, making a floating-point type a safer choice.

[0075] Taking another signal, "State," as an example, its metadata is: Factor=1, Offset=0, Min=0, Max=3, Length=8, Signed=0. In the floating-point decision branch, Factor=1 and Offset=0 are both integers, and Min=0 and Max=3 are both integers. Therefore, the floating-point decision branch is not triggered, and the explicit range decision branch is entered.

[0076] In the explicit range determination branch, it first checks if Min and Max both exist and are integers, thus satisfying the condition. Then, it performs a Boolean fastpath check: it checks if the USE_BOOLEAN_FOR_BIN configuration is true and if Min ≥ 0 and Max ≤ 1. In this example, Max = 3 > 1, which does not meet the Boolean condition, so it enters the unsigned integer selection logic. Since Min = 0 ≥ 0, the system selects the smallest bit-width type from uint8 (upper limit 255), uint16 (upper limit 65535), uint32, and uint64 that ensures Max = 3 ≤ the upper limit of that type. The upper limit of uint8 is 255, and 3 ≤ 255, therefore uint8 is selected as the target data type for the State signal.

[0077] Taking the third signal "Reserved" as an example, its metadata is missing the Min and Max fields, Factor=1, Offset=0, Length=8, and Signed=0. This signal does not trigger the floating-point decision branch (Factor and Offset are both integers, and the absence of Min and Max is not used as a basis for non-integer decision), nor does it meet the conditions of the explicit range decision branch (Min and Max do not exist simultaneously), so it enters the bit-width sign catch-all branch.

[0078] In the bit-width sign fallback branch, bit-width fusion is performed first: L=8 is obtained from the Length field. Then, sign fusion is performed: Σ=0 (unsigned) is obtained from the Signed field. After obtaining L*=8 and Σ*=unsigned, since the condition of "1 bit unsigned and Boolean enabled" is not met (L*=8≠1), the system selects the smallest type that can cover the 8-bit bit width from uint8, uint16, uint32, and uint64, namely uint8.

[0079] The above three-stage inference process fully realizes the function of "determining the data type of each signal based on the preset data type inference rules and generating the target data type corresponding to each signal". The data type inference rule is a rule for deterministic type selection based on the priority order of the signal's numerical representation attribute, physical range attribute, bit width and sign attribute.

[0080] Through the above three-stage inference, the target data types of single, uint8 and uint8 were obtained from the three signals, respectively. The entire inference process is deterministic, interpretable and reproducible.

[0081] Step S3: Generate a Bus element object corresponding to each signal based on the signal name, the target data type, and the unit information in the physical range attribute; generate a Simulink Bus object corresponding to each message based on the Bus element objects of each signal; and persist all Simulink Bus objects as a bus dictionary file.

[0082] This section describes in detail the specific implementation of step S3, including the creation of BusElement objects, the aggregation of Bus objects, and the range gating write mechanism.

[0083] Following the inference result in step S2, for the State signal (target data type uint8, Min=0, Max=3), the tool first creates a Simulink.BusElement object. During creation, the attributes are assigned values ​​according to the following rules:

[0084] Name attribute: Set to "State";

[0085] DataType property: Set to "uint8";

[0086] Unit attribute: Set to the unit extracted from DBC (if any), and remove the "﹣" character;

[0087] Dimensions property: Set to 1;

[0088] Complexity property: Set to "real";

[0089] SampleTime property: Set to -1;

[0090] Description attribute: Combines the Comment field with Factor and Offset into a string in the format "State signal(Factor=1, Offset=0)".

[0091] For the Min and Max attributes, a range-gated write mechanism is executed. The tool first obtains the legal value limit range of the uint8 type by calling Simulink's numericLimits function. numericLimits('uint8') returns [0,255], that is, the minimum legal value of the uint8 type is 0, and the maximum legal value is 255.

[0092] Subsequently, the tool performs range gating judgment: it checks whether the Min=0 and Max=3 of the State signal both fall within the interval [0,255]. Since 0∈[0,255] and 3∈[0,255], it is determined to be valid, and Min=0 is written to the Min property of the BusElement object, and Max=3 is written to the Max property of the BusElement object.

[0093] Taking another signal, "Temperature," as an example, suppose its Min = -40 and Max = 150, and the target data type is inferred to be uint16. In the range gating judgment, the valid range of uint16 is [0, 65535]. Min = -40 does not satisfy the condition "Min ∈ [0, 65535]", so the Min attribute remains unassigned (left empty); Max = 150 satisfies the condition "Max ∈ [0, 65535]", so Max = 150 is written to the Max attribute of the BusElement object.

[0094] After creating BusElement objects for all signals, the tool aggregates the BusElement objects belonging to the same message (e.g., the "BMS" message) into a single Simulink.Bus object. Bus objects are named according to a preset naming convention, in the format "SG_CH_BMS_0x18FEEB00_PDU". Here, "SG_CH_" is a fixed prefix, "BMS" is the message name, "0x18FEEB00" is the hexadecimal uppercase representation of the message ID (with the "0x" prefix), and "PDU" is a fixed suffix.

[0095] Finally, the tool saves all generated Simulink.Bus objects (corresponding to each message in DBC) as a .mat format bus dictionary file named "powertrain_bus.mat". This file is the output of step S3 and is used for the model framework generation in the subsequent step S4.

[0096] Step S4: Obtain the bus dictionary file and automatically create a signal chain group corresponding to each message in the Simulink environment according to the preset model topology template; the signal chain group includes at least an input port module, a signal selection module, a data type conversion module, a signal reassembly module, and an output port module.

[0097] This section describes in detail the specific implementation of step S4, including the automatic creation of the model framework and the unique naming process.

[0098] First, the tool loads the "powertrain_bus.mat" bus dictionary file generated in step S3, and imports all Simulink.Bus objects into the MATLAB workspace using the load function.

[0099] Then, for each Bus object (i.e., each message), the tool creates a corresponding set of signal chain modules in the Simulink model. Taking the "BMS" message as an example (this message contains 5 signals), the tool creates the following modules:

[0100] An Inport module is used to receive externally input bus signals;

[0101] A Bus Selector module is used to select individual signals from the input bus;

[0102] Five Data Type Conversion modules (the same number as the number of signals) are used to convert the selected signals into the specified data type;

[0103] A Bus Creator module is used to recombine all signals into a bus;

[0104] An Outport module is used to output the reassembled bus to the outside of the model.

[0105] When creating the above modules, the tool performs a unique naming process. The specific process is as follows:

[0106] First, the tool generates an initial model name "powertrain_bus_model" based on the DBC filename "powertrain.dbc". Before saving the model, the tool checks if a loaded model named "powertrain_bus_model" already exists by calling the bdIsLoaded function, and simultaneously checks if a model file named "powertrain_bus_model.slx" already exists in the file system by calling the which function. If both return negative results, the name is valid. If a conflict exists, "__1" is appended to the initial name, forming "powertrain_bus_model__1", and the check is performed again until a unique model name is generated.

[0107] For naming modules within the model, the tool creates a containers.Map (named "usedBlockNames") to record the names of all used modules within the current model. The initial names of each module are generated according to the following rules:

[0108] Inport module: named "BMS_in";

[0109] Bus Selector module: named "BMS_BusSel";

[0110] Data Type Conversion module: Named according to signal name, such as "DTConv_Voltage", "DTConv_Current", etc.

[0111] Bus Creator module: named "BMS_BusCreator";

[0112] Outport module: named "BMS_out".

[0113] After generating the initial name, the tool checks if the name already exists in the "usedBlockNames" container. If it doesn't exist, the name is used directly and added to the container. If it already exists (for example, if there are two signals with the same name in the same model, or if the user has manually added a module with the same name to the model), the initial name is appended with "__serial number" (e.g., "BMS_BusSel__2"), and the check is repeated until the name is unique.

[0114] In a specific scenario, assuming the "powertrain_bus_model" model already exists, the tool automatically generates a new model named "powertrain_bus_model__1". In this new model, if the "BMS" message contains two signals with the same name (although this would not happen in standard DBC, it is a defensive design), the tool will automatically generate a unique name such as "DTConv_Voltage__2" for the Data Type Conversion module corresponding to the second signal.

[0115] Step S5: Bind the corresponding Simulink Bus objects in the bus dictionary file to the input port module and the output port module of each signal chain group, and perform automatic wiring and layout optimization on each module in all signal chain groups, and finally generate and save a Simulink model file containing a complete signal chain.

[0116] This section describes in detail the specific implementation of step S5, including Bus type binding, automatic wiring, and layout optimization.

[0117] Following the signal chain modules created in step S4, the tool first performs a Bus type binding operation. For the signal chain group corresponding to the "BMS" message, the Simulink.Bus object "SG_CH_BMS_0x18FEEB00_PDU" is bound to the "OutDataTypeStr" attribute of the Inport module, making the output data type of the Inport module the Bus type; at the same time, the Bus object is bound to the "DataTypeStr" attribute of the Outport module, making the input data type of the Outport module the Bus type as well.

[0118] The tool then performs an automatic connection. The specific connection path is as follows:

[0119] Connect the output port of the Inport module to the input port of the Bus Selector module;

[0120] Connect from the first signal output port (e.g., "Voltage") of the Bus Selector module to the input port of the first DataType Conversion module ("DTConv_Voltage");

[0121] Connect the second signal output port (e.g., "Current") of the Bus Selector module to the input port of the second DataType Conversion module ("DTConv_Current");

[0122] ...and so on, until all signals are connected;

[0123] Connect the output ports of each Data Type Conversion module to the corresponding input ports of the Bus Creator module;

[0124] Connect the output port of the Bus Creator module to the input port of the Outport module.

[0125] After completing the wiring, the tool performs layout optimization. For the "BMS" signal chain group (containing 5 signals), the tool sets the X-axis position of each module according to preset horizontal coordinates: the X-coordinate of the Inport module is set to 50, the X-coordinate of the Bus Selector module is set to 240, the X-coordinate of the Data Type Conversion module is set to 510, the X-coordinate of the Bus Creator module is set to 770, and the X-coordinate of the Outport module is set to 1040. These coordinate values ​​ensure that the modules are arranged horizontally from left to right, forming a clear main path for signal flow.

[0126] In the vertical (Y-axis) direction, the tool first obtains the number of signals N=5 contained in the signal chain group. Then, it calculates the vertical arrangement of each signal with a row height rowH=24. Specifically, the Bus Selector output port of the first signal ("Voltage") is located at Y=100, and the corresponding Data Type Conversion module is also located at Y=100; the second signal ("Current") is located at Y=124; the third at Y=148; the fourth at Y=172; and the fifth at Y=196. The module height blkH=16, and a vertical spacing of yGap=100 is maintained between the bottom of each group and the top of the next group.

[0127] When creating each connection, the tool sets the "autorouting" property of the connection to "on", so that Simulink automatically generates connections using straight-line routing to avoid connections crossing.

[0128] After completing all connections, the tool calls the Simulink.BlockDiagram.arrangeSystem function and sets the "NestedSystem" parameter to true to perform a global automatic fine-tuning of the current model. This function can further optimize the spacing and alignment between modules, making the model layout cleaner and more aesthetically pleasing.

[0129] Finally, the tool saves the model, which has completed the creation, binding, connection, and layout of all signal chain groups, as a Simulink model file in the format of "powertrain_bus_model.slx" and displays a success message and the file save path in the command window.

[0130] In one embodiment of this application, the specific implementation of the configuration initialization step is described in detail.

[0131] When the tool starts, it first loads a preset configuration file. This configuration file can be in JSON, XML, or MATLAB's .mat format. In a specific example, the configuration file is named "dbc2bus_config.json", and its content is shown below:

[0132] {"FLOAT_DEFAULT_TYPE": "single", "USE_BOOLEAN_FOR_BIN": true, "BLOCK_X_SPACING": 270, "ROW_HEIGHT": 24, "BLOCK_HEIGHT": 16, "Y_GAP": 100, "INPORT_X": 50, "BUSSELECTOR_X": 240,"DTCONV_X": 510,"BUSCREATOR_X": 770,"OUTPORT_X":1040}

[0133] After loading the configuration file, the tool displays a summary of the current configuration on the main panel of the graphical user interface (GUI), such as: "Floating-point default type: single; 1-bit signal → boolean: enabled; Module horizontal spacing: 270". This information helps users understand the current behavior settings before running the program.

[0134] The GUI also provides an "Advanced Options" button or panel, which users can click to view and modify all current configuration parameters. For example, if a user wants the generated model to use the double type instead of the single type, they can change the "Default Floating-Point Type" from "single" to "double" in the advanced options and then click the "OK" button. After the tool captures this modification instruction, it updates the configuration object in memory. In subsequent step S2, when performing data type inference, all signals that trigger the floating-point decision branch will be assigned the double type.

[0135] Configuration changes only apply to the current session and will not be written to the default configuration file itself. If a user wishes to permanently modify the default configuration, they can directly edit the configuration file.

[0136] In one embodiment of this application, the specific implementation of the intermediate data caching and reuse steps is described in detail.

[0137] When a user executes the complete process for "powertrain.dbc" for the first time, after completing steps S1 (DBC parsing) and S3 (Bus object generation), the tool will, in addition to generating the Bus dictionary file "powertrain_bus.mat", also save the following data as an intermediate data file:

[0138] The original signal metadata parsed in step S1 includes the message structure, signal list, and all attributes of each signal such as Factor, Offset, Min, Max, Unit, Length, and Signed; the target data type of each signal inferred in step S2; and the complete structure of each Simulink.BusElement object and Simulink.Bus object generated in step S3.

[0139] The intermediate data file is named "powertrain_metadata.mat" and is saved in the same directory as the Bus dictionary file.

[0140] When the user later needs to generate a model with a different layout style for the same DBC (e.g., adjusting layout parameters such as module spacing or vertical step size), they can select the "Generate Model from Existing Metadata" option on the tool interface and specify the "powertrain_metadata.mat" file. After detecting this instruction, the tool directly reads the intermediate data file, recovers the complete signal metadata, target data type, and Bus object structure from memory, and then jumps to step S4 to quickly generate the model file using the new layout parameters.

[0141] This intermediate data caching mechanism eliminates the need for users to repeatedly perform time-consuming DBC parsing (especially for large DBC files containing hundreds of messages and thousands of signals, where the parsing process may take several seconds to tens of seconds) and type inference processes, significantly improving the efficiency of parameter adjustment and model iteration.

[0142] refer to Figure 2 One embodiment of this application also provides a Simulink model framework building system. This embodiment details the modules of the Simulink model framework building system and their collaborative relationships. This system, as a toolbox application integrated into the MATLAB environment, includes the following functional modules.

[0143] 1. DBC Acquisition and Parsing Module: This module is responsible for interacting with the user to obtain the DBC file path and calling the canDatabase function to complete the parsing of the DBC file. After parsing, this module passes the signal metadata set as output to the data type inference module.

[0144] 2. Data Type Inference Module: This module receives signal metadata from the DBC acquisition and parsing module, executes a three-stage deterministic data type inference algorithm, and generates a target data type for each signal. After inference, this module outputs the "signal-target data type" mapping relationship to the bus object generation module.

[0145] 3. Bus Object Generation Module: This module receives signal metadata and its corresponding target data type, creates a Simulink.BusElement object for each signal (where the Min / Max attributes are written using a range gating mechanism), and aggregates all BusElement objects belonging to the same message into a Simulink.Bus object. After generation, this module passes the Bus object collection to the bus dictionary persistence module.

[0146] 4. Bus dictionary persistence module: This module receives a collection of Bus objects and saves them as a bus dictionary file in .mat format. It can also selectively save intermediate data files.

[0147] 5. Model framework generation module: This module reads the bus dictionary file and creates a signal chain group (including Inport, Bus Selector, Data Type Conversion, Bus Creator, Outport, etc.) for each message in the Simulink environment according to the preset topology template. A unique naming strategy is used during the creation process.

[0148] 6. Model Optimization and Output Module: This module receives the signal chain groups created by the model framework generation module, binds the corresponding Simulink.Bus objects to the Inport and Outport ports, performs automatic wiring and layout optimization, and finally saves the complete model as a .slx file.

[0149] The modules communicate with each other through standardized data structures: the DBC acquisition and parsing module outputs signal metadata (an array of structures), the data type inference module outputs a type mapping table (a container Map), the bus object generation module outputs Bus objects (an array of Simulink.Bus objects), the bus dictionary persistence module outputs file paths (strings), the model framework generation module outputs model handles (numerical values), and the model optimization and output module finally outputs the model file path. This standardized data interface allows each module to be developed, tested, and upgraded independently, reducing system coupling.

[0150] The Simulink model framework rapid construction method and system provided in this application can be widely applied in model-based design development processes in fields such as automotive electronics, aerospace, and industrial automation. By automating manual operations, it significantly improves the efficiency of building vehicle controller communication models, reduces human error rates, and ensures model consistency and maintainability, thus possessing significant industrial practical value.

[0151] The embodiments of the aforementioned construction method and the embodiments of the aforementioned construction system are identical or related in technical concept, and they can be referenced and learned from each other in terms of technical details and technical effects, which will not be repeated here.

[0152] Overall, the advantages of this application compared to the prior art include:

[0153] 1. Regarding modeling efficiency

[0154] In existing vehicle controller development processes, engineers manually create Simulink Buses line by line based on DBC files, configure signal data types and dimensions, and build the model structure from Inport to Outport. A model containing hundreds to thousands of signals often takes hours or even days. This application establishes an end-to-end automated pipeline from DBC file parsing, automatic signal data type inference, Bus object generation to automatic model framework construction. Users only need to provide DBC files to generate complete Simulink model files with one click, reducing modeling time from hours to minutes, fundamentally eliminating the repetitive work of manually dragging and dropping modules and configuring signals line by line.

[0155] 2. Regarding the accuracy and consistency of data type inference

[0156] In traditional manual modeling, engineers select data types for each signal based on personal experience. Different people may make different judgments about the same signal, and type configuration errors are easily caused by oversight. This application designs a deterministic three-stage data type inference algorithm—selecting types based on a priority order of non-integer features first, explicit range minimum coverage, and bit width sign fusion as a fallback. Any signal under the same input will necessarily obtain the same data type, completely eliminating the ambiguity and randomness of human judgment, and ensuring the consistency and reproducibility of data type configurations across engineers and projects.

[0157] 3. Robustness of range configuration

[0158] When manually configuring the minimum / maximum values ​​of signals, engineers often struggle to accurately remember the legal numerical limits of various data types. They frequently fill in the physical range defined in the DBC without considering its compatibility with the target data type, leading to warnings or even simulation interruptions due to out-of-bounds attribute configurations. This application employs a range-gated write mechanism. Before writing the Min / Max value to the BusElement object, it first obtains the legal limit range of the target data type and performs a validity check. Writing is only performed when the physical range defined in the DBC falls entirely within the legal range; otherwise, it is automatically left blank and logged, thus avoiding simulation errors caused by out-of-bounds configurations.

[0159] 4. Regarding DBC version compatibility

[0160] Existing DBC files may use different field names for the same semantic field due to different generation tools or versions (e.g., bit width may be represented as Length, BitLength, Dimensions, or Size). If the parsing script does not perform normalization processing, it is very easy to cause cross-toolchain mapping errors. This application adopts a compatible parsing strategy of establishing a list of multiple candidate fields and searching them sequentially, which automatically adapts to the format differences generated by different DBC versions and tools. This enables the automated construction method to be stably applied to various new and old projects without the need for customized modifications for specific DBC formats.

[0161] 5. Consistency between model naming and layout

[0162] When different engineers manually build models, their understanding of module naming rules and layout differs, leading to significant differences in model style within the same project. This hinders team collaboration and the reuse of results. This application employs automatic uniqueness processing for model names and module names, coupled with a standardized layout strategy that pre-sets horizontal coordinates and vertical steps. This ensures that all generated models have a unified naming convention and a neat signal flow arrangement, allowing them to be directly used for simulation verification without manual adjustments.

[0163] 6. Complete automation from Bus to model framework

[0164] Existing automated solutions can only achieve a one-way conversion from DBC to Bus objects to generate a data dictionary. Engineers still need to manually build the standard signal chain structure in Simulink: Inport → Bus Selector → Data Type Conversion → Bus Creator → Outport. This application further automates the creation of complete signal chain groups, performs Bus type binding, and automatic wiring layout after generating the Bus dictionary. It integrates the data definition and model framework generation into a single automated process, achieving seamless output from DBC input to a directly executable Simulink model file.

[0165] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of this application. Figure 3 As shown in the embodiments of this application, an electronic device includes: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the construction methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0166] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0167] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0168] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0169] This application also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps in any of the construction methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0170] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described construction method.

[0171] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0172] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0173] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0174] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing the status information of the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0175] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0176] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0177] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0178] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0179] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0180] Exemplary embodiments have been disclosed in this application, and while specific terminology has been used, it is used only and should be interpreted in a general illustrative sense and is not intended to be limiting. In some embodiments, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A method for constructing a Simulink model framework, characterized in that, include: Step S1: Obtain the target DBC file and parse the target DBC file to extract at least one message and the signal metadata set corresponding to each message; The signal metadata set includes signal name, numerical representation attribute, physical range attribute, bit width and sign attribute; Step S2: Based on the preset data type inference rules, determine the data type of each signal and generate the target data type corresponding to each signal; the data type inference rules are a rule for deterministic type selection based on the priority order of the signal's numerical representation attribute, physical range attribute, bit width, and sign attribute. Step S3: Generate a Bus element object corresponding to each signal based on the signal name, the target data type, and the unit information in the physical range attribute; generate a Simulink Bus object corresponding to each message based on the Bus element object of each signal; and persist all the Simulink Bus objects as a bus dictionary file. Step S4: Obtain the bus dictionary file and automatically create a signal chain group corresponding to each message in the Simulink environment according to the preset model topology template; the signal chain group includes at least an input port module, a signal selection module, a data type conversion module, a signal reassembly module, and an output port module; Step S5: Bind the corresponding Simulink Bus objects in the bus dictionary file to the input port module and the output port module of each signal chain group, and perform automatic wiring and layout optimization on each module in all signal chain groups, and finally generate and save a Simulink model file containing a complete signal chain.

2. The construction method according to claim 1, characterized in that, The data type inference rules in step S2 specifically include: The floating-point determination branch is executed first. That is, when the factor or offset in the numerical representation attribute has non-integer characteristics, or the minimum and maximum values ​​in the physical range attribute have non-integer characteristics, the target data type is directly determined to be a floating-point type. When the conditions of the floating-point determination branch are not met, the explicit range determination branch is executed, that is, based on the minimum and maximum values ​​in the physical range attribute, the integer type with the minimum bit width that can completely cover the physical range of the signal is selected as the target data type. When the conditions of the explicit range determination branch are not met, the bit width sign catch-all branch is executed, that is, the corresponding integer type or floating-point type is selected as the target data type based on the bit width value and sign attribute inferred by the fusion of the bit width and sign attribute.

3. The construction method according to claim 2, characterized in that, When generating the Bus element object in step S3, the process also includes a range gating writing step, which specifically includes: Obtain the legal numerical limit range corresponding to the target data type; Determine whether the minimum and maximum values ​​in the physical range attribute both fall within the legal numerical limit range; If yes, then the minimum and maximum values ​​are assigned to the Min and Max properties of the Bus element object, respectively; otherwise, the Min and Max properties of the Bus element object remain unassigned.

4. The construction method according to claim 1, characterized in that, When parsing the target DBC file in step S1, a cross-version field compatibility parsing step is also included, specifically: For the target field to be extracted, a candidate list containing multiple candidate field names is established; the multiple candidate field names correspond to the same semantic field under different DBC versions or different parsing tools; According to the order of the candidate list, find and obtain the value of the first existing candidate field in the signal metadata set, and use it as the parsing result of the target field; If none of the candidate fields in the candidate list exist, then the target field is assigned a preset default value.

5. The construction method according to claim 1, characterized in that, When generating the Simulink model file in step S5, a unique naming process is also included, specifically: Set the initial name for the Simulink model file to be generated or the internal module of the model; Detect whether a model or module with the same initial name exists in the current Simulink workspace; If a conflict exists, a distinguishing identifier is added to the initial name according to the preset naming conflict resolution strategy to generate a new unique name, and the creation or saving operation is performed with the new name.

6. The construction method according to claim 1, characterized in that, The automatic wiring and layout optimization in step S5 specifically includes: For each of the signal chain groups, preset horizontal coordinates are assigned to the input port module, signal selection module, data type conversion module, signal reconstruction module, and output port module to form the main path of signal flow in the horizontal direction; Based on the number of signals in the signal chain group, calculate the vertical arrangement step size of the signal selection module, data type conversion module, and signal reconstruction module, and arrange each module and its corresponding signal line in sequence according to the arrangement step size, so that the vertical spacing between each signal line is maintained. The modules are connected using a linear routing method, and after connection, Simulink's automatic layout function is called to perform a global fine-tuning of the overall model framework.

7. The construction method according to claim 1, characterized in that, Before step S1, a configuration initialization step is also included, specifically including: Load the preset configuration file; the configuration file contains adjustable parameters for data type inference rules, model generation options, and style parameters for model topology templates; Displays the currently loaded configuration information on the graphical user interface and provides an entry point for modifying the configuration; In response to a user's configuration modification command on the graphical user interface, the configuration parameters of the current session are updated, and subsequent steps are performed based on the updated configuration parameters.

8. The construction method according to claim 1, characterized in that, The signal metadata set parsed in step S1 and the Simulink Bus object generated in step S3 are both recorded and stored as structured intermediate data files. The construction method also includes: In response to a user-triggered model generation command, the intermediate data file is read directly, skipping steps S1 to S3, and steps S4 and S5 are executed to generate a Simulink model file.

9. A system for building a Simulink model framework, characterized in that, include: The DBC acquisition and parsing module is used to acquire the target DBC file and parse it to extract at least one message and the signal metadata set corresponding to each message; The data type inference module is used to perform deterministic type selection of the numerical representation attribute, physical range attribute, bit width and sign attribute of each signal according to priority order, and generate the target data type of each signal; The bus object generation module is used to generate Bus element objects corresponding to each signal based on the signal metadata set and the target data type, and aggregate them into Simulink Bus objects corresponding to each message. The bus dictionary persistence module is used to save all the Simulink Bus objects as a bus dictionary file; The model framework generation module is used to obtain the bus dictionary file and automatically create a signal chain group corresponding to each message in the Simulink environment according to the preset model topology template; the signal chain group includes at least an input port module, a signal selection module, a data type conversion module, a signal reassembly module, and an output port module; The model optimization and output module is used to bind the Simulink Bus object to the port of the signal chain group, perform automatic wiring and layout optimization on each module in the signal chain group, and generate the final Simulink model file.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it can perform the steps in the construction method according to any one of claims 1 to 8.

Images