METHOD FOR GENERATING SOURCE CODE

DE502022004223D1Active Publication Date: 2025-06-26DSPACE SE & CO KG
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE502022004223
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-09-10
Filing Date
2022-09-08
Publication Date
2025-06-26
Estimated Expiration
2042-09-08

AI Technical Summary

Technical Problem

Existing methods for generating source code from block diagrams often result in inefficient code due to the creation of unnecessary block variables and optimizations that can lead to increased memory consumption and execution time, particularly when dealing with multi-component variables.

Method used

A method that transforms a block diagram into an intermediate representation, optimizes it by identifying and replacing variable references in block pairs with equal value assignments, and removes assignments where both sides refer to the same variable, thereby reducing the number of variables and improving code efficiency.

Benefits of technology

The method generates more compact and efficient source code, reduces memory requirements, and accelerates execution time by eliminating unnecessary variable copies and optimizations, while avoiding undesirable side effects.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The invention relates to the generation of executable code from a block diagram, in particular for the programming of control devices.

[0002] Control units are used in a wide variety of applications to measure physical process variables and / or to influence a process using connected actuators. For example, this could be an anti-lock brake control system. The time constants that determine the dynamic behavior of the process often require cycle times of 1 ms or shorter, requiring real-time capability from the control unit. For cost reasons, control units often have microcontrollers with small memory and limited computing power, which is why the size and efficiency of the executable code are of great importance.

[0003] To accelerate the design of control units, control strategies are often developed using models in a computing environment such as MATLAB / Simulink. This allows the process and / or controller, or the behavior of the control unit in general, to be initially simulated and the existence of desired properties to be checked. The models can in particular be block diagrams containing blocks that perform operations such as calculations, where a block can, for example, calculate an output signal from several input signals. Block diagrams are usually executed cyclically, with all blocks being permanently stored in memory and each block being executed once per time step. In particular, in each time step, a block can apply one or more operations to input signals from the previous block in order to generate output signals of the current step.Block diagrams can also include a submodel for describing discrete behavior, in which a number of states and transition conditions are defined. Source code for programming the control unit can be generated directly from the models using a code generator. For example, a code generator for generating production-quality source code is described in the document "Production Quality Code Generation from Simulink Block Diagrams," Proceedings of the 1999 International Symposium on Computer-Aided Control System Design, Kohala Coast, Hawaii, by H. Hanselmann et al.

[0004] When models are described in the form of a block diagram, with blocks linked via directed connections or signal connections to exchange data or forward signals, a common approach to code generation is to create a variable in the source code for each output of a block. However, this has the disadvantage that more block variables are usually created initially than are actually necessary. Subsequent optimization can reduce the number of block variables or, in general, the code size. For example, EP 2418577 A1 discloses transforming a block diagram into an intermediate representation and applying at least one optimization to this intermediate representation in order to create an optimized intermediate representation. A variety of other optimizations, which are known per se from compiler construction, can be applied sequentially to create further optimized intermediate representations.Subsequently, C code in particular is generated from the optimized intermediate representation.

[0005] Since every optimization results in a changed intermediate representation, the order of the optimization steps can determine the extent to which the code is optimized overall. For example, a function call between two processing blocks, for which no further information is locally available, can make optimization impossible. Such optimization weaknesses have a particularly strong impact on multi-component variables, since even a simple copy can result in high memory consumption and a considerable execution time. For example, copying a vector or matrix can be performed as an assignment of the entire variable, via assignments in loops, or via element-by-element assignments, so that even an essentially identical operation is not always recognizable as such in the intermediate representation.

[0006] EP3438817A1 discloses a method for generating source code from one or more blocks of a block diagram. For two blocks, each containing a block variable, the identifier of the block variable is compared and an additional check is performed to determine whether the first block and the second block lie in the same region. Only if both conditions are met are the block variables implemented as a single variable. By preventing variables from being grouped together in semantically uncorrelated regions, difficult-to-detect side effects can be avoided.

[0007] For writing to a special medium, such as flash memory with a limited number of possible write operations, US 2018 / 088911 A1 proposes checking whether a block group results in a value change only for parts of a multi-component variable due to an assignment operation, and then generating write instructions only for the individual affected elements. Thus, a special block group is detected and the generated code is modified appropriately for this constellation. However, increased memory requirements and longer-than-necessary execution times may occur for a large number of block groups or operations that do not fall into this specific scheme.

[0008] Against this background, it is an object of the present invention to further develop the state of the art and, in particular, to support the generation of more compact source code while avoiding undesirable side effects.

[0009] This object is achieved by a method for generating source code according to claim 1, a computer program product according to claim 11, and a computer system according to claim 12. Advantageous further developments are the subject of the dependent subclaims.

[0010] A method is therefore provided for generating source code from one or more blocks of a block diagram, which comprises at least two non-virtual blocks and at least one signal connection between two non-virtual blocks, wherein the generation of source code comprises transforming the block diagram into an intermediate representation, successively optimizing the intermediate representation and translating the optimized intermediate representation into source code, wherein the transformation of a non-virtual block comprises creating a reference to a block output variable.According to the invention, the transformation for a first block with access to a multi-component variable comprises a check as to whether a block pair comprising this block and a neighboring block comprises an assignment of equal value, wherein the block pair consists either of the first block and its predecessor or of the first block and its successor, and wherein an assignment of equal value exists if at least a part of the multi-component variable of one block of the block pair is copied unchanged into a part of the multi-component variable of the other block of the block pair.If an assignment of equal value exists, a replacement of variable references occurs, whereby either a reference to the part of the variable in one block of the block pair is replaced by a reference to the corresponding part of the variable in the other block of the block pair, or the reference to an output variable in the first block is replaced by a reference to a data storage variable. Furthermore, the transformation involves removing assignments where both sides refer to the same variable.

[0011] Data or signals can be transmitted via a signal connection; here, a first block outputs one value or, depending on the definition, several related values, and a second block receives these and takes them into account when determining one or more related output values ​​of the second block. Signals can contain scalar variables and / or structured data types such as arrays, as is the case with a bus, for example. If a block involves accessing a multi-component variable, saving these variables can enable considerable savings in memory space and execution time, for example by not generating instructions for copying the individual components or elements of the variable in the code and therefore not having to be executed at runtime.The multi-component variable may be a vector comprising a plurality of variables of the same data type, a matrix comprising a plurality of vectors, a structure comprising a plurality of variables of any data type, or a vector or matrix of structures.

[0012] The transformation step can include several substeps, such as checking a number of rules and adding further code generation information. The optimization according to the invention can, in principle, be performed in any intermediate step of the transformation. In the intermediate representation, the blocks were translated into instructions with a fixed execution order, whereby the structure semantically maps a textual programming language (corresponding to C code). The variable copied unchanged can also be a constant.

