DE102019008598A1 - Identification and visualization of associations between code generated by a model and sources that influence code generation - Google Patents

Abstract

A system determines which aspects of input sources contribute to code generation and provides associations between the input sources and components of features of the generated code. These associations can be visualized by displaying visual references to the associations. The input sources can be of different types, including, but not limited to, a model, a code generator, and values for atomic configuration settings for code generation. The visual indication displayed can take the form of a visible connection between the input sources and the relative part or parts of the generated program code. Recommendations can be generated in response to edits in the generated program code regarding how the sources can be modified to effect desired changes in the generated program code. Analysis can be performed to identify artifacts in the generated program code, and associations to the sources can be identified to specify which source contributed to parts of the generated program code.

Description

Related registrations

This application claims priority from U.S. Patent Application No. 62 / 778,101 , filed on December 11, 2018, entitled "Identification And Visualization Of Associations Among Code Generated From A Model And Sources That Affect Code Generation". The contents of the aforementioned applications are hereby incorporated by reference.

Summary

According to an exemplary embodiment, a method is carried out by a processor of a computing device. Program code for a model and / or one or more configuration values that are set for the model is generated for the method. The model is executed, or the program code that simulates the behavior of a real world system such as a physical system, a computer system, an engineered system, an embedded system, a biological system, a chemical system, etc. , is running. Information regarding behavioral effects of the model on the program code is recorded. One or more configuration effects from one or more configuration values that affect the program code are also recorded. At least some of the behavior effects and the one or more configuration effects are interdependent. For part of the program code, one of the one or more configuration effects and / or behavioral effects is determined to contribute to a feature of the part of the program code. This determination includes analyzing the recorded information and deriving the behavior effects and the one or more configuration effects, an identity of the one or more configuration effects and / or behavior effects that have contributed to the feature of the part of the program code. An association between the identified one or more configuration effects and / or behavioral effects that have contributed to the feature of the part of the program code is stored. Accordingly, the method permits improved human-machine interaction, since specifically the configuration effects can be obtained with computer assistance, and more specifically can be obtained automatically. It is also advantageous for at least part of the program code to determine one or more configuration effects and / or behavioral effects in a computer-assisted manner, which makes it possible to establish an association between the identified one or more configuration effects and / or behavioral effects that lead to the feature of the part of the program code have contributed, so that effects and / or the influence of individual features on the behavior of the code and / or the model can be identified. Accordingly, the method enables an improved computer-assisted generation of code. The method can also advantageously roll out the code and / or adaptation and / or optimizations and / or customer-specific adaptations for different systems to which the generated code is to be rolled out.

The analysis performed by the method may identify the one or more configuration effects as contributing to the feature in some cases. In other cases, the analysis can identify the one or more behavioral effects as contributing to the characteristic. The configuration effects can result from one or more of the following configuration values: choice of naming rules for identifiers, choice of a storage class, choice of a solver type, choice of a solver, choice of data to be imported, choice of data to be exported, target hardware details, coding style parameters or choice of programming language of the generated program code. Advantageously, according to one or both of the aforementioned embodiments, associations between a plurality of types of sources can be identified and / or program code can be generated by the sources by a code generator.

The identified one or more behavioral effects may be the result of at least one of the following: a choice of optimization in the code generation, an added feature of the code generator, a patch applied to the code generator, an algorithm of the model, a change on the model to fix an error or a change to the model to make the generated program code compatible with a coding standard.

In some embodiments, the saved association is used to identify which of the one or more configuration values, aspects of the model, and / or aspects of the code generator contributed to the feature of the portion of the program code. A visual indication can be shown on a display. The visual hint makes the identified configuration values, Aspects of the model and / or aspects of the code generator that have contributed to the feature of the part of the program code are visually distinguishable. The display can be triggered automatically by a programming mechanism. Alternatively, the display may be in response to a user interface event.

The model can be, for example, a graphic model or a textual model. The configuration values can be atomic configuration values (as described below). The code to be rolled out and / or an adaptation and / or optimizations and / or customer-specific adaptations can advantageously be made possible for different systems on which the generated code is to be rolled out. Atomic tracing, more specifically the identification of aspects of sources at an atomic level, can allow users to make appropriate changes to the model or model configurations to obtain desired code.

There can be different relationships between configuration values. For example, at least one of the configuration values may have at least one of the following relationships relative to causing the one or more configuration effects: a logical and relationship, a logical or relationship, an overriding or overriding relationship, one of the two configuration values overwriting the other overrides, or a combination relationship, the at least two configuration values each contributing to the one or more configuration effects.

The method described above can be carried out by executing computer-executable instructions stored on a non-transitory computer readable storage medium.

In example embodiments, a method may be performed by a computing device. The method may include identifying that generated code has been modified to have a modification, the generated code being generated by a code generator for multiple sources that include a model, such as a graphical model or a text model, and at least one other Source type that influences the code generation by the code generator. A determination is made of how the sources can be modified to effect the code generation modification by the code generator. Information is displayed on the display device relating to how the sources can be modified in order to effect the modification by means of code generation by the code generator. Information relating to relationships between sources can be collected and used in determining how the sources can be modified. How the sources can be modified can be displayed in a prioritized order based on a predetermined prioritization system. The predetermined prioritization system may be based on at least one of past behavior, a received preference, or a rule. This method can be carried out by executing computer-executable instructions stored on a non-transitory computer readable storage medium.

According to another exemplary embodiment, a method is carried out by a processor of a computing device. The method includes performing an analysis of a portion of generated code that is generated by a code generator for multiple input sources. The multiple input sources may include a graphical model and another input source of a type that is not a graphical model and that affects the generation of the generated code by the code generator. The analysis delivers results. A determination is made as to which of the input sources contributed to the results of the analysis. A trace of the results of the analysis of the particular input sources that have contributed to the results is displayed on a display device. The analysis can identify one of the following: violations of a coding standard, compilation errors, errors in the program code that part of the generated code cannot be proven by a code prover or a code verifier, or changes in the generated code relative to previously generated code, generated by the code generator from the graphic model. The analysis can be a static analysis or a dynamic analysis.

Figure list

• 1A shows components in an exemplary embodiment.
• 1B shows an exemplary list of source types.
• 1C shows an exemplary list of aspects of a code generator that can change and affect the code generation.
• 1D shows an exemplary list of types of configuration settings.
• 1E shows an example of source aspects that are categorized as behavioral or non-behavioral.
• 2A FIG. 10 is a flowchart that provides a high level overview of steps performed in an exemplary embodiment.
• 2 B shows sources, a code generator and generated program code.
• 2C Figure 3 shows an example of a tree of information that can be stored during source code generation.
• 2D FIG. 14 is a flow diagram of steps performed in an exemplary embodiment to create an inverse association between source aspect (s) and component (s) of generated program code.
• 2E FIG. 4 is a flow diagram of steps performed in an exemplary embodiment to forward association between component (s) generated program code and source aspect (s).
• 3A illustrates an example of displaying an association among a component in generated program code and source aspects.
• 3B illustrates an example of a display of an association to source aspects and components of generated program code.
• 4A 10 is a flowchart illustrating the steps performed in the analysis in an exemplary embodiment.
• 4B illustrates exemplary types of analysis.
• 5A and 5B illustrate an exemplary user interface that shows associations between source components and an artifact of analysis.
• 6A Fig. 4 is a flowchart illustrating steps that are performed to associate differences in generated code with source aspects.
• 6B shows an example of a user interface showing associations under a source aspect, a code change and a compile error.
• 7 illustrates exemplary different types of code differences.
• 8A illustrates an exemplary user interface in which parameters for a solver can be selected.
• 8B illustrates an example user interface in which import / export settings can be selected.
• 8C FIG. 14 is an example user interface illustrating an example in which hardware implementation parameters can be selected.
• 8D illustrates an example user interface in which naming rules can be selected and an explanation of the naming rules syntax can be provided.
• 8E illustrates an exemplary user interface in which coding style parameters can be selected.
• 9A illustrates an example of an example user interface in which code generation parameters can be selected.
• 9B illustrates an example user interface in which levels and priorities of optimization can be selected.
• 9C illustrates an exemplary user interface in which the priority of maximum execution speed was selected.
• 9D illustrates an exemplary user interface in which the priority of minimal use of random access memory (RAM) has been selected.
• 10A shows an example of a logical and relationship from source aspects.
• 10B shows an illustrative feature in generated program code when buffer reuse is not selected, in contrast to the feature described in 10A is shown.
• 10C shows an example of an overwriting or overriding relationship, whereby a storage class is selected which overwrites a default storage class.
• 10D shows an example of generated program code, with a default storage class selected for imports in a model.
• 10E shows an example of generated program code when a storage class is selected for an inport to overwrite the default storage class.
• 11A FIG. 4 is a flowchart of steps performed to generate and accept recommendations in an exemplary embodiment.
• 11B shows an example of recommendations, the results of accepting the recommendations and possible side effects.
• 11C shows an example in which the recommendations are displayed in tooltips.
• 12A illustrates a computing device suitable for implementing an exemplary embodiment.
• 12B illustrates a distributed environment suitable for implementing an exemplary embodiment.

