EP3070558A1 - Verfahren zum konfigureren eines embedded-geräts - Google Patents

Verfahren zum konfigureren eines embedded-geräts Download PDF

Info

Publication number
EP3070558A1
EP3070558A1 EP15159471.0A EP15159471A EP3070558A1 EP 3070558 A1 EP3070558 A1 EP 3070558A1 EP 15159471 A EP15159471 A EP 15159471A EP 3070558 A1 EP3070558 A1 EP 3070558A1
Authority
EP
European Patent Office
Prior art keywords
embedded device
transformer
data
repository
input data
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
EP15159471.0A
Other languages
English (en)
French (fr)
Other versions
EP3070558B1 (de
Inventor
Nils Schwenkel
Sebastian Heidepriem
Patrick Jeschall
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.)
Sick AG
Original Assignee
Sick AG
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 Sick AG filed Critical Sick AG
Priority to EP15159471.0A priority Critical patent/EP3070558B1/de
Publication of EP3070558A1 publication Critical patent/EP3070558A1/de
Application granted granted Critical
Publication of EP3070558B1 publication Critical patent/EP3070558B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/04—Program control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Program control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence

Definitions

  • the present invention relates to methods of configuring an embedded device and methods of operating the same.
  • Embedded devices are in particular electronic computers or computers that are embedded or embedded in a technical context.
  • the embedded device may be used in the technical context e.g. the control and regulation of processes, the monitoring of measured variables or the processing of data.
  • Under an embedded device can thus, for example, a programmable logic controller (PLC) or generally an automation device, such as. a servo drive, an HMI (Human Machine Interface) or a frequency converter are understood.
  • PLC programmable logic controller
  • HMI Human Machine Interface
  • Such embedded devices are used in a variety of applications and control, for example, automated processes in machines, robots or manufacturing equipment.
  • the embedded devices are programmed and configured to suit the needs of the industrial manufacturing facility. If the production plant is subsequently to be changed to carry out a new production process, it may be sufficient to change a configuration of the embedded devices. For this purpose, for example, the parameters or variables stored in the embedded devices must be changed in order to take the new production process into account.
  • the values of the parameters are changed in a programming system, wherein subsequently a software of the embedded devices is completely recreated.
  • the complete renewal of the software is complex and requires appropriate resources.
  • a modeling or configuration tool can also be used for the change.
  • a configuration tool generates, for example, configuration files which do not comprise code in a programming language but in a markup language, such as a language of description. XML, are authored.
  • the information contained in the configuration file must be stored, for example. be manually transmitted by a programmer in the underlying software of the embedded devices code. From the manually adapted code, new software can be generated for the embedded devices, which then enables the operation of the embedded devices with the new configuration.
  • configuration of the embedded device is also used here in the sense of a new configuration and can also be the adaptation include the configuration of the embedded device during operation of the embedded device.
  • the transformation description is used to generate from the input data a data structure that can be used by the embedded device.
  • the input data can be created manually or by a configuration tool and contain information about how the embedded device should behave during operation.
  • the input data may include information indicating how a graphical user interface (GUI) of the embedded device is constructed.
  • GUI graphical user interface
  • the input data may include data to be managed or processed, such as e.g. Names and addresses of customers, for example, to automate a sales process.
  • information about an industrial manufacturing process such as e.g. a number of pieces per unit time, number of revolutions of motors to be controlled, clock frequencies, thresholds for current or voltage controlled operations, and the like, more of the input data.
  • the input data can be created by a configuration tool and therefore does not contain code in a programming language.
  • a programming language here a language is called, which includes both data structures and algorithms. Algorithms are in particular processing instructions or calculation instructions. Accordingly, a file written in a markup language containing only data and data structures is not written in a programming language. The exemplary XML files shown below are thus not written in a programming language.
  • the input data is in a markup language, such as XML (Extensible Markup Language).
  • the input data may be in the form of a configuration file, in particular in XML format, or as a data stream or the like.
  • the transformation description also does not include any code in a programming language according to the above definitions. Also, the transformation description is preferably written in a markup language, preferably also in XML.
  • a transformer is configured using the transformation description.
  • the transformation description contains specifications as to which data should be taken from the input data (here the configuration file) in order to configure the operation of the embedded device, but like input data (in this case the configuration file) does not include any code in a programming language and is preferred also written in a markup language, such as XML.
  • the transformer (ie the transformation means) is an executable program or executable code which is configured by means of the transformation description.
  • the transformer itself can be constructed generically in such a way that it can be configured by means of arbitrary transformation descriptions. In this way, almost any input data can be processed by the transformer.
  • configuration in the context of the transformer should be understood to mean that, depending on the circumstances, either First a transformer is generated and then configured or an existing transformer is configured.
  • the transformation description includes references to structural elements of the input data and describes how these structural elements should be represented in a high level language (e.g., in C or C ++ code).
  • the transformation of the structural elements into processable data or executable code is then carried out by the transformer, which is configured by means of the transformation description.
  • the data generated by the transformer is present and transmitted to the embedded device.
  • the transformation description also contains information on how the data generated by the transformer must be structured in order to be used by the embedded device in operation.
  • the generated data may be in a format that corresponds to executable code of the high-level language used by the embedded device.
  • the embedded device can now use the transferred data during operation. For example, in the examples given above, after transferring the data generated by the transformer to the embedded device, the embedded device may use new customer data or use new clock frequencies, e.g. to control electric motors connected to the embedded device.
  • the transformer can thus process the input data such that, according to the specifications of the transformation description, those data are taken from the input data specified in the transformation description.
  • the transformer generates data that can be processed by the embedded device. This means that the generated data need not be translated (compiled) into an executable format in an additional step.
  • data can be generated that can be processed directly by the embedded device without having to make a detour via a programming language and an additional translation from the programming language.
  • the data generated by the transformer may be a "repository", i. a data store.
  • all the data generated by the transformer can be combined in the repository.
  • all generated data can be in structured arrays of C code or other programming language.
  • information from the input data is thus taken from the transformer on the basis of the specifications from the transformation description and transferred to the repository, the repository in particular comprising variables structured in data structures.
  • the data may then be in the repository in variables structured in data structures, such as an "array of struct".
  • the "array of struct” can be a field of structures, where each structure can be a combination of multiple variables.
  • a field with the name "MyCustomers” is created, in which structures are created that consist of the variables "Name”, “First name”, “Street”, “Zip code”, "City” and "Customer number " consist. All information taken from the input data from the transformer can thus be stored in the repository in a similar data structure, namely the array of struct.
  • only information that is defined in the transformation description is transferred to the repository. This means that it is only specified in the transformation description which information is relevant for the respective embedded device. Irrelevant information can then be omitted, for example, to reduce the storage requirements of the repository or the data generated by the transformer. In particular, e.g. omit any information that affects functions that the particular embedded device does not support.
  • the data generated by the transformer and processable by the embedded device also includes a program structure generated by the transformer.
  • the program structure can correspond to the structure of a high-level language.
  • high-level language is meant here a programming language such as C, C ++, C #, Java or the like.
  • the program structure can likewise be executable, with the result that the embedded device can access the information contained in the program structure without intermediate steps.
  • the program structure may contain definitions of variables, with the variables themselves or their values in turn can be contained in the repository.
  • the program structure may also contain definitions of functions and function instructions.
  • the processable data are designed such that they can be read natively by a high-level language, preferably C or C ++.
  • a high-level language preferably C or C ++.
  • the processable data is stored, in particular in a processable format, so that it can be read by the embedded device programmed in a high-level language.
  • the processable data is not available in the high-level language itself. Instead, the processable data is in a format that matches that of high-level executable code. In this way, the processable data can be seamlessly integrated into the executable code of the embedded device.
  • the transformer creates the data structures in the repository and the data structures are filled with values during operation of the embedded device.
  • the initialization, i. the values of the applied variables are then set at runtime.
  • an interpreter program can be used which belongs to the transformer, works interpretatively and reads in the information from the input data and determines the values of the variables from the information.
  • the interpreter program can also be executed by the embedded device.
  • such a repository is then stored in a rewritable memory (eg the random access memory RAM) of the embedded device. Since no initialization has yet taken place, the memory must be writable because its contents change at runtime.
  • a rewritable memory eg the random access memory RAM
  • the transformer creates the data structure in the repository and initializes (or populates) it with values from the input data.
  • a constant array of struct (const struct []) is created. This constant array is also referred to below as a constant structure.
  • the constant structure is shown above only for clarity in a high level language. However, the shape shown does not correspond to the shape in which the constant structure is transferred to the embedded device. The transfer to the embedded device takes place in a processable (data) form, which is not readable by humans in particular. However, the information content of the structure shown above corresponds to the information content which, in the example chosen, would be transmitted to the embedded device.
  • a repository of such a configuration is then stored in a read-only memory (ROM) of the embedded device.
  • ROM read-only memory
  • the repository in this embodiment consists of constants, the data of the repository does not change after writing the ROM once in the operation of the embedded device. For this reason, the repository can be stored in the ROM, which can result in a cost advantage, especially for smaller processors of the embedded device.
  • the transformation description is selected such that a required storage space for the resulting repository is sized to be less than or equal to the storage space of the read-only memory of the embedded device.
  • the repository is designed to be adapted to the storage space of a ROM of the embedded device. This can be achieved, for example, by an appropriate choice of the transformation description.
  • the transformation description can be changed, e.g. To store truncated variables in the repository so that the repository has a desired size.
  • all data generated by the transformer may also have a size less than or equal to the memory location of the read only memory of the embedded device.
  • the data generated by the transformer contain binary code.
  • binary code When binary code is generated, no translation or compilation is required at runtime, which may cause altered operation of the embedded device immediately after transmission of the data generated by the transformer.
  • the binary code can be contained in the repository and / or the program structure.
  • the repository and / or the program structure preferably also consist entirely of binary code.
  • the repository comprises an array of structures, the array being in particular an array of fixed length and / or constant values.
  • the fixed-length array can be stored in RAM and, alternatively or additionally, using only constant values in the ROM of the embedded device.
  • An application program of the embedded device preferably accesses the processable data by means of an interface.
  • the interface can be one own program that allows access to the repository and / or program structure.
  • the application program can be an application executed on the embedded device, for example a motor control or the like.
  • the transformer comprises a filter, wherein the filter converts the input data into an intermediate file, and furthermore the intermediate file only contains information relevant for the embedded device.
  • the intermediate file may thus have a smaller memory requirement compared to the input data and speed up the processing by the transformer.
  • information may be omitted that pertains to additional functions of other embedded devices that the (target) embedded device can not handle.
  • information may also be added to the intermediate file, e.g. serve the device description of the embedded device.
  • the syntax of the markup language used for the input data may be removed.
  • the intermediate file may also be a binary file.
  • the transformer comprises an interpreter, which reads in the intermediate file and / or the input data and generates values for the data structure in the repository from the information of the read-in file.
  • the intermediate file can be used by the translator's interpreter or interpreter program to set values of variables in the embedded device at runtime.
  • the intermediate file may still contain so much structural information that the interpreter can skip unknown elements and is thus upwards and downwards compatible.
  • the transformer of the transformer may be executed either on a computer system separate from the embedded device.
  • the filter can also be run on the embedded device.
  • the data generated by the transformer can then be used in the operation of the embedded device.
  • This second configuration method according to the invention thus differs from the method according to the invention according to claim 1 in that the transformer is not executed completely outside the embedded device, but is at least partially executed on the embedded device.
  • step (b) the part of the input data transmitted to the embedded device in step (b) is generally processed by the part of the transformer transmitted or generated in step (b) in the embedded device.
  • the information taken over from the input data by the transformer in step (e) on the basis of the transformation description is preferably transmitted to a repository, wherein the repository comprises in particular variables structured in data structures.
  • the part of the transformer executed on the embedded device can be used to fill an initialized array of struct with information from the input data at runtime and thus to initialize it.
  • a part of the transformer can also be executed outside of the embedded device, this part being able to generate a data structure for the embedded device.
  • the invention also relates to a method for operating an embedded device, in which an embedded device is configured or configured with the second configuration method according to the invention or one of its advantageous embodiments and which uses data generated by the transformer for operation of the embedded device become.
  • the invention also relates to a computer program with program code means which are arranged such that one of the methods explained above is carried out when the program is executed on a computer.
  • the invention relates to a computer program product with program code means which are stored on a computer-readable data medium and are arranged such that at least one of the methods explained above is carried out when the program product is executed on a computer.
  • Fig. 1 schematically shows the sequence of an embodiment of a method according to the invention for the configuration or operation of an embedded device.
  • input data stored in a configuration file 10 is supplied to a transformer 14.
  • the transformer 14 is configured by means of a transformation description 12.
  • the transformer 14 is an executable program or executable code.
  • the configuration file 10 and the transformation description 12 are present in this example as XML files.
  • the transformer 14 includes a first part 14a and a second part 14b.
  • the first part 14 a requires as input values the input data from the configuration file 10 and from the transformation description 12.
  • data are taken from the configuration file 10 and stored in binary form in an array of struct in a repository 16.
  • the repository 16 is transferred to an embedded device 18 upon completion.
  • the repository 16 is a data memory in which data generated by the transformer 14 can be combined in the form of an array of struct.
  • the array of struct can be a field of structures, where each structure can be a combination of multiple variables.
  • the second part 14b of the transformer 14 requires as input only the transformation description 12, wherein the second part 14b of the transformation description 12 extracts which information from the configuration file 10 is transferred to the repository 16. For each of the various pieces of information, the second part 14b applies a variable, the variables being stored in a program structure 20 on the embedded device 18.
  • the program structure 20 is also in binary form and indicates at which memory locations in the repository 16 which variable is stored.
  • the variables may already exist as constant values, i. H. the transformer 14, and in particular its first part 14a, generates the values of the repository 16 or extracts them from the configuration file 10.
  • the repository 16 in this embodiment can be stored in a ROM of the embedded device 18 and completely occupy the ROM.
  • an application 22 is executed, which controls, for example, an electric motor (not shown).
  • 16 speed profiles and limits for the currents and voltages to be applied are stored in the repository, which are taken from the configuration file 10.
  • the application 22 accesses the values stored in the repository 16 via an interface 24.
  • the interface 24 also accesses the program structure 20.
  • the configuration file 10 can be changed, whereupon by means of the transformation description 12 and the transformer 14 an altered repository 16 can be generated automatically.
  • the application 22 is accessed by the data in the repository 16, the operation of the electric motor is then also adapted to the new parameters. It's one in this way simple and easy adjustment of the operation of the embedded device possible.
  • Fig. 2 shows an embodiment of another method according to the invention for configuring or operating an embedded device 18.
  • the transformer 14 comprises a filter 26, wherein the filter 26 accesses the transformation description 12 and filters the configuration file 10 in such a way that only information relevant for the embedded device 18 is stored in an intermediate file 28.
  • the filter 26, like the transformer 14, comprises executable code and can operate both interpretatively and generatively.
  • the intermediate file 28 is, for example, a binary file, which in particular also contains no syntax of the original XML configuration file 10.
  • the transformer 14 includes an interpreter 30 which is generated by the first part 14a and executed by the embedded device 18.
  • the interpreter 30 may be generated outside of the embedded device 18, such as on a PC system (not shown), and then transmitted to the embedded device 18.
  • the interpreter 30 generates the values of the variables in the repository 16 at runtime of the embedded device 18 from the intermediate file 28, which is previously transmitted to the embedded device 18. This means that the repository 16 initially only generates non-variable values when it is generated. contains initialized variables, for example, an array of struct of length 1024. In this embodiment, the repository 16 is stored in a RAM of the embedded device 18 to make changes to the data in the repository 16 at runtime. Otherwise, the comments on the exemplary embodiment of FIG Fig. 1 ,
  • Fig. 3 is a modified embodiment of the method of FIG. 2 shown.
  • the third embodiment differs from the embodiment according to FIG Fig. 2 in that the interpreter 30 reads in the configuration file 10 directly, which is transmitted to the embedded device 18 for this purpose and from which the information specified in the transformation description 12 is transferred to the repository 16. There is thus no intermediate step via the intermediate file 28.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft Verfahren zum Konfigurieren und zum Betrieb eines Embedded-Geräts. Ein erstes erfindungsgemäßes Verfahren zur Konfigurierung umfasst, dass ein Transformator mittels einer Transformationsbeschreibung konfiguriert wird, wobei die Transformationsbeschreibung Vorgaben darüber enthält, welche Daten aus Eingangsdaten entnommen werden sollen, wobei die Eingangsdaten Konfigurationsdaten für das Embedded-Gerät umfassen, und wobei die Transformationsbeschreibung keinen Code in einer Programmiersprache umfasst und die Eingangsdaten vorzugsweise als XML-Datei dargestellt sind; die Eingangsdaten von dem Transformator nach den Vorgaben der Transformationsbeschreibung verarbeitet werden; der Transformator bei dieser Verarbeitung Daten erzeugt, die von dem Embedded-Gerät verarbeitbar sind und bevorzugt ein Repository umfassen; und die von dem Transformator erzeugten Daten an das Embedded-Gerät übertragen werden um beim Betrieb des Embedded-Geräts verwendet werden zu können.

