Method for generating program code, method for configuring control device, and computer system

Abstract

To provide a method capable of supporting various communication methods in a further favorable manner without the need to newly generate a program code, a computer program, a computer readable data carrier, and a computer system.SOLUTION: A method includes: step S1 of generating a first placeholder P1 representing a variable to be used in a preset section 10 of a program code; step S2 of generating a second placeholder P2 placed before the beginning of a preset section using the first placeholder P1, of the program code; and step S3 for generating a third placeholder P3 placed after the end of a preset section using the first placeholder P1, of the program code.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a computer-implemented method for generating program code for an executable control program for controlling a control system.

[0002] The invention further relates to a method for configuring a control device.The invention further relates to a computer program, a computer readable data carrier and a computer system. [Background technology]

[0003] Control devices are used in many applications to sense physical quantities of a process and / or to influence the process by means of connected actuators, which may be, for example, anti-lock control of braking processes.

[0004] The time constants that determine the dynamic behavior of the process often require cycle times of 1 ms or less, making real-time capability of the controller essential.

[0005] To accelerate the design of controllers, control strategies are often developed based on models in a computational environment, such as MATLAB / Simulink, whereby the behavior of the process and / or controller, or the controller in general, can first be simulated to verify that it has the desired characteristics.

[0006] A model may in particular be a block diagram containing multiple blocks that perform operations such as calculations, e.g., to calculate an output signal from multiple input signals. Typically, the block diagram is executed cyclically, with all blocks persistently stored in memory and each block executed once per time step.

[0007] In particular, at each time step, a block can apply one or more operations to input signals from a preceding block to generate an output signal for the current step. In addition to partial models that are executed periodically to describe approximately time-continuous behavior, a block diagram may also contain partial models that describe discrete behavior, in which many states and transition conditions are defined.

[0008] From these models, a program code generator can be used to directly generate program code for programming the control device. For example, a program code generator for generating program code in production quality is known from the article "Production Quality Code Generation from Simulink Block Diagrams" by H. Hanselmann et al., Proceedings of the 1999 International Symposium on Computer Aided Control System Design, Kohala Coast, Hawaii.

[0009] Here, additional annotations of blocks or block variables allow the generated program code to be adapted, in particular to provide scaling for models that were originally created for calculations with high-precision floating-point variables, so that the control device can calculate with fixed-point numbers in order to significantly reduce the calculation costs, with only a small loss of precision.

[0010] The AUTOSAR development partnership has been defining a software framework for developing control unit software for several years.

[0011] Before implementing the actual control strategy or desired behavior, the software architecture is determined. For example, this software architecture can correspond to the AUTOSAR Classic Platform Standard Version 4.3.0 of November 30, 2016. This architecture includes software components, subcomponents such as runnables, and interfaces between the software components.

[0012] Messaging between the different software components takes place via a virtual function bus in a runtime environment that is generated based on a defined architecture and adapted to the specific control device.

[0013] In larger development projects, different areas of development are often realized by several people, possibly working for different companies. Thus, individual parts of the model may be created and improved by several feature developers. Once created, a partial model can be used for different projects and adapted in function.

[0014] In this case, it is advantageous to use incremental program code generation, i.e., program code is generated separately for each subsystem and then compiled into program code for the entire model. The model is thus divided into several submodels, which has the advantage that when local changes are made, new code only has to be generated for the corresponding submodels.

[0015] Incremental program code generation is understood to mean checking whether each partial model for a program code generator has been changed since the last program code generation, for example, checksums for blocks of the program code generator and / or model version counters that are incremented upon each change can be stored in the definition data collection unit for this purpose.

[0016] Alternatively or additionally, the definition data collector can store a checksum for the last generated code and / or a code version counter that is incremented during each code generation for this code generation unit. In particular, if the newly calculated checksum for the program code generator block differs from the stored checksum for the model, changes have been made to the model since the last program code generation and a new program code generation must follow. Otherwise, i.e., if the current program code is up to date, it can be used.

