Method for generating a control program for a target platform, device for data processing, computer program product and data carrier

The procedure identifies and optimizes block pairs with opposite or inverse operations in graphic control models to generate more compact control programs, addressing the inefficiencies in existing code generation methods.

DE102023124151A1Pending Publication Date: 2025-03-13DSPACE SE & CO KG
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
DE102023124151
Authority / Receiving Office
DE · DE
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-09-07
Publication Date
2025-03-13

AI Technical Summary

Technical Problem

Existing procedures for generating control programs from graphic control models often result in unnecessary block variables and code size, due to the creation of variables for each output of a block, which can be optimized but are sensitive to the order of optimization steps and indexing array types.

Method used

A computer-implemented procedure that identifies block pairs in the graphic control model where successive blocks perform opposite or inverse operations, allowing for the elimination of unnecessary calculations and code generation by modifying the block diagram to bypass these operations.

Benefits of technology

This approach enables the creation of more compact control programs by eliminating unnecessary operations and code, thereby improving efficiency and reducing memory consumption.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

The invention relates to a computer-implemented method for generating a control program for a target platform from a graphical control model (12) of a development platform, wherein the graphical control model (12) comprises a block diagram (12) with a plurality of blocks (14), wherein, when generating the control program for the target platform from the graphical control model (12), block pairs comprising a first and a second block (14a, 14b) are identified, wherein the first and the second block (14a, 14b) are connected to each other by at least one signal connection (16) in such a way that an output of the first block (14a) drives an input of the second block (14b), and wherein i) the first block (14a) and the second block (14b) are designed such that an input signal (I1) of the first block (14a) corresponds to an output signal (O2) of the second block (14b); or ii) the first block (14a) and the second block (14b) are designed in such a way that an input signal (I3) of the first block (14a) corresponds to an intermediate result (Aux4) of the second block (14b), and the second block (14b) is designed in such a way that, in an operation (OpZ) of the second block (14b) using the intermediate result (Aux4), an input signal of this operation (OpZ) can be substituted. Furthermore, the invention relates to a device (10) for data processing comprising means for carrying out the above method, a computer program product and a corresponding computer-readable data carrier.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The invention relates to a computer-implemented method for generating a control program for a target platform from a graphical control model of a development platform.

[0002] Furthermore, the invention relates to a method for configuring a target platform designed as a control unit, in which a control program for the target platform is generated from a read-in graphical control model according to the above method.

[0003] Furthermore, the invention relates to a device for data processing comprising means for carrying out the first-mentioned method.

[0004] Furthermore, the invention relates to a computer program product comprising instructions which, when the program is executed by a computer, cause it to execute the first-mentioned method.

[0005] Furthermore, the invention relates to a computer-readable data carrier on which the above computer program product is stored.

[0006] Methods for the computer-aided generation of a control program from a graphical control model have been known for some time and are among the fundamental functionalities of development environments. In particular, programs for control systems such as electronic control units (ECUs) can be created in this way.

[0007] The graphical control model is often presented as a block diagram, which can be used, for example, to model and represent the mathematical functionality of a control algorithm. Using the graphical control model, processes, controllers, and / or the general behavior of the control unit can be simulated, and the presence of desired properties can be verified. The block diagram forming the model typically comprises several blocks connected by signal paths, which perform operations such as calculations. For example, a block might calculate an output signal from several input signals. Block diagrams are usually executed cyclically, with all blocks permanently stored in memory and each block executed once per time step.In particular, a block can apply one or more operations to input signals from the last time step to generate output signals of the current time step. Accordingly, common assumptions regarding control programs, such as the lifetime of variables in the control program, cannot be directly transferred to the graphical control model.

[0008] Graphical control models can include not only a cyclically executed sub-model to describe approximately time-continuous behavior of the control unit, but also a sub-model to describe discrete behavior in which a number of states and transition conditions are defined.

[0009] Methods for generating control programs from graphical control models are also known as code generators. These are computer programs that translate the graphical control model into source code for the chosen target platform—that is, into the control program itself. Unlike the graphical control model, the control program exists in entirely textual form and includes instructions for execution on the target platform. Code generators thus ensure the reliable and error-free implementation of an abstract functional description (graphical control model) into a program for the target platform (control system).

[0010] A method for generating a control program is described, for example, in publication EP 4 148 557 A1.

[0011] When generating control programs from graphical control models, a common approach is to create a variable in the control program for each output of a block. However, this has the disadvantage that it usually results in more block variables than are actually needed. Subsequent optimization can reduce the number of block variables and, more generally, the code size of the control program. For example, EP 2418577 A1 discloses the ability to transform a block diagram into an intermediate representation and apply at least one optimization to this intermediate representation to generate an optimized intermediate representation. A multitude of further optimizations, which are themselves known from compiler construction, can be applied sequentially to generate further optimized intermediate representations. The control program, particularly in C code, is then generated from the optimized intermediate representation.

[0012] Since every optimization results in a changed intermediate representation, the degree to which the overall code is optimized can depend on the order of the optimization steps. Furthermore, the different methods of array indexing in graphical control models and in the control program, where array indices can start at 1 or 0, create situations that cannot be resolved by optimizing the intermediate representation.

[0013] 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 compact control programs.

[0014] This problem is solved by the subject matter of the main claims. Preferred embodiments are found in the dependent claims.

[0015] According to the invention, a computer-implemented method for generating a control program for a target platform from a graphical control model of a development platform is provided, wherein the graphical control model comprises a block diagram with a plurality of blocks, wherein, when generating the control program for the target platform from the graphical control model, block pairs comprising a first and a second block are identified, wherein the first and the second block are connected to each other by at least one signal connection in such a way that an output of the first block drives an input of the second block, and wherein i) the first block and the second block are designed in such a way that an input signal of the first block corresponds to an output signal of the second block within the computational accuracy necessary for the execution of the control program and for all values ​​in a range of values ​​necessary for the execution of the control program; or ii) the first block and the second block are designed in such a way that an input signal of the first block corresponds to an intermediate result of the second block within the computational accuracy necessary for the execution of the control program and for all values ​​in a range of values ​​necessary for the execution of the control program, and the second block is designed in such a way that, in an operation of the second block that uses the intermediate result, an input signal of this operation can be replaced.