Detailed description

Conventional systems do not offer the possibility of identifying associations between several types of sources and generated program code, which is generated by a code generator from the sources. In this context, a source refers to something that can be modified and that affects the program code generated by the code generator from a model. In addition, with conventional systems, it is difficult to know how to modify a source or sources to effect a desired change in the generated program code. The exemplary embodiments described herein can overcome these shortcomings of conventional systems.

The exemplary embodiments described herein may also be able to analyze aspects of the sources that contribute to a feature of the generated program code. The exemplary embodiments are therefore not limited to simple mapping or mapping between a model and generated program code. Rather, the exemplary embodiments may be able to identify associations not only to the model but also to other types of sources that contribute to the resulting features of the generated program code, such as configuration settings for the code generation and versions or modifications to the graphic Model and / or code generator. The exemplary embodiments can therefore identify associations between multiple sources of different types and the resulting feature (s). The exemplary embodiments therefore particularly provide improved human-machine interaction and improved and efficient simulation of the behavior of a real world system by providing associations between multiple sources of different types and the resulting feature (s).

Sources can be categorized according to the effects they have on the generated program code. This represents a way of categorizing sources by type. A source can be the type that affects the observable behavior / results of the generated program code. This type of source is referred to herein as "behavioral" because this type of source has a "behavioral" effect. Conversely, a source can be of the type that does not influence the observable behavior / results of the generated program code, but has non-behavioral effects on the generated program code (for example memory consumption of the generated program code). This type of source is referred to herein as its "non-behavioral" source. It is understood that some sources have both behavioral and non-behavioral effects. In such cases Aspects of the sources may be categorized as behavioral or non-behavioral as appropriate.

The type of a source can identify the variety of the source. For example, different types of sources can include a model and a code generator. In addition, configuration settings and / or configuration values, such as the choice of naming rules and the choice of a storage class, form a further type of source, which influences the generated program code. Furthermore, the choice of optimizations applied by a code generator forms a type of source in that they are configuration settings for the code generator.

Systems and / or methods as described herein may use a computing environment, such as a technical computing environment (TCE), to perform computing operations. A TCE may include hardware-based logic or a combination of hardware and software-based logic that provides a computing environment that enables tasks (for example, users) to be performed that are limited to, but not limited to, disciplines such as be math science, engineering, medicine and business. The TCE can use text-based environments (e.g. MATLAB® software), a graphically based environment (e.g. Simulink® software, Stateflow® software, SimEvents® software, Simscape ™ software, etc.) from The MathWorks, Incorporated; VisSim from Visual Solutions; LabView® from National Instruments, etc.), or another type of environment, such as a hybrid environment, which may include, for example, one or more of the aforementioned text-based environments and one or more of the aforementioned graphically-based environments.

The TCE can be integrated into, or can cooperate with, a graphical modeling environment that can provide graphical tools for creating models of systems and / or processes. The TCE may include other tools, such as tools that are designed to convert a model to an alternate representation, such as computer source code, compiled computer code, or a hardware description (e.g., a description of a circuit layout). This alternative representation can also include a link to an identifier or identifier that is associated with a model element of a graphic model. The identifier can therefore enable the TCE to navigate to the model element and / or to one or more hierarchical levels of a model in which the model element exists. Additionally or alternatively, the identifier may allow the TCE to navigate to an element in the alternate representation that contains the link to the identifier. Additionally or alternatively, the identifier may allow the TCE to navigate to one or more hierarchical levels of the alternate representation in which the element exists. In some implementations, the TCE can provide this capability using graphical tool boxes (e.g. tool boxes for signal processing, image processing, color manipulation, data plotting, parallel processing, etc.). In some implementations, the TCE can provide these functions as justified blocks. In some implementations, the TCE can provide these functions in other ways.

Models that are generated with the TCE can be, for example, models of a physical system, a computer system, a system designed by engineers, an embedded system, a biological system, a chemical system, etc. The models can be based on differential equations, partial differential equations, differential equations, differential and algebraic equations, discrete event systems, state transition systems, state diagrams, data flow systems, etc. In some implementations, models can be hierarchical and include a number of hierarchical levels. A hierarchical level of a hierarchical model can be represented by an entity, such as a subsystem or a sub-diagram. The subsystem or subchart may be associated with a local namespace, with data within the namespace being globally available, but not outside the namespace.

A model that is generated with the TCE can include, for example, equations, action language, assignments, conditions, calculations, algorithms, functions, procedures and / or process flows. The model can be implemented, for example, as time-based block diagrams (for example using the Simulink® product, available from The MathWorks, Incorporated), discrete event-based diagrams (for example, using the SimEvents® product, available from The MathWorks, Incorporated), data flow diagrams, state transfer diagrams ( for example using the Stateflow® product available from The MathWorks, Incorporated), software diagrams, a text field based and / or dynamically typed language (e.g. using the MATLAB® product available from The MathWorks, Incorporated), Acausal block diagrams (for example, using the Simscape ™ product available from The MathWorks, Incorporated) and / or as another type of model.

The TCE can use one or more text-based products, such as textual modeling environments. For example, a text based environment may be implemented using products such as, but not limited to, MATLAB from The MathWorks, Incorporated; Octave from the Free Software Foundation; National Instruments MATRIXx; Python from the Python Software Foundation; Comsol Script by Comsol Inc .; Mathematica by Wolfram Research, Inc .; Mathcad from Mathsoft Engineering & Education Inc .; Maple by Maplesoft; Extend by Imagine That Inc .; Scilab by the French National Research Institute for Computer Science and Automation (INRIA), Virtuoso by Cadence Design Systems, Inc .; or Modelica from the Modelica Association or Dymola from Dassault Systemes. In some embodiments, the text-based modeling environment may include hardware and / or software based on logic that provides a computing environment that allows users to perform tasks related to disciplines such as, but not limited to, math, science, Engineering, medicine, economics, etc. to perform more efficiently than if the tasks were in a different computing environment, such as an environment that would require the user to code in a conventional programming language such as C ++, C, Fortran, Pascal, etc developed.

In some implementations, the text-based modeling environment can include a dynamically typed language that can be used to express problems and / or solutions in mathematical notations that are known to those skilled in the relevant fields. The modeling environment can, for example, use a field or array as its basic element, the field not requiring dimensioning. These fields can be used to enable field programming by making operations applicable to an entire set of values, such as values in a field. Field programming can allow field-based operations to be treated as high-level language programming techniques or models that allow a programmer to think and work on entire aggregations of data without explicit loops of individual, non-field-based, i.e., scalar operations to have to fall back.

The modeling environment may be further adapted to execute matrix and / or vector formulations that can be used for data analysis, data visualization, application development, simulation, modeling, algorithm development, etc. These matrix and / or vector formulations can be used in many areas, such as Statistics, finance, image processing, signal processing, control and / or regulation design, computer-aided design (CAD), product life cycle management (PLM), life sciences, education, discrete event analysis and / or design, condition-based analysis and / or design, etc.

In another exemplary embodiment, the TCE can be implemented in a graphically based modeling environment using products such as, but not limited to, Simulink®, Stateflow®, SimEvents®, Simscape ™, etc. from The MathWorks, Incorporated; VisSim from Visual Solutions; National Instruments LabView®; Dymola from Dassault Systemes; SoftWIRE from Measurement Computing; WiT from DALSA Coreco; VEE Pro or SystemVue from Agilent; Vision Program Manager from PPT Vision; Khoros from Khoral Research; Gedae by Gedae, Inc .; Scicos from INRIA; Virtuoso by Cadence; Rational Rose from IBM; Rhapsody or Tau from IBM; Ptolemy from the University of California at Berkeley; or aspects of a Unified Modeling Language (UML) or SysML environment.

The exemplary embodiments enable aspects of sources to be identified at an atomic level as well as at non-atomic levels. An atomic source aspect refers to an aspect of the sources that produces an observable and traceable effect in the generated code. Identifying aspects of sources at an atomic level, which can also be referred to as atomic tracing, allows users to make appropriate changes to a model or model configurations to achieve desired code.

The term "atomic" can be used herein to refer to source aspects, such as configuration settings, model elements, optimization selections, etc. "Atomic" can also be used herein to refer to effects derived from the atomic source aspects during code generation. Higher-level settings, such as choosing a level of optimization, are non-atomic source aspects, for example. Lower level configuration settings that are set in response to the higher level settings may be atomic source aspects.

The exemplary embodiments may allow one to see associations between atomic source aspects and features in the generated program code. It is therefore particularly possible to see associations between an aspect of a source, such as one or more configuration effects and / or one or more behavioral effects of, for example, the model and / or the code generator, and features of the generated code. More specifically, it is therefore possible to identify aspects of a source that can then be modified to effect a desired change in the generated code, and vice versa. Each characteristic can have one or more components. Atomic source aspects can be associated with atomic components in the generated program code. The visualization of each such association can show all such components and associated source aspects. The atomic nature of source aspects and resulting atomic configuration effect (s) perceived in the components enable one to identify at a fundamental level what is manifested in the sources by means of code generation in the relevant features in the generated program code and vice versa . For example, the atomic level in a code as used in this application may refer to granular components of program code.

