INTEGRATED SIMULATION CODE AND PRODUCTION CODE GENERATING

Description

[0001] The present invention relates to the model-based development and model-based testing of programs, in particular control programs for control units. In particular, the present invention relates to a method and a code generator for generating source code from a model of a program, for example, a control program, wherein the source code comprises both simulation code portions for testing the model and production code portions executable on the control unit. Furthermore, the invention relates to a test environment for testing models for control programs.

[0002] Model-based development and testing of technical systems have become established in many development processes across many applications, such as the development of control programs, particularly for ECUs in the automotive sector. Model-based development offers the possibility of graphically modeling technical systems at a high level of abstraction, rather than having to program them. The actual source code is no longer programmed manually, but is largely generated automatically from the model, thus placing the focus of development on the model rather than the code.

[0003] Production code generation is the logical step for converting models into efficient, production-ready code. TargetLink is an example of such a model-based environment. TargetLink generates highly efficient production code as C code directly from MATLAB / Simulink or Stateflow and enables early verification through the integration of simulation and testing. TargetLink supports efficient modular development, is certified for ISO 26262, ISO 25119, and IEC 61508, and offers powerful native AUTOSAR support.

[0004] Although automatic code generators reduce the error rate compared to manual programming, both the generated code and the underlying specification, or model, must be tested.

[0005] US 2006 / 0010429 A1 discloses a method for model-based software development with test case generation and evaluation. Source code generated from a model definition of the control process processing input data is retrieved. Furthermore, model information from the model definition is retrieved, and the test case is generated based on the source code and the model information.

[0006] The control programs developed in the above manner are usually not standalone programs, but interact with external components (software and / or hardware components).

[0007] For example, during AUTOSAR software development, it may happen that a first runnable of a software component (SWC) exchanges data with a second runnable, where the second runnable may be located within the first SWC or in a second SWC. Parallel execution of the two runnables can cause side effects that are not currently covered in Simulink. Because the external software components are often only available in later development phases, early testing of the control program is not possible or only possible to a limited extent.

[0008] Hardware-dependent technical effects resulting from the interaction of the production software with external hardware components are also typically not covered in the model at an early development stage. Here, too, the development and implementation of the external hardware components are unknown, making early testing of the production software impossible or only possible to a limited extent.

[0009] To achieve early testing with appropriate coverage, there should be options for injecting "external" signals within a model, allowing parallel execution to be simulated by emulating external components and specifically modeling side effects resulting from interactions with external components. In addition to the option of injecting external signals into the model for testing purposes, it is also desirable to "tunnel out" or hide signal values from the model, especially when missing model and code components are implemented for testing purposes using "stubs" that must be appropriately simulated during the simulation.

[0010] In this respect, it is the object of the present invention to provide a modeling and testing environment that overcomes the above-mentioned disadvantages.

[0011] The invention is based on the finding that this problem can be solved by assigning simulation code to individual blocks. The blocks assigned as simulation code can be placed at various locations alongside the production code blocks. Depending on the assignment, the code generator then generates production code or simulation code from the corresponding block or a group of blocks. Thus, both production code and simulation code can be generated from an existing model in a single run. The simulation code is used temporarily for testing purposes and can be removed from the production code before the latter is compiled and executed on the control unit.

[0012] This object is achieved by a method and a test environment according to the independent claims. The dependent claims specify advantageous embodiments and further developments of the invention. In a first aspect of the invention, a method for generating source code from a model according to claim 1 is provided.

[0013] By assigning model blocks an additional attribute as simulation code blocks, these attributed blocks can be used for simulation. However, when generating source code, the simulation code output is separated from the production code. Thus, by inserting appropriately attributed blocks into the model, the user can emulate the substitute behavior of external components, thus enabling testing of the model with high coverage.

[0014] The method according to the invention thus makes it possible to inject a test signal into the model or to trigger a change in a data element occurring between two calls of an AUTOSAR runnable. Furthermore, changes within a time step or the occurrence of interrupts can be modeled with simulation code blocks. Since these components are separated from the production code component in the generated source code, the generated production code can also be used in the ECU without requiring re-code generation or modification of the model.

[0015] The method according to the invention provides a modeling environment that enables simulation and testing of models for production code, in particular for production code that is linked in a technical system, for example a control unit, with external software and / or hardware components whose exact implementation is only determined at a later point in time.

