Computer mounting method for processing unsupported signal system, computer mounting method for generating control program, data processing device, computer program product and data carrier

Abstract

To provide a method, a device and a program for improving workability of a signal system which is unsupported in a graphic control model.SOLUTION: A data memory object 20 of definition database (DDT) specifies a globally reachable memory area for a graphic control model 12, thereby the graphic control model transfers a signal between two blocks 14 and 16 which are coupled to each other through a signal line, and can store specification having at least one identifier for a data type variable corresponding to an unsupported signal system in definition database, and the data memory object is used as a representative for the variable through an identifier when a control program for a target platform is generated.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to a computer-implemented method for handling signaling methods not supported in a graphical control model of a development platform such that a control program for a target platform can, and preferably is, generated from the graphical control model of the development platform.

[0002] The invention also relates to a method for configuring a target platform designed as a control device, in which a control program for the target platform is generated from a graphic control model loaded according to the method described above.

[0003] The invention also relates to an apparatus for processing data, comprising means for carrying out the method described above.

[0004] Furthermore, the invention relates to a computer program product comprising instructions that, when the program is executed by a computer, cause the computer to carry out the method described above.

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

[0006] Methods for computer-assisted generation of control programs from graphic control models are known from the prior art and belong to the underlying functionality of development environments. In particular, programs for control systems, e.g., control devices, can be created in this way.

[0007] Graphical control models often exist in the form of block circuit diagrams, which are used to model and display, for example, the mathematical functionality of a control algorithm. Using a graphic control model, the behavior of a process, a controller, and / or generally, a control device can first be simulated and the presence of desired characteristics can be verified. The block diagrams forming the model typically include multiple blocks connected via signal lines, which perform operations such as calculations, e.g., a block can calculate an output signal from multiple input signals. Signals of different signaling types can be transmitted between blocks via multiple signal lines or by using globally accessible memory areas for the graphic control model. Graphical control models support many signaling types, including scalars and matrices. However, a given block does not support all possible signaling types. Furthermore, a given signaling type may not be supported at all by the graphic control model.

[0008] Typically, block diagrams are executed cyclically, where all blocks are permanently stored in memory and each block is executed once per time step. In particular, a block may apply one or more operations to input signals from the last time step to generate an output signal for the current time step. Correspondingly, the usual behavior associated with control programs, such as the lifetime evolution of control program variables, is not necessarily easily transferable to a graphic control model.

[0009] In addition to periodically executed submodels for describing the behavior of the control device in a nearly time-continuous manner, the graphic control model can also include submodels for describing discrete behavior in which multiple states and transition conditions are defined.

[0010] The method for generating a control program from a graphical control model is also called a code generator. It is a computer program that converts a graphical control model into source code for a selected target platform, i.e., a control program. In contrast to the graphical control model, the control program exists in a completely textual form and contains instructions for execution on the target platform. Thus, the code generator ensures a reliable and error-free implementation of the abstract functional description (graphical control model) in a program for the target platform (control system). Signals of different signaling types occurring in the graphical control model are implemented in the control program by variables of different data types.

[0011] The usual procedure for code generation is to create a variable in the source code for each output of a block. However, this usually has the disadvantage of initially creating more variables than are actually needed. Subsequent optimization makes it possible to reduce the number of variables or, in general, reduce the code size. For example, EP-A-2 418 577 discloses converting a block diagram into an intermediate representation and applying at least one optimization to this intermediate representation to generate an optimized intermediate representation. To generate a further optimized intermediate representation, numerous further optimizations known per se from compiler construction can be applied in succession. A control program, preferably in C code, is then generated from the optimized intermediate representation. Methods for generating control programs are described, for example, in DE-A-10 2020 124 080 or EP-A-2 916 183.

[0012] Control systems, such as control devices, especially in the automotive sector, must not only comply with technical requirements but also meet certain regulatory standards. AUTOSAR (AUTomotive Open System ARchitecture) is a global development partnership between automotive manufacturers, suppliers, and software companies, aiming to develop and establish a standard software architecture for electronic control devices. To achieve the goals of scalability to different vehicle and platform variants and software portability, standards and specifications that must be met by the control programs of control devices have been defined and continue to be defined. For example, system configuration descriptions between various control devices contain agreed-upon information, such as the definition of specific data types. Therefore, it is possible that a specific data type is specified at the control program level, but in the graphic control model, there is no corresponding signaling method supported by the graphic control model for this data type.

[0013] Furthermore, graphic control models typically allow the integration of so-called custom code blocks, i.e., blocks that perform operations specifically programmed by the user. Therefore, a user may use a specific data type within a custom code block or a corresponding code block in a control program, for which no corresponding signaling scheme supported by the graphic control model exists. Nevertheless, generating a control program from a graphic control model requires the processing of the unsupported signaling scheme. Summary of the Invention [Problem to be solved by the invention]

[0014] Based on this, it is an object of the present invention to provide a means for improving the workability of unsupported signaling methods in a graphic control model, and a means for simplifying the generation of a control program from a graphic control model. [Means for solving the problem]

[0015] This problem is solved by the subject matter of the independent claims. Preferred developments are revealed in the dependent claims.

[0016] In summary, the present invention provides a computer-implemented method for processing signaling methods unsupported in a graphic control model of a development platform such that a control program for a target platform can be, and preferably is, generated from the graphic control model of the development platform, the graphic control model including a block diagram having a plurality of blocks and designed to transfer signals of different signaling methods between at least two blocks, the signaling methods being implemented by different data types in the generated control program, the graphic control model not supporting all data types required in the control program, the graphic control model referencing a definition database storing information for the graphic control model, the definition database including at least one data memory object, the data memory object specifying a globally reachable memory area for the graphic control model, whereby the graphic control model is designed to transfer signals between two blocks that are not coupled via signal lines. The method is characterized in that the definition database can store specifications having at least one identifier for variables of a data type corresponding to the unsupported signaling method, and the data memory object is used as a representative for the variable via the identifier during generation of the control program for the target platform.

[0017] In the case of the method according to the invention, a control program for a target platform is preferably generated, which in other words is preferably a computer-implemented method for generating a control program for a target platform from a graphical control model of a development platform.