The exemplary embodiments can identify and generate a visualization of associations between results of the analysis of the generated program code and the source aspects. For example, static analysis can be performed, such as identifying artifacts such as compilation errors, logic errors, code standard violations, and code evidence errors. The static analysis can include an analysis of the code syntax, such as a structural analysis, or an analysis of the behavior of the code without executing the code. In the exemplary embodiments, the source aspects that result in the artifacts can be identified and the association of the source aspects and the artifacts can be visualized. Similarly, dynamic analysis (that is, analysis that is performed on the generated program code when the generated program code is executed), such as code profiling and code coverage analysis, can be performed to generate artifacts. The results of the static analysis and / or the dynamic analysis can be one or more identified artifacts. Exemplary embodiments can identify associations between the artifacts and source aspects of the sources and provide a visualization of the associations. In particular, this enables improved human-machine interaction, for example when specific changes to the code are desired.

The exemplary embodiments may also provide useful information regarding generated program code generated from a first set of sources, with generated program code generated from a second set of sources. In exemplary embodiments, a code differentiator can identify the differences between the sets of generated program code, and can identify which atomic source aspect (s) in the respective sets of sources are responsible for the differences in the sets of generated program code. For example, assume that a first version of a code generator was subsequently used to generate program code for a graphic model. It is further assumed that a second version of the code generator was used to generate code for the graphical source model to generate a second set of generated program code. A code differentiator can be applied to the first version of the program code and the second version of the program code to identify differences between the generated program code. A particular one of the differences can be identified as being due to a particular difference in the versions of the code generator. The association between the differences in the code generators and the difference in the generated program code can be identified and visualized in exemplary embodiments. It is therefore possible in particular to quickly and efficiently identify differences in code that are caused by the use of different code generators and / or different versions of a code generator. For example, this provides a significantly improved simulation result, since undesirable behavior and / or configuration effects caused by the use of the code generators can be identified quickly and efficiently and can be distinguished from actual results of the simulation. Furthermore, it is also possible to provide an improved human-machine interaction, for example during the debugging of the generated code and / or during the debugging and / or the design of code generators.

Other differences in code, such as improvements in generated program code and code changes made to fix bugs or regressions (e.g. deterioration in program code performance resulting from changes) can be identified and back with the changes in the atomic source aspect ( en) associated that caused the improvements, bugs or regressions. Furthermore, it is by the associations for example between Improvements in the generated program code and changes in atomic source aspects of the code generator are identified and provided, possible to significantly improve the efficiency and performance of the code generator.

Identifying the associations between source aspects and the resulting features in the generated program code or artifacts can be based on storing information in constructs, such as data structures, during the code generation process. In some example embodiments, a code generator may identify effects of source aspects in data structures when the generated program code is generated. In example embodiments in which the sources include a model from which the generated program code is generated, some example embodiments may use intermediate representations used in code generation. The stored information (as mentioned above) can be stored along with such intermediate representations to identify the atomic source aspects and to allow associations of the source aspects with the resulting effects in the generated code. In alternative exemplary embodiments, other information may be stored, such as an identification of the association or change information, which indicates when an aspect of a source has changed. In particular, storing the information further improves human-machine interaction by allowing the information to be retrieved efficiently later when needed.

Exemplary embodiments may also provide recommendations on how to modify the sources, such as the source aspects, to have an associated effect in the generated program code. The recommendations can be viewed through a user interface or other mechanism. Each recommendation can include a mechanism that can be activated to implement the recommendation. Exemplary embodiments may further indicate, for each recommendation displayed, a change in the generated program code that is related to the associated effect by implementing the respective recommendation displayed. In other words, for each recommendation displayed, exemplary embodiments may further indicate how the generated program code would be changed to effect the associated effect in the generated program code. Exemplary embodiments may further display a caused change in the generated program code for each displayed recommendation that is not related to the associated effect by implementing the respective displayed recommendation. In other words, exemplary embodiments can further display, for each recommendation displayed, potential changes as a side effect to the generated code that are caused by implementing the respective recommendation. The recommendation can be triggered, for example, by the user modifying the generated program code. In particular, by presenting the recommendations in such a manner, the human-machine interaction during, for example, modifying generated code and / or modifying sources is significantly simplified and improved.

1A shows an illustration 100 a number of components that may be provided in an exemplary embodiment. As in 1A shown can be a number of different types of sources 102 as inputs to a code generator 104 act to generated program code 106 to create. As in 1B shown the sources 102 a model 122 include, such as a textual model or a graphical model. The sources can also use the code generator 104 include. Algorithms in the code generator 104 and changes made to the code generator 104 can affect the generated program code. The sources can also use configuration settings 126 include. As described in more detail below, values can be a number of atomic configuration settings that affect the model 122 and relate the code generation, effects on the generated program code 106 to have. The sources 102 can also do optimizations 128 include which of the code generator 104 be carried out. The code generator 104 can provide the option of the generated program code 106 optimize in different ways. The generated code can be optimized, for example, to minimize memory requirements or to run faster on a processor with limited computing power. This list of sources 102 is not intended to be conclusive, but is intended to be illustrative only.

As mentioned above, the code generator can 104 as a source 102 act that have an effect on the generated program code 106 Has. 1C shows an example of some illustrative aspects of the code generator 104 what impact on generated program code 106 can have. On the code generator 104 can bug fixes 132 applied to fix errors previously in the code generator 104 have existed. These bug fixes 132 can have a resulting effect on the generated program code 106 to have. New features 134 that the code generator 104 can also be added generated program code 106 influence. Often, new releases include a code generator 104 such new features 134 . Other aspects 136 of the code generator 104 can use the generated program code 106 affect such as the selection of code generation algorithms and the like.

As mentioned above, configuration values can be changed 126 the generated program code 106 influence. These configuration settings can be atomic or non-atomic. 1D shows an illustrative list of exemplary categories of configuration settings 126 which the generated program code 106 can influence. Under these categories of configuration settings 126 can be a storage class specification 142 be. Each storage class can specify characteristics of a variable and / or function. The features can include, for example, the scope or scope, visibility, lifespan, data type and storage section. For example, a "ConstVolatile" storage class specifies a storage section for data elements by adding the type qualifiers "const" and "volatile" before data declarations: Declaration: exported via file: INSTANCE_SPECIFIC_HEADER / * ConstVolatile memory section * / / * CSC declaration comment generated by default * / extern const volatile DATA TYPE DATA NAME [DIMENSION], Definition: / * ConstVolatile memory section * / / * CSC declaration comment generated by default * / const volatile DATA TYPE DATA NAME [DIMENSION] [= {...}];

As another example, a "BitField" memory class tells the code generator to generate a type struct with bit field information so that the compiler can generate memory efficient code. typedef struct INSTANCE SPECIFIC STRUCTURAL NAME identifier { unsigned int x: 2; unsigned int y: 2; unsigned int z: 2; } INSTANZEN_SPEZIFISCHER_STRUKTURNAME_typ;

