A Simulink-based automated AUTOSAR code generation method

Abstract

The application provides a Simulink-based automatic AUTOSAR code generation method, relates to the technical field of automobile electronic control unit (ECU) software development, and comprises the following steps: model identification and engineering model construction, automatically identifying and determining a unique Simulink original model to be processed, and generating an independent engineering model; standardized parameter configuration, automatically configuring a parameter set specially used for AUTOSAR code generation for the engineering model; AUTOSAR architecture automatic mapping, automatically creating an AUTOSAR software component architecture corresponding to the standardized configuration model and establishing an interface mapping relationship; code generation and quality guarantee, automatically generating codes and ARXML files conforming to the AUTOSAR standard based on the mapping relationship, and performing quality detection and packaging output. The application realizes full-process automation from model identification to code packaging, eliminates the tediousness and inconsistency of manual operation, effectively prevents the problem of ECU computing performance decline by using a built-in double type detection mechanism, and significantly improves the development efficiency and code quality.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control unit (ECU) software development technology, specifically to a Simulink-based automated AUTOSAR (AUTomotive Open System Architecture) code generation method. Background Technology

[0002] In automotive ECU (Electronic Control Unit) software development, the Simulink model is the primary carrier of control algorithms. As automotive electronic systems become increasingly complex, the AUTOSAR (AUTomotive Open System Architecture) standard has become an industry-standard software architecture specification, requiring the conversion of control algorithms from Simulink models into AUTOSAR-compliant C language code and ARXML (AUTOSAR XML) description files.

[0003] Traditional code generation processes require multiple complex steps performed manually, including model renaming, interface configuration, parameter setting, AUTOSAR environment setup, code generation, and final result packaging. This manual process suffers from the following prominent problems: cumbersome steps, high human intervention, and low efficiency; a complete code generation process typically requires several hours of manual operation; differences in configuration habits and skill levels among developers lead to inconsistencies in the performance, style, and quality of the generated code; precision errors are prone to occur, such as misuse of the double type causing a significant decrease in ECU calculation performance; file management is chaotic, version tracking is difficult, and it hinders team collaboration and project maintenance.

[0004] Therefore, there is an urgent need for a Simulink code generation method that can automatically execute model recognition, parameter configuration, architecture mapping, code generation and quality verification in an integrated manner, in order to eliminate the tedium and inconsistency of manual operation and improve development efficiency and code quality. Summary of the Invention

[0005] In view of the technical defects and drawbacks existing in the prior art, embodiments of the present invention provide an automated AUTOSAR code generation method based on Simulink to overcome the above problems or at least partially solve the above problems, the specific solution of which is as follows;

[0006] As a first aspect of the present invention, an automated AUTOSAR code generation method based on Simulink is provided, comprising the following steps:

[0007] Model identification and engineering model construction: Automatically identify and determine the unique Simulink original model to be processed, and generate an independent engineering model for subsequent automated processing based on the complete interface and structure of the original model;

[0008] Standardized parameter configuration: Automatically configure a predefined set of parameters specifically for AUTOSAR code generation for the engineering model. The parameter set includes at least the solver type, system target file, and default data type to form a standardized configuration model.

[0009] Automatic AUTOSAR architecture mapping: Based on the standardized configuration model, automatically create the corresponding AUTOSAR software component architecture, and automatically establish the mapping relationship between the signal ports in the standardized configuration model and the runtime and events in the AUTOSAR software component architecture;

[0010] Code generation and quality assurance: Based on the established mapping relationship, the code generator is automatically invoked to generate C language code and ARXML description files that conform to the AUTOSAR standard; then, the generated code is automatically tested for quality, and after passing the test, intermediate files are automatically cleaned up and the final product is packaged into a single deliverable.

[0011] In some embodiments, the model identification and engineering model construction steps include:

[0012] Scan the current working directory to get a list of all Simulink model files;

[0013] Verify the number of files in the model file list; if the number is not 1, terminate the execution and issue a prompt; if the number is 1, identify the unique model file as the original model.

[0014] Based on the original model, a new blank Simulink model is automatically created as the target engineering model, and its top-level subsystem and all its input ports, output ports and trigger ports are automatically extracted and copied from the original model to the target engineering model.

[0015] In the target engineering model, signal connections between the input ports, output ports and the top-level subsystem are automatically established to restore the data flow structure of the original model, thereby generating a structurally complete and functionally equivalent engineering model.

[0016] In some embodiments, before extracting and replicating its top-level subsystem from the original model, the following steps are also included:

[0017] The original model file is renamed, and the current timestamp is added to the end of its filename to generate a backup file with a timestamp.

[0018] The backup file is saved in the original directory where the original model is located to prevent irreversible modifications or data loss to the original model during subsequent automated operations.

[0019] In some embodiments, the set of automatically configured parameters includes at least the following types of configuration items:

[0020] The first category, solver and simulation configuration, is used to ensure the real-time running characteristics of the code. Specifically, it includes setting the solver type to fixed step size and selecting the solver as discrete solution mode.

[0021] The second category is code generation target configuration, which is used to specify the architectural standard for generated code. Specifically, it includes specifying the system target file as the AUTOSAR-specific target template file autoSar.tlc.

[0022] The third category, data types and optimization configurations, is used to improve code execution efficiency and security. Specifically, it includes setting the default unspecified data type to a single-precision floating-point type and enabling code optimization options.

[0023] The fourth category, traceability configuration, is used to enhance the readability and maintainability of generated code. Specifically, it includes enabling code generation reporting to generate ASAP2 calibration files, code metric reports, and code replacement reports, as well as enabling custom annotation to embed tracing information in the code.

[0024] In some embodiments, the process of automatically creating an AUTOSAR software component architecture includes the following steps in a hierarchical order from macro to micro:

[0025] Component layer creation: Automatically generate an AUTOSAR software component as a container to carry the functions of the standardized configuration model, and at the same time generate an abstract behavior description framework for the software component;

[0026] Runtime layer creation: Within the software component generated in the component layer creation step, at least two runtime entities are automatically created according to the functional requirements of the standardized configuration model, namely the initialization runtime and the periodic runtime, to encapsulate different execution stages of the model;

[0027] Event layer binding: For each runtime created in the runtime layer creation step, a corresponding AUTOSAR scheduling event is automatically created and bound, wherein the initialization runtime is bound to an initialization event, and the periodic runtime is bound to a periodic trigger event, so as to establish a scheduling trigger mechanism for the runtime;

[0028] Export configuration layer settings: Based on the preset AUTOSAR standard and the target controller platform specifications, automatically configure the ARXML file attributes of the software components during export, including setting the export directory of the ARXML file, defining the hierarchical path of the data structure package, and specifying the packaging mode as single file output mode.

[0029] In some embodiments, the initialization runtime and periodic runtime created in the runtime layer creation step, as well as the events bound in the event layer binding step, are all automatically named according to a preset unified naming rule to achieve a unique correspondence between runtimes, events, and the original model, specifically including:

[0030] The initialization runtime is automatically named Runnable_<model name>_Init, and the initialization event bound to it is automatically named Event_<model name>_Init;

[0031] The periodic running body is automatically named Runnable_<model name>_Step, and the periodic triggering event bound to it is automatically named Event_<model name>_Step;

[0032] Wherein, <model name> is the name of the original model determined in the model identification and engineering model construction steps.

[0033] In some embodiments, the quality inspection in the code generation and quality assurance steps specifically includes:

[0034] Code scanning: Traverse all generated C source code files, read the file content line by line, and use preset regular expression patterns to match any of the following double-precision floating-point type identifiers within non-commented areas:

[0035] The keywords are float64 or real64_T;

[0036] Floating-point constants expressed in scientific notation and with a precision exceeding the range of single-precision floating-point;

[0037] Detection and Judgment: If any double-precision floating-point type identifier is matched in any C source code file, the quality detection result is determined to be unqualified, and the subsequent packaging process is immediately stopped. At the same time, an error log is output to the console and a graphical warning box pops up to notify the user that there is a precision risk in the code. If no double-precision floating-point type identifier is matched in any C source code file, the quality detection result is determined to be qualified, and the packaging step in the code generation and quality assurance steps is automatically triggered.

[0038] In some embodiments, during the code scanning process of the code scanning step, in order to improve detection accuracy and avoid the risk of misjudging double-precision floating-point type-related strings in comment text as precision in actual code, the following comment exclusion mechanism is specifically adopted:

[0039] When reading C source code files line by line, a comment status flag is maintained in real time to track whether the current reading position is within the block comment area defined by the comment start character / * and the comment end character * / .

[0040] When the comment status flag indicates that the current line content is within a block comment area, the matching operation of the regular expression pattern is skipped for that line content, and it is not detected.

[0041] When the comment status flag indicates that the current line content is outside the block comment area, the regular expression pattern matching operation is performed normally on the line content.

[0042] In some embodiments, in the code generation and quality assurance step, after passing quality inspection, packaging the final product into a single deliverable includes:

[0043] Intermediate file cleanup: Delete temporary and intermediate files generated during code generation, specifically Simulink cache files with the .Slxc extension and MATLAB autosave files with the .aSv extension, to reduce redundant data;

[0044] Compression and Packaging: Take the code generation folder containing all generated C source code files, header files, and ARXML description files, i.e., the folder named <model name>_autoSar_rtw, as the packaging object, and use a compression tool to compress it into a ZIP format compressed file;

[0045] The compressed file is named according to a preset naming convention, with the format <model name>_autoSar_<timestamp>.zip. The timestamp is the current date when the packaging operation is performed, so as to realize the unique identification and version traceability of the output product.

[0046] In some embodiments, the set of parameters automatically configured in the standardized parameter configuration step further includes a fifth category, safety and diagnostic configuration, used to capture potential programming errors and data anomalies during code generation. According to the type of risk monitored, this specifically includes the following sub-classes of configuration:

[0047] The first subclass, data flow integrity detection configuration: set the diagnostic response level of integer overflow detection, integer saturation detection, read-before-write detection, write-after-write detection, continuous write detection, and multi-task data storage conflict detection to the error level to ensure the consistency and integrity of data during the read and write process;

[0048] The second subclass, Signal and Bus Compliance Detection Configuration: Sets the diagnostic response level for mandatory checks of non-bus signals and detection of signals that are not numerical (NaN) or infinite (Inf) to the error level to ensure the validity of signal data types and numerical ranges.

[0049] The third subclass, State Machine Security Detection Configuration: Sets the diagnostic response level for illegal data access detection, state transition overstepping detection, and undirected broadcast event detection to the error level to ensure the correctness and security of the Stateflow state machine's execution logic.

[0050] The fourth subclass, Resource Uniqueness Detection Configuration: Sets the diagnostic response level for data storage uniqueness detection to the error level to ensure the uniqueness of data storage resources in the model and avoid naming conflicts.

[0051] The present invention has the following beneficial effects:

[0052] This invention provides an automated AUTOSAR code generation method based on Simulink. By integrating dozens of scattered operations that previously required manual execution by engineers into a single, automated pipeline—including model preparation, unified configuration, architecture mapping, code generation, and verification—this method streamlines the process into a single, one-click workflow. For example, in traditional workflows, engineers need to manually create the engineering model, configure solver parameters item by item, create AUTOSAR components and runtimes one by one, manually map interfaces, run the code generator separately, and then manually check code quality and package the output. This entire process takes several hours and is highly error-prone. This method, however, links all these steps into an automated chain. Engineers only need to provide a Simulink model file and start the script to obtain a complete AUTOSAR-compliant code package within minutes, significantly shortening the development cycle, reducing labor costs, and eliminating inconsistencies introduced by manual operations. Attached Figure Description