[0018] That is, the method according to the present invention uses data memory objects present in the definition database that identify globally accessible memory areas for the graphic control model, as well as identifiers that can also be stored in the definition database for variables in the control program that have data types for which no corresponding signaling method exists in the graphic control model, to use the data memory objects as representatives for the variables via their identifiers during the generation of the control program. At the level of the graphic control model, the data memory objects used as representatives for the variables during the generation of the control program are passed to those blocks that process unsupported signaling methods, so to speak, from the outside, i.e., from the globally accessible memory area. In other words, this ensures that signals whose signaling method is not supported by or not allowed in the graphic control model are nevertheless used in the generated control program at the correct location. In this example, the unsupported signaling methods include not only signaling methods not supported by the graphic control model, but also signaling methods not supported by the code generator for generating the control program.

[0019] In other words, in this way, the modeling of the interface to the block in which signals are processed in unsupported signaling formats is extended for unsupported signaling formats, thereby improving the workability of unsupported signaling formats at the level of the graphic control model and simplifying the generation of control programs from the graphic control model.

[0020] In particular, this method allows a control program, i.e., source code, to be correctly generated starting from a graphic control model even if the signaling method is not supported by the graphic control model and / or the code generator. For the generation of the control program, it is not necessary to transmit a definitive description of the unsupported signaling method to the code generator. Instead, for automated and correct code generation, it is sufficient that the definition database contains a data memory object and that the identifier stored in the definition database in the specification is transmitted to the code generator. During the generation of the control program, the data memory object is used as a representative for variables of a data type corresponding to the unsupported signaling method, thereby enabling bypassing of correspondingly undisplayable signal parts not supported by the graphic control model and / or the code generator. In other words, this method allows a correct control program to be generated despite incomplete information about the unsupported signaling method.

[0021] The block diagram of the graphic control model includes several blocks and is designed to transfer signals between at least two blocks. To this end, a first block outputs an output signal, which, depending on the definition, may consist of one value or several related values, and a second block receives this output signal as its input signal and takes this signal into account when determining its output signal. These signals may be in different formats and may contain and / or transmit structured or unstructured data types. For example, signals may be designed as matrices or as scalars.

[0022] A block in a block diagram may be an atomic unit, i.e., from the perspective of the surrounding blocks, may form a unit to which all input signals must be applied at the start of a calculation step and all output signals are present at the end of the calculation step.

[0023] When a block diagram is hierarchical, multiple blocks in a lower level can describe the structure of a block in a higher level. A hierarchical or composite block can contain multiple blocks in lower levels, even if they are atomic units.

[0024] Signals can be transferred via signal lines connecting the blocks (although this is not required). Signals between blocks can also be transmitted using a globally reachable memory area for the graphic control model, specified by a data memory object. Preferably, the globally reachable memory area is a memory area defined by a DataStore memory block in the graphic control model. The memory area specified by the data memory object is writable by a DataStore write block of the graphic control model and / or readable by a DataStore read block of the graphic control model. In this way, signals can be transferred between blocks even if no signal lines exist between the blocks.

[0025] Because a DataStore memory block has a name that hierarchically uniquely identifies it in the hierarchy below, the hierarchical structure of the graphic control model and the location of the DataStore memory block within the graphic control model relative to the location of the DataStore write block and / or DataStore read block determine the access rights to the memory region. If a DataStore memory block exists at the highest hierarchical level within a graphic control model, all DataStore write blocks and / or DataStore read blocks occurring within the graphic control model that name that DataStore memory block have access rights to the memory region identified by the DataStore memory block. In contrast, DataStore write blocks and / or DataStore read blocks that name DataStore memory blocks that do not exist at the same level or higher in the hierarchy of the graphic control model are invalid. "Globally reachable memory region" specifically means in this example that the memory region identified by a data memory object is reachable to blocks in which signals of unsupported signaling types are processed. Thus, the term "globally accessible memory area" does not necessarily imply that the memory area applies to the highest hierarchical level of the graphics control model, but rather that the memory area applies to at least the hierarchical level necessary for functionality.

[0026] The graphic control model references a definition database in which information for the graphic control model is stored. In particular, the definition database also includes data memory objects for identifying globally accessible memory areas used as representatives for variables of data types corresponding to unsupported signaling methods. In particular, the definition database is designed to be able to store specifications including identifiers for variables of data types corresponding to at least unsupported signaling methods. This definition database can have, for example, a tree structure.

[0027] When a control program is derived from a graphic control model, the control program is preferably generated in a multi-stage process, where signals of different signaling types occurring in the graphic control model correspond to variables of different data types in the control program. This process preferably uses information stored in a definition database, particularly preferably identifiers defined in the specification. In this example, signals occurring in the graphic control model are referred to as signals of unsupported signaling types, and variables in the control program have a data type in the graphic control model for which no signaling types supported by the graphic control model exist. In this example, the term "unsupported signaling types" should be understood to mean signals for which the code generator does not recognize the formation rules and which are therefore not supported by the code generator. For example, unsupported signaling types may be variable-width bus array signals (English: "Arrays of Buses"). For unsupported signaling types, no formation rules are stored for generating a control program, as for correspondingly supported signaling types. However, it is possible to bypass unknown or unrepresentable signal parts by explicitly using data memory objects stored in the definition database, which are used as representatives for variables of data types corresponding to unsupported signaling types. Specifically, the definition database includes a data memory object for identifying a globally reachable memory region, which data memory object is used as a representative for a variable of a data type corresponding to an unsupported signaling method.

[0028] The control program (also called source code) is preferably entirely in text form and preferably contains instructions for the control device.

[0029] That is, this method has the advantage that a user can receive a representation of an object that is not clearly understood by the user, i.e., a representation of a signal of an unsupported signaling type, and use this representation for further specification and modeling as desired. Furthermore, this method makes it possible to generate correct source code through the representation without specific knowledge of the unsupported signaling type. In particular, this makes it possible to generate correct source code for a graphic control model in which a signal of an unsupported signaling type is received (a consuming block) and / or an unsupported signaling type is output (a specific block). When generating a control program, a data memory object that specifies a globally accessible memory area for the graphic control model is used as a representative for variables, thereby benefiting from the hierarchical access rights to the memory area specified by the data memory object, as described above, thereby generating correct source code without a final description of the unsupported signaling type. In other words, variables having data types corresponding to the unsupported signaling type are automatically used in parts of the control program corresponding to each block.