The following table shows other exemplary storage classes. Storage class name description ExportedGlobal Generate a global variable definition and declaration. The name of the variable is the name of the data element. ImportedExtern Generate code that reads and writes a global variable defined by your external code. ImportedExternPointer Generate code that reads and writes a global pointer variable defined by your external code. Use this storage class when external code defines a data element and provides a pointer to access that data. Compiler flag Supports preprocessor conditional defined by compiler flag or option. Const Generate a global variable definition and declaration with the type qualifier const. ConstVolatile Generate a global variable definition and declaration with the type qualifiers const and volatile. Define Generate a macro (#define directive) such as #define myParam 5. ExportToFile Generate a global variable definition and declaration. The names of the files that define and declare the variable can be specified. FileScope Generate a global variable definition and declaration with the type qualifier static. In the generated code, the scope or scope of the variables is limited to the current file. GetSet Generate code that interacts with data by calling your custom access functions. External code defines the data and provides the function definitions. ImportedDefine Generate code that uses a macro (#define directive) that is defined in a header file in external code. ImportFromFile Generate code that reads and writes a global variable that is defined by your external code. Similar to ExportToFile, but the generated code doesn't define the variable. Reusable Generate more efficient code that stores intermediate calculations of a data path in a single, reused global variable. Struct Generate a global structure whose name you can specify. Volatile Generate a global variable definition and declaration with the volatile type qualifier. Localizable For signals, if possible, generate variables that are local to functions rather than in global memory. Generating local variables prevents the code generator from implementing optimizations that remove the variables from the generated code.

The configuration settings 126 can also specify naming rules 144 for identifiers in the generated program code 106 include. The naming rules 144 specify the conventions based on names of identifiers used in the generated program code 106 occur. The configuration settings 126 can include settings that relate to solvers and parameters of the solvers 146 refer to the generated program code 106 can influence. The configuration settings 124 can import / export data settings 148 which contain the generated program code 106 influence. Such data import / export settings can specify whether data is imported, where data is imported from, whether data is exported, and where data is exported to. The configuration settings 126 may include settings that relate to hardware details 150 Respectively. Such hardware details can define details of the target device in which the generated program code 106 to be executed. The configuration settings 126 may include settings that relate to coding style 152 Respectively. The coding style settings 152 can influence the syntax and / or structure of the generated program code. For example, cast configuration settings can be selected to determine whether in the generated program code 106 all types for identifiers are made explicit, are made implicitly, or whether only some of the types are made explicit. The atomic configuration settings 126 can settings 154 include that relate to code generation. The code generation settings 154 can, for example, specify the programming language in which the generated program code is generated.

1E shows that the source aspects 102 into a category of behavioral sources 103 and non-behavioral sources 105 can be categorized as described above. In the representation in 1E may include some source aspects of the model 160 and the code generator 162 as sources of behavior 103 be grouped. Also can be found in the behavioral sources 103 Optimizations 164 are located. The sources can also include source aspects that can be categorized as non-behavioral 105. In the in 1E The example shown can or can non-behavioral source aspect (s) various configuration settings 166 , Aspects of the code generator 168 and aspects of the model 170 include.

It is understood that the in 1E The categorization shown is not intended to be restrictive, but rather is intended to be merely illustrative. For example, there may be other aspects of optimizations that have non-behavioral effects, and there may be aspects of the configuration settings 150 give that have behavioral effects.

Referring back to 1A The exemplary embodiments may have programming functionality to perform the analysis 108 to execute. As mentioned above, the analysis can be a static analysis 110 or a dynamic analysis 112 be. Examples of a static analysis 110 include the identification of compilation errors, the identification of logic errors, the identification of bugs and the identification of coding standard violations. There can therefore be a static analysis of the code structure and a static analysis of the runtime behavior. Examples of dynamic analysis 112 include code profiling and code coverage analysis.

The results of applying the analysis 108 are artifacts 114 . For example, applying coding standard violation analysis can generate a list of coding standard violations. Each of these injuries can constitute an artifact. A coding violation can relate, for example, to a prohibited operator that is used in generated program code. The exemplary embodiments provide the ability to identify such artifacts and associate them with source aspects. This makes it possible to pinpoint the cause of the artifacts. Therefore, the cause of the artifacts can be modified so that the artifact no longer exists, which improves, for example, human-machine interaction.

As in 1A As shown, exemplary embodiments may include a code differentiator 116 include. The code differentiator 116 can make differences 118 in sets of generated program code 106 identify. In exemplary embodiments, these code differences 118 be identified and the causes (i.e. the source aspects) in the sources 102 the code differences 118 can be identified to the source aspects with respective code differences 118 to associate. The association can be visualized on a display by giving visual indications of the associations. Examples of code differences 118 that are useful to know and useful with the aspects of the sources 102 For example, may be associated with code differences that result from different versions of modules or different versions of the code generator 104 in the sources 102 , Code improvements, code errors, code bugs or code regressions.

By identifying the code differences and identifying the associations between aspects of the sources and corresponding components in the generated program code generated by the changed sources, the exemplary embodiments can identify causes of the code differences in the generated program code for the original sources and the allow modified sources. Identifying the causes can in turn make it possible to correct any errors or deteriorate performance.

It should be understood that there may not be a single reason for code differences or the artifacts of the analysis. Instead, there may be multiple causes, and these causes may be interdependent, so that the multiple causes together result in the code difference or artifact of the analysis. As described in greater detail below, the exemplary embodiments have the ability to record the causes (e.g., atomic source aspect (s)) and determine the interdependency of the causes. Furthermore, the exemplary embodiments have the ability to visualize these causes.

2A presents a flow chart 200 of steps that are performed in an exemplary embodiment. This flowchart 200 is used in conjunction with the diagram 220 of components that in 2 B is shown. First, in step 202 generating code from sources 222 kick off. As mentioned above, the sources 222 for example include a model, a code generator, configuration settings for code generation and selection of optimizations. In step 204 becomes source aspect information in intermediate representations 228 and / or data structures 230 , such as entries, tables or other types of data structures.

In step 206 of the 2A the code generation process is completed, which is in the generated program code 226 results. After the code generation process is complete (step 206 ), the stored information is processed to identify associations (step 208 ). The associations are between source aspects and the components of features in the generated program code 226 which of the source aspects of the sources 222 to be influenced. Processing can be performed on demand when a request is made to identify such associations. In alternative embodiments, some or all of the associations can be processed before a request is made and the association information stored for use when needed.

A visual indication of the associations can be displayed on a display device in step 210 from 2A . The shape of the visual cues can vary. Some examples are described below. The display of the visual information can be triggered by actions, such as the selection of a part of the generated program code, hovering over generated program code or the like.

2C FIG. 5 shows an example of the information that may be stored in an exemplary embodiment for a model element and a variable associated with the model element that is contained in the generated program code. In this case the information is in a tree diagram 240 contain. The model element in question is an inport (for example an input port), which is referred to as “Inport1”.

The tree diagram 240 in 2C records information related to decisions made during the code generation process. The tree diagram draws especially for the in 2C shown examples of information taken at different decision points during the code generation process to determine the name of a block output signal variable in the generated program code from the inport. The in 2nd shown subtree 240 begins at the decision point to determine the name of the output signal variable for the model block Inport1. A node is created for the model element 242 saved and generated. At the next decision point, the code generator checks whether a signal name is specified for the output signal as for the node 244 specified. In a first case, the signal name is specified as "In1", as with the branch 245 in 2C specified. The specified signal name "In1" is used as the basis for the variable name. In another case, the signal name is not specified, as with the branch 243 to see.

The code generator then checks at the next decision point (reflected in the node 246 ) whether a storage class is specified for the In1 signal. If the storage class is specified as "Exported Global" as in the left branch 247 shown, the code generator then determines that the variable should be a stand-alone global variable. As such, the system uses the naming rules in the node 248 are specified, which results in the final variable name in the node 250 is reflected.

If at the decision point, the step 246 is associated, it is determined that the storage class is "default", as by the branch 249 displayed, the code generator determines that the variable should be a field of a global variable of a structure type, and the naming rule for such fields of global variables applies, as by the node 252 displayed. This results in the variable final structure field name "In1" within a global variable of the structure type.

1. 1. Die Speicherklasse ist „Exportiert Global“ für das Eingangssignal und daher wird es als alleinstehend global generiert.
2. 2. Der Variablenname wird durch die Namensgebungsregel für alleinstehende globale Variablen bestimmt:
   1. a. Der „rt“ Teil kommt von den Zeichenliteralen in der Namensgebungsregel „rt$R_$N$M.“
   2. b. Der „Modell“ Teil in dem Variablenname ist wegen dem „$R“, der in der Namensgebungsregel spezifiziert ist.
   3. c. Es existiert ein Signalname „In1“ und bildet den letzten Teil des Variablennamens, weil „$N“ in der Namensgebungsregel spezifiziert ist.

This recorded information can be processed during and after the code generations. The code generator can determine which source aspects are responsible for which component (s) of the generated program code. For the example with the 2C associated, the stored tree of information can be used to determine:

1. 1. The storage class is "Exported Global" for the input signal and therefore it is generated as a single global.
2. 2. The variable name is determined by the naming rule for single global variables:
   1. a. The "rt" part comes from the character literals in the naming rule "rt $ R_ $ N $ M."
   2. b. The "model" part in the variable name is because of the "$ R" specified in the naming rule.
   3. c. There is a signal name "In1" and forms the last part of the variable name because "$ N" is specified in the naming rule.

With such information, the code generator can determine which source aspects are associated with the components of a feature of the generated program code, and can also make recommendations about what changes can be made to achieve the desired effects if a user modifies the variable name in the generated code .

It is understood that the representation in 2C only for a very small part of the underlying model. Information can be saved for the entire model during code generation. Furthermore, information such as configuration settings and the like can be stored to identify the configuration effects which selections in the sources have on the generated program code. Information regarding optimizations and aspects of the code generator can also be stored in such a manner.

The exemplary embodiments identify and visualize associations of the component (s) of the generated program code with the source aspects. 2D shows a flow chart 260 , which shows an example of steps that can be performed to accomplish the "reverse" operations of identifying component (s) of a feature in the generated program code and source aspects. In step 262 a component (s) of a feature in the generated program code that is of interest are identified. This can be accomplished by a user or other party who positions the cursor to hover over the component (s) by selecting the component (s) using an input device or other mechanisms. On the stored information, such as that in 2C is then shown in step 264 accessed. The information is accessed to identify the source aspect (s) associated with the identified component (s) of the feature (step 266 ). For example, if you're interested in knowing where the code is 250 who in 2C is shown, originally comes from the sources, the process can be the tree that is in 2C is traversed, starting at the leaf levels, to notice that the code stems from the selection of the storage class, the naming rules, and therefore that the model specifies the signal name and the model element of the import.

Based on that in step 266 the source aspect (s) can be identified in step 268 Associations are identified. These associations can be reflected in the visual cues that can be displayed, as in step 210 from 2A mentioned.

2E shows a flow chart 270 the forward process that can be performed to identify and associate source aspect (s) with component (s) in the generated program code, in exemplary embodiments. This process is largely a reversal of the backward process of 2D . In particular, the process begins with step 272 in which one or more source aspects are identified, such as the model element 242 , the signal name In1 245 , the storage class exports globally 246 and the naming rule 248 ( 2C ). This may include that the user select or hover over various source aspects that are displayed on a user interface. In step 274 the stored information is accessed, such as that in 2C is shown. Based on the stored information, one or more components are created in the generated program code in step 276 identifies how the variable name in the declaration 302 ( 3A) . Associations between the source aspect (s) and the identified component (s) are in step 278 identified. When identifying a component or components, the system can read the information in 2C Use to step down the tree from the identified source aspect (s) until the appropriate leaf is reached that reflects the code in question. These associations can be visualized by displaying visual cues of the associations, as discussed above.

The user interface components for displaying the associations can take various forms. 3A shows an example corresponding to the information given in 2C is saved. As can be seen, the generated program code contains a line of code 79 which is the type of In1 302 Are defined. A user interface element 304 , such as a popup tooltip, can be displayed in response to an event, such as when the user entered the line 79 dials or above the line 79 hovers. The popup 304 can have a definition section 306 which identifies where the variable is defined in the underlying code for the model (i.e. one of the source aspects). The popup 304 can also have a model element section 308 which include the model elements 310 (for the Inport1) and 312 (for the signal that is output by Inport1). These elements 310 and 312 are other source aspects related to the line 79 are associated in the generated program code. The popup 304 includes an adjustment section 314 . The adjustment section 314 identified in the field 318 , How the In1 signal was adjusted by declaring In1 to be global from the storage class, rather than from a default storage class. this section 318 identifies this additional associated source aspect.

3B Figure 11 shows another example of a set of user interface components to illustrate associations such as those discussed above. In the in 3B The example shown shows a window 332 a model in a simulation environment. The model includes the inport 340 . The Inport 340 gives the signal In1 341 out. A model data editing window 336 indicates a specification that the signal name of the exported storage class is global (see 344 ). This model data editing window 336 can be used to define or edit this storage class of the signal In1. It is a third window 334 shown that shows the generated program code. The generated program code contains highlighted lines of code 342 . The highlighted lines of code 342 are the components with the highlighted source aspects in the windows 332 and 336 are associated. Like in the window 332 can be seen are the inport 340 as well as the signal name 341 Highlighted in1. The line is still 344 in window 336 highlighted to provide a visual indication of the atomic source aspect that In1 is associated with the Exported Global storage class. In particular, it is by highlighting one or more components or features of a portion of generated program code associated with a specific source aspect, such as an aspect of a model or code generator, in response to the highlighting or selection (for example, by a user). the specific source aspect, and / or by highlighting one or more source aspects associated with a specific component or feature of a portion of generated program code in response to highlighting or selecting (for example, by a user) the specific component or specific Features of a part of generated program code, possible to maintain both the presentation of the one or more source aspects and the generated program code, and further a visual indication of the association between respective components or features of a part of generated program code and in each case to present en source aspects. Therefore, these two conflicting requirements are resolved.

As mentioned above, an analysis can be performed on the generated program code to identify various artifacts of the analysis that are of interest. As also mentioned above, the exemplary embodiments can identify the artifacts and associate them with the source aspects that caused the artifacts.

4A shows a flow chart 400 of the steps that can be performed with respect to such analysis. First in step 402 an analysis of the generated program code is carried out. This analysis can take many different forms, such as identifying compilation errors, coding standard violations, logic errors or bugs. The analysis can be carried out by programs, libraries or other tools that have the desired analytical functionalities. Based on the analysis, artifacts are identified (step 404 ). In particular, this analysis can provide results which can be the identified artifacts. A determination is made of which source aspects have contributed to the artifacts (steps 406 ). Based on the information stored above with respect to 2C is discussed, the system knows the association between components of the generated program code and source aspects. The system knows the association between the artifacts and the components of the generated program code. Therefore, the system can determine the associations between source aspects and the artifacts. The resulting associations based on the determination are made between the source aspects and the artifacts (step 408 ). When prompted or based on selected commands, the visual cue can show their associations on the user interface (step 410 ) are displayed. In particular, it is therefore possible to significantly improve the human-machine interaction if, for example, it is desired to bring about desired changes in a generated program code.

The types of analysis can vary. 4B shows an example of some of the types of analysis that can be applied to the generated program code and that can result in artifacts. In the representation in 4B has the analysis chart 420 the analysis 422 at the root. Under the root 422 there are two types of analysis: static analysis 424 and dynamic analysis 426 . Examples of static analysis 424 involve structural analysis 430 for analyzing the structure of the generated program code and analyzing the runtime behavior 432 of the generated program code. An example of structural analysis 430 is a coding standard analysis 440 to determine whether the generated program code conforms to coding standards such as Misra C. . Another type of structural analysis 430 is an analysis 442 which identifies logic errors in the generated program code, or which bugs identifies the are present in the generated program code. An example of such an analysis is the analysis performed by programs such as debuggers and logic analysis tools. Another type of runtime behavior analysis 432 that can be applied is that of a code prover 444 is performed. The code verifier 444 can identify logic errors and bugs, but may also identify whether part of the generated program code is provably correct.

The analysis 422 can also do a dynamic analysis 426 be. Examples of dynamic analysis 426 involve analysis by a code profiler 436 is performed. The code profiler profiles the performance of the generated program code when it is executed. The code profiler 436 can provide information such as memory usage, CPU usage and the like. Another kind of dynamic analysis 426 is a code coverage analysis 438 . Various programs and tools can be used to determine whether or not there is full code coverage. Doing the dynamic analysis 426 analyze different types of coverage. The dynamic analysis 426 For example, can analyze decision coverage, condition coverage, condition / decision coverage, modified condition / decision coverage, expression coverage, etc.

As mentioned above, these analysis tools can generate artifacts. The types of artifacts depend on the nature of the tool. A coding standard analysis tool 440 for example, identification can generate which components in the generated program code do not conform to the coding standard that is applied. In contrast, a logic error and bug analysis tool 442 Generate artifacts in the form of an identification of where there are logic errors in the generated program code and where there are bugs in this generated program code. For example, a code proof tool 444 identify a division-by-zero operation, whereas other types of tools may not identify such an operation. A code profiler 436 generates artifacts such as how much memory a function uses in the generated program code and how much CPU time a function uses in the generated program code when it is executed.

5A Figure 10 shows an example of a user interface where a visual cue is provided to identify the association of source aspects with an artifact. In the in 5A Case shown is a code proofer on the generated program code that is in the window 536 is shown. As with the tooltip 542 can be seen, the code proofer recognizes that the multiplication operation of the code in the line 364 potentially lead to an overflow and generates the tooltip 542 . This multiplication operation is from the product block 538 (see model 532 ), which has two input signals, one of which is the output from a look-up table and one from an inport. The Tooltip 542 indicates that there are options to fix the artifact. The artifact can be eliminated by selecting the signal attributes of "Saturation at integer overflow" of the product block, or you can specify limits for the input signals. This specification of limits can be achieved by changing "table data" attributes of the look-up table block and specifying the signal attribute so that it has a "maximum" value on the inport block.

5A also shows a representation of the model 532 , where the multiplication block 538 is highlighted to indicate an atomic source aspect that produces the artifact. In 5A is also a window 534 shown for the code verifier that the error in the line 540 identified as an overflow error.

5B FIG. 5 shows an example 550 in which the code provider is used to identify a coding standard violation in the generated program code. As in 5B shown, the code verifier contains windows 552 a highlighted entry 554 , which identifies that there is a coding standard error. It will be a window 555 displayed that details 556 of the coding standard violation shows. The window 557 is displayed and contains a listing of the generated program code with the tooltip 558 . The Tooltip 558 notes that there are several source aspects associated with this coding standard violation. The Tooltip 558 identifies the subsystem of the model from which the error originated ("factory") and specifies the configuration parameters attached, which result in the coding standard violation. See 'solver': ode5 (Dormand-Prince) and bracket level: minimum (rely on C / C ++ operator precedence). By specifying the configuration parameters, you can change the parameters to correct the coding standard violation. The hyperlink 559 can be selected to invoke a UI element to make the change in parenthesis level. In this case, for example, changing the bracket level from minimum to maximum will fix the coding standard violation.

As mentioned above, the exemplary embodiments can perform code differentiation and visualize associations between code differences and the causes (source aspects) of the Provide code differences. This can be applied to different versions of generated program code. 6A presents a flow chart 600 of the steps that are performed with respect to code differences. First in step 602 Code differences identified. This can be carried out by the code differentiator, which compares the generated program code in question and identifies any differences. In step 604 the cause of the code differences is identified. The code differences are displayed and their causes can be displayed in step 606 . The system can therefore identify the code differences and what caused the code differences in the sources.

6B Figure 10 shows an example of a user interface that helps to illustrate the identification visualization of associations related to code differentiation and artifacts. In the diagram 620 from 6B shows a first window 622 a model. It is also a window 624 shown that identifies storage class information. A third window 630 shows generated program code. In the in 6B The example shown is the inport 631 that in window 622 is shown, which represents the model associated with the illustrative part of the generated program code, which is in window 630 is shown as directed by the arrow 623 displayed. In particular, the highlighted section contains 634 the line 78 that with the Inport 631 may be associated. The popup window 637 identified that line 78 in the generated program code with the Inport 631 is associated as through the entry 640 occupied. The popup window 637 also notices that the signal value from the Inport 631 output, has changed from a default storage class to an imported external storage class, as indicated by the entry 638 specified. The window 624 shows that the imports were specified as imported external storage class, as indicated by the highlighted entry 626 specified. The association between the element 626 and the entry 638 in the popup window 637 is indicated by the arrow 636 detected. This association captures the cause of the change in the generated program code. These changes can be produced and highlighted by a code differentiator, as indicated in the code listing of the generated program code.

6B also shows an example of an artifact associated with the code change. In this example, changing the storage class resulted in a compilation error, as with the entry 652 in window 650 displayed. The compilation error is an undefined reference to rtln1. This association is indicated by the directional arrow 654 in 6B detected. The association between what caused the compilation error and what caused the code change can therefore be represented in such a user interface for an exemplary embodiment.

7 shows an example of certain illustrative code differences that may be identified by the code differentiator that may be of interest. As in the diagram 700 shown, the code difference 702 Code improvements 704 include. It may be of interest to know why the code is improved and which atomic source aspects bring about the improvement in the generated program code. The code differentiator 702 in conjunction with other tools (such as debuggers), can also identify bugs and / or regressions found between versions of generated code. Other types of differences can also be identified as its result of code differentiation 708 . Code differences are not due to code improvements 704 or code errors and regressions 706 limited. In particular, by determining associations between features or parts of generated program code and source aspects that contribute to the features or parts of generated program code, embodiments of the present disclosure therefore make it possible to efficiently determine why a feature or part of generated program code has changed, For example, is improved and which® source aspect (s) caused this change in the generated program code. For example, this significantly improves human-machine interaction.

As discussed above, configuration settings can affect the program code that is generated. 8A shows an example of the type of atomic configuration settings that can affect generated program code. In particular, as in 8A shown the user interface 800 an option 804 in the left pane 802 which, when selected, results in the display of settings related to the selection of the solver. As in the right pane 806 can be seen, a user can simulation time parameters 808 specify. The user can also use a type of solver 812 and a certain solver 814 specify in the section's solver selection 810 . Choosing the type of solver and a particular solver can affect the program code that is generated. In the in 8A The example shown is the type of solver 812 selected as a fixed step solver. The particular solver is through the entry 814 specified as a discrete solver with no continuous states. Other solver configuration values 816 can be displayed and specified using the right window area 806 . 8A shows an example in which certain advanced parameters 818 can be selected or deselected.

8B shows a user interface 800 in which data import / export parameter values are set. The user has the entry 820 in the left pane 802 so selected the right pane 807 display. The right pane 807 poses in section 822 various options for loading inputs or an initial state from a work area. MATLAB, for example, includes a work area for holding variables with values, such as work values, that can be changed while running MATLAB code and / or Simulink models. The right pane 807 also includes a section 824 to specify various parameters related to storing values in the work area or in a file. Specifying these parameters can modify the program code generated from the model.

8C shows an example of a window 800 in which a user has a hardware implementation option 826 from the left pane 802 selected. The hardware implementation refers to the hardware implementation for which the code is generated. You can then use a hardware board 828 , a device manufacturer 830 and a device type 832 specify. Various other parameters can also be used 834 specify that relate to the hardware implementation. For example, the bit sizes can be specified for data types, such as char, short and long. In 8C the bit size for char is specified as 8 bits, for short as 16 bits and for long as 32 bits.

The configuration settings can also refer to naming rules, such as in 8D shown. 8D shows two versions of a window 800 and 801 in which a user has an icon option 836 in the left pane 802 selects. As in 8D can be seen, contains the right pane 811 a number of different naming rules for things like global variables and global types. The window 801 includes a popup 838 , which explains part of the syntax of the naming rules. The pop-up identifies which macros can be used to derive specific parts of the identifier name for a global variable. In particular, $ M refers to the mangle macro, $ R refers to the root model name macro, $ G refers to the storage class name macro, $ N refers to the mark of the name of the object being identified, and $ V refers to the user token text -Macro. The macro names reflect their functionality. For example, $ G, the storage class macro, is given characters that reflect the storage class of the variables. The choice of naming rules can affect the program code generated by the model.

Another configuration setting that can affect the program code generated by the model is a coding style setting. In the in 8E In the example shown, the user has the "Coding Style" option 840 from the left pane 802 selected to establish the coding style parameters in the right pane 842 are listed. The user can then select a number of different options using check boxes and drop-down lists that can affect the program code generated by the model. For example, the parenthesis level can be set, such as the nominal level option specified in 8E is shown. Parameters such as converting if-then-else patterns into switch case expressions, or keeping static keywords in function declarations can be set. As for code indentation, an indentation style can be set and an indentation size can be selected.

As discussed above, certain settings for code generation that affect the program code generated from the model can be selected. As in 9A shown, shows the window 900 a code generation option 902 that can be selected to the right pane 904 display. Among the values that can be set is a name of a system target file 906 and the programming language 908 in which the code is to be generated. The system target file is a file that is used to convert a model into generated program code. The system target file describes how to generate code for a given target. The right pane 904 also displays a number of options related to the build process 910 concern, such as whether only code should be generated (for example whether to continue and the generated code should be compiled or not) and / or to pack the code and artifacts.

As discussed above, the selection of optimizations for code generation can affect the program code that is generated.

9B shows an example in which an optimization option 910 is selected so that the right pane 911 a number of optimization level settings 912 displays. In the in 9B The example shown specifies a drop-down list 914 the degree of optimization. This level can be minimal, maximal or to be an intermediate value. In the in 9B The example shown is the maximum degree of optimization, which leads to the drop-down list 916 contains the three options of balancing RAM and speed, maximizing execution speed or minimizing RAM. Depending on which option is selected, there may be a number of selection boxes under the detail section 913 be available. For example, options are displayed to activate local block outputs, reuse local block outputs, use expression folding, reuse global block outputs, simplify field indexing, reuse buffers of different sizes and dimensions, etc. Furthermore, options are displayed for how global data access should be optimized and / or how block execution order should be optimized in the generated code. Selecting the option “Balance between RAM and speed” as a priority (see 916) sets the values for many of these other parameters. You can see that after this selection, many of the selection boxes are set or not. Furthermore, values for "Optimize global data access" will be set to "Use globally to store intermediate results" and for "Optimize block execution order in the generated code" to "Improved code execution speed".

9C the appearance of the right pane 911 when the maximum level 914 selected and priority to maximize execution speed 920 is selected. It should be noted that some of the selection of the selection boxes and list boxes have been changed compared to 9B . In particular, in 9C the box "Simplified field indexing" is set and the list "Optimize global data access" has selected "None". This shows the effect that a non-atomic selection has on the settings for atomic sources.

9D shows an example in which the maximum level 914 is selected and the priority minimize RAM 922 is selected. As a result, the selection boxes "Pack Boolean data into bit fields" and "Use buffers of different sizes and dimensions" are selected. Furthermore, in the list box "Optimize block operation order in the generated code", the selected option is "Off". This is an example of how two non-atomic source aspects (that is, maximize optimization and minimize RAM as a priority) affect the selection of atomic source aspects (that is, the selection boxes and list boxes listed). These user interface representations in the 8th and 9 are not intended as a limitation, but rather are intended to be illustrative. It is understood that a number of different user interfaces can be used to select the atomic configuration settings. The atomic configuration settings may contain more or less than those shown.

The exemplary embodiments are set up to determine interdependencies between source aspects and the resulting features in the generated program code. The exemplary embodiments can grasp the relationships between source aspects and assess how the source aspects affect the generated program code. This detection of these relationships enables the associations between components of features in the generated program code and source aspects to be determined. The detected associations enable reverse code generation, where code can be changed and the system derives changes to source aspects in order to achieve the desired code changes.

Several relationships related to the source aspects can be captured and stored in a manner similar to that related to 2C has been described. A first example of such a relationship is a logical and relationship in which several source aspects are necessary to achieve a specific code effect. Like for example in 10A an optimization setting is shown 1006 , which allows identifier-based buffer reuse, along with having multiple signal lines having the same identifier, an example of source aspects that have a logical and relationship. 10A shows a window 1000 , in which configuration settings related to code generation can be set. In this case, the "optimization" settings 1002 selected. The right pane 1004 of the window 1000 has a number of settings that can be set by selecting selection boxes. One of these settings 1006 sets the signal identifiers to guide buffer reuse. In 10A is this selection 1006 selected.

This is an example of a logical and relationship in which several source aspects are necessary to produce an effect in the generated program code. The effect can therefore be associated with the multiple source aspects and indicated by the arrows in 10A can be specified. Often, this type of relationship is between a broad source aspect (for example, a model-wide setting) and a narrower source aspect (e.g. a local setting). In this illustrative case, the "Use signal identifier to guide buffer reuse" setting 1006 the broader source aspect since the setting 1006 affects the entire class of signal identifier instances. The multiple signal lines 1012 and 1014 (see model 1010 ), which have the same identifier, is the narrower source aspect, since this refers to the specific instances of the same identifier for signal lines 1012 and 1014 relates. The resulting component 1016 in the generated program code is in the code listing 1008 shown. If any of these source aspects are absent, as in 10B shown, the component differs 1020 in that there is no buffer reuse in the code listing 1002 of the generated program, in contrast to the component 1016 in 10A .

Source aspect variables can also have a logical or relationship, with several source aspects independently of one another having an effect on the generated program code. As for example in more detail below with reference to 11B As described, a signal name in the generated program code may result from a change in the signal name in the model or a change in the storage class specified for the signal.

Another example of a relationship is an overriding relationship, in which one configuration setting value overrides another, but both settings contribute to an effect in the generated program code.

10C shows an overriding or overlapping relationship between source aspects. In particular, a setting of a storage class to "ExportingFile" or "ExportToFile" for In1 overwrites in targets 1046 of the model data editor 1042 the default storage class for the group of imports, which is determined by the setting 1044 in the window 1040 are specified.

10D shows an example 1060, in which all inports have the default storage class. 10E shows the case where the storage class for In1 has been changed to "ExportierFile" or "ExportToFile" 1062 while the storage class is specified for the other inports (see 1064) to remain with the default storage class.

Another example of a relationship between configuration setting values that is captured by various exemplary embodiments is a combination relationship. In such a combination relationship, multiple configuration setting values in combination result in an effect in the generated program code. An exemplary case is that of a naming rule (see 838 in 8D ), where several parts of a naming rule can come from different source aspect values (such as root model name, storage class name, etc.). For example, like in 838 shown, the global variables have a naming rule "rt $ N $ M". This rule indicates that the “rt” becomes a leading part of the variable name, followed by the name of the object, which in turn is followed by the Mangle macro, as in 8D shown.

Finally, the example embodiments may capture a composite relationship between configuration setting values. Such a composite relationship arises from recursively applying any of the other types of relationships, such as those described above.

The exemplary embodiments may generate recommendations when a user makes a modification to a particular line of the generated program code. 11A presents a flow chart 1100 of the steps that can be taken regarding such recommendations. First in step 1102 made a change to the generated program code. The system notices that the change is associated with a change (step 1104 ). In this example, the subsystem is a Simulink subsystem. - A recommendation is displayed in response to the change (step 1106 ). For example, the system can be configured so that changes to variable names or other changes generate associated recommendations. The recommendation explains how atomic source aspects can be modified in such a way that the generated program code has the changes without the manual editing of the change being necessary. If there are multiple recommendations, the recommendations may be displayed in a prioritized order based on a predetermined prioritization system, or may be displayed without a prioritized order. The priority may be based on information such as past behavior, a preference received (such as from a user), a rule, or some other basis. In some embodiments, the user may have the option to accept the recommendation or not. Therefore, in step 1108 a determination is made as to whether the recommendation will be accepted (that is, the atomic source aspect (s) identified in the recommendation) automatically modified). If the recommendation is not accepted, the identified atomic source aspects will not be modified. However, if the recommendation is accepted, the recommended changes to the atomic source aspects are made in step 1110 and the generated code can (automatically) be regenerated to account for the changes in the source aspects elsewhere in the model.