[0017] Thus, a program code generator generates program code in a text-based programming language, e.g., C code, directly from a graphical model, e.g., MathWorks, Simulink, and / or Stateflow. This allows program code generated once for a library subsystem or reference model to be used for various projects without the need to generate and test the program code anew for this project.

[0018] DE 102020124080 A1 discloses a method for generating source code from one or more blocks of a block diagram, the block diagram being hierarchical and including at least one first subsystem configured for incremental code generation, the first subsystem being included in a second subsystem, and the block diagram referencing a definition database including a first object, the method comprising the steps of opening the block diagram including the first subsystem in a model editor, generating source code for the first subsystem, the step including determining information about the first subsystem, storing the information about the first subsystem in a first object, and generating source code for the block diagram, the step reading the first object to modify at least one parameter of the code generation.

[0019] The definition data collector or definition database can store information about variables that can only be accessed for reading. This allows for optimized code generation in external subsystems without requiring additional code generation for internal submodels. Data exchange between external and internal subsystems can be achieved, for example, using input and output ports. If an internal submodel models a function, the caller is the external (sub)system in the graphical model, and the callee, i.e., the internal submodel, receives data via a port and sends data via another port. Placeholders can be defined in the internal submodel, and global variables can be created for these placeholders during code generation for the calling system. This allows for a certain degree of flexibility in communication, but this flexibility is not sufficient to support all communication methods common in AUTOSAR, for example. Summary of the Invention [Problem to be solved by the invention]

[0020] Against this background, the object of the present invention is to develop the prior art and in particular to enable better support of different communication methods without the need to create new program code. [Means for solving the problem]

[0021] This problem is solved according to the invention by a computer-implemented method for generating program code of a control program executable for controlling a control system, having the characterizing features of claim 1.

[0022] The above problem is further solved by a method for setting a control device having the characterizing features of claim 14, a computer program having the characterizing features of claim 15, a computer-readable data carrier having the characterizing features of claim 16, and a computer system having the characterizing features of claim 17.

[0023] The present invention relates to a computer-implemented method for generating program code for an executable control program for controlling a control system, the functionality of which is described, at least in part, in a graphical model, which is converted into program code in a text-based programming language.

[0024] The method includes generating a first placeholder representing a variable to be used in a predetermined section of program code.

[0025] The method further includes generating a second placeholder that is located before the beginning of the predetermined section of program code that uses the first placeholder.

[0026] The method further includes generating a third placeholder that is located after the end of the predetermined section of the program code that uses the first placeholder.

[0027] The invention further relates to a method for configuring a control device, which includes at least one computing unit and preferably has at least one sensor and / or at least one actuator for collecting data of and / or acting on a physical process.

[0028] The method includes the steps of reading a block diagram and generating program code according to the method of the present invention.

[0029] The method further includes compiling the program code for the computing unit to generate executable program code, transmitting the executable program code to the control device, storing the executable program code in a non-volatile memory of the control device and / or executing the executable program code by the computing unit of the control device.

[0030] The invention further relates to a computer program having a program code for performing at least one of the methods according to the invention when the computer program runs on a computer.

[0031] The invention further relates to a computer-readable data carrier comprising a program code of a computer program for performing at least one of the methods according to the invention when the computer program is run on a computer.

[0032] The invention further relates to a computer system comprising a man-machine interface, a non-volatile memory and a processor configured to implement the method according to the invention.

[0033] The idea of ​​the present invention is that by providing the first, second and third placeholders, a more flexible code is generated already during incremental code generation for the respective functions, so that by using placeholders the program code already generated for the respective application can be correspondingly adapted.

[0034] To obtain the required flexibility, the three placeholders mentioned above are used instead of the individual placeholders that are conventionally used.

[0035] The individual placeholders used conventionally are used in the program code variable-wise, i.e. like global variables, so that they can only be replaced by things that behave like variables in the program code.

[0036] Although placeholders according to the invention are generated in the program code during incremental program code generation, the definitions of the placeholders are not generated until a later point in time, at which point the surrounding system is generated and the definitions of the placeholders can then be generated, if necessary.