[0030] According to a preferred further development of the invention, it is envisaged that the specifications can be stored in data elements in a definition database, and that data memory objects are used as representatives for the data elements in the graphic control model. The data elements in the definition database are particularly easy to handle and / or access using the specifications. At the level of the graphic control model, the data memory objects act like placeholders for the data elements.

[0031] In this context, according to a further development of the invention, it is envisaged that the specification contains additional information relating to access to and / or transfer of data elements in the graphic control model, for example, the specification may define that a particular block in the graphic control model has only read access to a data element, or that read and write access is allowed.

[0032] According to a further preferred embodiment of the invention, the specification preferably includes additional information specifying the data types of supported signaling schemes according to which unsupported signaling schemes behave. In this example, the supported signaling schemes include not only signaling schemes supported by the graphic control model, but also signaling schemes supported by the code generator and for which corresponding formation rules exist. In other words, the specification preferably stores not only identifiers of variables of data types corresponding to unsupported signaling schemes, but also rules on how the unsupported signaling schemes behave. Preferably, behavior rules are stored in the specification that refer to the signaling schemes supported by the graphic control model and / or specify their data types. For example, in addition to the identifiers, the specification can store information on whether the variable behaves as a scalar, vector, matrix, or bus signal. This simplifies the generation of control programs, since even if the graphic control model includes unsupported signaling schemes, the control program can be generated from the graphic control model using the known formation rules for such supported signaling schemes.

[0033] According to a further preferred embodiment of the present invention, the specification includes additional information specifying the data types of the supported signaling formats contained in the unsupported signaling formats. Preferably, the specification includes additional information specifying the data types of the components of the unsupported signaling formats. In particular, if the variable is a structured data type (also called a combination, English: structure), the components of the structured data type can be advantageously represented in the specification. In this example, a structured data type is understood to mean a grouping of multiple related data, where the data do not necessarily have to be of the same data type, and in this case, each individual data can be referred to as a component (English: member) of the structured data type. For example, the specification can include additional information that the variable is a structured data type and has at least one component whose structured data type is a vector. Preferably, the specification can also include additional information specifying the data types of the supported signaling formats according to which the components of the structured data type behave. In this way, it is also possible to process signaling formats in a graphic control model, where part of the data contained in the signal indicates an unsupported signaling format. This also makes it possible to generate a control program based on such a graphic control model even if only some of the data types are known at the time of code generation. In particular, known formation rules can be used during program generation depending on the supported signaling methods.

[0034] According to a preferred embodiment of the invention, a method for processing signaling methods not supported in a graphic control model is provided, which comprises a step of storing specifications in a definition database, preferably in a data element. This step can preferably be initiated by a user. Alternatively, this step can be automated via an interface specification or a tool chain.

[0035] According to a further preferred development of the invention, it is envisaged that a method for processing signalling methods not supported in a graphic control model, particularly preferably a method for generating a control program for a target platform from a graphic control model of a development platform, comprises a step of calling a specification during the generation of the control program. In this way, the identifiers of the variables and preferably additional information for the variables can be accessed, and a data memory object can be used as a representative for the variables via the identifiers.

[0036] As already mentioned, at the level of the graphic control model, data memory objects used as representatives for variables during the generation of the control program are passed to those blocks in which unsupported signaling methods are processed as if from the outside, i.e. from a globally accessible memory area. In this respect and with regard to the generated control program, according to a preferred development of the invention, the block diagram contains at least one user-specific code block with a signaling method defined by the user and not supported in the graphic control model and / or at least one function block with an external function with an unsupported signaling method, wherein during the generation of the control program for the target platform, the control program, by referring to the data memory object: a) the variables identified via the specification are used by identifier in the part of the control program that corresponds to the user-specific code block, and / or b) It is assumed that the function block is generated in such a form that when a portion of the control program corresponding to the function block is called, the variables specified through the specification are passed as arguments.

[0037] That is to say, particularly advantageously in connection with variant a), in which the graphic control model contains user-specific code blocks (also called custom code blocks) in which unsupported signaling methods are used, the control program is generated in such a way that, in the parts of the control program corresponding to the user-specific code blocks, variables are used directly identifier by identifier, which results in leaner code being generated, since unnecessary function calls are avoided.

[0038] In the context of variant b), in which external functions are integrated into a non-supported signaling system via function blocks in a graphic control model, the control program is preferably generated in such a way that, when calling the part of the control program corresponding to the function block, the variables specified in the specification are passed as arguments. This also ensures that the variables are present in the generated control program in the correct context, i.e., at the time of the function call. The arguments represent the passed values ​​that are indicated at the time of the function call. This ensures that, when the function is called, a list of arguments that matches the function signature is indicated and passed to the function.

[0039] According to a further preferred development of the invention, the block diagram is hierarchically structured and comprises at least a first subsystem and a second subsystem, where the first subsystem is an outer subsystem such that the second subsystem is contained by the first subsystem, where the second subsystem comprises at least one code block in which an unsupported signaling method is processed, where the specification comprises additional information regarding the transfer of variables represented by data memory objects, where it is envisaged that when generating a control program for the target platform, the control program is generated in such a way that the variables represented by the data memory objects are hierarchically inherited as function parameters from the part of the control program corresponding to the first subsystem to the part of the control program corresponding to the second subsystem.