The recommendations can be determined from the stored information, such as with reference to 2C discussed. Since the decision points of the code generation process and the associated information can be stored, the stored information can be used to identify how to achieve the desired change. For example, one can determine the effects of modifying a storage class from the stored data information, and if one of the effects is the desired change, an appropriate recommendation can be generated.

The system records and stores the appropriate information for recording the interdependencies and for generating recommendations. For example, the system can collect and store information related to the above logical and relationships. This information and the effective scope information can be used to give recommendations as to which source aspects need to be changed in order to obtain the desired feature in the generated program code. An improved human-machine interaction is therefore provided. For example, if a user disables buffer reuse for a single buffer, the recommendation may be to rename the signals with different identifiers in terms of logic and relationship.

In the case of a logical or relationship, the system knows that all sources must be changed to result in the associated component (s) in the generated program code.

In the case of an overwriting or overriding relationship under source aspects, the system similarly captures and stores all source aspects and the overriding or overriding relationship. Therefore, if a default storage class is overwritten, the information of the default storage class is still recorded, together with the overwriting information. Therefore, if the overriding setting is removed, the default storage class can be restored.

11B shows an example 1120, which table recommendations for changes 1122 indicates the results of accepting the change recommendation 1124 on the same line and the side effects 1125 accepting the recommendations. In some embodiments, the method may include displaying, on a display device, information related to how one or more sources and / or source aspects can be modified to effect modification or desired modification of generated program code by code generation by a code generator, information related to the modification or desired change to the generated program code when the one or more sources and / or source aspects are modified, and information regarding whether one or more additional changes and / or side effects are caused to the generated program code when the one or the multiple sources and / or source aspects are modified. The information displayed regarding how one or more sources and / or source aspects can be modified to achieve modification or desired change of generated program code by code generation by a code generator can further specify several ways, such as the one or more sources and / or source aspects can be modified to effect the modification or desired change. In this example, a user would like to change a variable name from "ln1" to "rtln1". There are three recommendations on how to change the variable name in this way.