Description

  • Die vorliegende Erfindung betrifft Verfahren zum Konfigurieren eines Embedded-Geräts und Verfahren zu dessen Betrieb.
  • Embedded-Geräte sind insbesondere elektronische Rechner oder Computer, die in einen technischen Kontext eingebunden bzw. eingebettet sind. Das Embedded-Gerät kann in dem technischen Kontext z.B. die Steuerung und Regelung von Prozessen, die Überwachung von Messgrößen oder die Verarbeitung von Daten übernehmen. Unter einem Embedded-Gerät kann also beispielsweise eine speicherprogrammierbare Steuerung (SPS) oder generell ein Automatisierungsgerät, wie z.B. ein Servoantrieb, ein HMI (Human Machine Interface) oder ein Frequenzumrichter verstanden werden. Solche Embedded-Geräte kommen in einer Vielzahl von Anwendungen zum Einsatz und steuern beispielsweise automatisierte Prozesse in Maschinen, Robotern oder Fertigungsanlagen.
  • Wird eine industrielle Fertigungsanlage mit Embedded-Geräten ausgestattet, so werden die Embedded-Geräte derart programmiert und konfiguriert, dass sie an die Gegebenheiten der industriellen Fertigungsanlage angepasst sind. Soll die Fertigungsanlage nun nachträglich verändert werden, um einen neuen Produktionsprozess durchführen, so kann es ausreichen, eine Konfiguration der Embedded-Geräte zu verändern. Dazu müssen beispielsweise die in den Embedded-Geräten gespeicherten Parameter bzw. Variablen verändert werden, um dem neuen Produktionsprozess Rechnung zu tragen.
  • Üblicherweise werden zu diesem Zweck die Werte der Parameter in einem Programmiersystem verändert, wobei anschließend eine Software der Embedded-Geräte vollständig neu erzeugt wird. Die vollständige Erneuerung der Software ist dabei aufwändig und benötigt entsprechende Ressourcen.
  • Alternativ zu der Veränderung in dem Programmiersystem kann auch ein Modellierungs- bzw. Konfigurierungstool zur Änderung verwendet werden. Ein solches Konfigurierungstool erzeugt als Ergebnis beispielsweise Konfigurationsdateien, die keinen Code in einer Programmiersprache umfassen sondern in einer Auszeichnungssprache, wie z.B. XML, verfasst sind.
  • Soll nun ein Embedded-Gerät oder eine Fertigungsanlage mit einer Vielzahl von Embedded-Geräten mit der neuen Konfiguration betrieben werden, so müssen die in der Konfigurationsdatei enthaltenen Informationen z.B. manuell von einem Programmierer in den der Software der Embedded-Geräte zugrundeliegenden Code übertragen werden. Aus dem manuell angepassten Code kann dann eine neue Software für die Embedded-Geräte erzeugt werden, die dann den Betrieb der Embedded-Geräte mit der neuen Konfiguration ermöglicht.
  • Die Anpassung des Codes der Embedded-Geräte ist dabei aufwändig und zudem fehleranfällig.
  • Es ist daher die der Erfindung zugrundeliegende Aufgabe, ein Verfahren anzugeben, welches die Konfiguration eines Embedded-Geräts auf einfache und effiziente Weise ermöglicht und damit den Betrieb des Embedded-Gerätes vereinfacht.
  • Diese Aufgabe wird durch die Verfahren gemäß den unabhängigen Ansprüchen gelöst.
  • Die Erfindung betrifft gemäß Anspruch 1 ein Verfahren zur Konfiguration eines Embedded-Geräts, bei welchem
    1. (a) ein Transformationsmittel (im vorliegenden Text auch einfach als Transformator bezeichnet) mittels einer Transformationsbeschreibung konfiguriert wird, wobei die Transformationsbeschreibung Vorgaben darüber enthält, welche Daten aus Eingangsdaten entnommen werden sollen, wobei die Eingangsdaten Konfigurationsdaten für das Embedded-Gerät umfassen, und wobei die Transformationsbeschreibung keinen Code in einer Programmiersprache umfasst und die Eingangsdaten vorzugsweise als XML-Datei dargestellt ist;
    2. (b) die Eingangsdaten von dem Transformator nach den Vorgaben der Transformationsbeschreibung verarbeitet werden;
    3. (c) der Transformator bei dieser Verarbeitung Daten erzeugt, die von dem Embedded-Gerät verarbeitbar sind und bevorzugt ein Repository umfassen; und
    4. (d) die von dem Transformator erzeugten Daten an das Embedded-Gerät übertragen werden, um sie beim Betrieb des Embedded-Geräts verwenden zu können.
  • Im Folgenden werden die Elemente, die bei dem erfindungsgemäßen Verfahren zum Einsatz kommen und ihr vorteilhaftes Zusammenwirken erläutert und beschrieben.
  • Der Begriff der "Konfiguration des Embedded-Gerätes" wird im vorliegenden Text auch im Sinne eine Neu-Konfiguration verwendet und kann auch die Anpassung der Konfiguration des Embedded-Gerätes während des Betriebes des Embedded-Gerätes umfassen.
  • Die Transformationsbeschreibung wird dazu eingesetzt, aus den Eingangsdaten eine Datenstruktur zu erzeugen, die von dem Embedded-Gerät verwendet werden kann. Die Eingangsdaten können dabei manuell oder von einem Konfigurationstool erstellt worden sein und Informationen darüber enthalten, wie sich das Embedded-Gerät während des Betriebs verhalten soll.
  • Beispielsweise können die Eingangsdaten Informationen umfassen, die angeben, wie eine graphische Benutzeroberfläche (GUI - Graphical User Interface) des Embedded-Geräts aufgebaut ist. Bei anderen Anwendungen können die Eingangsdaten zu verwaltende oder zu verarbeitende Daten enthalten, wie z.B. Namen und Adressen von Kunden, um beispielsweise einen Verkaufsprozess zu automatisieren. Weiterhin können auch Informationen über einen industriellen Herstellungsprozess, wie z.B. eine Stückzahl pro Zeiteinheit, Umdrehungszahlen von zu steuernden Motoren, Taktfrequenzen, Schwellenwerte für strom- oder spannungsgesteuerte Vorgänge und dergleichen mehr von den Eingangsdaten umfasst sein.
  • Wie erwähnt können die Eingangsdaten von einem Konfigurationstool erstellt werden und enthalten insofern keinen Code in einer Programmiersprache. Als Programmiersprache wird hier eine Sprache bezeichnet, welche sowohl Datenstrukturen als auch Algorithmen umfasst. Algorithmen sind insbesondere Verarbeitungsanweisungen bzw. Rechenvorschriften. Dementsprechend ist eine in einer Auszeichnungssprache verfasste Datei, welche nur Daten und Datenstrukturen enthält, nicht in einer Programmiersprache verfasst. Die nachfolgend dargestellten beispielhaften XML-Dateien sind somit nicht in einer Programmiersprache verfasst.
  • Bevorzugt liegen die Eingangsdaten in einer Auszeichnungssprache vor, wie beispielsweise XML (Extensible Markup Language). Die Eingangsdaten können in Form einer Konfigurationsdatei, insbesondere im XML-Format, oder als Datenstrom oder dergleichen vorliegen.
  • Die Transformationsbeschreibung umfasst ebenfalls keinen Code in einer Programmiersprache gemäß den obigen Definitionen. Auch die Transformationsbeschreibung ist bevorzugt in einer Auszeichnungssprache verfasst, vorzugsweise ebenfalls in XML.
  • Ein Beispiel für Eingangsdaten in Form einer Konfigurationsdatei, welche Kundendaten enthält, ist im Folgenden als XML-Datei aufgeführt. In der Konfigurationsdatei sind die Namen, Vornamen, Adressen und Kundennummern mehrerer Personen als Strukturelemente gespeichert. 
 <?xml version="1.0" encoding="UTF-8"?>
 <Kunden xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="Kundendaten.xsd">
  <Person Name="Mustermann" Vorname="Max">
    <Adresse Strasse="Heimweg 1" PLZ="12342" Ort="Hohenheim"/>
    <Account KundenNummer="98234987345"/>
  </Person>
  <Person Name="Mustermann" Vorname="Eva">
    <Adresse Strasse="Heimweg 1" PLZ="12342" Ort="Hohenheim"/>
    <Account KundenNummer="98234987346"/>
  </Person>
  <Person Name="Mustermann" Vorname="Jan">
    <Adresse Strasse="Heimweg 1" PLZ="12342" Ort="Hohenheim"/>
    <Account KundenNummer="98234987347"/>
  </Person>
  <Person Name="Herrmann" Vorname="Jonathan">
    <Adresse Strasse="Haupstraße 22" PLZ="03812" Ort="Feldheim"/>
    <Account KundenNummer="92873444683"/>
  </Person>
  <Person Name="Herrmann" Vorname="Ines">
    <Adresse Strasse="Haupstraße 22" PLZ="03812" Ort="Feldheim"/>
    <Account KundenNummer="92873444685"/>
  </Person>
  <Person Name="Herrmann" Vorname="Julian">
    <Adresse Strasse="Haupstraße 22" PLZ="03812" Ort="Feldheim"/>
    <Account KundenNummer="92873444686"/>
  </Person>
  <Person Name="Herrmann" Vorname="Angelika">
    <Adresse Strasse="Haupstraße 22" PLZ="03812" Ort="Feldheim"/>
    <Account KundenNummer="92873444931"/>
  </Person>
  </Kunden>
  • Um die Konfiguration des Embedded-Geräts nun entsprechend anzupassen (beim vorliegenden Beispiel an die Konfiguration in der Konfigurationsdatei) und damit einen veränderten Betrieb des Embedded-Geräts zu ermöglichen, wird mit Hilfe der Transformationsbeschreibung ein Transformator konfiguriert. Die Transformationsbeschreibung enthält dabei Vorgaben darüber, welche Daten aus den Eingangsdaten (hier der Konfigurationsdatei) entnommen werden sollen, um den Betrieb des Embedded-Geräts zu konfigurieren, umfasst jedoch ebenso wie Eingangsdaten (hier also die Konfigurationsdatei) keinen Code in einer Programmiersprache und ist bevorzugt ebenfalls in einer Auszeichnungssprache verfasst, wie z.B. XML.
  • Der Transformator (also das Transformationsmittel) ist dabei ein ausführbares Programm bzw. ausführbarer Code, welcher mittels der Transformationsbeschreibung konfiguriert wird. Der Transformator selbst kann so generisch aufgebaut sein, dass er mittels beliebiger Transformationsbeschreibungen konfigurierbar ist. Auf diese Weise können nahezu beliebige Eingangsdaten von dem Transformator verarbeitet werden. Der Begriff der "Konfiguration" soll im Zusammenhang mit dem Transformator so verstanden werden, dass - je nach den Gegebenheiten-entweder zunächst ein Transformator generiert und dann konfiguriert wird oder ein bereits bestehender Transformator konfiguriert wird.
  • Im Folgenden ist ein Beispiel einer Transformationsbeschreibung im XML-Format angegeben. Die gezeigte beispielhafte Transformationsbeschreibung veranlasst den mit ihr erzeugten Transformator dazu, aus der oben beispielhaft angegebenen Konfigurationsdatei die Namen, Vornamen, Adressen und Kundennummern sämtlicher Personen zu entnehmen. Dabei werden beispielsweise die Namen als String-Variablen ("toStringTransformation") und die Kundennummer als Ganzzahl ohne Vorzeichen ("toUnsignedlntegralNumberTransformation") entnommen. 
    •  <?xml version="1.0" encoding="UTF-8"?>
 <TransformationLanguage xmlns:xsi="http://www.w3.org/2001/XMLSchema-
 instance" xsi:noNamespaceSchemaLocation="TransformationLanguage.xsd">
  <Transformation xsi:type="toListTransformation" Source-
  Path="/Kunden/Person" DestName="MeineKunden">
    <InnerTransformation xsi:type="toStringTransformation" Source-
    Path="@Name" DestName="name">
    </ InnerTransformation >
    <InnerTransformation xsi:type="toStringTransformation" Source-
    Path="@Vorname" DestName="vorname">
    </InnerTransformation>
    <InnerTransformation xsi:type="toStringTransformation" Source-
    Path="Adresse/@Strasse" DestName="strasse">
    </InnerTransformation>
    <InnerTransformationxsi:type="toUnsignedIntegralNumberTransformation"
    SourcePath="Adresse/@PLZ" DestName="postleitzahl" >
    </InnerTransformation>
    <InnerTransformationxsi:type="toStringTransformation" Source-
    Path="Adresse/@Ort" DestName="ort">
    </InnerTransformation>
    <InnerTransformation
    xsi:type="toUnsignedIntegralNumberTransformation" Source-
    Path="Account/@KundenNummer" DestName="kundenNummer" >
    </InnerTransformation>
  </Transformation>
  </TransformationLanguage>
  • Allgemein enthält die Transformationsbeschreibung Referenzen auf Strukturele-mente der Eingangsdaten und beschreibt, wie diese Strukturelemente in einer Hochsprache (z.B. in C oder C++-Code) repräsentiert werden sollen. Die Transformation der Strukturelemente in verarbeitbare Daten bzw. ausführbaren Code erfolgt dann durch den Transformator, welcher mittels der Transformationsbeschreibung konfiguriert wird.
  • Hat der Transformator die Eingangsdaten verarbeitet, so liegen die von dem Transformator erzeugten Daten vor und werden an das Embedded-Gerät übertragen. Die Transformationsbeschreibung enthält dabei auch Informationen, wie die von dem Transformator erzeugten Daten strukturiert sein müssen, um von dem Embedded-Gerät im Betrieb verwendet zu werden. Die erzeugten Daten können dabei in einem Format vorliegen, das ausführbarem Code der von dem Embedded-Gerät verwendeten Hochsprache entspricht.
  • Das Embedded-Gerät kann die übertragenen Daten nun während des Betriebs verwenden. Beispielsweise kann das Embedded-Gerät bei den oben angegebenen Beispielen nach dem Übertragen der von dem Transformator erzeugten Daten an das Embedded-Gerät auf neue Kundendaten zurückgreifen oder neue Taktfrequenzen verwenden, um z.B. an das Embedded-Gerät angeschlossene Elektromotoren anzusteuern.
  • Mit dem erfindungsgemäßen Verfahren ist es somit möglich, Embedded-Geräte in verschiedenen Konfigurationen zu betreiben, ohne eine Programmierung der Embedded-Geräte vollständig neu zu erstellen. Trotzdem ist es dabei möglich, weiterhin Eingangsdaten oder Konfigurationsdateien zu verwenden, die nicht in einer Programmiersprache verfasst sind. Somit bleibt der Einsatz von Konfigurationstools möglich.
  • Dabei kann der Transformator die Eingangsdaten also derart verarbeiten, dass nach den Vorgaben der Transformationsbeschreibung diejenigen Daten aus den Eingangsdaten entnommen werden, die in der Transformationsbeschreibung spezifiziert sind. Der Transformator erzeugt dabei Daten, die von dem Embedded-Gerät verarbeitbar sind. Dies bedeutet, dass die erzeugten Daten nicht in einem zusätzlichen Schritt in ein ausführbares Format übersetzt (kompiliert) werden müssen.
  • Vielmehr können Daten erzeugt werden, die von dem Embedded-Gerät direkt verarbeitbar sind, ohne den Umweg über eine Programmiersprache und eine zusätzliche Übersetzung aus der Programmiersprache beschreiten zu müssen.
  • Vorteilhafte Weiterbildungen der Erfindung sind der Beschreibung, den Unteransprüchen sowie den Zeichnungen zu entnehmen.
  • Die von dem Transformator erzeugten Daten können ein "Repository", d.h. einen Datenspeicher, umfassen. Insbesondere können in dem Repository sämtliche von dem Transformator erzeugten Daten zusammengefasst sein. In dem Repository können sämtliche erzeugten Daten in strukturierten Arrays von C-Code oder einer anderen Programmiersprache vorliegen.
  • Gemäß einer vorteilhaften Ausführungsform werden also von dem Transformator anhand der Vorgaben aus der Transformationsbeschreibung Informationen aus den Eingangsdaten entnommen und in das Repository übertragen, wobei das Repository insbesondere in Datenstrukturen gegliederte Variablen umfasst.
  • Die Daten können dann in dem Repository in in Datenstrukturen gegliederten Variablen vorliegen, beispielsweise einem "Array of Struct". Bei dem "Array of Struct" kann es sich um ein Feld von Strukturen handeln, wobei jede Struktur eine Kombination mehrere Variablen sein kann. Bei dem oben genannten Beispiel wird also ein Feld mit dem Namen "MeineKunden" angelegt, in welchem jeweils Strukturen angelegt werden, die aus den Variablen "Name", "Vorname", "Strasse", "PLZ", "Ort" und "Kundennummer" bestehen. Sämtliche den Eingangsdaten von dem Transformator entnommenen Informationen können so in dem Repository in einer gleichartigen Datenstruktur, nämlich dem Array of Struct, abgelegt sein.
  • Gemäß einer weiteren vorteilhaften Ausführungsform der Erfindung werden ausschließlich solche Informationen in das Repository übernommen, die in der Transformationsbeschreibung definiert sind. Dies bedeutet, dass ausschließlich in der Transformationsbeschreibung festgelegt wird, welche Informationen für das jeweilige Embedded-Gerät relevant sind. Nicht relevante Informationen können dann weggelassen werden, um beispielsweise den Speicherbedarf des Repositorys bzw. der von dem Transformator erzeugten Daten zu verringern. Insbesondere können z.B. solche Informationen weggelassen werden, die Funktionen betreffen, die das jeweilige Embedded-Gerät nicht unterstützt.
  • Bevorzugt umfassen die von dem Transformator erzeugten und von dem Embedded-Gerät verarbeitbaren Daten auch eine Programmstruktur, welche von dem Transformator erzeugt wird. Die Programmstruktur kann dabei der Struktur einer Hochsprache entsprechen. Unter Hochsprache wird hierbei eine Programmiersprache wie beispielsweise C, C++, C#, Java oder dergleichen verstanden. Die Programmstruktur kann dabei ebenfalls ausführbar sein, wodurch das Embedded-Gerät ohne Zwischenschritte auf die in der Programmstruktur enthaltenen Informationen zugreifen kann. Insbesondere kann die Programmstruktur Definitionen von Variablen enthalten, wobei die Variablen selbst bzw. deren Werte wiederum in dem Repository enthalten sein können. Zusätzlich kann die Programmstruktur auch Definitionen von Funktionen und Funktionsanweisungen enthalten.
  • Besonders bevorzugt sind die verarbeitbaren Daten derart angelegt, dass sie von einer Hochsprache, bevorzugt C oder C++, nativ gelesen werden können. Dies bedeutet, dass die verarbeitbaren Daten so gespeichert sind, insbesondere in einem verarbeitbaren bzw. ausführbaren Format, dass sie von dem in einer Hochsprache programmierten Embedded-Gerät gelesen werden können. Die verarbeitbaren Daten liegen aber nicht in der Hochsprache selbst vor. Stattdessen liegen die verarbeitbaren Daten in einem Format vor, das dem von ausführbarem Code der Hochsprache entspricht. Auf diese Weise können sich die verarbeitbaren Daten nahtlos in den ausführbaren Code des Embedded-Geräts eingliedern.
  • Gemäß einer weiteren vorteilhaften Ausführungsform legt der Transformator die Datenstrukturen in dem Repository an und die Datenstrukturen werden beim Betrieb des Embedded-Geräts mit Werten gefüllt. Dies bedeutet, dass zunächst z.B. ein Array of Struct mit fester Länge erzeugt (d.h. instanziiert) wird (z.B. struct[1024]), aber keine Initialisierung der Werte erfolgt. Die Initialisierung, d.h. das Festlegen der Werte der angelegten Variablen, erfolgt dann erst zur Laufzeit. Zur Festlegung der Werte kann ein Interpreterprogramm verwendet werden, welches zu dem Transformator gehört, interpretativ arbeitet und die Informationen aus den Eingangsdaten einliest und aus den Informationen die Werte der Variablen festlegt. Das Interpreterprogramm kann auch von dem Embedded-Gerät ausgeführt werden.
  • Bevorzugt wird ein solches Repository dann in einem wiederbeschreibbaren Speicher (z.B. dem RAM - Random Access Memory) des Embedded-Geräts gespeichert. Da noch keine Initialisierung erfolgt ist, muss der Speicher beschreibbar sein, weil sich sein Inhalt zur Laufzeit verändert.
  • Gemäß einer alternativen Ausführungsform legt der Transformator die Datenstruktur in dem Repository an und initialisiert (oder belegt) sie mit Werten aus den Eingangsdaten. Es wird ein konstantes Array of struct (const struct [ ]) erzeugt. Dieses konstante Array wird im Folgenden auch als konstante Struktur bezeichnet.
  • Ein Beispiel für eine erzeugte konstante Struktur ist im Folgenden aufgeführt. Die Struktur ist aus der weiter oben gezeigten Konfigurationsdatei unter Verwendung der obigen Transformationsbeschreibung zur Erzeugung des Transformators entstanden. 
    •  #include "KundenDaten.h"
 KD_PersonenStruct KD_Personen[7] =
 {
  {
     "Mustermann",
     "Max",
     "Heimweg 1",
     "Hohenheim",
     12342,
     &(KD_Personen[1])
  },
  {
     "Mustermann",
     "Eva",
     "Heimweg 1",
     "Hohenheim",
     12342,
     &(KD_Personen[2])
  },
  {
     "Mustermann",
     "Jan",
     "Heimweg 1",
     "Hohenheim",
     12342,
     &(KD_Personen[3])
  },
  {
     "Herrmann",
     "Jonathan",
     "Haupstraße 22",
     "Feldheim",
     3812,
     &(KD_Personen[4])
  },
  {
     "Herrmann",
     "Ines",
     "Haupstraße 22",
     "Feldheim",
     3812,
     &(KD_Personen[5])
  },
  {
     "Herrmann",
     "Julian",
     "Haupstraße 22",
     "Feldheim",
     3812,
     &(KD_Personen[6])
  },
  {
     "Herrmann",
     "Angelika",
     "Haupstraße 22",
     "Feldheim",
     3812,
     NULL
  }
  };
  • Die in dem obigen Beispiel referenzierte "KundenDaten.h" ist nachfolgend dargestellt. 
    •  typedef struct _KD_PersonenStruct
 {
  const char * const name;
  const char * const vorname;
  const char * const strasse;
  const char * const ort;
  const unsigned long long postleitzahl;
  const struct _KD_PersonenStruct * const pNext;
  } KD_PersonenStruct;
  extern const KD_PersonenStruct KD_Personen[7];
  • Die konstante Struktur ist hier voranstehend nur zur Verständlichkeit in einer Hochsprache dargestellt. Die dargestellte Form entspricht aber nicht der Form, in welcher die konstante Struktur auf das Embedded-Gerät übertragen wird. Die Übertragung auf das Embedded-Gerät erfolgt in einer verarbeitbaren (Daten-) Form, welche insbesondere für den Menschen nicht lesbar ist. Jedoch entspricht der Informationsgehalt der voranstehend gezeigten Struktur dem Informationsgehalt, welcher - in dem gewählten Beispiel - an das Embedded-Gerät übertragen würde.
  • Bevorzugt wird ein Repository einer solchen Ausgestaltung dann in einem Nurlesespeicher (ROM - Read Only Memory) des Embedded-Geräts gespeichert. Da das Repository in dieser Ausführungsform aus Konstanten besteht, ändern sich die Daten des Repositorys nach dem einmaligen Beschreiben des ROMs im Betrieb des Embedded-Geräts nicht. Aus diesem Grund kann das Repository in dem ROM gespeichert werden, wodurch sich insbesondere bei kleineren Prozessoren des Embedded-Geräts ein Kostenvorteil ergeben kann.
  • Weiter bevorzugt ist die Transformationsbeschreibung derart ausgewählt, dass ein benötigter Speicherplatz für das resultierende Repository eine solche Größe hat, dass er kleiner oder gleich dem Speicherplatz des Nurlesespeichers des Embedded-Geräts ist. Anders ausgedrückt wird das Repository derart angelegt, dass es auf den Speicherplatz eines ROMs des Embedded-Geräts angepasst ist. Dies kann beispielsweise durch eine entsprechende Wahl der Transformationsbeschreibung erreicht werden. Gegebenenfalls kann die Transformationsbeschreibung verändert werden, z.B. um Variablen mit verkürzter Zeichenfolge in dem Repository abzulegen, so dass das Repository eine gewünschte Größe besitzt. Anstelle des Repositorys können auch sämtliche von dem Transformator erzeugten Daten eine Größe aufweisen, die kleiner oder gleich dem Speicherplatz des Nurlesespeichers des Embedded-Geräts ist.
  • Gemäß einer weiteren vorteilhaften Ausführungsform enthalten die von dem Transformator erzeugten Daten Binärcode. Wird Binärcode erzeugt, ist zur Laufzeit keine Übersetzung bzw. Kompilierung notwendig, wodurch ein veränderter Betrieb des Embedded-Geräts unmittelbar nach der Übertragung der vom Transformator erzeugten Daten beginnen kann. Dabei kann der Binärcode in dem Repository und/oder der Programmstruktur enthalten sein. Bevorzugt bestehen das Repository und/oder die Programmstruktur auch vollständig aus Binärcode.
  • Vorteilhafterweise umfasst das Repository also ein Array von Strukturen (Array of Struct), wobei das Array insbesondere ein Array mit festgelegter Länge und/oder mit konstanten Werten ist. Wie bereits oben ausgeführt, kann das Array bei fester Länge im RAM und bei der alternativen oder zusätzlichen Verwendung von ausschließlich konstanten Werten im ROM des Embedded-Geräts gespeichert werden.
  • Bevorzugt greift ein Anwendungsprogramm des Embedded-Geräts mittels einer Schnittstelle auf die verarbeitbaren Daten zu. Die Schnittstelle kann dabei ein eigenes Programm sein, das den Zugriff auf das Repository und/oder die Programmstruktur ermöglicht. Bei dem Anwendungsprogramm kann es sich um eine auf dem Embedded-Gerät ausgeführte Applikation handeln, beispielsweise eine Motorsteuerung oder dergleichen. Mittels der Schnittstelle ist es insbesondere möglich, dass ein Anwendungsprogramm, welches auf einer ersten Hochsprache basiert, auf die verarbeitbaren Daten zugreifen kann, obwohl die verarbeitbaren Daten eine Struktur umfassen, die nur von einer zweiten Hochsprache nativ gelesen werden kann.
  • Gemäß einer weiteren vorteilhaften Ausführungsform umfasst der Transformator einen Filter, wobei der Filter die Eingangsdaten in eine Zwischendatei umwandelt, wobei ferner die Zwischendatei nur für das Embedded-Gerät relevante Informationen enthält. Die Zwischendatei kann somit im Vergleich zu den Eingangsdaten einen kleineren Speicherbedarf haben und die Verarbeitung durch den Transformator beschleunigen. Insbesondere können in der Zwischendatei Informationen weggelassen sein, die Zusatzfunktionen anderer Embedded-Geräte betreffen, die das (Ziel-) Embedded-Gerät nicht beherrscht. Andererseits können der Zwischendatei auch Informationen hinzugefügt sein, die z.B. der Gerätebeschreibung des Embedded-Geräts dienen. Auch kann beispielsweise die Syntax der für die Eingangsdaten verwendeten Auszeichnungssprache entfernt sein. Bevorzugt kann die Zwischendatei auch eine Binärdatei sein.
  • Weiter bevorzugt umfasst der Transformator einen Interpreter, welcher die Zwischendatei und/oder die Eingangsdaten einliest und aus den Informationen der eingelesenen Datei Werte für die Datenstruktur in dem Repository erzeugt. Die Zwischendatei kann also von dem Interpreter bzw. einem Interpreterprogramm des Transformators verwendet werden, um Werte von Variablen in dem Embedded-Gerät zur Laufzeit festzulegen. Die Zwischendatei kann noch so viele Strukturinformationen enthalten, dass der Interpreter unbekannte Elemente überlesen kann und damit auf- und abwärtskompatibel ist.
  • Der Filter des Transformators kann entweder auf einem von dem Embedded-Gerät getrennten Computersystem ausgeführt werden. Alternativ kann der Filter auch auf dem Embedded-Gerät ausgeführt werden.
  • Die Erfindung betrifft auch ein Verfahren zum Betrieb eines Embedded-Gerätes, bei dem ein Embedded-Gerät mit dem ersten erfindungsgemäßen Konfigurationsverfahren oder eines seiner vorteilhaften Ausgestaltungen konfiguriert wird oder konfiguriert worden ist und die dabei an das Embedded-Gerät übertragenen Daten zum Betrieb des Embedded-Gerätes verwendet werden.
  • Die Erfindung betrifft weiterhin gemäß Anspruch 2 ein zweites Verfahren zur Konfiguration eines Embedded-Geräts, bei welchem
    1. (a) ein Transformationsmittel (im vorliegenden Text auch einfach als Transformator bezeichnet) mittels einer Transformationsbeschreibung konfiguriert wird, wobei die Transformationsbeschreibung Vorgaben darüber enthält, welche Daten aus Eingangsdaten entnommen werden sollen, wobei die Eingangsdaten Konfigurationsdaten für das Embedded-Gerät enthalten, und wobei die Transformationsbeschreibung keinen Code in einer Programmiersprache umfasst und die Eingangsdaten vorzugsweise als XML-Datei dargestellt sind,
    2. (b) wobei zumindest ein Teil des konfigurierten Transformators an das Embedded-Gerät übertragen wird oder zumindest ein Teil des Transformators direkt im Embedded-Gerät konfiguriert wird, und wobei zumindest ein Teil der Eingangsdaten an das Embedded-Gerät übertragen wird;
    3. (c) die Eingangsdaten von dem Transformator nach den Vorgaben der Transformationsbeschreibung verarbeitet werden; und
    4. (d) der Transformator bei dieser Verarbeitung Daten erzeugt, die von dem Embedded-Gerät verarbeitbar sind und bevorzugt ein Repository umfassen,
    5. (e) wobei Informationen aus den Eingangsdaten von dem Transformator anhand der Vorgaben in der Transformationsbeschreibung entnommen werden.
  • Die von dem Transformator erzeugten Daten können dann beim Betrieb des Embedded-Geräts verwendet werden.
  • Dies zweite erfindungsgemäße Konfigurationsverfahren unterscheidet sich somit von dem erfindungsgemäßen Verfahren gemäß Anspruch 1 darin, dass der Transformator nicht vollständig außerhalb des Embedded-Geräts ausgeführt wird, sondern zumindest teilweise auf dem Embedded-Gerät ausgeführt wird.
  • Dabei versteht es sich, dass der in Schritt (b) an das Embedded-Gerät übertragene Teil der Eingangsdaten in der Regel von dem in Schritt (b) an das Embedded-Gerät übertragenen oder dort erzeugten Teil des Transformators verarbeitet wird.
  • Auch bei diesem zweiten erfindungsgemäßen Konfigurationsverfahren werden die von dem Transformator in Schritt (e) anhand der Transformationsbeschreibung aus den Eingangsdaten übernommenen Informationen bevorzugt in ein Repository übertragen, wobei das Repository insbesondere in Datenstrukturen gegliederte Variablen umfasst.
  • Bevorzugt kann der auf dem Embedded-Gerät ausgeführte Teil des Transformators dazu dienen, ein angelegtes Array of Struct zur Laufzeit mit Informationen aus den Eingangsdaten zu füllen und damit zu initialisieren.
  • Ein Teil des Transformators kann dabei auch außerhalb des Embedded-Geräts ausgeführt werden, wobei dieser Teil eine Datenstruktur für das Embedded-Gerät erzeugen kann.
  • Ansonsten gelten die zu dem Verfahren gemäß Anspruch 1 gemachten Erläuterungen und bevorzugten Ausführungsformen.
  • Die Erfindung betrifft auch ein Verfahren zum Betrieb eines Embedded-Gerätes, bei dem ein Embedded-Gerät mit dem zweiten erfindungsgemäßen Konfigurationsverfahren oder eines seiner vorteilhaften Ausgestaltungen konfiguriert wird oder konfiguriert worden ist und die dabei von dem Transformator erzeugten Daten zum Betrieb des Embedded-Gerätes verwendet werden.
  • Die Erfindung betrifft auch ein Computerprogramm mit Programmcode-Mitteln, die derart eingerichtet sind, dass eines der vorstehend erläuterten Verfahren durchgeführt wird, wenn das Programm auf einem Computer ausgeführt wird.
  • Ferner betrifft die Erfindung ein Computerprogrammprodukt mit Programmcode-Mitteln, die auf einem computerlesbaren Datenträger gespeichert sind und derart eingerichtet sind, dass wenigstens eines der vorstehend erläuterten Verfahren durchgeführt wird, wenn das Programmprodukt auf einem Computer ausgeführt wird.
  • Nachfolgend wird die Erfindung rein beispielhaft unter Bezugnahme auf die Zeichnungen beschrieben. Es zeigen:
    • Fig. 1
    eine Ausführungsform eines ersten erfindungsgemäßen Verfahrens;
    Fig. 2
    eine erste Ausführungsform eines zweiten erfindungsgemäßen Verfahrens; und
    Fig. 3
    eine zweite Ausführungsform des zweiten erfindungsgemäßen Verfahrens.
  • Fig. 1 zeigt schematisch den Ablauf einer Ausführungsform eines erfindungsgemäßen Verfahrens zur Konfigurierung beziehungsweise zum Betrieb eines Embedded-Geräts. Gemäß dem Verfahren werden Eingangsdaten, die in einer Konfigurationsdatei 10 gespeichert sind, einem Transformator 14 zugeführt. Der Transformator 14 wird mittels einer Transformationsbeschreibung 12 konfiguriert. Der Transformator 14 ist ein ausführbares Programm bzw. ein ausführbarer Code. Die Konfigurationsdatei 10 und die Transformationsbeschreibung 12 liegen in diesem Beispiel als XML-Dateien vor.
  • Der Transformator 14 umfasst einen ersten Teil 14a und einen zweiten Teil 14b. Der erste Teil 14a benötigt als Eingangswerte die Eingangsdaten aus der Konfigurationsdatei 10 und aus der Transformationsbeschreibung 12. Anhand der Transformationsbeschreibung 12 werden Daten aus der Konfigurationsdatei 10 entnommen und in binärer Form in einem Array of Struct in einem Repository 16 gespeichert. Das Repository 16 wird nach seiner Fertigstellung an ein Embedded-Gerät 18 übertragen.
  • Das Repository 16 ist wie oben beschrieben ein Datenspeicher, in welchem von dem Transformator 14 erzeugte Daten in Form eines Array of Struct zusammengefasst sein können. Bei dem Array of Struct kann es sich um ein Feld von Strukturen handeln, wobei jede Struktur eine Kombination mehrerer Variablen sein kann.
  • Der zweite Teil 14b des Transformators 14 benötigt als Eingang nur die Transformationsbeschreibung 12, wobei der zweite Teil 14b der Transformationsbeschreibung 12 entnimmt, welche Informationen aus der Konfigurationsdatei 10 in das Repository 16 übertragen werden. Für jede der verschiedenen Informationen legt der zweite Teil 14b eine Variable an, wobei die Variablen gesammelt in einer Programmstruktur 20 auf dem Embedded-Gerät 18 gespeichert werden. Die Programmstruktur 20 liegt ebenfalls in binärer Form vor und gibt an, an welchen Speicherpositionen in dem Repository 16 welche Variable gespeichert ist. In dem Repository 16 können die Variablen bereits als konstante Werte vorliegen, d. h. der Transformator 14 und insbesondere dessen erster Teil 14a erzeugt die Werte des Repositorys 16 bzw. entnimmt diese der Konfigurationsdatei 10. Das Repository 16 kann in dieser Ausführungsform in einem ROM des Embedded-Geräts 18 gespeichert sein und das ROM vollständig belegen.
  • Auf dem Embedded-Gerät 18 wird eine Applikation 22 ausgeführt, die beispielsweise einen Elektromotor (nicht gezeigt) steuert. Um den Betrieb des Elektromotors zu ermöglichen, sind in dem Repository 16 Drehzahlverläufe und Grenzwerte für die anzulegenden Ströme und Spannungen gespeichert, die aus der Konfigurationsdatei 10 entnommen sind. Die Applikation 22 greift auf die in dem Repository 16 gespeicherten Werte über ein Interface 24 zu. Um die in dem Repository 16 gespeicherten Daten korrekt zuordnen zu können, greift das Interface 24 auch auf die Programmstruktur 20 zu.
  • Um nun den Betrieb des Embedded-Geräts 18 und damit des Elektromotors zu verändern, kann die Konfigurationsdatei 10 verändert werden, woraufhin mittels der Transformationsbeschreibung 12 und des Transformators 14 automatisiert ein verändertes Repository 16 erzeugt werden kann. Beim Zugreifen der Applikation 22 auf die Daten in dem Repository 16 wird damit dann auch der Betrieb des Elektromotors an die neuen Parameter angepasst. Es ist auf diese Weise eine einfache und unaufwändige Anpassung des Betriebs des Embedded-Geräts möglich.
  • Fig. 2 zeigt eine Ausführungsform eines anderen erfindungsgemäßen Verfahrens zur Konfigurierung beziehungsweise zum Betrieb eines Embedded-Geräts 18. Diese Ausführungsform unterscheidet sich von der Ausführungsform gemäß Fig. 1 darin, dass der Transformator 14 einen Filter 26 umfasst, wobei der Filter 26 auf die Transformationsbeschreibung 12 zugreift und die Konfigurationsdatei 10 derart filtert, dass nur für das Embedded-Gerät 18 relevante Informationen in einer Zwischendatei 28 abgelegt werden. Der Filter 26 umfasst wie der Transformator 14 ausführbaren Code und kann sowohl interpretativ als auch generativ arbeiten. Die Zwischendatei 28 ist beispielsweise eine Binärdatei, die insbesondere auch keine Syntax der ursprünglichen XML-Konfigurationsdatei 10 enthält.
  • Bei diesem Ausführungsbeispiel umfasst der Transformator 14 einen Interpreter 30, welcher von dem ersten Teil 14a erzeugt wird und von dem Embedded-Gerät 18 ausgeführt wird. Der Interpreter 30 kann außerhalb des Embedded-Geräts 18, beispielsweise auf einem (nicht gezeigten) PC-System, erzeugt und anschließend an das Embedded-Gerät 18 übertragen werden.
  • Der Interpreter 30 erzeugt zur Laufzeit des Embedded-Geräts 18 aus der Zwischendatei 28, welche vorher an das Embedded-Gerät 18 übertragen wird, die Werte der Variablen in dem Repository 16. Dies bedeutet, dass das Repository 16 bei seiner Erzeugung zunächst nur nicht-initialisierte Variablen enthält, beispielsweise ein Array of Struct der Länge 1024. In diesem Ausführungsbeispiel ist das Repository 16 in einem RAM des Embedded-Geräts 18 gespeichert, um zur Laufzeit Veränderungen der Daten in dem Repository 16 vornehmen zu können. Im Übrigen gelten die Ausführungen zu dem Ausführungsbeispiel von Fig. 1.
  • In Fig. 3 ist eine abgewandelte Ausführungsform des Verfahrens der Figur 2 gezeigt. Die dritte Ausführungsform unterscheidet sich von der Ausführungsform gemäß Fig. 2 dadurch, dass der Interpreter 30 direkt die Konfigurationsdatei 10 einliest, welche dafür an das Embedded-Gerät 18 übermittelt wird, und aus dieser die in der Transformationsbeschreibung 12 festgelegten Informationen in das Repository 16 überträgt. Es erfolgt also kein Zwischenschritt über die Zwischendatei 28.
  • Mit den erfindungsgemäßen Verfahren ist es möglich, anhand von Änderungen in der Konfigurationsdatei 10 und mittels der in der Transformationsbeschreibung 12 getroffenen Festlegungen eine automatische und damit effiziente und kostensparende Konfigurierung des Betriebs des Embedded-Geräts 18 vorzunehmen.
    • Bezugszeichenliste
    • 10
    Konfigurationsdatei
    12
    Transformationsbeschreibung
    14
    Transformator
    14a
    erster Teil des Transformators
    14b
    zweiter Teil des Transformators
    16
    Repository
    18
    Embedded-Gerät
    20
    Programmstruktur
    22
    Applikation
    24
    Interface
    26
    Filter
    28
    Zwischendatei
    30
    Interpreter

    Claims (16)

    1. Verfahren zum Konfigurieren eines Embedded-Geräts (18), bei welchem
      ein Transformator (14) mittels einer Transformationsbeschreibung (12) konfiguriert wird, wobei die Transformationsbeschreibung (12) Vorgaben darüber enthält, welche Daten aus Eingangsdaten (10) entnommen werden sollen, wobei die Eingangsdaten Konfigurationsdaten für das Embedded-Gerät (18) umfassen, und wobei die Transformationsbeschreibung (12) keinen Code in einer Programmiersprache umfasst und die Eingangsdaten (10) vorzugsweise als XML-Datei dargestellt sind,
      die Eingangsdaten (10) von dem Transformator (14) nach den Vorgaben der Transformationsbeschreibung (12) verarbeitet werden,
      der Transformator (14) bei dieser Verarbeitung Daten (16, 20) erzeugt, die von dem Embedded-Gerät (18) verarbeitbar sind, und
      die von dem Transformator (14) erzeugten Daten (16, 20) an das Embedded-Gerät (18) übertragen werden.
    2. Verfahren zum Konfiguration eines Embedded-Geräts (18), bei welchem
      ein Transformator (14) mittels einer Transformationsbeschreibung (12) konfiguriert wird, wobei die Transformationsbeschreibung (12) Vorgaben darüber enthält, welche Daten aus Eingangsdaten (10) entnommen werden sollen, wobei die Eingangsdaten Konfigurationsdaten für das Embedded-Gerät (18) umfassen, und wobei die Transformationsbeschreibung (12) keinen Code in einer Programmiersprache umfasst und die Eingangsdaten (10) vorzugsweise als XML-Datei dargestellt sind,
      wobei zumindest ein Teil (30) des konfigurierten Transformators (14) an das Embedded-Gerät (18) übertragen wird oder zumindest ein Teil des Transformators (14) direkt im Embedded-Gerät konfiguriert wird, und zumindest ein Teil der Eingangsdaten an das Embedded-Gerät übertragen wird;
      die Eingangsdaten (10) von dem Transformator (14) nach den Vorgaben der Transformationsbeschreibung (12) verarbeitet werden; und
      der Transformator (14) bei dieser Verarbeitung Daten erzeugt, die von dem Embedded-Gerät (18) verarbeitbar sind,
      wobei von dem Transformator (14) Informationen aus den Eingangsdaten (10) anhand der Vorgaben in der Transformationsbeschreibung (12) entnommen werden.
    3. Verfahren nach zumindest einem der vorstehenden Ansprüche,
      dadurch gekennzeichnet, dass die verarbeitbaren Daten (16, 20) auch eine Programmstruktur (20) umfassen, welche von dem Transformator (14) erzeugt wird.
    4. Verfahren nach zumindest einem der vorstehenden Ansprüche,
      dadurch gekennzeichnet, dass die verarbeitbaren Daten (16, 20) derart angelegt sind, dass sie von einer Hochsprache, bevorzugt C oder C++, nativ gelesen werden können.
    5. Verfahren nach einem der vorstehenden Ansprüche,
      dadurch gekennzeichnet, dass die von dem Transformator (24) erzeugten Daten (16, 20), die von dem Embedded-Gerät (18) verarbeitbar sind, ein Repository (16) umfassen.
    6. Verfahren nach Anspruch 5,
      dadurch gekennzeichnet, dass von dem Transformator (14) anhand der Vorgaben in der Transformationsbeschreibung (12) Informationen aus den Eingangsdaten (10) entnommen werden und in das Repository (16) übertragen werden, wobei das Repository (16) insbesondere in Datenstrukturen gegliederte Variablen umfasst,
    7. Verfahren nach zumindest einem der Ansprüche 5 oder 6,
      dadurch gekennzeichnet, dass ausschließlich in der Transformationsbeschreibung (12) definierte Informationen in das Repository (16) übernommen werden.
    8. Verfahren nach zumindest einem der Ansprüche 5 bis 7,
      dadurch gekennzeichnet, dass der Transformator (14) die Datenstrukturen in dem Repository (16) anlegt und die Datenstrukturen beim Betrieb des Embedded-Geräts (18) mit Werten gefüllt werden, wobei das Repository (16) bevorzugt in einem wiederbeschreibbaren Speicher des Embedded-Geräts (18) gespeichert wird.
    9. Verfahren nach zumindest einem der Ansprüche 5 bis 7,
      dadurch gekennzeichnet, dass der Transformator (14) die Datenstrukturen in dem Repository (16) anlegt und mit Werten aus den Eingangsdaten (10) füllt.
    10. Verfahren nach zumindest einem der Ansprüche 5 bis 9,
      dadurch gekennzeichnet, dass die Transformationsbeschreibung (12) derart ausgewählt ist, dass ein benötigter Speicherplatz für das Repository (16) eine solche Größe hat, dass er kleiner oder gleich dem Speicherplatz eines Nurlesespeichers des Embedded-Geräts (18) ist, in dem das Repository (16) des Embedded-Gerätes (18) gespeichert wird.
    11. Verfahren nach zumindest einem der Ansprüche 5 bis 10,
      dadurch gekennzeichnet, dass
      das Repository (16) ein Array von Strukturen (array of struct) enthält, wobei das Array insbesondere ein Array mit festgelegter Länge und/oder mit konstanten Werten ist.
    12. Verfahren nach zumindest einem der vorstehenden Ansprüche,
      dadurch gekennzeichnet, dass
      der Transformator (14) einen Filter (26) umfasst und der Filter (26) die Eingangsdaten (10) in eine Zwischendatei (28) umwandelt, wobei die Zwischendatei (28) nur für das Embedded-Gerät (18) relevante Informationen enthält.
    13. Verfahren nach zumindest einem der Ansprüche 5 bis 12,
      dadurch gekennzeichnet, dass
      der Transformator (14) einen Interpreter (30) umfasst, welcher die Eingangsdaten und/oder die Zwischendatei (28) einliest und aus den Informationen der eingelesenen Daten (10, 28) Werte für die Datenstruktur in dem Repository (16) erzeugt.
    14. Verfahren zum Betrieb eines Embedded-Gerätes, bei dem das Embedded-Gerät mit einem Konfigurationsverfahren nach einem der Ansprüche 1 bis 13 konfiguriert wird und die von dem Transformator erzeugten Daten zum Betrieb des Embedded-Gerätes verwendet werden, oder
      die vom Transformator erzeugten Daten zum Betrieb des Embedded-Gerätes, das mit einem Konfigurationsverfahren nach einem der Ansprüche 1 bis 13 konfiguriert worden ist, verwendet werden.
    15. Computerprogramm mit Programmcode-Mitteln, die derart eingerichtet sind, dass ein Verfahren nach wenigstens einem der Ansprüche 1 bis 14 durchgeführt wird, wenn das Programm auf einem Computer ausgeführt wird.
    16. Computerprogrammprodukt mit Programmcode-Mitteln, die auf einem computerlesbaren Datenträger gespeichert sind und derart eingerichtet sind, dass ein Verfahren nach wenigstens einem der Ansprüche 1 bis 14 durchgeführt wird, wenn das Programmprodukt auf einem Computer ausgeführt wird.
    EP15159471.0A 2015-03-17 2015-03-17 Verfahren zum konfigurieren eines embedded-geräts Active EP3070558B1 (de)

    Priority Applications (1)

    Application Number Priority Date Filing Date Title
    EP15159471.0A EP3070558B1 (de) 2015-03-17 2015-03-17 Verfahren zum konfigurieren eines embedded-geräts

    Applications Claiming Priority (1)

    Application Number Priority Date Filing Date Title
    EP15159471.0A EP3070558B1 (de) 2015-03-17 2015-03-17 Verfahren zum konfigurieren eines embedded-geräts

    Publications (2)

    Publication Number Publication Date
    EP3070558A1 true EP3070558A1 (de) 2016-09-21
    EP3070558B1 EP3070558B1 (de) 2018-05-09

    Family

    ID=52779487

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP15159471.0A Active EP3070558B1 (de) 2015-03-17 2015-03-17 Verfahren zum konfigurieren eines embedded-geräts

    Country Status (1)

    Country Link
    EP (1) EP3070558B1 (de)

    Cited By (1)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    CN111679867A (zh) * 2020-05-29 2020-09-18 中国航空工业集团公司西安航空计算技术研究所 一种嵌入式系统配置数据生成方法

    Citations (3)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US6757587B1 (en) * 2003-04-04 2004-06-29 Nokia Corporation Method and apparatus for dynamically reprogramming remote autonomous agents
    WO2004074952A2 (en) * 2003-02-18 2004-09-02 Tokyo Electron Limited Method for automatic configuration of a processing system
    WO2005038613A2 (en) * 2003-10-17 2005-04-28 Hydralift Amclyde, Inc. Equipment component monitoring and replacement management system

    Patent Citations (3)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    WO2004074952A2 (en) * 2003-02-18 2004-09-02 Tokyo Electron Limited Method for automatic configuration of a processing system
    US6757587B1 (en) * 2003-04-04 2004-06-29 Nokia Corporation Method and apparatus for dynamically reprogramming remote autonomous agents
    WO2005038613A2 (en) * 2003-10-17 2005-04-28 Hydralift Amclyde, Inc. Equipment component monitoring and replacement management system

    Cited By (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    CN111679867A (zh) * 2020-05-29 2020-09-18 中国航空工业集团公司西安航空计算技术研究所 一种嵌入式系统配置数据生成方法
    CN111679867B (zh) * 2020-05-29 2024-02-27 中国航空工业集团公司西安航空计算技术研究所 一种嵌入式系统配置数据生成方法

    Also Published As

    Publication number Publication date
    EP3070558B1 (de) 2018-05-09

    Similar Documents

    Publication Publication Date Title
    EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
    EP2330469B1 (de) Verfahren und Entwicklungsumgebung zur Erzeugung eines ausführbaren Gesamtsteuerungsprogramms
    EP3076633A1 (de) Verfahren zur konfiguration eines webservice-gateways sowie webservice-gateway
    WO2016141998A1 (de) Vorrichtung und verfahren zum bereitstellen einer digitalen abbildung einer physikalischen entität
    EP2407842B1 (de) Verfahren zur Inbetriebnahme von Maschinen oder Maschinen einer Maschinenserie und Projektierungssystem
    EP2649497A1 (de) Vorrichtung und verfahren zur erstellung eines programms für computergesteuerte maschinen
    EP3438774B1 (de) Verfahren zur bereitstellung von funktionen innerhalb eines industriellen automatisierungssystems und automatisierungssystem
    EP2608026A1 (de) Verfahren zur Generierung eines Software-Moduls für ein Feldgerät aus einer Gerätebeschreibungsdatei sowie Gerätebeschreibungsdatei
    EP3204831B1 (de) Verfahren zur nachverfolgbaren programmierung und konfigurierung eines geräts
    EP3070558B1 (de) Verfahren zum konfigurieren eines embedded-geräts
    EP3921710B1 (de) Verfahren zur automatischen interpretation eines rohrleitungsschemas
    EP2866105A1 (de) Verfahren zur Generierung von Automatisierungsprogrammen
    EP2299341A1 (de) Editiergerät und Verfahren zur Konfigurierung von Parametern einer industriellen Automatisierungsanordnung
    EP1365297A1 (de) System und Verfahren zur Anpassung anwendungsspezifischer Funktionsbausteine für ein Automatisierungsgerät
    DE102009017816A1 (de) Verfahren zum Parametrieren von Betriebsmitteln
    EP1515207A1 (de) Automatisierungsobjekt und Verfahren zur Beschreibung eines Automatisierungsobjektes unter Verwendung einer Metasprache
    EP2787403A1 (de) Verfahren zum automatischen Erstellen eines Automatisierungsprogramms aus einer technologischen Beschreibung einer Automatisierungslösung
    WO2019101345A1 (de) Verfahren und vorrichtung zur projektierung einer spezifi-schen verfahrenstechnischen anlage
    EP4176579A1 (de) Verfahren zum betreiben eines automatisierungssystems einer maschine oder einer anlage
    EP3098672A1 (de) Konfigurationsvorrichtung und verfahren zum konfigurieren eines automatisierungssystems
    DE102013002085A1 (de) SPS-Funktionsbausteine für Energieverwaltungsfunktionalitäten
    EP1413964A2 (de) Verfahren und Vorrichtung zur automatischen Zuordnung von Datenelementen beim Modellieren eines technischen Systems
    EP2926504B1 (de) Verfahren zum betreiben eines feldbusprotokoll-fähigen feldgerätes
    WO2019037936A1 (de) Vorrichtung und verfahren zur kopplung einer maschine mit einer mehrzahl von applikationen
    DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek

    Legal Events

    Date Code Title Description
    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

    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

    17P Request for examination filed

    Effective date: 20160822

    RBV Designated contracting states (corrected)

    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

    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: 20170105

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R079

    Ref document number: 502015004169

    Country of ref document: DE

    Free format text: PREVIOUS MAIN CLASS: G05B0019418000

    Ipc: G05B0019042000

    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

    RIC1 Information provided on ipc code assigned before grant

    Ipc: G05B 19/042 20060101AFI20170908BHEP

    Ipc: G05B 19/418 20060101ALI20170908BHEP

    INTG Intention to grant announced

    Effective date: 20171009

    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: 998129

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20180515

    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: DE

    Ref legal event code: R096

    Ref document number: 502015004169

    Country of ref document: DE

    REG Reference to a national code

    Ref country code: NL

    Ref legal event code: MP

    Effective date: 20180509

    REG Reference to a national code

    Ref country code: LT

    Ref legal event code: MG4D

    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: 20180509

    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: 20180509

    Ref country code: BG

    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: 20180809

    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: 20180809

    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: 20180509

    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: 20180509

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

    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: 20180810

    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: 20180509

    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: 20180509

    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: 20180509

    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: 20180509

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

    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: 20180509

    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: 20180509

    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: 20180509

    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: 20180509

    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: 20180509

    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: 20180509

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R097

    Ref document number: 502015004169

    Country of ref document: DE

    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: 20180509

    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: 20180509

    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

    26N No opposition filed

    Effective date: 20190212

    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: 20180509

    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: 20180509

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PL

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

    Effective date: 20190317

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

    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: 20180509

    Ref country code: LU

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

    Effective date: 20190317

    REG Reference to a national code

    Ref country code: BE

    Ref legal event code: MM

    Effective date: 20190331

    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: 20190331

    Ref country code: IE

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

    Effective date: 20190317

    Ref country code: LI

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

    Effective date: 20190331

    Ref country code: GB

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

    Effective date: 20190317

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

    Ref country code: BE

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

    Effective date: 20190331

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

    Ref country code: TR

    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: 20180509

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

    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: 20180910

    Ref country code: MT

    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: 20180509

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

    Ref country code: CY

    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: 20180509

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

    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: 20180909

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

    Ref country code: HU

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

    Effective date: 20150317

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

    Ref country code: MK

    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: 20180509

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

    Ref country code: AT

    Payment date: 20240318

    Year of fee payment: 10

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: MM01

    Ref document number: 998129

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20250317

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

    Ref country code: AT

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

    Effective date: 20250317

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

    Ref country code: DE

    Payment date: 20260320

    Year of fee payment: 12

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

    Ref country code: FR

    Payment date: 20260324

    Year of fee payment: 12