[0040] When a graphic control model is hierarchically structured, blocks at a lower level (the second subsystem in this example) can describe the structure of blocks at a higher level (the first subsystem in this example). Subsystems can have additional characteristics, such as implementation in separate functions and / or triggering their execution via dedicated signals. Special blocks may be located within a subsystem to further specify its characteristics. In particular, the specification includes additional information regarding the transfer of variables represented by data memory objects from the first subsystem to the second subsystem, thereby enabling inheritance of variables as function parameters at the control program level. During inheritance, variables and functions of base classes are reused and possibly extended in derived classes. This allows for lean code and resource conservation through the DRY (Don't Repeat Yourself) principle and object-oriented programming.

[0041] According to a further preferred embodiment of the present invention, the block diagram includes at least one block into which signals of an unsupported signaling type are read and / or written, and it is assumed that when a control program for a target platform is generated, the control program is generated in such a manner that read and / or write access to variables of the data type specified in the specification is achieved by referencing a data memory object. At the level of the graphic control model, writing to signals of an unsupported signaling type can be enabled, for example, by importing signals of an unsupported signaling type from the outside of the system using an Input port block and writing them inside the system using a DataStore write block that writes them to a globally accessible memory area specified by a data memory object. The DataStore write block is an example of an identified block. Similarly, signals of an unsupported signaling type can be read via a DataStore read block that reads from a globally accessible memory area specified by a data memory object and transferred to a destination outside the system using an Output port block. The DataStore read block is an example of a consuming block. In this manner, it is possible to read and / or write signals, i.e. consume and identify, at the level of the graphic control model without knowledge of the specific format of the unsupported signaling format, and to forward the signals to further blocks. At the level of the control program, this is preferably implemented by referencing a data memory object within the framework of an access function (also called access method) to perform a corresponding read or write access to a variable identified via a specification whose data type corresponds to the unsupported signaling format, without therefore requiring specific and detailed knowledge of the unsupported signaling format.Preferably, the control programs are generated in such a way that write accesses are implemented as change methods (also called setters) and / or read accesses are implemented as query methods (also called getters).

[0042] According to a further development of the invention, the block diagram comprises at least one first block whose output value is an unsupported signalling method and is passed as an index definition input value to a second block implementing dynamic selection and / or dynamic allocation, wherein the definition database comprises a first data memory object and a second data memory object, wherein, during the generation of the control program, the first data memory object is used as a representative for a first variable to be processed in the part of the control program corresponding to the first block, and wherein, during the generation of the control program, the second data memory object is used as a representative for a second variable to be processed in the part of the control program corresponding to the second block, wherein the specification of the second data memory object comprises additional information such that the unsupported signalling method processed in the second block behaves like an associative data type comprising a plurality of elements, said additional information comprising access rules for accessing the elements, wherein, during the generation of the control program for the target platform, the control program: - in a portion of the control program corresponding to a first block, a read access is made to a first variable represented by a first data memory object, and in a portion of the control program corresponding to a second block, a dynamic read and / or write access is made to elements of a second variable, which is designed as an associative data type and which is represented by a second data memory object; It is envisaged that a first variable in the part of the control program corresponding to the first block is generated in such a form that it is a key allowing access to an element of a second variable, designed as an associative data type, to be processed in the part of the control program corresponding to the second block.

[0043] That is, in a graphic control model in which a function output, i.e., an output of a first block, returns a pointer or index that drives an index input for dynamic selection and / or dynamic allocation of a second block, supported signaling methods are extracted from signals of unsupported signaling methods by dynamic element access in terms of modeling techniques related to dynamic selection and / or dynamic allocation. The access rules stored in the specification of the second data memory object for unsupported signaling methods processed in the second block can be stored in the specification as a function or method. This stored function or method is then preferably used when generating the control program.

[0044] An associative data type is understood in this example to mean a grouping of several related data, which are preferably structured in the same way. The individual data are called elements of the associative data type. Access to the elements of the associative data type can be done numerically via the index of the corresponding element or via a key for addressing the element. The key can be of any data type (such as a string), but must uniquely identify the element.

[0045] In this context, according to a further preferred development of the invention, it is assumed that the associative data type is an associative array, and that array element access can be performed using a key. In this case, the access rules stored in the specification of the second data memory object are, i.e., preferably, methods for performing array element access. In the case of associative arrays, unlike conventional arrays, the keys may also not be numeric, i.e., may be, for example, strings.

[0046] According to an alternative preferred development of the invention, it is assumed in this context that an associative data type identifies a part of the main memory of the target platform and that a key indicates an address to this main memory. In other words, a key is a pointer that caches a memory address and refers to the main memory location identified by this address. Data such as variables, objects or program instructions may be stored in the main memory. Retrieval of data stored there is called dereferencing.

[0047] In relation to a first block of the block diagram, whose output value is an unsupported signaling method, it is assumed that an untyped pointer is declared at the level of the control program, preferably in the part of the control program corresponding to the first block. An untyped pointer (English: Pointer to void) is a pointer for which the data type of the main memory address to which it refers is not declared. An untyped pointer cannot be dereferenced as is, i.e., it is not possible to directly reach the data stored at that address in main memory. For dereferencing, the untyped pointer is preferably first converted into a typed pointer by type conversion. Accordingly, in this case, it is assumed that the access rules stored in the specification of the second data memory object are preferably access rules for performing type conversion from an untyped pointer to a typed pointer, so that dynamic read and / or write access to addresses in the main memory of the target platform can be performed in the part of the control program corresponding to the second block.

[0048] According to a preferred development of the invention, the step of generating a control program for a target platform from a graphic control model of a development platform comprises the following steps: - generating an intermediate representation from the graphical control model; optimizing the generated intermediate representation; - generating a control program for the target platform by converting the optimized intermediate representation; wherein at least one of the steps includes invoking an identifier of a variable whose data type corresponds to an unsupported signaling method to use a data memory object as a representative for the variable.

[0049] Preferably, a method is provided for generating a control program for a target platform from a graphical control model of a development platform, wherein the step of generating the control program comprises the steps of converting the graphical control model into an intermediate representation, optimizing the intermediate representation, preferably continuously, and converting the optimized intermediate representation into a control program, wherein at least one of the steps is performed taking into account specifications stored in a definition database, whereby identifiers of variables are retrieved. Preferably, the identifiers are retrieved already during the generation of the intermediate representation from the graphical control model. In this way, more comprehensive information about the graphical control model is available.

[0050] Preferably, in the intermediate representation, blocks of the block diagram of the graphical control model are converted into instructions with a fixed execution order, so that the structure of the intermediate representation semantically maps to a textual programming language. The converting step can include substeps such as checking rules and adding additional code generation information. The use of data memory objects via identifiers as representatives for variables can occur essentially at any intermediate step of the conversion, and is preferably performed during each conversion step.

[0051] According to a further development of the invention, it is envisaged that the control program is generated in C code, which in this example is understood to mean a programming language based on C in terms of syntax and / or basic language structures. Such a language has, for example, semicolon-terminated instructions, brace-delimited code blocks, parenthesized parameters, and / or arithmetic and logical expressions defined in infix notation, some of which are also referred to as "bracket languages". Preferably, the C code in this example also includes code in the programming languages ​​C++, Handel-C and / or SA-C. More preferably, it should be understood to mean C code in a standardized format such as ANSI C, ANSI C++, ISO C, ISO C++, Standard C, and / or Standard C++ as published by the American National Standards Institute (ANSI), ISO / IEC JTC1 / SC22 / WG14 of the International Organization for Standardization (ISO), ISO / IEC JTC1 / SC22 / WG21 of "The C++ Standards Committee-ISOCPP" of the International Organization for Standardization (ISO), and / or the International Electrotechnical Commission (IEC).

[0052] The present invention further relates to a method for configuring a target platform designed as a control device, wherein the target platform comprises at least one computing unit and preferably has at least one sensor and / or actuator for capturing data of and / or acting on a physical process, and comprises the following steps: - loading a graphical control model of a development platform; - generating a control program for the target platform from the loaded graphic control model according to the method described above; - generating executable code for a computing unit of the target platform by compiling the generated control program; - transferring the generated executable code to the target platform, and / or storing the generated executable code in a non-volatile memory of the target platform, and / or executing the generated executable code by a computing unit of the target platform.

[0053] The control device preferably includes an interface for connecting to a development platform. More preferably, the control device includes a microcontroller having an architecture different from the processor of the development platform, a working memory, and a non-volatile memory. More preferably, the control device may also include two or more computing units.

[0054] Furthermore, the invention relates to an apparatus for processing data, including means for carrying out the above-mentioned computer-implemented method for generating a control program.

[0055] Particularly preferably, the device comprises a definition database for storing information for the graphic control model, in particular for storing data memory objects, and for storing specifications with at least one identifier and possibly additional information. The definition database may have a tree structure and / or may be stored in the memory of the device as a simple file. Alternatively, it may be envisaged that the specifications and additional information are stored in a dedicated database system.

[0056] Furthermore, the invention relates to a computer program product comprising instructions that, when the program is executed by a computer, cause the computer to carry out the above-mentioned computer-implemented method for generating a control program.

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

[0058] Preferably, the instructions are embedded on a computer readable data carrier, which when executed by a processor of a computer cause the processor to carry out the method for generating a control program.

[0059] The technical advantages and effects of the method for configuring a target platform designed as a control device, the apparatus for data processing, the computer program product and the computer-readable data carrier will be apparent to those skilled in the art from the description of the method for generating a control program as well as the examples described below.

[0060] The invention will now be explained in more detail with reference to the drawings, in which: The illustrated embodiments are highly schematic, i.e., the distances and lateral and longitudinal dimensions are not necessarily to scale and, unless expressly stated, do not have any derivable geometric relationship to one another. [Brief explanation of the drawings]

[0061] [Figure 1] 1 is a schematic diagram illustrating an apparatus for data processing according to a preferred embodiment of the present invention; [Figure 2] FIG. 2 is a schematic diagram showing software components installed on the device according to FIG. 1; [Figure 3] FIG. 1 is a schematic diagram illustrating a graphic control model in which a computer-implemented method for processing signaling methods not supported in the graphic control model so that a control program can be generated is illustrated, according to a preferred embodiment of the present invention. [Figure 4] FIG. 1 is a schematic diagram illustrating a graphic control model in which a computer-implemented method for processing signaling methods not supported in the graphic control model so that a control program can be generated is illustrated, according to a preferred embodiment of the present invention. [Figure 5] FIG. 5 is a schematic diagram illustrating a definition database for the graphic control model shown in FIGS. 3 and 4. [Figure 6a]FIG. 1 is a schematic diagram showing a hierarchically structured graphic control model. [Figure 6b] FIG. 1 is a schematic diagram showing a hierarchically structured graphic control model. [Figure 7] FIG. 10 is a schematic diagram illustrating a further graphical control model for illustrating a computer-implemented method for handling unsupported signaling methods according to a preferred embodiment of the present invention. [Figure 8] FIG. 10 is a schematic diagram illustrating a further graphical control model for illustrating a computer-implemented method for handling unsupported signaling methods according to a preferred embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0062] FIG. 1 shows a schematic diagram of an exemplary design of a data processing device 10, referred to in this example as a computer system PC. The computer system PC is configured to execute a method for generating a control program for a target platform ES from a development platform, i.e., a graphical control model of a computer system. The computer system PC has a processor CPU, which may be implemented in particular as a multi-core processor, a working memory RAM, and a bus controller BC. Preferably, the computer system PC is designed for direct manual operation by a user, with a monitor DIS connected via a graphics card GPU and a keyboard KEY and mouse MOU connected via a human-machine interface HMI. In principle, the human-machine interface of the computer system PC may be configured as a touch interface. Furthermore, the computer system PC includes a non-volatile data memory HDD, which may be designed in particular as a hard disk and / or solid-state disk, as well as an interface NET, in particular a network interface. Via the interface NET, a control device ES, i.e., a target platform ES, may be connected. In principle, one or more arbitrary interfaces, in particular wired interfaces, may be present on the computer system PC and each available for connection to the control device ES. Expediently, a network interface according to the Ethernet standard can be used, but the interface NET can also be implemented wirelessly, in particular as a WLAN interface or according to standards such as Bluetooth.