[0053] Figure 1 A flowchart illustrating an automated AUTOSAR code generation method based on Simulink, provided for an embodiment of the present invention;

[0054] Figure 2 A schematic diagram illustrating the process of model recognition and engineering model construction provided in an embodiment of the present invention;

[0055] Figure 3 A schematic diagram illustrating the process of automatic mapping of the AUTOSAR architecture provided in an embodiment of the present invention;

[0056] Figure 4 A schematic diagram of the code quality detection process provided in an embodiment of the present invention;

[0057] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0058] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention 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 the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0059] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

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

[0061] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, 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.

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

[0063] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0064] To address at least one of the technical problems existing in the aforementioned related technologies, this invention provides an automated AUTOSAR code generation method based on Simulink. Figure 1 This is a flowchart illustrating an automated AUTOSAR code generation method based on Simulink, provided in an embodiment of the present invention. The method includes:

[0065] Step S1, Model Identification and Engineering Model Construction: Automatically identify and determine the unique Simulink original model to be processed, and generate an independent engineering model for subsequent automated processing based on the complete interface and structure of the original model;

[0066] Step S2, Standardized parameter configuration: Automatically configure a predefined set of parameters specifically for AUTOSAR code generation for the engineering model. The parameter set includes at least the solver type, system target file, and default data type to form a standardized configuration model.

[0067] Step S3, Automatic AUTOSAR Architecture Mapping: Based on the standardized configuration model, automatically create the corresponding AUTOSAR software component architecture, and automatically establish the mapping relationship between the signal ports in the standardized configuration model and the runtime and events in the AUTOSAR software component architecture;

[0068] Step S4, Code Generation and Quality Assurance: Based on the established mapping relationship, the code generator is automatically invoked to generate C language code and ARXML description files that conform to the AUTOSAR standard; subsequently, the generated code is subjected to automated quality checks, and after passing the checks, intermediate files are automatically cleaned up and the final product is packaged into a single deliverable.

[0069] This invention provides an automated AUTOSAR code generation method based on Simulink. By integrating dozens of scattered operations that previously required manual execution by engineers into a single, automated pipeline—including model preparation, unified configuration, architecture mapping, code generation, and verification—this method streamlines the process into a single, one-click workflow. For example, in traditional workflows, engineers need to manually create the engineering model, configure solver parameters item by item, create AUTOSAR components and runtimes one by one, manually map interfaces, run the code generator separately, and then manually check code quality and package the output. This entire process takes several hours and is highly prone to errors. This method, however, links all these steps into an automated chain. Engineers only need to provide a Simulink model file and start the script to obtain a complete AUTOSAR-compliant code package within minutes, significantly shortening the development cycle, reducing labor costs, and eliminating inconsistencies introduced by manual operations.

[0070] refer to Figure 2 As shown, in some embodiments, step S1 includes:

[0071] Step S1a: Scan the current working directory to obtain a list of all Simulink model files;

[0072] Step S1b: Verify the number of files in the model file list; if the number is not 1, terminate the execution and issue a prompt; if the number is 1, determine the unique model file as the original model.

[0073] Step S1c: Based on the original model, automatically create a new blank Simulink model as the target engineering model, and automatically extract and copy its top-level subsystem and all its input ports, output ports and trigger ports from the original model to the target engineering model;

[0074] In step S1d, signal connections between the input port, output port and top-level subsystem are automatically established in the target engineering model to restore the data flow structure of the original model, thereby generating a structurally complete and functionally equivalent engineering model.

[0075] The above embodiments, by introducing uniqueness verification and structured copying mechanisms during the model identification phase, ensure the input accuracy and model structure integrity of the automated process, effectively preventing compilation failures caused by multiple model conflicts or empty directories. Specifically, the method first scans the current directory and verifies the number of model files. It only continues execution if a unique model file exists; otherwise, it terminates immediately with a prompt. This fundamentally avoids erroneous compilation caused by misselecting models or directory chaos. For example, in large projects, multiple versions of model files (such as BrakeCtrl_v1.Slx, BrakeCtrl_v2.Slx, TeStModel.Slx) may exist simultaneously in a working directory. Without uniqueness verification, the script might incorrectly select a non-target model, resulting in generated code that does not meet actual requirements. Furthermore, when copying the model, this method not only copies the top-level subsystem but also all input ports, output ports, and trigger ports, and automatically reconstructs signal connections, ensuring that the newly generated engineering model is structurally and functionally completely equivalent to the original model. This lays a solid model foundation for subsequent automated configuration and code generation.

[0076] In some embodiments, before extracting and copying the top-level subsystem from the original model in step S1c, the method further includes:

[0077] The original model file is renamed, and the current timestamp is added to the end of its filename to generate a backup file with a timestamp.

[0078] The backup file is saved in the original directory where the original model is located to prevent irreversible modifications or data loss to the original model during subsequent automated operations.

[0079] The above embodiments provide data security for the entire automation process by automatically backing up the original model before the model copying operation, effectively preventing damage or loss of the original model due to accidental operations. Specifically, before making any modifications to the original model, the method first renames the original model file and adds the current timestamp, generating an independent backup file saved in the original directory. For example, assuming the original model file name is BrakeCtrl.Slx, before performing the copy operation, the system will automatically back it up as BrakeCtrl_20260617.Slx, and then create a new project model based on the original model. In this way, even if unexpected events occur during the subsequent automation process (such as script errors, system crashes, disk write failures, etc.), engineers can still restore the original, unmodified model from the backup file without having to rebuild or retrieve it from the version control system. This mechanism is particularly suitable for mature models that have undergone long-term iterative optimization and contain a large number of debugging parameters and test cases. Its value far exceeds the scope covered by a simple "undo" operation, providing strong protection for the reliability and fault tolerance of the automation process.

