-
Die
Erfindung betrifft ein Verfahren zur Überwachung der Funktionsfähigkeit
eines elektronischen Bausteins in einem Steuergerät, ein
solches Steuergerät sowie ein Computerprogramm und ein
Computerprogrammprodukt zur Durchführung des Verfahrens.
-
Stand der Technik
-
Elektronische
Steuergeräte werden bei Kraftfahrzeugen in unterschiedlichen
Bereichen eingesetzt, um diverse Abläufe zu steuern und/oder
zu regeln. So ist der Einsatz von Steuergeräten in Vorrichtungen
zur Fahrzustandserkennung bekannt, bei denen unterschiedliche Größen,
wie bspw. die Lenkwinkelgeschwindigkeit, aber auch optische Signale bzw.
Bildsignale aufgezeichnet und ausgewertet werden, um einen kritischen
Fahrzustand zu erkennen.
-
Die
Druckschrift
DE
10 2005 057 267 A1 beschreibt ein Verfahren und eine Vorrichtung
zur Fahrzustandserkennung, bei denen der Verlauf eines den Fahrzustand
charakterisierenden Signals ausgewertet und bei einem typischen
Verlauf ein den Fahrzustand kennzeichnendes Signal erzeugt wird.
Die Vorrichtung weist dabei eine elektronische Steuereinheit auf,
die im wesentlichen aus Komponenten wie Eingangsschaltung, Rechner
und Ausgangsschaltung besteht, wobei die einzelnen Komponenten zum
gegenseitigen Daten- und Informationsaustausch mit einem Bussystem
verbunden sind. Zur Erkennung von Fahrbahnrandmarkierungen wird
eine Videokamera eingesetzt, die mit der Eingangsschaltung verbunden
ist.
-
Zu
beachten ist jedoch, dass videobasierte Fahrerassistenzsysteme aufgrund
der Komplexität der Umwelt einen äußerst
hohen Ressourcenbedarf haben. Dies spiegelt sich auch in der verwendeten Hardware
wider. Zum Einsatz kommen äußerst leistungsfähige
automotive zertifizierte Bausteine, deren Komplexität es
zunehmend schwierig macht, die Hardware im Rahmen einer neben den
Applikationen laufenden Selbstdiagnose vollständig, d.
h. mit einer Testabdeckung von bspw. mehr als 90%, zu überwachen.
Auch die Überwachung von FPGAs im automobilen Umfeld ist
bisher nicht zufriedenstellend gelöst.
-
Zur
Gewährleistung der Funktionsfähigkeit der eingesetzten
Steuergeräte sind unterschiedliche Vorgehensweisen bekannt.
Dabei müssen Anforderungen an Hard- und Software formuliert
werden, die einen sicheren Betrieb gestatten. Zur Vereinheitlichung
der Entwicklungsprozesse und der Überwachung im Betrieb
werden normierte Vorgehensweisen angestrebt.
-
Die ISO
26262 ist eine vorgesehene ISO-Norm für sicherheitsrelevante
Systeme in Kraftfahrzeugen, die ein Prozess-Rahmenwerk und Vorgehensmodell
zusammen mit geforderten Aktivitäten und Arbeitsprodukten
sowie anzuwendenden Methoden definiert. Die Umsetzung der Norm soll
die funktionale Sicherheit eines elektronischen Systems in Kraftfahrzeugen
gewährleisten.
-
Dabei
wird eine Methode zur Gefahrenanalyse und Risikoabschätzung
vorgeschlagen, bei der auf Grundlage der Systembeschreibung die
möglicherweise gefährlichen Situationen identifiziert
werden. Jede Gefahr wird dann mit einer Sicherheitsanforderungsstufe
von A bis D klassifiziert oder als nicht sicherheitsrelevant eingeordnet.
Dazu muss für jede identifizierte Gefahr einzeln der Verletzungsgrad,
die Häufigkeit der Situation und die Wertbarkeit der Situation
durch den Fahrer abgeschätzt werden. Aus einer vorgegebenen
Tabelle lässt sich dann für jede Gefahr die Einstufung
QM (quality managed) oder ASIL (automotive safety integrity level)
A bis D ablesen.
-
Mit
steigendem ASIL steigen auch die Anforderungen an die Sicherheit,
die in den nachfolgenden Teilen spezifiziert sind. An Gefahren der
Klasse QM sind keine Anforderungen gestellt, die über das übliche
Qualitätsmanagement des Systemherstellers hinausgehen.
-
Die
Norm definiert konkrete Anforderungen an Software und Hardware,
sowohl für die Entwicklungsprozesse als auch für
das Fehlverhalten im Feld, und beeinflusst bereits heute die Anforderungen
an die Systeme im Fahrzeug. Besonderes Augenmerk verdient die Erkennung
von permanenten zufälligen bzw. systematischen Fehlern.
Dabei werden Prozesse empfohlen und zum Teil quantitative Forderungen
an Ausfallraten und Testabdeckungen für die verschiedenen
Sicherheitsstufen vorgegeben.
-
Die
Norm adressiert die Absicherung von Systemen im automobilen Bereich,
wenn es durch ein Versagen der Hardware oder durch Software-Implementierungsfehler
im technischen Sinne zu einer Gefährdung kommen kann. Funktionale
Unzulänglichkeiten, die bspw. durch unzureichende Umfelderfassung
entstehen, werden nicht durch die Norm adressiert. Diese müssen
ggf. über weitere Maßnahmen außerhalb
der Norm adressiert werden. Die Software hat im Verständnis
der Norm einen vernachlässigbar kleinen Fehler, wenn sie
nach den Prozessen der Norm entwickelt wird. Dieses Sicherheitskonzept
zeigt die Absicherung von E/E/PES-Systemen im Sinne der Norm. Diese
Absicherung ist im allgemeinen durch die Hardware getrieben.
-
Betrachtete
Fehlerarten sind u. a. permanent zufällige Fehler, wie
bspw. eine defekte RAM-Zelle, systematische Fehler, wie bspw. eine
falsch ausgelegte Betriebstemperatur, transiente Fehler, wie bspw.
ein Single Event Upset (Bit-Kipper). Diese Fehler können
sich auf Programm und Daten auswirken.
-
Vorgaben
sind, dass das betrachtete System ausfallsicher (fail-safe) ist,
d. h., dass das Abschalten des Systems im Fehlerfall immer sicher
ist. Zudem führt ein Fehler, der zum Ausbleiben jeder Kommunikation
führt (fail-silent), ebenfalls in den sicheren Zustand.
-
Offenbarung der Erfindung
-
Das
erfindungsgemäße Verfahren dient zur Überwachung
der Funktionsfähigkeit eines elektronischen Bausteins in
einem Kraftfahrzeug. Dabei wird dem elektronischen Baustein eine
einen Fahrzustand des Kraftfahrzeugs betreffende Größe
als Eingangssignal zur Verarbeitung zugeführt. Ein Ausgangssignal
des elektro nischen Bausteins wird an eine elektronische Recheneinheit
weitergeleitet, in der das Ausgangssignal mit diversitären
Softwarealgorithmen weiterverarbeitet wird, wobei die Ausgaben der diversitären
Softwarealgorithmen in einem Komparator miteinander verglichen werden. Üblicherweise werden
zwei Softwarealgorithmen eingesetzt, deren Ausgänge in
dem Komparator miteinander verglichen werden. Ein fehlgeschlagener
Vergleich führt zu einem Fehlerfall.
-
Hinreichend
komplexe und diversitäre Algorithmen kommen nur auf fehlerfreier
Hardware zu äquivalenten Ergebnissen. Somit übernehmen
diversitäre Algorithmen auch die Funktion der Selbstdiagnose
auf komplexer Hardware.
-
Das
Steuergerät mit dem elektronischen Baustein kommt bspw.
bei einem videobasierten Fahrerassistenzsystem zum Einsatz, bei
dem eine Fahrzustandsüberwachung durchgeführt
wird. Bei dieser Anwendung kann dem elektronischen Baustein ein
Bildsignal als Eingangssignal zugeführt werden. Hierbei
kann der elektronische Baustein, der bspw. als FPGA (field programmable
gate array: vor Ort modifizierbarer Logikbaustein) ausgebildet ist, mit
einer Testabdeckung von bspw. mehr als 90% überwacht werden.
-
In
Ausgestaltung wird dem elektronischen Baustein zusätzlich
ein Testmuster zugeführt, das in dem elektronischen Baustein
verarbeitet wird. Das verarbeitete Testmuster wird dann an die elektronische
Recheneinheit weitergeleitet. Dabei kann das verarbeitete Testmuster
und das Ausgangssignal getrennt in der elektronischen Recheneinheit,
bspw. ein Mikrocontroller, weiterverarbeitet werden.
-
In
der elektronischen Recheneinheit kann eine Testmusterverifikation
durchgeführt werden. Ein Fehlschlagen der Testmusteranalyse
führt regelmäßig zu einem Fehlerfall.
-
In
Ausgestaltung wird die Funktionsfähigkeit des Komparators überwacht.
Hierzu wir bspw. ein in Hardware unabhängiger SCON (safety
controller) eingesetzt.
-
Das
beschriebene Steuergerät für ein Kraftfahrzeug
dient insbesondere zur Durchführung eines Verfahrens der
vorstehend beschriebenen Art. Dieses weist einen elektronischen
Baustein, bspw. ein FPGA, und eine elektronischen Recheneinheit, bspw.
einen Mikrocontroller, auf, wobei der elektronische Baustein zur
Aufnahme und zur Verarbeitung einer einen Fahrzustand des Kraftfahrzeugs
betreffenden Größe ausgebildet ist und die elektronische
Recheneinheit zur Weiterverarbeitung eines Ausgangssignal des elektronischen
Bausteins ausgelegt ist. Bei der Weiterverarbeitung in der elektronischen
Recheneinheit werden diversitäre Softwarealgorithmen eingesetzt.
Es ist weiterhin ein Komparator vorgesehen, der dafür ausgelegt
ist, Ausgaben der diversitären Softwarealgorithmen miteinander
zu vergleichen.
-
In
Ausgestaltung ist eine Sicherheitseinrichtung zur Überwachung
des Komparators, bspw. ein in Hardware unabhängiger SCON,
vorgesehen.
-
Das
vorgestellte Computerprogramm umfasst Programmcodemittel, um alle
Schritte eines vorstehend beschriebenen Verfahrens durchzuführen,
wenn das Computerprogramm auf einem Computer oder einer entsprechenden
Recheneinheit, insbesondere in einem Steuergerät der beschriebenen Art,
ausgeführt wird.
-
Das
Computerprogrammprodukt weist diese Programmcodemittel auf, die
auf einem computerlesbaren Datenträger gespeichert sind,
um alle Schritte eines vorgestellten Verfahrens durchzuführen,
wenn das Computerprogramm auf einem Computer oder einer entsprechenden
Recheneinheit, insbesondere in einem Steuergerät, wie dies
vorstehend beschrieben ist, ausgeführt wird.
-
Das
vorgestellte Verfahren weist, zumindest in einigen der dargelegten
Ausführungen, eine Reihe von Vorteilen auf. So kann eine
generische Überwachung des elektronischen Bausteins und
damit eines FPGA ohne Verwendung expliziter Hardwareeigenschaften
des FPGA durchgeführt werden. Die Verwendung diversitärer
Algorithmen in der elektronischen Recheneinheit vereinfacht auf
hohem Abstraktionsniveau die aufwendige Selbstdiagnose der Recheneinheit
stark. Daher können selbst komplexe Mikrocontroller in
einem ASIL-B-Steuergerät eingesetzt werden. Außerdem
können, wenn genügend Ressourcen vorhanden sind,
bestehende Hardwarekonzepte sowohl für QM als auch für
ASIL-A/B verwendet werden.
-
Weitere
Vorteile und Ausgestaltung der Erfindung ergeben sich aus der Beschreibung
und den beiliegenden Zeichnungen.
-
Es
versteht sich, dass die voranstehend genannten und die nachstehend
noch zu erläuternden Merkmale nicht nur in der jeweils
angegebenen Kombination, sondern auch in anderen Kombinationen oder
in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden
Erfindung zu verlassen.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt
in schematischer Darstellung eine Ausführungsform eines
Steuergeräts.
-
2 zeigt
in schematischer Darstellung ein Hardwarekonzept einer Vorrichtung
zur Erkennung des Fahrzustands.
-
3 zeigt
in einem Blockschaltbild den Aufbau der Software in einer Vorrichtung
zur Fahrzustandserkennung.
-
4 zeigt
den Übergang von einem unkritischen zu einem kritischen
transienten Fehler.
-
5 zeigt
ein Systemkonzept für ein Steuergerät zur Fahrzustandserfassung.
-
6 verdeutlicht
die Detektion permanenter FPGA-Fehler.
-
7 zeigt
ein mögliches Komparatorkonzept.
-
Ausführungsformen der Erfindung
-
In 1 ist
eine Ausführung eines Steuergeräts, insgesamt
mit der Bezugsziffer 10 bezeichnet, dargestellt. Dieses
Steuergerät 10 weist einen elektronischen Baustein 12,
in diesem Fall ein FPGA, und eine elektronische Recheneinheit 14,
in dieser Ausführung einen Mikrocontroller, auf. Weiterhin
ist in dem Steuergerät 10 ein Komparator 16 und
ein Controller 18 zur Überwachung des Komparators 16 gegeben.
-
In
dem elektronischen Baustein 12 ist ein Bereich 20 zum
Ablegen eines Algorithmus und ein Generator 22 zum Erzeugen
eines Testmusters vorgesehen.
-
In
der elektronischen Einheit 14 sind ein erster Bereich 24 für
einen ersten Algorithmus, ein zweiter Bereich 26 für
einen zweiten Algorithmus und ein dritter Bereich 28 für
eine Testmusterverifikation vorgesehen.
-
Ein
Bildgeber 30 gibt erfasste Bildsignale an den elektronischen
Baustein 12 weiter. In den Datenfluss der Bildsignale werden
vor der Bearbeitung durch den elektronischen Baustein 12 Testmuster
sowohl vor als auch nach den relevanten Bilddaten eingespeist. Die
Testmuster werden ohne Sonderbehandlung durch den Baustein 12 verarbeitet.
Das Ergebnis der Berechnungen kann in einem Block-RAM (nicht dargestellt)
zwischen dem Baustein 12 und der Recheneinheit 14 abgelegt
werden. Hierbei ist es nicht relevant, ob es sich bei dem Baustein 12 und der
Recheneinheit 14 um getrennte oder integrierte Komponenten
handelt. Die Ergebnisse des Bausteins 12 werden getrennt
nach Bild und Testmuster in der Recheneinheit 14 weiterverarbeitet.
Eine Testmusterverifikation vergleicht das Baustein- 12 Ergebnis
des Testmusters mit bekannten Sollwerten.
-
Bei
der dargestellten Ausführung verarbeiten zwei diversitäre
Algorithmen die Berechnungen des elektronischen Bausteins 12 bezüglich
des tatsächlichen Bildes. Der Komparator 16 stellt
den single point failure der Recheneinheit 14 dar. In diesem
werden die beiden diversitären Softwarekanäle
verglichen und bei festgestellter Äquivalenz auf einen Fahrzeugbus 32 gegeben.
Der Komparator 16 wird dabei durch den in Hardware unabhängigen
SCON (safety controller) überwacht.
-
In 2 ist
in schematischer Darstellung eine Vorrichtung zur Fahrzustandserkennung
dargestellt. Diese Vorrichtung, die mit der Bezugsziffer 50 bezeichnet
ist, umfasst einen Leistungsanschluss 52, der mit dem elektrischen
System des Fahrzeugs verbunden ist (Pfeil 54), einen Controller 56,
einen NVM-Speicher 58 (non volatile memory: nichtflüchtiger
Speicher), einen FPGA 60, einen Bildgeber 62, einen
Blockspeicher 64 und eine Linseneinheit 70.
-
Einfallendes
Licht 72 wird von der Linseneinheit 70 erfasst
und an den Bildgeber 62 weitergegeben. Der Bildgeber 62 gibt
Bilddaten, wie mit Pfeil 74 verdeutlicht, an den FPGA 60 weiter.
-
Der
FPGA 60 umfasst eine Logikeinheit 76, einen eingebetteten
Kern 78 und einen Bereich 80 zum Ablegen der Algorithmen.
Weiterhin ist der FPGA 60 mit dem Blockspeicher 64,
und dem NVM-Speicher 58 verbunden. Nach außen
kommuniziert der FPGA 60 mit einem fahrzeugeigenen CAN-Bus
(Doppelpfeil 82) und über den Controller 56 mit
einem weiteren Feldbussystem (Doppelpfeil 86), bspw. ein
FlexRay.
-
In 3 ist
in einem Blockschaltbild der Aufbau der in einer Fahrzustandserkennungsvorrichtung eingesetzten
Software dargestellt. In einem ersten Block 100 sind externe
Daten enthalten, in einem zweiten Block die Daten und Programme
der Vorrichtung zur Fahrerszustandserkennung und in einem dritten
Block 104 die ausgegebenen Daten.
-
Die
externen Daten umfassen Bildsensordaten 106 und Fahrzeugsensordaten 108.
Die Bildsensordaten 106 werden an den FPGA 110 weitergegeben,
in dem eine Bildvorverarbeitung und Datenreduktion vorgenommen wird
(Block 112). Innerhalb der Vorrichtung ist weiterhin einen
Mikrocontroller 114 vorgesehen. Dieser erfasst die Bilddaten
des FPGA 110 und führt eine Objektbildung in der
Bildebene durch (Block 116). Die Fahrzeugsensordaten 108 werden
zusätzlich zur realen Objektbildung (Block 118)
und zur Zustandsschätzung (Block 120) herangezogen.
-
Das
FPGA 110 im Kontext der betrachteten Funktion dient somit
der Datenreduktion auf Ebene der Low-Level-Bildverarbeitung. Aus
Sicht des FPGA 110 ist daher jedes Bild vollständig
neu und ohne Bezug auf vorangegangene Bilder.
-
Transiente
Fehler im Datenfluss des FPGA 110 entsprechen dem allgemeinen
Sensorrauschen. Die Verarbeitung verrauschter Eingangssignale ist eine
funktionale Anforderung an die Algorithmik. Das verwirklichte Sicherheitskonzept
konzentriert sich daher auf die Erkennung permanenter Fehler des FPGA 110.
-
Die
algorithmische Logik der Objektbildung wird in dem Mikrocontroller 114 berechnet.
Hierbei wird nicht nur eine Einzelbildauswertung, wie dies beim
FPGA 110 der Fall ist, durchgeführt. In Folge der
zeitlichen Korrelation ist es nicht möglich, transiente
Fehler zu vernachlässigen. Die Erkennung transienter und
permanenter Fehler ist durch das Sicherheitskonzept adressiert.
-
4 verdeutlicht
den Übergang von einem unkritischen zu einem kritischen
transienten Fehler. In der Darstellung ist eine zweidimensionale
Bildebene 150 einer realen Umgebung 152 gegenübergestellt.
Ein Bereich 154 zeigt unkritische transiente Fehler und
ein Bereich 156 transiente Fehler, die erkannt werden müssen.
-
Ein
Bildgeber 158 erzeugt die Daten der Bildebene 150,
die in ein reales Modell bzw. die reale Umgebung 152 überführt
und an einen Fahrzeugbus 160 weitergegeben werden.
-
In
Bezug zu den unterschiedlichen Ebenen ist die Datenmenge im Verhältnis
zum Informationsgehalt pro Datum 164 aufgetragen. Zu erkennen
ist das Anwachsen des Informationsgehalts 164 der Datenmenge 162 von
der Bildebene 150 hin zu der realen Umgebung 152.
In diesem Bereich liegen auch transiente Fehler 156 vor,
die erkannt werden müssen.
-
In 5 ist
ein mögliches Systemkonzept für ein Steuergerät,
dass bei einer Fahrzustandserfassung zum Einsatz kommt, wiedergegeben.
Die Darstellung zeigt einen Bildgeber, einen FPGA 402,
ein RAM 404, einen Mikrocontroller 406 und einen
Fahrzeugbus 408.
-
Der
FPGA 402 weist ein Testmuster 410 und einen ersten
Algorithmus 412 auf. In dem Mikrocontroller 406 sind
ein erster Algorithmus 414, ein zweiter Algorithmus 416,
ein Testmusterverifikator 418 und ein Komparator 420 vorgesehen.
-
Der
Datenfluss ist bspw. einkanalig von dem Bildgeber 400 zu
dem FPGA 402. In dem FPGA 402 findet die Datenvorverarbeitung
statt. Das Ergebnis wird im gemeinsamen Speicher von FPGA 402 und Mikrocontroller 406,
nämlich dem RAM 404, abgelegt. Auf Basis dieser
Ergebnisse berechnen im Mikrocontroller 406 zwei diversitäre
Algorithmen die Objektdaten. Die Ergebnisse der diversitären
Algorithmen werden in dem Komparator 420 verglichen.
-
In
dem FPGA 402 werden die Bilddaten um definierte und nicht
statische Testmuster 410 erweitert, die ohne Sonderbehandlung
in dem FPGA 402 bearbeitet werden. Das Ergebnis der Testmuster 410 wird
in dem Mikrocontroller 406 überprüft.
-
Voraussetzung
ist die hinreichende Diversifizierung der Algorithmen auf Basis
gleicher FPGA-Ergebnisse, was eine Vorverarbeitung ermöglicht,
und dass hinreichend diversitäre Algorithmen auf einer fehlerhaften
Hardware nicht zum gleichen Ergebnis kommen. Von Vorteil ist, dass
das Hardware-Grundkonzept übernommen werden kann. Weiterhin
vorteilhaft ist die gute Erkennung systematischer und zufälliger
transienter/permanenter Fehler.
-
In 6 ist
die Detektion permanenter FPGA-Fehler verdeutlicht. Ein Bildgeber
gibt Bilddaten 452 an ein FPGA 454. In diesem
FPGA 454 wird zusätzlich ein Testmuster 456 erzeugt.
In einer Einheit 458 erfolgt eine Testmusterverifikation,
so dass ein Datensatz 460 mit Bilddaten 452 und
Testmuster 456 vorliegt. Die Testmuster 456 zu
Beginn und am Ende jedes Bildes ermöglichen eine vollständige
Testabdeckung des FPGA 454 (pipelining im FPGA). Der Datensatz 460 wird
weitergeleitet (Pfeil 462).
-
Das
Testmuster 456 am Anfang und am Ende des eigentlichen Bildes
stellt für den aktuellen Zyklus sicher, dass keine permanenten
Fehler vorliegen. Die Muster sind nicht konstant, sondern werden in
jedem Zyklus gegeneinander veschoben. Der Speicher in dem FPGA 454 wird
vollständig abgetastet. Die Ergebnisse werden blockweise
in der Ergebnisliste abgelegt. Die Position des Ergebnisblocks innerhalb
der Liste wird ebenfalls rotiert. Der relevante Speicherbereich
ist dadurch abgesichert.
-
In 7 ist
ein mögliches Komparatorkonzept gezeigt. Die Darstellung
zeigt einen Komparator 500 mit zwei Eingängen,
nämlich einen Kanal A 502 und einen Kanal B 504.
Zu beachten ist, dass in jedem mehrkanaligen System der Vergleich
der Kanäle 502 und 504 der einzige ”single
point of failure” ist.
-
Die
Darstellung zeigt weiterhin einen SCON 506, einen CRC (cyclic
redundancy check) 508, einen Nachrichtenzähler 510 und
einen Fahrzeugbus 512. Zur Überprüfung
des Komparators 500 sendet der SCON 506 eine sogenannte
Challenge (Pfeil 514) und empfängt eine Antwort
bzw. Response (Pfeil 516). Je nach Ausgang der Überprüfung
sendet der SCON 506 ein enable oder disable zu dem Fahrzeugbus 512 (Pfeil 518).
-
Ein
erster kritischer Fehlerfall, der sogenannte stuck-at-1 (permanente
Zustimmung) muss erkannt werden. Der SCON 506 stellt eine
Anfrage, die zur Ablehnung führen muss. Antwortet der Komparator 500 falsch,
gibt der SCON 506 den Fahrzeugbus 512 nicht frei
(disable).
-
Unkritische
Fälle sind eine permanente Ablehnung (stuck-at-0), da das
System fail-safe ist. Weiterhin unkritisch ist ein transienter einmaliger
Fehler, der in Bezug zur Fehler-Latenzzeit und der Trägheit der
angesteuerten Aktuatorik zu vernachlässigen ist.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - DE 102005057267
A1 [0003]
-
Zitierte Nicht-Patentliteratur
-