[0016] One aspect of the invention is therefore that, in the graphical control model, block pairs are identified in which the successive blocks perform opposite and / or inverse operations. In case i), the result of the two blocks—that is, the output signal of the second block—exhibits identical behavior to the input signal of the first block within the computational accuracy necessary for the execution of the control program and for all values ​​within the value range required for the execution of the control program. In case ii), the second block includes the opposite and / or inverse operation to the first block as part of its block code pattern in a form that can be replaced within the block code pattern.In the narrower sense, "block code pattern" refers to a specific implementation of a block with a particular parameterization and one or more specific input signals in parts of the control program, preferably in C code. In a broader sense, "block code pattern" also refers to the operations and computational steps defined at the level of the graphical control model within the block, which are applied to the input signal and / or intermediate results to generate the output signal or state values ​​of the respective block. Furthermore, in case ii), the intermediate result of the second block exhibits identical behavior to the input signal of the first block, within the computational accuracy required for the execution of the control program and for all values ​​within the range necessary for the execution of the control program.

[0017] The invention enables the identification of situations where a user has modeled a block diagram and two consecutive blocks perform opposing operations, thus allowing the removal of unnecessary computational steps. In case i), cumbersome calculations on a signal connection from the second block to a subsequent block of the second block can be eliminated, while in case ii), a cumbersome calculation in the identified block pair can be eliminated. The invention thus makes it possible to avoid creating unnecessary code for the blocks following the block pair. In other words, during code generation, the invention allows the signal connections and block parameters in the block diagram to be modified so that the model's behavior remains unchanged, but the unnecessary operations are not included in the initial code.

[0018] In other words, the graphical control model takes the form of a block diagram, preferably comprising a large number of blocks interconnected via signal connections. The blocks in the block diagram can be atomic, meaning they form a single unit from the perspective of the surrounding blocks, where 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. If block diagrams are hierarchical, a large number of blocks at a lower level can describe the structure of a block at a higher level. Hierarchical or composite blocks, even if atomic, can also comprise a large number of blocks at a lower level.Composite blocks can be subsystems; subsystems can have additional properties, such as being implemented in a separate function and / or having their execution triggered by a dedicated signal. Special blocks can be arranged within subsystems to further specify their properties.

[0019] For the purposes of the invention, block pairs in which the first and second blocks are connected to each other by at least one signal connection such that an output of the first block drives an input of the second block are also understood to include block pairs in the block diagram that are connected across subsystem boundaries. Furthermore, block pairs in which additional blocks are connected between the first and second blocks, but which do not modify the signal transmitted on the signal connection, are also understood to include block pairs in which further blocks are interposed between the first and second blocks, such as blocks relating to signal routing or blocks that combine several signals and then separate them back into individual signals.

[0020] Data or signals can be transmitted via the signal connection between the first and second blocks. The first block outputs a value, or, depending on the definition, several related values, and the second block receives these as its input signal and uses them to determine its output signal—that is, to determine one or more related output values. Signals can contain scalar variables and / or structured data types such as arrays, as is the case, for example, with a bus.

[0021] When a block involves accessing a multi-component variable, eliminating one operation accessing that variable can significantly reduce memory and execution time. This can be achieved, for example, by not generating the necessary instructions in the code and therefore not executing them at runtime. The multi-component variable can be a vector containing multiple variables of the same data type, a matrix containing multiple vectors, a structure containing multiple variables of any data type, or a vector or matrix of structures.

[0022] The process of generating the control program can include multiple sub-steps, such as checking a number of rules and adding further code generation information. The identification process according to the invention can, in principle, take place in any intermediate step.

[0023] As already mentioned, one aspect is the identification of mutually opposing and / or inverse operations in successive blocks, which in principle represents a computationally intensive way of passing the input value of the first block through. Specifically, within the computational accuracy required for the control program, the output signal of the second block, or the intermediate result of the second block, corresponds to the input signal of the first block and exhibits the same behavior for all values ​​within the value range required by the control program.

[0024] Preferably, the identification of block pairs configured according to i) and / or ii) includes analyzing the operations performed by the blocks. More preferably, for block pairs where the first and second blocks are connected to each other by at least one signal connection such that the output of the first block drives the input of the second block, operation pairs that are opposite to each other and / or inverse to each other are identified. Whether an operation of one block is opposite to and / or inverse to an operation of another block preferably depends not only on the type of operation, but also on the data type processed by the operation, the computational precision, and / or the range of values ​​under consideration.For example, the operation of squaring a value is the opposite of the operation of taking the square root of a value, as long as the range of positive numbers is considered. Furthermore, for the integer data type, adding and subtracting the integer 1 are opposite operations, regardless of the computational precision. However, for the floating-point data type, whether adding and subtracting a value are opposite operations depends on the computational precision required by the control program. The term "computational precision required by the control program" refers specifically to the precision necessary for the control program to function correctly.Furthermore, the term "value range necessary for the control program" refers to the value range that can be assumed by a signal when the control program is executed.

[0025] Preferably, for identifying block pairs configured according to i) and / or ii), a database contains a list of operation pairs that are considered opposite and / or inverse operations under certain conditions. If, in a block pair where the first and second blocks are connected by at least one signal connection such that the output of the first block drives the input of the second block, operation pairs have been identified that are considered opposite and / or inverse operations in the list, it is preferably checked in a further step whether these operations are also opposite and / or inverse operations within the context of the present block diagram, preferably by comparing the value and behavior of the input signal of the first block and the value and behavior of the output signal of the second block, respectively.The value and behavior of the intermediate result in the second block are analyzed. It is particularly preferred to check whether the operation of the first block and the operation of the second block, for the specific block diagram and the data type transmitted on the signal connection, produce the same behavior of the result of the two operations with respect to the input signal of the first block, within the limits of fixed-point accuracy.