[0037] The advantage of this approach is that by providing a placeholder, the read and write locations of the variable represented by the placeholder can be marked or defined.

[0038] In this case, the second placeholder is set before the first use of the first placeholder in the program code, and the third placeholder is set after the last use of the first placeholder in the program code.

[0039] Thus, by inserting placeholders, it is possible to distinguish between different phases of the data object represented by the placeholders, thereby allowing the use of the appropriate program code for this phase, respectively: in the sequential flow of the program, first the second placeholder representing the reading of the data object is executed, then the first placeholder representing the data object, followed by the third placeholder representing the writing of the data object.

[0040] What is not possible with this variable use of the first placeholder is to define it for an access function that is not variable in the program code.

[0041] Since the second and third placeholders are not used variable in the program code, it is possible to define them for such access functions, and therefore, by positioning them relative to the first placeholder, these access functions can be placed in the program code before or after the first placeholder is used.

[0042] Alternatively, at least one of the placeholders can be defined as e.g. empty, i.e. it is replaced by nothing or a blank in this case, which allows to keep the code compact in case one of the phases is not needed.

[0043] Distinguishing between reading a second placeholder representing a data object and writing a third placeholder representing a data object is useful, for example, under AUTOSAR to access Interrunnable-Variables (IRVs), which are modeling elements for specifying communication between runnable entities in a software component.

[0044] An IRV can be implicit or explicit. Implicit means that the runnable entity works with a local copy of the IRV. The local copy is created by the runtime environment when the runnable entity begins execution. When the runnable entity finishes, changes are written back. This avoids conflicting accesses to the IRV while the runnable entity is running. Explicit means that the runnable entity has direct access to the IRV. To another runnable entity, changes become immediately visible upon access to the corresponding IRV.

[0045] In AUTOSAR communication via ports, it is also useful to distinguish between reading a second placeholder representing a data object and writing a third placeholder representing a data object.

[0046] Implicit AUTOSAR communication is variable, but read and write access must be distinguished, so it cannot be used for the first placeholder if it is used in general.

[0047] Explicit AUTOSAR communication is not available variably and must distinguish between read and write access.

[0048] Both of these can be resolved by the local buffer resolving the second placeholder to a read access and / or the third placeholder to a write access, and the first placeholder to a direct access to the local buffer.

[0049] Further embodiments of the invention are the subject of the following description, which refers to the further subclaims and figures.

[0050] According to a preferred embodiment of the invention, the method is configured to generate a first placeholder, a second placeholder and a third placeholder in the program code belonging to a subsystem of the surrounding graphic model, whereby advantageously a variable represented by the first placeholder can be generated at a predetermined position in the program code belonging to the graphic model.

[0051] According to another preferred development of the invention, the method is configured to include a step of generating a fourth placeholder, which is located at the beginning of the used area of ​​the predetermined section of the program code for defining the variable represented by the first placeholder. Thus, by providing a fourth placeholder, which is a setup placeholder, it is advantageous to use an auxiliary variable for buffering the value of the data object or variable.

[0052] According to another preferred development of the invention, in a predetermined section of the program code, it is arranged to perform calculations using first placeholders representing variables, so that by replacing the first placeholders by variables the calculations and / or operations performed in the code can be changed accordingly.

[0053] According to another preferred development of the invention, the second placeholder is arranged immediately before the beginning of a predetermined section of the program code that uses the first placeholder, in particular at the beginning of the area where the first placeholder is used, so that the actual value of the variable represented by the first placeholder can be determined advantageously immediately before its use.

[0054] The second placeholder can be used to define, for example, a local variable, which is then accessed through the first placeholder. Alternatively, it is possible to access a global variable through the first placeholder and not define a local variable.

[0055] The idea of ​​the present invention is that in the generated program code, access to external data objects can be adapted more or less arbitrarily, without the need to regenerate the generated program code by replacing placeholders accordingly.