[0013] A virtual block is a block that only serves to structure the block diagram but has no direct influence on the simulation. For example, a mux or demux block that combines several signals into a virtual vector or extracts an element signal from a virtual vector are virtual blocks. Processing blocks that calculate an output value and / or assign at least parts of a signal are non-virtual blocks. The reference to a block can, in particular, be a name of the block. Block variables can be explicitly defined in the block or generated automatically, for example, using a signal connection, where a block variable, i.e. a block output variable, is expediently generated for an output signal of a block. The identifiers or names of block variables can be fixed or defined using generation rules.For example, the identifier of a block output variable can include the name of the block and / or the name of the port within the block from which the signal originates. Because the signal flow is tracked in the block diagram and not merely compared with variable names of an intermediate representation, optimization is possible regardless of naming conventions or generation rules.

[0014] Advantageously, the method according to the invention identifies different block pairs or block groups and block variables that result in assignments of equal values, and overwrites one of the variables of the identified block pair in order to trigger assignments between the same variable or the same variable parts, which then do not need to be created when generating the intermediate representation, or to perform assignments of the same value to the same variable, so that at least one of the variables is omitted. This not only generates more efficient code overall, but also accelerates optimization on the intermediate representation, since fewer variables or code patterns need to be considered right from the start.

[0015] Starting with a first block with access to a multi-component variable, the block diagram is transformed to check whether a block pair consisting of this block and a neighboring block contains an assignment of equal value. The block pair can consist either of the first block and its predecessor or of the first block and its successor. An assignment of equal value occurs when at least part of the multi-component variable of one block in the block pair is copied unchanged into part of the multi-component variable of the other block in the block pair. It is also possible for the entire multi-component variable to be copied unchanged, whereby the part comprises 100% or the entire variable.The procedure is equally applicable to variables as well as to corresponding variable parts, i.e. the part of the block variable of one block that is copied unchanged and the part of the block variable of the other block that receives the unchanged components.

[0016] If a part of the multi-component variable of the first block of the block pair in the signal flow is copied unchanged into a part of the multi-component variable of the block following in the signal flow, this is an assignment with the same value. Variable references are then replaced, whereby either a reference to the part of the variable of the first block of the block pair in the signal flow is replaced by a reference to the corresponding part of the variable of the block following in the signal flow, or the reference to an output variable of the first block is replaced by a reference to a data storage variable. The type of replacement depends on the block types of the two blocks in the block pair. Furthermore, transformation involves removing assignments where both sides refer to the same variable or the same part of the variable.

[0017] Preferably, one or more of the following types of blocks are checked for an equal value assignment: A DataStore Read block that reads from a data storage variable, a DataStore Write block that writes to a data storage variable, a Switch block that selectively connects an output to one of several inputs, a Bus Outport block that models an output to a bus, an Outport block that models an output, and / or a Delay block that outputs an input signal with a time step delay.

[0018] In the case of a DataStore read block, this is preferably considered together with the subsequent block, and if an assignment of the same value exists, a reference to an output variable of the DataStore read block is replaced by a reference to the corresponding part of the data storage variable, and / or in the case of a DataStore write block, switch block, bus outport block, outport block and / or delay block, this is considered together with the predecessor block, and if an assignment of the same value exists, a reference to an output variable of the predecessor block is replaced by a reference to a variable of the first block. An output of the predecessor block is directly connected to an input of the subsequent block via a signal. The (block) output variable of the DataStore read block can be a buffer variable or the data storage variable or the DataStore memory variable.In a DataStore write block, a (block) output variable of the previous block is conveniently replaced by the datastore variable or the corresponding part of the datastore variable.

[0019] Based on block properties, an equal-value assignment is identified, enabling optimization. The optimization according to the invention is also simple and possible for complex signals or multi-component block variables, regardless of the number of components. Only a few rules need to be checked, which affect a few blocks and the signals connected to them. This makes it easy to verify the correctness of the substeps and ensures that identical modeling also leads to equally efficient code.

[0020] If a block diagram comprises a plurality of blocks whose block type corresponds to a block type to be checked for an equal-value assignment, a check for an equal-value assignment is preferably carried out for each block of the plurality of blocks in accordance with the block type, and if an equal-value assignment is present, variable references are replaced.

[0021] A possible replacement is conveniently checked for all blocks of the appropriate type present in the block diagram. In particular, for one of the blocks, all possible block pairs from the block and a neighboring block in the signal flow, especially directly adjacent blocks, are checked for the presence of an assignment of the same value. If so, the corresponding references to variables are replaced. Depending on the type of block, the predecessor or successor block is conveniently considered part of the block pair. Virtual blocks can be skipped to determine neighborhood relationships.

[0022] Preferably, block diagrams are defined hierarchically, wherein a block in a higher level can comprise several blocks of a lower level, wherein blocks of a lower level are assigned to a block of a higher level, and when a DataStore read block is checked for an assignment of the same value, a search is carried out in a comprehensive hierarchical block, in particular an atomic hierarchical block, for DataStore write blocks that access the same data storage variable.

[0023] Particularly preferably, if a DataStore read block and a DataStore write block with access to the same data store variable have been found in the comprehensive hierarchical block, it is checked whether the DataStore read block and the DataStore write block are at least partially connected in the signal flow, so that the part of the data store variable which is read in the DataStore read block has a non-empty intersection with the part of the data store variable which is written in the DataStore write block, wherein at least one block in the signal flow lies between the DataStore read block and the DataStore write block, wherein the block or blocks lying in between comprise at least one non-virtual processing block which processes an input variable in order to generate an output variable.As an additional condition, it is checked whether the block(s) in between have a processing order such that at least one processing block is executed before the DataStore Write block, and if this additional condition is met, the portion of the output variable of the DataStore Read block corresponding to the intersection is replaced by the portion of the datastore variable corresponding to the intersection.

[0024] If the DataStore read block and the DataStore write block accessing the same datastore variable are not connected in the signal flow, the blocks can be checked independently of each other for the existence of an equal-value assignment. A signal flow connection can only exist if the part of the datastore variable read from in the DataStore read block has a non-empty intersection with the part of the datastore variable written to in the DataStore write block. The intersection is empty if other components of the variable are accessed, for example, other elements of a vector or parallel parts in the bus hierarchy. For a structure S, for example, Sa would have a non-empty intersection with Sab, but no intersection with Scb.Processing can also be the assignment of a new value to parts of a variable, so that a block that makes a dynamic assignment also represents a processing block in this sense. If multiple DataStore write blocks in the comprehensive hierarchical block access the same data store variable as the DataStore read block, the existence of a forward data flow relationship, i.e., that the data store variable is read from before the data store variable is written to, is checked for each of the DataStore write blocks. Alternatively, it can also be specified that only a clear sequential execution order of the blocks accessing the data store variable and the blocks in between is required, i.e., either read first or write first, to allow for optimization. The check of the preconditions orThe additional conditions such as the clear sequential execution order ensure that no undesirable side effects occur as a result of the optimization according to the invention.