[0063] The control device ES may be designed as a serial control device or as an evaluation board for the target platform ES and suitably includes an interface NET for connection to a computer system PC, a microcontroller MCR having an architecture different from the processor of the computer system PC, a working memory RAM and a non-volatile memory NVM.

[0064] 2 shows a schematic diagram of the software components preferably installed in the computer system PC, which use the mechanisms of the operating system OS, for example, to access the non-volatile memory HDD or to establish connections with external computers and / or control devices ES via the network interface NET.

[0065] The technical computing environment TCE allows the creation of models, in particular graphic control models 12, and the generation of control programs, also called source code, from the graphic control models 12. In the modeling environment MOD, preferably via a graphical user interface, the graphic control models 12 of a dynamic system can be created. Here, in particular, they can be block diagrams including a number of blocks 14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46, describing the temporal behavior and / or internal state of the dynamic system. At least some of these blocks 14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46 can be interconnected via signal lines, which represent directional connections for exchanging signals of different signaling types, which can be scalar or composite. Operations and / or calculation steps to be performed can be defined for these signals via these blocks 14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46. In particular, using globally reachable memory regions for the graphic control model 12, signals can be transferred between two blocks 14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46 that are not connected via signal lines. For this purpose, the definition database DDT includes data memory objects 20 that identify globally reachable memory regions.