[0056] According to another preferred development of the invention, the third placeholder is arranged immediately after the end of the section of the program code that uses the first placeholder, in particular at the end of the area used by the first placeholder, so that the newly calculated value can be written immediately after the area used by the first placeholder by replacing the third placeholder with a write access, thereby avoiding possible side effects due to a delay between calculation and write-back.

[0057] According to another preferred development of the invention, the program code is configured to generate at least one placeholder, in particular a first placeholder, a second placeholder, a third placeholder and / or a fourth placeholder, as a preprocessor macro in the program code.

[0058] According to another preferred development of the invention, placeholders are used in subsystems and are defined in a graphical model, which thus allows the definition of variables to be used within the framework of incremental code generation and their implementation or use in the corresponding subsystems.

[0059] Corresponding variables can be defined, for example, in a data dictionary. When using placeholders in the interface of an incremental code generation unit, TargetLink automatically generates definitions in the external code generation system based on the links present in the graphical model. In turn, the internal system generates corresponding placeholder usages. In turn, the external system generates definitions for the placeholders used internally.

[0060] In a model with multiple hierarchical levels, multiple groups of placeholders may be used, preferably with the placeholders of internal subsystems being identified with the corresponding placeholders of external subsystems. Preferably, first, corresponding definitions for the placeholders used are generated in the model including all subsystems.

[0061] According to another preferred development of the invention, in particular during incremental program code generation, provision is made to create at least one local variable in the already generated program code by defining at least one placeholder.

[0062] According to another preferred development of the invention, the variables represented by the first placeholders are accessed via function calls, where the second, third and / or fourth placeholders can be defined as empty, and the variables represented by the first placeholders are preferably stored in a database or data dictionary that is not part of the graphic model.

[0063] According to a further preferred development of the invention, provision is made to read and write, in particular external variables, via function calls in the AUTOSAR RTE API or Runtime Environment API, where placeholders define the positions in the program code where these should be created, so that the corresponding variables can be created exactly at the desired positions in the code.

[0064] According to another preferred development of the invention, the placeholders are defined in such a way that in a multithreading model, locks are provided that prevent different threads from accessing the same resource simultaneously, allowing the user to easily implement a locking mechanism by defining appropriate macros.

[0065] According to a further preferred development of the invention, provision is made in particular for the placeholders to be defined in such a way that error handling of the access functions is provided, in particular by storing the last error-free value in a persistent variable.

[0066] In this way, the last known error-free value can advantageously be stored in a unique persistent variable (which can be defined in the corresponding setup macro) so that it can be used in case of an error, or an alternative access function can be called.

[0067] The features described herein of a method for generating program code of a control program executable for controlling a control system are equally applicable to a computer system according to the present invention, and vice versa.

[0068] For a better understanding of the present invention and its advantages, reference should be made to the following description taken in conjunction with the accompanying drawings, in which:

[0069] The invention will be explained in more detail below on the basis of exemplary embodiments shown in the schematic diagrams of the drawings. [Brief explanation of the drawings]

[0070] [Figure 1] FIG. 2 shows a flowchart of a method for generating program code for an executable control program for controlling a control system, according to a preferred embodiment of the present invention. [Figure 2] 1 shows the time course of the execution of two runnable entities R1 and R2 of a control program executable on a control device. [Figure 3] FIG. 1 illustrates a method for configuring a controller according to a preferred embodiment of the present invention. [Figure 4] 1 is a schematic diagram of a computer system in accordance with a preferred embodiment of the present invention; [Figure 5] FIG. 1 illustrates an exemplary block diagram from which program code can be generated. DETAILED DESCRIPTION OF THE INVENTION

[0071] Unless otherwise specified, like reference numbers refer to like elements in the drawings.

[0072] The method shown in FIG. 1 includes the step of generating program code 1 of a control program executable for controlling a control system.

[0073] The functionality of the control program is described at least in part in a graphical model 2. This graphical model 2 is converted into program code 1 in a text-based programming language.

[0074] The method further comprises a step S1 of generating a first placeholder P1 representing a variable to be used in the preset section 10 of the program code 1.