[0025] If the additional condition is not initially met, the processing order of at least one of the intermediate blocks is preferably changed to fulfill the additional condition. If a processing order is not specified for one or more of the blocks, neither by the modeling itself nor by technical circumstances, this provides degrees of freedom to reorder the blocks so that the preconditions or additional conditions can be fulfilled.

[0026] Particularly preferably, if a DataStore read block and a DataStore write block with access to the same data storage variable have been found in the comprehensive hierarchical block, it is checked whether the DataStore read block and the DataStore write block are at least partially connected in the signal flow, so that the part of the data storage variable which is read in the DataStore read block has a non-empty intersection with the part of the data storage variable which is written in the DataStore write block, wherein at least one block in the signal flow lies between the DataStore read block and the DataStore write block, wherein the block or blocks lying in between comprise at least one non-virtual processing block which processes an input variable in order to generate an output variable.In this case, for a predecessor block of the DataStore-Write block, namely the processing block closest to the DataStore-Write block in the signal flow, it is checked as additional conditions whether the portion of the block output of the predecessor block corresponding to the intersection is connected to the DataStore-Write block without a signal flow branch, and whether the block output variable of the predecessor block matches the dimension and data type with the at least partial connection in the signal flow, whereby if these additional conditions are met, the block output variable of the predecessor block is replaced by the portion of the data storage variable corresponding to the intersection.

[0027] Preferably, block diagrams are defined hierarchically, wherein a block in a higher level can comprise several blocks of a lower level, wherein blocks of a lower level are assigned to a block of a higher level, and wherein, when a first DataStore write block is checked for an assignment of the same value, a search is carried out in a comprehensive hierarchical block, in particular an atomic hierarchical block, for further DataStore write blocks that access the same data store variable, and that, as a reason for excluding the replacement of references to variables in the block pair of the first DataStore write block, for each further DataStore write block found, it is checked whether this writes to a part of the data store variable that is also described by the first DataStore write block,Where, despite the existence of an assignment of the same value, a reference to the output variable of the predecessor block is not replaced by a reference to the part of the data store variables described by the first DataStore Write block if the exclusion reason exists.

[0028] If multiple DataStore write blocks access the same part of a datastore variable, the write order must be fixed and immutable to avoid unpredictable side effects, otherwise optimization is not performed.

[0029] Preferably, variables can be specified as states, whereby even if an assignment of the same value exists between a first variable and a second variable of a block pair, a reference to the first variable is only replaced by a reference to the second variable if the first variable is not specified as a state and / or the second variable is specified as a state. Preferably, the second variable can assume the role of a state if it has a static storage duration and an initial value; then, if the initial value is the same, a first variable specified as a state can also be replaced by the second variable.

[0030] In particular, a delay block contains a state variable. Since a state variable influences the output values ​​of the following time step, it may only be replaced by an identical state variable to avoid incorrect behavior.

[0031] According to the invention, despite the existence of an equal-value assignment between a first variable and a second variable of a block pair, a reference to the first variable is not replaced by a reference to the second variable if one or more of the exclusion reasons listed below apply, whereby in the case of an equal-value assignment only for parts of the first and second variables, only these parts are considered for the exclusion reasons: The first and second variables have different dimensions. At least one element of the first variable has a different data type than the corresponding element of the second variable. The first variable is specified as necessary. Due to signal flow branching and / or the execution order of the connected blocks, an unpredictable data flow occurs.

[0032] A variable is specified as necessary in particular if a user has manually assigned it a specific data type. The method according to the invention particularly optimizes or eliminates automatically generated block variables. If the first variable and the second variable have the same dimension (i.e., not a different one), they also occupy the same number of memory locations, so that the reference to these variables can be swapped (the same applies to parts of variables). In particular, a partial copying of the elements of the data storage variable or the DataStore Memory can take place in a DataStore read block DSR and a connected DataStore write block DSW, such as an assignment DSR[0..4] = DSM[3..7], in which a partial copying of a vector with dimension 5 is performed.

[0033] Particularly preferably, block diagrams are defined hierarchically, wherein a block at a higher level can comprise several blocks of a lower level, wherein blocks of a lower level are assigned to a block of a higher level, wherein all blocks at the level of the first block and all blocks assigned to these blocks are checked for the existence of an exclusion reason.

[0034] The invention further relates to a method for configuring a control unit, wherein the control unit comprises at least one computing unit and preferably has at least one sensor and / or at least one actuator in order to acquire data of a physical process and / or to act on it, the method comprising the steps a. reading in a block diagram, b. generating a source code using a method according to the invention, c. compiling the source code for the computing unit so that an executable code is generated, d. transferring the executable code to the control unit, and e. storing the executable code in a non-volatile memory of the control unit and / or executing the executable code by the computing unit of the control unit.

[0035] Furthermore, the invention relates to a computer program product having a computer-readable storage medium on which instructions are embedded which, when executed by a processor, cause the processor to be configured to carry out a method according to the invention.

[0036] Furthermore, the invention relates to a computer system comprising a human-machine interface, a non-volatile memory and a processor, wherein the processor is configured to carry out a method according to the invention.

[0037] The invention is explained in more detail below with reference to the drawings. Similar parts are labeled with identical designations. The illustrated embodiments are highly schematic, meaning that the distances and the lateral and vertical dimensions are not to scale and, unless otherwise stated, do not have any deducible geometric relationships to one another.

[0038] It shows: Figure 1 shows a preferred embodiment of a computer system, Figure 2 shows a schematic representation of the software components preferably present on a computer system, Figure 3 shows a schematic flow chart of an embodiment of the method according to the invention for generating source code, Figure 4 shows a section of a block diagram with a dynamic assignment, Figure 5 shows a section of a block diagram with a read-modify-update mechanism, Figure 6 shows a section of a block diagram with a read-update-use mechanism, Figure 7 shows a section of a block diagram with parallel and returned delay states, Figure 8 shows a section of a block diagram with an iterated system, and Figure 9 shows a section of a block diagram with switch blocks.

[0039] Figure 1shows an exemplary embodiment of a computer system PC. This has a processor CPU, which can in particular be implemented as a multi-core processor, a main memory RAM and a bus controller BC. The computer system PC is preferably designed to be operated directly manually by a user, with a monitor DIS being connected via a graphics card GPU and a keyboard KEY and a mouse MOU being connected via a peripheral interface HMI. In principle, the human-machine interface of the computer system PC could also be designed as a touch interface. The computer system further comprises a non-volatile data storage device HDD, which can in particular be implemented as a hard disk and / or solid state disk, and an interface NET, in particular a network interface. A control unit ES can be connected via the NET interface.In principle, one or more interfaces, particularly wired interfaces, can be present on the PC computer system and each can be used to connect to a control unit (ES). A network interface based on the Ethernet standard can be used; the NET interface can also be wireless, particularly as a WLAN interface or based on a standard such as Bluetooth.