The first change recommendation is to directly change the corresponding signal name in the model from which the generated program code is generated, as by the element 1126 shown. The resulting change is in the code listing 1128 shown for the generated program code. There are no side effects like through the item 1130 shown.

The second change recommendation is to change the storage class description for the imports from "Default" to "ImportedExtern" or "ImportiertExtern" or "ImportedExtern" in the model by modifying the declaration in the configuration settings setting, as by the element 1132 identified. The result in the generated program code is through the element 1134 shown. The side effects as in the element 1036 identified are that the names of all root inport names change, and that there are changes from struct field names to individual variables.

The third change recommendation changes an identifier naming rule for the naming rule for field names of global type. The resulting changes to the generated program code are in the 1140 shown. The side effect 1142 is that the names of all field names of global variables change.

The results 1128 , 1134 , 1140 can be generated by making a partial code generation regarding changes in the background. For this example, the code generator can generate the variable declaration that contains its name without executing the full code generation. Therefore, he can quickly provide recommendations and expected side effects immediately after the user changes the variable name in the code. The recommendations can appear live to the user or immediately as the user modifies the variable name.

11 C. shows an example of a user interface showing change recommendations. As in 11C shown includes a code listing of generated program code 1150 a change to a field name 1152 from In1 to rtln. As a result of this change, a tooltip 1154 with two recommendations for change 1156 and 1162 displayed. The first recommendation 1156 is a hyperlink menu item that, when selected, is the model 1160 in a user interface element 1158 indicates the recommended change in the model 1160 display. The second menu item 1162 is also a hyperlink menu item that, when selected, displays a user interface item 1164 initiated, which identifies the naming rules and the modification of the naming rules. If the user chooses to change the naming rule (see 1162), the naming rule Edit-Ul 1164 are displayed with the focus on the specific rule to be modified 1166 .