[0016] The method according to the invention makes it possible to generate both simulation code and production code within a single run of the code generator.

[0017] Preferably, the simulation code is integrated into the source code using preprocessor instructions.

[0018] By integrating the simulation code components into the source code using preprocessor instructions, such as a preprocessor macro, the corresponding instructions can be inserted, retained, or removed by a preprocessor at the relevant locations in the source code. The simulation code components can thus remain in the overall code—enclosed by preprocessor instructions—and are only removed during compilation for the ECU. This ensures that the code generation for the production code is as identical as possible to the test version, thus guaranteeing consistent behavior both during the simulation and for the final production code on the ECU.

[0019] The detachable integration of simulation code and production code in the source code can be achieved, for example, using conditional compilation constructs. For example, the #ifdef statement can be used to bracket an implementation of an external function, thus removing it from the source code without leaving any residue. Other well-known preprocessor statements, such as #include or #define, can also be used for this purpose.

[0020] The above approach allows the simulation code to always remain in place and only be discarded when the production code is compiled.

[0021] Preferably, the simulation code can be stored separately from the production code in a code module or a code file.

[0022] By moving the simulation code components into separate code modules, a separation between simulation code and production code can be achieved at the file level. This avoids the risk of inconsistencies during code generation, as a single code generation pass is sufficient to generate both code for a software-in-the-loop simulation and code for use in the final ECU. Furthermore, the clear separation of the two code components ensures that no simulation code components are included in the final production code.

[0023] The method further comprises the step of performing a software-in-the-loop simulation, taking into account the simulation codes.

[0024] A software-in-the-loop simulation enables fast and efficient testing of the production code.

[0025] Preferably, a model-in-the-loop simulation can be performed for the entire model or for specific model blocks. A model-in-the-loop simulation can be used to verify correctness at the model level, i.e., to check whether the blocks executed during the simulation actually describe the intended behavior of the control program. Furthermore, a first portion of the model can be simulated in a model-in-the-loop mode, e.g., to describe a controlled system, while simultaneously a second portion of the model is simulated in a software-in-the-loop mode. The second portion can contain production code and / or simulation code.

[0026] The method further comprises the step of discarding the simulation code and compiling the production code for execution on a processor of an ECU. Execution can occur at any time if the compiled code is first stored in a non-volatile memory of the ECU.

[0027] Preferably, a block marked with a simulation code attribute includes at least one additional attribute that is taken into account when generating simulation code. This allows multiple attributes to be used to differentiate between simulation code components depending on their purpose, allowing, for example, a distinction to be made between logging (reading a value) and value specification (writing a value). This allows variants or different types of simulation code to be distinguished within the simulation code. In particular, depending on the function, a distinction can be made between signal injection, debug / assert, and logging. It is also possible, for example, to enable only the simulation code for logging blocks. This results in a flexible and efficient simulation.

[0028] Preferably, the step of generating simulation code includes a code optimization step taking into account the at least one further attribute. This allows simulation code attribute(s) to be read to set properties (particularly regarding code optimization) accordingly during code generation. For example, the simulation code can be optimized for readability, in particular by not eliminating any variables.

[0029] Preferably, a block is assigned a simulation code attribute if the block specifies an aspect of a component interacting with the program and / or external influences on the program, whereby the simulation code generated from the block emulates the aspect of the component and / or the external influences on the program. Such a block can thus model the behavior of an external component as well as any external influences on the program. Furthermore, a group of blocks can model the behavior; in this case, each individual block would be attributed as a simulation code block.

[0030] Preferably, the step of generating simulation code comprises generating a stub function from the specified behavior of the component, wherein the stub function emulates the component interacting with the program through the corresponding simulation code.

[0031] The additional attribution of the blocks as simulation code blocks can preferably be used to simulate a component, for example, a parallel-executing software component, in particular an I / O driver, whose concrete implementation is initially unknown and will only be determined in a later development phase. In other words, a block or a group consisting of several blocks will replace a component. For example, this could be a block for changing a variable value ("Data Store Write", DSW), which emulates / models a replacement behavior of a software component, changes the values of certain program variables, or even a block that models a call to a software component. This makes it possible to perform a simulation of the program even if the software environment in which the program is executed has not yet been implemented.