[0026] According to a preferred embodiment of the invention, upon identification of a block pair configured according to i), the control program is generated in such a way that it corresponds to a modified block diagram. In this modified version, a branch before the first block uses the input signal of the first block to drive a successor block of the second block, bypassing the first and second blocks. In other words, the situation where the two blocks perform opposite and / or inverse operations is resolved by creating a branch before the first block, so that the input signal of the first block is directly connected to the successor block of the second block, bypassing the first and second blocks. It is particularly preferred that the signal connection of the second block to the successor block of the second block is also disconnected from the successor block.If the second block, apart from the successor block described here, has no other successor that processes the output signal of the second block, the signal link transmitting the output signal of the second block is preferably terminated. This eliminates the need for cumbersome calculations on the signal link for all successors of the block pair.

[0027] In this context, it is further preferably provided that, in the event that the signal connection transmitting the output signal of the second block is terminated, the block code pattern of the second block is preferably also adapted in such a way that the opposite and / or inverse operation in the second block is not calculated at all.

[0028] According to a further preferred embodiment of the invention, it is provided that, upon identification of a block pair designed according to ii), the control program is generated in such a way that it corresponds to a modified block diagram in which a branch before the first block drives the second reparameterized block with the input signal of the first block, bypassing the first block, and wherein, in the reparameterized block, the input signal of the operation using the intermediate result is replaced by the input signal of the first block.In other words, the situation where the second block, as part of its block code pattern, contains the inverse operation of the operation performed by the first block, and the inverse operation can be disabled, is resolved by creating a branch before the first block. This allows the input signal of the first block to be connected directly to the reparameterized second block, bypassing the first block. Preferably, the signal connection from the first block to the second reparameterized block is omitted. Furthermore, the second block is reparameterized to avoid performing the operation that yields the intermediate result.

[0029] If, due to the loss of the signal connection to the second, reconfigured block, the first block no longer has another successor that processes the output signal of the first block, the signal connection transmitting the output signal of the first block is preferably terminated. This eliminates a cumbersome calculation within the block pair.

[0030] In this context, it is further preferably provided that, in the event that the signal connection transmitting the output signal of the first block is terminated, the block code pattern of the first block is preferably also adapted in such a way that the operation in the first block, which is the inverse of the operation of the second block that achieves the intermediate result, is not calculated at all.

[0031] According to a further preferred embodiment of the invention, the control program is generated in such a way that it corresponds to a multiply modified block diagram, in which, after a first modification of the block diagram, one or more further identifications of a block pair configured according to i) and / or ii) are carried out and corresponding modifications of the block diagram are made. In other words, the block diagram corresponding to the control program is preferably not modified only once after checking whether block pairs with mutually opposing and / or inverse operations exist, but rather the process is preferably carried out multiple times.

[0032] According to a further preferred embodiment of the invention, a warning is generated when a block pair configured according to i) and / or ii) is identified during the generation of the control program. Instead of or in addition to the behavior described above, in which the control program is generated in a form corresponding to a modified or multiply modified block diagram, it can be advantageous to alert the user to the situation by generating a warning. Particularly in cases where model modification is not possible or is particularly complex, this allows the user to be notified that unnecessary calculations through remodeling can be avoided.

[0033] The first and / or the second block can be configured as different types. According to a preferred embodiment of the invention, the second block of the block pair is configured as a selector block or as an assignment block. Preferably, one or more of the following block types are examined with regard to the configuration of the block pair according to i) or ii): - A selector block that extracts selected elements from a vector, matrix, or multidimensional signal; - An assignment block that assigns values ​​to specific elements of a signal;

[0034] In particular, the different methods of array indexing in the graphical control model and the control program—where array indices preferably start at 1 in the graphical control model and preferably at 0 in the control program—lead to the generated control program automatically implementing a -1 assignment when accessing array indices. However, in block configurations within the graphical control model, where the user converts a 0-based indexing to a 1-based indexing using a modeled +1 operation, this behavior results in canceling-out calculation steps, where the index value is unnecessarily incremented by +1 only to be subsequently decremented by -1 (or vice versa).In such situations, as already mentioned, it is preferred that when generating the control program, the modeled increase by +1 is offset against the decrease by -1 from the 1-based indexing by bypassing the +1 operation.

[0035] As already mentioned, it is preferably provided that the first and second blocks of the block pair perform mutually inverse operations and / or mutually opposite operations. In this context, according to a further preferred embodiment of the invention, the first and second blocks of the block pair are configured such that they - mutually additive inverse operations, - mutually logically inverse operations, - bitwise inverse operations, - mutually inverse mathematical functions, - multiplicatively inverse operations, - opposite data type conversions, and / or - Make connections between them.

[0036] In this context, it may be further preferred that the first and second blocks of the block pair are designed in such a way that they perform combinations of operations which are inversely related to each other in their entirety.

[0037] Additive inverse operations are operations that, when added together, yield the additive neutral element. In particular, the previously described incrementing an index by +1 and subsequently decreasing it by -1 is an example of two additive inverse operations, where the additive neutral element is 0.

[0038] A logical operation is a function that returns a truth value and / or operates on a truth value. In two-valued Boolean logic, the operation returns true or false; in multi-valued logic, other values ​​can also be returned. An example of two mutually logically inverse operations are two logical exclusive OR operations, also called XOR, with the same second input value for the first and second blocks. Another example is the logical NOT operation, which applies to both blocks.