12A shows a computing system 1200 that is suitable to implement exemplary embodiments. The computing system 1200 can be a computing device 1202 with one or two processors 1204 include. The computing device 1202 has access to or contains a memory 1206 . The memory 1206 may include a technical computing environment (TCE), such as the MATLAB technical computing environment, which may also include Simulink, Stateflow, and other components. The memory 1206 can be a code generator 1210 may include and program code 1212 include which is generated by the code generator. The memory 1206 can be one or more graphic models 1214 include. The memory can be a compiler 1216 for compiling code and identifying compilation errors. The memory 1206 may also include a code analyzer that can identify problems with the code, such as coding standard violations, logic errors, code proof errors, bugs, and other artifacts. The programs in the memory 1206 can from the processor 1204 the computing device. The memory 1206 may include non-transitory computer readable storage media for containing computer-executable instructions issued by the processor 1204 of the computing device to perform the functionality of the exemplary embodiments discussed above. The memory 1206 may take a number of different forms, which may include different types of memory devices including, but not limited to, magnetic disk storage, optical disk storage, RAM, flash memory, read only memory (ROM), semiconductor memory, and / or the like.

The computing device 1202 can access a display device 1220 for displaying information, such as the user interface and elements discussed above. The computing device 1202 can access a network adapter 1222 which enables the computing device to interact with networks, including local area and wide area networks.