[0075] The method further includes a step S2 of generating a second placeholder P2 in the section 10 that uses the first placeholder P1 and that is positioned before the beginning of the predetermined section 10 of the program code 1.

[0076] Further, the method includes a step S3 of generating a third placeholder P3 that is located after the end of the predetermined section 10 of the program code 1, the section 10 using the first placeholder P1.

[0077] In particular, in the program code 1 belonging to the subsystem 12 of the surrounding graphic model 2, a first placeholder P1, a second placeholder P2 and a third placeholder P3 are generated.

[0078] Further, the computer-implemented method includes a step S4 of generating a fourth placeholder P4, which is placed at the beginning of the use area 14 of the preset section 10 of the program code 1, to define the variable represented by the first placeholder P1.

[0079] In the preset section 10 of the program code 1, a calculation is performed using a first placeholder P1 representing a variable.

[0080] The second placeholder P2 is located immediately before the beginning of the section 10 of the program code 1 that uses the first placeholder P1, that is, the preset section 10, in particular at the beginning of the usage area 14 of the first placeholder P1.

[0081] The third placeholder P3 is placed immediately after the end of the section 10 that uses the first placeholder P1 and that is preset in the program code 1, in particular at the end of the usage area 14 of the first placeholder P1.

[0082] Here, as a preprocessor macro in the program code 1, at least one placeholder is generated, in particular a first placeholder P1, a second placeholder P2, a third placeholder P3 and / or a fourth placeholder P4.

[0083] Placeholders are used in the subsystem 12 and defined in the graphic model 2.

[0084] In particular, during incremental program code generation, at least one placeholder P1, P2, P3, P4 is defined to create at least one local variable in the already generated program code 1.

[0085] The variable represented by the first placeholder P1 is accessed via a function call 16. Additionally, if desired, the second placeholder P2, the third placeholder P3 and / or the fourth placeholder P4 can be defined to be empty.

[0086] Within the framework of conventional variable placeholders, a fixed read-execute-write sequence is provided, which can be problematic in the case of, for example, the concurrent execution of several subsystems or the program code contained by these subsystems, such as the runnable entities R1 and R2 shown in Figure 2. Access to the placeholder value is made at the beginning of the corresponding program code section, for example by a function call in the runtime environment API.

[0087] In the conventional method, if the program code already generated incrementally has only one (variable) placeholder, it is not possible to call the RTE-API function later in this program code. Therefore, functions can be generated only in the newly generated program code of the external system before the call of the internal system.

[0088] FIG. 2 shows the time course of the execution of two runnable entities R1 and R2 of a control program executable on a control device.

[0089] By generating the code for the runnable entity R1 according to the method according to the invention, better temporal coincidence between the reading and calculating processes can be achieved.

[0090] The t-axis shows the time course of this embodiment, where R1 and R2 are executed in parallel. Here, reference numeral 9 denotes the incrementally generated region of R1, and reference numeral 11 denotes the subregion where placeholders are accessed or calculations are performed. According to the prior art, read and write accesses take place outside the incrementally generated region, here shown at times 11a and 11b.

[0091] Here, in particular, external variables are read and written via function calls 16 in the AUTOSAR RTE-API, respectively.

[0092] The diagram also shows how runnable entity R2, which executes in parallel, accesses the same variable at time t1 and writes a new value to it. Runnable entity R1 performs a calculation with the variable after R2's write access has taken place, so this calculation must be performed compensatory with the new value. However, because the read access took place at time 11a, the calculation is actually still performed with the old value.

[0093] Furthermore, runnable entity R2 accesses the variable again at time t2 to read its latest value, which at this stage should have been the value changed by the calculation in R1, but which is only written back at time 11b. Overall, the arrangement of read and write accesses means that both R1 and R2 end up working with an outdated and possibly incorrect value for the variable.

[0094] The code generation according to the invention generates multiple accesses in the code of subregion 11, which are therefore closer to the computation, as indicated in the figure by the vertical dashed lines 11a' and 11b'. Thus, according to the invention, even in the case of incremental code generation, it is possible for the value written by R2 at time t1 to be used in computation 11, and for R2 at time t2 to read the value already calculated in 11.

