Underlying software and simulink model combination method and MBD tool chain design method

Abstract

The invention discloses an underlying software and simulink model combination method and an MBD tool chain design method, and relates to the technical field of automobile electronic embedded software development, and the method comprises the following steps: constructing a lightweight structure on a software architecture level; generating a common header file data dictionary; setting an input or output signal; a polling interface of the functional module is incorporated into time slice scheduling logic; and completing automatic integration from the function model to the executable code. According to the method, the deployment process from the model to the executable code is simplified, the development threshold and cost are remarkably reduced, the development efficiency, the code reusability and the iteration speed are improved, and meanwhile good reliability and maintainability are kept.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic embedded software development technology, and in particular to a method for combining low-level software and Simulink models, as well as an MBD toolchain design method. Background Technology

[0002] With the rapid development of automotive intelligence and electrification, the number and complexity of on-board electronic control units (ECUs) continue to rise, placing higher demands on software development efficiency, reliability, and cost control. Model-based development (MBR) has become the mainstream paradigm for automotive electronic software development due to its advantages such as visual modeling, automatic code generation, and early verification. Meanwhile, AUTOSAR (Automotive Open System Architecture), as an industry standard software architecture, is widely used in the MBD process to decouple the application layer from the underlying software.

[0003] However, the mainstream MBD toolchains in existing technologies heavily rely on commercial AUTOSAR solutions, which are not only expensive to license but also have complex configuration processes and steep learning curves. Professional engineers need to invest a lot of time in RTE (Runtime Environment) configuration, interface mapping, and middleware development. Especially for small ECUs with limited resources and relatively simple functions, such as starter power controllers and window control modules, such heavy toolchains are redundant and uneconomical. In addition, traditional solutions usually achieve the interface between the underlying software and Simulink generated code by customizing middleware or manually writing glue code. The process is cumbersome, error-prone, and difficult to reuse, which seriously restricts development efficiency and iteration speed. Summary of the Invention

[0004] In view of the problems existing in the current methods of combining underlying software and Simulink models and the MBD toolchain design method, this invention is proposed.

[0005] Therefore, the problem to be solved by this invention is: how to provide a lightweight MBD development method and toolchain for small, resource-constrained automotive ECUs that is independent of commercial AUTOSAR, requires no manual gluing of code, and supports automatic and efficient integration of Simulink models and underlying software.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, embodiments of the present invention provide a method for combining underlying software and Simulink models and an MBD toolchain design method, which includes: constructing a lightweight structure at the software architecture level, generating a common header file data dictionary, and binding the common header file data dictionary to the data dictionary configuration of each functional Simulink model; During the Simulink model development phase, the script is run to read the files in the COMMON layer, generate a common header file data dictionary, and associate the common header file data dictionary with the data dictionary configuration of each functional Simulink model, so that the Simulink model can directly reference the global structure variables defined in the COMMON layer. In the Simulink model code generation configuration, the input or output signals are set, and the generation function name is uniformly modified to the preset polling interface name to complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program; Reserve the corresponding functional module polling interface in the main.c file, and incorporate the functional module polling interface into the time slice scheduling logic to complete the periodic execution of each ASW layer; For the ert_rtw code directory generated by the functional model, the corresponding cleanup script for the ert_rtw code directory is called, and the cleanup script is placed at the ASW layer location to complete the automated integration of the functional model into executable code.

[0007] As a preferred embodiment of the underlying software and Simulink model combination method and MBD toolchain design method described in this invention, the lightweight structure includes an ASW layer, a BSW layer, a COMMON layer, an RTE layer, and a Main module. The ASW layer is used to integrate application layer code generated from the Simulink model, and the BSW layer is used to generate low-level driver code through the graphical configuration tool provided by the MCU manufacturer. The COMMON layer is used to uniformly store global structure variables shared by the BSW layer and the ASW layer; the RTE layer is used to encapsulate custom general functions; and the Main module is used to implement a time-slice scheduling mechanism based on a timer. The generation of the common header file data dictionary involves using files in the COMMON layer and automatically generating the common header file data dictionary by running a script, enabling the Simulink model to reference global structure variables defined in the COMMON layer during the code generation phase.

[0008] As a preferred embodiment of the underlying software and Simulink model combination method and MBD toolchain design method described in this invention, the reading of files in the COMMON layer includes executing a Matlab script named Commonhead_sldd_make.m before starting the Simulink model development process. The Matlab script refers to automatically locating and reading the commonhead.h and commonhead.c files in the COMMON layer directory of the software architecture, and extracting the defined common global structure definition information. The Matlab script uses the data dictionary API provided by the Simulink model to convert the extracted structure information into a Simulink model data dictionary object that conforms to the Simulink model specification, and packages it to generate a shared data dictionary file commonhead.sldd as a unified data contract; The configuration of the data dictionary that associates the common header file data dictionary with each functional Simulink model includes enabling the Simulink model to reference the global structure variables defined in the COMMON layer. After opening the functional model, in the property settings interface of the functional model, the generated commonhead.sldd file is added as the associated data dictionary of the current functional model. After the binding is completed, the modules inside the functional model select the structure fields defined in commonhead.sldd as the signal source or target. During the code generation phase, based on the data dictionary, the signals of the functional model are mapped to read and write operations on global structure variables declared in the COMMON layer.