It should be understood that the exemplary embodiments can also be implemented in a distributed environment. 12B shows an example of a suitable distributed environment 1250 . The distributed environment includes a client 1252 and a server 1254 which over a network 1256 such as the Internet. The client 1252 can be one or more processors 1258 include. Similarly, the server can have one or more processors 1260 include. The client 1252 can access a memory 1262 have, which can include a graphic model. The server 1254 can access a memory 1266 to have. The memory can be a code generator 1268 and a code analyzer 1270 include that of the one or more processors 1260 on the server 1254 can be executed. In some embodiments, the client can 1252 provide the model to the server, which is the code generator 1268 used to generate code, which is then generated by the code analyzer 1270 is analyzed. It is understood that other client server configurations and other distributed environments can also be used to implement the exemplary embodiments.

While exemplary embodiments of the present invention have been described herein, those skilled in the art will understand that various changes in form and detail can be made without departing from the scope of the present invention as defined by the appended claims.

QUOTES INCLUDE IN THE DESCRIPTION

This list of documents listed by the applicant has been generated automatically and is only included for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• US 62778101 [0001]

Claims (26)

A method executed by a processor (1258, 1260) of a computing device (1202), the method comprising: Generate program code (106, 1150, 1212) with a code generator (104, 162, 168, 1210, 1268) for a model (122, 160, 170, 532, 1160) and one or more configuration values for the model (122 , 160, 170, 532, 1160), executing the model (122, 160, 170, 532, 1160) or the program code (106, 1150, 1212) that simulates the behavior of a real world system, wherein the generation includes Record information about behavioral effects of the model (122, 160, 170, 532, 1160) and / or the code generator (104, 162, 168, 1210, 1268) and one or more configuration effects on the program code (106, 1150, 1212) of the model (122, 160, 170, 532, 1160) and / or the code generator (104, 162, 168, 1210, 1268) and the one or more configuration values, with at least some of the behavior effects and the one or more configuration effects from each other are dependent; for a portion of the program code (106, 1150, 1212), determining which of the one or more configuration effects and / or behavioral effects contributed to a feature of the portion of the program code (106, 1150, 1212), the determining comprising Analyzing the recorded information and deriving the behavior effects and the one or more configuration effects, an identity of the one or more configuration effects and / or behavior effects related to the feature of the part of the program code (106, 1150, 1212) contributed or have; and Storing an association between the identified one or more configuration effects and / or behavioral effects that contributed to the feature of the portion of the program code (106, 1150, 1212). Procedure according to Claim 1 analyzing identifies the one or more configuration effects as contributing to the feature. Procedure according to Claim 2 , wherein the one or more identified configuration effects result or result from one or more of the following configuration values: choice of a naming rule (144) for identifiers, choice of a storage class, choice of a solver type, choice of a solver (146, 812, 814), Choice of data to be imported, choice of data to be exported, target hardware details (150), coding style parameters, or choice of a programming language (908) of generated program code (106, 1150, 1212). The method of any preceding claim, wherein the analyzing identifies one or more of the behavioral effects as contributing to the feature. Procedure according to Claim 4 , wherein the one or more identified behavior effects are the result of at least one of the following: a choice of an optimization (128, 164) in the code generation, an added feature of the code generator (104, 162, 168, 1210, 1268) , a patch applied to the code generator (104, 162, 168, 1210, 1268), an algorithm of the model (122, 160, 170, 532, 1160), a modification to the model (122, 160, 170, 532, 1160) to fix an error or a modification to the model (122, 160, 170, 532, 1160) to make the generated program code (106, 1150, 1212) compatible with a standard. Method according to one of the preceding claims, further comprising: Use the saved association to identify which of the one or more configuration values, aspects of the model (122, 160, 170, 532, 1160) and / or aspects of the code generator (104, 162, 168, 1210, 1268) to contributed to the feature of the part of the program code (106, 1150, 1212); and Display of a visual indication or display that indicates that the identified configuration values, aspects of the model (122, 160, 170, 532, 1160) and / or aspects of the code generator (104, 162, 168, 1210, 1268) contributed to the feature of the part of the program code (106, 1150, 1212). Procedure according to Claim 6 , whereby the display is triggered automatically by a programmatic mechanism. Procedure according to Claim 6 displaying in response to a user interface event. The method of any preceding claim, wherein the model (122, 160, 170, 532, 1160) is one of a graphic model (1214) or a textual model. The method of any preceding claim, wherein the one or more configuration values includes at least one atomic configuration value. The method of any preceding claim, wherein at least two source aspects include aspects of the model (122, 160, 170, 532, 1160), aspects of the code generator (104, 162, 168, 1210, 1268) and / or one or more configuration values , have at least one of the following relationships related to causing the one or more configuration effects and / or behavior effects: a logical AND relationship, a logical OR relationship, an overriding or overriding relationship, wherein one of the at least two source aspects is another of the at least overrides or overrides two source aspects, or a combination relationship, each of the at least two source aspects contributing to the one or more configuration effects or the behavior effects. Method according to one of the preceding claims, wherein the feature is one of scope, visibility, lifespan, data type or storage sector. A method executed by a processor (1258, 1260) of a computing device (1202), the method comprising: Identify that generated code has been modified to include a modification, the generated code being generated by a code generator (104, 162, 168, 1210, 1268) from multiple sources (102, 222) that generate a model (122, 160, 170, 532, 1160) and at least one other type of source (102, 222) that affects code generation by the code generator (104, 162, 168, 1210, 1268); Determining how the sources (102, 222) can be modified to effect the modification by code generation by the code generator (104, 162, 168, 1210, 1268); and Displaying information on a display device (1220) related to how the sources (102, 222) can be modified to effect the modification by code generation by the code generator (104, 162, 168, 1210, 1268). Procedure according to Claim 13 , the information displayed specifying several ways in which the sources (102, 222) can be modified to effect the modification. Procedure according to one of the Claims 13 to 14 , further comprising acquiring information regarding relationships between the sources (102, 222) and using the information regarding the relationships in determining how the sources (102, 222) can be modified. Procedure according to one of the Claims 13 to 15 wherein displaying information indicates how the sources (102, 222) can be modified in a prioritized order based on a predetermined prioritization system. Procedure according to Claim 16 wherein the predetermined prioritization system is based on at least one of an earlier behavior, a received preference, or a rule. Procedure according to one of the Claims 13 to 17th , the at least one other source (102, 222) including at least one of configuration information for the code generator (104, 162, 168, 1210, 1268) or modifications made to the code generator (104, 162, 168, 1210, 1268) were. Procedure according to one of the Claims 13 to 18th , wherein the model (122, 160, 170, 532, 1160) is a graphic model (1214). A method executed by a processor (1258, 1260) of a computing device (1202), the method comprising: performing an analysis (108, 110, 112, 422, 424, 426, 442) of a portion of generated code that generates was generated by a code generator (104, 162, 168, 1210, 1268) from several input sources (102, 222) of different types, including a graphic model (1214) and another input source (102, 222) of a type that is not a graphic one Model (1214), the analysis (108, 110, 112, 422, 424, 426, 442) providing results; Determining which of the input sources (102, 222) contributed to the results of the analysis (108, 110, 112, 422, 424, 426, 442); and displaying, on a display device (1220), tracking the results of the analysis (108, 110, 112, 422, 424, 426, 442) to the particular input sources (102, 222) that have contributed to the results. Procedure according to Claim 20 , the analysis (108, 110, 112, 422, 424, 426, 442) identifying one of the following: violations of a coding standard, compilation errors, errors in the program code (106, 1150, 1212) that part of the generated code from a Code Evidence (444) cannot be proven, or changes in the generated code relative to previously generated code generated from the graphical model (1214) by the code generator (104, 162, 168, 1210, 1268). Procedure according to one of the Claims 20 to 21st , wherein the analysis (108, 110, 112, 422, 424, 426, 442) is performed by a code provider (444) that identifies errors in the portion of the generated code. Procedure according to one of the Claims 20 to 22 , wherein the analysis (108, 110, 112, 422, 424, 426, 442) is a static analysis (110, 424). Procedure according to one of the Claims 20 to 22 , wherein the analysis (108, 110, 112, 422, 424, 426, 442) is a dynamic analysis (112, 426). Procedure according to one of the Claims 20 to 24th , wherein the other input source (102, 222) of a type that is not a graphic model (1214) influences the generation of the generated code by the code generator (104, 162, 168, 1210, 1268). A non-transitory computer-readable storage medium that stores instructions that can be executed by a processor (1258, 1260), a computing device (1202) that causes the processor (1258, 1260), a method according to one of the Claims 1 to 25th to execute.

Images