[0080] In some embodiments, the set of parameters automatically configured in step S2 includes at least the following types of configuration items:

[0081] The first category, solver and simulation configuration, is used to ensure the real-time running characteristics of the code. Specifically, it includes setting the solver type to fixed step size and selecting the solver as discrete solution mode.

[0082] The second category is code generation target configuration, which is used to specify the architectural standard for generated code. Specifically, it includes specifying the system target file as the AUTOSAR-specific target template file autoSar.tlc.

[0083] The third category, data types and optimization configurations, is used to improve code execution efficiency and security. Specifically, it includes setting the default unspecified data type to a single-precision floating-point type and enabling code optimization options.

[0084] The fourth category, traceability configuration, is used to enhance the readability and maintainability of generated code. Specifically, it includes enabling code generation reporting to generate ASAP2 calibration files, code metric reports, and code replacement reports, as well as enabling custom annotation to embed tracing information in the code.

[0085] The above embodiments ensure high consistency in performance and format of generated code across all projects by unifying solver, code generation target, data type, and traceability configuration into a standardized parameter set, eliminating the problem of inconsistent code quality caused by differences in individual engineer configurations. Specifically, this method enforces a fixed-step-size discrete solver, guaranteeing the determinism and predictability of the generated code in embedded real-time environments; it uniformly specifies the system target file as autoSar.tlc, ensuring all code strictly adheres to the AUTOSAR architecture standard; and it unifies the default data type to single-precision floating-point, avoiding performance degradation in ECU calculations due to misuse of the double type. For example, in traditional workflows, engineer A might habitually use a variable-step-size solver, engineer B might forget to enable code optimization options, and engineer C might use the double type without realizing it. These differences can lead to the same algorithm generating code with drastically different performance in different engineers' hands. This method, through one-click standardized configuration, ensures that regardless of who operates it or in which project it is executed, the generated code has the same real-time performance, memory usage, and coding style, greatly improving team collaboration efficiency and code maintainability.

[0086] refer to Figure 3 As shown, in some embodiments, the process of automatically creating the AUTOSAR software component architecture in step S3 includes the following steps in a hierarchical order from macro to micro:

[0087] Step S3a, Component layer creation: Automatically generate an AUTOSAR software component as a container to carry the functions of the standardized configuration model, and at the same time generate an abstract behavior description framework for the software component.

[0088] Step S3b, Runtime layer creation: Within the software component generated in step S3a, at least two runtime entities are automatically created according to the functional requirements of the standardized configuration model, namely the initialization runtime and the periodic runtime, which are used to encapsulate different execution stages of the model;

[0089] Step S3c, Event layer binding: For each run created in step S3b, a corresponding AUTOSAR scheduling event is automatically created and bound, wherein the initialization run is bound to an initialization event, and the periodic run is bound to a periodic trigger event, so as to establish a scheduling trigger mechanism for the run;

[0090] Step S3d, Export Configuration Layer Settings: Based on the preset AUTOSAR standard and the target controller platform specifications, automatically configure the ARXML file attributes of the software component during export, including setting the export directory of the ARXML file, defining the hierarchical path of the data structure package, and specifying the packaging mode as single file output mode.

[0091] The above embodiments automatically create a complete AUTOSAR software component architecture by following the hierarchical order of "component layer → runtime layer → event layer → export configuration layer," completely automating the manual configuration process that originally required deep AUTOSAR expertise, significantly reducing the skill threshold for engineers. Specifically, this method first automatically generates an AUTOSAR software component as a functional container, then automatically creates initialization runtimes and periodic runtimes within it, then automatically binds corresponding scheduling events to each runtime, and finally automatically configures the export directory, data structure package path, and packaging mode of the ARXML file. For example, in the traditional process, engineers need to manually create SWCs in the AUTOSAR Authoring Tool, manually add Runnables, manually configure TimingEvents, and manually set the package structure and export path of ARXML. This process is not only time-consuming (usually more than 30 minutes), but also prone to errors that could lead to subsequent code generation failures or ARXML files that do not conform to OEM standards. This method encapsulates all these operations into automated scripts. Engineers do not need to understand the underlying details of AUTOSAR configuration; they can obtain a complete and compliant AUTOSAR architecture description file with just one click, significantly improving development efficiency and configuration accuracy.

[0092] In some embodiments, the initialization run body and periodic run body created in step S3b, as well as the events bound in step S3c, are all automatically named according to a preset unified naming rule to achieve a unique correspondence between the run body, events, and the original model, specifically including:

[0093] The initialization runtime is automatically named Runnable_<model name>_Init, and the initialization event bound to it is automatically named Event_<model name>_Init;

[0094] The periodic running body is automatically named Runnable_<model name>_Step, and the periodic triggering event bound to it is automatically named Event_<model name>_Step;

[0095] Wherein, <model name> is the name of the original model determined in step S1.

[0096] The above embodiments ensure the uniqueness and identifiability of the names of each element in the AUTOSAR architecture by establishing a unified and traceable automatic naming rule for runtimes and events, greatly facilitating code management and troubleshooting in large projects. Specifically, this method automatically names the initialization runtime as Runnable_<model name>_Init, the periodic runtime as Runnable_<model name>_Step, and the corresponding events as Event_<model name>_Init and Event_<model name>_Step, respectively. For example, in a large automotive electronics project containing multiple ECUs, there may be dozens or even hundreds of Simulink models, each generating its own runtimes and events. Without a unified naming rule, engineers might need to open ARXML files one by one during debugging to determine which model a particular runtime belongs to, which is extremely inconvenient. By using the naming rules in this claim, engineers can intuitively determine the nature of the code simply by its name: Runnable_BrakeCtrl_Step clearly belongs to the periodic operation of the braking control model, and Event_MotorCtrl_Init is clearly the initialization event of the motor control model. This naming method not only improves the readability of the code, but also facilitates automated testing, integration verification, and problem tracing, effectively reducing the maintenance complexity of large projects.