[0032] In software development, a stub function refers to program code that replaces another program code. The actual program code being replaced by the stub has not yet been developed. The stub function thus emulates the substitute behavior of a component that interacts with the program. By emulating a component using a stub function, a rudimentary behavior of the component is described in the model, enabling testing of the production code in an early development phase when the exact implementation of the component is not yet known. For example, an I / O driver can be temporarily considered for simulation purposes using the generated stub function.

[0033] Preferably, the step of generating simulation code comprises generating function calls for transforming an input signal. The function calls can model different algorithms that transform the input signal. This allows input signals whose values change within a sampling step to be efficiently simulated.

[0034] By inserting appropriately attributed blocks into the model, a test signal can be injected to externally modify model variables and / or parameters. Signal injection occurs via the block attributed as simulation code, but the signal injection is not indicated by signals. Signal injection can also be used, for example, to specify a value for the production code using a constant block. In this case, the block attributed as simulation code has only one output.

[0035] Preferably, the simulation code replaces function calls for assigning a value to a local variable occurring in the production code. The value assignment can include both initializing and modifying an existing value.

[0036] This provides a flexible simulation environment that allows the value of a variable and / or parameter to be flexibly changed in each simulation step.

[0037] Preferably, the simulation code contains a global simulation variable whose value is determined by a value of a local variable calculated in the production code. This allows the signal to be measured or logged for later analysis or debugging.

[0038] Preferably, the production code contains a local variable whose value is determined by a global variable calculated in the simulation code. This allows for reading and writing of local variables.

[0039] Preferably, the simulation code comprises an initialization module that initializes parameters and / or variables of the emulated component, and a function module that contains functions, in particular stub functions, of the emulated component, wherein function calls (e.g., one or more stub functions) are made in the production code.

[0040] Preferably, the initialization module comprises an index-based data structure, in particular an array, wherein the data structure defines a plurality of values of a variable, wherein each time a stub function is called in the production code, individual values of the variable are accessed via the index.

[0041] By using an index-based data structure, multiple calls to a component in the simulation code can be designed efficiently.

[0042] To ensure that the test cases can be modeled as smoothly as possible, a correctness check is carried out. The model is considered correct if a continuous signal line within a hierarchy level has matching block markings as simulation code blocks, i.e. blocks whose simulation code attributes are set. A signal line refers to the signal line known from Simulink, for example, which connects the output of a first block with the input of a subsequent second block and indicates that the signal input of the second block depends on the signal output of the first block. If the first block is marked as a simulation block, the second block would also have to be attributed as such, since both blocks model aspects of the substitute behavior of an external component.

[0043] Preferably, the method further comprises the steps of checking, starting from a first block comprising a simulation code attribute, whether all consecutive blocks along a simulation line extending from the first block comprise simulation code attributes, and generating an error message if the simulation code attribute of a block is not set. The check can stop at a block along the simulation line marked as a transition block.

[0044] A simulation line can correspond to a signal line familiar from Simulink, which connects blocks within a hierarchy level. This ensures that signal connections only occur between simulation code components (which can, in principle, also be in different subsystems). This avoids difficult-to-find errors if individual components are not marked as simulation code, causing, for example, a value assignment to mistakenly remain in the production code.

[0045] In addition, it can also be provided that the blocks along the simulation or signal lines that incorrectly do not have a simulation code attribute are automatically assigned one.

[0046] For ease of use, it can also be provided that a group of blocks can be selected and the simulation code attribute can be set the same for all selected blocks. Alternatively, it is also conceivable to perform backward propagation starting from a target block marked as simulation code (or the output port linked to the input to be stimulated). In this case, all blocks passed through are marked as simulation code blocks until a block is reached that marks a boundary.

[0047] Preferably, certain blocks, also called transition blocks, which have been assigned a fixed predefined property as production code blocks, can form a boundary between simulation and production code parts in the model.

[0048] Transition blocks can be selected, for example, from the TargetLink block library and can contain additional data for code generation, such as scaling information for fixed-point variables, variable classes, variable names, etc. For code generation, all production code blocks can be assigned individual scaling. These blocks then also contain the additional data for code generation mentioned here. Block libraries can, in particular, contain predefined, composite blocks.

[0049] However, it is also conceivable to mark the boundary between the simulation and production portions without dedicated transition blocks, for example, by considering an in-port or an out-port as a transition block. For better readability, however, the use of a dedicated transition block is advantageous.

[0050] According to a third aspect, the invention relates to a test environment for testing models for control programs according to claim 13.

