A graphical-based C language code file automatic generation system
The graphical C language code file automated generation system solves the problems of programming difficulties and poor cross-vendor portability in PLC development, realizes high-quality and fast C language code generation and multi-vendor code reuse, and simplifies the PLC development process.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- JIANGSU JINLING YUANWANG TECHNOLOGY CO LTD
- Filing Date
- 2022-10-28
- Publication Date
- 2026-04-17
AI Technical Summary
The development of PLCs faces challenges such as programming difficulties, reading difficulties, high learning costs of C language, fragmented development standards, and poor cross-vendor portability, making it difficult to meet the high-quality and rapid delivery requirements of industrial control.
This paper provides a graphical C language code file automatic generation system, including a data structure module, a data mapping module, a C language code file generation module, and a data storage module. The system uses data structures to store component variables, data mapping to establish the correspondence between data elements, and generates high-quality C language code that conforms to the MISRA standard. It also supports AUTOSAR code reuse and performance optimization.
It improves code readability and generation efficiency, supports code reuse from multiple vendors, achieves high-quality C language code generation, simplifies the PLC development process, and meets the rapid delivery needs of industrial control.
Smart Images

Figure CN115658068B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, specifically to a graphical C language code file automated generation system. Background Technology
[0002] With the increasing complexity of control software in industrial control scenarios, text-based development methods—that is, coding according to text-based specifications and then testing and debugging through operation on prototype or physical systems—are increasingly unable to meet the current market demands for rapid product or system delivery while ensuring high quality. Model-based design, utilizing automatic code generation tools to directly convert specification models into runnable product-level code, is an effective means of addressing this development challenge. PLC (Programmable Logic Controller) is an embedded processor widely used in industrial control; it is an electronic device specifically designed for digital operation in industrial environments. Developing PLC-based industrial control software is a core task in PLC applications. Dedicated controllers, due to their integrated CPU / MPU, allow logic control to be implemented through programming, thus providing great flexibility. However, for most users, general-purpose C programming or other programming languages remain a significant hurdle, making them inconvenient to use. The current state of PLC development faces many difficulties. The original ladder diagram system was designed to simplify programming, but as the system has become increasingly complex, ladder diagrams are not adept at expressing complex programming concepts, leading to difficulties in programming and reading. PLCs are primarily developed using C, a language with a very high learning curve. Furthermore, the development of the internet industry has resulted in C language developers being unable to meet the demands of industrial development. PLC programs have extremely high requirements for determinism, real-time performance, and security, and development standards are severely fragmented. Large and medium-sized enterprises both domestically and internationally have their own IDE products, making the generated control programs unusable across vendors and resulting in poor portability.
[0003] Therefore, a graphical C language code file automatic generation system is needed to solve the above problems. Summary of the Invention
[0004] The purpose of this invention is to provide a graphical C language code file automatic generation system to solve the problems mentioned in the background art.
[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a graphical C language code file automated generation system, comprising a data structure module, a data mapping module, a C language code file generation module, and a data storage module, wherein,
[0006] The data structure module is used to store the variables of the component, and the output of the data structure module is connected to the input of the data mapping module;
[0007] The data mapping module is used to establish a correspondence between data elements between two data models, match data fields and target fields, and complete the data transformation after performing data mapping operations.
[0008] The C language code file generation module is used to combine data structures and operation rules to generate the final C language code file based on data information;
[0009] The output of the C language code file generation module is connected to the input of the data storage module;
[0010] The data storage module is used to store the generated code.
[0011] Furthermore, the data structure module stores the component's variables. Like the function header, the component is automatically generated, and the user has no influence on this data structure. A portion of this data structure consists of the component's instance variables, which can be used in any method. Therefore, they must be passed to all generated functions. At the same time, the data structure also depends on the code extender, thus hiding the exact naming from the user.
[0012] Furthermore, the user-defined element names of C language variables in the data structure must be valid ANSI C identifiers. In addition to reserved C keywords, the names themselves are also reserved. To facilitate access to the elements of the component, a macro will be automatically defined for each element, and each element can then be accessed by its name. Public elements defined in other components can be accessed from C functions using symbolic objects. Access permissions are limited to basic elements, arrays, and matrices.
[0013] The matrix element search algorithm is as follows:
[0014] The function f(x,y) depends on two variables x and y, which represent the absolute values of the determinant Δ, ω, and δ, respectively. The function returns a function value matrix obtained by [X,Y] = meshgrid(x,y) on a grid, and then linearly scans the region [x1,x2,y] with the largest grid point Nx×Ny. N ]×[y1,y N [, until the absolute precision tolerances dx and dy are reached.]
[0015] Furthermore, the data mapping module includes ID mapping and data structure mapping;
[0016] The ID mapping generates a C function for each method or process. When the function header is automatically generated, the C code is only used within the function body itself. The names of the functions generated for the methods and procedures of the component depend on the code extender and the software architecture of the generated code. A unique namespace is implemented based on the code extender, allowing methods in different classes to have the same name without any naming conflicts.
[0017] The data structure mapping is as follows: For basic types, method names such as int, float, double, etc. can be used. When accessing arrays or matrices, C language methods are used to operate using the index operator "[]". Since the method name of the user-defined type depends on the extension program, the user-defined type method can only be called if the exact function name generated by the method is known.
[0018] When using predefined elements, these elements are of model type;
[0019] The definition is either a standard C language definition or a user-defined definition;
[0020] When switching specification levels, such as fixed-point code, model type logical elements can be represented by bits. To achieve data consistency, code generation must create additional message copies. If messages are used for read or write access in functional code, additional code is needed to ensure that the current value is safely copied from the message original to the local copy. In the process body, only these local copies are used. Finally, all local copies that may have their values changed in the process body must be written back to the message original.
[0021] These messages are usually well detected in SEDL and block diagram components. However, the availability of this feature is limited when using C code for the specification. In this case, the user must handle data consistency themselves. Under this condition, it is not possible to detect variables written by the user in the specified C code, and only a few special cases are identified.
[0022] If a variable is modified in a macro, external function, or through addressing operators and pointer arithmetic media, the change will not be detected; when using messages, this behavior results in a copy of the message being created at the start of the process, but cannot be written back when the process ends if the process is blocked or terminated abnormally.
[0023] Furthermore, in the data mapping module, the method's parameters are mapped to function parameters in the parameter list of the function generated by the method, and these parameters can also be accessed by their names. According to general C language syntax rules, function local variables can be declared within the method body. Here, only variables of C data types can be declared, but variables of model types cannot be declared, especially in the main specification components of C, where user-defined type local variables cannot be used.
[0024] Since each implementation variant has a code variant, users can define local variables related to the implementation variant and their data types.
[0025] Furthermore, the data mapping module uses a linear interpolation mapping algorithm, specifically:
[0026]
[0027] Where x is the independent variable, x1 and x0 are known values of the independent variable, and f(x) is the dependent variable value of the independent variable x. Multiple index values are used to evaluate the accuracy of the difference, and finally RMSE squared difference is selected as the error evaluation algorithm.
[0028] The RMSE error assessment algorithm is as follows:
[0029]
[0030] Where N is the calculated number, O i For the observed data points, P i To extrapolate data points, RMSE provides the same dimension for the error values as the actual and predicted values; a smaller RMSE value indicates a smaller model error.
[0031] Furthermore, the C language code file generation module generates AUTOSAR code by mapping the code generator model to the AUTOSAR structure. This enables the rapid reuse of existing code generator models and allows for the generation of code for different targets through custom options. Custom callbacks can be routed to device-specific arithmetic, interpolation, or service libraries. Meanwhile, the compiler's memory instructions can parse conditional codes and data structures during compilation or generation and provide performance optimization strategies at runtime.
[0032] Furthermore, the code development process can be implemented in the form of C code, block diagrams, and SEDL. It requires specifying the body of a method or procedure, thereby automatically generating method declarations, function headers, and frames, and completing data initialization.
[0033] Compared to specifications in SEDL or block diagrams, components in C code are specified at the implementation level rather than the model level, without any transformation from the model to the implementation level.
[0034] SEDL (Skyline Embedded Development Language) is a scripting language definition for embedded development. Its purpose is to simplify the problem of excessive complexity in developing industrial automation control software. Unlike traditional development languages, SEDL is a model-oriented language. SEDL supports both text-based and graphical programming methods, and these methods are interchangeable, enabling rapid development of PLC, DCS, and other industrial control programs.
[0035] Based on different goals, specification levels, and implementations, code is specified separately for each variant to ensure file consistency. When using user-defined types, C code must generate corresponding code frameworks because interfaces are generated. Furthermore, the names of C functions generated by the extender are not visible to the user. In the current extender, class identifiers are used in the generated function names to ensure a unique namespace.
[0036] Components described in C code have the same structure as those described in SEDL or block diagrams; C code describes the body of a method or process; the specification of components in C code depends on the target compiler; and the code is variable.
[0037] The C code can be used to represent the physical level, in which case the implementation level is as consistent as possible with the physical level. Alternatively, the C code can be converted to the implementation level of the fixed-point algorithm, since the C code depends on the implementation of the variables, especially their quantization.
[0038] Furthermore, in the data storage module, each code variant is stored separately.
[0039] Compared with the prior art, the beneficial effects achieved by the present invention are:
[0040] 1. This invention can automatically generate high-quality production C code that conforms to the MISRA standard. For users, it improves code readability, allows traceability to the user's code generator model, and can automatically insert defensive code, including: division by zero protection, saturation limits based on type attributes, and index overflow protection for array types. It also supports fixed-point or floating-point code generation.
[0041] 2. This invention uses a simple and easy-to-use automatic code generation mechanism to generate AUTOSAR code by mapping the code generator model to the AUTOSAR structure. It can quickly reuse existing code generator models and generate code for different targets through custom options. It can parse conditional codes and data structures during compilation or generation, and provide performance optimization strategies at runtime.
[0042] 3. In this invention, the code generator provides various interfaces and standardized file exchange formats, which can easily integrate tools into the user's development process and toolchain. The code generator is built on the Eclipse platform, allowing seamless integration of process tools in the same IDE. It connects to JIRA, Bitbucket, Git, SVN, and ibmrtc through native Eclipse plugins, and can be installed in existing Eclipse embedded workbenches provided by different vendors such as STM and ARM. It can model and generate code for multiple targets, build and debug in the same IDE, generate additional process artifacts such as A2L, ARXML, and MDX from the model, and extend the user's process through the accompanying SDK. For example, the user's own process code can be inserted into the static analysis engine, and the workbench can automatically achieve continuous integration. Attached Figure Description
[0043] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:
[0044] Figure 1 This is a schematic diagram of data mapping for an automated C language code file generation system based on a graphical representation, according to the present invention.
[0045] Figure 2 This is an example based on the text;
[0046] Figure 3 This is a screenshot of Implementation Example 1 presented based on the text;
[0047] Figure 4 This is a screenshot of Example 3 presented based on the text. Detailed Implementation
[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0049] like Figure 1 and Figure 2 As shown, this invention provides the following technical solution: a graphical C language code file automated generation system, comprising a data structure module, a data mapping module, a C language code file generation module, and a data storage module, wherein...
[0050] The data structure module is used to store the variables of the component, and the output of the data structure module is connected to the input of the data mapping module;
[0051] The data mapping module is used to establish a correspondence between data elements between two data models, match data fields and target fields, and complete the data transformation after performing data mapping operations.
[0052] The C language code file generation module is used to combine data structures and operation rules to generate the final C language code file based on data information;
[0053] The output of the C language code file generation module is connected to the input of the data storage module;
[0054] The data storage module is used to store the generated code.
[0055] The data structure module stores the component's variables. Like the function header, the component is automatically generated, and the user has no effect on this data structure. A part of the data structure consists of the component's instance variables, which can be used in any method. Therefore, they must be passed to all generated functions. At the same time, the data structure also depends on the code extender, thus hiding the exact names from the user.
[0056] User-defined element names for C language variables must be valid ANSI C identifiers. In addition to reserved C keywords, the names themselves are also reserved. To facilitate access to the elements of a component, a macro will be automatically defined for each element, and each element can then be accessed by its name. Public elements defined in other components can be accessed from C functions using symbolic objects. Access permissions are limited to basic elements, arrays, and matrices.
[0057] The matrix element search algorithm is as follows:
[0058] The function f(x,y) depends on two variables x and y, which represent the absolute values of the determinant Δ, ω, and δ, respectively. The function returns a function value matrix obtained by [X,Y] = meshgrid(x,y) on a grid, and then linearly scans the region [x1,x2,y] with the largest grid point Nx×Ny. N ]×[y1,y N [, until the absolute precision tolerances dx and dy are reached.]
[0059] The data mapping module includes ID mapping and data structure mapping;
[0060] The ID mapping generates a C function for each method or process. When the function header is automatically generated, the C code is only used within the function body itself. The names of the functions generated for the component's methods and procedures depend on the code extender and the software architecture of the generated code. A unique namespace is implemented based on the code extender, allowing methods in different classes to have the same name without any naming conflicts. For example, the component's identifier is used to generate a unique name QX040H28HJ8HAMDJ870S4G7MDIBQQLSM_calc for the method calc.
[0061] The data structure mapping is as follows: For basic types, method names such as int, float, double, etc. can be used. When accessing arrays or matrices, C language methods are used to operate using the index operator "[]". Since the method name of the user-defined type depends on the extension program, the user-defined type method can only be called if the exact function name generated by the method is known.
[0062] When using predefined elements, these elements are of model type;
[0063] The definition is either a standard C language definition or a user-defined definition;
[0064] At the physical level, primitive types have the following default implementations:
[0065] continuous=real64
[0066] udisc = unsigned int32
[0067] sdisc = signed int32
[0068] Log = int16;
[0069] The data structure may be as follows:
[0070] Struct QX040H28HJ8HAMDJ870S4G7MDIBQQLSM_Obj{
[0071] ASDObjectHeader objectHeader;
[0072] real64_Obj*a;
[0073] real64_Obj*b;
[0074] real64_Obj*c;
[0075] real64_Obj*d;
[0076] };
[0077] When switching specification levels, such as fixed-point code, model type logical elements can be represented by bits. To achieve data consistency, code generation must create additional message copies. If messages are used for read or write access in functional code, additional code is needed to ensure that the current value is safely copied from the message original to the local copy. In the process body, only these local copies are used. Finally, all local copies that may have their values changed in the process body must be written back to the message original.
[0078] These messages are usually well detected in SEDL and block diagram components. However, the availability of this feature is limited when using C code for the specification. In this case, the user must handle data consistency themselves. Under this condition, it is not possible to detect variables written by the user in the specified C code, and only a few special cases are identified.
[0079] If a variable is modified in a macro, external function, or through addressing operators and pointer arithmetic, the change will not be detected; when using messages, this behavior results in a copy of the message being created at the start of the process, but cannot be written back when the process terminates if the process is blocked or terminates abnormally. Figure 2 The displayed module contains multiple messages. Initially, copies of all messages are created. However, in the generated code, messages that are written directly can be accessed in a recognized manner, while changes to messages used in macros are not recognized and are lost. Therefore, in the end, only copies of the messages that are written directly are available.
[0080] In the data mapping module, the parameters of the method are mapped to the function parameters in the parameter list of the function generated by the method. These parameters can also be accessed by their names. According to general C language syntax rules, local variables of a function can be declared in the method body. Here, only variables of C data type can be declared, but variables of model type cannot be declared. In particular, in the main specification components of C, local variables of user-defined type cannot be used.
[0081] Since each implementation variant has a code variant, users can define local variables related to the implementation variant and their data types.
[0082] Furthermore, the data mapping module uses a linear interpolation mapping algorithm, specifically:
[0083]
[0084] Where x is the independent variable, x1 and x0 are known values of the independent variable, and f(x) is the dependent variable value of the independent variable x. Multiple index values are used to evaluate the accuracy of the difference, and finally RMSE squared difference is selected as the error evaluation algorithm.
[0085] The RMSE error assessment algorithm is as follows:
[0086]
[0087] Where N is the calculated number, O i For the observed data points, P i To extrapolate data points, RMSE provides the same dimension for the error values as the actual and predicted values; a smaller RMSE value indicates a smaller model error.
[0088] For example, linear interpolation works as follows:
[0089] tmpVal=CharTable1_getAt_real64_real64(LLpr,3000);
[0090] / / 1.5 was allocated to tmpVal
[0091] tmpVal=CharTable1_getAt_real64_real64(LLpr,2280);
[0092] / / Calculate the interpolation factor for 2280
[0093] / / The interpolation of 1.212 to 2280 is assigned to its tmpVal
[0094] tmpVal=CharTable1_getAt_real64_real64(LLpr,9000);
[0095] / / Calculated the interpolation factor of 9000.
[0096] / / Assign the interpolation of 2.2 to its tmpVal value of 9000.
[0097] In some cases, separating the search and interpolation steps in a table can improve efficiency. In this case, the subroutines CharTable1_search_real64(charline,index) and CharTable1_interpol_real64_real64(charline) can be used.
[0098] CharTable1_search_real64(LLpr, 1000);
[0099] / / Set the sample points to 1000
[0100] tmpVal=CharTable1_interpol_real64_real64(LLpr);
[0101] / / 0.8 was allocated to tmpVal
[0102] CharTable1_search_real64(LLpr, 2780);
[0103] / / Calculated the interpolation factor of 2780.
[0104] tmpVal=CharTable1_interpol_real64_real64(LLpr);
[0105] / / Assign the interpolation of 1.412 to its tmpVal
[0106] The feature table is as follows:
[0107]
[0108] The CharTable2_search_real64_real64(charlien, indX, indY) subroutine is usually sufficient for evaluating feature values.
[0109] The linear interpolation method for this sub-example is as follows:
[0110] tmpVal=CharTable2_getAt_real64_real64_real64(LLpr2,8,5);
[0111] / / Assign 4.0 to tmpVal
[0112] tmpVal=CharTable2_getAt_real64_real64_real64(LLpr2,2,2);
[0113] / / Calculate the interpolation factors for x=2 and y=2
[0114] / / Set the interpolation of (2, 2) to -0 and .571, and assign it to tmpVal
[0115] tmpVal=CharTable2_getAt_real64_real64_real64(LLpr2,20,9);
[0116] / / Calculate the extrapolation factors for x = 20 and y = 10
[0117] / / The value of (20, 10) is inferred to be 5.0.
[0118] / / Set x sample points to 1 and y sample points to 3
[0119] tmpVal=harTable2_interpol_real64_real64_real64(LLpr2);
[0120] / / Allocate 1.0 to tmpVal
[0121] CharTable2_search_real64_real64(LLpr2, 4, 4);
[0122] / / Calculate the interpolation factor for x=4, y=4
[0123] tmpVal=CharTable2_interpol_real64_real64_real64(LLpr2);
[0124] / / Assign the interpolation 3.143 of (4,4) to its tmpVal;
[0125] The C language code file generation module generates AUTOSAR code by mapping the code generator model to the AUTOSAR structure. It can quickly reuse existing code generator models and generate code for different targets through custom options, allowing custom callbacks to device-specific arithmetic, interpolation, or service libraries. At the same time, the compiler's memory instructions can parse conditional codes and data structures during compilation or generation and provide performance optimization strategies at runtime.
[0126] The code development process can be implemented using C code, block diagrams, and SEDL. It requires specifying the body of a method or procedure, which will then automatically generate method declarations, function headers, and frames, and complete data initialization.
[0127] Compared to specifications in SEDL or block diagrams, components in C code are specified at the implementation level rather than the model level, without any transformation from the model to the implementation level.
[0128] SEDL (Skyline Embedded Development Language) is a scripting language definition for embedded development. Its purpose is to simplify the problem of excessive complexity in developing industrial automation control software. Unlike traditional development languages, SEDL is a model-oriented language. SEDL supports both text-based and graphical programming methods, and these methods are interchangeable, enabling rapid development of PLC, DCS, and other industrial control programs.
[0129] Based on different goals, specification levels, and implementations, code is specified separately for each variant to ensure file consistency. When using user-defined types, C code must generate corresponding code frameworks because interfaces are generated. Furthermore, the names of C functions generated by the extender are not visible to the user. In the current extender, class identifiers are used in the generated function names to ensure a unique namespace.
[0130] Components described in C code have the same structure as those described in SEDL or block diagrams; C code describes the body of a method or process; the specification of components in C code depends on the target compiler; for example, the C code can vary depending on whether it is for a PC, PPC, or a specific controller CPU, for example, if a controller CPU has special registers that must be directly addressed.
[0131] The C code can be used to represent the physical level, in which case the implementation level is made as consistent as possible with the physical level; for example, a continuous type is re-represented as a 64-bit floating-point number. Alternatively, the C code can be converted at the fixed-point arithmetic implementation level, since the C code depends on the implementation of the variables, especially their quantization.
[0132] In the data storage module, each code variant is stored separately.
[0133] Example 1:
[0134] like Figure 3 As shown, the automatic code generation process is as follows: select the application file, right-click, and run code generation;
[0135] In operation, the output can be defined as:
[0136] (1) An Eclipse project in the workspace, where the project name property defines the name of the Eclipse project. Activating the "Add" property will trigger the creation of the target. The artifacts generated by this project can be compiled using the function and can be used to quickly analyze and browse the code and use the built-in gcc compiler.
[0137] (2) Absolute folder, where the Folder attribute defines the absolute path of the root folder, and the root folder will contain subfolders such as include, src, etc. The subsequent compilation and linking steps will be performed by external tools.
[0138] During code generation, if it is necessary to automatically create symbols in the generated C code that are unrelated to the names in the SEDL code, it is necessary to use the prefix of the internally generated symbols, such as the name of the temporary variable;
[0139] All internally created symbols are prefixed with this string. To prevent accidental name conflicts with symbols generated from the SEDL model, identifiers are not allowed to be defined in the SEDL model and start with the prefix defined here; by default, this prefix is SEDL_.
[0140] The prefix can be changed to avoid name conflicts with names in third-party software. For example, if the prefix SEDL_ is already used in the user's own library or legacy C program, the prefix can be any valid C identifier and can only contain alphanumeric and underscore characters.
[0141] Example 2: Quickly regenerate the project from the last run;
[0142] Each time the code generator is run, a run configuration with the same name as the created project is used and added to the run history as the configuration from the last launch.
[0143] To rerun code generation for your project, you can do one of the following:
[0144] (1) Use the menu "Run Last Startup" or press F11;
[0145] (2) Quickly regenerate the project from the run history; open the menu "Run, Run History" and select the project from which you want to generate C code;
[0146] Example 3: Create a custom runtime configuration;
[0147] For example, a user-selected custom name, such as Figure 4 As shown, creating a custom runtime configuration includes the following steps:
[0148] S1: Open the "Run Configuration" menu;
[0149] S2: In the "Run Configuration" window, click the "New Configuration" button;
[0150] S3: Please enter the name of the "Run Configuration";
[0151] S4: Click the Browse button and select the SEDL project;
[0152] S5: No need to modify the default Eclipse runtime configuration. If you need a different behavior than the default, you can save the configuration to a shared file through the "Common" tab, such as by adding a menu item.
[0153] S6: Click "Apply" to save the runtime configuration.
[0154] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A graphical C language code file automatic generation system, characterized in that: The system includes: a data structure module, a data mapping module, a C language code file generation module, and a data storage module, wherein... The data structure module is used to store the variables of the component, and the output of the data structure module is connected to the input of the data mapping module; The data structure module stores the variables of the components. The components and function headers are automatically generated. User behavior has no impact on this data structure. A part of the data structure consists of the instance variables of the components. The data structure relies on a code extender and hides the exact names from the user; The user-defined element names for C language variables in the data structure must be valid ANSI C identifiers; When accessing elements of a component, each element will be automatically defined as a macro, and the corresponding element will be accessed by its name. Public elements defined in other components will be accessed through symbolic objects defined in C functions. The matrix element search algorithm is as follows: The function f(x,y) depends on two variables x and y, which represent the absolute values of the determinant Δ, ω, and δ, respectively. The function returns a function value matrix obtained by [X,Y]=meshgrid(x,y) on a grid, and then linearly scans the region [x1,x2,x3] at the largest grid point Nx×Ny. N ]×[y1,y N [, until the absolute precision tolerances dx and dy are reached;] The data mapping module is used to establish a correspondence between data elements between two data models, match data fields and target fields, and complete the data transformation after performing data mapping operations. The C language code file generation module is used to combine data structures and operation rules to generate the final C language code file based on data information; The output of the C language code file generation module is connected to the input of the data storage module; The data storage module is used to store the generated code.
2. The graphical C language code file automatic generation system according to claim 1, characterized in that: The data mapping module includes ID mapping and data structure mapping; The ID mapping generates a corresponding C function for each method or process. When the function header is automatically generated, the C code is only used in the function body itself. The names of the functions generated for the methods and procedures of the components depend on the software architecture of the code extender and the generated code; The data structure mapping specifically involves using the indexing operator "[]" in C language when accessing arrays or matrices. When switching specification levels, model type logical elements can be represented using bits, and additional message copies need to be created during code generation; When using messages for read or write access in functional code, additional code is required to ensure that the current value is safely copied from the original message to a local copy; in the main body of the process, only the local copy is used.
3. The graphical C language code file automatic generation system according to claim 2, characterized in that: In the data mapping module, the parameters of the method are mapped to the function parameters in the parameter list of the function generated by the method, and these parameters can be accessed by their names.
4. The graphical C language code file automatic generation system according to claim 2, characterized in that: The data mapping module uses a linear interpolation mapping algorithm, specifically: ; Where x is the independent variable, x1 and x0 are known values of the independent variable, and f(x) is the dependent variable value of the independent variable x. Multiple index values are used to evaluate the accuracy of the difference, and RMSE squared difference is selected as the error evaluation algorithm. The RMSE error assessment algorithm is as follows: ; Where N is the calculated number, O i For the observed data points, P i To extrapolate data points, RMSE provides the same dimension for the error values as the actual and predicted values; a smaller RMSE value indicates a smaller model error.
5. The graphical C language code file automatic generation system according to claim 1, characterized in that: The C language code file generation module includes a code generator and a compiler; The code generator generates AUTOSAR code by mapping the model to the AUTOSAR structure, and generates code for different targets through custom options; The compiler's memory instructions parse conditional codes and data structures during compilation or generation, and provide performance optimization strategies at runtime.
6. The graphical C language code file automatic generation system according to claim 4, characterized in that: The code development process can be implemented using C code, block diagrams, and SEDL. Components described in C code have the same structure as those described in SEDL or block diagrams; The C code describes the main body of the method or process; The specifications of the components in the C code depend on the target compiler; The C code can be changed; When the C code is used to represent physical levels, level conversion can be achieved through a fixed-point algorithm.
7. The graphical C language code file automatic generation system according to claim 1, characterized in that: In the data storage module, each code variant is stored separately.
Citation Information
Patent Citations
System and method for graphical programming facing children
CN103197929A
Code display method, system and device for graphical programming scene and storage medium
CN112306481A