[0097] refer to Figure 4 As shown, in some embodiments, the quality inspection in step S4 specifically includes:

[0098] Step S4a, Code Scanning: Traverse all generated C source code files, read the file content line by line, and use a preset regular expression pattern to match any of the following double-precision floating-point type identifiers in non-comment areas:

[0099] The keywords are float64 or real64_T;

[0100] Floating-point constants expressed in scientific notation and with a precision exceeding the range of single-precision floating-point;

[0101] Step S4b, Detection and Judgment: If any double-precision floating-point type identifier described in step S4a is matched in any C source code file, the quality detection result is determined to be unqualified, and the subsequent packaging process is immediately stopped. At the same time, an error log is output to the console and a graphical warning box pops up to notify the user that there is a precision risk in the code. If no double-precision floating-point type identifier is matched in any C source code file, the quality detection result is determined to be qualified, and the packaging step in step S4 is automatically triggered.

[0102] The above embodiments effectively prevent ECU computational performance degradation caused by data type misuse by automatically performing a special check for double-precision floating-point types after code generation, providing automated assurance for the quality and reliability of generated code. Specifically, this method traverses all generated C source code files, using regular expressions to precisely match float64, real64_T, and scientific notation floating-point constants exceeding the single-precision range in non-commented areas. Once detected, it is judged as quality unqualified and packaging is stopped. For example, in traditional development processes, engineers may unintentionally use a double-type constant or signal in a Simulink model, but due to the large size of the model and the numerous signals, it is difficult to detect manually. If the generated code contains a double-type variable, it will trigger software simulation of double-precision operations when running on a low-cost ECU with only a single-precision floating-point arithmetic unit, causing the calculation speed to drop by several times or even tens of times, seriously affecting the real-time performance of the control algorithm. This method automatically intercepts such problems immediately after code generation and provides clear error messages, enabling engineers to correct data type errors in the model as soon as possible, avoiding the delivery of defective code to subsequent integration testing or mass production stages, significantly improving code quality and development efficiency.

[0103] In some embodiments, during the code scanning process of step S4a, in order to improve detection accuracy and avoid the risk of misjudging double-precision floating-point type-related strings in comment text as precision in actual code, the following comment exclusion mechanism is specifically adopted:

[0104] When reading C source code files line by line, a comment status flag is maintained in real time to track whether the current reading position is within the block comment area defined by the comment start character / * and the comment end character * / .

[0105] When the comment status flag indicates that the current line content is within a block comment area, the matching operation of the regular expression pattern is skipped for that line content, and it is not detected.

[0106] When the comment status flag indicates that the current line content is outside the block comment area, the regular expression pattern matching operation is performed normally on the line content.

[0107] The above embodiments effectively avoid misjudgments caused by example code or explanatory text in comment areas by automatically excluding content in the comment area during double-precision floating-point type detection, significantly improving the accuracy and reliability of the detection results. Specifically, when scanning the C source code file line by line, the method maintains a comment status flag in real time to track whether the current reading position is within the block comment area defined by / * and * / . When it is within the comment area, the regular expression matching is skipped; otherwise, the matching is performed normally. For example, in the generated code, the developer might write the following explanatory text in the comment: "Note: float64 type should be used here to improve precision, but Single is temporarily used instead." Without the comment exclusion mechanism, the detection script would misjudge the float64 in the comment as the actual double type used in the code, thus incorrectly aborting the packaging process and causing engineers to spend a lot of time troubleshooting a non-existent "problem." However, through the comment exclusion mechanism of this claim, the detection script can intelligently distinguish between "actual usage in the code" and "textual mention in the comments," only detecting the actual code content, thereby ensuring the accuracy and reliability of the detection results and avoiding invalid alarms and rework.

[0108] In some embodiments, in step S4, after passing the quality inspection, packaging the final product into a single deliverable includes:

[0109] Step S4c, intermediate file cleanup: Delete temporary and intermediate files generated during code generation, specifically including Simulink cache files with the extension .Slxc and MATLAB autosave files with the extension .aSv, to reduce redundant data;

[0110] Step S4d, Compression and Packaging: Take the code generation folder containing all generated C source code files, header files, and ARXML description files, i.e., the folder named <model name>_autoSar_rtw, as the packaging object, and use a compression tool to compress it into a ZIP format compressed package file;

[0111] The compressed file is named according to a preset naming convention, with the format <model name>_autoSar_<timestamp>.zip. The timestamp is the current date when the packaging operation is performed, so as to realize the unique identification and version traceability of the output product.

[0112] The above embodiments, through a sequential operation of first cleaning intermediate files and then compressing and packaging, combined with standardized naming rules, ensure the cleanliness, integrity, and traceability of the final deliverables, facilitating subsequent version management and integration deployment. Specifically, this method first removes redundant data such as .Slxc cache files and .aSv autosave files generated during code generation. Then, it compresses the entire code generation folder named <model name>_autoSar_rtw into a compressed package in <model name>_autoSar_<timestamp>.zip format. For example, in a typical code generation process, Simulink generates multiple cache files (such as BrakeCtrl.Slxc) and autosave files (such as BrakeCtrl.aSv) in the working directory. These files are meaningless for the final code delivery. Packaging them directly without cleaning would increase transmission time and storage space, and might confuse the recipient about which are deliverables and which are temporary files. By cleaning before packaging, the final ZIP package contains only the necessary C source code, header files, and ARXML description files, resulting in a clean and concise package. Meanwhile, the naming rules embed model names and timestamps (such as BrakeCtrl_autoSar_20260617.zip), giving each deliverable a unique identifier, facilitating version tracking and multi-version comparison, and meeting the automotive industry's stringent requirements for deliverable management.

