PatentDe  


Dokumentenidentifikation DE102005063162A1 31.10.2007
Titel Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik
Anmelder CodeWrights GmbH, 76137 Karlsruhe, DE
Erfinder Vetter, Immanuel, 76547 Sinzheim, DE;
Gunzert, Michael, 76863 Herxheim, DE
Vertreter Kornmeier, H., Dipl.-Phys. Dr.rer.nat., Pat.-Anw., 79576 Weil am Rhein
DE-Anmeldedatum 30.12.2005
DE-Aktenzeichen 102005063162
Offenlegungstag 31.10.2007
Veröffentlichungstag im Patentblatt 31.10.2007
IPC-Hauptklasse G05B 23/02(2006.01)A, F, I, 20051230, B, H, DE
Zusammenfassung Bei einem Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik wird eine endliche Zustandsmaschine aus einer Gerätebeschreibung erzeugt, die als Basis für einen Testscript dient. Zum Testen der Gerätebeschreibung wird das Testscript ausgeführt, wobei Daten an die Gerätebeschreibung gesendet und von dieser empfangen werden. Dabei wird geprüft, ob die im Testscript festgelegten Sollwerte mit den Istwerten, die z. B. vom Feldgerät geliefert werden, übereinstimmen.

Beschreibung[de]

Die Erfindung betrifft ein Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik gemäß dem Oberbegriff des Anspruchs 1.

In der Prozessautomatisierungstechnik und Farbikautomatisierungstechnik werden vielfach Feldgeräte eingesetzt, die zur Erfassung und/oder Beeinflussung von Prozessvariablen dienen. Beispiele für derartige Feldgeräte sind Füllstandsmessgeräte, Massendurchflussmessgeräte, Druck- und Temperaturmessgeräte, pH-Redoxpotential-Messgeräte, Leitfähigkeitsmessgeräte etc. für die Prozessautomatisierungstechnik, die als Sensoren die entsprechenden Prozessvariablen Füllstand, Durchfluss, Druck, Temperatur, pH-Wert bzw. Leitfähigkeitswert erfassen.

Zur Beeinflussung von Prozessvariablen dienen Aktoren, z. B. Ventile, die den Durchfluss einer Flüssigkeit in einem Rohrleitungsabschnitt steuern oder Pumpen, die den Füllstand in einem Behälter verändern.

Eine Vielzahl solcher Feldgeräte wird von der Firma Endress + Hauser® hergestellt und vertrieben.

Häufig sind Feldgeräte über Kommunikationssysteme (Profibus®, Foundation®-Fieldbus, HART® etc.) mit übergeordneten Einheiten verbunden. Diese übergeordneten Einheiten mit ihren entsprechenden Anwendungsprogrammen dienen u. a. zum prozessnahen Asset-Management.

Die Integration der Feldgeräte in Anwendungen von übergeordneten Einheiten erfolgt über Gerätebeschreibungen. Diese Gerätebeschreibungen werden von den Geräteherstellern bereitgestellt, damit übergeordnete Einheiten die Bedeutung der von den Feldgeräten gelieferten Daten erkennen und interpretieren können.

Es sind verschiedene Gerätebeschreibungen für die unterschiedlichen Feldbussysteme bekannt (HART-Gerätebeschreibungen, Fieldbus Foundation Gerätebeschreibungen, Profibus-Gerätebeschreibungen).

In Zusammenarbeit der Fieldbus Foundation (FF), der HART Communication Foundation (HART CF) und der Profibus Nutzerorganisation (PNO) wurde eine elektronische Gerätebeschreibung (Electronic Device Description EDD) geschaffen, die in der Norm IEC 61804-2 definiert ist.

Mit einer Vielzahl von weltweit installierten EDD-basierten Feldbussystemen (FF, HART, Profibus) ist EDD eine wichtige und sehr verbreitete Beschreibungssprache für Gerätebeschreibungen in der Automatisierungstechnik.