[0051] Code generators, such as those typically used for production code generation, can be used to generate simulation code. However, it should be possible to not optimize simulation code in the same way as production code, since, for example, it is not always sensible to "optimize away" variables. Code generators with flexible optimization options make it possible, for example, to distinguish whether a variable can be omitted or not. The simulation code attribute allows you to select a predefined set of optimization options. In conjunction with this, different optimizations can also be applied within the simulation code. For example, certain variables related to measured values can play an essential role in prototyping and should therefore be considered in the simulation code.Therefore, when optimizing simulation code, the focus could be more on readability and less on maximum execution speed, as is usually the case for production code.

[0052] Further features and advantages of the invention will become apparent from the following description of exemplary embodiments according to the invention as well as further alternative embodiments in conjunction with the following drawings, which show: Figure 1 shows a schematic view of the model-based environment according to the invention for developing and testing programs; Figure 2 shows a block diagram of the method according to the invention for generating source code comprising simulation code and production code; Figure 3 shows an embodiment of the invention for simulating the interaction between an AUTOSAR model and a parallel-executed runnable of another software component; Figure 4 shows an embodiment for signal manipulation, in which a value is to be read from a memory location, which value can be changed by external processes; Figure 5 shows an embodiment of the invention for signal injection and tunneling; Figure 6 shows an embodiment of the invention for emulating multiple calls of a software component.

[0053] The same reference symbols and designations are used for the same elements in the different drawings. DETAILED DESCRIPTION

[0054] Fig. 1 shows schematically the structure of a model-based environment 100 for developing and testing control programs, in particular control programs for control units.

[0055] The model-based development and test environment 100 includes a code generator (CG) 120 and a simulator (SIM) 130.

[0056] Furthermore, the development and test environment can include a model editor (MOD) 110. The model editor 110 can provide a graphical user interface for creating and modifying block diagrams that preferably describe or model the dynamic, time-dependent behavior of a system or program. The blocks can, for example, describe finite program states and conditions for transitions between states, similar to Stateflow, or operations on signals that are executed cyclically with a specified frequency, as known from Simulink.

[0057] A block can describe an atomic operation, such as an arithmetic calculation or a logical expression, or it can represent a subsystem that is further described by another block diagram at a lower hierarchical level. Thus, the functionality of a hierarchical block is defined by a multitude of blocks at a lower level.

[0058] Alternatively, it can contain code in a programming language, particularly a dynamic language intended for mathematical programming, which implements the functionality of the block. Multiple blocks can be connected by signals for data exchange. For example, an output block can receive a Single signal as an input (in other words, a block parameter for code generation), modify the signal, for example, by adding a constant, and send an output Double signal to another block. In other words, two blocks can be connected by a signal path or signal line, so that data flows from the first block to the next block, as is known, for example, from Simulink.

[0059] According to the invention, the model editor 110 offers the user the possibility of marking certain blocks with a simulation code attribute in order to distinguish attributed blocks (block 111) that are used for simulation purposes from blocks (block 112) that are used exclusively for generating production code.

[0060] This attribution of the blocks is taken into account by the code generator (CG) 120. The code generator 120 enables the creation of source code from the blocks of the block diagram created by the model editor 110. Due to the inventive attribution of the blocks at the model level, the generated source code contains both simulation code portions and production code portions corresponding to the respective blocks. The code generator 120 can preferably have a modular structure, comprising a module (PCG) 121 for generating production code and a module (SCG) 122 for generating simulation code. However, it is also conceivable to provide both functionalities through a single module.

[0061] Both the production code portion and the simulation code portion can be optimized according to different criteria. For example, the code can be optimized for readability, traceability, security, low power consumption, execution speed, and / or memory requirements. The code generator preferably provides a user interface for setting a variety of options for customizing the generated code. Customization options can include target-specific optimizations for the embedded program's microcontroller and enforcing the generated code's conformance to a specific standard, such as the MISRA C guidelines. A particularly preferred code generator (CG) is TargetLink from dSPACE.

[0062] The simulator (SIM) 130 can be configured to execute a block diagram created in the model editor 110 in order to observe the temporal behavior of the dynamic system described by the block diagram. The simulator 130 can be configured to perform both a software-in-the-loop and a model-in-the-loop simulation. In the first case, the software-in-the-loop simulation is performed taking into account the simulation code created by the code generator 120. However, for certain model blocks, a model-in-the-loop simulation can also be performed by directly executing the blocks. With a model-in-the-loop simulation, the correctness can be checked at the model level, i.e., whether the blocks executed during the simulation actually describe the intended behavior of the control program. The entire model can be executed as a model-in-the-loop simulation.However, only certain model sections, such as a plant model, can be executed in model-in-the-loop simulation mode, while other model sections, such as a controller code, are executed in software-in-the-loop simulation mode.