[0113] In some embodiments, prior to step S1, a safety verification step is further included to prevent the unintended activation of the automated process due to accidental operation, specifically including:

[0114] A confirmation dialog box will pop up through the graphical user interface, showing the user a summary of key information for this automation operation. The summary of key information includes at least: the identified original model file name, the total number of steps in the automation process to be executed, and a brief description of each step.

[0115] The confirmation dialog box provides two operation options: "Confirm Execution" and "Cancel Execution".

[0116] When the user clicks the "Confirm Execution" option, the system receives a confirmation command and then starts the automated process from steps S1 to S4.

[0117] When the user clicks the "Cancel Execution" option or closes the dialog box, the system terminates the operation and returns to the initial state.

[0118] The above embodiments provide a safety barrier for the entire automated operation by setting an interactive confirmation step before the automated process starts. This effectively prevents unexpected code generation processes from starting due to misoperation or incorrect model selection, avoiding waste of time and resources. Specifically, before step S1 is executed, a confirmation dialog box pops up, showing the user the identified original model file name, the total number of steps to be executed, and a brief description of each step, and providing two options: "Confirm Execution" and "Cancel Execution". For example, in real-world scenarios, engineers may have multiple project windows open simultaneously, or multiple versions of model files may remain in the working directory. The model automatically identified by the script may not be the one the engineer currently wants to process. Without a confirmation step, the script will directly start executing a series of time-consuming operations such as copying, configuration, and code generation. By the time the engineer discovers that the wrong model has been selected, several minutes may have already passed, resulting in a large amount of invalid work and wasted computing resources. However, with the confirmation dialog box of this claim, the engineer can immediately identify the problem after seeing the pop-up model name and click "Cancel Execution" to terminate the operation. The entire process takes only a few seconds, effectively avoiding major errors caused by negligence and significantly improving the usability and user experience of the automated process.

[0119] In some embodiments, the set of parameters automatically configured in step S2 further includes a fifth category, security and diagnostic configuration, used to capture potential programming errors and data anomalies during code generation. According to the type of risk monitored, this specifically includes the following sub-classes of configuration:

[0120] The first subclass, data flow integrity detection configuration: set the diagnostic response level of integer overflow detection, integer saturation detection, read-before-write detection, write-after-write detection, continuous write detection, and multi-task data storage conflict detection to the error level to ensure the consistency and integrity of data during the read and write process;

[0121] The second subclass, Signal and Bus Compliance Detection Configuration: Sets the diagnostic response level for mandatory checks of non-bus signals and detection of signals that are not numerical (NaN) or infinite (Inf) to the error level to ensure the validity of signal data types and numerical ranges.

[0122] The third subclass, State Machine Security Detection Configuration: Sets the diagnostic response level for illegal data access detection, state transition overstepping detection, and undirected broadcast event detection to the error level to ensure the correctness and security of the Stateflow state machine's execution logic.

[0123] The fourth subclass, Resource Uniqueness Detection Configuration: Sets the diagnostic response level for data storage uniqueness detection to the error level to ensure the uniqueness of data storage resources in the model and avoid naming conflicts.

[0124] The above embodiments systematically classify and uniformly set security and diagnostic configurations according to risk types, constructing a comprehensive quality defense line for the code generation process. This ensures that the generated code meets stringent industry standards in terms of data flow integrity, signal compliance, state machine security, and resource uniqueness. Specifically, this method sets detection of integer overflow, integer saturation, and read / write order conflicts as error-level checks, enabling the immediate capture of potential data consistency issues during the code generation phase. It also sets NaN / Inf detection and non-bus signal checks as error-level checks, ensuring that the numerical range and data type of signals remain valid. Furthermore, it sets detection of illegal data access, out-of-level transitions, and undirected broadcast events in the state machine as error-level checks, preventing runtime anomalies caused by state machine logic errors. Finally, it sets data storage uniqueness checks as error-level checks, avoiding resource contention caused by naming conflicts. For example, in traditional development, an engineer might accidentally create two Data Store Memory instances with the same name in the model. This error might not be detected during model simulation, but it can lead to accidental data overwriting after code generation, causing serious control logic errors. By configuring the code as described in this claim, such problems can be immediately captured and stopped during the code generation phase, preventing potentially fatally flawed code from being delivered to subsequent stages.

[0125] In some embodiments, the automatic code generation process in step S4 specifically includes the following sub-steps executed sequentially:

[0126] Step S4e, Interface Mapping Synchronization: Before executing code generation, the signal ports in the standardized configuration model are automatically compared and updated with the interface definitions of the AUTOSAR software component architecture established in step S3 to ensure that the mapping relationship between the two is completely consistent, so as to eliminate the risk of interface mismatch caused by model modification.

[0127] Step S4f, Top-level model construction: After the interface mapping synchronization is completed, the top-level model construction operation is forcibly executed, and the code generator specified by the system object file autoSar.tlc is called to generate complete project code containing C source code files, corresponding header files and ARXML description files;

[0128] Step S4g, Result Output and Archiving: Save the complete project code generated in step S4f to a dedicated folder named after the original model file name, which is named <model name>_autoSar_rtw. At the same time, output the success status of code generation and the time consumed by the entire build process to the console.