Zur Bedienung der Feldgeräte sind entsprechende Bedienprogramme (Bedientools) notwendig, die auf den übergeordneten Einheiten entweder eigenständig ablaufen (Endress + Hauser FieldCare, Pactware, AMS Fisher-Rosemount, PDM Siemens) oder aber auch in Leitsystem-Anwendungen (Siemens PCS7, ABB Symphony, Emerson Delta V) integriert sind.

Für eine vollumfängliche Bedienung der Feldgeräte sind seit kurzem spezielle Gerätebeschreibungen, so genannte DTMs (Device Type Manager), die den FDT (Field Device Tool) Spezifikationen entsprechen, erhältlich. Die als Industriestandard geltenden FDT-Spezifikationen wurden von der PNO (Profibus Nutzer Organisation) in Zusammenarbeit mit dem ZVEI (Zentralverband Elektrotechnik- und Elektroindustrie) entwickelt. Die aktuelle FDT-Spezifikation 1.2.1 inklusive dem Addendum für die Kommunikation „Foundation Fieldbus" ist über den ZVEI bzw. die PNO bzw. die FDT-Group erhältlich.

Viele Feldgerätehersteller liefern bereits für ihre Feldgeräte entsprechende DTMs aus. Die DTMs kapseln alle Variablen und Funktionen des jeweiligen Feldgeräts und bieten meist eine graphische Nutzeroberfläche zum Bedienen der Geräte an. Gerätespezifischen Gerätebeschreibungen können bereits via Internet-Verbindung von Servern der entsprechenden Gerätehersteller heruntergeladen werden.

Mit Hilfe von DTMs ist eine geräte- und herstellerübergreifende Bedienung von Feldgeräten mit entsprechenden Bedienprogrammen möglich.

Als Laufzeitumgebung benötigen die DTMs eine Rahmenapplikation (FDT-Frame). Die Rahmenapplikation und die entsprechenden DTMs erlauben so einen sehr komfortablen Zugriff auf verschiedene Variablen der Feldgeräte (z.B. Geräteparameter, Messwerte, Diagnoseinformationen, Statusinformationen, etc.) sowie den Aufruf von speziellen Funktionen, die einzelnen DTMs zur Verfügung stellen.

Rahmenapplikationen und DTMs arbeiten nach dem Client-Server-Prinzip.

Da die Feldgeräte über DTMs bedient werden, sind umfangreiche Funktionstests notwendig, um zu gewährleisten, dass die DTMs einwandfrei arbeiten.

Diese Funktionstests haben insbesondere auch einen sicherheitskritischen Aspekt, da auch sicherheitskritische Einstellungen an Feldgeräten mit DTMs vorgenommen werden.

Eine Möglichkeit DTMs zu testen, bietet das Testwerkzeug dtmINSPECTOR (M&M Software GmbH, St. Georgen). Hierzu werden umfangreiche Testscripts erstellt, die zusammen mit dem zu testenden DTM ausgeführt werden. Im Wesentlichen wird bei diesen Tests überprüft, ob der DTM den FDT-Spezifikationen, also den FDT Schnittstellendefinitionen entspricht. Die korrekte Funktion des DTMs hinsichtlich der Gerätefunktionalität wird hierbei jedoch nicht geprüft.

Die Testscripts für den dtmINSPECTOR werden einzeln von Hand erstellt. Typische Testfälle auf Basis der FDT – Spezifikationen werden zusammengestellt und in Testscripts umgewandelt.

Die Anmelderin, CodeWrights GmbH (Karlsruhe), erstellt aus herkömmlichen Gerätebeschreibungsdateien (HART, FF oder Profibus) mit Hilfe eines entsprechenden Werkzeugs (DTMstudio®) gerätespezifische DTMs in großer Stückzahl. Für jeden einzelnen DTM ein spezielles Testscript manuell zu erzeugen, das neben der Schnittstellenüberprüfung auch den test der Gerätefunktionalität umfasst, ist äußerst zeitaufwendig und kostenintensiv.

Je mehr Parameter ein Feldgerät umfasst, desto höher wird dabei der Test-Aufwand. Komplexe Feldgeräte können heute bereits bis zu 1000 und mehr Parameter aufweisen.