[0063] After the simulation has been successfully executed, the simulation code portion can be removed from the source code. The source code, which can now contain exclusively production code, is preferably compiled so that it can be executed on a target processor 140, in particular on a processor of a control unit.

[0064] Fig. 2 is a block diagram illustrating the inventive method for generating source code from a model. The method can be implemented on the Fig. 1 The process is started on a model compiled with the model editor 110. The process from Fig. 2 is executed for each of the blocks in the model. The code generator 120 generates both production and simulation code in the same run. Simulation code is generated for blocks that include a simulation code attribute (step S10), and production code is generated for blocks that do not include a simulation code attribute (step S20).

[0065] By being able to assign a simulation code attribute to blocks and to set this attribute again in each code generation run, the same block can be used as a production block in one run and as a simulation block in another run.

[0066] In a further step S30, a simulation is performed taking the simulation code into account. This step preferably includes a software-in-the-loop (SIL) simulation. However, for certain model blocks, a model-in-loop (MIL) simulation can also be performed. Well-known simulation environments, such as TargetLink, can be used for this purpose. TargetLink, in collaboration with MATLAB / Simulink, provides various simulation modes for this purpose. The MIL simulation serves as a reference for the SIL simulation.

[0067] The SIL simulation can be performed on a host PC taking into account the simulation code and, if applicable, the results of the MIL simulation in order to compare the behavior of the generated code with the reference data obtained during the MIL simulation.

[0068] In addition to the MIL and SIL simulations, a processor-in-the-loop (PIL) simulation can also be performed. This can be performed on an evaluation board equipped with a processor that corresponds to the processor on the ECU. The combined use of the three simulation modes ensures the correctness of the generated source code.

[0069] The Figuren 3A bis 3C show an embodiment according to the invention in which a runnable of a software component of an AUTOSAR system is described. Here, the influence of a parallel runnable of another software component on the runnable described in the Simulink model is simulated. The basic assumption is that the block groups shown are executed in the order specified in the groups. This can be controlled in MATLAB / Simulink using block priorities.

[0070] Fig. 3A shows a Simulink model that describes the following behavior: The value of a data element x is read from the "Data Store Memory" block (not shown here) by the "Data Store Read" block Rte_Lies_x 320. At the same time, a value indicating whether the value of the data element x has changed is read from another "Data Store Memory" block by the "Data Store Read" block Rte_IstGeändert_x 310. This value is preferably a Boolean value. If the value has changed, block 330, an action specified by block 340 is executed. If the value of the data element has remained unchanged, the action specified by block 350 is executed.

[0071] The value of the data element x is changed by a runnable of a parallel executed SW component. The behavior of this additional SW component is determined by the model in Fig. 3B described. All four blocks in Fig. 3B are attributed as simulation blocks, ie, they are provided with a simulation code attribute. Blocks 360 and 370 each generate an output signal with a con stanten Value, with the output signals being forwarded as input signals 361, 371 to blocks 380 and 390, respectively. Signal line 371 models the writing of a new value of x, i.e., the new value of the data element x is written by the "Data Store Write" block Write_Data 390 into the "Data Store Memory" block (not shown here). Signal line 361 models a corresponding change in the state of the "Data Store Write" block Write_IsChanged 380, whereby a new value is written to the Data Store Memory block, indicating whether the value of the data element x has changed.

[0072] Fig. 3A and Fig. 3C show parts of the same runnable which are executed one after the other. Fig. 3B shows a model part that models the influence of another runnable executed in parallel and between the model parts in Fig. 3A and Fig. 3C is executed. Fig. 3C shows model parts that are influenced by the parallel executed runnable.

[0073] Further embodiments of the invention with examples for generating source code are described in the Figuren 4 bis 6 shown.

[0074] The Figuren 4A bis 4D The embodiment shown represents an example of signal manipulation in which a value is to be read from a memory location which can be changed by external processes.