[0039] A bitwise operation is an operation performed on one or two bit strings, bit fields, bit sequences, and / or bit vectors at the level of individual bits. An example of mutually bitwise inverse operations are two opposite cyclic shifts (also called bitwise rotations or circular shifts) of the same number, for example, a cyclic left shift of 2 bits followed by a cyclic right shift of 2 bits.

[0040] With regard to logical operations and bitwise operations, many programming languages, especially the C family, distinguish between bitwise (multi-element and component-wise) and logical (boolean, i.e., a single component).

[0041] Inverse mathematical functions are two functions where one function assigns to each element of a preimage a corresponding element of a codomain, and the other function assigns to each element of the codomain its uniquely determined preimage element. Examples include the sine and arcsine functions, the exponential and logarithmic functions, and the quadratic and square root functions.

[0042] Multiplicative inverse operations are operations that, when multiplied together, yield the neutral element. For example, multiplication by 7 followed by division by 7 is an example of two multiplicative inverse operations, where the multiplicative neutral element is 1.

[0043] Opposite data type conversions are transformations of the data type—also called type conversions—in which the original data type is generated sequentially. For example, a conversion from a 16-bit integer to a 32-bit integer and then another conversion back to a 16-bit integer.

[0044] Naturally, the first and second blocks of the block pair can also be designed to perform operations that are mutually inverse and / or opposite in their entirety. An example of this would be the first block performing a type conversion followed by a left shift—that is, a bitwise operation—where the type conversion to a larger range of values ​​is carried out in such a way that no bits are lost during the left shift. The second block then performs a right shift followed by a type conversion back to the original type and range of values. In this example, the type conversion allows the block operations to be considered as mutually inverse bitwise operations, thus bypassing them.

[0045] According to a further preferred embodiment of the invention, generating the control program for the target platform from the graphical control model of the development platform comprises the following steps: - Generating an intermediate representation from the graphical control model, - Optimizing the generated intermediate representation, and - Generating the control program for the target platform by translating the optimized intermediate representation, wherein at least one of the steps, and in particular the step generating the intermediate representation, includes identifying block pairs designed according to i) and / or ii).

[0046] A preferred method for generating the control program from the graphical control model is provided, in which the generation of the control program comprises transforming the block diagram into an intermediate representation, preferably successively optimizing the intermediate representation, and translating the optimized intermediate representation into the control program. In particular, block pairs configured according to i) and / or ii) are identified during the generation of the intermediate representation. Because the identification preferably takes place during the transformation into the intermediate representation, all information from the block diagram remains available. This makes it possible, in particular, to consider the result of block diagram transformations and / or to select or enforce a suitable execution sequence of the blocks for optimization, provided the corresponding degrees of freedom are available.

[0047] Preferably, in the intermediate representation, the blocks of the block diagram are translated into instructions with a fixed execution order, whereby the structure of the intermediate representation semantically maps to a textual programming language.

[0048] Preferably, the block pairs configured according to i) and / or ii) are not merely identified, but the block diagram is also preferably modified during transformation. In this regard, a preferred embodiment of the invention provides that, upon identification of a block pair configured according to i), the intermediate representation is generated in such a way that it corresponds to a modified block diagram in which a branch before the first block, using the input signal of the first block and bypassing the first and second blocks, drives a successor block of the second block.

[0049] Similarly, according to a preferred embodiment of the invention, it is provided that upon identification of a block pair designed according to ii), the intermediate representation is generated in such a way that it corresponds to a modified block diagram in which a branch before the first block drives the second reparameterized block with the input signal of the first block, bypassing the first block, and wherein, in the reparameterized block, the input signal of the operation using the intermediate result is replaced by the input signal of the first block.

[0050] The transformation process can include multiple sub-steps, such as checking a number of rules and appending further code generation information. Identifying and subsequently modifying code can, in principle, occur at any intermediate step of the transformation process.

[0051] Advantageously, the method according to the invention identifies block pairs configured according to i) or ii) and modifies the signal connections and / or the block parameterization to avoid unnecessary calculations, so that these do not even need to be created when generating the intermediate representation. This not only results in more efficient code overall, but also accelerates the optimization on the intermediate representation, since fewer calculations need to be considered at the beginning.

[0052] In this context, according to a further preferred embodiment of the invention, optimizing the generated intermediate representation includes re-identifying block pairs configured according to i) and / or ii) in the modified block diagram corresponding to the intermediate representation. Alternatively or additionally, optimizing the generated intermediate representation may include generating an optimized intermediate representation corresponding to a multiply modified block diagram, in which, after a first modification of the block diagram, one or more further identifications of a block pair configured according to i) and / or ii) are performed, and the block diagram is modified accordingly.In other words, when generating the intermediate representation, it is preferentially not just a single check to see if block pairs with mutually opposing and / or inverse operations exist, but rather multiple identifications and corresponding modifications are performed.

[0053] According to a further embodiment of the invention, the control program is generated in C code. For the purposes of this invention, C code is understood to be a programming language whose syntax and / or basic structure are similar to C. Such languages ​​feature, for example, semicolon-terminated statements, code blocks separated by curly braces, parameters separated by parentheses, and / or arithmetic and logical expressions defined in infix notation. They are sometimes also referred to as "curly brace languages." Preferably, C code also includes code written in the programming languages ​​C++, Handel-C, and / or SA-C.Furthermore, a standardized form of C code such as ANSI C, ANSI C++, ISO C, ISO C++, Standard C and / or Standard C++, published by the American National Standards Institute (ANSI), ISO / IEC JTC 1 / SC 22 / WG 14 of the International Organization for Standardization (ISO), ISO / IEC JTC 1 / SC 22 / WG 21 of "The C++ Standards Committee - ISOCPP" of the International Organization for Standardization (ISO) and / or the International Electrotechnical Commission (IEC), is preferred.