Aufgabe der vorliegenden Erfindung ist es deshalb, ein Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik anzugeben, das die oben genannten Nachteile nicht aufweist, das insbesondere die einfache Erzeugung von Testscripts erlaubt, wobei die Testscripts möglichst alle denkbaren Testfälle für das jeweilige Feldgerät abdecken.

Gelöst wird diese Aufgabe durch die im Anspruch 1 angegebenen Verfahrensmerkmale.

Vorteilhafte Weiterentwicklungen der Erfindung sind in den Unteransprüchen angegeben.

Nachfolgend ist die Erfindung anhand mehreren in der Zeichnung dargestellten Ausführungsbeispiele näher erläutert.

Es zeigen:

1 schematische Darstellung eines Netzwerks der Automatisierungstechnik mit mehreren Feldgeräten;

2 schematische Darstellung einer Kommunikationsverbindung zwischen einem Bedienprogramm und mehreren Feldgeräten;

3 schematische Darstellung der Erzeugung eines Testscripts;

4 Test DTM online;

5 Test mit einem Model-Checker;

6 Test Kommunikations Interpreter

7 Gerätebeschreibungsdatei Micropilot M (auszugsweise)

8 abstrakte Zustandsmaschine (auszugsweise)

9 endlicher Zustandsautomat (auszugsweise)

10 Testsequenz (auszugsweise)

In 1 ist ein Kommunikationsnetzwerk der Prozessautomatisierungstechnik näher dargestellt. An einen Datenbus D1 sind mehrere Rechnereinheiten (Workstations, Host-Rechner) WS1, WS2 angeschlossen. Diese Rechnereinheiten können als übergeordnete Einheiten (Leitsystem, Steuereinheit, Bedienstation) zur Prozessvisualisierung, Prozessüberwachung und zum Engineering aber auch zum Bedienen und Überwachen von Feldgeräten dienen. Der Datenbus D1 arbeitet z. B. nach dem Profibus® DP-Standard oder nach dem HSE (High Speed Ethernet)-Standard der Foundation® Fieldbus. Über ein Gateway G1, das auch als Linking Device oder als Segmentkoppler bezeichnet wird, ist der Datenbus D1 mit einem Feldbussegment SM1 verbunden. Das Feldbussegment SM1 besteht aus mehreren Feldgeräten F1, F2, F3, F4 die über einen Feldbus FB miteinander verbunden sind. Bei den Feldgeräten F1, F2, F3, F4 können es sich sowohl um Sensoren oder um Aktoren handeln. Der Feldbus FB arbeitet entsprechend nach einem der bekannten Kommunikations-Standards Profibus, Foundation Fieldbus oder HART. Mit dem Feldbus FB kann temporär auch eine tragbare Rechnereinheit BE verbunden werden.

In 2 ist ein Bedienprogramm, das auf einer der Rechnereinheiten WS1, WS2 oder auf der Bedieneinheit BE ablaufen kann, schematisch dargestellt. Bei dem Bedienprogramm kann es sich z. B. um die Bediensoftware PACTware (PACTware Consortium e.V.) oder FieldCare® (Firma Endress + Hauser®) handeln, die beide als Betriebssystem Microsoft Windows®, 98NT, 2000 benötigen und die als FDT-Frame dienen. Die Rahmen-Applikation FDT-Frame ist insbesondere verantwortlich für die Verwaltung der DTMs in einer Projektdatenbank (projekt database), für die Kommunikation zum Bussystem und für die Verwaltung des Gerätekatalogs.

In die Rahmen- Applikation FDT-Frame sind Gerätetreiber u. a. für mehrere Feldgeräte integriert. Der Übersichtlichkeit halber sind nur zwei Geräte-DTMs DTM-F1 und DTM-F2 sowie ein Kommunikations-DTM CommDTM dargestellt. Beispielsweise kapselt der Geräte-DTM DTM-F1 die Parameter und Funktionen des Feldgerätes F1.