[0095] According to another preferred embodiment, TargetLink is used to model AUTOSAR software components or the runnable entities they contain. A runnable entity is the smallest independently executable sub-module of an AUTOSAR software component. If a runnable entity has a large number of sub-modules, such as subsystems, and especially library blocks, it can be difficult to correlate or debug errors that occur.

[0096] Instead of direct or explicitly modeled AUTOSAR communication, it is advantageous to use placeholders: for each sub-module, an adapted model can be created, containing runnable entities adapted for testing.

[0097] By using placeholders, the code for the partial module itself only needs to be generated once, avoiding the multiple tests that are typically required when code generation is repeated.

[0098] Equivalent test modeling can in principle also be used for non-AUTOSAR models that use equivalent access functions such as explicit AUTOSAR communication. The advantage of placeholders is that they can be used for explicit access functions as well as for traditional / variable access.

[0099] According to another preferred embodiment, the calibration and measurement quantities are stored separately from the code of the functions, so that at the time of code generation it may not yet be known exactly where these variables should be associated for certain components, and possibly these components will be reused in other projects.

[0100] The use of constants under AUTOSAR usually requires RTE-API function calls, since calibration and measurement quantities should be stored in the RTE or runtime environment. In other cases, calls to special hardware functions may be required. Placeholders for access to constants are modeled so that the access details can be adapted later without changing the function code.

[0101] Furthermore, the corresponding subsystems providing, for example, a PID controller with configurable functionality can be easily reused without requiring new code generation.

[0102] According to another preferred embodiment, the placeholders P1, P2, P3, P4 are defined in such a way that locks are provided in a multithreading model that prevents different threads from accessing the same resource at the same time.

[0103] When a model or a program contains multiple threads, this requires a locking mechanism to prevent different threads from accessing the same resources simultaneously, in particular shared memory, i.e., global variables, for example.

[0104] In the corresponding placeholder position in the code, for example, a bit can be set to 1 or a pre-set count variable can be incremented. The respective task continues to run as soon as it is able to do so, thus waiting for the corresponding lock. In this case, for enabling, the corresponding bit or count variable is subsequently reset back to its original state.

[0105] Therefore, users can easily implement a locking mechanism by appropriate macro definition, where the second placeholder P2 is used for locking and the third placeholder P3 is used for enabling.

[0106] According to another preferred embodiment, the placeholders are further defined in such a way that error handling of the access functions is provided, in particular by storing the last error-free value in a persistent variable.

[0107] For example, some access functions, such as RTE-API functions, can signal in case of an error that the data read was incorrect or that the data could not be written correctly. Corresponding handling of this error case can then be added to the macro definition. In this way, for example, the last known error-free value can be stored in a specific persistent variable that can be defined in the corresponding setup macro or placeholder, so that it can be used in case of an error, or an alternative access function can be called.

[0108] FIG. 3 shows a method of configuring a control device 18 according to a preferred embodiment of the present invention, the control device 18 including at least one computing unit 20 and preferably having at least one sensor 22 and / or at least one actuator 24 for detecting and / or acting on data of a physical process.

[0109] The method comprises a step S1' of reading a block diagram and a step S2' of generating a program code 1 by the method according to the invention.

[0110] The method further includes a step S3' of compiling the program code 1 for the computing unit 20 to generate an executable program code 1', and a step S4' of transmitting the executable program code 1' to the control device 18.

[0111] The method further includes a step S5' of storing the executable program code 1' in a non-volatile memory of the control device 18 and / or executing the executable program code 1' by the computing unit 20 of the control device 18.

[0112] FIG. 4 shows a schematic diagram of a computer system 100 in accordance with a preferred embodiment of the present invention.

[0113] The computer system 100 includes a man-machine interface 101, a non-volatile memory 102, and a processor 103. The processor 103 is configured to perform at least one of the methods according to the invention.

[0114] FIG. 5 shows an example of a block diagram from which program code can be generated.