[0009] As a preferred embodiment of the underlying software and Simulink model integration method and MBD toolchain design method described in this invention, the step of setting the input or output signals includes, after the Simulink model completes data dictionary binding, entering the C code generation > code interface > code mapping page in the model configuration parameters, and selecting the signals for the Simulink model. This setting enables Simulink Coder to declare the variables corresponding to signals as extern type when generating code, instead of redefining them inside the generated code. The definition of extern type variables is located in commonhead.h and commonhead.c of the COMMON layer, ensuring that the generated code of the ASW layer and the underlying driver of the BSW layer access the same global structure variable, thus completing the data-level interoperability. The function is called by the main program in the Simulink model's C code generation > interface > generated function name configuration item, which explicitly changes the Simulink model execution function name to the preset polling interface name corresponding to the functional module; At this point, it needs to be consistent with the function call statements reserved in the time slice scheduling logic in the main.c file in the Main module. After the code is generated, the Simulink Coder outputs the C function. The C function implementation is located in the ASW layer, and internally it reads and writes the global structure of the COMMON layer through the ImportedExtern variable. In the time-slice scheduling loop of main.c, the main program calls the polling interface function at a set period to complete the execution of the Main module.

[0010] As a preferred embodiment of the underlying software and Simulink model combination method and MBD toolchain design method described in this invention, the polling interface function is included in the main.c file of the Main module, where a time slice scheduling loop based on hardware timer interrupt is predefined, and the time slice scheduling loop executes the polling interface functions corresponding to each functional module in sequence according to a preset fixed period. The name of the polling interface function has been explicitly configured during the Simulink model code generation stage and is consistent with the function call statement in the main.c file; The time-slice scheduling loop calls the corresponding C function located in the ASW layer in the form of function calls. The called polling interface function reads the shared interaction data between the BSW and ASW layers collected by the BSW layer through the global structure variable, thereby completing the periodic execution of the functional modules of each ASW layer under the unified scheduling of the Main module.

[0011] As a preferred embodiment of the underlying software and Simulink model combination method and MBD toolchain design method described in this invention, the step of calling the corresponding ert_rtw code directory purification script includes, after the Simulink model completes code generation, outputting a code directory with the suffix _ert_rtw, and executing a Matlab purification script that matches the Simulink model name. The Matlab cleanup script refers to automatically locating and reading the generated files in the Diagnose_ert_rtw directory, filtering out the polling interface functions and related data structures generated by the user configuration, and eliminating redundant runtime support code. After removing redundant runtime support code and organizing it, it is automatically copied or moved to the corresponding functional subdirectory of the ASW layer in the software architecture; the Matlab cleanup script synchronously updates the project build configuration, enabling the main.c file to be linked during compilation, completing the end-to-end automated integration from the Simulink model to the ASW layer executable code that can be scheduled by the Main module without manual intervention.

[0012] As a preferred embodiment of the underlying software and Simulink model combination method and MBD toolchain design method described in this invention, wherein: the time-slice scheduling loop includes the first... The polling interface function of the first functional module, after startup, Execution time in the next scheduling cycle Satisfy the following formula: ; in, Indicates the scheduling start reference time. Indicates the preset main scheduling period. Indicates the first The estimated execution time cost of each functional module. Indicates the functional module number. Indicates the first The first functional module in the The execution time within the next scheduling cycle.

[0013] Secondly, embodiments of the present invention provide a method for combining underlying software and Simulink models and an MBD toolchain design system, which includes: an architecture building module, which builds a lightweight structure at the software architecture level, generates a common header file data dictionary, and binds the common header file data dictionary to the data dictionary configuration of each functional Simulink model; The data dictionary generation and binding module runs scripts during the Simulink model development phase, reads files in the COMMON layer, generates a common header file data dictionary, and associates the common header file data dictionary with the data dictionary configuration of each functional Simulink model, enabling the Simulink model to directly reference the global structure variables defined in the COMMON layer. The code interface configuration module sets the input or output signals in the code generation configuration of the Simulink model, and uniformly modifies the name of the generated function to the preset polling interface name to complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program. The scheduling and execution module reserves the corresponding functional module polling interface in the main.c file and incorporates the functional module polling interface into the time slice scheduling logic to complete the periodic execution of each ASW layer; The automated integration module calls the corresponding cleanup script in the ert_rtw code directory generated by the functional model, and places the cleanup script in the ASW layer to complete the automated integration of the functional model into executable code.