Mit Hilfe der DTMs ist eine geräte- und herstellerübergreifende Bedienung der Feldgeräte sowie der Aufbau einer Kommunikationsverbindung zwischen der Rechnereinheit WS1 und den Feldgeräten F1, F2, F3, F4 möglich. So erlaubt der DTM-F1 den speziellen Zugriff auf verschiedene Informationen im Feldgerät F1 wie Geräteparameter, Gerätekonfiguration, Diagnosedaten und Statusinformationen. Erleichtert wird der Zugriff für den Anwender auf diese Informationen meist durch eine herstellerspezifische graphische Benutzeroberfläche.

Das FDT-Konzept basiert darauf, dass in eine FDT-Frame-Applikation unterschiedliche Feldgeräte von unterschiedlichen Herstellern über die entsprechenden Geräte-DTMs, die im Prinzip Treibern für Peripheriegeräte wie z. B. Druckern für Standard-PCs entsprechen, in einfacher Weise integriert werden können.

Hardwaremäßig erfolgt die Verbindung über eine Busanschaltung BA, den Datenbus D1, das Gateway G1, den Feldbus FB zum Feldgerät F1.

In 3 ist schematisch dargestellt, wie ein Testscript TS aus einer Gerätebeschreibungsdatei DD erzeugt wird. DD steht allgemein für Device Description (Gerätebeschreibung) und bezeichnet die textliche Beschreibung des Geräts bzw. die entsprechende Datei.

Gerätebeschreibungen können als System aufgefasst werden, das Zustände und Zustandsübergänge des Feldgerätes beschreibt. Ein Zustand ist dabei durch die Werte aller Variablen und ggf. der aktiven Transaktionen, sowie der zur Verfügung stehenden Funktionen einschließlich des Bedienmenüs definiert. Zustandsübergänge werden definiert als die erlaubten Änderungen der Variablenwerte. Diese Änderungen erfolgen normalerweise durch das Editieren von Werten über die Benutzeroberfläche am Bedienprogramm (Bedientool oder Bedienwerkzeug). Weiterhin können Funktionen (Methoden) Änderungen von Variablenwerten bewirken. Die Änderung von Variablenwerten oder das Ausführen von Funktionen wird über die externe Kommunikationsverbindung des Feldgerätes ausgelöst.

Der Inhalt einer Gerätebeschreibungsdatei ist am Beispiel des Produkts Micropilot M FMR2xx der Fa. Endress + Hauser auszugsweise in 7 dargestellt.

Aus der Gerätebeschreibungsdatei DD-F1 für das Feldgerät F1 wird mit Hilfe eines Compilers C2 eine abstrakte Zustandsmaschine DD-F1 ASM erzeugt. Abstrakte Zustandsmaschinen werden in der englischen Literatur als Abstract State Machines bezeichnet und zum Teil auch mit ASM abgekürzt.

Eine abstrakte Zustandsmaschine ist ein abstraktes Maschinenmodell, mit dem beliebige Algorithmen, Programmiersprachen, Protokolle und andere Systeme beschrieben und simuliert werden können.

Zur Beschreibung einer abstrakten Zustandsmaschine steht z. B., die Abstract State Machine Language von Microsoft and XASM (www.xasm.org) als Open Source Implementierung zur Verfügung wie sie in 8 auszugsweise dargestellt ist. Derartige Sprachen eignen sich vor allem zur Erstellung von ausführbaren Spezifikationen.

Diese abstrakte Zustandsmaschine DD-F1 ASM wird noch um eine zusätzliche allgemeine abstrakte Zustandsmaschine DDL-ASM erweitert, die aus den Spezifikationen der Gerätebeschreibungssprache DDL (Device Description Language) gewonnen wird. DD-F1 ASM und DDL-ASM werden miteinander verknüpft und bilden zusammen eine Zustandsmaschine x-DD-F1 ASM. Diese erweiterte abstrakte Zustandsmaschine x-DD-F1 ASM wird mit Hilfe eines FSM-Generators (finite state machine Generator) unter Zuhilfenahme von speziellen Testparametern (z. B vorgegebene Wertebereiche für bestimmte Datentypen) für das Feldgerät F1 in eine endliche Zustandsmaschine DD-F1 FSM (Finite State Machine) umgewandelt.

Ein Auszug einer solchen endlichen Zustandsmaschine ist in 9 dargestellt