[0066] The computing environment TCE can select blocks or modules from one or more libraries BIB for building a model. The scripting environment MAT allows commands to be entered interactively or via batch files to perform calculations or modify models. The computing environment TCE further includes a simulation environment SIM, which is configured to interpret or execute block diagrams to study the time behavior of a system. These calculations are preferably performed with high-precision floating-point numbers on one or more cores of the microprocessor CPU of the computer system PC.

[0067] From the created model, a source code can be generated, preferably in a programming language such as C, using a code generator PCG. In the generated source code, signaling methods are implemented using different data types, although in this case the graphic control model 12 does not support all data types required in the control program. To generate the source code, in this embodiment, a method for generating a control program for a target platform ES from the graphic control model 12 of the development platform is implemented. In this embodiment, additional information for the model 12 is stored in the definition database DDT, in particular a specification with at least one identifier 22 for variables of a data type corresponding to the unsupported signaling methods, and during the generation of the source code, a data memory object 20 is used as a representative for the variable via the identifier 22.

[0068] Furthermore, the definition database DDT may also store other additional information for the model 12, such as information for variables within blocks, also referred to as block variables. These block variables may be assigned a value range and / or scaling to support calculation of the model using fixed-point instructions. Desired characteristics of the source code, such as compliance with standards such as MISRA, may also be configured or stored in the definition database DDT. Each block variable may be assigned a predefined variable type and / or may have one or more desired characteristics configured, such as the allowability for optimizations such as variable merging.

[0069] The code generator PCG preferably evaluates the settings of the definition database DDT, in particular the stored identifiers 22, and uses the data memory objects 20 during source code generation via the identifiers 22 as representatives for variables of data types for which no corresponding signaling exists. The definition database DDT may have a tree structure or may be stored as simple files in the memory of the computer system; alternatively, it may be envisaged that the definition data is stored in a dedicated database system. The definition database may have a program interface and / or import / export functions.

[0070] The computer system PC in this example comprises a compiler COM and a linker LIN, which are expediently configured for generating binary files that can be executed on the control device ES and / or the computer system PC. In principle, several compilers, in particular cross-compilers for different target platforms, may be present in order to support control devices or evaluation boards ES with different processor architectures.

[0071] 3-5 illustrate the principle of a computer-implemented method for processing unsupported signaling methods in the graphic control model 12 so that a control program can be generated based on the exemplary graphic control model 12 and the exemplary definition database DDT. FIG. 3 shows the exemplary graphic control model 12, which in this example includes a user-specific code block 14 with an unsupported signaling method defined by the user and a function block 16 with an external function with the unsupported signaling method. In other words, within blocks 14 and 16, there is code whose content is not completely known. To extend the interface in the code for the unsupported signaling method, an object 18 with the unsupported signaling method should be passed from the outside as a function parameter. This is implemented as follows within the framework of this example and with reference to FIGS. 4 and 5.

[0072] 5, the definition database DDT includes a data memory object 20 that identifies a globally reachable memory region for the graphic control model 12, whereby the graphic control model 12 is designed to transfer signals between two blocks that are not coupled via signal lines (in this example, blocks 18 and 16 or blocks 18 and 14). The definition database DDT also stores a specification with at least one identifier 22 for a variable of a data type that corresponds to the unsupported signaling method, in this example the identifier "Blub."

[0073] 4, during the generation of a control program for a target platform, the data memory objects 20 are used as representatives for variables via the identifiers 22. In this way, at the level of the graphic control model 12, the data memory objects 20 used as representatives for variables during the generation of a control program are delivered from the outside, i.e. from a globally accessible memory area, to those blocks 14, 16 in which unsupported signaling methods are processed.

[0074] At the control program level, for a user-specific code block 14 and a function block 16 with external functions, the following exemplary source code is generated, which shows the use of a data memory object 20 via an identifier 22 (in this example "Blub") as a representative for a variable: Foo (int16_t In1, T_Blub* Blub) { ExternalFunktion(In1, Blub); / * Custom Code: output section * / { … Blub… } }

[0075] That is, when calling the part of the control program corresponding to the function block, the variables identified via the specification are passed as arguments (ExternalFunction(In1,Blub)), whereas in the part of the control program corresponding to the user-specific code block, the variables identified via the specification are used directly as identifiers (...Blub...).

[0076] 5, it is also apparent that the specification includes additional information 24 that specifies the data types of supported signaling according to which unsupported signaling behaves. In this example, it is specified that unsupported signaling behaves like a VectorOfStruct.

[0077] 6a) and 6b) schematically illustrate propagation across subsystem boundaries in a hierarchically structured graphic control model 12. The graphic control models 12 of FIGS. 6a) and 6b) are structured in essentially the same way and include multiple subsystems 26A, 26B, 26C, 26D, 26E, and 26F, where subsystem 26A is an outer subsystem relative to subsystems 26D, 26E, and 26F because subsystems 26D, 26E, and 26F are encompassed by subsystem 26A. Similarly, subsystem 26C is an outer subsystem relative to subsystem 26G.

[0078] In the example of Figure 6a), subsystems 26D and 26C have code blocks in which unsupported signaling is processed, and subsystem 26F has a user-specific code block 14 in which unsupported signaling is processed.

[0079] The specifications stored in the definition database DDT contain additional information regarding the transfer of the variables represented by the data memory objects (called identifier "pAdditional" in this example), so that when generating a control program for the target platform, the control program is generated in such a form that the variables represented by the data memory objects 20 are inherited as function parameters hierarchically from the part of the control program corresponding to the first subsystem 26A to the parts of the control program corresponding to the second subsystems 26D, 26E, 26F, and for the example of Figure 6a), the following code is generated: Root(OpaqueType* pAdditional) { A(pAdditional); / * nicht direkt markiert, Propagation * / B(); C(pAdditional); / * direkt markiert * / } A(OpaqueType* pAdditional) { D(pAdditional); / * direkt markiert * / E(); F(pAdditional); / * nicht direkt markiert, Propagation * / } C(OpaqueType* pAdditional) { G(); / * Keine Propagation * / }