[0040] The control unit ES can be implemented as a production control unit or as an evaluation board for a target platform. It preferably includes a NET interface for connecting to the computer system PC, a microcontroller MCR with an architecture different from the computer system's processor, a RAM, and a non-volatile memory NVM. If the control unit ES is present, a processor-in-the-loop simulation of the generated code can preferably be performed.

[0041] In Figure 2 A diagram of the software components typically installed on the PC computer system is shown. These use operating system mechanisms, for example, to access the non-volatile memory (HDD) or to establish a connection to an external computer via the NET network interface.

[0042] A Technical Computing Environment (TCE) enables the creation of models and the generation of source code from the models. In a modeling environment (MOD), models of a dynamic system can be created, preferably via a graphical user interface. These can be block diagrams comprising several blocks and describing the temporal behavior and / or internal states of a dynamic system. At least some of the blocks are connected via signals, i.e., directed connections for exchanging data, which can be scalar or composite. Blocks can be atomic, i.e., from the perspective of the surrounding blocks, they form a unit in which all input signals must be present at the beginning of a calculation step and all output signals must be present at the end of a calculation step.When block diagrams are hierarchical, a plurality of blocks at a lower level can describe the structure of a block at a higher level. Hierarchical or compound blocks, even if they are atomic, can contain a plurality of blocks at a lower level. Compound blocks can, in particular, be subsystems; subsystems can have additional properties, such as implementation in a separate function and / or triggering the execution of the subsystem via a dedicated signal. Special blocks can be arranged within subsystems to further specify the properties of the subsystem. The computing environment TCE comprises one or more libraries BIB from which blocks or building blocks can be selected for building a model. In a scripting environment MAT, instructions can be entered interactively or via a batch file to perform calculations or modify the model.The TCE computing environment also includes a simulation environment (SIM), which is configured to interpret and execute the block diagram to investigate the system's temporal behavior. These calculations are preferably performed using high-precision floating-point numbers on one or more cores of the computer system's microprocessor (CPU).

[0043] From a created model, source code can be generated using a PCG code generator, preferably in a programming language such as C. Additional information about the model, in particular about the block variables, is expediently stored in a DDT definition data collection. Value ranges and / or scaling are expediently assigned to the block variables to support calculation of the model using fixed-point instructions. Desired properties of the source code, for example, conformity to a standard such as MISRA, can also be set or stored in the DDT definition data collection. Expediently, each block variable is assigned to a predefined variable type, and one or more desired properties are set, such as the admissibility of optimizations such as combining variables.The PCG code generator preferably evaluates the settings of the DDT definition data collection and takes them into account when generating the source code. The DDT definition data collection can have a tree structure or be stored as a simple file in a computer system memory; alternatively, the definition data can be stored in a dedicated database system. The DDT definition data collection can have a program interface and / or import / export functions.

[0044] The computer system PC has a compiler COM and a linker LIN, which are conveniently configured to generate binary files executable on an ECU ES and / or the computer system PC. In principle, a variety of compilers can be available, particularly cross-compilers for different target platforms, to support ECUs or evaluation boards ES with different processor architectures.

[0045] Figure 3 shows a schematic flowchart of an embodiment of the method according to the invention for generating source code. The method can be executed entirely by a processor of an exemplary embodiment of the computer system PC; however, it can also be designed for execution in a client-server environment with a host computer and one or more servers connected via a network, with computationally intensive steps being performed on the servers.

[0046] In step S1 (reading the block diagram), a block diagram is read in. The block diagram comprises at least two processing blocks connected by signals and may contain a plurality of additional blocks. Reading the block diagram expediently also includes reading at least one block property and / or settings relevant for code generation, such as the data type of a variable, from the definition data collection DDT.

[0047] In step S2 (Transform into intermediate representation), the selected model is transformed from one or more blocks of the block diagram into an intermediate representation, which preferably comprises one or more hierarchical graphs. This can in particular be a data flow graph, a control flow graph or a tree structure. In addition to the block diagram, additional information from a definition data collection DDT is expediently also taken into account when generating the intermediate representation or is incorporated into it. This can also include situations in which elements are generated based on information in the definition data collection DDT or properties of elements or settings relevant for code generation, such as the data type of a variable, are extracted from the definition data collection DDT.

[0048] In step S3 (Another block pair?), a check is made to determine whether the block diagram contains another, previously unconsidered block pair that could potentially be optimized according to the invention. If this is the case, step S4 follows; otherwise, execution continues in step S8.

[0049] In step S4 (equal-value assignment?), the currently unconsidered block pair is checked to determine whether at least part of a variable can be assigned to another variable (or part of this variable) without changing its value. If this is the case, step S5 follows; otherwise, execution continues in step S3 to determine whether another block pair can be checked.

[0050] The invention is based on the idea of ​​identifying block ensembles, especially block pairs, and block variables that lead to assignments of the same value during the transformation into an intermediate representation within atomic subsystems. By overwriting block variables or replacing references, assignments can be triggered between the same variable or variable parts, which then do not need to be created during block code generation, or assignments of the same value can be made to the same variable—usually a state variable—so that at least one of the variables is omitted.

[0051] Because the optimization occurs during the transformation into an intermediate representation, all information from the block diagram is still available. This makes it possible, in particular, to consider the results of block diagram transformations and / or to select or enforce a suitable execution order for the blocks for optimization, provided the appropriate degrees of freedom are available. Furthermore, it is possible to select a suitable order to perform the corresponding replacements multiple times or with maximum benefit.

[0052] In one embodiment of the invention, outputs of blocks that can be considered as atomic units, in particular atomic systems, can be replaced by the outputs and / or states of subsequent blocks if appropriate modeling is available. This replacement preferably takes place before the interior of the atomic system is considered; when checking for reasons for exclusion, the initial value, initialization behavior, and state reset behavior are preferably taken into account.

[0053] In step S5 (Is there a reason for exclusion?), a check is performed to determine whether there is a reason for exclusion that makes optimization according to the invention impossible. If this is the case, execution continues in step S3. Possible reasons for exclusion from optimization include, in particular: The variables involved differ in dimensional width, data type, and / or scaling. The block diagram contains signal line branches, which would result in the loss of a necessary buffer or state if a variable is eliminated. There is an unknown data flow, for example, due to ∘ a release of variable merging ∘ a call to external functions ∘ additional DataStore write blocks and / or DataStore read blocks with no clear data flow relationship to the blocks currently being considered. The variable to be eliminated is specified in such a way that it must appear in the initial code pattern.