[0014] Thirdly, embodiments of the present invention provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement any step of the above-described method for combining low-level software and Simulink models and the MBD toolchain design method.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program thereon, wherein: when the computer program is executed by a processor, it implements any step of the above-described method for combining underlying software and Simulink models and the MBD toolchain design method.

[0016] The beneficial effects of this invention are as follows: By constructing a lightweight software architecture including an ASW layer, BSW layer, COMMON layer, RTE layer, and Main module, and combining automated scripts to generate a common header file data dictionary and bind it to the Simulink model, this invention achieves seamless integration between the application layer and the underlying software without the need for commercial AUTOSAR RTE support. By configuring the model input / output signals as ImportedExtern type and uniformly generating preset polling interface function names, Simulink generated code can directly read and write global structure variables defined in the COMMON layer, avoiding the need to manually write glue code or customize middleware. At the same time, the Main module directly calls each polling interface function based on the time slice scheduling mechanism of the timer, ensuring the periodic and deterministic execution of functional modules. With the automated purification and integration scripts of the ert_rtw code directory, the deployment process from model to executable code is greatly simplified. The overall solution significantly reduces the MBD development threshold and cost of small ECUs, improves development efficiency, code reusability and iteration speed, while maintaining good reliability and maintainability. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 The flowchart illustrates a method for combining underlying software and a Simulink model, as well as a method for designing the MBD toolchain, provided in an embodiment of the present invention.

[0018] Figure 2 This is a system schematic diagram illustrating a method for combining underlying software and a Simulink model, as well as an MBD toolchain design method, provided in an embodiment of the present invention.

[0019] Figure 3 This is a schematic diagram of the structure of a medium for a method of combining underlying software and Simulink model and a design method of MBD toolchain provided in an embodiment of the present invention.

[0020] Figure 4 This is a schematic diagram of a computing device that provides a method for combining underlying software and a Simulink model, as well as an MBD toolchain design method, according to an embodiment of the present invention. Detailed Implementation

[0021] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0022] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0023] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0024] This invention is described in detail with reference to the schematic diagrams. When describing the embodiments of this invention, for ease of explanation, the cross-sectional views illustrating the device structure may be partially enlarged, not according to the usual scale. Furthermore, the schematic diagrams are merely examples and should not be construed as limiting the scope of protection of this invention. In actual fabrication, the three-dimensional spatial dimensions of length, width, and depth should be included.

[0025] Furthermore, in the description of this invention, it should be noted that the terms "upper," "lower," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are used solely for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. In addition, the terms "first," "second," or "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0026] Unless otherwise explicitly specified and limited, the terms "installation," "connection," and "joining" in this invention should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; similarly, they can refer to mechanical connections, electrical connections, or direct connections, or indirect connections through an intermediate medium, or internal connections between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0027] Example Reference Figure 1 and Figure 2This is the first embodiment of the present invention, which provides a method for combining underlying software and Simulink models, and a method for designing the MBD toolchain, including: S1: Build a lightweight structure at the software architecture level, generate a common header file data dictionary, and bind the common header file data dictionary to the data dictionary configuration of each functional Simulink model.

[0028] The lightweight structure includes the ASW layer, BSW layer, COMMON layer, RTE layer, and Main module; The ASW layer is used to integrate application layer code generated from the Simulink model, while the BSW layer is used to generate low-level driver code using the graphical configuration tools provided by the MCU manufacturer. The COMMON layer is used to uniformly store global structure variables shared by the BSW and ASW layers; the RTE layer is used to encapsulate custom general functions; and the Main module is used to implement a time-slice scheduling mechanism based on timers. Generating a common header data dictionary involves using files in the COMMON layer and automatically generating the common header data dictionary by running a script, enabling the Simulink model to reference global structure variables defined in the COMMON layer during the code generation phase.

[0029] Furthermore, the lightweight structure consists of five core parts: the ASW layer, the BSW layer, the COMMON layer, the RTE layer, and the Main module. Each layer has a clear responsibility and works collaboratively. The ASW layer is specifically designed to integrate application-layer C code automatically generated from Simulink functional models (such as Diagnose.slx, Protect.slx, etc.). The BSW layer utilizes graphical configuration tools provided by the MCU manufacturer (such as NXP S32DS Configuration Tools) to generate low-level driver code, including peripheral initialization and operation logic for ADC, PWM, CAN, GPIO, etc. The COMMON layer acts as a data bridge between ASW and BSW, uniformly storing shared global structure variables (such as BmsInfo_t) to ensure that both access the same memory data. The RTE layer does not rely on the AUTOSAR standard runtime environment but encapsulates custom general functions required by the project (such as byte order conversion, bubble sort, checksum calculation, etc.) for ASW or BSW to call. The Main module is responsible for the system's main control logic, the core of which is a time-slice scheduling mechanism based on hardware timers or SysTick, which sequentially calls the polling interfaces of each ASW functional module according to a preset period. Based on this architecture, by running the Commonhead_sldd_make.m script, the commonhead.h and commonhead.c files in the COMMON layer are automatically parsed, and the common global structure definition information defined therein is extracted. The Simulink data dictionary API is then used to generate a common header file data dictionary named commonhead.sldd. This data dictionary is then bound to the data dictionary configuration of each Simulink model, enabling the model to directly reference the global structure variables declared in the COMMON layer during the development and code generation phases. This achieves data interoperability and efficient collaboration between the application layer and the underlying software without introducing RTE configuration or middleware.