[0075] Fig. 4A illustrates the conventional modeling, where production code is generated exclusively from blocks 410, 420, 430, in the form of: Int16 volatile * pInputVariable = (Int16 volatile *) 0x1111; FromPort_Var = Calculation_1(*pInputVariable); FromPort1_Var = Calculation_2(*pInputVariable); FromPort2_Var = Calculation_3(*pInputVariable);

[0076] Der Wert The variable InputVariable is read via port 400 and is thus defined for all subsequent calculations in blocks 410, 420, and 430. A simulation can only be realized by overwriting the variable InputVariable with a new value via port 400 for each simulation step. However, all calculations (Calculation_1 to Calculation_3) are performed with this same value. Therefore, the above approach cannot simulate a change in the value of InputVariable within a sampling step, allowing each calculation to be performed with a different value of the InputVariable.

[0077] This flexibility can be achieved by the inventive attribution of blocks as simulation blocks. Fig. 4B shows an inventive extension of the model from Fig. 4A , in which additional simulation blocks, ie blocks 440, 450, 460 provided with a simulation code attribute, are added. Simulation code is generated for these blocks, and production code is generated for the remaining blocks 410, 420, 430.

[0078] The blocks identified by the simulation code attribute are further specified in a lower model level by further blocks 461. Thus, in block 461, which contains the subsystem Subsystem_Fkt_ <n>specified, model different algorithms that transform the input signal.

[0079] This example takes advantage of the fact that ports can be used as transition blocks between simulation and production code. Fig. 4A The input variable modelled as InputPort is used in the modelling according to the invention in Fig. 4B as the boundary between the simulation code blocks 440, 450, 460 and the production code blocks 410, 420, 430.

[0080] Aus the in Fig. 4B The model shown is calculated using the procedure according to Fig. 2 the following source code is generated: Int16 volatile * pInputVariable = (Int16 volatile *) 0x1111; #ifdef SIMULATION / * Calculation of the subsystem: Subsystem_Fkt_1 * / *pInputVariable =<Subsystem_Fkt_1> (In1_1); #endif AusPort_Var = Calculation_1(*pInputVariable); #ifdef SIMULATION / * Calculation of the subsystem: Subsystem_Fct_2 * / *pInputVariable =<Subsystem_Fkt_2> (In1_1); #endif AusPort1_Var = Calculation_2(*pInputVariable); #ifdef SIMULATION / * Calculation of the subsystem: Subsystem2_Fct_3 * / *pInputVariable =<Subsystem _Fkt_3> (In1_1); #endif AusPort2_Var = Calculation_3(*pInputVariable);