[0054] If there are no reasons for exclusion, execution continues in step S6 (Replace Variable References), where a reference to a variable of an equal-value assignment is replaced with a reference to the variable of the corresponding neighboring block. Subsequently, in step S7 (Remove Identical Assignment), any identical assignment caused by the exchange of the variable reference is removed from the intermediate representation. Execution then continues in step S3 to process any additional block pairs that may exist.

[0055] In step S8 (further optimization of intermediate representation), the hierarchical graphs are optimized to reduce the number of required variables and / or memory consumption, such as stack occupancy, and / or the number of operations or processor instructions, and / or the execution time of the source code. This optimization may comprise a plurality of intermediate steps in which further intermediate representations between the model / block diagram and the source code / program text are generated. In particular, it may be provided that, in each intermediate step, a set of original hierarchical graphs is converted into another set of modified hierarchical graphs, whereby one or more optimization rules are applied. Various strategies such as "constant folding" or the elimination of "dead code" can be applied during the optimization.In principle, it is possible for several variables generated during the transformation to be combined in step S. However, according to the invention, several variables of the block diagram are preferably combined during the transformation into an intermediate representation in such a way that the first intermediate representation already contains only one variable.

[0056] In step S9 (translate intermediate representation into source code), the optimized intermediate representation or the optimized hierarchical graphs resulting from all the intermediate steps performed are translated into source code of a textual programming language, such as C code in particular. Further optimization can also be performed in this step, in particular such that the generated instructions represent a subset of the instructions principally encompassed by the language and / or the generated control structures represent a subset of the control structures principally encompassed by the language. This makes it possible to comply with precisely defined rules. Alternatively or additionally, additional information, such asto create a reference between the program line and the block of the block diagram and, in particular, to include it in the source code in the form of comments in order to improve the readability of the source code and / or to simplify debugging.

[0057] During or after code generation, information about the current block diagram or code generation results, such as warnings, can be stored in the definition data collection. This information can be used, for example, to influence compilation of the generated source code or to provide metainformation for other tools, such as calibration information in ASAP2 format or information for generating an intermediate layer according to the AUTOSAR standard. In alternative embodiments of the invention, it may be provided to generate code in a hardware description language or a configuration of a programmable hardware component from the block diagram.

[0058] Exemplary embodiments of the invention are explained below using some sections of block diagrams.

[0059] Figure 4shows a section of a block diagram with a dynamic assignment. The section includes a DataStore Read block, which reads from a data store A, an Assignment block, and a DataStore Write block, which writes to the data store A. The Assignment block receives as input signals the vector value read from the data store A, an index Idx1, and a scalar replacement value U. After the previous value of A at location Idx1 has been replaced by the replacement value U, the Assignment block outputs the resulting signal to the DataStore Write block.

[0060] For this section, a direct implementation without Optimization generates the following code: for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { Sa1_Data_Store_Read1[Aux_S32] = A[Aux_S32];} for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { Sa1_Assignment [Aux_S32] = Sal_Data_Store_Read1 [Aux_S32];} Sa1_Assignment[Idx1] = U; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A[Aux_S32] = Sa1_Assignment[Aux_S32];}

[0061] A best possible optimization would result in the following code: A [Idx1] = U;

[0062] Compared to the non-optimized code, the buffer variables Sa1_Assignment and Sa1_Data_Store_Read1 have been eliminated.

[0063] In a method according to the invention, the following

[0064] Initial conditions identified: Equal value assignment in the block code pattern of the DataStore read block Equal value assignment at the input of the assignment block Equal value assignment in the block code pattern of the DataStore write block No multiple modification of the DataStore variable No read / write order conflicts between DataStore read and / or write blocks

[0065] This allows Sa1_Data_Store_Read1 to be replaced by the A ' of the DataStore memory at the output of the DataStore read block. Here and in the following, dashes appended to an identifier indicate whether this refers to the left or upstream block in the signal flow—in which case it is marked with one dash—or to the right or downstream block in the signal flow—in which case it is marked with two dashes. Furthermore, Sa1_Assignment can be replaced by the A " of the subsequent DataStore write block at the output of the Assignment block.

[0066] Thus, one obtains for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A' [Aux_S32] = A[Aux_S32];} for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A" [Aux_S32] =A' [Aux_S32];} A" [Idx1] = U; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A[Aux_S32] = A'' [Aux_S32];} as possible initial code (for better readability, the explanation is based on C source code, even though the optimization actually occurs before translation into source code). The dashes here and below only serve to clarify the reference to one of the blocks and do not change the fact that they refer to the same identifier in each case.

[0067] According to the invention, transforming the block diagram into the intermediate representation comprises removing those assignments where there is a reference to the same variable on both sides (as indicated above, none of the exclusion reasons apply).

[0068] Thus, the three "A[Aux_S32] = A[Aux_S32]" assignments including surrounding loops are not created at all, ie the result is immediately: A" [Idx1] = U;

[0069] The method according to the invention therefore offers the following advantage: Unnecessary statements and variables are not generated in the first place, which immediately results in efficient code and obviously unnecessary variables and statements do not have to go through the further optimization steps or code generation at all.

[0070] In the Figure 4 The section of a block diagram shown models reading from a data storage variable, changing the value of a portion of the variable, and writing at least the changed portion of the variable to the same data storage. However, even if the value of the variable is written to another data storage variable, the method according to the invention can be used to generate more efficient source code.

[0071] So, if the DataStore variable of the DataStore write block were something else, such as B, then "A" would be replaced by "B" in the initial code. The two dashes indicate that the identifier refers to the right-hand block. Without optimization, the initial code would be as follows: for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A' [Aux_S32] = A[Aux_S32];} for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { B" [Aux_S32] = A' [Aux_S32];} B" [Idx1] = U; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { B [Aux_S32] = B" [Aux_S32];}