[0080] For the example shown in FIG. 6b), where subsystem 26D has a code block where unsupported signaling is handled and subsystem 26F has a user-specific code block 14 where unsupported signaling is handled, the following code is generated based on the global memory area identified by data memory object 20, which exists on the hierarchical level of subsystem 26A: #include “OpaqueTypeVariables.h” Root() { / * Data Store Memory-Block innerhalb, kein Additional-Parameter * / A(&Additional); / * nicht direkt markiert, Propagation * / B(); C(); } A(OpaqueType* pAdditional) { D(pAdditional); / * direkt markiert * / E(); F(pAdditional); / * nicht direkt markiert, Propagation * / }

[0081] With reference to Figure 7, in a further embodiment, it will be made clear how a method for generating a control program handles unsupported signaling formats. Figure 7 shows a schematic representation of a further graphic control model 12, which in this example includes a block 28 from which signals of the unsupported signaling format are read and a block 30 to which signals of the unsupported signaling format are written. In this example, the definition database stores "FieldB" as an identifier for a variable of a data type corresponding to the unsupported signaling format.

[0082] At the level of the graphic control model 12, writing to a signal with an unsupported signaling type "MyVector" is possible by using an Input port block 32 to bring the signal with the unsupported signaling type into the system from the outside and writing it inside the system using a DataStore write block 34, which writes it to a globally reachable memory area specified by a data memory object 20, designated as a DataStore memory block. Read access is implemented in this example via a DataStore read block 36, which reads from the globally reachable memory area specified by the data memory object 20 and forwards the signal with the unsupported signaling type to a destination outside the system using an output port block 38. Figure 7 also shows that a block 40, where the unsupported signal is processed, can access the signal.

[0083] When generating a control program for a target platform, the control program is generated in such a way that read and write access to variables of the data type specified via the specification is provided by referencing the data memory object 20, in which case the following exemplary code is generated: void f_FieldCommunication(void) { dspace::targetlink::vectorOfStruct FieldB; Get_AdaptiveSwc_RP_ServiceB_FieldB_NoServiceDiscovery_S1(FieldB); compute(FieldB); Set_AdaptiveSwc_RP_ServiceB_FieldB_NoServiceDiscovery_S1(FieldB); }

[0084] That is, without specific, detailed knowledge of the unsupported signaling method "MyVector", write access in the source code is implemented as a setter to the variable "FieldB", and read access is implemented as a getter to the variable "FieldB".

[0085] In connection with Figure 8, in a further embodiment it will be made clear how a method for generating a control program handles unsupported signalling methods. Figure 8 shows schematically a further graphic control model 12, which in this example is structured as follows:

[0086] The block diagram includes a first block 42 whose output value 44a is an unsupported signaling scheme and is passed as an index-defined input value 44b to a second block 46 that implements dynamic selection and dynamic allocation. As can be seen from the two DataStore memory blocks 20a and 20b in FIG. 8, the definition database includes a first data memory object 20a and a second data memory object 20b. During control program generation, the first data memory object 20a is used as a representative for a first variable processed in the portion of the control program corresponding to the first block 42, and the second data memory object 20b is used as a representative for a second variable processed in the portion of the control program corresponding to the second block 46. In this example, the first variable has the identifier "RamBlockPtr." The specification of the second data memory object 20b also includes additional information designed to cause the unsupported signaling scheme processed in the second block 46 to behave like an associative data type containing multiple elements and to have access rules for accessing the elements.

[0087] When generating a control program for a target platform, the control program: - in the part of the control program corresponding to the first block 42, a read access is made to a first variable ("RamBlockPtr") represented by a first data memory object 20a, and in the part of the control program corresponding to the second block 46, a dynamic read and write access is made to elements of a second variable, designed as an associative data type and represented by a second data memory object 20b; - a first variable in the part of the control program corresponding to the first block 42 is generated in such a form that it is a key allowing access to elements of a second variable, designed as an associative data type, which is processed in the part of the control program corresponding to the second block 46.

[0088] A second variable, in this example designed as an associative data type and represented by a second data memory object 20b, identifies a portion of the main memory of the target platform, and this key (i.e., the first variable) represents, in this example, an address, i.e., a pointer, to the main memory.

[0089] That is, in the portion of the control program corresponding to the first block 42, the following code is generated, in which an untyped pointer is declared: void* RamBlockPtr; RWBGetRamBlockPtr(&RamBlockPtr);

[0090] It is further assumed that the access rules stored in the specification of the second data memory object 20b are access rules for performing type conversion of untyped pointers into typed pointers, whereby in the part of the control program corresponding to the second block 46, dynamic read and write accesses to addresses in the main memory of the target platform ES are performed as follows: const sint16* pContents_Read; / * points to sint16

[10] / * sint16 OperationOut

[10] ; sint16* pContents_Write; / * points to sint16

[10] / * pContents_Read = (const sint16*) RamBlockPtr; Rte_Read_MyReceiverPort_DE_XA(&DE_XA); Rte_Call_SomeOperation(pContents_Read, DE_XA, OperationOut); pContents_Write = (sint16*) RamBlockPtr; for (i = 0; i< 10; i++) { pContents_Write[i] = OperationOut[i]; } Rte_Write_MySenderPort_DE_XC(&DE_XC); [Explanation of symbols]

[0091] 10. Data processing equipment 12 Graphic Control Model 14 User-specific code blocks 16 Function blocks with external functions 18 blocks 20 Data Memory Objects 22 Identifiers 24 Additional Information 26 Subsystems 28 Blocks where unsupported signaling is read 30 Blocks where unsupported signaling methods are written 32 Input port blocks 34 DataStore write blocks 36 DataStore read blocks 38 Output Port Blocks 40 Blocks where unsupported signaling methods are processed 42 Block whose output value is an unsupported signaling format 44a Output value 44b Input value 46 Blocks with unsupported signaling formats as their input values PC computer system CPU processor RAM Working memory BC Bus Controller GPU graphics card DIS Monitor HMI peripheral interface KEY Keyboard MOU Mouse HDD non-volatile data memory NET interface, network interface ES control equipment MCR Microcontroller NVM memory OS Operating System TCE Technical Computing Environment MOD modeling environment BIB Library MAT-Scripting Environment SIM simulation environment PCT Code Generator DDT definition database COM Compiler LIN linker