[0129] The above embodiment ensures the reliability of code generation and the traceability of results by breaking down the code generation process into three sequentially executed sub-steps: interface synchronization, model building, and result archiving. This effectively avoids generation failures or code errors caused by interface mismatches. Specifically, before officially generating the code, the method first automatically compares and updates the mapping relationship between the Simulink model signal ports and the AUTOSAR component interfaces to ensure complete consistency. Then, after confirming that the interface synchronization is correct, it calls the code generator specified by autoSar.tlc to force the top-level model building. Finally, it saves the generated complete project code to a dedicated folder named after the model and outputs the build status and time consumption information. For example, in actual development, engineers may modify the model's input and output ports after completing the AUTOSAR mapping, resulting in inconsistencies between the model and the AUTOSAR definition. Without the interface synchronization step, the code generator will generate code based on incorrect mapping relationships, causing function parameters in the generated C code to mismatch with the ARXML definition. This problem will only be exposed during subsequent integration and compilation, resulting in extremely high rework costs. Through the interface synchronization mechanism of this claim, such problems are automatically fixed or reported before code generation, ensuring that each generated code is based on the latest and correct mapping relationship, which greatly improves the success rate and reliability of code generation.

[0130] In some embodiments, during the automated process execution of steps S1 to S4, a hierarchical log and prompt information output step is further included to provide real-time feedback to the user on the execution status of each stage, specifically including:

[0131] Level 1, Progress Indication: At the start of each stage, the name of the stage and a start prompt message are output to the console, for example, in the format "Start Execution: [Stage Name]";

[0132] Level 2, Success Confirmation: After each stage is successfully completed, the completion confirmation information for that stage will be output to the console, for example, in the format "[Stage Name] Execution Completed";

[0133] Level 3, Error Alarm: When an error or abnormal situation is detected, an error warning message marked in red is output to the console, and an error message dialog box pops up through the graphical user interface, which includes the error description and the reason for termination.

[0134] Level 4, Final Result Notification: After the entire automated process is successfully completed, a confirmation message of successful completion is output through the console, and a success prompt dialog box pops up through the graphical user interface, which includes the storage path and file name of the output product.

[0135] The above embodiments, by establishing a hierarchical log and prompt information output mechanism, provide transparent information support for the full monitoring and problem diagnosis of automated processes, enabling engineers to grasp the process progress in real time and quickly locate the root cause of problems when anomalies occur. Specifically, the method divides information output into four levels: progress prompts (output at the start of a stage), success confirmations (output after a stage is completed), error alerts (output in red font and pop-ups when an anomaly occurs), and final result notifications (output after all stages are completed). For example, in an automated process containing six stages, without hierarchical log output, engineers can only wait for the process to finish to view the final result. If a step fails midway, they have to start troubleshooting from the beginning, which is extremely inefficient. However, through the mechanism of this claim, engineers can see progress information such as "Executing: Model Recognition Stage" → "Model Recognition Stage Completed" → "Executing: Parameter Configuration Stage" in real time on the console. Once the process gets stuck or an error occurs, red font and pop-ups will immediately indicate the stage and cause of the error, allowing engineers to quickly locate and fix the problem. In addition, the final result notification dialog box includes the storage path and filename of the output artifacts. Engineers do not need to search in the file system to directly obtain the accurate location of the deliverables, significantly improving user experience and work efficiency.

[0136] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: 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, enable the one or more processors to implement any of the Simulink-based automated AUTOSAR code generation 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.

[0137] 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).

[0138] 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.

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

[0140] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements any of the Simulink-based automated AUTOSAR code generation methods described in the above embodiments.

[0141] This invention 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 any of the above-described Simulink-based automated AUTOSAR code generation methods.

[0142] 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).

[0143] As is known to those skilled in the art, computer storage media 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.

[0144] 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.

[0145] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state 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 circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0146] 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.

[0147] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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.

[0148] 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.

[0149] 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.

[0150] 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 the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains 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 shown 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, may 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.

[0151] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, 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 the invention as set forth in the appended claims.

Claims

1. An automated AUTOSAR code generation method based on Simulink, characterized in that, Includes the following steps: Model identification and engineering model construction: Automatically identify and determine the unique Simulink original model to be processed, and generate an independent engineering model for subsequent automated processing based on the complete interface and structure of the original model; Standardized parameter configuration: Automatically configure a predefined set of parameters specifically for AUTOSAR code generation for the engineering model. The parameter set includes at least the solver type, system target file, and default data type to form a standardized configuration model. Automatic AUTOSAR architecture mapping: Based on the standardized configuration model, automatically create the corresponding AUTOSAR software component architecture, and automatically establish the mapping relationship between the signal ports in the standardized configuration model and the runtime and events in the AUTOSAR software component architecture; Code generation and quality assurance: Based on the established mapping relationship, the code generator is automatically invoked to generate C language code and ARXML description files that conform to the AUTOSAR standard; Subsequently, the generated code undergoes automated quality checks, and upon passing the checks, intermediate files are automatically cleaned up and the final product is packaged into a single deliverable.

2. The method according to claim 1, characterized in that, The model identification and engineering model construction steps include: Scan the current working directory to get a list of all Simulink model files; Verify the number of files in the model file list; if the number is not 1, terminate the execution and issue a prompt; if the number is 1, identify the unique model file as the original model. Based on the original model, a new blank Simulink model is automatically created as the target engineering model, and its top-level subsystem and all its input ports, output ports and trigger ports are automatically extracted and copied from the original model to the target engineering model. In the target engineering model, signal connections between the input ports, output ports and the top-level subsystem are automatically established to restore the data flow structure of the original model, thereby generating a structurally complete and functionally equivalent engineering model.

3. The method according to claim 2, characterized in that, Before extracting and replicating its top-level subsystem from the original model, the following steps are also included: The original model file is renamed, and the current timestamp is added to the end of its filename to generate a backup file with a timestamp. The backup file is saved in the original directory where the original model is located to prevent irreversible modifications or data loss to the original model during subsequent automated operations.