[0030] S2: During the Simulink model development phase, run the script, read the files in the COMMON layer, generate a common header file data dictionary, and associate the common header file data dictionary with the data dictionary configuration of each functional Simulink model, so that the Simulink model can directly reference the global structure variables defined in the COMMON layer.

[0031] The process of reading files in the COMMON layer includes executing a Matlab script named Commonhead_sldd_make.m before the Simulink model development process starts. The Matlab script automatically locates and reads the commonhead.h and commonhead.c files in the COMMON layer directory of the software architecture and extracts the definition information of the defined common global structures. The Matlab script uses the data dictionary API provided by the Simulink model to convert the extracted structure information into a Simulink model data dictionary object that conforms to the Simulink model specification, and packages it to generate a shared data dictionary file commonhead.sldd as a unified data contract; The configuration of the data dictionary that links the common header file data dictionary to the data dictionary of each functional Simulink model includes enabling the Simulink model to reference the global structure variables defined in the COMMON layer. After opening the functional model, in the property settings interface of the functional model, add the generated commonhead.sldd file as the associated data dictionary of the current functional model; after the binding is completed, the modules inside the functional model select the structure fields defined in commonhead.sldd as the signal source or target. During the code generation phase, based on the data dictionary, the signals of the functional model are mapped to read and write operations on global structure variables declared in the COMMON layer.

[0032] Furthermore, before the Simulink model development process officially begins, the system first executes a Matlab script named Commonhead_sldd_make.m. This script automatically locates and reads the commonhead.h and commonhead.c files in the COMMON layer directory of the software architecture, parsing out all global structure types and their member variables defined for use by the BSW and ASW layers (i.e., "shared global structure definition information," such as the cellVoltage, systemState, and other fields in BmsInfo_t, along with their data types and dimensions). Subsequently, the script calls the data dictionary programming interfaces provided by Simulink (such as Simulink.data.Dictionary, Simulink.Signal, etc. APIs) to convert the parsed structure information into data dictionary objects that conform to the Simulink modeling specifications, and packages them into a shared data dictionary file named commonhead.sldd, serving as a unified data contract between the underlying driver and the application model. After opening any functional Simulink model (such as Diagnose.slx or Protect.slx), developers can add the generated commonhead.sldd file as the associated external data dictionary for the current model in the "Data Dictionary" configuration item of its model property settings interface. After binding, the Inport, Outport, Data Store Memory, or Bus modules inside the model can directly select the corresponding structure fields from this data dictionary as signal sources or targets, achieving semantic alignment between model variables and global variables in the COMMON layer. In the subsequent code generation stage, the Simulink Coder automatically maps the signals in the model to direct read and write operations on global structure variables declared with extern in the COMMON layer based on the preset storage class configuration (such as ImportedExtern) in the data dictionary. This ensures that the generated ASW layer code can share the same runtime data with the BSW layer without additional adaptation, achieving efficient, consistent, and glue-free cross-layer communication.

[0033] S3: In the Simulink model code generation configuration, set the input or output signals, uniformly modify the generation function name to the preset polling interface name, complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program.

[0034] Setting the input or output signals involves navigating to the C code generation > code interface > code mapping page in the model configuration parameters after the Simulink model has completed data dictionary binding, and selecting the signals for the Simulink model. This setting enables Simulink Coder to declare the variables corresponding to signals as extern type when generating code, instead of redefining them inside the generated code. The definition of extern type variables is located in commonhead.h and commonhead.c of the COMMON layer, ensuring that the generated code of the ASW layer and the underlying driver of the BSW layer access the same global structure variable, thus completing the data-level interoperability. The function is called by the main program. In the Simulink model's C code generation > Interface > Generated Function Name configuration item, the Simulink model execution function name is explicitly changed to the preset polling interface name corresponding to the functional module. At this point, it needs to be consistent with the function call statements reserved in the time slice scheduling logic in the main.c file in the Main module. After the code is generated, the Simulink Coder outputs the C function. The C function implementation is located in the ASW layer, and internally it reads and writes the global structure of the COMMON layer through the ImportedExtern variable. In the time-slice scheduling loop of main.c, the main program calls the polling interface function at a set period to complete the execution of the Main module.