[0054] The invention further relates to a method for configuring a target platform designed as a control unit, wherein the target platform comprises at least one computing unit and preferably at least one sensor and / or actuator to acquire data of a physical process and / or to act on a physical process, comprising the steps: - Importing a graphical control model of a development platform - Generating a control program for the target platform from the imported graphical control model using the method described above, - Generating executable code for the target platform's computing unit by compiling the generated control program, - Transferring the generated executable code to the target platform and / or storing the generated executable code in non-volatile memory of the target platform and / or executing the generated executable code by the computing unit of the target platform.

[0055] The control unit preferably includes an interface for connection to the development platform. More preferably, the control unit includes a microcontroller with an architecture different from that of a processor of the development platform, working memory, and non-volatile memory.

[0056] Furthermore, the invention relates to a device for data processing comprising means for carrying out the computer-implemented method described above for generating the control program.

[0057] Furthermore, the invention relates to a computer program product comprising instructions which, when the program is executed by a computer, cause it to execute the computer-implemented method for generating the control program described above.

[0058] Furthermore, the invention relates to a computer-readable data carrier on which the above computer program product is stored.

[0059] Preferably, the instructions are embedded on the computer-readable data carrier, and when executed by a processor of the computer, the instructions cause the processor to execute the procedure for generating the control program.

[0060] The technical advantages and effects of the method for configuring the target platform designed as a control unit, the data processing device, the computer program product and the computer-readable data carrier become apparent to the person skilled in the art from the description of the method for generating the control program, as well as from the embodiments described below.

[0061] The invention is explained in more detail below with reference to the drawings. The embodiments shown are highly schematic, i.e., the distances and the lateral and vertical dimensions are not to scale and, unless otherwise indicated, do not have any derivable geometric relationships to each other. The drawing shows Fig. 1 schematically a device for data processing, according to a preferred embodiment of the invention, Fig. 2 schematically the on the device according to Fig. 1 installed software components, Fig. 3 schematically a flowchart of a method for generating a control program for a target platform from a graphical control model, according to a preferred embodiment of the invention, Fig. 4 schematically in a) a block diagram of a graphical control model from which a control program is generated by means of the method for generating a control program, according to a preferred embodiment of the invention, and in b) a modified block diagram, Fig. 5 schematically in a) a further block diagram from which a control program is generated by means of the method for generating a control program, according to a preferred embodiment of the invention, and in b) a modified block diagram, and Fig. 6 schematically in a) a further block diagram from which a control program is generated by means of the method for generating a control program, according to a preferred embodiment of the invention, and in b) a modified block diagram,

[0062] Fig. Figure 1 schematically shows an exemplary embodiment of a data processing device 10, here referred to as a computer system PC. The computer system PC is configured to execute a method for generating a control program for a target platform from a graphical control model of a development platform—that is, the computer system itself. The computer system PC has a processor CPU, which can be implemented as a multi-core processor, main memory RAM, and a bus controller BC. Preferably, the computer system PC is designed to be operated directly and manually by a user, with a monitor DIS connected via a graphics card GPU and a keyboard KEY and mouse MOU connected via a human-machine interface HMI. In principle, the human-machine interface of the computer system PC could also be designed as a touch interface.The PC computer system further comprises a non-volatile data storage device (HDD), which can be a hard disk and / or solid-state drive, and a NET interface, specifically a network interface. A control unit (ES) – i.e., the target platform – can be connected via the NET interface. In principle, one or more interfaces of any type, particularly wired interfaces, can be present on the PC computer system and each can be used for connecting to a control unit (ES). A network interface conforming to the Ethernet standard is advantageous; the NET interface can also be wireless, such as a WLAN interface or a standard like Bluetooth.

[0063] The ES control unit can be implemented as a standard production control unit or as an evaluation board for the target platform. It expediently includes a NET interface for connection to the PC computer system, a microcontroller (MCR) with an architecture different from that of the PC computer system's processor, RAM, and NVM non-volatile memory.

[0064] In Fig. Figure 2 shows a diagram of the software components preferably installed on the PC computer system. These use mechanisms of the operating system (OS) to, for example, access the non-volatile hard drive (HDD) or to establish a connection to an external computer and / or the control unit (ES) via the network interface (NET).