[0072] By removing such assignments in which there is a reference to the same variable on both sides, i.e. by omitting the unnecessary identical copying actions, the following code is obtained: for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { B" [Aux_S32] = A' [Aux_S32];} B" [Idx1] = U;

[0073] Without further information, this is the best possible code pattern. Advantageously, the method for generating source code according to the invention does not require a joint analysis of all three blocks; rather, a consideration of block pairs is sufficient. Therefore, the following two parts are considered here: 1. Does the Data Store Read block output have no signal line branch or a clear data flow-driven sequence relative to any Data Store Write blocks for all successors? Then the dedicated block output variable can be replaced by the portion of the Data Store memory variable selected for dynamic assignment. 2. Does the block output variable of the predecessor block of the Data Store Write input have the same properties as the selected portion of the Data Store memory variable, and are there no signal line branches? Then the block output variable of the predecessor block can be replaced by the selected portion of the Data Store memory variable.

[0074] Figure 5shows an excerpt of a block diagram with a read-modify-update mechanism. The excerpt includes a DataStore-Read block, which reads from a data store A, a Selector block, a calculation block, an Assignment block, and a DataStore-Write block, which writes to the data store A. The Selector block receives the vector value read from the data store A and an index Idx as input signals, and supplies the value of the element of the input vector located at position Idx1 to the subsequent calculation block as output. The DoSomething calculation block is designed as a hierarchical block and can apply any operations before the result is output to the Assignment block as a scalar replacement value U. In addition to the scalar replacement value U, the Assignment block receives the vector value read from the data store A and the index Idx1 as input signals.After the previous value of A at location Idx1 has been replaced by the replacement value U, the Assignment block outputs the resulting signal to the DataStore Write block.

[0075] The key point here, compared to the previous example, is the branch to the Selector block. The Data Store Read block output variable buffers the Data Store memory value at the time of reading. If the Selector block code, or in the case of static selection, a successor to the Selector block, is potentially executed after the Data Store Write or its predecessor block, then the Data Store Read block output cannot be eliminated. If "DoSomething" is a chain of blocks that also drive the U input of the Assignment block, or if "DoSomething" is an atomic system, then the correct execution order of the blocks is guaranteed, and substitution of the block variables is possible. This results in the following: Source code: for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A' [Aux_S32] = A[Aux_S32];} Sa1_Selector = A' [Idx1]; / * Output variable of the selector block * / ... / * Do Something calculates U and reads Sa1_Selector * / for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A" [Aux_S32] = A' [Aux_S32];} A" [Idx1] = U; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A[Aux_S32] = A' [Aux_S32];}

[0076] After removing unnecessary assignments, we get: Sa1_Selector = A' [Idx1]; / * Output variable of the selector block * / ... / * Do Something calculates U and reads Sa1_Selector * / A" [Idx1] = U;

[0077] By checking and, if necessary, adjusting the block execution order, optimized source code can be generated even if there is a branch in the signal flow.

[0078] Figure 6shows a section of a block diagram with a read-update-use mechanism, which combines reading a data store variable, changing the value, and writing back part of the variable with a calculation based on the changed variable. The section includes a DataStore-Read block that reads from a DataStore memory A, an Assignment block, and a DataStore-Write block that writes to the data store A. In addition to the scalar replacement value U, the Assignment block receives the vector value read from the data store A and the index Idx1 as input signals. After the previous value of A at location Idx1 has been replaced by the replacement value U, the Assignment block outputs the resulting signal to the DataStore-Write block and a calculation block performCalculation.The output signal of the DataStore Read block is also connected to a Selector block, which receives the vector value read from data store A and an index Idx1 as input signals, and outputs the value of the element of the input vector located at position Idx1 as output signal. This output signal is connected to the trigger input of the performCalculation calculation block, which can perform any operation on the updated value of the data store variable before outputting the result to an output port sumofValues.

[0079] The key difference here from the previous situation is that there is no guarantee that the Selector block will be executed before the DataStore Write block. According to the state of the art, the following code is typically generated during code generation: for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { Sa1_Data_Store_Read[Aux_S32] = A[Aux_S32];} for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { Sa1_Assignment [Aux_S32] = Sa1_Data_Store_Read [Aux_S32];} Sa1_Assignment [index] = value; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A[Aux_S32] = Sa1_Assignment[Aux_S32];} Sa1_Selector = Sa1_Data_Store_Read1[index]; if (Sa1_Selector) { sumOfValues ​​= performCalculation (Sa1_Assignment);}

[0080] This means that optimization on the intermediate representation can no longer achieve anything and the block output variable Sa1_Data_Store_Read is left over unnecessarily.

[0081] Optimized code for the block pair consisting of the DataStore Read block and the Selector block can be generated if the calculation order of the blocks is ensured, i.e., the Selector block is always executed before the DataStore Write block. According to a preferred embodiment of the invention, the production code generator expediently checks whether the execution of the Assignment block and the Selector block can be freely shifted relative to each other, and if so, establishes a virtual data flow dependency between the Selector block and the Assignment block (as the predecessor block of the DataStore Write block). This enforces a suitable execution order of the blocks and ensures timely execution of the Selector block.

[0082] Furthermore, optimization of the block pair consisting of an Assignment block and a DataStore Write block can only occur if no DataStore Read block or—in the case of the elimination of the DataStore Read output variable—a DataStore Read successor block is executed after the Assignment block. Only then can the Assignment block, as the predecessor of the DataStore Write block, receive the DataStoreMemory variable as its output variable, or the output variable of the Assignment block be removed.

[0083] Signal line branches therefore require more than two blocks to be checked to ensure the validity of the optimization according to the invention. This also applies when multiple DataStore read and write blocks access the same DataStore memory block.