4. The method according to claim 1, characterized in that, The set of parameters for automatic configuration includes at least the following categories of configuration items: The first category, solver and simulation configuration, is used to ensure the real-time running characteristics of the code. Specifically, it includes setting the solver type to fixed step size and selecting the solver as discrete solution mode. The second category is code generation target configuration, which is used to specify the architectural standard for generated code. Specifically, it includes specifying the system target file as the AUTOSAR-specific target template file autoSar.tlc. The third category, data types and optimization configurations, is used to improve code execution efficiency and security. Specifically, it includes setting the default unspecified data type to a single-precision floating-point type and enabling code optimization options. The fourth category, traceability configuration, is used to enhance the readability and maintainability of generated code. Specifically, it includes enabling code generation reporting to generate ASAP2 calibration files, code metric reports, and code replacement reports, as well as enabling custom annotation to embed tracing information in the code.

5. The method according to claim 1, characterized in that, The process of automatically creating the AUTOSAR software component architecture, following a hierarchical order from macro to micro, includes the following steps: Component layer creation: Automatically generate an AUTOSAR software component as a container to carry the functions of the standardized configuration model, and at the same time generate an abstract behavior description framework for the software component; Runtime layer creation: Within the software component generated in the component layer creation step, at least two runtime entities are automatically created according to the functional requirements of the standardized configuration model, namely the initialization runtime and the periodic runtime, to encapsulate different execution stages of the model; Event layer binding: For each runtime created in the runtime layer creation step, a corresponding AUTOSAR scheduling event is automatically created and bound, wherein the initialization runtime is bound to an initialization event, and the periodic runtime is bound to a periodic trigger event, so as to establish a scheduling trigger mechanism for the runtime; Export configuration layer settings: Based on the preset AUTOSAR standard and the target controller platform specifications, automatically configure the ARXML file attributes of the software components during export, including setting the export directory of the ARXML file, defining the hierarchical path of the data structure package, and specifying the packaging mode as single file output mode.

6. The method according to claim 5, characterized in that, The initialization run and periodic run created in the run layer creation step, as well as the events bound in the event layer binding step, are all automatically named according to a preset unified naming rule to achieve a unique correspondence between run, event, and original model. Specifically, this includes: The initialization runtime is automatically named Runnable_<model name>_Init, and the initialization event bound to it is automatically named Event_<model name>_Init; The periodic running body is automatically named Runnable_<model name>_Step, and the periodic triggering event bound to it is automatically named Event_<model name>_Step; Wherein, <model name> is the name of the original model determined in the model identification and engineering model construction steps.

7. The method according to claim 1, characterized in that, The quality inspection process in the code generation and quality assurance steps specifically includes: Code scanning: Traverse all generated C source code files, read the file content line by line, and use preset regular expression patterns to match any of the following double-precision floating-point type identifiers within non-commented areas: The keywords are float64 or real64_T; Floating-point constants expressed in scientific notation and with a precision exceeding the range of single-precision floating-point; Detection and Judgment: If any double-precision floating-point type identifier is matched in any C source code file, the quality detection result is determined to be unqualified, and the subsequent packaging process is immediately stopped. At the same time, an error log is output to the console and a graphical warning box pops up to notify the user that there is a precision risk in the code. If no double-precision floating-point type identifier is matched in any C source code file, the quality detection result is determined to be qualified, and the packaging step in the code generation and quality assurance steps is automatically triggered.

8. The method according to claim 7, characterized in that, During the code scanning process described above, to improve detection accuracy and avoid the risk of misinterpreting double-precision floating-point type-related strings in comment text as precision data in the actual code, the following comment exclusion mechanism is specifically adopted: When reading C source code files line by line, a comment status flag is maintained in real time to track whether the current reading position is within the block comment area defined by the comment start character / * and the comment end character * / . When the comment status flag indicates that the current line content is within a block comment area, the matching operation of the regular expression pattern is skipped for that line content, and it is not detected. When the comment status flag indicates that the current line content is outside the block comment area, the regular expression pattern matching operation is performed normally on the line content.

9. The method according to claim 1, characterized in that, In the code generation and quality assurance steps, after passing quality inspection, packaging the final product into a single deliverable includes: Intermediate file cleanup: Delete temporary and intermediate files generated during code generation, specifically Simulink cache files with the .Slxc extension and MATLAB autosave files with the .aSv extension, to reduce redundant data; Compression and Packaging: Take the code generation folder containing all generated C source code files, header files, and ARXML description files, i.e., the folder named <model name>_autoSar_rtw, as the packaging object, and use a compression tool to compress it into a ZIP format compressed file; The compressed file is named according to a preset naming convention, with the format <model name>_autoSar_<timestamp>.zip. The timestamp is the current date when the packaging operation is performed, so as to realize the unique identification and version traceability of the output product.

10. The method according to claim 1, characterized in that, The standardized parameter configuration step also includes a fifth category: safety and diagnostic configuration. This category is used to capture potential programming errors and data anomalies during code generation. Based on the type of risk being monitored, it specifically includes the following subcategories: The first subclass, data flow integrity detection configuration: set the diagnostic response level of integer overflow detection, integer saturation detection, read-before-write detection, write-after-write detection, continuous write detection, and multi-task data storage conflict detection to the error level to ensure the consistency and integrity of data during the read and write process; The second subclass, Signal and Bus Compliance Detection Configuration: Sets the diagnostic response level for mandatory checks of non-bus signals and non-numerical / infinite signal detection to error level to ensure the validity of signal data types and numerical ranges. The third subclass, State Machine Security Detection Configuration: Sets the diagnostic response level for illegal data access detection, state transition overstepping detection, and undirected broadcast event detection to the error level to ensure the correctness and security of the Stateflow state machine's execution logic. The fourth subclass, Resource Uniqueness Detection Configuration: Sets the diagnostic response level for data storage uniqueness detection to the error level to ensure the uniqueness of data storage resources in the model and avoid naming conflicts.

Images