[0035] Furthermore, after the Simulink model is bound to the commonhead.sldd data dictionary, navigate to the "C Code Generation > Code Interface > Code Mapping" page in the model configuration parameters. Set the StorageClass of the model's input and output signals to ImportedExtern, so that SimulinkCoder declares these variables in extern form when generating code. Their actual definitions are located in commonhead.h and commonhead.c in the COMMON layer, ensuring that the ASW layer and BSW layer access the same global structure variables. At the same time, in the "C Code Generation > Interface > Generated Function Name" configuration item, change the default execution function name to the preset polling interface name corresponding to the functional module (such as Diagnose_polling). This name must be consistent with the reserved call statement in the time-slice scheduling logic in main.c. After code generation, the C functions output by Simulink are located in the ASW layer, and internally read and write the global structure of the COMMON layer directly through the ImportedExtern variable. In the time-slice scheduling loop of main.c, the main program directly calls these polling interface functions according to the set period to complete the periodic execution of each ASW module.

[0036] S4: In the time-slice scheduling loop of main.c, the main program calls the polling interface function at a set period to complete the execution of the Main module.

[0037] The polling interface function is called in the main.c file of the Main module. A time-slice scheduling loop based on hardware timer interrupt is predefined. The time-slice scheduling loop executes the polling interface function corresponding to each functional module in sequence according to a preset fixed period. The name of the polling interface function is explicitly configured during the Simulink model code generation phase and is consistent with the function call statement in the main.c file; The time-slice scheduling loop calls the corresponding C function located in the ASW layer in the form of function calls. The called polling interface function reads the shared interaction data between the BSW and ASW layers collected by the BSW layer through the global structure variable, thereby completing the periodic execution of the functional modules of each ASW layer under the unified scheduling of the Main module.

[0038] Furthermore, in the main.c file of the Main module, a time-slice scheduling loop based on hardware timer interrupts or system ticks is predefined. This loop sequentially calls the polling interface functions corresponding to each functional module according to a preset fixed period. The names of these polling interface functions have been explicitly specified as unified preset names (such as Diagnose_polling, Protect_polling, etc.) through configuration items during the Simulink model code generation stage, and are strictly consistent with the function call statements written in the scheduling logic in main.c. The time-slice scheduling loop executes the corresponding C functions located in the ASW layer in the form of direct function calls. The called polling interface functions access the underlying data collected by the BSW layer through the global structure variables defined in the COMMON layer, that is, the BSW-ASW layers share interactive data, thereby realizing the deterministic and periodic execution of each ASW layer functional module under the unified scheduling of the Main module.

[0039] S5: For the ert_rtw code directory generated by the functional model, call the corresponding cleanup script of the ert_rtw code directory, and put the cleanup script into the ASW layer position to complete the automated integration of the functional model into executable code.

[0040] The cleanup script that calls the corresponding ert_rtw code directory includes outputting a code directory with the suffix _ert_rtw after the Simulink model has completed code generation, and executing a Matlab cleanup script that matches the Simulink model name. The Matlab cleanup script refers to automatically locating and reading the generated files in the Diagnose_ert_rtw directory, filtering out the polling interface functions and related data structures generated by the user configuration, and eliminating redundant runtime support code. After removing redundant runtime support code and organizing it, it is automatically copied or moved to the corresponding functional subdirectory of the ASW layer in the software architecture; the Matlab cleanup script synchronously updates the project build configuration, enabling the main.c file to be linked during compilation, completing the end-to-end automated integration from the Simulink model to the ASW layer executable code that can be scheduled by the Main module without manual intervention.

[0041] Furthermore, after the Simulink model completes code generation, the system outputs a code directory with the suffix _ert_rtw (e.g., Diagnose_ert_rtw). Subsequently, a Matlab cleanup script matching the model name (e.g., PurifyCode_Diagnose.m) is executed. This script automatically locates and reads the generated files in the ert_rtw directory, including the main C file, header files, and type definition files. The script then filters out the polling interface functions (e.g., Diagnose_polling) generated by the user configuration and their dependent data structures, removing Simulink functions. The coder generates redundant runtime support code by default (such as rt_logging, model initialization / termination functions, rt_OneStep, and other non-essential content). The cleaned-up, streamlined code is automatically copied or moved to the subdirectory corresponding to the ASW layer in the software architecture (such as ASW / Diagnose / ). At the same time, the cleanup script updates the project build configuration file (such as makefile or IDE project list) to ensure that main.c can correctly identify and integrate the module during the compilation and linking phase. Thus, end-to-end automated integration from the Simulink model to the ASW layer executable code that can be directly scheduled by the Main module is completed without manual intervention.

[0042] Further refinement of step S3: The time-slice scheduling loop is included in the... The polling interface function of the first functional module, after startup, Execution time in the next scheduling cycle Satisfy the following formula: ; in, Indicates the scheduling start reference time. Indicates the preset main scheduling period. Indicates the first The estimated execution time cost of each functional module. Indicates the functional module number. Indicates the first The first functional module in the The execution time within the next scheduling cycle.

