WO2006050550A1 - Verfahren zum austausch von daten - Google Patents

Verfahren zum austausch von daten Download PDF

Info

Publication number
WO2006050550A1
WO2006050550A1 PCT/AT2005/000457 AT2005000457W WO2006050550A1 WO 2006050550 A1 WO2006050550 A1 WO 2006050550A1 AT 2005000457 W AT2005000457 W AT 2005000457W WO 2006050550 A1 WO2006050550 A1 WO 2006050550A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
computer system
compb
information
platform
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.)
Ceased
Application number
PCT/AT2005/000457
Other languages
English (en)
French (fr)
Inventor
Raimund Kirner
Peter Puschner
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.)
Technische Universitaet Wien
Original Assignee
Technische Universitaet Wien
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 Technische Universitaet Wien filed Critical Technische Universitaet Wien
Publication of WO2006050550A1 publication Critical patent/WO2006050550A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications

Definitions

  • the invention relates to a method for exchanging data between a first computer system and a second computer system, wherein the data is displayed on the first computer system in a first platform-specific data representation and on the second computer system in a second platform-specific data representation, and the conversion of the data between the first and second data representation is performed in both directions on the first computer system, wherein platform-specific data representation designating the binary representation of numerical data caused by the processor and compiler used.
  • platform-specific data representation designating the binary representation of numerical data caused by the processor and compiler used.
  • the two computer systems - computer system being, for example, a processor on which data is processed - can consist of completely different hardware and software structures.
  • the second computer system which is also referred to below as “target computer system” or “target”
  • the present invention the resource consumption, which for the conversion of the data into another Platformspezifische data representation is necessary is minimized.
  • the first computer system will hereinafter also be referred to as “host computer system” or "host”.
  • platform-specific data representation introduced above is intended to be explained in more detail below: In this document, this term is understood to mean the binary representation of numerical data which is caused by the computer platform used (processor and / or compiler) Parameters for this binary representation of numeric data include:
  • Total size of data field for storing data value (e.g., number of bits)
  • Geometric arrangement of the individual data bits within the data field e.g., endianity (litüe versus big endian), placement of elements of composite data within the data field, etc.
  • a computer system converts the data into the platform-specific format of the target system before it is sent or after it has been received in. its own platform-specific format. In this method, the second computer system is completely relieved of the expense of data conversion. However, this presupposes that knowledge about the internal platform-specific data format of the other computer system is known in the computer system performing the conversion.
  • a data exchange method according to method 2.b is particularly suitable for target computer systems, in which the resource consumption, which is necessary for the conversion of the data, is minimized.
  • a disadvantage of the previously known methods according to Method 2.b is that the support of the platform-specific data representation of a specific target platform a prio ⁇ must be built into the host, i. that the host must already have the necessary platform-specific information to exchange data with a specific target. The support of a new target therefore requires an explicit a priori adaptation of execution logic (e.g., software) on the host.
  • the invention relates to a resource-saving method for exchanging data between a host computer equipped with a relatively large number of available resources and a relatively scarce resource-equipped embedded system (target).
  • the embedded system uses little computing time and storage space for data transmission of the exchanged data.
  • the conversion of the data is performed on the host computer, whereby the required platform-specific information about the target is automatically calculated on the target and transmitted to the host computer.
  • the host requires a priori information about the platform-specific data format of the target, since the target itself calculates the required information and transmits it to the host.
  • the host thus takes care of the conversion of the data into the respective platform-specific data formats.
  • the target only has to determine certain characteristics of its own platform once before the first exchange of user data and send it to the host. These characteristics include, for example, endianity (endian or big endian, i.e., the order of bytes within a data word). Knowledge of the endianity is required to interpret more information.
  • An important aspect of such a data exchange method is portability to new platforms both on the host side and on the target side.
  • the method of this invention takes this into account by implementing the method for data conversion on host and target in platform-independent form. Neither the execution logic of the host nor the execution logic of the target need to be changed if the respective other system has been migrated to a new platform.
  • the method of this invention takes this into account by not requiring any special development tools for the realization.
  • the method can be realized in a platform-independent form.
  • the process can be implemented with standard system development tools.
  • the method for calculating the information on the second computer system is realized in a platform-independent form.
  • the required execution logic on the side of the target can thus be realized independently of the platform, whereby the host computer can communicate with different targets without changing its execution logic.
  • no specially adapted development tools are necessary to realize communication based on the method.
  • the platform-specific information which is calculated by the second Comptttersystem, an endian flag for describing the byte order, in which data are stored on the second computer system contains. This displays the storage strategies Little Endian and Big Endian.
  • the value of this endian flag is the first data value within the information, since it determines how the further values of the information regarding byte order are to be interpreted.
  • information about the length or value ranges of the basic data types may be contained by the second computer system.
  • the first computer system and the second computer system are connected via an electronic data channel and automatically before the first transmission of the data, the information is transmitted from the second computer system to the first computer system.
  • connection between the flat data structure of the data and the complex data structures is carried out by the second computer system via its own translation table, it is achieved that the size of the execution logic necessary for this connection is independent of type and number of data elements in the data.
  • the memory structure provides the required indirect data accesses if data types are not passed directly as value parameters to the subroutine to be tested, allowing the data exchange method of the test environment to be used without modification on different platforms.
  • FIG. 2 shows schematically the memory concept at the target for conversion between communicated data and internal data
  • FIG. 3 schematically shows the extension of the storage concept at the target in order to be able to use this data exchange method for a decentralized test environment.
  • Fig. 1 illustrates the data flow and information flow between host (CompA) and target (CompB).
  • DatAB data (DatAB) can be exchanged between host (CompA) and target (CompB)
  • the target (CompB) once transferred to the host (CompA) information (InfB) about platform properties of the target (CompB) ⁇ must. These platform properties are automatically determined on the target (CompB) by means of short calculation steps.
  • the host (CompA) has sufficient data available to know in which form the target (CompB) processes the data (DatAB).
  • the data (DatAB) can be transmitted in both directions between host and target.
  • Claim 3 describes the information content of the information (InfB). 2 shows the memory concept on the target (CompB), by means of which objects of combined data types (DatB) are transmitted as a sequence of objects of basic data types (DatAB).
  • Basic data types are data types which consist of only one numerical value. Claim 4 describes this splitting of the objects of complex data types (DatB) into their elements of basic data types (DatAB). Depending on the software development environment used, different ranges of values as well as different number representations such as integer values or decimal values are available.
  • Compound data types can consist of basic data types as well as of hierarchically composed data types. Typical forms of this composition, such as are supported in programming languages, are arrays (indexable sequence of similar data types), structures (association of any data types).
  • the objects of basic data types (DatAB) are therefore called a flat data structure, while the composite data types of data types (DatB) are referred to as a complex data structure.
  • This composition of data types can be mapped concretely to memory cells, objects of combined data types are transmitted as a sequence of objects of the basic data types.
  • the assignment of elements of the composite data types to the transmitted basic data types is possible via a table (TabB).
  • This table (TabB) contains an entry for each object of a basic data type of (DatB), this entry containing a reference to the memory location where this object is expected to be executed in the target (CompB).
  • this memory location can also be located within an object of a composite data type (DatB).
  • Fig. 3 in which an extension of the memory interface of the data exchange method for realizing a decentralized test environment is described.
  • the aim of this decentralized test environment is to run a (sub) program on the target computer system (CompB), the corresponding test data being provided by the host (Comp A) and transmitting the test result back to the host (Comp A) becomes. It may happen that the subroutine to be tested can not be called directly with the values of the test data, which is the case, for example, if the subroutine to be tested accesses the test data indirectly via other data structures In the case, these additional data structures must be set up and initialized before the test.
  • This extension for the realization of a decentralized test environment is described in claims 13 and 14.
  • test data consists of the two data sets svl and sv2 of the type Sn_t.
  • first element of the array snl should point to the test value svl and the second element should be initialized as a zero pointer.
  • the second input parameter is to be initialized directly with the test value sv2.
  • typedef struct ⁇ void * ref; int size; ⁇ data_list_t;
  • a receiving unit In the target (CompB), a receiving unit is implemented which interprets the objects of basic data types coming from the host (CompA) as a byte stream and distributes them to the corresponding memory cells which are specified in the table (TabB).
  • the memory layout of objects of composite datatypes on Host (CompA) and Target CompB is structured differently, in a resource-saving way, by subtracting on the target (CompB) the data (DatB) with the translation table (TabB) on the objects of basic datatypes in ( DatAB).
  • This example demonstrates how to realize data communication from host (CompA) to target (CompB) for a remote test environment.
  • the described data structures (table (TabB) and memory area (MGlue)) have been specified specifi cally for the (sub) program to be tested.
  • the implementation of data structures for a data exchange from Target (CompB) to Host (Comp A) follows the same pattern.
  • the platform properties described in the platform-specific information (InfB) contain in the first place the endianity (litfcte endian or big endian, i.e. the arrangement of the bytes within a data word). Knowledge of the endianity is required to interpret more information. Further additional information which may be contained in the information (InfB) are, for example, the value ranges of the basic data types.
  • the endianity could be calculated using the following platform-independent code in ANSI C:
  • FBsdata data types have internal partitioning into sign bit, exponent field, and mantissa field.
  • a compiler for ANSI C BO / IEC 9899 would already float the data for this partitioning as constants in the file. have predefined h. In the case of older compilers, however, this partitioning data can also be calculated automatically.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Devices For Executing Special Programs (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Austausch von Daten (DatAB) zwischen einem ersten Computersystem (CompA) und einem zweiten Computersystem (CompB), wobei die Daten (DatAB) auf dem ersten Computersystem (CompA) in einer ersten plattformspezifischen Datenrepräsentation und auf dem zweiten Computersystem (CompB) in einer zweiten plattformspezifischen Datenrepräsentation dargestellt werden, wobei plattformspezifische Datenrepräsentation die binäre Repräsentation von numerischen Daten bezeichnet, die durch die verwendete Plattform (Prozessor und Compiler) bedingt ist. Die Konvertierung der Daten (DatAB) zwischen der ersten und zweiten plattformspezifischen Datenrepräsentation wird in beiden Richtungen auf dem ersten Computersystem (CompA) durchgeführt, wobei die auf dem ersten Computersystem (CompA) benötigte Information (InfB) über das zweite Computersystem (CompB), welche Information (InfB) zur Umwandlung der Daten (DatAB) für beide Richtungen des Datenaustausches notwendig ist, vollständig auf dem zweiten Computersystem (CompB) berechnet wird.

Description

VERFAHREN ZUM AUSTAUSCH VON DATEN
Die Erfindung betrifft ein Verfahren zum Austausch von Daten zwischen einem ersten Computersystem und einem zweiten Computersystem, wobei die Daten auf dem ersten Computersystem in einer ersten plattformspezifischen Datenrepräsentation und auf dem zweiten Computersystem in einer zweiten plattformspezifischen Datenrepräsentation dargestellt werden, und die Konvertierung der Daten zwischen der ersten und zweiten Datenrepräsentation in beiden Richtungen auf dem ersten Computersystem durchgeführt wird, wobei plattformspezifische Datenrepräsentation die die binäre Repräsentation von numerischen Daten bezeichnet, die durch verwendeten Prozessor und Compiler bedingt ist. Diese konkrete Definition von plattformspezifischer Datenrepräsentation ist wesentlich für die Problemstellung und der Lösung durch die vorliegende Erfindung. Im Folgenden be¬ zeichnen heterogene Computersysteme jene Computersysteme, welche eine unterschiedliche plattformspezifischer Datenrepräsentation aufweisen.
Die beiden Computersysteme - unter Computersystem ist dabei beispielsweise ein Prozessor auf dem Daten verarbeitet werden zu verstehen - können dabei aus völlig unterschiedlichen Hardware- und Softwarestrukturen bestehen. Insbesondere eignet sich die vorliegende Erfindung, wie weiter unten noch erläutert, wenn auf dem zweiten Computersystem, wel¬ ches im folgenden auch als „Target-Computersystem" oder „Target" bezeichnet wird, der Ressourcenverbrauch, welcher für die Umwandlung der Daten in eine andere plattformspe¬ zifische Datenrepräsentation nötig ist, minimiert ist. Das erste Computersystem wird im folgenden auch als „Host-Computersystem" oder „Host" bezeichnet.
Im Folgenden soll der oben eingeführte Begriff der „plattformspezifischen Datenrepräsenta¬ tion" näher erläutert werden. In diesem Dokument wird unter diesem Begriff die binäre Repräsentation von numerischen Daten, welche durch die verwendete Computerplattform (Prozessor und/ oder Compiler) bedingt ist, verstanden. Relevante Parameter für diese binäre Repräsentation von numerischen Daten sind beispielsweise:
• Gesamtgröße des Datenfeldes zur Speicherung von Datenwertes (z.B. Anzahl der Bits)
• Adressausrichtung des Datenfeldes (d.h., von welcher Größe die konkrete Adresse des Datenfeldes immer ein Vielfaches sein muss) • Binäre Kodierung von Zahlen (z.B., Einer- bzw. Zweierkomplement für ganzzahlige Werte, oder IEEE-Format für Fließkommazahlen, etc.)
• Geometrische Anordnung der einzelnen Datenbits innerhalb des Datenfeldes (z.B., Endianität (litüe versus big endian), Platzierung von Elementen zusammengesetzter Daten innerhalb des Datenfeldes, etc.)
Das Problem der Konvertierung von Daten zum Austausch von Informationen zwischen heterogenen Computersystemen ist schon relativ lange bekannt, da sich die plattformspezifi¬ schen Datenformate von verschiedenen Computersystemen und den darauf laufenden Programmen typischerweise in gewissen Details zu einander unterscheiden. Prinzipiell gibt es zwei Arten, mit dem Problem der unterschiedlichen Datenformate umzugehen:
1. Austausch der Daten über ein einheitliches Zwischenformat: Jedes Computersystem muss dann die Daten zwischen dem internen plattformspezifischen Format und dem einheitlichen Zwischenformat konvertieren. Der Vorteil dieser Methode ist, dass Computersysteme Daten austauschen können ohne gegenseitiges Wissen über die jeweils verwendeten plattformspezifischen Datenformate zu besitzen. Der Nachteil dieser Methode ist mangelnde Effizienz, da gewisse Aspekte der Datenrepräsentation oft unnötig konvertiert werden müssen.
2. Austausch der Daten über ein plattformspezifisches Datenformat: Daten werden da¬ bei nur dann konvertiert, wenn es auf grund der plattformspezifischen Datenformate der beteiligten Computersysteme notwendig ist. Der Vorteil dieser Methode ist, dass die Datenkonvertierung effizienter als bei der ersten Methode realisierbar ist, da un¬ nötige Konvertierungen vermieden werden. Grundsätzlich sind zwei Varianten denkbar:
a. Symmetrisch: Jedes System konvertiert die Daten im Bedarfsfalle nur beim Empfangen (bzw. nur beim Senden). Damit übernehmen beide Computersys¬ teme einen Teil der notwendigen Datenkonvertierung. Diese Methode kann beispielsweise realisiert werden, indem zu Beginn der übertragenen Daten ei¬ ne Formatbeschreibung der plattformspezifischen Datenrepräsentation hin¬ zugefügt wird. Nachteilig an dieser Variante ist dabei, dass beide Cσmputer- systeme mit der Datenkonvertierung beschäftigt sind.
b. Asymmetrisch: Ein Computersystem wandelt die Daten vor dem Senden in das plattformspezifische Format des Zielsystems bzw. nach dem Empfangen in. das eigene plattformspezifische Format um. Bei dieser Methode ist das zweite Computersystem völlig vom Aufwand der Datenkonvertierung entlas¬ tet. Dies setzt allerdings voraus, dass bei dem die Konvertierung durchfüh¬ renden Computersystem Wissen über das interne plattformspezifische Daten¬ format des anderen Computersystems bekannt ist.
Ein Datenaustauschverfahren nach Methode 2.b eignet sich besonders für Target- Computersysteme, bei denen der Ressourcenverbrauch, welcher für die Umwandlung der Daten nötig ist, minimiert ist. Nachteilig an den bisher bekannten Verfahren nach Methode 2.b ist allerdings, dass die Unterstützung der plattformspezifischen Datenrepräsentation einer konkreten Target-Plattform a prioή in den Host eingebaut sein muss, d.h. dass der Host über die notwendigen plattformspezifischen Informationen für den Datenaustausch mit einem bestimmten Target bereits verfügen muss. Die Unterstützung eines neuen Targets erfordert daher eine explizite a priori Anpassung Ausführungslogik (z.B. Software) auf dem Host.
Es ist eine Aufgabe der Erfindung, ein Datenaustauschverfahren nach Methode 2.b dahin¬ gehend zu verbessern, dass auch für neue Targets eine solche Anpassung der Ausführungs¬ logik (z.B. Software) auf dem Host-Computersystem nicht notwendig ist.
Diese Aufgabe wird mit einem eingangs erwähnten Verfahren dadurch gelöst, dass erfin¬ dungsgemäß die auf dem ersten Computersystem benötigte plattformspezifische Informati¬ on über das zweite Computersystem, welche Information zur Umwandlung der Daten für beide Richtungen des Datenaustausches notwendig ist, vollständig auf dem zweiten Compu¬ tersystem berechnet wird.
Die oben genannte Aufgabe wird weiters noch mit einem entsprechenden platfform- unabhängigen Verfahren mit einem entsprechenden Target-Computersystem sowie mit einer Testumgebung wie in den Ansprüchen dargelegt gelöst.
Die Erfindung betrifft ein ressourcensparendes Verfahren zum Datenaustausch zwischen einem, mit relativ vielen verfügbaren Ressourcen ausgestatteten Hostcomputer und einem mit relativ knappen Ressourcen ausgestatteten Eingebetteten System (Target). Das eingebet¬ tete System verwendet zur Datenübertragung der ausgetauschten Daten wenig Rechenzeit und Speicherplatz. Die Konvertierung der Daten wird auf dem Hostcomputer durchgeführt, wobei die hierzu benötigten plattformspezifischen Informationen über das Target automatisch auf dem Target berechnet und an den Hostcomputer übertragen werden.
Zugleich wird beim Host a priori kerne Information über das plattformspezifische Daten¬ format des Targets benötigt, da das Target die benötigte Information selbst berechnet und an den Host überträgt.
Der Host kümmert sich somit um die Konvertierung der Daten in die jeweiligen plattform¬ spezifischen Datenformate. Das Target muss dabei lediglich einmal vor dem ersten Aus¬ tausch von Nutzdaten gewisse Kenngrößen der eigenen Plattform bestimmen und an den Host schicken. Diese Kenngrößen enthalten beispielsweise die Endianität (litüe endian oder big endian, d.h. die Anordnung der Bytes innerhalb eines Datenwortes). Das Wissen über die Endianität ist erforderlich, um weitere Informationen interpretieren zu können.
Ein wichtiger Aspekt bei einem solchen Datenaustauschverfahren ist die Portierbarkeit auf neue Plattformen sowohl auf Seite des Hosts wie auch auf Seite des Targets. Das Verfahren dieser Erfindung trägt dem Rechnung, indem das Verfahren zur Datenkonvertierung auf Host und Target in plattform-unabhängiger Form realisierbar ist. Weder die Ausführungslo¬ gik des Hosts noch die Ausführungslogik des Targets brauchen geändert werden, wenn das jeweils andere System auf eine neue Plattform migriert wurde.
Um ein Datenaustauschverfahren einzusetzen ist es auch wichtig, dass es mit den Entwick¬ lungswerkzeugen, welche für eine konkrete Computerplattform zur Verfügung stehen, kompatibel ist. Das Verfahren dieser Erfindung trägt dem Rechnung, indem es für die Realisierung keinerlei spezielle Entwicklungswerkzeuge benötigt. Das Verfahren ist in plattform-unabhängiger Form realisierbar.
Das Verfahren lässt sich mit Standard-Werkzeugen zur Systementwicklung realisieren. Vorzugsweise ist entsprechend Anspruch 2 das Verfahren zur Berechnung der Information auf dem zweiten Computersystem in plattform-unabhängiger Form realisiert. Der benötigte Ausführungslogik auf Seite des Targets lässt sich somit plattform-unabhängig realisieren, wobei der Hostcomputer ohne Änderung seiner Ausführungslogik mit unterschiedlichen Targets kommunizieren kann. Es sind somit keine speziell angepassten Entwicklungswerk¬ zeuge notwendig, um eine Kommunikation basierend auf dem Verfahren zu realisieren. Entsprechend Anspruch 3 ist vorgesehen, dass die plattformspezifische Information, welche von dem zweiten Comptttersystem berechnet wird, ein Endian-Flag zur Beschreibung der Byte-Reihenfolge, in welcher Daten auf dem zweiten Computersystein abgelegt werden, enthält. Damit werden die Speicherstrategien Little Endian bzw. Big Endian dargestellt. Der Wert dieses Endian-Flags ist der erste Datenwert innerhalb der Information, da dieser bestimmt, wie die weiteren Werte der Information bezüglich Byte-Reihenfolge zu interpre¬ tieren sind. Weiters können noch Informationen über die Länge oder Wertebereiche der Grunddatentypen von dem zweiten Computersystem enthalten sein.
Um das Problem der unterschiedlichen internen Adressausrichtung komplexer Datentypen auf Host und Target zu umgehen, ist entsprechend Anspruch 4 vorgesehen, dass in den Daten die Werte von Objekten komplexer Datentypen, wie beispielsweise Strukturen, in flacher Form, d.h. als Sequenz von in den Objekten komplexer Datentypen enthaltenen Elementen von Grunddatentypen, gespeichert werden.
Gemäß Anspruch 5 ist weiters vorgesehen, dass das erste Computersystem und das zweite Computersystem über einen elektronischen Datenkanal verbunden sind und automatisch vor der ersten Übermittlung der Daten die Information von dem zweiten Computersystem auf das erste Computersystem übertragen wird.
Mit den Merkmalen des Anspruchs 6, nämlich dass von dem zweiten Computersystem die Verbindung zwischen der flachen Datenstruktur der Daten und den komplexen Datenstruk¬ turen über eine eigene Übersetzungstabelle durchgeführt wird, wird erreicht, dass die Größe der für diese Verbindung notwendigen Ausführungslogik unabhängig ist von Typ und Anzahl der Datenelemente in den Daten.
Weiters ist noch vorgesehen, dass die für die Verbindung zwischen den übertragenen Objek¬ ten von Grunddatentypen und den am Target verwendeten Objekten von komplexen Daten¬ typen sowie für die Berechnung der Information notwendigen Transformationsschritte vollständig als plattform-unabhängiges Verfahren spezifiziert sind.
Durch diese Merkmale ergibt es sich, dass das erfindungsgemäße Verfahren ohne Änderung weiterhin funktioniert, sollte ein bestimmtes Target-Computersystem durch ein anderes Target, welches unterschiedliche Hardware- und/ oder Softwarestrukturen aufweist, ersetzt werden. Das Verfahren kann also sehr leicht auf unterschiedliche Plattformen portiert werden. Insgesamt lässt sich feststellen, dass das Verfahren keine spezielle Unterstützung seitens der Entwicklungswerkzeuge benötigt, womit die PortahÜität des Verfahrens auch diesbezüglich erreicht wird. Die Umwandlung der Daten auf Seite des Host-Computersystems kann unter Zuhilfenahme der plattformspezifischen Information in plattform-unabhängiger Form realisiert werden und muss nur die Umwandlung aller Grunddatentypen zwischen den beiden Plattformen unterstützen.
Neben dem oben beschriebenen Verfahren, einem Computersystem entsprechend den Ansprüchen 8 -12 wird die eingangs genannte Aufgabe auch noch mit einer Testumgebung gelöst entsprechend den Ansprüchen 13, 14.
Bei dieser Testumgebung stellt die Speicherstruktur die benötigten indirekten Datenzugriffe bereit, falls Datentypen nicht direkt als Wert-Parameter an das zu testende (Unterprogramm übergeben werden. Damit kann das Datenaustauschverfahren der Testumgebung ohne Änderung auf unterschiedlichen Plattformen verwendet werden.
Im Folgenden ist die Erfindung an Hand der Zeichnung näher erläutert. In dieser zeigt
Fig. 1 Informationsfluss zwischen Host und Target,
Fig. 2 schematisch das Speicherkonzept am Target zur Umwandlung zwischen kommuni¬ zierten Daten und internen Daten benutzt wird, und
Fig. 3 schematisch die Erweiterung des Speicherkonzeptes am Target, um dieses Datenaus¬ tauschverfahren für eine dezentrale Testumgebung verwenden zu können.
Fig. 1 veranschaulicht den Datenfluss und Informationsfluss zwischen Host (CompA) und Target (CompB). Hierzu ist festzuhalten, dass bevor Daten (DatAB) zwischen Host (CompA) und Target (CompB) ausgetauscht werden können, das Target (CompB) einmal an den Host (CompA) Informationen (InfB) über Plattform-Eigenschaften des Targets (CompB) übertra¬ gen muss. Diese Plattformeigenschaften werden auf dem Target (CompB) automatisch mittels kurzer Berechnungsschritte ermittelt. Sobald die Information (InfB) vom Host (Com¬ pA) empfangen wurde, hat der Host (CompA) ausreichend Daten zur Verfügung, um zu wissen, in welcher Form das Target (CompB) die Daten (DatAB) verarbeitet. Die Daten (DatAB) können in beide Richtungen zwischen Host und Target übertragen werden. Die notwendige Konvertierung des Datenformates der Daten (DatAB) wird zur Gänze auf Seite des Hosts (CompA) durchgeführt Anspruch 3 beschreibt den Informationsgehalt der Infor¬ mationen (InfB). Fig. 2 zeigt das Speicherkonzept auf dem Target (CompB), mittels dessen Objekte zusam¬ mengesetzter Datentypen (DatB) als Sequenz von Objekten von Grunddatentypen (DatAB) übertragen werden.
Als Grunddatentypen werden dabei Datentypen bezeichnet, welche nur aus einem Zahlen¬ wert bestehen. Anspruch 4 beschreibt diese Aufsplittung der Objekte komplexer Datentypen (DatB) in deren Elemente von Grunddatentypen (DatAB). Abhängig von der verwendeten Software-Entwicklungsumgebung stehen hierfür unterschiedliche Wertebereiche sowie unterschiedliche Zahldarstellungen wie etwa ganzzahlige Werte oder Dezimalwerte zur Verfügung. Zusammengesetzte Datentypen können aus Grunddatentypen, sowie aus hierar¬ chisch zusammengesetzten Datentypen, bestehen. Typische Formen dieser Zusammenset¬ zung, wie sie etwa in Programmiersprachen unterstützt werden, sind Arrays (indizierbare Sequenz gleichartiger Datentypen), Strukturen (Verband beliebiger Datentypen). Bei den Objekten von Grunddatentypen (DatAB) spricht man daher von einer flachen Datenstruktur, während man bei den zusammengesetzten Datentypen von Datentypen (DatB) von einer komplexen Datenstruktur spricht.
Da es sehr viele unterschiedliche Möglichkeiten gibt, wie diese Zusammensetzung von Datentypen konkret auf Speicherzellen abgebildet werden kann, werden Objekte zusam¬ mengesetzter Datentypen als Sequenz von Objekten der Grunddatentypen übertragen. Die Zuordnung von Elementen der zusammengesetzten Datentypen auf die übertragenen Grunddatentypen wird über eine Tabelle (TabB) ermöglicht. Diese Tabelle (TabB) enthält einen Eintrag für je ein Objekt eines Grunddatentypes von (DatB), wobei dieser Eintrag eine Referenz auf den Speicherplatz enthält, wo dieses Objekt für die Programmausführung im Target (CompB) erwartet wird. Dieser Speicherplatz kann sich somit natürlich auch inner¬ halb eines Objektes eines zusammengesetzten Datentypes aus (DatB) befinden.
Nun sei auf Fig. 3 Bezug genommen, in welcher eine Erweiterung des Speicherinterfaces des Datenaustauschverfahrens zur Realisierung einer dezentralen Testumgebung beschrieben ist. Ziel dieser dezentralen Testumgebung ist es, auf dem Target-Computersystem (CompB) ein (Unter)Programm laufen zu lassen, wobei die entsprechenden Testdaten vom Host (Comp A) bereitgestellt werden und das Testergebnis zurück an den Host (Comp A) übertra¬ gen wird. Es kann dabei vorkommen, dass das zu testende (Unterprogramm nicht direkt mit den Werten der Testdaten aufgerufen werden kann. Dies ist beispielsweise dann der Fall, wenn das zu testende (Unter)Programm auf die Testdaten indirekt über andere Datenstruk¬ turen zugreift. In diesem Fall müssen vor dem Test diese zusätzlichen Datenstrukturen aufgebaut und initialisiert werden. Der dafür notwendige Speicherbereich ist mit (MGlue) benannt Diese Erweiterung für die Realisierung einer dezentralen Testumgebung ist in Anspruch 13 und 14 beschrieben.
Beispielhafte Realisierung der Datenstrukturen
Im folgenden sei anhand eines Beispieles verdeutlicht, wie die beschriebenen Speicherberei¬ che für das Datenaustauschverfahren und eine darauf aufbauende Testumgebung realisiert und verwendet werden können. Das Datenaustauschverfahren lässt sich sowohl in Hard¬ ware als auch in Software realisieren. Da sich jedoch mit Programmiersprachen eine Ausfüh¬ rungslogik sehr kompakt und in einem allgemein bekannten Format darstellen lässt, wurde zur Beschreibung gewisser Mechanismen die Programmiersprache ANSI C gewählt. Die Konzepte der Testumgebung werden ebenfalls für die Programmiersprache ANSI C skiz¬ ziert.
Angenommen, es sei auf dem Target CompB das Unterprogramm
typedef struct { int a [3] ; char b ; } Sn_t ;
void test (Sn_t *snl [20] , Sn_t sn2 ) ;
zu testen. Um die flexiblen Möglichkeiten durch den Speicherbereich (MGlue) zu demonst¬ rieren, sei angenommen, dass die relevanten Testdaten aus den zwei Datensätzen svl und sv2 vom Typ Sn_t bestehen. Weiters sei festgelegt, dass bezüglich der Eingabeparameter des zu testenden Unterprogramms das erste Element des Arrays snl auf den Testwert svl zeigen soll und das zweite Element als Null-Pointer initialisiert sein soll. Der zweite Einga¬ beparameter soll direkt mit dem Testwert sv2 initialisiert werden.
Um die Testdaten lokal auf dem Target (CompB) speichern zu können, ist folgender Spei¬ cherbereich zu allokieren:
Sn_t svl , sv2 ;
Da die zu testende Prozedur im ersten Argument eine komplexere Datenstruktur benutzt, ist zusätzlicher Speicherbereich (MGlue) zum Aufbau der komplexen Datenstruktur (DatB) zu allokieren:
Sn t *av [20] ; welcher mit folgenden Werten initialisiert wird:
av[0] = av[0] = &svl;
av[l] = (Sn_t*) 0;
Die zu testende Prozedur könnte nun folgendermaßen aufgerufen werden:
test (av, sv2) ;
Für den Empfang der vom Host (Comp A) kommenden Testdaten kann nun auf dem Target (CompB) folgende Übersetzungstabelle (TabB) verwendet werden:
typedef struct { void *ref; int size; } data_list_t ;
data_list_t data[] = { \
{ &(svl.a), sizeof (svl.a) }, \
{ &(svl.b), sizeof (svl .b) }, \
{ &(sv2.a), sizeof (sv2. a) }, \
{ &(sv2.a), sizeof (sv2.b) } } ;
Im Target (CompB) wird eine Empfangseinheit realisiert, welche die Objekte von Grundda¬ tentypen kommend vom Host (CompA) als Bytestrom interpretiert und auf die entspre¬ chenden Speicherzellen, welche in der Tabelle (TabB) spezifiziert sind, verteilt. Dass das Speicherlayout von Objekten zusammengesetzter Datentypen auf Host (CompA) und Target CompB anders aufgebaut ist, wird auf ressourcensparende Weise abstrahiert, indem auf dem Target (CompB) die Daten (DatB) mit der Übersetzungstabelle (TabB) auf die Objekte von Grunddatentypen in (DatAB) aufgeteilt werden.
Mit diesem Beispiel wurde demonstriert, wie man eine Datenkommunikation von Host (CompA) nach Target (CompB) für eine dezentrale Testumgebung realisieren kann. Die beschriebenen Datenstrukturen (Tabelle (TabB) und Speicherbereich (MGlue) ) sind spezi¬ fisch für das zu testende (Unter)Programm angegeben worden. Die Realisierung von Datenstrukturen für einen Datenaustausch von Target (CompB) nach Host (Comp A) folgt demselben Schema.
Beispielhafte Berechnung der Plattform-Eigenschaften
Im Folgenden wird die Realisierungsmöglichkeit der automatischen Berechnung der Platt¬ form-Eigenschaften (Information (InfB) ) auf Seite des Targetsystems (CompB) beschrieben. Die verwendeten Beispiele sollen bloß das Prinzip verdeutlichen und stellen keine Ein¬ schränkung des Schutzumfangs wie in den Ansprüchen definiert dar.
Für den Zeitpunkt, wann die plattformspezifische Information (InfB) berechnet wird, gibt es mehrere Möglichkeiten. Um möglichst viele Ressourcen auf dem Target (CompB) einzuspa¬ ren, wäre es etwa denkbar, die Berechnung der Informationen (InfB) als eigenständiges Programm auf dem Target (CompB) laufen zu lassen und die plattformspezifische Informa¬ tionen (InfB) auf dem Hostsystem (CompA) abzuspeichern für die spätere Kommunikation mit dem Target (CompB). Eine alternative Möglichkeit wäre, die Berechnung der plattform¬ spezifischen Informationen (InfB) direkt in den Applikationscode des Targets (CompB) aufzunehmen, was allerdings zusätzliche Bytes an Programmcode belegt.
Die Plattform-Eigenschaften, welche in den plattformspezifischen Informationen (InfB) beschrieben sind, enthalten an erster Stelle die Endianität (litfcte endian oder big endian, d.h. die Anordnung der Bytes innerhalb eines Datenwortes). Das Wissen über die Endianität ist erforderlich, um weitere Informationen interpretieren zu können. Weitere Zusatzinformati¬ on, die in den Informationen (InfB) enthalten sein können, sind beispielsweise die Wertebe¬ reiche der Grunddatentypen.
Die Endianität könnte etwa mit folgendem plattformunabhängigen Programmcode in ANSI C berechnet werden:
int e = 1 ;
if (* ( (char * ) &e) == 1 ) endian=LITTLE; eise endian=BIG;
Die Wertebereiche von integralen Grunddatentypen könnten mit folgendem Programmcode in ANSI C berechnet werden:
sizeof (char) , sizeof (unsigned char) , sizeof ( short) , sizeof (unsigned Short) ,
sizeof ( int ) , sizeof (unsigned int ) ,
sizeof ( long) , sizeof (unsigned long)
Bei den Grunddatentypen für Fließkommazahlen verhält sich die Berechnung ähnlich. Die Länge dieser Grunddatentypen kann analog berechnet werden:
sizeof ( float ) , sizeof (double)
Zusätzlich jedoch haben diese FBeßkomma-Datentypen eine interne Partitionierung in Vorzeichenbit, Exponentenfeld und Mantissenfeld. Ein Compiler für ANSI C BO/ IEC 9899 würde die Daten für diese Partitionierung bereits als Konstanten in der Datei float . h vordefiniert haben. Im Falle von älteren Compilern lassen sich diese Partitionierungsdaten allerdings auch automatisch berechnen.
Wien, den

Claims

PATENTANSPRÜCHE
1. Verfahren zum Austausch von Daten (DatAB) zwischen einem ersten Computersystem (CompA) und einem zweiten Computersystem (CompB), wobei die Daten (DatAB) auf dem ersten Computersystem (CompA) in einer ersten plattformspezifischen Datenrepräsentation und auf dem zweiten Computersystem (CompB) in einer zweiten plattformspezifischen Datenrepräsentation dargestellt werden, und die Konvertierung der Daten (DatAB) zwi¬ schen der ersten und zweiten plattformspezifischen Datenrepräsentation in beiden Richtun¬ gen auf dem ersten Computersystem. (CompA) durchgeführt wird, wobei plattformspezifi¬ sche Datenrepräsentation die binäre Repräsentation von Daten bezeichnet die durch ver¬ wendeten Prozessor und/ oder Compiler des jeweiligen Computersystems (CompA, CompB) bedingt ist
dadurch gekennzeichnet, dass
die auf dem ersten Computersystem (CompA) benötigte Information (InfB) über das zweite Computersystem (CompB), welche Information (InfB) zur Umwandlung der Daten (DatAB) für beide Richtungen des Datenaustausches notwendig ist, vollständig auf dem zweiten Computersystem (CompB) berechnet wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren zur Berech¬ nung der Information (Inf B) auf dem zweiten Computersystem (CompB) in plattformunab¬ hängiger Form realisiert ist.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Information (InfB), welche von dem zweiten Computersystem (CompB) berechnet wird, ein Endian-Flag zur Beschreibung der Byte-Reihenfolge, in welcher Daten auf dem zweiten Computersystem. (CompB) abgelegt werden, enthalt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in den Daten (DatAB) die Werte von Objekten komplexer Datentypen (DatB) der Daten am Target, wie beispielsweise Strukturen, in flacher Form, d.h. als Sequenz der in den komplexen Datentypen enthaltenen Grunddatentypen, gespeichert werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet dass das erste Computersystem (CompA) und das zweite Computersystem (CompB) über einen elektroni¬ schen Datenkanal verbunden sind und automatisch vor der ersten Übermittlung der Daten (DatAB) die Information (InfB) von dem zweiten Computersystem (CompB) auf das erste Computersystem (CompA) übertragen wird.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass von dem zweiten Computersystem (CompB) die Verbindung zwischen den übertragenen Daten mit flachen Datenstruktur (DatAB) und den Objekten komplexer Datenstrukturen (DatB) über eine eigene Übersetzungstabelle (TabB) durchgeführt wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die für die Transformation zwischen den übertragenen Daten (DatAB) und den Objekten komplexer Datentypen (DatB) sowie die Berechnung der Information (InfB) notwendigen Transformati¬ onsschritte vollständig als plattformspezifisches Verfahren spezifiziert sind.
8. Computer System (CompB) für ein Verfahren nach einem der Ansprüche 1 bis 7, welches dazu eingerichtet ist, die auf einem ersten Computersystem (CompA) benötigte Information (InfB) über das zweite Computersystem (CompB), welche Information (InfB) zur Umwand¬ lung der Daten (DatAB) für beide Richtungen des Datenaustausches notwendig ist (InfB), vollständig zu berechnen.
9. Computersystem (CompB) nach Anspruch 8, dadurch gekennzeichnet, dass das Verfah¬ ren zur Berechnung der Information (InfB) auf dem zweiten Computersystem (CompB) in plattformunabhängiger Form realisiert ist.
10. Computersystem (CompB) nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass die für die Berechnung der Information (InfB) notwendigen Ressourcen nach erfolgter Berech¬ nung der Information (InfB) anschließend für andere Aufgaben wiederverwendet werden können.
11. Computersystem nach einem der Ansprüche 8 bis 10, dadurch gekennzeichnet dass die Information (InfB), welche von diesem Computersystem (CompB) berechnet wird, ein Endian-Flag zur Beschreibung der Byte-Reihenfolge, in welcher Daten auf diesem Compu¬ tersystem (CompB) abgelegt werden, enthält.
12. Computersystem nach einem der Ansprüche 8 bis 11, dadurch gekennzeichnet/ dass in den Daten (DatAB) die Werte von Objekten komplexer Datentypen, wie beispielsweise Strukturen, in flacher Form, d.h. als Sequenz der in den Objekten komplexer Datentypen enthaltenen Elementen von Grunddatentypen, gespeichert werden.
13. Testumgebung basierend auf dem Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass auf einem zweiten Computersystem (CompB) das zu testende (Un- ter)Programm ausgeführt wird, wobei Textvektoren von dem ersten Computersystem (CompA) empfangen werden sowie Testergebnisse zurück an das erste Computersystem (CompA) übertragen werden, und wobei eine Speicherstruktur (MGlue) verwendet wird, welche die Anbindung der Test-Daten (DatB) an ein Programminterface (DatBInt) des zu testenden (Unter)Programmes realisiert.
14. Testumgebung nach Anspruch 13, dadurch gekennzeichnet, dass die Beschreibung und Initialisierung der Speicherstruktur (MGlue) mit den beiden Interfaces (DatB) und (DatBInt) auf Quellcodeebene als plattformunabhängiges Verfahren realisiert ist.
PCT/AT2005/000457 2004-11-15 2005-11-15 Verfahren zum austausch von daten Ceased WO2006050550A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AT19032004A AT501854B1 (de) 2004-11-15 2004-11-15 Verfahren zum austausch von daten
ATA1903/2004 2004-11-15

Publications (1)

Publication Number Publication Date
WO2006050550A1 true WO2006050550A1 (de) 2006-05-18

Family

ID=36095851

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AT2005/000457 Ceased WO2006050550A1 (de) 2004-11-15 2005-11-15 Verfahren zum austausch von daten

Country Status (2)

Country Link
AT (1) AT501854B1 (de)
WO (1) WO2006050550A1 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020124118A1 (en) * 2001-01-04 2002-09-05 Colley Adrian E. Method and system for passing objects in a distributed system using serializatin contexts
US20030179112A1 (en) * 2002-03-22 2003-09-25 Parry Travis J. Systems and methods for data conversion
US6772413B2 (en) * 1999-12-21 2004-08-03 Datapower Technology, Inc. Method and apparatus of data exchange using runtime code generator and translator

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261080A (en) * 1987-08-21 1993-11-09 Wang Laboratories, Inc. Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formats
DE19744293C1 (de) * 1996-06-26 1999-07-01 Fraunhofer Ges Forschung Verschlüsselung und Entschlüsselung von Multimediadaten
US6826597B1 (en) * 1999-03-17 2004-11-30 Oracle International Corporation Providing clients with services that retrieve data from data sources that do not necessarily support the format required by the clients
DE10054887A1 (de) * 2000-11-06 2002-05-08 Fileants Com Ag Verfahren zum Austausch von Daten in einem Netzwerk, Vorrichtung zur Durchführung des Verfahrens, Computerprogramm zum Durchführen desselben und Datenträger, auf dem ein solches gespeichert ist
DE10125383B4 (de) * 2000-12-15 2006-12-14 Siemens Ag Verschlüsselung von Steuerungsprogrammen
JP2003058361A (ja) * 2001-08-20 2003-02-28 Oki Electric Ind Co Ltd データ転送方法およびデータ変換装置
EP1298525A1 (de) * 2001-09-26 2003-04-02 Sap Ag Interaktion zwischen Computern mit unterschiedlichen Objekt-orientierten Laufzeitumgebungen
US20030061062A1 (en) * 2001-09-26 2003-03-27 Tucker Timothy J. XML data switch
US7707077B2 (en) * 2002-03-28 2010-04-27 Sap Ag Electronic financial transaction with balancing invoice and credit items via page

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6772413B2 (en) * 1999-12-21 2004-08-03 Datapower Technology, Inc. Method and apparatus of data exchange using runtime code generator and translator
US20020124118A1 (en) * 2001-01-04 2002-09-05 Colley Adrian E. Method and system for passing objects in a distributed system using serializatin contexts
US20030179112A1 (en) * 2002-03-22 2003-09-25 Parry Travis J. Systems and methods for data conversion

Also Published As

Publication number Publication date
AT501854B1 (de) 2008-03-15
AT501854A1 (de) 2006-11-15

Similar Documents

Publication Publication Date Title
DE68919631T2 (de) Verfahren zur Verarbeitung von Programmteilen eines verteilten Anwendungsprogramms durch einen Hauptrechner und einen intelligenten Arbeitsplatz in einer SNA LU 6.2-Netzwerkumgebung.
DE68919976T2 (de) Verfahren zur Herstellung von aktuellen Terminaladressen für Systemanwender die verteilte Anwendungsprogramme in einer SNA LU 6.2-Netzwerkumbegung verarbeiten.
DE69405408T2 (de) Objektorientiertes system und verfahren zur hardwarekonfiguration
DE69329577T2 (de) Verfahren und system für implementierung-unabhängige schnittstellenspezifikation
DE69606184T2 (de) Klient-server-brücke
DE112012004747B4 (de) Verborgenes automatisiertes Spiegeln von Daten für native Schnittstellen in verteilten virtuellen Maschinen
DE69719620T2 (de) Vorrichtung und Verfahren zur Bestimmung von Server-Cluster-Topologien
DE69024753T2 (de) Tragbarer, Ressourcen teilender Datei-Server, der gemeinsame Routines benutzt
DE69322887T2 (de) Datenverarbeitung und Betriebssystem mit dynamischer Belastungsteilung in einem Netzwerk von verknüpften Prozessoren
DE69910826T2 (de) Rechnersystem mit rekonfigurierbarer programmierbarer logik-vorrichtung
DE68927375T2 (de) Arbitrierung von Übertragungsanforderungen in einem Multiprozessor-Rechnersystem
DE69630480T2 (de) Verfahren, Vorrichtung und Datenstrukturen zur Objektverwaltung
DE3786069T2 (de) Virtueller Programmablauf auf einem Mehrfachverarbeitungssystem.
DE112011101469T5 (de) Kompilieren von Software für ein hierarchisches verteiltes Verarbeitungssystem
DE112013000752T5 (de) Verwalten von Verarbeitungselementen in einem Streaming-Datensystem
DE112012000693T5 (de) Ausführen einer Vielzahl von Instanzen einer Anwendung
DE10113577A1 (de) Verfahren, Computerprogrammprodukt und Computersystem zur Unterstützung mehrerer Anwendungssysteme mittels eines einzelnen Datenbank-Systems
DE112012002905T5 (de) Technik zum Kompilieren und Ausführen von Programmen in höheren Programmiersprachen auf heterogenen Computern
DE112017004663T5 (de) Mehrfachverbinder-unterstützung für usb-c
DE102017213160B4 (de) Kompilierung für knotenvorrichtungs-GPU-basierte Parallelverarbeitung
DE69323196T2 (de) Rechnersystem und Verfahren zur Ausführung von mehreren Aufgaben
DE102013006396A1 (de) Eine grafikverarbeitungseinheit, in der eine standardverarbeitungseinheit verwendet ist, und ein verfahren zum aufbau einer grafikverarbeitungseinheit
DE112012004629T5 (de) Dynamischer Speicheraffinitätsanpasser auf Prozess/Objektebene
DE60122671T2 (de) Anforderungsbedingte dynamische Schnittstellengenerierung
DE69904766T2 (de) Kodenübersetzer

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05804668

Country of ref document: EP

Kind code of ref document: A1