[0081] The above source code contains both simulation code and production code. The simulation code is separated from the production code trennbar marked or excluded using the preprocessor instructions (#ifdef,#endif).

[0082] In contrast to the source code, which is derived from the model in Fig. 4A The above code allows the value of the input variable to be changed during a single simulation step. The new value is calculated using blocks 440, 450, 460, and 461. In the generated code file, the code for these blocks is expressed as simulation code.

[0083] An alternative modeling of the embodiment from Fig. 4B will be in Fig. 4C Instead of a single port block at the top level (In1_1), as in Fig. 4B , a constant block 400 can also be used. Instead of the constant block, a "Data Store Read" block could also be used (and a corresponding "Data Store Memory" block defined). This means that the input for the subsystems Subsystem_Fkt_1 to Subsystem_Fkt_3 does not necessarily have to be routed to the root subsystem, as in the case of the modeling approach from Fig. 4B Instead, the stored value can be changed through signal injection, which the user performs in a separate part of the model. For example, code generation can be performed only for a TargetLink subsystem, while the signal change is modeled externally.

[0084] It is also possible to specify the different values of the input variable directly, as in the alternative embodiment of the Fig. 4D shown. Three values for the input variable are specified directly as constants 1, 2, and 3 via three simulation blocks 440, 450, and 460, respectively, and the corresponding subsystem blocks 461.

[0085] From the model in Fig. 4D The following source code is generated using the method according to the invention: Int16 volatile * pInputVariable = (Int16 volatile *) 0x1111; #ifdef SIMULATION / * Define the output variable of the block Constant * / Int16 Constant_1_Var = 3; Int16 Constant_2_Var = 2; Int16 Constant_3_Var = 1; #endif ... #ifdef SIMULATION / * Calculation of the subsystem: Subsystem_Fct_1 * / *pInputVariable = Constant_1_Var; #endif OutPort_Var = Calculation_1(*pInputVariable); #ifdef SIMULATION / * Calculation of the subsystem: Subsystem_Fct_2 * / *pInputVariable = Constant_2_Var; #endif OutPort1_Var = Calculation_2(*pInputVariable); #ifdef SIMULATION / * Calculation of the subsystem: Subsystem2_Fkt_3 * / *pEingabeVariable = Konstante_3_Var; #endif AusPort2_Var = Berechnung_3(*pEingabeVariable);

[0086] For each new simulation step, the new value of Constant_1_Var to Constant_3_Var can be set via a signal injection mechanism. This writing can be done in a similar way as described for reading below with reference to the Figur 5 shown embodiment is explained.

[0087] Fig. 5 shows the initial situation of an embodiment according to the invention for tunneling, which can also be used for signal injection.

[0088] The data store write block 500 is marked as a simulation block and the simulation variable generated for the data store write block is declared as a global variable.

[0089] This is illustrated by the following source code, which was generated by the method according to the invention Fig. 2 from the model Fig. 5 is generated. #ifdef SIMULATION <datatype>DataMemoryWriteVariable; #endif Void foo(void) { <datatype>ToTunnelVariable ... / * Calculate the value of the local production code variable ToTunnelVariable * / ToTunnelVariable = .... #ifdef SIMULATION DataMemoryWriteVariable = ToTunnelVariable; #endif}

[0090] The above source code contains both simulation and production code. The simulation code contains a global simulation variable, DataMemoryWriteVariable, whose value is determined by a value of a local variable, VariableToTunnel, calculated in the production code.

[0091] With the approach of attributing certain blocks as simulation code blocks according to the invention, local variables can be read or written.

[0092] A further embodiment of the invention is described in the Figuren 6A and 6B In this embodiment, several calls of a software component, in particular a driver, are integrated into the model by means of simulation blocks, as shown by blocks 600 in Fig. 6A The POS signal 601 can be configured as a vector, whose various elements each provide the value for a driver call. The driver implementation is emulated by simulation code.

[0093] Fig. 6B shows the subsystem 600 for the driver call, comprising a simulation code section 610 and a production code section 620. This subsystem 600 can then be implemented as a selection of the corresponding section to describe the variable LinPos 611 with different values, namely a value 611-1 for production code and a value 611-2 for simulation code. The variable LinPos is thus modeled as an outport with two identities, i.e., for use in the production code 611-1 and for use in the simulation code 611-2.

[0094] To better separate the code components, the simulation code is conveniently "pushed out" of the production code subsystem. This allows the simulation code to be outsourced to separate code modules, and a production code module does not contain any simulation code components.

[0095] For example, the simulation code module for the driver call contains the following code section, which is taken from the simulation code section 610 in Fig. 6B is generated. / ************************** / / * Module IOLies.c - Simulation code * / / **************************************** / Int16 Position[2]; UInt16 current _Idx = 0; Void IO_LiesPosition(Int16 * LinPos) { *LinPos = Position[current_Idx]; current _Idx += 1;

[0096] For example, the production code module for the driver call contains the following code section, which is taken from the production code section 620 in Fig. 6B is generated. **************************************** / * Module IOLies.c - production code * / **************************************** CAL UInt16 Channel = 3; void IOLiesPosition(Int16 * LinPos) { *LinPos = ReadValueOfHardware(Channel);}

[0097] Additional submodules, such as an initialization module and a module for the individual function calls, can also be generated. Initialization - Stub module 1: Pos[0] = 1; Pos[1] = 2; ... Pos[n] = 123; Stub function - Stub module 2: IOLiesPosition(&LinPos, IO_Kanal_3) { static LiesIdx = 0; LinPos = Pos[LiesIdx]; LiesIdx += 1;}

[0098] Production code with call to the I / O driver: ... #include IOLies.h void myProdCode () { ... / * first call I / O driver * / IOLiesPosition(&LinPos, IO_Channel _3); / * start calculation - calculateSomething1 * / ... / * second call I / O driver * / IOLiesPosition(&LinPos, IO_CHANNEL _3); / * continue calculation - calculateSomething2 * / ...};

[0099] The initialization module is part of the simulation code and is used to initialize parameters and / or variables of the emulated component (for example, the driver 600 in Fig. 6B ). The function module contains stub functions of the emulated component, with function calls to one or more stub functions occurring in the production code.

[0100] To be able to describe multiple calls of the I / O driver, the input port 601 in Fig. 6A multiple values are assigned. In one embodiment, the input is connected to an array containing various variables or values as direct input variables, which are switched between depending on the number of previous calls.

[0101] Preferably, the initialization module can comprise an index-based data structure, in particular an array, that defines a plurality of values of a variable. With each function call of a stub function in the production code, individual values of the variable are accessed via the index. For example, in the above source code, the initialization module stub module 1 contains an array Pos of length n, where the individual fields are assigned values from 1 to 123.

[0102] Alternatively, it may also be intended to explicitly model conditions for switching in the simulation blocks.

[0103] Additional modules, such as an initialization module for error cases, can also be specified to emulate a component's malfunction.

[0104] In addition, changing values of the Lin.Pos variable can also be modeled outside the production code subsystem using Simulink blocks.

[0105] By exchanging the included header files (or by linking to the corresponding library), you can switch between simulation code for the test and the driver to be called in the control unit.< / datatype> < / datatype> < / n>

Claims

1. A method for generating source code from a model, the model comprising one or more blocks (111; 112; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 500; 600) specifying a desired behavior of a control program, defined in that at least one of the blocks comprises a simulation code attribute, wherein the method comprises the following steps: - generating (S10) simulation code for all blocks comprising a simulation code attribute; - generating (S20) production code for all blocks not comprising a simulation code attribute; - performing (S30) a software-in-the-loop simulation taking into account the simulation code for testing the production code; discarding (S40) the simulation code and compiling the production code for execution on a processor (140) of a controller; wherein the simulation code and the production code are generated within a single run of the code generator and are contained separably from each other in the source code.

2. The method according to claim 1, characterized in that the simulation code is integrated into the source code by means of preprocessor instructions.

3. The method according to claim 1 or 2, characterized in that the simulation code is stored separately from the production code in a code module or a code file.

4. The method according to any one of claims 1 to 3, characterized in that a block comprising a simulation code attribute comprises at least one further attribute which is taken into account during the generation of simulation code.

5. The method according to claim 4, characterized in that the step (S20) of generating simulation code comprises a code optimization step taking into account the at least one further attribute.

6. The method according to any one of claims 1 to 5, characterized in that the step (S20) of generating simulation code comprises generating a stub function, wherein the stub function emulates a component interacting with the program by means of the corresponding simulation code.

7. The method according to any one of claims 1 to 6, characterized in that the step (S20) of generating simulation code comprises generating function calls for transforming an input signal.

8. The method according to claim 7, characterized in that the simulation code replaces the function calls for assigning a value to a local variable occurring in the production code.

9. The method according to any one of claims 1 to 8, characterized in that the simulation code contains a global simulation variable having a value determined by a value of a local variable calculated in the production code.

10. The method according to any one of claims 1 to 9, characterized in that the production code contains a local variable having a value determined by a value of a global variable calculated in the simulation code.

11. The method according to any one of claims 1 to 10, characterized in that the simulation code contains an initialization module, for initializing parameters and / or variables of the emulated component, and a function module for receiving functions, in particular stub functions, of the emulated component, wherein function calls are made in the production code.

12. The method according to any one of claims 1 to 11, characterized in that said method further comprises the steps: - checking, starting from a first block comprising a simulation code attribute, whether all consecutive blocks along a simulation line extending from the first block to a block marked as a transition block comprise simulation code attributes; and - generating an error message if the simulation code attribute of a block is not set.

13. A test environment (100) for testing models for control programs, wherein a model comprises one or more blocks (111; 112; 310; 320; 330; 340; 350; 360; 370; 380; 390; 400; 410; 420; 430; 440; 450; 460; 500; 600) for specifying a desired behavior of a control program, defined in that at least one of the blocks comprises a simulation code attribute, wherein the test environment comprises a code generator (120) for generating source code from the model, wherein the code generator (120) is configured to generate simulation code for all blocks comprising a simulation code attribute and to generate production code for blocks not comprising a simulation code attribute, wherein the simulation code and the production code are generated within a single run of the code generator and are contained separably from each other in the source code, wherein the test environment further comprises a simulator (130), wherein the simulator (130) is configured to perform a software-in-the-loop simulation for testing the production code taking into account the blocks comprising a simulation code attribute, wherein thereafter the simulation code is discarded and the production code is compiled for execution on a processor of a controller.