Mit Hilfe eines Testgenerators TG wird aus der endlichen Zustandsmaschine DD-F1 FSM letztendlich ein Testscript TS-F1 für das Feldgerät F1 erzeugt. Ein solches Testscript ist auszugsweise in 10 dargestellt.

Die Compiler C1 bzw C2 und die Generatoren FMS und TG sind Programme die auf beliebigen Computer-Einheiten z. B. Standard PCs unter Windows®, Unix® oder Linux ablaufen. ablaufen. Sie müssen einmal erstellt werden und können dann für Gerätebeschreibungen von verschiedenen Feldgeräten verwendet werden.

Die allgemeine abstrakte Zustandsmaschine DDL-ASM muß ebenfalls einmalig erstellt werden.

Aus der Gerätebeschreibungsdatei DD-F1 für das Feldgerät F1 kann auch mit Hilfe eines Compilers C1 (z. B. DTM Studio) ein DTM-F1 für das Feldgerät F1 gewonnen werden.

In 4 ist der Online-Test des Feldgeräts F1 schematisch dargestellt.

Das Feldgerät F1 ist dabei wie in 1 dargestellt mit einer Rechnereinheit verbunden, die mit WS-Test bezeichnet ist. Die Rechnereinheit WS-Test ist im Wesentlichen ähnlich zur Rechnereinheit WS1. Neben einem DTM-Frame ist noch ein weitere Applikation, ein Testwerkzeug „Testtool", installiert.

Das Testwerkzeug „Testtool" kann auf die DTMs zugreifen, d. h. Daten an DTMs senden und von diesen abrufen.

Die Kommunikation kann entweder über den FDT-Frame oder falls am DTM eine entsprechende Test-Schnittstelle vorgesehen ist, auch über den DTM direkt erfolgen.

Diese Kommunikationswege sind durch Pfeile entsprechend dargestellt.

Zum Testen des DTMs DTM-F1 wird das Testscript TS-F1 vom Testwerkzeug Testtool abgearbeitet.

Dabei werden spezielle Parameterwerte an den DTM-F1 gesendet und von diesem empfangen. Der DTM-F1 kommuniziert online über den Comm DTM mit dem an dem am Feldbus FB angeschlossenen Feldgerät F1. Über den Comm DTM können Geräteparameter auch direkt vom Testwerkzeug Testtool aus dem Feldgeräte F1 ausgelesen bzw. in dieses geschrieben werden.

Enthält das Testscript TS-F1 die Anweisung Write (A, 10), so soll die Variable A im Feldgerät F1 mit Hilfe des DTM-F1 mit dem Wert 10 (Sollwert) beschrieben werden. Durch die direkte Abfrage des Istwerts der Variablen A aus dem Feldgerät F1 über den Comm DTM kann anschließend geprüft werden, ob diese Anweisung ordnungsgemäß durchgeführt wurde. Auf diese Weise können alle gemäß der Gerätebeschreibung möglichen Zustandsübergänge durchgeführt und geprüft werden. Die verschiedenen Aktionen werden in einem Testreport, der vom Testwerkzeug „Testtool" erzeugt wird, festgehalten. Treten Abweichungen auf, d.h. Sollwerte stimmen nicht mit Istwerten überein, so wird dies im Testreport speziell vermerkt. Diese Fehler müssen anschließend analysiert werden um festzustellen, ob die Ursache ein fehlerhaftes Verhalten des DTMs bzw. des Gerätes war oder ob ein Fehler in der Gerätebeschreibung vorliegt.

Neben dem Online-Test mit einem angeschlossenen Feldgerät ist auch ein Offline-Test ohne Kommunikation mit dem Feldgerät F1 möglich. Weiterhin kann anstatt eines Online-Tests der Test auch mit einem simulierten Feldgerät erfolgen.

In 5 ist ein alternativer Test schematisch dargestellt. Aus den Gerätespezifikationen für das Feldgerät F1, die im Prinzip als Basis für die Gerätebeschreibungsdatei DD-F1 dient, wird direkt eine endliche Zustandsmaschine GS-F1 FSM erzeugt. Mit Hilfe eines Model-Checkers MC kann die endliche Zustandsmaschine DD-F1 FSM gegen die endliche Zustandsmaschine GS-F1 FSM gestestet werden, um zu prüfen, ob die Gerätebeschreibungsdatei DD-F1 den Spezifikationen für das Feldgerät F1 entspricht.