[0084] If the required execution order of the blocks connected in the signal flow is maintained, the following code results: for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A' [Aux_S32] = A[Aux_S32];} Sa1_Selector = A' [index]; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A" [Aux_S32] = A' [Aux_S32];} A" [index] = value; for (Aux_S32 = 0; Aux_S32 < 20; Aux_S32++) { A[Aux_S32] = A" [Aux_S32];} if (Sa1_Selector) { sumOfValues ​​= performCalculation(A'');}

[0085] Nach dem Entfernen überflüssiger Zuweisungen einer Variablen auf sich selbst erhält man: Sa1_Selector = A' [index]; A" [index] = value; if (Sa1_Selector) { sumOfValues ​​= performCalculation (A");}

[0086] Figure 7shows a section of a block diagram with parallel and feedback states of delay blocks that delay a signal by one time step. A subsystem receives an input signal In. The input signal is applied to a summation block S, whose output is connected to both an output port and a first delay block with state X1. The output of the delay block is connected to a first input of a selector block, which also receives a constant and can alternatively output it. The output of the selector block forms a second input of the summation block S. The output signal Out of the subsystem is connected to a second unit delay block, which has a state X2. Such modeling with similar delay blocks occurs, for example, when using library blocks from a block library.

[0087] Unless atomic system boundaries force different update orders of the two states or other initial values ​​are specified, X1 and X2 can get the same state variable: ... / * Use X1 * / S = ...; ... / * Use X2 * / ... / * Use S * / X1 = S; ... X2 = S;

[0088] This results in the following code, where the unnecessary double definition is removed by the optimization later: ... / * Use X1 * / S = ...; ... / * Use X1 * / ... / * Use S * / ... X1 = S;

[0089] If there are no parallel states that can be optimized in this way, then it is possible for feedback delays to replace the previous block output variable. Thus, if the represented subsystem is atomic, one obtains Sa2_Out1 as the block output variable of the subsystem: ... / * Use X1 * / S = ...; Sa2_Out1 = S; X1 = S; ... / * Use X2 * / ... / * Use Sa2_Out1 * / ... X2 = Sa2_Out1;

[0090] An inventive optimization of equal-value assignments results in the following code: ... / * Use X1 * / X1 = ...; Sa2_Out1 = X1; ... / * Use X2 * / ... / * Use Sa2_Out1 * / ... X2 = Sa2_Out1;

[0091] If the atomic system is a conditionally executed subsystem, the outputs receive initial values ​​and, if the storage duration is static, can assume the role of a state in the generated production code. If such a state has the same initial value as X1, then it is a parallel state, similar to X2 in the case without conditional execution. Therefore, the state can also be replaced by the output of the atomic system, provided the initial values ​​are the same: ... / * Use Sa2_Out1 * / Sa2_Out1 = ...; ... / * Use X2 * / ... / * Use Sa2_Out1 * / ... X2 = Sa2_Out1;

[0092] In this case, unless the system is executed conditionally or the user has specified a specification for the system output and the Unit Delay State has sufficient visibility, it is more advantageous to swap the order, i.e. to first replace the block output with the system output (regardless of whether and how initialized) in order to circumvent the condition of equal initialization: ... / * Use X1 * / X1 = ...; ... / * Use X2 * / ... / * Use X1 * / ... X2 = X1;

[0093] Figure 8shows a section of a block diagram with an iterated system. In iterated systems, non-scalar signals may result in inner loops that negatively impact performance, particularly when constructing a vector or matrix using an assignment block. The processing of vector signals is shown. A for-iterator block receives a signal Width via a first input port. This signal specifies the number of iterations, i.e., how often the for-iterator block executes connected blocks during a time step. The output of the for-iterator block is connected to an index input Idx1 of a selector block and an assignment block A. The selector block selects an element of a vector input signal received at a second input port and passes it on to a processing block doSth, which is additionally connected to a third input port.The output signal Out1 of the processing block doSth is fed to the assignment block A as the new value U. The output of the assignment block is fed back via a delay block as the vector Y0 to be changed and is output via an output port O.

[0094] A code generation for the block diagram section shown with the returned delay block results in: Sa2_Assignment_FirstRun = 1; for (iterator = 0; iterator <= 9; iterator++) { Sa2_Selector = in2[iterator]; U = doSth(Sa2_Selector, in3); if (Sa2_Assignment_FirstRun) { for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { Sa2_Assignment[Aux_S32] = X_Sa2_UnitDelay[Aux_S32];} Sa2_Assignment_FirstRun = 0;} Sa2_Assignment[iterator] = U; for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { X_Sa2_UnitDelay [Aux_S32] = Sa2_Assignment [Aux_S32];}

[0095] The optimization results in the following code, where - as usual - redundant code that will be removed later is shown crossed out: Sa2_Assignment_FirstRun = 1; for (iterator = 0; iterator <= 9; iterator++) { Sa2_Selector = in2 [iterator]; U = doSth(Sa2_Selector, in3); if (Sa2_Assignment_FirstRun) { Sa2_Assignment_FirstRun = 0;} X_Sa2_UnitDelay [iterator] = U;}

[0096] The optimization according to the invention eliminates the need for inner loops, which are more difficult to optimize using conventional methods.

[0097] Figure 9shows a section of a block diagram using switch blocks. A first input port A receives a vector input signal and feeds it to a gain block G1, which multiplies the values ​​by a factor of 123. A second input port B receives a scalar signal and feeds it to a gain block G2, which multiplies the value by a factor of 456. The output signals from both gain blocks are fed to a switch block S1, which selects which signal is passed on based on a value at the input port Cond1. The output of switch block S1 is connected to the first input of a second switch block S2. Another vector input signal is received via an input port C and fed to a third gain block G3, which multiplies the values ​​by a factor of 456 and outputs them to the second input of switch block S2.Using an additional input port, Cond2, the second switch block S2 switches between the output of the first switch block S1 and the output of the third gain block G3. The switched signal is output via output port O.

[0098] When the production code generator moves predecessor blocks of switch blocks or multiport switch blocks into the control flow branch of a data input based on the block diagram, the block outputs of the immediate predecessors are copied directly to the block output variable of the switch or multiport switch block. In this case, they can be replaced by the switch output. if (Cond2) { if (Cond1) { for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { G1 [Aux_S32] = 123 * A [Aux_S32];} for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { S1 [Aux_S32] = G1 [Aux_S32];}} else { G2 = 456 * B; for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { S1 [Aux_S32] = G2;}} for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { S2[Aux_S32] = S1[Aux_S32];}} else { for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { G3[Aux_S32] = 456 * C[Aux_S32];} for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { S2[Aux_S32] = G3[Aux_S32];}} for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { O[Aux_S32] = S2[Aux_S32];}

[0099] Hier ergibt sich dann bei Anwendung auf S2 und S1 sowie vorheriger Rückkopie des Ausgangs O if (Cond2) { if (Cond1) { for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { O'[Aux_S32] = 123 * A[Aux_S32];}} else { G2 = 456 * B; for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { O" [Aux_S32] = G2;}}} else { for (Aux_S32 = 0; Aux_S32 < 10; Aux_S32++) { Oʺʺ [Aux_S32] = 456 * C[Aux_S32];}}

[0100] Here, O' denotes a replaced reference from the block pair with G1, O" a replaced reference from the block pair with S1, O‴ a replaced reference from the block pair with S2 and Oʺʺ a replaced reference from the block pair with G3. Because there is an exclusion criterion, namely the signals have different widths, G2 cannot be optimized.

[0101] The method according to the invention enables a significant reduction in the memory requirements and the execution time otherwise required for copying, particularly when using multi-component variables with a high memory consumption, which occur, for example, when modeling buses.

Claims

1. A computer-implemented method for generating source code from one or more blocks of a block diagram comprising at least two non-virtual blocks, i.e., processing blocks, for calculating an output value and / or for making an assignment to at least parts of a signal, and at least one signal connection between two non-virtual blocks, the generating of source code comprising a transformation (S2) of the block diagram into an intermediate representation, a successive optimization (S8) of the intermediate representation, and a translation (S9) of the optimized intermediate representation into source code, the transformation (S2) of a non-virtual block comprising creating a reference to a block output variable, characterized in that, for a first block having an access to a multicomponent variable, the transforming (S2) comprises checking (S4) whether a pair of blocks comprising said block and an adjacent block comprises an equal-value assignment, wherein the multicomponent variable is a vector comprising a plurality of variables of the same data type, a matrix comprising a plurality of vectors, a structure comprising a plurality of variables of any data type, or a vector of structures or a matrix of structures, wherein the pair of blocks consists either of the first block and the predecessor thereof or of the first block and the successor thereof, depending on the type of the first block, wherein an equal-value assignment is present if at least a part of the multi-component variable of one block of the block pair is copied unchanged into a part of the multi-component variable of the other block of the block pair, wherein a replacement (S6) of variable references takes place if an equal-value assignment is present, in which either a reference to the part of the variable of the one block of the block pair is replaced by a reference to the corresponding part of the variable of the other block of the block pair or the reference to an output variable of the first block is replaced by the reference to a data memory variable and wherein the transforming comprises a removal (S7) of such assignments in which there is a reference to the same variable on both sides, wherein, despite the presence of an equal-value assignment between a first variable and a second variable of a block pair, no replacement (S6) of a reference to the first variable by a reference to the second variable takes place if one or more of the reasons for exclusion (S5) mentioned below are present, wherein, in the case of an equal-value assignment existing only for portions of the first and second variables, only said portions are also considered in the reasons for exclusion (S5): • the first and second variables have a different dimension, • at least one element of the first variables has a different data type than the corresponding element of the second variables, • the first variable is specified as necessary, • the signal flow branching and / or execution sequence of the connected blocks results in an unpredictable data flow.

2. The method according to claim 1, characterized in that one or more of the following block types are checked for an equal-value assignment: a DataStore read block for reading from a data memory variable, a DataStore write block for writing to a data memory variable, a switch block for selectively connecting an output to one of a plurality of inputs, a bus outport block for modeling an output to a bus, an outport block for modeling an output, and / or a delay block for outputting an input signal delayed by one time step, wherein in the case of a DataStore read block said block is considered together with the subsequent block, and in the presence of an equal-value assignment a reference to an output variable of the DataStore read block is replaced by a reference to the corresponding part of the data memory variable, and / or in the case of a DataStore write block, switch block, bus outport block, outport block and / or delay block said block is considered together with the predecessor block, and if an equal-value assignment is present, a reference to an output variable of the predecessor block is replaced by a reference to a variable of the first block.

3. The method according to any one of the preceding claims, characterized in that block diagrams are defined hierarchically, wherein a block in a higher level may comprise several blocks of a subordinate level, wherein blocks of a subordinate level are assigned to a block of a higher level, and in that when a DataStore read block is checked for an equal-value assignment, a search is made in a global hierarchical block, in particular an atomic hierarchical block, for DataStore write blocks for accessing the same data memory variable.

4. The method according to claim 3, characterized in that, if a DataStore read block and a DataStore write block having access to the same data memory variable have been found in the global hierarchical block, it is checked whether the DataStore read block and the DataStore write block are at least partially connected in the signal flow, so that the part of the data memory variables being read in the DataStore read block has a non-empty intersection with the part of the data memory variables which is written in the DataStore write block, wherein at least one block in the signal flow is between the DataStore read block and the DataStore write block, wherein the one or more intervening blocks comprise at least one non-virtual processing block for processing an input variable to generate an output variable, and that as an additional condition it is checked whether the one or more intervening blocks have a processing order such that the at least one processing block is executed before the DataStore write block, and if said additional condition is fulfilled, the portion of the output variable of the DataStore read block corresponding to the intersection is replaced by the portion of the data memory variables corresponding to the intersection.

5. The method according to any one of claims 3 to 4, characterized in that if the additional condition is initially not fulfilled, the processing sequence of at least one of the intervening blocks is changed in order to fulfil the additional condition.

6. The method according to any one of claims 3 to 5, characterized in that if a DataStore read block and a DataStore write block having access to the same data memory variable have been found in the global hierarchical block, it is checked whether the DataStore read block and the DataStore write block are at least partially connected in the signal flow, such that the portion of the data memory variables being read in the DataStore read block has a non-empty intersection with the portion of the data memory variables being written in the DataStore write block, wherein at least one block in the signal flow lies between the DataStore read block and the DataStore write block, wherein the intervening block or blocks comprises at least one non-virtual processing block for processing an input variable to generate an output variable, and that in this case it is checked, as additional conditions for a predecessor block of the DataStore write block, namely the processing block closest to the DataStore write block in the signal flow, whether the portion of the block output of the predecessor block corresponding to the intersection without a signal flow branch is connected to the DataStore write block, and whether the block output variable of the predecessor block corresponds in dimension and data type to the at least partial connection in the signal flow, wherein if said additional conditions are fulfilled, the block output variable of the predecessor block is replaced by the portion of the data memory variables corresponding to the intersection.

7. The method according to any one of the preceding claims, characterized in that block diagrams are defined hierarchically, wherein a block in a higher level may comprise a plurality of blocks of a subordinate level, wherein blocks of a subordinate level are assigned to a block of a higher level, and in that when a first DataStore write block is checked for an equal-value assignment, a search is made in a global hierarchical block, in particular an atomic hierarchical block, for further DataStore write blocks accessing the same data memory variable, and in that, as a reason for excluding the replacement of references to variables in the block pair of the first DataStore write block, a check is made for each further DataStore write block found as to whether said block writes to a part of the data memory variables also written to by the first DataStore write block, wherein no replacement of a reference to the output variable of the predecessor block by a reference to the part of the data memory variables written to by the first DataStore write block takes place despite the presence of an equal-value assignment if the reason for exclusion is present.

8. The method according to any one of the preceding claims, characterized in that variables may be specified as states for influencing the output values of the following time step, wherein even if there is an equal-value assignment between a first variable and a second variable of a block pair, a reference to the first variable is replaced (56) by a reference to the second variable only if the first variable is not specified as a state and / or the second variable is specified as a state.

9. The method according to any one of the preceding claims, characterized in that block diagrams are defined hierarchically, wherein a block in a higher level may comprise a plurality of blocks of a subordinate level, wherein blocks of a subordinate level are assigned to a block of a higher level, wherein all blocks at the level of the first block and all blocks assigned to said blocks are checked for the presence of a reason for exclusion.

10. A method for configuring a control device, wherein the control device comprises at least one processing unit and preferably comprises at least one sensor and / or at least one actuator for capturing data of a physical process and / or for acting on the same, the method comprising the steps: a.reading in a block diagram, b.generating a source code by means of a method according to any one of the preceding claims, c.compiling the source code for the processing unit so that an executable code is generated, d.transferring the executable code to the control device, and e.saving the executable code in a non-volatile memory of the control device and / or executing the executable code by the processing unit of the control device.

11. A computer program product having a computer-readable memory medium in which commands are embedded which, when executed by a processor, cause the processor to be configured to perform a method according to any one of the preceding claims.

12. A computer system comprising a human-machine interface, a non-volatile memory, and a processor, wherein the processor is configured to execute a method according to any one of the preceding claims.