Claims

1. 1. A computer-implemented method for processing signaling methods not supported in a graphic control model (12) of a development platform (PC) such that a control program for a target platform (ES) can be generated, and preferably will be generated, from the graphic control model (12) of the development platform (PC), comprising: The graphic control model (12) includes a block diagram having a plurality of blocks (14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46), and is designed to transfer signals of different signaling formats between at least two of the blocks (14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46); In the generated control program, the signaling is implemented by different data types; the graphic control model (12) does not support all data types required in the control program; The graphic control model (12) refers to a definition database (DDT) in which information about the graphic control model (12) is stored, The definition database (DDT) includes at least one data memory object (20), The data memory object (20) specifies a globally reachable memory region for the graphic control model (12), whereby the graphic control model (12) is designed to transfer signals between two blocks (14, 16, 18, 28, 30, 32, 34, 36, 38, 40, 42, 46) that are not coupled via a signal line, The definition database (DDT) can store a specification having at least one identifier (22) for a variable of a data type corresponding to an unsupported signaling method, In the generation of a control program for the target platform (ES), the data memory object (20) is used as a representative for variables via the identifier (22). method.

2. The specifications can be stored in data elements in the definition database (DDT), and data memory objects (20) are used as representatives for the data elements in the graphic control model (12). The method of claim 1.

3. the specification includes additional information regarding access to and / or transfer of data elements in the graphic control model (12); The method of claim 2.

4. the specification includes additional information specifying the data types of supported signaling according to which unsupported signaling behaves, and / or the specification includes additional information specifying the data types of supported signaling that are included in the unsupported signaling.

4. The method according to any one of claims 1 to 3.

5. the method comprises a step of storing the specification in the definition database (DDT), preferably in a data element, and / or the specification is called upon during the generation of the control program; 5. The method according to any one of claims 1 to 4.

6. The block diagram includes at least one user-specific code block (14) having a signaling method defined by a user and not supported in the graphic control model (12), and / or at least one function block (16) having an external function having an unsupported signaling method, and when a control program for the target platform (ES) is generated, the control program references a data memory object (20) to: a) the variables identified via the specification are used per identifier (22) in the portion of the control program corresponding to the user-specific code block (14); and / or b) When calling a part of the control program corresponding to the function block (16), the variables specified through the specification are generated in such a way that they are passed as arguments.

6. The method according to any one of claims 1 to 5.

7. the block diagram is hierarchically structured and includes at least a first subsystem (26) and a second subsystem (26), the first subsystem (26) being an outer subsystem (26a) such that second subsystems (26d, 26e, 26f) are included by the first subsystem (26a), the second subsystems (26d, 26e, 26f) including at least one code block (14) in which an unsupported signaling method is processed; the specification includes additional information regarding the transfer of variables represented by the data memory object (20); and upon generation of a control program for the target platform (ES), the control program is generated in such a manner that the variables represented by the data memory object (20) are hierarchically inherited as function parameters from a portion of the control program corresponding to the first subsystem (26a) to a portion of the control program corresponding to the second subsystems (26d, 26e, 26f).

7. The method according to any one of claims 1 to 6.

8. The block diagram includes at least one block (28, 30) into which a signal of an unsupported signaling method is read and / or into which a signal of an unsupported signaling method is written, and when a control program for the target platform (ES) is generated, the control program is generated in a form such that read access and / or write access to a variable of a data type specified through the specification is performed by referencing the data memory object (20).

8. The method according to any one of claims 1 to 7.

9. The block diagram includes at least one first block (42) whose output value (44a) is an unsupported signaling method and is passed as an index-defining input value (44b) to a second block (46) that implements dynamic selection and / or dynamic allocation; The definition database (DDT) includes a first data memory object (20a) and a second data memory object (20b); During generation of the control program, the first data memory object (20a) is used as a representative for a first variable to be processed in the portion of the control program corresponding to the first block (42); During generation of the control program, the second data memory object (20b) is used as a representative for a second variable to be processed in the portion of the control program corresponding to the second block (46); the specification of the second data memory object (20b) includes additional information such that the unsupported signaling methods processed in the second block (46) behave like an associative data type containing multiple elements, the additional information including access rules for accessing the elements; When generating a control program for the target platform (ES), the control program: - in the part of the control program corresponding to said first block (42), a read access is made to a first variable represented by said first data memory object (20a), and in the part of the control program corresponding to said second block (46), a dynamic read and / or write access is made to elements of a second variable, designed as an associative data type, represented by said second data memory object (20b); a first variable in the part of the control program corresponding to said first block (42) is generated in such a way that it is a key that allows access to elements of a second variable, designed as an associative data type and processed in the part of the control program corresponding to said second block (42); 9. The method according to any one of claims 1 to 8.

10. The associative data type is an associative array, and array element access is possible using the key.

10. The method of claim 9.

11. the associative data type identifies a portion of a main memory of a target platform, and the key indicates an address into the main memory; 10. The method of claim 9.

12. The step of generating a control program for the target platform (ES) from a graphic control model (12) of the development platform (PC) comprises: - generating an intermediate representation from said graphic control model (12); - optimizing the generated intermediate representation; - generating a control program for said target platform (ES) by transforming said optimized intermediate representation; wherein at least one of the steps includes calling an identifier (22) of a variable whose data type corresponds to an unsupported signaling method to use the data memory object (20) as a representative for the variable.

12. The method according to any one of claims 1 to 11.

13. A method for configuring a target platform (ES) designed as a control device, said target platform (ES) comprising at least one computation unit (MCR) and preferably having at least one sensor and / or actuator for capturing data of and / or acting on a physical process, said method comprising: - loading the graphic control model (12) of the development platform (PC); - generating a control program for said target platform (ES) from the loaded graphic control model (12) according to the method of any one of claims 1 to 12; - generating a code executable for said computing unit (MCR) of said target platform (ES) by compiling said generated control program; - transferring the generated executable code to the target platform (ES) and / or storing the generated executable code in a non-volatile memory (NVM) of the target platform (ES) and / or executing the generated executable code by the computing unit (MCR) of the target platform (ES); A method comprising:

14. An apparatus (10) for data processing, comprising means for carrying out the method according to any one of claims 1 to 12. Apparatus (10).

15. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any one of claims 1 to 12. Computer program products.

Images