In 6 ist die Testautomation für einen Kommunikations-Interpreter KI dargestellt. Der Kommunikationsinterpreter KI kommuniziert mit einem Test-Comm DTM und der endlichen Zustandsmaschine DD-F1 FSM. Wenn das Feldgerät F1 angeschlossen ist, kennt der Test-Comm DTM die Parameterwerte des Geräts. Andernfalls können einfach Regeln definiert werden, so dass der Test-Comm DTM ein virtuelles Feldgerät repräsentiert.

In 10 ist eine Testsequenz auszugsweise dargestellt.

Die wesentlichen Schritte des erfindungsgemäßen Verfahrens sind:

Erzeugung einer endlichen Zustandsmaschine aus einer Gerätebeschreibung, wobei die Gerätebeschreibung in beliebiger Form vorliegen kann, z. B. als Device Description.

Aus der endlichen Zustandsmaschine wird ein Testscript generiert.

Zum Testen der Gerätebeschreibung wird das Testscript ausgeführt, wobei Daten an die Gerätebeschreibung gesendet und von dieser empfangen werden. Dabei wird geprüft, ob die im Testscript festgelegten Sollwerte mit den Istwerten, die z. B. vom Feldgerät geliefert werden, übereinstimmen.

Die Erfindung erlaubt automatische Tests von Gerätebeschreibung bzw. Feldgeräten in beliebiger Hinsicht, funktionales Verhalten, Kommunikationsverhalten, Schnittstellendefinitionen etc. ohne dass Testscripts von Hand erstellt werden müssen. Dadurch können schnell und einfach Gerätebeschreibungen überprüft werden. Dadurch erhöht sich auch die Prozess-Sicherheit, da Fehler bei der Bedienung von Feldgeräten aufgrund von fehlerhaften Gerätebeschreibungen, weitgehenst ausgeschlossen werden können.


Anspruch[de]
Verfahren zum Testen von Gerätebeschreibungen für Feldgeräte der Automatisierungstechnik, die in ein Bedienprogramm integriert werden um Feldgeräte zu bedienen, gekennzeichnet durch folgende Verfahrensschritte:

A. Erzeugung einer endlichen Zustandsmaschine aus der Gerätebeschreibung, die auf Zuständen und Zustandsübergängen basiert

B. Erzeugung eines Testscripts mit Hilfe der endlichen Zustandsmaschine

C. Abarbeiten des Testscripts wobei Daten an die Gerätebeschreibung gesendet bzw. von dieser empfangen werden um Istwerte zu generieren

D. Überprüfung der vom Testscript vorgegebenen Sollwerte mit den Istwerten
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die endliche Zustandsmaschine über eine abstrakte Zustandsmaschine gewonnen wird. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein erstes abstraktes Maschinenmodell aus der Gerätebeschreibung und ein zweites abstraktes Maschinenmodell aus den der Gerätebeschreibung zugrunde liegenden allgemeinen Spezifikationen für Gerätebeschreibungen erzeugt wird, die beide in ein erweitertes abstraktes Maschinenmodell umgewandelt werden, aus dem die endliche Zustandsmaschine erzeugt wird. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Gerätebeschreibung ein Gerätetreiber für das Feldgerät ist. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur Abarbeitung des Testscripts ein Testwerkzeug vorgesehen ist, das zur Sollwerte und Istwerte vergleicht. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Bedienprogramm online mit dem Feldgerät kommuniziert, Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Testwerkzeug die Istwerte von einem Kommunikationstreiber CommDTM erhält, über den der Gerätetreiber DTM-F1 mit dem Feldgerät F1 kommuniziert. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Gerätetreiber DTM-F1 und die abstrakte Zustandsmaschine DTM-F1 ASM mit Hilfe eines Compilers aus der Gerätebeschreibungsdatei DD gewonnen werden.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com