EP3568757A1 - Verfahren zur erzeugung von quellcode - Google Patents

Verfahren zur erzeugung von quellcode

Info

Publication number
EP3568757A1
EP3568757A1 EP18737311.3A EP18737311A EP3568757A1 EP 3568757 A1 EP3568757 A1 EP 3568757A1 EP 18737311 A EP18737311 A EP 18737311A EP 3568757 A1 EP3568757 A1 EP 3568757A1
Authority
EP
European Patent Office
Prior art keywords
block
blocks
variable
region
variables
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP18737311.3A
Other languages
English (en)
French (fr)
Other versions
EP3568757B1 (de
Inventor
Michael Mair
Wolfgang Trautmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dspace GmbH
Original Assignee
Dspace GmbH
Dspace Digital Signal Processing and Control Engineering GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dspace GmbH, Dspace Digital Signal Processing and Control Engineering GmbH filed Critical Dspace GmbH
Publication of EP3568757A1 publication Critical patent/EP3568757A1/de
Application granted granted Critical
Publication of EP3568757B1 publication Critical patent/EP3568757B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment

Definitions

  • the invention relates to the generation of executable code from a block diagram, in particular for the programming of control devices.
  • Controllers are used in a variety of applications to detect and / or by means of physical quantities of a process
  • control devices to act on a process; For example, it may be a Antibiockierregeiung a braking operation.
  • the time constants determining the dynamic behavior of the process often require cycle times of 1 ms or shorter, so that a real-time capability of the control unit is required.
  • control devices often have microcontrollers with low memory and limited computing power, which is why the size and efficiency of the executable code is of great importance.
  • control strategies are often based on models in a computing environment such as
  • models may be block diagrams that include blocks that perform operations such as calculations, where a block may compute an output signal from, for example, multiple input signals.
  • block diagrams are executed cyclically, with all blocks held permanently in memory and each block executed once per time step.
  • a block may apply one or more operations to input signals from the last step to generate output signals of the current step. From the models can by means of a code generator directly source code for the
  • variable in several blocks can lead to unwanted side effects, in particular by a change in the data flow in the source code.
  • Block diagram comprises a model of a dynamic system with at least one signal connection between two blocks and can be executed to simulate the dynamic system.
  • the block diagram is defines at least one region in which one or more blocks reside, the block diagram comprising a first block and a second block, the first block having a first block variable and the second block having a second block variable, each block variable of the block diagram having an identifier, wherein the identifier of the first block variable is compared to the identifier of the second block variable, checking to see if the first block and the second block are in the same region, and wherein the first block variable and the second block variable are implemented in the source code as a single variable if the identifiers
  • Data or signals can be transmitted via a signal connection;
  • a first block outputs a value or, depending on the definition, a plurality of associated values, and a second block receives them and takes them into account in the determination of one or more associated output values of the second block.
  • Signals can be scalar
  • Contain variables and / or structured data types such as arrays, as is the case for example with a bus.
  • Block variables can be defined explicitly in the block or generated automatically, for example by means of a signal connection.
  • the identifiers or names of block variables can be predefined or defined on the basis of generation rules or generation rules with or without predetermined evasion behavior.
  • the identifier may include the name of the port in the block from which the signal originates.
  • block diagrams are hierarchically defined, wherein a higher-level block may comprise a plurality of lower-level blocks, with lower-level blocks associated with a higher-level block. Conveniently, therefore, each block belongs to one
  • Blocks can be defined by associated blocks in subordinate levels or can be simple blocks without substructures.
  • a hierarchical structure of the block diagram improves the overview.
  • the block diagram includes one or more
  • Definition blocks wherein a region is defined on the basis of a definition block such that the block comprising the definition block of the
  • next highest level and all blocks associated with this comprehensive block lie in the region.
  • the comprehensive block of the next higher level can be designed in particular as a subsystem.
  • blocks that are not in a region spanned by a definition block are assigned to an additional region such that each block of the
  • Block diagram is located in a region. Alternatively, it may also be provided that only those blocks which are in one of a definition block
  • Definition blocks can be dedicated only to the definition of a region. However, it may also be provided to assign the property of a definition block to certain semantic blocks at the same time. In particular these may be function blocks, which thus indicate that the surrounding subsystem is to be implemented in the source code as a function and preferably define further properties of the function. Since a function forms a unit in the source text, it is expedient, for example for reasons of clarity, to limit the grouping of variables to this unit.
  • a runnable block for defining a runnable as a stand-alone subunit of the software component can also be assigned the property of a definition block.
  • the block diagram comprises at least two definition blocks comprised of a common higher level block, wherein a first definition block is located in a first level and a second definition block is located in a second level subordinate to the first level, the first block comprising a first level defines the first region and wherein the second block defines a second region such that the block comprising the second definition block is the level higher than the second level and all blocks associated with that block are in the second region.
  • the second level can be arranged a plurality of hierarchy levels below the first level. This allows a more targeted control over which regions variables can be grouped together.
  • first definition block there may be at least two types of definition blocks, wherein one type of excellent definition blocks is defined, and in the case that the first definition block is an excellent definition block, the first region and the second region are combined into a common region, and otherwise first region and the second region are treated as separate regions.
  • a functional block or a runnable block may be considered an excellent one
  • Definition block are defined. By splintering the clearly circumscribed uniformity of a function or a runnable is prevented, the optimizability of the block diagram is maintained.
  • the identifier of a block variable prefferably be determined on the basis of an evaluation of at least one generation rule, the generation rule including the identifier of the block variable based on the block of a higher level in which the block comprising the block variable and / or on the basis of the region, in which the block variable block is located determined. It is advantageous if the
  • the identifier may be at least partially given in the form of a name macro such as $ (Scope) _ $ B.
  • the generation rule or the name macro is evaluated at the time of code generation, where $ (scope) is replaced by the name of the region, in particular a comprehensive subsystem, and $ B by the name of the block. In principle, more can
  • Name macros or wildcards defined and included in the name of one or more identifiers can also be provided that a fallback rule is assigned to a name macro in each case in order to enable automatic resolution in the case of name collisions.
  • escape rules can be assigned to a block or region.
  • the identifier can expediently also have a fixed name component. If two block variables have the same name based on the name macros, or if a name collision occurs, different ones can be used
  • Dodge rules are applied. For example, it may be provided to supplement the name obtained by evaluating the name macro with a counting component (such as "VarName_a”, “VarName_b”,
  • Name equality occurs.
  • the name of a region which initially only contains local information on the basis of the name macro, in order to expand context information, For example, prepend a file name or the name of one or more hierarchically superior blocks, such as comprehensive subsystems, to the name of the region.
  • the user specifies a possible name component, which in the event of a name collision additionally or instead of one in the
  • Name macro defined name component is inserted.
  • Dodge rule can check additional constraints, and especially in case of exceeding a given maximum length also include a reduction rule.
  • a reduction rule For example, in the case of hierarchically composed names, which contain several consecutive regions, the associated one can be provided
  • Block diagram may be present. Conveniently, in the event that there are multiple instances of a block in the block diagram, either an independent region is defined for each instance, or a common function for the instances and a common function for each instance
  • the complete content of the library block or the referenced model is not copied, but an instance-independent function of the block is combined with an instance-specific data structure.
  • This makes it possible to keep the generated source code very compact.
  • it is appropriate to store the data in a structure, which is referenced by a pointer. This allows an arbitrary frequent use of the instructions, with only the data must be multiple times in memory. Thus, the usually limited memory of a controller is less busy.
  • the complete content of the library block or the referenced model is not copied, but an instance-independent function of the block is combined with an instance-specific data structure.
  • This makes it possible to keep the generated source code very compact.
  • it is appropriate to store the data in a structure, which is referenced by a pointer. This allows an arbitrary frequent use of the instructions, with only the data must be multiple times in memory. Thus, the usually limited memory of a controller is less busy.
  • the complete content of the library block or the referenced model is not copied, but an instance-independent function of the block is combined
  • each block variable has an allowance flag which may be set or not set, and two block variables are implemented in a common variable only if both
  • the allowability flag can be set indirectly for one or more variables, for example, by referring back to a definition data collection, in particular by assigning a variable class or a variable
  • Variable type that defines one or more properties common to different variables.
  • the setting of a mark of admissibility allows a direct influence on the optimization by the user.
  • Admissibility marking may be unconditional or may allow optimization only in conjunction with the fulfillment of an additional condition.
  • each block variable or the blocks can also be assigned an unconditional additional marking as well as one or more check marks. More preferably, each block variable has at least one check mark which may be set or not set, and two block variables are implemented in a common variable only if the check mark is set in both block variables and additionally
  • test condition associated with the checkmark At least one test condition associated with the checkmark is met. Thus, it can be automatically ensured that the optimization in the present model produces meaningful results. It is expedient to check one or more of the following test conditions:
  • variable definition is assigned.
  • a variable definition can be
  • the specification of a basic data type, the minimum and / or maximum value and / or a scaling include. ⁇ Whether the block variables are located at a same specified directed connection.
  • a directed connection between two blocks expediently indicates the exchange of signals; Signals may have a scalar data type or be composed of several scalar data types, such as a bus. The signal is transmitted from an output block to one or more destination blocks.
  • Block variables fulfill the condition, in particular if one is defined in the starting block and the other in a target block.
  • Test condition is assigned, or a check mark several
  • Test conditions are assigned, wherein a summarization of variables only takes place if all the test mark associated conditions. There may also be more than one check mark, with each check mark then having one or more test conditions
  • one or more parameters can be assigned to a block variable, whereby two block variables only in a common Variable to be implemented if one or more of the following
  • the names of block variables are determined by means of generation rules, whereby only those block variables whose names have been determined with the same generation rule are combined.
  • At least one block variable is automatically generated based on directed links between blocks, and in the case where a first block is connected to a second block and the second block is connected to a third block, a block variable of the first block for those outgoing from the first block Connection is generated and a block variable of the second block for the connection originating from the second block is generated, the two block variables then being used as a common block
  • Variables are implemented in the source code if the first block and the second block are in the same region.
  • Block variables of blocks that are in the separation region are always implemented as separate variables in the source code.
  • the outermost region may be predefined as a separation region, with definition blocks in subordinate hierarchical levels then defining individual regions in which block variables may be grouped together.
  • the invention further relates to a method for configuring a
  • control unit wherein the control unit comprises at least one arithmetic unit and preferably has at least one sensor and / or at least one actuator to detect data of a physical process and / or act on this, the method comprising the steps
  • the invention relates to a computer program product having a computer-readable storage medium embedded with instructions which, when executed by a processor, cause the computer to perform the
  • Processor is adapted to a method according to one of
  • the invention relates to a computer system comprising a man-machine interface, a nonvolatile memory and a processor, wherein the processor is adapted to carry out a method according to the invention.
  • Figure 2 is a schematic representation of preferably on a
  • Figure 3 is a general scheme of generating source code
  • Figure 4 is a schematic representation of the review of
  • Figure 5 is a schematic representation of an exemplary
  • Figure 6 is a schematic flow diagram of a preferred embodiment
  • Figure 7 is a detailed embodiment of a block diagram.
  • FIG. 1 shows a preferred embodiment of a computer system PC.
  • This has a processor CPU, which can be implemented in particular as a multi-core processor, a main memory RAM and a bus controller BC.
  • the computer system PC is preferably designed to be operated manually by a user directly, with a GPU via a graphics card
  • the computer system further includes a non-volatile one
  • Data storage HDD which may be designed in particular as a hard disk and / or solid state disk, and an interface NET, in particular a network interface. Via the interface NET, a control unit ES can be connected. In principle, one or more arbitrary
  • Interfaces in particular wired interfaces, on the
  • the Interface NET can also be designed wirelessly, in particular as a WLAN interface or according to a standard such as Bluetooth.
  • the control unit ES can be designed as a production control unit or as an evaluation board for a target platform. Conveniently, it comprises an interface NET for connection to the computer system PC, a microcontroller MCR with an architecture deviating from the processor of the computer system, a random access memory RAM and a nonvolatile memory NVM.
  • FIG. 2 shows a schematic of the software components preferably installed on the computer system PC. These use mechanisms of the operating system OS, for example to access the non-volatile memory HDD or to establish a connection to an external computer via the network interface NET.
  • a technical computing environment TCE allows the creation of models and the generation of source code from the models.
  • models of a dynamic system can preferably be created via a graphical user interface.
  • These may in particular be block diagrams which comprise a plurality of blocks and describe the temporal behavior and / or internal states of a dynamic system. At least some of the blocks are connected via signals, that is, directed connections for exchanging data which may be scalar or compound.
  • Blocks can be atomic, providing a predefined functionality in one step. When block diagrams are hierarchical, a plurality of blocks at a subordinate level can describe the structure of a block at a higher level. Conveniently, atomic blocks may then also comprise a plurality of blocks at a subordinate level.
  • compound blocks can be subsystems
  • Subsystems may have additional properties, such as Implementation in a separate function and / or triggering of the execution of the subsystem via a dedicated signal.
  • special blocks may be arranged to match the properties of the
  • the computing environment TCE comprises one or more libraries BIB, from which blocks or building blocks for the construction of a model can be selected.
  • libraries BIB from which blocks or building blocks for the construction of a model can be selected.
  • statements can be entered interactively or through a batch file to perform calculations or to modify the model.
  • the computing environment TCE further includes a simulation environment SIM that is adapted to interpret the block diagram to examine the temporal behavior of the system. These calculations are preferably done with high precision floating point numbers on one or more cores of the computer system microprocessor CPU.
  • a source code can preferably be generated in a programming language such as C using a code generator PCG.
  • a definition data collection DDT expediently contains additional information about the model, in particular about the block variables.
  • value ranges and / or scalings are assigned to the block variables to aid in calculating the model with fixed-point instructions. Also desired properties of
  • Source codes for example conformity to a standard such as MISRA, can be set or stored in the DDT definition data collection.
  • each block variable is assigned to a given variable type and one or more desired properties, such as the permissibility of optimizations such as summarizing variables, are set.
  • the code generator PCG preferably evaluates the settings of the definition data collection DDT and takes these into account when generating the source code.
  • the definition data collection DDT can have a tree structure or as a simple file in one
  • the definition data collection may include a program interface and / or import / export functions.
  • the computer system PC has a compiler COM and a linker LIN, which are expediently set up for the generation of binary files executable on a control device ES and / or the computer system PC.
  • a large number of compilers can be present
  • Figure 3 shows a general scheme of generating source code by means of a code generator.
  • the method may be performed entirely by a processor of a preferred embodiment of the computer system PC; However, it can also be provided for execution in a client-server environment with an operating computer and one or more servers connected via a network, wherein in particular computer-intensive steps are performed on the servers.
  • a transformation the selected model is transformed from one or more blocks of the block diagram BLD into an intermediate representation IR, preferably one or more
  • Hierarchical graphs This can in particular be a data flow graph, a control flow graph or a tree structure.
  • additional information from a definition data collection DDT is expediently taken into account or incorporated into the generation of the intermediate representation. This can also include situations in which elements are generated based on information in the definition data collection DDT or properties of elements or settings relevant for code generation, such as
  • a second step S2 an optimization, the hierarchical graphs are optimized to the number of required variables and / or a
  • Memory consumption such as a stack occupancy, and / or the number of operations or processor instructions and / or the
  • This optimization can include a multitude of intermediate steps, in which further intermediate representations between model / block diagram and source code / program text are generated.
  • it may be provided to convert a set of original hierarchical graphs into a different set of changed hierarchical graphs in each intermediate step, using one or more optimization rules.
  • step Sl Apply transformation of step Sl, especially if they can be performed on a block diagram representation easier.
  • step S2 it is in principle possible for several variables generated in step S1 to be combined in step S2, and for several variables of the block diagram to be combined in step S1 in such a way that the first intermediate representation already contains only one variable.
  • warnings that are stored in the definition data collection can be used, for example, to influence a compilation of the generated source code or to provide meta-information for other tools, such as calibration information in the ASAP2 format or information for
  • Alternate embodiments of the invention may be provided to generate from the block diagram code in a hardware description language or a configuration of a programmable hardware device.
  • Figure 4 shows a schematic representation of the verification of the generated source code based on the block diagram.
  • a block diagram BLD or a subsystem consisting of three blocks is shown schematically, which has an input port for receiving an input signal and an output port for transmitting an output signal.
  • the block diagram can
  • the block diagram expediently describe a predetermined or desired behavior of a control program. If the block diagram is executed in the simulation environment not shown here, the behavior for successive time steps is calculated; In particular, the block diagram BLD can be interpreted directly here. From the specification or the intended application, a number of test cases were determined in advance, in particular stimuli STIM as input signals for the control program comprise, wherein the stimuli associated with a corresponding output signal RESP.
  • a stimulus STIM is shown in the example shown as a diagram which indicates a specific temporal behavior of the input signal.
  • a current value of the stimulus STIM is applied to the input port of the block diagram BLD for a plurality of time steps, and the operations corresponding to the blocks are calculated to be an internal state and / or to determine an output signal of the control program.
  • a target response RESPl can be determined in a model-in-the-loop simulation. Since all arithmetic operations are calculated with high accuracy, for example by having variables always of the double data type and thus floating point calculations, the correct behavior of the model can be verified on the one hand and on the other hand this can be
  • Simulation result sufficiently accurate to use the stored output signal or the target response RESPL as reference data.
  • Code generator PCG source code from blocks of the block diagram corresponding to the control program.
  • the generated source code is then compiled with a compiler COM to object code OBJ, which expediently contains instructions for the processor of the target system.
  • object code is transferred from a linker to an executable file in the
  • settings may be a conversion of the model operations in fixed-point representation, which also include a corresponding scaling, or in general transformations are used to reduce the computational effort to enable real-time execution even on lower performing hardware such as a microcontroller of an embedded system ES.
  • a software-in-the-loop simulation in which the target system corresponds to the computer system PC, or a
  • the executable file with the object code OBJ is supplied with the stimulus STIM during the predetermined execution duration and the output signal of the generated source code resulting from the calculations is recorded in order to obtain the actual response RESP2.
  • the set response RESPl of the model-in-the-loop simulation can be found on the
  • Computer system are presented simultaneously to the actual response RESP2 of the generated code to allow the user a visual comparison.
  • a comparison of setpoint response RESP1 and actual response RESP2 can also be calculated in a comparison program CMP. This allows, for example, the determination of a deviation measure and / or the checking of one or more test conditions, for example the calculation of a pointwise difference between the actual response and the setpoint response and the comparison with a threshold value or a maximum permissible deviation.
  • FIG. 5 is a schematic illustration of an exemplary embodiment
  • Block diagrams are shown with multiple hierarchical levels, with blocks of a hierarchical level are represented in a rectangular border.
  • the blocks BI, B2, B3 and B5 may be atomic or simple or not having shown substructure.
  • Block B4 is a composite block whose functionality is defined by blocks in a second (subordinate) hierarchical level E2.
  • the shown section of a second hierarchical level E2 comprises a
  • Plurality of blocks B2j, j 1..4, a definition block D2 and two ports for exchanging signals with the higher-level hierarchy, an input port P21 and an output port P22.
  • the blocks B21, B22 and B24 may be atomic or one or not
  • Block B23 is a composite block whose functionality is represented by blocks in a third (lowest)
  • Hierarchy level is defined.
  • the blocks B31, B32, B33 and B34 may be atomic or have a substructure, not shown. In principle, block diagrams may have any number of hierarchy levels; For better clarity, no further hierarchy levels have been displayed here.
  • different blocks can be used as definition blocks; Conveniently, composite blocks, which may be called from other model parts and comprise a contiguous functionality or code unit, should form a self-contained region. These may preferably be functions, in particular at the top level of the block diagram.
  • a runnable may conveniently be a standalone region.
  • the block comprising the region, or preferably a block arranged in the region can serve as a definition block. It can be provided that dedicated blocks are used to define a region, For example, a scope block is predefined. According to one
  • blocks which specify the properties of the function or of the runnable are simultaneously defined as a definition block.
  • a defined region comprises all hierarchically subordinate blocks.
  • definition block Dl defines a first region
  • port blocks it may also be preferred that they are part of the encompassing region.
  • Definition block and normal definition blocks is distinguished.
  • D2 were an excellent definition block
  • normal definition blocks only define a region if there is no excellent definition block in a higher level.
  • normal definition blocks define a new region from a standard definition block
  • the first region defined by Dl may comprise the blocks BI, B2, B3, B5, while block B4 may form the second region defined by definition block D2 Region then comprises blocks B21, B22 and B24, while block B23 forms the third region defined by definition block D3.
  • D2 should be a regular definition block, which defines in particular a subfunction
  • D3 should be a regular
  • Definition block in particular define a library block without defining its own function.
  • the region spanned by a definition block will be denoted by the same name as the definition block.
  • block variables of B2, B3, B21, B24, B31 and B33 are each assigned the generation specification or the name macro "$ (Scope) _X"
  • code generation for blocks B2, B3 results in variables with the identifier "D1_X” , for blocks B21, B24 variables with the identifier "D2_X” and for blocks B31, B33 variables with the identifier "D3_X”.
  • the variables of block B2 may be combined with those of block B3. It may also be envisaged that a production rule distinguishes between award-winning regions or excellent definition blocks and regular regions or definition blocks. Is that
  • Block variables of the blocks Bl, B22 and B32 respectively assigned to the generation rule or the name macro "$ (Scope: ParentFunction) _Y", so taking into account the surrounding function, so obtained in a
  • a generation rule may only have references to a region comprising the associated block. This further increases the reliability of the generated programs.
  • FIG. 6 is a schematic flow chart of a preferred one
  • Embodiment of the inventive method shown in which case only the procedure for a first and a second block variable is shown.
  • a list of the block variables present in the block diagram is first of all created, whereby all block variables are checked consecutively. Preferably, all possible pairs of block variables are checked.
  • Block variables selected so in step 101, a first block variable and in step 102, a second block variable.
  • step 103 it is checked whether the first and second block variables have the same identifier. This can be the evaluation of
  • step 109 Production rules. If the block variables have different identifiers, a transition is made to step 109.
  • step 104 If the block variables are identically named, it is checked in step 104 whether an allowance flag is set in both variables. If the marker is only set in one of the block variables, it is expedient to create a separate variable in the source code for the block variable without an admissibility marking, and instead select a new block variable for the comparison. Unless one or both block variables
  • step 108 If there is a validity mark, a transition is made to step 108. It is then checked in step 105 whether the block variables are arranged in the same region and thus there is a sufficient local reference. If this is not the case, a transition to step 108 takes place.
  • step 106 it is checked whether the block variables fulfill an additional condition. For example, it may be necessary for the first and second block variables in the definition data collection to have one or more
  • step 108 If the additional condition is not met, a transition to step 108 occurs.
  • the first and the second block variables are combined in step 107 into a variable in the source code, ie a variable is generated. If the two block variables have the same identifier, but at least one of the other conditions is not satisfied, it is checked in step 108 whether it is possible to avoid it, ie for one of the block variables in the program code a differently named variable can be generated. It is advantageous if in a production rule also a possible
  • Rename or an alternative rule is defined. If, in the specific case, no evasion is possible, an error message is output to the user in step 110. In addition, it can optionally be provided to cancel the code generation, so that first necessary adjustments to the model are made.
  • step 108 one or (in step 109) two variables in
  • Source code were generated, the method is advantageously carried out with the other block variables to be checked.
  • the order of the conditions checked can be changed, and it can also be provided to check several conditions in one step, if, for example, the identifiers of the block variables also contain information about the region.
  • the optimization takes place in several steps, that is to say initially a multiplicity of variables are created in the source text and these are then combined on the basis of a comparison of the associated block variables.
  • Figure 7 shows a detailed embodiment of a block diagram which provides the functionality of a reset-enabled buffer. This serves, in particular, to implement a block with the corresponding functionality in a higher-level model, not shown, wherein the block diagram can be referenced one or more times, that is, if necessary, represents a complex library block.
  • the two blocks are DetermineValue and StoreOverwrite atomic subsystems, which are implemented in a subordinate hierarchical level, but are executed in one computing step.
  • the respective implementation in the block itself is shown here, wherein the connection between the signal connected to the respective block and the arrow is shown by dashed arrows
  • a definition block DR1 is arranged which defines a region R1 comprising all blocks shown.
  • the block diagram shown has the input port In, which receives a scalar signal, the input port ResetValue, which receives a vector signal with a width of 11, and the input port Reset, which receives a scalar or Boolean signal. It also has an output port Out which sends a scalar signal.
  • Two unconnected MemBuf and Memldx blocks define memory blocks (DataStoreMemory) that can be accessed through special read / write blocks.
  • the memory blocks can between several calls of the functionality implemented in the block diagram retain their value and thus represent states.
  • the memory block MemBuf is read with the block ReadBuf and described with the block WriteBuf. Accordingly, the memory block Memidx is read with the block Readldx and described with the block Writeldx.
  • An externally applied vector signal ResetValue is applied to the switch input of the block ResetBuf in the atomic subsystem Determine Value; this also receives the externally applied signal Reset and the current value of the memory block MemBuf. This is read out via the block ReadBuf and suitably converted by means of the block RBuf (Convert).
  • the block ResetBuf supplies either the actual value of the output signal as output signal depending on the applied changeover value
  • the scalar value can be extracted from the bus signal with the index Idx and output via the output port Out.
  • the entire vector signal is next passed to the output port CurBuf.
  • the value currently stored in the memory block Memidx is read out by means of the block Readldx, suitably converted by the block RIdxl (Convert) and then via the input port in_Idx to the atomic subsystem
  • the output port out_Idx is connected to a first input of the sum block Incrldx, the second input of which is supplied with the fixed value 1 via a constant block Constant.
  • the output of Incrldx is applied to one input of the block Normalize_Idx and to a first input of comparison block Rel.
  • the value NDelaySize is applied to the second input of the comparison block Rel via constant block Constantl, so that the comparison block Rel outputs the value 1 or 0 depending on whether the output signal of Incrldx is smaller than NDelaySize.
  • the output of Comparison block Rel is connected to a switching input of the block Normalizeldx.
  • a constant block Constant2 is the block
  • Normalizeldx to 0.
  • the output of the block Normalizeldx is connected to the block Writeldx for writing to the memory block Memldx and to the input port Idx of the atomic subsystem DetermineValue.
  • the output port is overwrite with an index input of the
  • a value input from ReplaceOverwrite receives via an input port into an externally applied scalar value. Furthermore, a vector input of the
  • Assignment block to which a vector signal is applied is with the block
  • allocation block ReplaceOverwrite can change the current value of the scalar sub-signal located at the position given by Overwrite on the bus.
  • Listing 1 can be generated from the block diagram shown in FIG. 7 (here in the language C).
  • Idx Idx + 1;
  • the block variables of the blocks MemBuf, ReadBuf, WriteBuf, RBuf and ResetBuf have been combined into an array variable BufBWR [] and the block variables of the blocks Memldx, Readldx, Writeldx, RIdxl and Incrldx into a scalar variable IdxBWR.
  • the instance-specific variables are defined in a structure that can be addressed via a pointer to allow convenient reuse of the function.
  • the method according to the invention enables particularly great optimization.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Programmable Controllers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Erzeugen von Quellcode aus einem oder mehreren Blöcken eines Blockdiagramms, welches ein Modell eines dynamischen Systems mit mindestens einer gerichteten Verbindung zwischen zwei Blöcken umfasst, wobei das Blockdiagramm ausgeführt werden kann, um das dynamische System zu simulieren, und wobei in dem Blockdiagramm mindestens eine Region definiert ist, in der ein oder mehrere Blöcke liegen. Das Blockdiagramm umfasst einen ersten Block und einen zweiten Block, wobei der erste Block eine erste Blockvariable und der zweite Block eine zweite Blockvariable aufweist, wobei jede Blockvariable des Blockdiagramms einen Bezeichner aufweist. Der Bezeichner der ersten Blockvariable wird mit dem Bezeichner der zweiten Blockvariable verglichen, und es wird überprüft, ob der erste Block und der zweite Block in der gleichen Region liegen. Die erste Blockvariable und die zweite Blockvariable werden im Quellcode als eine einzige Variable implementiert, wenn die Bezeichner übereinstimmen und die Blöcke in einer Region liegen. Sofern die Bezeichner verschieden sind und/oder die Blöcke nicht in der gleichen Region liegen, werden die erste Blockvariable und die zweite Blockvariable im Quellcode als zwei getrennte Variablen implementiert. Weiterhin betrifft die Erfindung ein Verfahren zum Konfigurieren eines Steuergeräts, ein Computerprogrammprodukt und ein Computersystem.

Description

Verfahren zur Erzeugung von Quellcode
Die Erfindung betrifft die Erzeugung von ausführbarem Code aus einem Blockdiagramm, insbesondere für die Programmierung von Steuergeräten.
Steuergeräte werden in einer Vielzahl von Anwendungen eingesetzt, um physikalische Größen eines Prozesses zu erfassen und/oder mittels
angeschlossener Aktuatoren auf einen Prozess einzuwirken; beispielsweise kann es sich um eine Antibiockierregeiung eines Bremsvorgangs handeln. Die das dynamische Verhalten des Prozesses bestimmenden Zeitkonstanten bedingen häufig Zykluszeiten von 1 ms oder kürzer, so dass eine Echtzeitfähigkeit des Steuergeräts erforderlich ist. Aus Kostengründen weisen Steuergeräte häufig MikroController mit geringem Speicher und beschränkter Rechenleistung auf, weshalb der Größe und Effizienz des ausführbaren Codes eine große Bedeutung zukommt.
Um den Entwurf von Steuergeräten zu beschleunigen, werden Kontrollstrategien häufig anhand von Modellen in einer Rechenumgebung wie
MATLAB/Simulink entwickelt. Somit können Prozess und/oder Regler bzw. allgemein das Verhalten des Steuergeräts zunächst simuliert und das
Vorliegen von gewünschten Eigenschaften überprüft werden. Bei den
Modellen kann es sich insbesondere um Blockdiagramme handeln, welche Blöcke umfassen, die Operationen wie Berechnungen ausführen, wobei ein Block beispielsweise aus mehreren Eingangssignalen ein Ausgangssignal berechnen kann. In der Regel werden Blockdiagramme zyklisch ausgeführt, wobei alle Blöcke dauerhaft im Speicher gehalten werden und jeder Block einmal pro Zeitschritt ausgeführt wird . Insbesondere kann ein Block auf Eingangssignale aus dem letzten Schritt eine oder mehrere Operationen anwenden, um Ausgangssignale des aktuellen Schritts zu erzeugen. Aus den Modellen kann mittels eines Codegenerators direkt Quellcode für die
Programmierung des Steuergeräts erzeugt werden. Beispielsweise ist aus dem Dokument„Production Quality Code Generation from Simulink Block Diagrams", Proceedings of the 1999 International Symposium on Computer Aided Control System Design, Kohala Coast, Hawai'i, von H. Hanselmann et al . ein Codegenerator für die Erzeugung von Quellcode in Produktionsqualität bekannt. Wenn Modelle in Form eines Blockdiagramms beschrieben werden, wobei Blöcke zum Austausch von Daten bzw. dem Weiterleiten von Signalen über gerichtete Verbindungen bzw. Signalverbindungen verknüpft sind, besteht ein übliches Vorgehen der Codeerzeugung darin, für jeden Ausgang eines Blocks eine Variable im Quellcode zu erzeugen. In der Regel entstehen dabei mehr Blockvariablen als wirklich erforderlich sind, so dass Raum für
Optimierungen besteht. Eine mögliche Optimierung besteht darin, die
Blockvariablen verschiedener Blöcke auf eine gemeinsame Variable im
Quellcode abzubilden. Allerdings ist dieses auch als„Mergen" bekannte Zusammenfassen von Blockvariablen nicht ungefährlich, denn die
Weiterverwendung einer Variablen in mehreren Blöcken kann insbesondere durch eine Veränderung des Datenflusses im Quellcode zu unerwünschten Seiteneffekten führen.
Vor diesem Hintergrund ist es eine Aufgabe der vorliegenden Erfindung, den Stand der Technik weiterzuentwickeln und insbesondere eine Erzeugung von kompakterem Quellcode unter Vermeidung von unerwünschten Seiteneffekten zu unterstützen.
Diese Aufgabe wird durch ein Verfahren zum Erzeugen von Quellcode nach Anspruch 1, ein Computerprogrammprodukt nach Anspruch 14 und ein
Computersystem nach Anspruch 15 gelöst. Vorteilhafte Weiterbildungen sind Gegenstand der abhängigen Unteransprüche.
Es wird also ein Verfahren zum Erzeugen von Quellcode aus einem oder mehreren Blöcken eines Blockdiagramms bereitgestellt, wobei das
Blockdiagramm ein Modell eines dynamischen Systems mit mindestens einer Signalverbindung zwischen zwei Blöcken umfasst und ausgeführt werden kann, um das dynamische System zu simulieren. In dem Blockdiagramm ist mindestens eine Region definiert, in der ein oder mehrere Blöcke liegen, wobei das Blockdiagramm einen ersten Block und einen zweiten Block umfasst, wobei der erste Block eine erste Blockvariable und der zweite Block eine zweite Blockvariable aufweist, wobei jede Blockvariable des Blockdiagramms einen Bezeichner aufweist, wobei der Bezeichner der ersten Blockvariable mit dem Bezeichner der zweiten Blockvariable verglichen wird, wobei überprüft wird, ob der erste Block und der zweite Block in der gleichen Region liegen, und wobei die erste Blockvariable und die zweite Blockvariable im Quellcode als eine einzige Variable implementiert werden, wenn die Bezeichner
übereinstimmen und die Blöcke in einer Region liegen, und wobei die erste Blockvariable und die zweite Blockvariable im Quellcode als zwei getrennte Variablen implementiert werden, wenn die Bezeichner verschieden sind und/oder die Blöcke nicht in der gleichen Region liegen. Über eine Signalverbindung können Daten bzw. Signale übertragen werden; hierbei gibt ein erster Block einen Wert oder je nach Definition mehrere zusammengehörige Werte aus und ein zweiter Block empfängt diese und berücksichtigt sie bei der Ermittlung von einem oder mehreren zusammengehörigen Ausgabewerten des zweiten Blocks. Signale können skalare
Variablen und/oder strukturierte Datentypen wie Arrays enthalten, wie dies beispielsweise bei einem Bus der Fall ist.
Blockvariablen können explizit im Block definiert sein oder automatisch erzeugt werden, beispielsweise anhand einer Signalverbindung . Die Bezeichner bzw. Namen von Blockvariablen können fest vorgegeben oder anhand von Erzeugungsvorschriften bzw. Erzeugungsregeln mit oder ohne vorgegebenem Ausweichverhalten definiert sein . Insbesondere kann bei Blockvariablen zu einem Ausgangssignal eines Blocks der Bezeichner den Namen des Ports in dem Block umfassen, von dem das Signal ausgeht. Somit können Bezeichner immer fest bleiben, oder im Falle eines Konflikts von mehreren übereinstimmenden Bezeichnern wird mindestens ein Bezeichner nach einer
vorgegebenen Regel modifiziert. Zweckmäßigerweise ist es vorgesehen, dass zwei Variablen, welche feste übereinstimmende Bezeichner haben, vorzugsweise dann zusammengefasst werden, wenn eine oder mehrere Zulässigkeitsbedingungen erfüllt sind .
Anhand der Definition von Regionen kann gesteuert werden, ob und in welcher Umgebung Blockvariablen zusammengefasst werden dürfen. Somit kann ein Zusammenfassen von Variablen in semantisch unkorrelierten Bereichen des Blockdiagramms ausgeschlossen werden. Dies vermeidet schwer zu findende Seiteneffekte durch erratische Veränderungen des Datenflusses. Bevorzugt sind Blockdiagramme hierarchisch definiert, wobei ein Block in einer höheren Ebene mehrere Blöcke einer untergeordneten Ebene umfassen kann, wobei Blöcke einer untergeordneten Ebene einem Block einer höheren Ebene zugeordnet sind . Zweckmäßigerweise gehört also jeder Block einer
untergeordneten Ebene zu einem Block einer höheren Ebene. Blöcke können mittels zugeordneter Blöcke in untergeordneten Ebenen definiert sein oder einfache Blöcke ohne Unterstruktur sein . Eine hierarchische Struktur des Blockdiagramms verbessert die Übersicht.
Besonders bevorzugt umfasst das Blockdiagramm einen oder mehrere
Definitionsblöcke, wobei eine Region anhand von einem Definitionsblock derart definiert ist, dass der den Definitionsblock umfassende Block der
nächsthöheren Ebene und alle diesem umfassenden Block zugeordneten Blöcke in der Region liegen. Der umfassende Block der nächsthöheren Ebene kann insbesondere als ein Subsystem ausgebildet sein. Vorzugsweise werden Blöcke, welche nicht in einer von einem Definitionsblock aufgespannten Region liegen, einer zusätzlichen Region zugeordnet, so dass jeder Block des
Blockdiagramms in einer Region liegt. Alternativ kann es auch vorgesehen sein, dass nur solche Blöcke, die in einer von einem Definitionsblock
definierten Region liegen, zusammengefasst werden dürfen.
Definitionsblöcke können dediziert nur für die Definition einer Region bestimmt sein. Es kann aber auch vorgesehen sein, bestimmten semantischen Blöcken gleichzeitig die Eigenschaft eines Definitionsblocks zuzuweisen. Insbesondere kann es sich dabei um Funktionsblöcke handeln, welche also anzeigen, dass das umgebende Subsystem im Quellcode als eine Funktion implementiert werden soll und vorzugsweise weitere Eigenschaften der Funktion definieren. Da eine Funktion im Quelltext eine Einheit bildet, ist es beispielsweise im Hinblick auf die Übersichtlichkeit zweckmäßig, ein Zusammenfassen von Variablen auf diese Einheit zu beschränken. Wenn das Blockdiagramm dazu eingesetzt wird, eine AUTOSAR-Softwarekomponente zu modellieren, kann insbesondere auch einem Runnable-Block zur Definition eines Runnables als eigenständiger Untereinheit der Softwarekomponente die Eigenschaft eines Definitionsblocks zugeordnet werden.
Ganz besonders bevorzugt umfasst das Blockdiagramm mindestens zwei Definitionsblöcke, welche von einem gemeinsamen Block einer höheren Ebene umfasst sind, wobei ein erster Definitionsblock in einer ersten Ebene und ein zweiter Definitionsblock in einer gegenüber der ersten Ebene untergeordneten zweite Ebene angeordnet ist, wobei der erste Block eine erste Region definiert und wobei der zweite Block eine zweite Region derart definiert, dass der den zweiten Definitionsblock umfassende Block der gegenüber der zweiten Ebene nächsthöheren Ebene sowie alle diesem Block zugeordneten Blöcke in der zweiten Region liegen. Prinzipiell kann die zweite Ebene mehrere Hierarchiestufen unterhalb der ersten Ebene angeordnet sein. Dies ermöglicht eine gezieltere Steuerung, in welchen Regionen Variablen zusammengefasst werden dürfen. Insbesondere kann es mindestens zwei Sorten von Definitionsblöcken geben, wobei eine Sorte ausgezeichneter Definitionsblöcke definiert ist, wobei in dem Fall, dass der erste Definitionsblock ein ausgezeichneter Definitionsblock ist, die erste Region und die zweite Region zu einer gemeinsamen Region zusammengefasst werden, und wobei ansonsten die erste Region und die zweite Region als getrennte Regionen behandelt werden. Beispielsweise kann ein Funktionsblock oder ein Runnable-Block als ein ausgezeichneter
Definitionsblock definiert werden. Indem ein Zersplittern der klar umgrenzten einheitlichen Region einer Funktion bzw. eines Runnables verhindert wird, bleibt die Optimierbarkeit des Blockdiagramms erhalten.
Es ist vorteilhaft, wenn der Bezeichner einer Blockvariable anhand einer Auswertung von mindestens einer Erzeugungsvorschrift bestimmt wird, wobei die Erzeugungsvorschrift den Bezeichner der Blockvariable anhand des Blocks einer höheren Ebene, in welchem der die Blockvariable aufweisende Block umfasst ist, und/oder anhand der Region, in welcher der die Blockvariable aufweisende Block liegt, bestimmt. Hierbei ist es vorteilhaft, wenn die
Überprüfung, ob zwei Blöcke in der gleichen Region liegen, anhand eines Vergleichs der Bezeichner der Blockvariablen erfolgt. Vorzugsweise kann der Bezeichner zumindest teilweise in Form eines Namensmakros wie $(Scope)_$B angegeben werden. Die Erzeugungsvorschrift bzw. das Namensmakro wird zum Zeitpunkt der Codeerzeugung ausgewertet, wobei $(Scope) durch den Name der Region, insbesondere eines umfassenden Subsystems, und $B durch den Namen des Blocks ersetzt werden. Prinzipiell können weitere
Namensmakros bzw. Platzhalter definiert und in dem Namen eines oder mehrerer Bezeichner eingebunden. Es kann auch vorgesehen sein, dass einem Namensmakro jeweils eine Ausweichvorschrift zugeordnet wird, um im Fall von Namenskollisionen eine automatische Auflösung zu ermöglichen.
Alternativ können einem Block oder einer Region Ausweichvorschriften zugeordnet werden. Der Bezeichner kann zweckmäßigerweise auch einen festen Namensbestandteil aufweisen. Wenn zwei Blockvariablen anhand der Namensmakros denselben Namen aufweisen, bzw. eine Namenskollision auftritt, können verschiedene
Ausweichvorschriften angewandt werden. Beispielsweise kann es vorgesehen sein, den durch Auswertung des Namensmakros erhaltenen Namen um einen Zählbestandteil zu ergänzen (wie„VarName_a",„VarName_b",
„Varname_aa",„Varname_ab", ...). Dies stellt sicher, dass keine zufällige
Namensgleichheit auftritt. Alternativ oder ergänzend kann es auch vorgesehen sein, den Namen einer Region, der anhand des Namensmakros ggfs. zunächst nur lokale Informationen enthält, um Kontext-Informationen zu erweitern, beispielsweise einen Dateinamen oder den Namen eines oder mehrerer hierarchisch übergeordneter Blöcke, wie umfassenden Subsystemen, dem Namen der Region voranzustellen. Ferner kann es alternativ oder ergänzend vorgesehen sein, dass der Nutzer einen möglichen Namensbestandteil vorgibt, der im Falle einer Namenskollision zusätzlich oder anstelle eines in dem
Namensmakro definierten Namensbestandteils eingesetzt wird . Eine
Ausweichvorschrift kann zusätzliche Randbedingungen überprüfen, und insbesondere im Falle des Überschreitens einer vorgegebenen Maximallänge auch eine Kürzungsvorschrift umfassen. Beispielsweise kann es vorgesehen sein, bei hierarchisch zusammengesetzten Namen, die also mehrere einander umfassende Regionen hintereinander enthalten, den zugehörigen
Namensbestandteil einer oder mehrerer dieser Regionen derart zu kürzen, dass nur einzelne Anfangsbuchstaben des Bezeichners der entsprechenden Region im Namen beibehalten werden. Dies ist insbesondere dann vorteilhaft, wenn Sprachstandards eine maximale Länge von Variablennamen vorgeben bzw. diese nur bis zu einer bestimmten Stelle ausgewertet werden.
Es ist vorteilhaft, wenn vordefinierte Blöcke, welche eine Funktionalität bereitstellen, aus einer Bibliothek in das Blockdiagramm eingefügt werden können, wobei mehrere Blöcke mit der gleichen Funktionalität in dem
Blockdiagramm vorhanden sein können. Zweckmäßigerweise wird in dem Fall, dass mehrere Instanzen eines Blocks in dem Blockdiagramm vorhanden sind, entweder für jede Instanz eine unabhängige Region definiert, öder es werden für die Instanzen eine gemeinsame Funktion und für jede Instanz eine
Datenstruktur mit den Blockvariablen definiert, wobei je nach auszuführendem Block die entsprechende Datenstruktur an die Funktion übergeben wird . Ein Block bzw. ein Subsystem, welches mehrfach in dem Blockdiagramm
verwendet wird, kann aus einer Bibliothek oder aus einer referenzierten Datei stammen. Es ist vorteilhaft, wenn bei der mehrfachen Verwendung nicht der vollständige Inhalt des Bibliotheksblocks oder des referenzierten Modells kopiert wird, sondern eine instanzübergreifende Funktion des Blocks mit einer instanzspezifischen Datenstruktur kombiniert wird . Dies ermöglicht es, den erzeugten Quellcode besonders kompakt zu halten. Insbesondere ist es zweckmäßig, die Daten in einer Struktur zu hinterlegen, welche über einen Zeiger referenziert wird . Dies ermöglicht eine beliebig häufige Verwendung der Anweisungen, wobei nur die Daten mehrfach im Speicher vorhanden sein müssen. Somit wird auch der in der Regel beschränkte Arbeitsspeicher eines Steuergeräts weniger ausgelastet. Im Falle mehrerer Instanzen ist die
Verwendung von Ausweichvorschriften, wie einem Zähler, besonders
vorteilhaft, um eindeutige und hinreichend kurze Namen zu gewährleisten.
Bevorzugt weist jede Blockvariable eine Zulässigkeitsmarkierung auf, welche gesetzt oder nicht gesetzt sein kann, und zwei Blockvariablen werden nur dann in einer gemeinsamen Variable implementiert, wenn in beiden
Blockvariablen die Zulässigkeitsmarkierung gesetzt ist. Die Zulässigkeitsmarkierung kann indirekt für eine oder mehrere Variablen gesetzt werden, beispielsweise durch Rückbezug auf eine Definitionsdatensammlung, insbesondere durch die Zuordnung einer Variablenklasse bzw. eines
Variablentyps, der eine oder mehrere für verschiedene Variablen gemeinsame Eigenschaften definiert. Das Setzen einer Zulässigkeitsmarkierung ermöglicht eine direkte Beeinflussung der Optimierung durch den Nutzer. Die
Zulässigkeitsmarkierung kann unbedingt gelten oder nur in Verbindung mit der Erfüllung einer zusätzlichen Bedingung eine Optimierung gestatten.
Prinzipiell können den Blockvariablen bzw. den Blöcken auch eine unbedingte Zusatzmarkierung sowie eine oder mehrere Prüfmarkierungen zugeordnet werden. Besonders bevorzugt weist jede Blockvariable mindestens eine Prüfmarkierung auf, welche gesetzt oder nicht gesetzt sein kann, und zwei Blockvariablen werden nur dann in einer gemeinsamen Variable implementiert, wenn in beiden Blockvariablen die Prüfmarkierung gesetzt ist und zusätzlich
mindestens eine der Prüfmarkierung zugeordnete Prüfbedingung erfüllt ist. Somit kann automatisch sichergestellt werden, dass die Optimierung in dem vorliegenden Modell sinnvolle Ergebnisse erzeugt. Zweckmäßigerweise werden eine oder mehrere der folgenden Prüfbedingungen überprüft:
• Ob die Blockvariablen innerhalb des Blocks nicht verändert, sondern nur ausgelesen werden.
• Ob die Lebensdauern verschiedener Instanzen der Blockvariablen disjunkt sind, so dass die zwei Blockvariablen nur zu unterschiedlichen, nicht überlappenden Zeiten gelesen oder geschrieben werden. · Ob den Blockvariablen in einer Definitionsdatensammlung dieselbe
Variablendefinition zugeordnet ist. Eine Variablendefinition kann
insbesondere die Angabe eines Grund-Datentyps, des Minimal- und/oder Maximal-Werts und/oder eine Skalierung umfassen. · Ob die Blockvariablen an einer gleich spezifizierten gerichteten Verbindung angeordnet sind. Eine gerichtete Verbindung zwischen zwei Blöcken zeigt zweckmäßigerweise den Austausch von Signalen an; Signale können einen skalaren Datentyp aufweisen oder aus mehreren skalaren Datentypen zusammengesetzt sein, wie etwa ein Bus. Das Signal wird von einem Ausgangsblock an einen oder mehrere Zielblöcke übertragen. Zwei
Blockvariablen erfüllen die Bedingung insbesondere dann, wenn die eine im Ausgangsblock und die andere in einem Zielblock definiert ist.
Hierbei kann es vorgesehen sein, dass einer Prüfmarkierung eine
Prüfbedingung zugeordnet ist, oder einer Prüfmarkierung mehrere
Prüfbedingungen zugeordnet sind, wobei ein Zusammenfassen von Variablen nur dann erfolgt, wenn alle der Prüfmarkierung zugeordneten Bedingungen erfüllt. Es kann auch mehr als eine Prüfmarkierung geben, wobei jeder einzelnen Prüfmarkierung dann eine oder mehrere Prüfbedingungen
zugeordnet sind .
Besonders bevorzugt kann einer Blockvariablen ein oder mehrere Parameter zugeordnet werden, wobei zwei Blockvariablen nur dann in einer gemeinsamen Variable implementiert werden, wenn eine oder mehrere der folgenden
Zusatzbedingungen erfüllt ist:
• Den Blockvariablen wurde derselbe Datentyp zugeordnet
• Den Blockvariablen wurden miteinander verträgliche Maßeinheiten zugeordnet
• Die Namen von Blockvariablen werden mittels Erzeugungsvorschriften bestimmt, wobei nur solche Blockvariablen zusammengefasst werden, deren Namen mit der gleichen Erzeugungsvorschrift bestimmt wurde.
Vorzugsweise wird mindestens eine Blockvariable anhand von gerichteten Verbindungen zwischen Blöcken automatisch erzeugt, wobei für den Fall, dass ein erster Block mit einem zweiten Block und der zweite Block mit einem dritten Block verbunden ist, eine Blockvariable des ersten Blocks für die von dem ersten Block ausgehende Verbindung erzeugt wird und eine Blockvariable des zweiten Blocks für die von dem zweiten Block ausgehende Verbindung erzeugt wird, wobei die zwei Blockvariablen dann als eine gemeinsame
Variable in dem Quellcode implementiert werden, wenn der erste Block und der zweite Block in der gleichen Region liegen.
Es ist vorteilhaft, wenn eine Trennungsregion definiert ist, wobei die
Blockvariablen von Blöcken, die in der Trennungsregion liegen, immer als getrennte Variable im Quellcode implementiert sind . Insbesondere kann die äußerste Region als Trennungsregion vordefiniert sein, wobei Definitionsblöcke in untergeordneten Hierarchieebenen dann einzelne Regionen definieren, in denen Blockvariablen zusammengefasst werden dürfen.
Die Erfindung betrifft ferner ein Verfahren zum Konfigurieren eines
Steuergeräts, wobei das Steuergerät mindestens eine Recheneinheit umfasst und vorzugsweise mindestens einen Sensor und/oder mindestens einen Aktor aufweist, um Daten eines physikalischen Prozesses zu erfassen und/oder auf diesen einzuwirken, das Verfahren umfassend die Schritte
a. Einlesen eines Blockdiagramms, b. Erzeugen eines Quellcodes mit einem Verfahren nach einem der vorhergehenden Ansprüche,
c. Kompilieren des Quellcodes für die Recheneinheit, so dass ein ausführbarer Code erzeugt wird,
d. Übertragen des ausführbaren Code auf das Steuergerät, und e. Hinterlegen des ausführbaren Codes auf einem nichtflüchtigen
Speicher des Steuergeräts und/oder Ausführen des ausführbaren Codes durch die Recheneinheit des Steuergeräts. Ferner betrifft die Erfindung ein Computerprogrammprodukt mit einem computerlesbaren Speichermedium, auf dem Befehle eingebettet sind, die, wenn sie von einem Prozessor ausgeführt werden, bewirken, dass der
Prozessor dazu eingerichtet ist, ein Verfahren gemäß einem der
vorhergehenden Ansprüche auszuführen.
Weiterhin betrifft die Erfindung ein Computersystem umfassend eine Mensch- Maschine-Schnittstelle, einen nichtflüchtigen Speicher und einen Prozessor, wobei der Prozessor dazu eingerichtet ist, ein erfindungsgemäßes Verfahren auszuführen.
Die Erfindung wird nachfolgend unter Bezugnahme auf die Zeichnungen näher erläutert. Hierbei werden gleichartige Teile mit identischen Bezeichnungen beschriftet. Die dargestellten Ausführungsformen sind stark schematisiert, d .h . die Abstände und die lateralen und die vertikalen Abmessungen sind nicht maßstäblich und weisen, sofern nicht anders angegeben, auch keine
ableitbaren geometrischen Relationen zueinander auf.
Darin zeigt: Figur 1 eine bevorzugte Ausführungsform eines Computersystems,
Figur 2 eine schematische Darstellung der vorzugsweise auf einem
Computersystem vorhandenen Softwarekomponenten, Figur 3 ein allgemeines Schema des Erzeugens von Quellcode,
Figur 4 eine schematische Darstellung der Uberprüfung des
erzeugten Quellcodes anhand des Blockdiagramms,
Figur 5 eine schematische Darstellung eines beispielgemäßen
Blockdiagramms mit mehreren Hierarchieebenen,
Figur 6 einen schematischen Ablaufplan einer bevorzugten
Ausführungsform des erfindungsgemäßen Verfahrens, und
Figur 7 ein detailliertes Ausführungsbeispiel eines Blockdiagramms.
Figur 1 zeigt eine bevorzugte Ausführungsform eines Computersystems PC. Dieses weist einen Prozessor CPU, der insbesondere als Mehrkernprozessor realisiert sein kann, einen Arbeitsspeicher RAM und einen Buscontroller BC auf. Bevorzugt ist das Computersystem PC dazu ausgelegt, von einem Nutzer direkt manuell bedient zu werden, wobei über eine Grafikkarte GPU ein
Monitor DIS und über eine Peripherieschnittstelle HMI eine Tastatur KEY und eine Maus MOU angeschlossen sind . Prinzipiell könnte die Mensch-Maschine- Schnittstelle des Computersystems PC auch als Touch-Interface ausgebildet sein. Das Computersystem umfasst weiterhin einen nichtflüchtigen
Datenspeicher HDD, der insbesondere als Festplatte und/oder Solid State Disk ausgeführt sein kann, sowie eine Schnittstelle NET, insbesondere eine Netzwerkschnittstelle. Über die Schnittstelle NET kann ein Steuergerät ES angeschlossen sein. Prinzipiell können ein oder mehrere beliebige
Schnittstellen, insbesondere drahtgebundene Schnittstellen, an dem
Computersystem PC vorhanden und jeweils für die Verbindung mit einem Steuergerät ES einsetzbar sein . Zweckmäßigerweise kann eine
Netzwerkschnittstelle nach dem Ethernet-Standard verwendet werden; die Schnittstelle NET kann auch drahtlos ausgeführt sein, wie insbesondere als WLAN-Schnittstelle oder nach einem Standard wie Bluetooth.
Das Steuergerät ES kann als ein Seriensteuergerät oder als Evaluierungs- board für eine Target- Plattform ausgeführt sein. Zweckmäßigerweise umfasst es eine Schnittstelle NET zur Verbindung mit dem Computersystem PC, einen MikroController MCR mit einer von dem Prozessor des Computersystems abweichenden Architektur, einen Arbeitsspeicher RAM und einen nichtflüchtigen Speicher NVM .
In Figur 2 ist ein Schema der vorzugsweise auf dem Computersystem PC installierten Softwarekomponenten dargestellt. Diese verwenden Mechanismen des Betriebssystems OS, um beispielsweise auf den nichtflüchtigen Speicher HDD zuzugreifen oder über die Netzwerkschnittstelle NET eine Verbindung zu einem externen Rechner aufzubauen.
Eine Technische Rechenumgebung TCE ermöglicht die Erstellung von Modellen und die Erzeugung von Quellcode aus den Modellen. In einer Modellier- Umgebung MOD können vorzugsweise über eine graphische Benutzerschnittstelle Modelle eines dynamischen Systems erstellt werden. Hierbei kann es sich insbesondere um Blockdiagramme handeln, welche mehrere Blöcke umfassen und das zeitliche Verhalten und/oder interne Zustände eines dynamischen Systems beschreiben. Zumindest einige der Blöcke sind über Signale verbunden, also gerichtete Verbindungen zum Austausch von Daten, welche skalar oder zusammengesetzt sein können. Blöcke können atomar sein, also in einem Schritt eine vordefinierte Funktionalität bereitstellen. Wenn Blockdiagramme hierarchisch sind, kann eine Vielzahl von Blöcken in einer untergeordneten Ebene den Aufbau eines Blocks in einer übergeordneten Ebene beschreiben. Zweckmäßigerweise können atomare Blöcke dann auch eine Vielzahl von Blöcken in einer untergeordneten Ebene umfassen.
Zusammengesetzte Blöcke können insbesondere Subsysteme sein;
Subsysteme können zusätzliche Eigenschaften aufweisen, wie die Implementierung in einer getrennten Funktion und/oder ein Triggern der Ausführung des Subsystems über ein dediziertes Signal. In Subsystemen können spezielle Blöcke angeordnet sein, um die Eigenschaften des
Subsystems weiter zu spezifizieren. Die Rechenumgebung TCE umfasst eine oder mehrere Bibliotheken BIB, aus der Blöcke bzw. Bausteine für den Aufbau eines Modells ausgewählt werden können. In einer Skriptumgebung MAT können Anweisungen interaktiv oder über eine Batchdatei eingegeben werden, um Berechnungen durchzuführen oder das Modell zu modifizieren. Die
Rechenumgebung TCE umfasst weiterhin eine Simulationsumgebung SIM, die dazu eingerichtet ist, das Blockdiagramm zu interpretieren bzw. auszuführen, um das zeitliche Verhalten des Systems zu untersuchen. Diese Berechnungen erfolgen vorzugsweise mit Fließkommazahlen hoher Genauigkeit auf einem oder mehreren Kernen des Mikroprozessors CPU des Computersystems. Aus einem erstellten Modell kann mit Hilfe eines Codegenerators PCG ein Quellcode bevorzugt in einer Programmiersprache wie C erzeugt werden. In einer Definitionsdatensammlung DDT werden zweckmäßigerweise zusätzliche Informationen zu dem Modell, insbesondere zu den Blockvariablen.
Zweckmäßigerweise werden den Blockvariablen Wertebereiche und/oder Skalierungen zugeordnet, um eine Berechnung des Modells mit Festkomma- Instruktionen zu unterstützen. Auch gewünschte Eigenschaften des
Quellcodes, beispielsweise Konformität zu einem Standard wie MISRA, können in der Definitionsdatensammlung DDT eingestellt bzw. hinterlegt werden.
Zweckmäßigerweise wird jede Blockvariable einem vorgegebenen Variablentyp zugeordnet und es werden eine oder mehrere gewünschte Eigenschaften, wie beispielsweise die Zulässigkeit von Optimierungen wie einem Zusammenfassen von Variablen eingestellt. Der Codegenerator PCG wertet vorzugsweise die Einstellungen der Definitionsdatensammlung DDT aus und berücksichtigt diese bei der Erzeugung des Quellcodes. Die Definitionsdatensammlung DDT kann eine Baumstruktur aufweisen bzw. als eine einfache Datei in einem
Speicher des Computersystems hinterlegt sein; alternativ kann es vorgesehen sein, die Definitionsdaten in einem dedizierten Datenbanksystem zu hinterlegen. Die Definitionsdatensammlung kann eine Programmschnittstelle und/oder Import-/Export-Funktionen aufweisen.
Das Computersystem PC weist einen Compiler COM und einen Linker LIN auf, die zweckmäßigerweise für die Erzeugung von auf einem Steuergerät ES und/oder dem Computersystem PC ausführbaren Binärdateien eingerichtet sind. Prinzipiell kann eine Vielzahl von Compilern vorhanden sein,
insbesondere Cross-Compiler für unterschiedliche Zielplattformen, um
Steuergeräte bzw. Evaluationsboards ES mit unterschiedlichen Prozessor- architekturen zu unterstützen.
Figur 3 zeigt ein allgemeines Schema des Erzeugens von Quellcode mittels eines Codegenerators. Das Verfahren kann vollständig von einem Prozessor einer bevorzugten Ausführungsform des Computersystems PC ausgeführt werden; es kann aber auch zur Ausführung in einer Client-Server-Umgebung mit einem Bedienrechner und einem oder mehreren über ein Netzwerk verbundenen Servern vorgesehen sein, wobei insbesondere rechenintensive Schritte auf den Servern durchgeführt werden.
In einem ersten Schritt Sl, einer Transformation, wird das gewählte Modell aus einem oder mehreren Blöcken des Blockdiagramms BLD in eine Zwischendarstellung IR transformiert, die vorzugsweise einen oder mehrere
hierarchische Graphen umfasst. Hierbei kann es sich insbesondere um einen Datenflussgraph, einen Kontrollflussgraph oder eine Baumstruktur handeln. Neben dem Blockdiagramm BLD werden zweckmäßigerweise auch Zusatzinformationen aus einer Definitionsdatensammlung DDT bei der Erzeugung der Zwischendarstellung berücksichtigt bzw. fließen in diese ein. Dies kann auch Situationen umfassen, in denen Elemente basierend auf Informationen in der Definitionsdatensammlung DDT erzeugt werden oder Eigenschaften von Elementen bzw. für die Codeerzeugung relevante Einstellungen, wie
beispielsweise der Datentyp einer Variablen, aus der
Datendefinitionssammlung DDT extrahiert werden. In einem zweiten Schritt S2, einer Optimierung, werden die hierarchischen Graphen optimiert, um die Anzahl benötigter Variablen und/oder einen
Speicherverbrauch, wie beispielsweise eine Stackbelegung, und/oder die Anzahl von Operationen bzw. Prozessorinstruktionen und/oder die
Ausführungszeit des Quellcodes zu verringern. Diese Optimierung kann eine Vielzahl von Zwischenschritten umfassen, in denen weitere Zwischendarstellungen zwischen Modell/Blockdiagramm und Quellcode/Programmtext erzeugt werden. Insbesondere kann es vorgesehen sein, in jedem Zwischen- schritt eine Menge von ursprünglichen hierarchischen Graphen in eine andere Menge von geänderten hierarchischen Graphen zu konvertieren, wobei eine oder mehrere Optimierungsregeln angewandt werden. Verschiedene
Strategien wie„Constant folding" oder eine Eliminierung von„Dead Code" können während der Optimierung angewandt werden. Es kann auch
vorgesehen sein, einzelne Optimierungen bereits im Rahmen der
Transformation von Schritt Sl anzuwenden, insbesondere wenn diese auf einer Blockdiagrammdarstellung einfacher durchgeführt werden können. Im Rahmen der Erfindung ist es prinzipiell sowohl möglich, dass mehrere in Schritt Sl erzeugte Variablen in Schritt S2 zusammengefasst werden, als auch dass in Schritt Sl mehrere Variable des Blockdiagramms derart zusammengefasst werden, dass bereits die erste Zwischendarstellung nur noch eine Variable enthält.
In einem dritten Schritt S3, einer Übersetzung, werden die optimierte
Zwischendarstellung IR bzw. die optimierten hierarchischen Graphen, welche aus den gesamten durchgeführten Zwischenschritten resultieren, in Quellcode PCO einer textuellen Programmiersprache, wie insbesondere C-Code, übersetzt. Auch in diesem Schritt kann eine weitere Optimierung erfolgen, insbesondere dergestalt, dass die erzeugten Anweisungen einer Untermenge der prinzipiell von der Sprache umfassten Anweisungen darstellen und/oder die erzeugten Kontrollstrukturen eine Untermenge der prinzipiell von der Sprache umfassten Kontrollstrukturen darstellen. Dies ermöglicht es, genau definierte Regeln zu erfüllen. Alternativ oder ergänzend kann es vorgesehen sein, Zusatzinformationen, wie z. B. einen Bezug zwischen Programmzeile und Block des Blockdiagramms BLD, zu erzeugen und insbesondere in Form von Kommentaren in den Quellcode einzubinden, um die Lesbarkeit des Quellcodes PCO zu verbessern und/oder ein Debugging zu vereinfachen.
Während oder nach der Codegenerierung können Informationen über das aktuelle Blockdiagramm oder Ergebnisse der Codegenerierung, wie
beispielsweise Warnungen, in der Definitionsdatensammlung gespeichert werden. Diese Informationen können beispielsweise dazu genutzt werden, eine Kompilierung des erzeugten Quellcodes zu beeinflussen oder Meta- informationen für andere Werkzeuge bereitzustellen, wie beispielsweise Kalibrierungsinformationen im ASAP2-Format oder Informationen zur
Erzeugung einer Zwischenschicht nach dem AUTOSAR- Standard . In
alternativen Ausführungsformen der Erfindung kann es vorgesehen, aus dem Blockdiagramm Code in einer Hardwarebeschreibungssprache oder eine Konfiguration eines programmierbaren Hardwarebausteins zu generieren.
Figur 4 zeigt eine schematische Darstellung der Überprüfung des erzeugten Quellcodes anhand des Blockdiagramms.
In dem abgebildeten Beispiel ist ein Blockdiagramm BLD bzw. ein Subsystem bestehend aus drei Blöcken schematisch dargestellt, welches einen Eingangs- Port zum Empfangen eines Eingangssignals und einen Ausgangs-Port zum Senden eines Ausgangssignals aufweist. Das Blockdiagramm kann
zweckmäßigerweise ein vorbestimmtes oder gewünschtes Verhalten eines Kontrollprogramms beschreiben. Wird das Blockdiagramm in der hier nicht gezeigten Simulationsumgebung ausgeführt, so wird das Verhalten für aufeinanderfolgende Zeitschritte berechnet; insbesondere kann das Block- diagramm BLD hierbei direkt interpretiert werden. Aus der Spezifikation bzw. der vorgesehenen Anwendung wurden im Vorfeld einige Testfälle ermittelt, die insbesondere Stimuli STIM als Eingangssignale für das Kontrollprogramm umfassen, wobei den Stimuli ein entsprechendes Ausgangssignal RESP zugeordnet ist.
Ein Stimulus STIM ist in dem gezeigten Beispiel als Diagramm dargestellt, welches ein bestimmtes zeitliches Verhalten des Eingangssignals angibt. Wenn das Kontrollprogramm bzw. das Blockdiagramm BLD in der Simulationsumgebung des Computersystems ausgeführt wird, so wird für eine Vielzahl von Zeitschritten ein momentaner Wert des Stimulus STIM an den Eingangs- Port des Blockdiagramms BLD angelegt und die den Blöcken entsprechenden Operationen berechnet, um einen inneren Zustand und/oder ein Ausgangssignal des Kontrollprogramms zu ermitteln. Durch das Aufzeichnen des
Ausgangssignals während der Ausführung des Blockdiagramms kann eine Sollantwort RESPl in einer Model-in-the-Loop-Simulation ermittelt werden. Da alle arithmetischen Operationen in einer hohen Genauigkeit berechnet werden, beispielsweise indem Variablen immer den Datentyp Double aufweisen und somit Floating-Point-Berechnungen erfolgen, kann zum einen das korrekte Verhalten des Modells verifiziert werden und zum anderen ist das
Simulationsergebnis hinreichend genau, um das gespeicherte Ausgangssignal bzw. die Sollantwort RESPl als Referenzdaten zu verwenden.
Nachdem also die Korrektheit des Modells bestätigt wurde, erzeugt der
Codegenerator PCG Quellcode aus den dem Kontrollprogramm entsprechenden Blöcken des Blockdiagramms. Der erzeugte Quellcode wird anschließend mit einem Compiler COM zu Objektcode OBJ kompiliert, der zweckmäßigerweise Instruktionen für den Prozessor des Zielsystems enthält. Vorzugsweise wird der Objektcode von einem Linker zu einer ausführbaren Datei in dem
Betriebssystem des Zielsystems zusammengefasst. Während der Codeerzeugung können Einstellungen bzgl . einer Umwandlung der Modelloperationen in Festkommadarstellung, die also auch eine entsprechende Skalierung umfassen, bzw. allgemein Transformationen zur Verringerung des Rechenaufwands angewandt werden, um eine Echtzeitausführung auch auf leistungsschwächerer Hardware wie einem MikroController eines Embedded- Systems ES zu ermöglichen. Um sicherzustellen, dass die optimierte Version des Kontrollprogramms bzw. der generierte Quellcode ein dem Blockdiagramm entsprechendes Verhalten aufweist, erfolgt zweckmäßigerweise eine Software-in-the-Loop-Simulation, bei der das Zielsystem dem Computersystem PC entspricht, oder eine
Processor-in-the-Loop-Simulation, bei der das Zielsystem ein Embedded- System ist. Hierbei wird der ausführbaren Datei mit dem Objektcode OBJ während der vorgegebenen Ausführungsdauer der Stimulus STIM zugeführt und das aus den Berechnungen resultierende Ausgangssignal des generierten Quellcodes aufgezeichnet, um die Istantwort RESP2 zu erhalten.
Die Sollantwort RESPl der Model-in-the-Loop-Simulation kann auf dem
Computersystem simultan zu der Ist-Antwort RESP2 des generierten Codes dargestellt werden, um dem Nutzer einen visuellen Vergleich zu ermöglichen. Alternativ oder ergänzend kann auch ein Vergleich von Sollantwort RESPl und Istantwort RESP2 in einem Vergleichsprogramm CMP berechnet werden. Dies ermöglicht beispielsweise die Bestimmung eines Abweichungsmaßes und/oder das Überprüfen einer oder mehrerer Testbedingungen, beispielsweise das Berechnen einer punktweisen Differenz zwischen Istantwort und Sollantwort und den Vergleich mit einem Schwellwert bzw. einer maximal zulässigen Abweichung.
In Figur 5 ist eine schematische Abbildung eines beispielgemäßen
Blockdiagramms mit mehreren Hierarchieebenen dargestellt, wobei Blöcke einer Hierarchieebene in einer rechteckigen Umrandung dargestellt sind .
Das gezeigte Blockdiagramm umfasst in der ersten (obersten) Hierarchieebene El eine Vielzahl von Blöcken Bi, i = 1..5, welche über Signale miteinander verbunden sind, wobei die Richtung der Verbindung den Signalfluss angibt. Weiterhin ist ein Definitionsblock Dl dargestellt, welcher eine erste Region definiert, so dass die Blöcke Bi, i = 1..5 in dieser ersten Region liegen. Die Blöcke BI, B2, B3 und B5 können atomar bzw. einfach sein oder eine nicht dargestellte Unterstruktur aufweisen. Block B4 ist ein zusammengesetzter Block, dessen Funktionalität durch Blöcke in einer zweiten (untergeordneten) Hierarchieebene E2 definiert ist. Der gezeigte Ausschnitt einer zweiten Hierarchieebene E2 umfasst eine
Vielzahl von Blöcken B2j, j = 1..4, einen Definitionsblock D2 und zwei Ports für den Austausch von Signalen mit der übergeordneten bzw. obersten Hierarchieebene, einen Eingangs-Port P21 und einen Ausgangs-Port P22. Die Blöcke B21, B22 und B24 können atomar bzw. einfach sein oder eine nicht
dargestellte Unterstruktur aufweisen. Block B23 ist ein zusammengesetzter Block, dessen Funktionalität durch Blöcke in einer dritten (tiefsten)
Hierarchieebene definiert ist.
Der gezeigte Ausschnitt einer dritten Hierarchieebene E3 umfasst eine Vielzahl von Blöcken B3k, k= 1..4, einen Definitionsblock D3 und zwei Ports für den Austausch von Signalen mit der übergeordneten bzw. zweiten Hierarchieebene, einen Eingangs-Port P31 und einen Ausgangs-Port P32. Die Blöcke B31, B32, B33 und B34 können atomar bzw. einfach sein oder eine nicht dargestellte Unterstruktur aufweisen. Prinzipiell können Blockdiagramme eine beliebige Anzahl von Hierarchieebenen aufweisen; der besseren Übersicht halber wurden hier keine weiteren Hierarchieebenen dargestellt.
Prinzipiell können verschiedene Blöcke als Definitionsblöcke eingesetzt werden; zweckmäßigerweise sollten zusammengesetzte Blöcke, welche von anderen Modellteilen aufgerufen werden können und eine zusammenhängende Funktionalität bzw. Code-Einheit umfassen, eine eigenständige Region bilden. Hierbei kann es sich vorzugsweise um Funktionen, insbesondere auf der obersten Ebene des Blockdiagramms handeln . Wenn das Blockdiagramm zur Modellierung von Steuergerätecode nach dem AUTOSAR-Standard verwendet wird, kann zweckmäßigerweise ein Runnable eine eigenständige Region bilden. Hierbei kann der die Region umfassende Block oder vorzugsweise ein in der Region angeordneter Block als Definitionsblock dienen. Es kann vorgesehen sein, dass dedizierte Blöcke für die Definition einer Region verwendet werden, also beispielsweise ein Scope-Block vordefiniert wird . Gemäß einer
alternativen bevorzugten Ausführungsform der Erfindung werden Blöcke, welche die Eigenschaften der Funktion bzw. des Runnables spezifizieren, gleichzeitig als Definitionsblock definiert.
Vorzugsweise ist es vorgesehen, dass eine definierte Region alle hierarchisch untergeordneten Blöcke umfasst. Wenn also Definitionsblock Dl eine erste Region definiert, so liegen zweckmäßigerweise neben den Blöcken Bi, i = 1..5 auch die Blöcke B2j, j = 1..4 und B3k, k= 1..4 in dieser ersten Region.
Hinsichtlich Port-Blöcken kann es bevorzugt ebenfalls vorgesehen sein, dass diese Teil der umfassenden Region sind .
Ergänzend kann es auch vorgesehen sein, dass zwischen ausgezeichneten Definitionsblöcken, beispielsweise der einem Runnable zugeordnete
Definitionsblock, und normalen Definitionsblöcken unterschieden wird . Wenn beispielsweise D2 ein ausgezeichneter Definitionsblock wäre, so würde die von Dl definierte erste Region nur die Blöcke Bi, i = 2..5 umfassen, wohingegen die von D2 definierte zweite Region sowohl die Blöcke B2j, j = 1..4 als auch die Blöcke B3k, k= 1..4 umfasst. Es kann vorgesehen sein, dass es nur einen Typ von ausgezeichneten Definitionsblöcken gibt. Zweckmäßigerweise definieren normale Definitionsblöcke nur dann eine Region, wenn kein ausgezeichneter Definitionsblock in einer übergeordneten Ebene vorhanden ist.
Weiterhin kann vorgesehen sein, dass normale Definitionsblöcke eine neue Region aus einer mit einem normalen Definitionsblock definierten
übergeordneten Region„ausschneiden" können. Wenn Dl, D2 und D3 normale Definitionsblöcke sind, so kann die von Dl definierte erste Region die Blöcke BI, B2, B3, B5 umfassen, während Block B4 die durch Definitionsblock D2 definierte zweite Region bildet. Diese zweite Region umfasst dann die Blöcke B21, B22 und B24, während Block B23 die durch Definitionsblock D3 definierte dritte Region bildet. Die Blöcke B3k, k= 1..4 liegen dann in der dritten Region. Bezugnehmend auf das in Figur 5 dargestellte Diagramm sollen im Folgenden kurz einige Ausführungsbeispiele von Erzeugungsvorschriften erläutert werden. Hierbei soll Dl ein ausgezeichneter Definitionsblock sein,
insbesondere ein Runnable, D2 soll ein regulärer Definitionsblock sein, der insbesondere eine Subfunktion definiert, und D3 soll ein regulärer
Definitionsblock sein, insbesondere einen Bibliotheksblock ohne Definition einer eigenen Funktion definieren. Der Einfachheit halber wird vorliegend die von einem Definitionsblock aufgespannte Region mit demselben Namen wie der Definitionsblock bezeichnet.
Wenn den Blockvariablen von B2, B3, B21, B24, B31 und B33 jeweils die Erzeugungsvorschrift bzw. das Namensmakro„$(Scope)_X" zugeordnet ist, so entstehen bei einer Codegenerierung für die Blöcke B2, B3 Variablen mit dem Bezeichner„D1_X", für die Blöcke B21, B24 Variablen mit dem Bezeichner „D2_X" und für die Blöcke B31, B33 Variablen mit dem Bezeichner„D3_X". Unter der Voraussetzung, dass eventuelle Zusatzbedingungen erfüllt sind, können also beispielsweise die Variablen von Block B2 mit denen von Block B3 zusammengefasst werden. Es kann auch vorgesehen sein, dass eine Erzeugungsvorschrift zwischen ausgezeichneten Regionen bzw. ausgezeichneten Definitionsblöcken und regulären Regionen bzw. Definitionsblöcken unterscheidet. Ist den
Blockvariablen der Blöcke Bl, B22 und B32 jeweils die Erzeugungsvorschrift bzw. das Namensmakro„$(Scope: ParentFunction)_Y" zugeordnet, wobei also die umgebende Funktion berücksichtigt wird, so erhalten bei einer
Codegenerierung aus dem Block Bl erzeugte Variablen den Bezeichner„D1_Y" und aus den Blöcken B22 und B32 erzeugte Variablen jeweils den Bezeichner „D2_Y". Wenn den Blöcken B5 und B34 bzw. deren Blockvariablen jeweils die Erzeugungsvorschrift„$(Scope: Runnable)_Z" zugeordnet ist, wobei also das umgebende Runnable berücksichtigt wird, so werden bei einer Codegenerierung sowohl für B5 als auch für B34 Variablen mit dem Bezeichner „D1_Z" erzeugt. Sofern also eventuelle Zusatzbedingungen erfüllt sind, können also beispielsweise die Variablen von B5 und B34 zusammengefasst werden.
Besonders vorteilhaft ist es, wenn bei dem Zusammenfassen von Variablen nicht nur die Bezeichner selbst verglichen werden, sondern auch die jeweiligen Erzeugungsvorschriften berücksichtigt werden. Wenn gemäß dieser optionalen Zusatzbedingung dann festgestellt wird, dass der Bezeichner einer ersten Variable anhand der Erzeugungsvorschrift„D1_X" (also einem festen Wert) erzeugt wurde, und der Bezeichner einer zweiten Variable anhand der
Erzeugungsvorschrift„$(Scope: Runnable)_X" erzeugt wurde, so ist es zweckmäßig, dass die Variablen nicht zusammengefasst werden, sondern eine Warnung oder Fehlermeldung erfolgt. Dies verringert die Gefahr von fehlerhaften Programmen aufgrund falscher Bezugnahmen. Indem die Erzeugungsvorschriften bereits einen Bezug auf die den
entsprechenden Block umfassende Region enthalten, wird also eine
verbesserte Sicherheit gegenüber fehlerhaften Programmen erreicht. Ganz besonders vorteilhaft ist es, wenn eine Erzeugungsvorschrift nur Bezüge auf eine den zugeordneten Block umfassende Region aufweisen darf. Dies erhöht die Zuverlässigkeit der erzeugten Programme weiter.
In Figur 6 ist ein schematischer Ablaufplan einer bevorzugten
Ausführungsform des erfindungsgemäßen Verfahrens dargestellt, wobei hier nur das Vorgehen für eine erste und eine zweite Blockvariable gezeigt ist. Gemäß einer besonders vorteilhaften Ausführungsform der Erfindung wird zunächst eine Liste der in dem Blockdiagramm vorhandenen Blockvariablen erstellt, wobei konsekutiv alle Blockvariablen überprüft werden. Vorzugsweise werden alle möglichen Paare von Blockvariablen überprüft.
Für die Prüfung eines möglichen Zusammenfassens werden zwei
Blockvariablen gewählt, also in Schritt 101 eine erste Blockvariable und in Schritt 102 eine zweite Blockvariable. In Schritt 103 wird überprüft, ob die erste und die zweite Blockvariable den gleichen Bezeichner aufweisen. Dies kann das Auswerten von
Erzeugungsvorschriften umfassen. Wenn die Blockvariablen verschiedene Bezeichner aufweisen, erfolgt ein Übergang auf Schritt 109.
Wenn die Blockvariablen gleich benannt sind, wird in Schritt 104 überprüft, ob in beiden Variablen eine Zulässigkeitsmarkierung gesetzt ist. Falls lediglich in einer der Blockvariablen die Markierung gesetzt ist, wird zweckmäßigerweise für die Blockvariable ohne Zulässigkeitsmarkierung eine gesonderte Variable im Quellcode erstellt und statt dieser eine neue Blockvariable für den Vergleich ausgewählt. Sofern für eine oder beide Blockvariablen keine
Zulässigkeitsmarkierung vorliegt, erfolgt ein Übergang auf Schritt 108. Anschließend wird in Schritt 105 überprüft, ob die Blockvariablen in der gleichen Region angeordnet sind und somit ein hinreichender lokaler Bezug besteht. Ist dies nicht der Fall, so erfolgt ein Übergang auf Schritt 108.
In Schritt 106 wird überprüft, ob die Blockvariablen eine Zusatzbedingung erfüllen. Beispielsweise kann erforderlich sein, dass die erste und die zweite Blockvariable in der Definitionsdatensammlung eine oder mehrere
übereinstimmende Eigenschaften aufweisen, wie insbesondere eine
Skalierung . Wenn die Zusatzbedingung nicht erfüllt ist, so erfolgt ein Übergang auf Schritt 108.
Wenn alle bisher überprüften Bedingungen erfüllt sind, werden die erste und die zweite Blockvariable in Schritt 107 zu einer Variable im Quellcode zusammengefasst, es wird also eine Variable erzeugt. Wenn die beiden Blockvariablen den gleichen Bezeichner aufweisen, aber mindestens eine der anderen Bedingungen nicht erfüllt ist, so wird in Schritt 108 überprüft ob ein Ausweichen möglich ist, d.h. für eine der Blockvariablen im Programmcode eine anders benannte Variable erzeugt werden kann. Es ist vorteilhaft, wenn in einer Erzeugungsvorschrift auch eine mögliche
Umbenennung bzw. eine Ausweichregel definiert ist. Sollte im konkreten Fall kein Ausweichen möglich sein, so wird in Schritt 110 eine Fehlermeldung an den Nutzer ausgegeben. Ergänzend kann optional vorgesehen sein, die Codeerzeugung abzubrechen, damit zunächst nötige Anpassungen am Modell vorgenommen werden.
Ist ein Ausweichen möglich oder war mindestens eine der überprüften
Bedingungen 104, 105 und 106 nicht erfüllt, dann findet in Schritt 109 eine Erzeugung von zwei getrennten Variablen statt.
Nachdem (in Schritt 108) eine oder (in Schritt 109) zwei Variablen im
Quellcode erzeugt wurden, wird das Verfahren zweckmäßigerweise mit den weiteren zu überprüfenden Blockvariablen durchgeführt.
Prinzipiell kann die Reihenfolge der überprüften Bedingungen gewechselt werden, und es kann auch vorgesehen sein, mehrere Bedingungen in einem Schritt zu überprüfen, wenn beispielsweise die Bezeichner der Blockvariablen auch Informationen über die Region enthalten. In andere Ausführungsformen der Erfindung kann es auch vorgesehen sein, dass zunächst eine Liste mit allen Blockvariablen in einer vorgegebenen Region erstellt wird, wobei die weiteren Bedingungen dann nur für die in der Liste enthaltenen Variablen überprüft werden. Ferner kann es vorgesehen sein, dass die Optimierung in mehreren Schritten erfolgt, also zunächst eine Vielzahl von Variablen im Quelltext erstellt und diese dann anhand eines Vergleichs der zugeordneten Blockvariablen zusammengefasst werden.
In alternativen Ausführungsformen der Erfindung kann es auch vorgesehen sein, verschiedene Zulässigkeits- bzw. Prüfmarkierungen mit verschiedenen Zusatzbedingungen zu verknüpfen. Beispielsweise kann ein Zusammenfassen von Variablen dann gestattet sein, wenn es sich um Blockparameter handelt, welche nur gelesen werden, die also insbesondere eine Kalibriergröße darstellen können. In einem anderen Beispiel kann ein Zusammenfassen dann gestattet sein, wenn die verschiedenen Blockvariablen disjunkte Lebensdauern aufweisen, so dass Seiteneffekte durch überlappende Schreib-/Lesevorgänge verschiedener Blöcke ausgeschlossen werden können.
Figur 7 zeigt ein detailliertes Ausführungsbeispiel eines Blockdiagramms, welches die Funktionalität eines Puffers mit Reset-Möglichkeit bereitstellt. Dies dient insbesondere dazu, einen Block mit der entsprechenden Funktionalität in einem nicht dargestellten übergeordneten Modell zu implementieren, wobei das Blockdiagramm ein- oder mehrfach referenziert werden kann, also ggfs. einen komplexen Bibliotheksblock darstellt.
In diesem Beispiel sind die beiden Blöcke DetermineValue und StoreOverwrite atomare Subsysteme, welche in einer untergeordneten Hierarchieebene implementiert sind, aber in einem Rechenschritt ausgeführt werden. Der besseren Übersichtlichkeit halber ist hier die jeweilige Implementierung in dem Block selber dargestellt, wobei über gestrichelte Pfeile die Verbindung zwischen dem mit dem jeweiligen Block verbundenen Signal und dem
zugeordneten Eingangs- oder Ausgangs-Port der untergeordneten
Hierarchieebene angegeben sind . Ports sind mit abgerundeten Ecken
dargestellt, wobei anhand der Signalrichtung erkennbar ist, ob es sich um einen Eingangs-Port, der ein Signal empfängt, oder einen Ausgangs-Port handelt. In dem beispielgemäßen Blockdiagramm ist ein Definitionsblock DR1 angeordnet, der eine Region Rl definiert, welche alle gezeigten Blöcke umfasst.
Das gezeigte Blockdiagramm hat den Eingangs-Port In, der ein skalares Signal empfängt, den Eingangs-Port ResetValue, der ein Vektor-Signal mit einer Breite von 11 empfängt, und den Eingangs-Port Reset, der ein skalares bzw. boolesches Signal empfängt. Ferner weist es einen Ausgangs-Port Out auf, der ein skalares Signal sendet. Zwei unverbundene Blöcke MemBuf und Memldx definieren Speicherblöcke (DataStoreMemory), auf die mittels spezieller Schreib- bzw. Leseblöcke zugegriffen werden kann. Die Speicherblöcke können zwischen mehreren Aufrufen der in dem Blockdiagramm implementierten Funktionalität ihren Wert beibehalten und stellen somit Zustände dar. Der Speicherblock MemBuf wird mit dem Block ReadBuf gelesen und mit dem Block WriteBuf beschrieben. Entsprechend wird der Speicherblock Memidx mit dem Block Readldx gelesen und mit dem Block Writeldx beschrieben.
Ein von außen angelegtes Vektor-Signal ResetValue wird dem Umschalteingang des Blocks ResetBuf in dem atomaren Subsystem Determine Value zugeführt; dieser empfängt weiterhin das von außen angelegte Signal Reset und den aktuellen Wert des Speicherblocks MemBuf. Dieser wird über den Block ReadBuf ausgelesen und mittels des Blocks RBuf (Convert) geeignet konvertiert. Der Block ResetBuf liefert in Abhängigkeit von dem anliegenden Umschaltwert als Ausgangssignal entweder den aktuellen Wert des
Speicherblocks oder den Wert des Signals ResetValue. Mittels des
Selektorblocks Selector kann der skalare Wert mit dem Index Idx aus dem Bus-Signal extrahiert und über den Ausgangs-Port Out ausgegeben werden. Das gesamte Vektor-Signal wird daneben an den Ausgangs-Port CurBuf übergeben. Der aktuell im Speicherblock Memidx hinterlegte Wert wird mittels des Blocks Readldx ausgelesen, durch den Block RIdxl (Convert) geeignet konvertiert und dann über den Eingangs-Port in_Idx dem atomaren Subsystem
StoreOverwrite zugeführt. Dieses weist zwei Ausgangs-Ports Overwrite und out_Idx auf, welche jeweils denselben Wert ausgeben.
Der Ausgangs-Port out_Idx ist mit einem ersten Eingang des Summenblock Incrldx verbunden, dessem zweiten Eingang über einen Konstanten-Block Constant der feste Wert 1 zugeführt wird . Das Ausgangssignal von Incrldx wird einem Eingang des Blocks Normalize_Idx und einem ersten Eingang von Vergleichsblock Rel zugeführt. An den zweiten Eingang des Vergleichsblocks Rel ist über Konstantenblock Constantl der Wert NDelaySize angelegt, so dass Vergleichsblock Rel in Abhängigkeit davon, ob das Ausgangssignal von Incrldx kleiner als NDelaySize ist, den Wert 1 oder 0 ausgibt. Der Ausgang von Vergleichsblock Rel ist mit einem Umschalteingang des Blocks Normalizeldx verbunden. Über einen Konstantenblock Constant2 wird dem Block
Normalizeldx weiterhin der konstante Wert 0 zugeführt. Somit liegt am
Ausgang von Normalizeldx das Ausgangssignal von Incridx an, solange dieses kleiner als NDelaysize ist; andernfalls wird der Ausgangswert von
Normalizeldx zu 0. Der Ausgang des Blocks Normalizeldx ist mit dem Block Writeldx zum Beschreiben des Speicherblocks Memldx sowie dem Eingangs- Port Idx des atomaren Subsystems DetermineValue verbunden. Der Ausgangs-Port Overwrite ist mit einem Index-Eingang des
Zuweisungsblocks ReplaceOverwrite verbunden. Ein Werte-Eingang von ReplaceOverwrite empfängt über einen Eingangs-Port In einen von außen angelegten skalaren Wert. Weiterhin ist ein Vektor-Eingang des
Zuweisungsblocks ReplaceOverwrite mit dem Ausgangs-Port CurrBuf des atomaren Subsystems DetermineValue verbunden. Der Ausgang des
Zuweisungsblocks, an dem ein Vektor-Signal anliegt, ist mit dem Block
WriteBuf zum Beschreiben des Speicherblocks MemBuf verbunden. Somit kann Zuweiungsblock ReplaceOverwrite den aktuellen Wert des an der durch Overwrite gegebenen Position im Bus angeordneten skalaren Teilsignals ändern.
Aus dem in Figur 7 dargestellten Blockdiagramm kann der Quellcode von Listing 1 erzeugt werden (hier in der Sprache C). Listing 1 : tdefine NDelaysize 10
Intl6 In, Overwrite, Idx, Out, idxl;
Int16 Buf [NDelaySize+1] ;
Intl6 ResetValue [NDelaySize+1] ; Over rite = Idx;
Idx = Idx + 1;
if (Idx >= NDelaySize) {
Idx = 0;
}
if (Reset) {
for (idxl = 0; idxl < NDelaySize; idxl++) {
Buf[idxl] = ResetValue [idxl] ;
}
}
Out = Buf [Idx] ;
Buf [Overwrite] = In;
Das prinzipielle Vorgehen bei der Erzeugung des Quellcodes wurde oben in Zusammenhang mit Figur 3 beschrieben. Vorliegend wurden zum einen die Blockvariablen der Blöcke MemBuf, ReadBuf, WriteBuf, RBuf und ResetBuf in eine Array-Variable Buf[] zusammengefasst. Zum anderen wurden die Blockvariablen der Blöcke Memldx, Readldx, Writeldx, RIdxl und Incrldx in eine skalare Variable Idx zusammengefasst.
Wenn die im Blockdiagramm von Figur 7 definierte Funktionalität mehrfach verwendet werden soll, so ist es zweckmäßig, die Daten in einer Struktur zu hinterlegen, welche über einen Zeiger referenziert wird . Dies ermöglicht eine beliebig häufige Verwendung der Anweisungen (Function Reuse), wobei nur die Daten instanzspezifisch, also mehrfach im Speicher vorhanden sein müssen. Der entsprechende Quellcode ist in Listing 2 angegeben.
Listing 2 :
#define NDelaysize 10
Struct tagISV{
Int16 IdxBWR;
Int16 BufBWR [NDelaysize+1] ; }; void BufWithReset ( Intl 6 In, Int16 ResetValue [NDelaysize +1], Bool Reset, Intl6* Out, struct taglSV* pISV)
{
Int32 idxl ;
Intl 6 Overwrite;
Over rite = pISV->IdxBWR;
pISV->IdxBWR = pISV->IdxBWR + 1 ;
if (pISV->IdxBWR >= NDelaysize) {
pISV->IdxBWR = 0;
}
if (Reset) {
for (idxl= 0; idxl < NDelaysize; idxl++) {
pISV->BufBWR [idxl] = ResetValue [ idxl ] ;
}
}
*Out = pISV->BufBWR[pISV->IdxBWR] ;
pISV->BufBWR [Overwrite] = In;
}
Auch hier wurden die Blockvariablen der Blöcke MemBuf, ReadBuf, WriteBuf, RBuf und ResetBuf in eine Array-Variable BufBWR[] und die Blockvariablen der Blöcke Memldx, Readldx, Writeldx, RIdxl und Incrldx in eine skalare Variable IdxBWR zusammengefasst. Die instanzspezifischen Variablen sind in einer Struktur definiert, welche über einen Zeiger adressiert werden kann, um eine bequeme Wiederverwendung der Funktion zu ermöglichen.
Im Fall von mehrfach verwendeten Bibliotheksblöcken ermöglicht das erfindungsgemäße Verfahren eine besonders große Optimierung .

Claims

Patentansprüche:
1. Verfahren zum Erzeugen von Quellcode aus einem oder mehreren Blöcken eines Blockdiagramms, welches ein Modell eines dynamischen Systems mit mindestens einer Signalverbindung zwischen zwei Blöcken umfasst, wobei das Blockdiagramm ausgeführt werden kann, um das dynamische System zu simulieren, wobei in dem Blockdiagramm mindestens eine Region definiert ist, in der ein oder mehrere Blöcke liegen, wobei das
Blockdiagramm einen ersten Block und einen zweiten Block umfasst, wobei der erste Block eine erste Blockvariable und der zweite Block eine zweite
Blockvariable aufweist, wobei jede Blockvariable des Blockdiagramms einen Bezeichner aufweist, wobei der Bezeichner der ersten Blockvariable mit dem Bezeichner der zweiten Blockvariable verglichen wird, wobei überprüft wird, ob der erste Block und der zweite Block in der gleichen Region liegen, und wobei die erste Blockvariable und die zweite
Blockvariable im Quellcode als eine einzige Variable implementiert werden, wenn die Bezeichner übereinstimmen und die Blöcke in einer Region liegen, und wobei die erste Blockvariable und die zweite Blockvariable im Quellcode als zwei getrennte Variablen implementiert werden, wenn die Bezeichner verschieden sind und/oder die Blöcke nicht in der gleichen
Region liegen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
Blockdiagramme hierarchisch definiert sind, wobei ein Block in einer höheren Ebene mehrere Blöcke einer untergeordneten Ebene umfassen kann, wobei Blöcke einer untergeordneten Ebene einem Block einer höheren Ebene zugeordnet sind, und dass das Blockdiagramm einen oder mehrere Definitionsblöcke umfasst, wobei eine Region anhand von einem Definitionsblock derart definiert ist, dass der den Definitionsblock
umfassende Block der nächsthöheren Ebene und alle diesem umfassenden
Block zugeordneten Blöcke in der Region liegen. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass das
Blockdiagramm mindestens zwei Definitionsblöcke umfasst, welche von einem gemeinsamen Block einer höheren Ebene umfasst sind, wobei ein erster Definitionsblock in einer ersten Ebene und ein zweiter Definitionsblock in einer gegenüber der ersten Ebene untergeordneten zweite Ebene angeordnet ist, wobei der erste Block eine erste Region definiert und wobe der zweite Block eine zweite Region derart definiert, dass der den zweiten Definitionsblock umfassende Block der gegenüber der zweiten Ebene nächsthöheren Ebene sowie alle diesem Block zugeordneten Blöcke in der zweiten Region liegen.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass es
mindestens zwei Sorten von Definitionsblöcken gibt, wobei eine Sorte ausgezeichneter Definitionsblöcke definiert ist, wobei in dem Fall, dass der erste Definitionsblock ein ausgezeichneter Definitionsblock ist, die erste Region und die zweite Region zu einer gemeinsamen Region
zusammengefasst werden, und wobei ansonsten die erste Region und die zweite Region als getrennte Regionen behandelt werden.
Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass der Bezeichner einer Blockvariable anhand einer Auswertung von mindestens einer Erzeugungsvorschrift bestimmt wird, wobei die
Erzeugungsvorschrift den Bezeichner der Blockvariable anhand des Blocks einer höheren Ebene, in welchen der die Blockvariable aufweisende Block umfasst ist, und/oder anhand der Region, in welcher der die Blockvariable aufweisende Block liegt, bestimmt.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die
Überprüfung, ob zwei Blöcke in der gleichen Region liegen, anhand eines Vergleichs der Bezeichner der Blockvariablen erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch
gekennzeichnet, dass vordefinierte Blöcke, welche eine Funktionalität bereitstellen, aus einer Bibliothek in das Blockdiagramm eingefügt werden können, wobei mehrere Blöcke mit der gleichen Funktionalität in dem Blockdiagramm vorhanden sein können, wobei in dem Fall, dass mehrere Instanzen eines Blocks in dem Blockdiagramm vorhanden sind, entweder für jede Instanz eine unabhängige Region definiert wird, oder für die Instanzen eine gemeinsame Funktion und für jede Instanz eine
Datenstruktur mit den Blockvariablen definiert werden, wobei je nach auszuführendem Block die entsprechende Datenstruktur an die Funktion übergeben wird .
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch
gekennzeichnet, dass jede Blockvariable eine Zulässigkeitsmarkierung aufweist, welche gesetzt oder nicht gesetzt sein kann, und wobei zwei Blockvariablen nur dann in einer gemeinsamen Variable implementiert werden, wenn in beiden Blockvariablen die Zulässigkeitsmarkierung gesetzt ist.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass jede
Blockvariable mindestens eine Prüfmarkierung aufweist, welche gesetzt oder nicht gesetzt sein kann, und wobei zwei Blockvariablen nur dann in einer gemeinsamen Variable implementiert werden, wenn in beiden Blockvariablen die Prüfmarkierung gesetzt ist und zusätzlich mindestens eine der Prüfmarkierung zugeordnete Prüfbedingung erfüllt ist, wobei eine oder mehrere der folgenden Prüfbedingungen überprüft werden :
• Ob die Blockvariablen innerhalb des Blocks nicht verändert,
sondern nur ausgelesen werden
• Ob die Lebensdauern verschiedener Instanzen der Blockvariablen disjunkt sind, so dass die zwei Blockvariablen nur zu
unterschiedlichen, nicht überlappenden Zeiten gelesen oder geschrieben werden
• Ob den Blockvariablen in einer Definitionsdatensammlung dieselbe Variablendefinition zugeordnet ist • Ob die Blockvariablen an einer gleich spezifizierten gerichteten Verbindung angeordnet sind .
10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass einer Blockvariablen eine oder mehrere Parameter zugeordnet werden, wobei zwei Blockvariablen nur dann in einer gemeinsamen Variable
implementiert werden, wenn eine oder mehrere der folgenden
Zusatzbedingungen erfüllt ist:
• Den Blockvariablen wurde derselbe Datentyp zugeordnet
· Den Blockvariablen wurden miteinander verträgliche Maßeinheiten zugeordnet
• Die Namen von Blockvariablen werden mittels Erzeugungsvorschriften bestimmt, wobei nur solche Blockvariablen zusammengefasst werden, deren Namen mit der gleichen Erzeugungsvorschrift bestimmt wurde.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch
gekennzeichnet, dass mindestens eine Blockvariable anhand von gerichteten Verbindungen zwischen Blöcken automatisch erzeugt wird, wobei für den Fall, dass ein erster Block mit einem zweiten Block und der zweite Block mit einem dritten Block verbunden ist, eine Blockvariable des ersten Blocks für die von dem ersten Block ausgehende Verbindung erzeugt wird und eine Blockvariable des zweiten Blocks für die von dem zweiten Block ausgehende Verbindung erzeugt wird, wobei die zwei Blockvariablen dann als eine gemeinsame Variable in dem Quellcode implementiert werden, wenn der erste Block und der zweite Block in der gleichen Region liegen.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch
gekennzeichnet, dass das Blockdiagramm einen oder mehrere
Definitionsblöcke umfasst, welche eine Region definieren wobei Blöcke, welche nicht in einer von einem Definitionsblock aufgespannten Region liegen, einer zusätzlichen Region zugeordnet werden, so dass jeder Block des Blockdiagramms in einer Region liegt und/oder dass eine Trennungsregion definiert ist, wobei die Blockvariablen von Blöcken, die in der Trennungsregion liegen, immer als getrennte Variablen im Quellcode implementiert sind .
13. Verfahren zum Konfigurieren eines Steuergeräts, wobei das Steuergerät mindestens eine Recheneinheit umfasst und vorzugsweise mindestens einen Sensor und/oder mindestens einen Aktor aufweist, um Daten eines physikalischen Prozesses zu erfassen und/oder auf diesen einzuwirken, das Verfahren umfassend die Schritte
a. Einlesen eines Blockdiagramms,
b. Erzeugen eines Quellcodes mit einem Verfahren nach einem der vorhergehenden Ansprüche,
c. Kompilieren des Quellcodes für die Recheneinheit, so dass ein ausführbarer Code erzeugt wird,
d . Übertragen des ausführbaren Code auf das Steuergerät, und e. Hinterlegen des ausführbaren Codes auf einem nichtflüchtigen
Speicher des Steuergeräts und/oder Ausführen des ausführbaren Codes durch die Recheneinheit des Steuergeräts.
14. Computerprogrammprodukt mit einem computerlesbaren Speichermedium, auf dem Befehle eingebettet sind, die, wenn sie von einem
Prozessor ausgeführt werden, bewirken, dass der Prozessor dazu eingerichtet ist, ein Verfahren gemäß einem der vorhergehenden
Ansprüche auszuführen.
15. Computersystem umfassend eine Mensch-Maschine-Schnittstelle, einen nichtflüchtigen Speicher und einen Prozessor, wobei der Prozessor dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 13 auszuführen.
EP18737311.3A 2017-07-31 2018-07-12 Verfahren zur erzeugung von quellcode Active EP3568757B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP17183987.1A EP3438817A1 (de) 2017-07-31 2017-07-31 Verfahren zur erzeugung von quellcode
PCT/EP2018/068986 WO2019025155A1 (de) 2017-07-31 2018-07-12 Verfahren zur erzeugung von quellcode

Publications (2)

Publication Number Publication Date
EP3568757A1 true EP3568757A1 (de) 2019-11-20
EP3568757B1 EP3568757B1 (de) 2022-09-07

Family

ID=59506100

Family Applications (2)

Application Number Title Priority Date Filing Date
EP17183987.1A Withdrawn EP3438817A1 (de) 2017-07-31 2017-07-31 Verfahren zur erzeugung von quellcode
EP18737311.3A Active EP3568757B1 (de) 2017-07-31 2018-07-12 Verfahren zur erzeugung von quellcode

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP17183987.1A Withdrawn EP3438817A1 (de) 2017-07-31 2017-07-31 Verfahren zur erzeugung von quellcode

Country Status (6)

Country Link
US (1) US10884715B2 (de)
EP (2) EP3438817A1 (de)
JP (1) JP6861844B2 (de)
CN (1) CN110506256B (de)
DE (1) DE102018116911A1 (de)
WO (1) WO2019025155A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10860298B2 (en) * 2018-03-21 2020-12-08 Dspace Digital Signal Processing And Control Engineering Gmbh Method and system for editing a block diagram model
CN111444618B (zh) * 2020-03-30 2023-06-30 北京润科通用技术有限公司 一种基于变量字典的仿真方法及装置
CN112783505B (zh) * 2021-01-28 2023-07-18 东北大学 一种用于源代码的函数智能重命名方法
DE102022116011A1 (de) * 2021-09-10 2023-03-16 Dspace Gmbh Verfahren zur Erzeugung von Quellcode
CN116820419A (zh) 2022-03-22 2023-09-29 瑞昱半导体股份有限公司 源代码校验方法及非暂态计算机可读存储介质装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8196056B2 (en) * 2001-07-24 2012-06-05 The Mathworks, Inc. Handling parameters in block diagram modeling
US7493595B2 (en) * 2003-12-19 2009-02-17 The United States Of America As Represented By The Secretary Of The Navy Multiple-user graphical programming and analysis environment
US7650574B2 (en) * 2004-05-11 2010-01-19 National Instruments Corporation Visually indicating problems found during programmatic analysis of a graphical program
US20060136181A1 (en) * 2004-12-22 2006-06-22 John Masse Method and system for optimising at least one parameter characteristic of a physical system that is to be subjected to variable external conditions
US7703027B2 (en) * 2005-01-13 2010-04-20 National Instruments Corporation Merging graphical programs
US7934194B2 (en) * 2006-10-17 2011-04-26 The Mathworks, Inc. User-defined hierarchies of user-defined classes of graphical objects in a graphical modeling environment
US8448155B2 (en) * 2009-06-01 2013-05-21 National Instruments Corporation Automatically creating parallel iterative program code in a graphical data flow program
US8667474B2 (en) * 2009-06-19 2014-03-04 Microsoft Corporation Generation of parallel code representations
US8555130B2 (en) * 2011-10-04 2013-10-08 Cleversafe, Inc. Storing encoded data slices in a dispersed storage unit
CN102426550B (zh) * 2011-10-26 2014-05-14 中国信息安全测评中心 源代码解析方法和系统
US9081900B2 (en) * 2012-10-15 2015-07-14 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for mining temporal requirements from block diagram models of control systems
CN104375875B (zh) * 2013-08-15 2017-08-25 国际商业机器公司 用于应用程序的编译优化的方法以及编译器

Also Published As

Publication number Publication date
EP3438817A1 (de) 2019-02-06
US10884715B2 (en) 2021-01-05
DE102018116911A1 (de) 2019-01-31
CN110506256B (zh) 2023-09-01
JP6861844B2 (ja) 2021-04-21
US20200050434A1 (en) 2020-02-13
CN110506256A (zh) 2019-11-26
JP2020529053A (ja) 2020-10-01
EP3568757B1 (de) 2022-09-07
WO2019025155A1 (de) 2019-02-07

Similar Documents

Publication Publication Date Title
EP3568757B1 (de) Verfahren zur erzeugung von quellcode
DE102005026040A1 (de) Parametrierung eines Simulations-Arbeitsmodells
EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
WO2007020231A2 (de) System für den maschinengestützten entwurf technischer vorrichtungen
DE19814422A1 (de) System zur Lösung eines Randbedingungsproblems und Aufbau eines derartigen Systems
WO2021058223A1 (de) Verfahren zur effizienten, simulativen applikation automatisierter fahrfunktionen
EP3451202B1 (de) Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät
DE102019124018A1 (de) Verfahren zum Optimieren von Tests von Regelsystemen für automatisierte Fahrdynamiksysteme
DE102010042288A1 (de) Vorrichtung und Verfahren zum maschinellen Erstellen eines Prozessdiagramms
DE102019134053A1 (de) Verfahren zur kontinuierlichen Absicherung im Fahrversuch applizierter automatisierter Fahrfunktionen
EP3629151A1 (de) Verfahren zum ändern von modellen für die erzeugung von quellcode
DE102020124080A1 (de) Verfahren zur inkrementellen Codegenerierung
DE10324594A1 (de) Verfahren zum Bereitstellen einer verbesserten Simulationsfähigkeit eines dynamischen Systems außerhalb der ursprünglichen Modellierungsumgebung
DE102020123506A1 (de) Verfahren zur Erzeugung von Quellcode mit servicebasierter Kommunikation
DE102010047954A1 (de) Formelle offline-Verifikation ausführbarer Modelle
EP2711794B1 (de) Verfahren zur zeitweiligen Separierung von Objektdaten von Entwurfsmodellen
DE10325513B4 (de) Verfahren und Vorrichtung zum Erstellen eines Verhaltensaspekts einer Schaltung zur formalen Verifikation
EP3001318A1 (de) Bestimmung von Signalen für Readback aus FPGA
EP3716058A1 (de) Verfahren zum ansteuern eines geräts mit einem neuen programmcode
EP4276600A1 (de) Verfahren zur erzeugung von quellcode
DE102004039884A1 (de) Verfahren und System zur Beschreibung und Ausführung automatischer Tests
WO2022083940A1 (de) Verfahren und konfigurationssystem zum konfigurieren einer steuereinrichtung für ein technisches system
DE102010047957A1 (de) Formelle online-Verifikation ausführbarer Modelle
EP4273732A1 (de) Verfahren und vorrichtung zur validierung von erzeugnisspezifikationen für qualitätsgeprüfte erzeugnisse
EP4148557A1 (de) Verfahren zur erzeugung von quellcode

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20190816

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200430

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DSPACE GMBH

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20220601

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: AT

Ref legal event code: REF

Ref document number: 1517631

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220915

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502018010588

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20220907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221207

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20221208

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230109

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230107

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502018010588

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230525

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

26N No opposition filed

Effective date: 20230608

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20230719

Year of fee payment: 6

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20230731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230712

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20230712

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230712

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230731

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230712

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220907

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230731

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20230731