[0043] In a preferred embodiment, a method for combining underlying software and Simulink models and an MBD toolchain design system are provided. The system includes an architecture building module, which builds a lightweight structure at the software architecture level, generates a common header file data dictionary, and binds the common header file data dictionary to the data dictionary configuration of each functional Simulink model. The data dictionary generation and binding module runs scripts during the Simulink model development phase, reads files in the COMMON layer, generates a common header file data dictionary, and associates the common header file data dictionary with the data dictionary configuration of each functional Simulink model, enabling the Simulink model to directly reference the global structure variables defined in the COMMON layer. The code interface configuration module sets input or output signals in the Simulink model code generation configuration, uniformly modifies the generated function names to preset polling interface names, completes the cross-layer communication mechanism based on global structure variables, and the function is called by the main program; the scheduling and execution module reserves corresponding functional module polling interfaces in the main.c file and incorporates the functional module polling interfaces into the time slice scheduling logic to complete the periodic execution of each ASW layer; the automated integration module calls the corresponding ert_rtw code directory cleanup script for the ert_rtw code directory generated by the functional model, puts the cleanup script to the ASW layer location, and completes the automated integration of the functional model into executable code.

[0044] The above-mentioned unit modules can be embedded in the processor of the computer device in hardware form or independent of it, or they can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of the above modules.

[0045] In one embodiment, a computer device is provided, which may be a terminal. The computer device includes a processor, memory, a communication interface, a display screen, and an input device connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The communication interface of the computer device is used for wired or wireless communication with external terminals. Wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen of the computer device may be an LCD screen or an e-ink display screen. The input device of the computer device may be a touch layer covering the display screen, or buttons, a trackball, or a touchpad located on the casing of the computer device, or an external keyboard, touchpad, or mouse, etc.

[0046] In summary, this invention achieves seamless integration between the application layer and underlying software without the need for commercial AUTOSAR RTE support by constructing a lightweight software architecture comprising an ASW layer, BSW layer, COMMON layer, RTE layer, and Main module. This is achieved by combining automated scripts to generate a common header file data dictionary and binding it to the Simulink model. By configuring model input / output signals as ImportedExtern type and uniformly generating preset polling interface function names, Simulink-generated code can directly read and write global structure variables defined in the COMMON layer, avoiding the need for manually writing glue code or custom middleware. Simultaneously, the Main module directly calls each polling interface function based on a timer's time-slice scheduling mechanism, ensuring the periodic and deterministic execution of functional modules. Combined with automated cleanup and integration scripts for the ert_rtw code directory, the deployment process from model to executable code is significantly simplified. The overall solution significantly reduces the development threshold and cost of MBD for small ECUs, improves development efficiency, code reusability, and iteration speed, while maintaining good reliability and maintainability.

[0047] Reference Figure 3 and Figure 4 After introducing the method and system of exemplary embodiments of the present invention, the following references are made. Figure 3 A computer-readable storage medium according to exemplary embodiments of the present invention will be described, please refer to... Figure 3The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it implements the steps described in the above method implementation, such as building a lightweight structure at the software architecture level, generating a common header file data dictionary, and binding the common header file data dictionary to the data dictionary configuration of each functional Simulink model; during the Simulink model development stage, running scripts, reading files in the COMMON layer, generating a common header file data dictionary, and associating the common header file data dictionary to the data dictionary configuration of each functional Simulink model, so that the Simulink model can directly reference C. The OMMON layer defines global structure variables; in the Simulink model's code generation configuration, input or output signals are set, and the generated function names are uniformly modified to the preset polling interface names to complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program; the corresponding functional module polling interface is reserved in the main.c file, and the functional module polling interface is incorporated into the time-slice scheduling logic to complete the periodic execution of each ASW layer; for the ert_rtw code directory generated by the functional model, the corresponding ert_rtw code directory's cleanup script is called, and the cleanup script is placed at the ASW layer location to complete the automated integration of the functional model into executable code. The specific implementation methods of each step will not be repeated here.

[0048] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0049] After introducing the methods and media of exemplary embodiments of the present invention, the following references are made. Figure 4 A computational device for adaptive recovery of low-voltage power grid self-healing control according to an exemplary embodiment of the present invention.

[0050] Figure 4 A block diagram is shown of an exemplary computing device 40 suitable for implementing embodiments of the present invention. The computing device 40 may be a computer system or a server. Figure 4 The computing device 40 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0051] like Figure 4As shown, the components of computing device 40 may include, but are not limited to: one or more processors or processing units 401, system memory 402, and bus 403 connecting different system components (including system memory 402 and processing unit 401).

[0052] The computing device 40 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computing device 40, including volatile and non-volatile media, and removable and non-removable media.