[0065] A technical computing environment (TCE) enables the creation of models – especially graphical control models 12 (in Fig. 2 not shown, but in the Fig. 4, Fig. 5 and Fig. 6), and the generation of a control program, also called source code, from the graphical control models 12. In a modeling environment MOD, graphical control models 12 of a dynamic system can preferably be created via a graphical user interface. These can be, in particular, block diagrams 12, which contain several blocks 14 (also not in Fig. 2 shown, but in the Fig. 4, Fig. 5 and Fig. (shown in Figure 6) and describe the temporal behavior and / or internal states of a dynamic system. At least some of the blocks 14 are connected via signal links 16 (also not shown in Figure 6). Fig. 2 shown, but in the Fig. 4, Fig. 5 and Fig. (shown in Figure 6) are interconnected, with the signal connections 16 representing directed connections for data exchange, where the data can be scalar or composite. Operations and / or computational steps to be performed on the data can be defined via the blocks 14. Blocks 14 can be atomic, meaning they form a single unit from the perspective of the surrounding blocks 14, where all input signals must be present at the beginning of a computational step and all output signals must be present at the end of a computational step. If block diagrams 12 are hierarchical, a plurality of blocks 14 at a subordinate level can describe the structure of a block 14 at a superior level. Hierarchical or composite blocks 14, even if they are atomic, can comprise a plurality of blocks 14 at a subordinate level.Composite blocks 14 can, in particular, be subsystems; subsystems can have additional properties, such as being implemented in a separate function and / or having their execution triggered by a dedicated signal. Special blocks 14 can be arranged within subsystems to further specify the subsystem's properties.

[0066] The computational environment TCE comprises one or more libraries BIB, from which blocks 14, or building blocks, can be selected for constructing a model 12. Instructions can be entered interactively or via a batch file in a scripting environment MAT to perform calculations or modify the model 12. The computational environment TCE also includes a simulation environment SIM, which is configured to interpret and execute the block diagram 12 in order 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.

[0067] From a created model 12, the source code can be generated, preferably in a programming language such as C, using a code generator PCG. In this exemplary embodiment, the method for generating a control program for a target platform from the graphical control model 12 of the development platform is performed. Additional information about the model 12, particularly about the variables in blocks 14 – called block variables – is expediently stored in a definition data set (DDT). Value ranges and / or scales are expediently assigned to the block variables to support the calculation of the model 12 with fixed-point instructions. Desired properties of the source code, such as conformity to a standard like MISRA, can also be set or stored in the definition data set (DDT).It is advantageous to assign each block variable to a predefined variable type and to set one or more desired properties, such as the permissibility of optimizations like variable merging. Furthermore, the definition data set (DDT) can also contain information on opposing and / or inverse operations of blocks 14.

[0068] The PCG code generator preferably evaluates the settings of the definition data collection (DDT) and takes them into account when generating the source code. The definition data collection (DDT) can have a tree structure or be stored as a single file in the computer system's memory; alternatively, it can be stored in a dedicated database system. The definition data collection can have a program interface and / or import / export functions.

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

[0070] Fig. Figure 3 shows a schematic flowchart of an embodiment of the inventive method for generating a control program for a target platform from the graphical control model 12 of the development platform. The method can be executed entirely by a processor of an exemplary implementation of the PC computer system; however, it can also be designed for execution in a client-server environment with an operator computer and one or more servers connected via a network, wherein, in particular, computationally intensive steps are performed on the servers.

[0071] In step S1 (read block diagram), a graphical control model 12, comprising a block diagram 12, is read in. In the Fig. Figures 4 to 6 show exemplary block diagrams 12. A block diagram 12 comprises at least one block pair consisting of two blocks 14a and 14b, which are connected to each other by at least one signal connection 16 such that an output of the first block 14a drives an input of the second block 14b. The block diagram 12 can contain a plurality of further blocks 14. Conveniently, reading the block diagram 12 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 set (DDT).

[0072] In step S2 (Transform into Intermediate Representation), the graphical control model 12 is transformed into an intermediate representation, preferably comprising one or more hierarchical graphs. This can be, in particular, a data flow graph, a control flow graph, or a tree structure. In addition to the block diagram 12, supplementary information from a definition data set (DDT) is expediently considered or incorporated into the generation of the intermediate representation. This can also include situations in which elements are created based on information in the definition data set (DDT), or in which properties of elements or settings relevant for code generation, such as the data type of a variable, are extracted from the definition data set (DDT).

[0073] When transforming into the intermediate representation, 12 block pairs are identified in the block diagram, in which the first and second blocks 14a 14b are connected to each other by at least one signal connection 16 in such a way that an output of the first block 14a drives an input of the second block 14b, and in which i) the first block 14a and the second block 14b are designed such that an input signal I1 of the first block 14a corresponds to an output signal O2 of the second block 14b; or ii) the first block 14a and the second block 14b are designed in such a way that an input signal I3 of the first block 14a corresponds to an intermediate result Aux4 of the second block 14b, and the second block 14b is designed in such a way that, in an operation OpZ of the second block 14b using the intermediate result Aux4, an input signal of this operation OpZ can be replaced.

[0074] In the present embodiment, specifically designed block pairs are identified during the transformation into the intermediate representation. In particular, with reference to the Fig. 4a) and Fig. 5a) This is explained in more detail: In Fig. Figure 4a) shows a block diagram 12 in which, in the first block 14a, also labeled B1, the operation OpX is performed on the input signal I1. This produces the result I2, which drives the input of the second block B2. In the second block 14b, also labeled B2, the operation OpY is performed on the signal I2, and this is output as signal O2 to a subsequent block B. i The operations OpX and OpY are inverses of each other, so that: OpX o OpY = Id. Here, Id denotes the identity operator, which returns the input signal unchanged. Accordingly, the output signal O2 of the second block 14b, B2 corresponds to the input signal I1 of the first block 14a, B1.

[0075] In Fig. Figure 5a) shows a block diagram 12 in which the operation OpX is performed on the input signal I3 in the first block 14a, also labeled B3. This produces the result I4, which drives the input of the second block 14b, also labeled B4. In block B4, the intermediate result Aux4 is generated on the signal I4 using the operation OpY, and is then further processed in the subsequent operation OpZ in the second block. The operations OpX and OpY are inverses of each other, so that: OpX ∘ OpY = Id. Id denotes the identity operator, which returns the input signal unchanged. Accordingly, the intermediate result Aux4 corresponds to the input signal I3 of the first block B3. Furthermore, the second block B4 is designed such that the input signal of the operation OpZ, which uses the intermediate result Aux4, is interchangeable.

[0076] In the present embodiment, the transformation to the intermediate representation not only identifies the block pairs specifically designed according to i) or ii). The intermediate representation is also directly generated in such a way that it corresponds to a modified block diagram 12' which exhibits the same behavior as the original block diagram 12, but without unnecessary operations and connections.

[0077] In the present case, when a block pair designed according to i) is identified, the intermediate representation is generated in such a way that it corresponds to a modified block diagram 12', in which a branch before the first block 14a with the input signal I1 of the first block 14a bypassing the first and second blocks 14a, 14b leads to a successor block B i of the second block 14b. This is in Fig. 4b) is evident, which is shown in the modified block diagram 12'. This diagram includes a branch that routes the input signal I1 of the first block B1 to the subsequent block B, bypassing the first block 14a, B1 and the second block 14b, B2. i forwards. Furthermore, the signal connection between the second block 14b, B2 and the subsequent block B is i lifted.