[0115] The block diagram shows an input port "In1" that receives a scalar input signal and an output port "Out1" that outputs a scalar output signal. The input port "In1" is connected to a first calculation block "Multiply", which multiplies the resulting signal by the value 3.14159 obtained from the constant block "Constant". The first calculation block "Multiply" is connected to a second calculation block "Add", which adds the resulting signal by the value 2.71828 obtained from the constant block "Constant1". The second calculation block "Add" is connected to a third calculation block "Multiply1", which multiplies the resulting signal by the input signal received at the input port "In1" and transfers the result to an output port.

[0116] According to a preferred embodiment of the method according to the invention, a first set of placeholders is generated for the input signal and a second set of placeholders is generated for the output signal. For the input signal, preferably a first placeholder "RDI_In", a second placeholder "RDI_In_Start", a third placeholder "RDI_In_Stop", and a fourth placeholder "RDI_In_Setup" are generated. For the output signal, preferably a first placeholder "RDI_Out", a second placeholder "RDI_Out_Start", a third placeholder "RDI_Out_Stop", and a fourth placeholder "RDI_Out_Setup" are generated.

[0117] To be able to incorporate the block diagram as a library function "LibraryFunction", preferably the following program code is generated: #include "tl_rdi_LibraryFunction.h" void Sincr1_LibraryFunction(void) { RDI_In_Setup RDI_Out_Setup RDI_In_Start RDI_Out_Start / * Outport: LibraryFunction / Out1 # combined # Product: LibraryFunction / Product1 # combined # Sum: LibraryFunction / Sum # combined # Product: LibraryFunction / Product * / RDI_Out = RDI_In * ((RDI_In * 3.14159)+ 2.71828); RDI_In_Stop RDI_Out_Stop }

[0118] Depending on the desired use of the library function, the placeholders can be replaced by different program code fragments. For example, if you want to get input values ​​via variables and output values ​​via variables as well, you can define the second, third, and fourth placeholders as empty. The resulting program code is just as compact as if no additional placeholders were provided.

[0119] In an alternative embodiment, if an input value is to be received via a first access function "RDI_InImpl" and an output value is to be output via a second access function "RDI_OutImpl", the placeholder may be defined, specifically as a preprocessor macro, as follows: #define RDI_In RDI_InImpl #define RDI_In_Setup float64 RDI_InImpl; #define RDI_In_Start Rte_Read_ReceiverPort_DE(&RDI_InImpl); #define RDI_In_Stop #define RDI_Out RDI_OutImpl #define RDI_Out_Setup float64 RDI_OutImpl; #define RDI_Out_Start #define RDI_Out_Stop Rte_Write_SenderPort_DE(RDI_OutImpl);