[0053] System memory 402 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 4021 and / or cache memory 4022. Computing device 40 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, ROM 4023 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 4 (Not shown in the image, usually referred to as "hard drive"). Although not shown in... Figure 4 The diagram illustrates that disk drives for reading and writing to removable non-volatile disks (e.g., "floppy disks") and optical disc drives for reading and writing to removable non-volatile optical discs (e.g., CD-ROMs, DVD-ROMs, or other optical media) can be provided. In these cases, each drive can be connected to bus 403 via one or more data media interfaces. System memory 402 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0054] A program / utility 4025 having a set (at least one) of program modules 4024 may be stored, for example, in system memory 402, and such program modules 4024 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment. Program modules 4024 typically perform the functions and / or methods described in the embodiments of the present invention.

[0055] The computing device 40 can also communicate with one or more external devices 404 (such as a keyboard, pointing device, display, etc.). This communication can be performed via the input / output (I / O) interface 405. Furthermore, the computing device 40 can also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 406. Figure 4 As shown, network adapter 406 communicates with other modules of computing device 40 (such as processing unit 401) via bus 403. It should be understood that, although... Figure 4 As not shown, it can be used in conjunction with computing device 40 with other hardware and / or software modules.

[0056] The processing unit 401 executes various functional applications and data processing by running programs stored in the system memory 402. For example, at the software architecture level, it builds a lightweight structure, generates a common header file data dictionary, and binds the common header file data dictionary to the data dictionary configuration of each functional Simulink model. During the Simulink model development phase, it runs scripts, reads files in the COMMON layer, generates a common header file data dictionary, and associates the common header file data dictionary with the data dictionary configuration of each functional Simulink model, enabling the Simulink model to directly reference the global structures defined in the COMMON layer. In the Simulink model code generation configuration, input or output signals are set, and the generated function names are uniformly modified to the preset polling interface names to complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program; the corresponding functional module polling interface is reserved in the main.c file, and the functional module polling interface is incorporated into the time slice scheduling logic to complete the periodic execution of each ASW layer; for the ert_rtw code directory generated by the functional model, the corresponding ert_rtw code directory cleanup script is called, and the cleanup script is placed at the ASW layer location to complete the automated integration of the functional model into executable code.

[0057] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0058] In the several embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0059] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0060] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0061] If the functionality is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0062] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0063] Furthermore, although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

Claims

1. A method for combining underlying software and Simulink models, and a method for designing the MBD toolchain, characterized in that: include, At the software architecture level, a lightweight structure is built, a common header file data dictionary is generated, and the common header file data dictionary is bound to the data dictionary configuration of each functional Simulink model; During the Simulink model development phase, the script is run to read the files in the COMMON layer, generate a common header file data dictionary, and associate the common header file data dictionary with the data dictionary configuration of each functional Simulink model, so that the Simulink model can directly reference the global structure variables defined in the COMMON layer. In the Simulink model code generation configuration, the input or output signals are set, and the generation function name is uniformly modified to the preset polling interface name to complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program; Reserve the corresponding functional module polling interface in the main.c file, and incorporate the functional module polling interface into the time slice scheduling logic to complete the periodic execution of each ASW layer; For the ert_rtw code directory generated by the functional model, the corresponding cleanup script for the ert_rtw code directory is called, and the cleanup script is placed at the ASW layer location to complete the automated integration of the functional model into executable code.

2. The method for combining underlying software and Simulink models and the MBD toolchain design method as described in claim 1, characterized in that: The lightweight structure includes an ASW layer, a BSW layer, a COMMON layer, an RTE layer, and a Main module; The ASW layer is used to integrate application layer code generated from the Simulink model, and the BSW layer is used to generate low-level driver code through the graphical configuration tool provided by the MCU manufacturer. The COMMON layer is used to uniformly store global structure variables shared by the BSW layer and the ASW layer; the RTE layer is used to encapsulate custom general functions; and the Main module is used to implement a time-slice scheduling mechanism based on a timer. The generation of the common header file data dictionary involves using files in the COMMON layer and automatically generating the common header file data dictionary by running a script, so that the Simulink model can reference the global structure variables defined in the COMMON layer during the code generation phase.

3. The method for combining underlying software and Simulink models and the MBD toolchain design method as described in claim 2, characterized in that: The process of reading files in the COMMON layer includes executing a Matlab script named Commonhead_sldd_make.m before starting the Simulink model development process. The Matlab script automatically locates and reads the commonhead.h and commonhead.c files in the COMMON layer directory of the software architecture and extracts the defined information of the common global structures. The Matlab script uses the data dictionary API provided by the Simulink model to convert the extracted structure information into a Simulink model data dictionary object that conforms to the Simulink model specification, and packages it to generate a shared data dictionary file commonhead.sldd as a unified data contract; The configuration of the data dictionary that associates the common header file data dictionary with each functional Simulink model includes enabling the Simulink model to reference the global structure variable defined in the COMMON layer. After opening the functional model, in the setting interface of the functional model's properties, the generated commonhead.sldd file is added as the associated data dictionary of the current functional model. After binding is complete, the modules within the functional model select the structure field defined in commonhead.sldd as the signal source or target; During the code generation phase, based on the data dictionary, the signals of the functional model are mapped to read and write operations on global structure variables declared in the COMMON layer.