[0078] Furthermore, upon identification of a block pair configured according to ii), the intermediate representation is generated in such a way that it corresponds to a modified block diagram 12', in which a branch before the first block 14a, using the input signal I3 of the first block 14a, bypasses the first block 14a and drives the second reparameterized block 14b', and in which, in the reparameterized block 14b', the input signal of the operation OpZ, which uses the intermediate result Aux4, is replaced by the input signal I3 of the first block 14a. This is in Fig. 5b) is evident from the modified block diagram 12'. This diagram contains a branch that bypasses the first block 14a, B3 and forwards the input signal I3 of the first block 14a, B3 to the second, reparameterized block 14b', B4'. In the reparameterized block 14b', B4', the input signal of the operation OpZ, which uses the intermediate result Aux4, is replaced by the input signal I3 of the first block 14a, B3. Furthermore, the signal connection between the first block 14a, B3 and the second, reparameterized block 14b', B4' is removed.

[0079] By generating the intermediate representation directly in a form corresponding to a modified block diagram 12', unnecessary calculations and signal connections 16 can be avoided, so that these do not even need to be created when generating the intermediate representation. This not only results in more efficient code overall, but also accelerates the subsequent optimization on the intermediate representation, since fewer calculations need to be considered at the beginning.

[0080] Back to Fig. In step S3 (further optimization of intermediate representation), the intermediate representation is optimized, and in particular the hierarchical graphs, to reduce the number of required variables and / or memory consumption, such as stack allocation, and / or the number of operations or processor instructions, and / or the execution time of the source code. This optimization can comprise a variety of intermediate steps in which further intermediate representations between the model / block diagram 12 and the source code / program text are generated. Specifically, it may be planned in each intermediate step to convert a set of original hierarchical graphs into another set of modified hierarchical graphs, applying one or more optimization rules. Various strategies, such as constant folding or the elimination of dead code, can be applied during the optimization.In principle, it is possible to combine several variables generated during the transformation in step S3.

[0081] In step S4 (Translate intermediate representation into source code), the optimized intermediate representation or the optimized hierarchical graphs resulting from all the intermediate steps are translated into source code of a textual programming language, in this case C code. Further optimization can also take place in this step, in particular ensuring that the generated instructions represent a subset of the instructions included in the language and / or that the generated control structures represent a subset of the control structures included in the language. This makes it possible to fulfill precisely defined rules. Alternatively or additionally, it may be possible to include supplementary information, such as...to create a link between the program line and block 14 of the block diagram 14, 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.

[0082] During or after code generation, information about the current—that is, the modified or multiply modified—block diagram (12') or results of the code generation, such as generated warnings, can be stored in the definition data collection (DDT). This information can be used, for example, to influence the compilation of the generated source code or to provide metadata for other tools, such as calibration information in ASAP2 format or information for generating an intermediate layer according to the AUTOSAR standard.

[0083] The following refers to Fig. Section 6 explains a further embodiment of the invention. In the developer platform, in the graphical control model 12, array indices start at 1 by default. Thus, in the development platform, the user has one-based indexing, i.e., indexing starting at 1, in blocks 14 (Selector Block 18) and 20 (Assignment Block 20). In the C programming language, in which the control program is generated, array indices start at 0 by default. When the control program is generated, the block diagram 12 specified by the user is implemented, and the index accesses in the generated C code are accordingly implemented with "-1" accesses.

[0084] In certain situations, which are described below as examples, the index is already present in the graphical control model 12 as zero-based indexing, and the user corrects the index in the control model 12 with a modeled +1 operation. Fig. Figure 6a) shows that one-based indexing is used for the selector block 18 and the assignment block 20 for the index inputs. The summation block 22 then calculates the corresponding index value.

[0085] Code generation in pseudocode for exactly that purpose Fig. 6a) The block diagram shown in 12, and without generating the code in the form that it corresponds to a modified block diagram, results in the following:

[0086] This code can only be compared to the code shown below, where, when generating the code for the target platform from the graphical control model 12, the intermediate representation is generated in such a way that it corresponds to the one in Fig. 6b) corresponds to the modified block diagram 12' shown, in which a branch before the summation block 22, with the input signal of the summation block 22, bypasses the summation block 22 and drives the reparameterized selector block 18' and the reparameterized assignment block 20', where the input signal of the reparameterized selector and assignment blocks 18' and 20' is replaced by the input signal of the summation block 22. In other words, the modeled increase of +1 is offset against the -1 from the one-based indexing by bypassing the +1 calculation. Fig. 6b) shows that there is a direct connection of the index signal (= input signal of the sum block 22) to the reparameterized selector and assignment blocks 18' and 20', and that the reparameterized selector block 18' and the reparameterized assignment block 20' are each switched to zero-based indexing. This model 12', which exhibits the same behavior as model 12 in Fig. 6a) avoids mutually inverse operations such as the following based on model 12' in Fig. 6b) The generated code in pseudocode shows: Reference symbol list 10. Data processing device 12. Graphical control model, block diagram 12' modified block diagram 14 blocks 14a, B1, B3 first block 14b, B2, B4 second block 14b', B4' reparameterized second block 16 Signal connection 18 Selector block 20 Assignment blocks 22 Summary Block I1, I3 Input signal of the first block O2 output signal of the second block Aux4 Interim result of the second block OpZ operation using the intermediate result B i successor block OpX and OpY are mutually opposing operations PC computer system CPU Processor RAM (Random Access Memory) BC Bus Controller GPU graphics card DIS Monitor HMI peripheral interface KEY keyboard MOU Mouse HDD non-volatile data storage NET interface, network interface ES control unit MCR Microcontroller NVM storage OS Operating System TCE technical computing environment MOD modeling environment BIB Library MAT scripting environment SIM simulation environment PCT Code Generator DDT Definition Data Collection COM Compiler LIN Linker QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] EP 4 148 557 A1