[0120] In this case, the already generated code looks like this to the compiler after macro substitution: void Sincr1_LibraryFunction(void) { float64 RDI_InImpl; float64 RDI_OutImpl; Rte_Read_ReceiverPort_DE(&RDI_InImpl); / * Outport: LibraryFunction / Out1 # combined # Product: LibraryFunction / Product1 # combined # Sum: LibraryFunction / Sum # combined # Product: LibraryFunction / Product * / RDI_OutImpl = RDI_InImpl * ((RDI_InImpl * 3.14159) + 2.71828); Rte_Write_SenderPort_DE(RDI_OutImpl); }

[0121] In the program code, Rte-API functions in the library functions are called by local variables as desired. By using additional macros, the generated code is flexible enough to be used for both communication via global variables and access functions via local buffers, without requiring new code generation for incremental parts.

[0122] The method for generating program code according to the invention therefore allows the generated program code to be adapted to support different communication methods, even in the case of incremental code generation.

Claims

1. 1. A computer-implemented method for generating program code (1) of an executable control program for controlling a control system, comprising: The functionality of the control program is at least partly described in a graphical model (2), and a method for converting the graphical model (2) into program code (1) in a text-based programming language comprises the following steps: A step (S1) of generating a first placeholder (P1) representing a variable to be used in a predetermined section (10) of said program code (1); generating (S2) a second placeholder (P2) for the section (10) using the first placeholder (P1), the second placeholder (P2) being placed before the beginning of the predetermined section (10) of the program code (1); generating (S3) a third placeholder (P3) in said section (10) using said first placeholder (P1), said third placeholder being placed after the end of said predetermined section (10) of said program code (1); 10. A computer-implemented method comprising:

2. generating said first placeholder (P1), said second placeholder (P2) and said third placeholder (P3) in a program code (1) belonging in particular to a subsystem (12) of a surrounding graphic model (2); 10. The computer-implemented method of claim 1.

3. The method further comprises a step (S4) of generating a fourth placeholder (P4) located at the beginning of a used area (14) of the predetermined section (10) of the program code (1) to define the variable represented by the first placeholder (P1), 10. The computer-implemented method of claim 1.

4. performing a calculation using the first placeholder (P1) representing a variable in the predetermined section (10) of the program code (1); 10. The computer-implemented method of claim 1.

5. the section (10) using the first placeholder (P1), and the second placeholder (P2) being located immediately before the beginning of the predetermined section (10) of the program code (1), in particular at the beginning of the usage area (14) of the first placeholder (P1); 10. The computer-implemented method of claim 1.

6. the section (10) using the first placeholder (P1), and the third placeholder (P3) being placed immediately after the end of the predetermined section (10) of the program code (1), in particular at the end of the usage area (14) of the first placeholder (P1); 10. The computer-implemented method of claim 1.

7. generating at least one placeholder (P1, P2, P3, P4), in particular the first placeholder (P1), the second placeholder (P2), the third placeholder (P3) and / or the fourth placeholder (P4), as a preprocessor macro in the program code (1); 4. The computer-implemented method of claim 3.

8. using said placeholders in said subsystem (12) and defining them in said graphic model (2); 3. The computer-implemented method of claim 2.

9. creating at least one local variable in the already generated program code (1) by defining at least one placeholder (P1, P2, P3, P4), in particular during incremental program code generation; 10. The computer-implemented method of claim 1.

10. the variable represented by the first placeholder (P1) is accessed via a function call (16), wherein the second placeholder (P2), the third placeholder (P3) and / or the fourth placeholder (P4) can be defined as empty; 4. The computer-implemented method of claim 3.

11. reading and writing of the external variables, in particular via function calls (16) in the AUTOSAR RTE-API, wherein the second placeholder (P2) and the third placeholder (P3) define the location in the program code (1) where one function call (16) is to be generated, respectively; 10. The computer-implemented method of claim 1.

12. defining the placeholders (P1, P2, P3, P4) so ​​as to provide a lock in a multithreading model that prevents different threads from accessing the same resource simultaneously; 10. The computer-implemented method of claim 1.

13. In particular, defining the placeholders so that error handling for the access functions is provided by storing the last error-free value in a persistent variable; 10. The computer-implemented method of claim 1.

14. A method for configuring a control device (18), comprising the steps of: The control device (18) comprises at least one calculation unit (20) and preferably has at least one sensor (22) and / or at least one actuator (24) for detecting and / or acting on data of a physical process, and the method comprises the following steps: A step (S1') of reading a block diagram; - generating (S2') a program code (1) by a method according to any one of claims 1 to 13; a step (S3') of compiling the program code (1) for the computing unit (20) to generate an executable program code (1'); transmitting (S4') the executable program code (1') to the control device (18); storing (S5') the executable program code (1') in a non-volatile memory of the control device (18) and / or executing the executable program code (1') by the computing unit (20) of the control device (18); A method having the following.

15. 14. Computer program having a program code (1) for performing at least one of the methods according to any one of claims 1 to 13 when the computer program is run on a computer.

16. A computer-readable data carrier having a program code (1) of a computer program for performing at least one of the methods according to any one of claims 1 to 13 when the computer program is run on a computer.

17. A computer system (100) including a man-machine interface (101), a non-volatile memory (102), and a processor (103), The processor (103) is configured to perform at least one of the methods according to any one of claims 1 to 13. A computer system (100).

Images