4. The method for combining underlying software and Simulink models and the MBD toolchain design method as described in claim 3, characterized in that: Setting the input or output signals involves, after the Simulink model completes data dictionary binding, navigating to the C code generation > code interface > code mapping page in the model configuration parameters, and selecting the signals for the Simulink model. This setting enables Simulink Coder to declare the variables corresponding to signals as extern type when generating code, instead of redefining them inside the generated code. The definition of extern type variables is located in commonhead.h and commonhead.c of the COMMON layer, ensuring that the generated code of the ASW layer and the underlying driver of the BSW layer access the same global structure variable, thus completing the data-level interoperability. The function is called by the main program in the Simulink model's C code generation > interface > generated function name configuration item, which explicitly changes the Simulink model execution function name to the preset polling interface name corresponding to the functional module; At this point, it needs to be consistent with the function call statements reserved in the time slice scheduling logic in the main.c file in the Main module. After the code is generated, the Simulink Coder outputs the C function. The C function implementation is located in the ASW layer, and internally it reads and writes the global structure of the COMMON layer through the ImportedExtern variable. In the time-slice scheduling loop of main.c, the main program calls the polling interface function at a set period to complete the execution of the Main module.

5. The method for combining underlying software and Simulink models and the MBD toolchain design method as described in claim 4, characterized in that: The polling interface function is included in the main.c file of the Main module, which predefines a time-slice scheduling loop based on hardware timer interrupts. The time-slice scheduling loop executes the polling interface functions corresponding to each functional module in sequence according to a preset fixed period. The name of the polling interface function has been explicitly configured during the Simulink model code generation stage and is consistent with the function call statement in the main.c file; The time-slice scheduling loop calls the corresponding C function located in the ASW layer in the form of function calls. The called polling interface function reads the shared interaction data between the BSW and ASW layers collected by the BSW layer through the global structure variable, thereby completing the periodic execution of the functional modules of each ASW layer under the unified scheduling of the Main module.

6. The method for combining underlying software and Simulink models and the MBD toolchain design method as described in claim 5, characterized in that: The purification script that calls the corresponding ert_rtw code directory includes outputting a code directory with the suffix _ert_rtw after the Simulink model has completed code generation, and executing a Matlab purification script that matches the Simulink model name. The Matlab cleanup script refers to automatically locating and reading the generated files in the Diagnose_ert_rtw directory, filtering out the polling interface functions and related data structures generated by the user configuration, and eliminating redundant runtime support code. After removing redundant runtime support code and organizing it, it is automatically copied or moved to the corresponding functional subdirectory of the ASW layer in the software architecture; the Matlab cleanup script synchronously updates the project build configuration, enabling the main.c file to be linked during compilation, completing the end-to-end automated integration from the Simulink model to the ASW layer executable code that can be scheduled by the Main module without manual intervention.

7. The method for combining underlying software and Simulink models and the MBD toolchain design method as described in claim 6, characterized in that: The time-slice scheduling loop includes the first The polling interface function of the first functional module, after startup, Execution time in the next scheduling cycle Satisfy the following formula: ； in, Indicates the scheduling start reference time. Indicates the preset main scheduling period. Indicates the first The estimated execution time cost of each functional module. Indicates the functional module number. Indicates the first The first functional module in the The execution time within the next scheduling cycle.

8. A method for combining low-level software and Simulink models, and an MBD toolchain design system, based on the method for combining low-level software and Simulink models and the MBD toolchain design method according to any one of claims 1 to 7, characterized in that: include, The architecture building module constructs a lightweight structure at the software architecture level, generates a common header file data dictionary, and binds the common header file data dictionary to the data dictionary configuration of each functional Simulink model; The data dictionary generation and binding module runs scripts during the Simulink model development phase, reads files in the COMMON layer, generates a common header file data dictionary, and associates the common header file data dictionary with the data dictionary configuration of each functional Simulink model, enabling the Simulink model to directly reference the global structure variables defined in the COMMON layer. The code interface configuration module sets the input or output signals in the code generation configuration of the Simulink model, and uniformly modifies the name of the generated function to the preset polling interface name to complete the cross-layer communication mechanism based on global structure variables, and the function is called by the main program. The scheduling and execution module reserves the corresponding functional module polling interface in the main.c file and incorporates the functional module polling interface into the time slice scheduling logic to complete the periodic execution of each ASW layer; The automated integration module calls the corresponding cleanup script in the ert_rtw code directory generated by the functional model, and places the cleanup script in the ASW layer to complete the automated integration of the functional model into executable code.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the underlying software and Simulink model combination method and MBD toolchain design method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the underlying software and Simulink model combination method and MBD toolchain design method as described in any one of claims 1 to 7.

Images