[0010] EP 2418577 A1

[0011]

Claims

[1] Computer-implemented method for generating a control program for a target platform from a graphical control model (12) of a development platform, wherein the graphical control model (12) comprises a block diagram (12) with a plurality of of blocks (14), characterized by that when generating the control program for the target platform from the graphical Control model (12) block pairs comprising a first and a second block (14a, 14b) are identified, in which the first and the second block (14a, 14b) are connected to each other with at least one signal connection (16) in such a way that an output of the first block (14a) drives an input of the second block (14b), and in which i) the first block (14a) and the second block (14b) are designed in such a way that an input signal (I1) of the first block (14a) corresponds to an output signal (O2) of the second block (14b) within the scope of a calculation accuracy necessary for the execution of the control program and for all values ​​in a value range necessary for the execution of the control program; or ii) the first block (14a) and the second block (14b) are designed in such a way that an input signal (I3) of the first block (14a) corresponds to an intermediate result (Aux4) of the second block (14b) within the scope of a calculation accuracy necessary for the execution of the control program and for all values ​​in a value range necessary for the execution of the control program, and the second block (14b) is designed in such a way that, in the case of an operation (OpZ) of the second block (14b) using the intermediate result (Aux4), an input signal of this operation (OpZ) is replaceable. [2] Method according to claim 1, wherein upon identification of a block pair configured according to i), the control program is generated in such a way that it corresponds to a modified block diagram (12') in which a branch in front of the first block (14a) drives a successor block of the second block (14b) with the input signal (I1) of the first block (14a), bypassing the first and second blocks (14a, 14b). [3] Method according to one of the preceding claims, wherein upon identification of a block pair configured according to ii), the control program is generated in such a form that it corresponds to a modified block diagram (12') in which a branch in front of the first block (14a) with the input signal (I3) of the first block (14a) drives the second reparameterized block (14b') bypassing the first block (14a), and wherein in the reparameterized block (14b') the input signal of the operation (OpZ) using the intermediate result (Aux4) is replaced by the input signal (I3) of the first block (14a). [4] Method according to one of claims 2 or 3, wherein the control program is generated in such a way that it corresponds to a multiply modified block diagram, in which, after a first modification of the block diagram (12), one or more further identifications of a block pair designed according to i) and / or ii) and corresponding modification of the block diagram (12') take place. [5] Method according to one of the preceding claims, wherein upon identification of a block pair configured according to i) and / or ii) a warning is generated when generating the control program. [6] Method according to one of the preceding claims, wherein the second block (14b) of the block pair is designed as a selector block (18) or as an assignment block (20). [7] Method according to one of the preceding claims, wherein the first and second blocks (14a, 14b) of the block pair perform mutually inverse operations (OpX, OpY) and / or mutually opposite operations (OpX, OpY). [8] Method according to one of the preceding claims, wherein the first and second blocks (14a, 14b) of the block pair are designed such that they - additive inverse operations, - logically inverse operations, - bitwise inverse operations, - mutually inverse mathematical functions, - multiplicatively inverse operations, - opposite data type conversions, and / or - links thereof, carry out; and / or wherein the first and second blocks (14a, 14b) of the block pair are designed to carry out combinations of operations which, as a whole, are inverse to one another. [9] Method according to one of the preceding claims, wherein the generation of the control program for the target platform from the graphical control model (12) of the development platform comprises the steps - generating an intermediate representation from the graphical control model (12), - Optimize the generated intermediate representation, and - generating the control program for the target platform by translating the optimized intermediate representation, and at least one of the steps, and in particular the step of generating the intermediate representation, comprises identifying block pairs designed according to i) and / or ii). [10] Method according to the preceding claim, wherein upon identification of a block pair configured according to i), the intermediate representation is generated in such a form that it corresponds to a modified block diagram (12') in which a branch in front of the first block (14a) drives a successor block of the second block (14b) with the input signal (I1) of the first block (14a), bypassing the first and second blocks (14a, 14b). [11] Method according to claim 9 or 10, wherein upon identification of a block pair configured according to ii), the intermediate representation is generated in such a form that it corresponds to a modified block diagram (12') in which a branch in front of the first block (14a) with the input signal (I3) of the first block (14a) drives the second reparameterized block (14b') bypassing the first block (14a), and wherein in the reparameterized block (14b') the input signal of the operation (OpZ) using the intermediate result (Aux4) is replaced by the input signal (I3) of the first block (14a). [12] Method according to claim 10 or 11, wherein the optimization of the generated intermediate representation comprises a renewed identification of block pairs designed according to i) and / or ii) in the modified block diagram (12') corresponding to the intermediate representation, and / or a generation of an optimized intermediate representation which corresponds to a multiply modified block diagram, in which after a first modification of the block diagram (12) one or more further identifications of a block pair designed according to i) and / or ii) and corresponding modification of the block diagram (12') take place. [13] Method for configuring a target platform designed as a control unit (ES), wherein the target platform comprises at least one computing unit (MCR) and preferably has at least one sensor and / or actuator to acquire data of a physical process and / or to act on a physical process, comprising the steps: - Reading in a graphical control model (12) of a development platform, - generating a control program for the target platform from the read-in graphical control model (12) according to the method according to one of the preceding claims, - Generating code executable for the computing unit (MCR) of the target platform by compiling the generated control program, - Transferring the generated executable code to the target platform and / or storing the generated executable code on a non-volatile memory (NVM) of the target platform and / or executing the generated executable code by the central processing unit (MCR) of the target platform. [14] Device (10) for data processing comprising means for carrying out the method according to one of claims 1 to 12. [15] A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 12.

Citation Information

Patent Citations

  • Application of optimization techniques to intermediate representations for code generation

    EP2418577A1

  • Method for generating source code

    EP4148557A1