Zerstörungsfreie Materialprüfung
Berlin, 21.-23. Mai 2001 -Berichtsband 75-CD
START| DGZfP-JAHRESTAGUNG 2001 Zerstörungsfreie Materialprüfung | ZfP in Anwendung, Entwicklung und Forschung Berlin, 21.-23. Mai 2001 -Berichtsband 75-CD | START |
|
Gängige Verfahren zur Gussfehlererkennung in Aluminiumgussteilen benutzen ein Röntgenbild des fraglichen Gussteiles, und bearbeiten diese Aufnahme mit speziell angepaßten Filtern. Das Verfahren muß jeweils für ein bestimmtes Teil parametrisiert werden.
Ein alternatives Verfahren beruht darauf, eine Sequenz von Röntgenbildern auszuwerten, die das Gussteil aus verschiedenen Richtungen zeigen. Dabei werden insbesondere die Positionsinformationen benutzt, um einen Fehler durch mehrere Aufnahmen hindurch zu verfolgen. Ein echter Fehler sollte - als Projektion eines dreidimensionalen Objektes - in mehreren Bildern vorhanden sein. Dadurch wird eine sichere Unterscheidung von zufällig auftretenden Störungen möglich. Das Verfahren muß nicht für jedes zu untersuchende Teil neu parametrisiert werden, sondern arbeitet korrekt mit unterschiedlichsten Gussteilen. Ein kritischer Punkt dieses Verfahrens ist die Geschwindigkeit, da für jedes Prüfteil, eine ganze Anzahl von Bildern ausgewertet werden muss.
Das Verfahren soll hier nur kurz vorgestellt werden (eine ausführliche Darstellung findet sich etwa in [1, 2]). Es lässt sich grob in zwei Phasen untergliedern. Als Eingangsdaten dient eine Sequenz von Röntgenbildern. Im ersten Abschnitt des Verfahrens, der auch den größten Anteil der Verarbeitungszeit in Anspruch nimmt, wird jedes Bild der Sequenz bearbeitet. Nach einer Vorfilterung wird eine Kantenerkennung durchgeführt, danach eine Segmentierung. Durch die Extraktion von Merkmalen lassen sich die gefundenen Segmente klassifizieren. Als Zwischenergebnis erhält man eine Sammlung von hypothetischen Gussfehlern.
Abb 1: übersicht des Verfahrens .
|
Im zweiten Teil des Verfahrens werden diese hypothetischen Fehler verfolgt. D.h., es wird versucht, einen Fehler aus einem Bild in einem darauffolgenden Bild wiederzufinden. Dabei werden die Informationen über die translatorische Positionsveränderung und die Drehung des Objektes zwischen den Aufnahmen ausgenutzt. Nur ein hypothetischer Fehler, der sich auch in einer bestimmten Anzahl darauffolgender Aufnahmen findet, wird als Gussfehler detektiert. Dadurch ist eine Klassifizierung der hypothetischen Fehler in Gussfehler und Fehldetektionen möglich.
Abbildung 1 zeigt eine übersicht über die Phasen des Verfahrens.
Das Verfahren wurde als Laborprototyp durch mehrere MatLab - Routinen implementiert. Diese wurden mit realen und bei simulierten Fällen getestet; die vorläufigen Ergebnisse bei der Detektion sind vielversprechend (100% der Gussfehler in 16 Bildsequenzen wurden erkannt. Dabei trat keine Fehldetektion auf.) Es sollte nun in einer Windows - Applikation in C++ implementiert werden, um dadurch eine größere Ausführungsgeschwindigkeit zu erreichen. Der vorliegende Beitrag beschreibt Designschwerpunkte und Strategie dieser Implementierung. In Abschnitt 2 wird der auf den Aufbau der Implementierung näher eingegangen, dabei wird in Abschnitt 2.3 der Einsatz von MMX beleuchtet. Abschnitt 3 gibt einen überblick der Ergebnisse, Abschnitt 4 die Schlussfolgerungen.
Die Implementierung verfolgt einen objektorientierten Ansatz und läuft unter Windows NT. Um das Verfahren möglichst unabhängig von einer spezifischen Prüfumgebung zu implementieren, wurde auf die Trennung von Verfahren und Benutzerschnittstelle geachtet (Document - View - Architecture). Die Benutzeroberfläche der Implementierung ermöglicht die Beeinflussung sämtlicher Parameter des Verfahrens.
2.1 Document - View - Architectur
Die Konzeption des Programmes stand unter dem Leitmotiv, eine überschaubare Struktur zu schaffen. Das Verfahren zur Gussfehlererkennung sollte unabhängig von einer bestimmten Benutzerschnittstelle arbeiten, deshalb war es wichtig, die Methoden und die Daten von der Benutzersteuerung und der Darstellung der Daten zu trennen. Ganz natürlich ergab sich aus dieser Vorgabe eine Strukturierung in eine Document - View - Architecture. Eine übersicht und Einführung dazu gibt [4].
In einer Document - View - Architecture sind die Daten, die das Programm verarbeitet (das Document) streng von der Darstellung dieser Daten (den Views) getrennt. Der Begriff des Document mag hier ein wenig in die falsche Richtung führen, in dem er zuerst an die "Dokumente" in Textverarbeitungsprogrammen und Spreadsheets erinnert. Tatsächlich versteht sich darunter die Gesamtheit aller Daten, die ein Programm verarbeitet. Im Falle der Gussfehlererkennung wären das also die zu bearbeitenden Bilder, die Ergebnisse der Zwischenschritte, die entgültigen Resultate. Des weiteren behandelt der Document - Teil die Speicherung und Manipulation dieser Daten.
Ein Document kann durch mehrere Views dargestellt werden. Ein View könnte z.B. eine bildliche Darstellung eines Ergebnisses sein, aber auch eine Aufbereitung statistischer Ergebnisse. Durch die strikte Trennung beider Teile ist es ohne weiteres möglich, dem Programm neue Views (also Darstellungsarten) hinzuzufügen, ohne den Daten - Teil (das Document) zu verändern (Abbildung 2).
Abb 2: Document - View - Architecture.
|
Der Document - Teil enthält die Speicherrepräsentation der Daten sowie Methoden zu ihrer Verarbeitung. Unabhängig davon ist die Benutzerschnittstelle: Sie besteht aus dem View - Teil, der für die Darstellung der Daten verantwortlich ist, und der Benutzersteuerung, die die Steuerung der Programmparameter über Menüs, Dialoge etc. ermöglicht. Abbildung 3 zeigt eine grobe übersicht der Programmstruktur.
Abb 3: Steuerung und Darstellung.
|
Abb 4: Aufbau der Kommunikationsschnittstelle.
|
Um eine möglichst große Unabhängigkeit von einer bestimmten Benutzerschnittstelle zu gewährleisten, bildet die Erkennung einen eigenen Programm - Thread. Unter einem Thread versteht man eine Art Prozeß, der im Gegensatz zur Win32 - Task aber nicht unabhängig ausgeführt werden kann. Trotzdem agieren die Threads natürlich völlig unabhängig voneinander. Ein Programm kann aus beliebig vielen verschiedenen Threads bestehen.
Der Vorteil liegt darin, dass Aktionen, die nicht auf einander aufbauen, sich also nicht gegenseitig bedingen, von einander getrennt werden können. Die Threads werden quasiparallel ausgeführt, d.h. für den Benutzer sieht es so aus, als liefen die Threads parallel nebeneinander, so wie z.B. auch Betriebssystemprozesse parallel zu Benutzerprogrammen ausgeführt werden. Tatsächlich werden die Prozesse natürlich nacheinander ausgeführt, indem ihre Ausführung vom Betriebssystem für einen kleinen Zeitabschnitt ("Zeitscheibe") angestoßen wird, um dann wieder suspendiert zu werden.[In einem Parallelrechner, der über mehrere CPUs verfügt, wäre - ein entsprechendes Betriebssystem vorausgesetzt, das die Verteilung der Threads auf die CPUs übernehmen kann - eine tatsächlich parallele Ausführung möglich]
Bei der Gussfehlererkennung ergibt sich als zusätzlicher Vorteil, dass die eigentliche Erkennung gänzlich unabhängig von der Benutzeroberfläche programmiert werden kann. Der einzige Berührungspunkt ist die Kommunikationsschnittstelle zwischen beiden Programmteilen. Die Benutzeroberfläche kann also problemlos ausgetauscht werden, bzw. das Erkennungsverfahren kann ohne weiteres in eine andere Benutzeroberfläche eingepasst werden.
Abbildung 4 zeigt das Zusammenwirken der beiden Programmteile. Die Benutzerschnittstelle führt nur Schreibzugriffe auf die Parameter durch. Das Erkennungsverfahren liest die Parameter, ohne sie zu verändern, und schreibt in den Datenbereich. Um die Daten darzustellen, liest der View - Teil den Datenbereich.
2.2 Praktische Umsetzung
Um den Datenbereich, der die Schnittstelle zwischen den Programmteilen bildet, übersichtlich zu gestalten, wird er auf mehrere globale Variablen aufgeteilt. Diese sind aus jedem Programmodul heraus erreichbar.
Die Anwendung selbst wird entsprechend des MFC (Microsoft Foundation Classes) - Modells durch eine von CWinApp abgeleitete Klasse CApplication gebildet. Dieses initialisiert zuerst den View - Teil der Anwendung. Beim Start der Erkennung wird ein neuer Thread gestartet, der das eigentliche Verfahren bildet. über die Funktion CApplication::OnIdle(), die regelmäßig vom Scheduler des Betriebssystems angesprochen wird, werden die verschiedenen Ansichten auf den neuesten Stand gebracht. Dadurch ist eine weitestgehende Unabhängigkeit der beiden Programmteile gewährleistet.
Da es eines der Entwicklungsziele war, ein Programm mit möglichst kurzer Rechenzeit zu schaffen, wurden die programmierten Verfahrensschritte einem Profiling unterzogen, um nach Stellen im Programmcode zu fahnden, an denen noch Verbesserungen zur Geschwindigkeitssteigerung vorgenommen werden könnten. Dabei wurde als einer der Schritte, die am meisten Zeit benötigten, die Segmentierung identifiziert (s. Abbildung 1). Der dort eingesetzte Region - Growing - Algorithmus erkennt durch Kanten abgeteilte Segmente im Bild. Es wurde besondere Mühe darauf verwendet, einen Algorithmus zu entwickeln, der sowohl schnell als auch sicher und robust war. Näheres dazu findet sich in [3].
Eine weitere Möglichkeit, die Ausführungszeit zu verbessern, lag in der Verwendung des MMX - Befehlssatzes. Dies wird im folgenden Abschnitt beschrieben.
2.3 MMX
Moderne, Intel-kompatible PC - Prozessoren bieten einen zusätzlichen Befehlssatz, der es ermöglicht, Algorithmen der Bildverarbeitung sehr schnell auszuführen. Diese MMX - Befehle (MultiMedia eXtension) wurden ursprünglich entwickelt, um eine größere Performance im Grafikbereich zu ermöglichen. MMX - Befehle werden an eine besondere Ausführungseinheit im Prozessor übergeben, und dort parallel zueinander ausgeführt. Es handelt sich praktisch um eine zweite ALU, die in sich selbst hoch parallel arbeitet. Es handelt es sich um einen SIMD - Befehlssatz (Single Instruction - Multiple Data), d.h. mit einem Befehl werden bis zu acht Datenwerte parallel verarbeitet. Die Programmsteuerung wird dabei vom konventionellen Prozessorkern ausgeführt.
Allein durch die Möglichkeit, bis zu acht Integer - Berechnungen parallel ausführen zu können, ist beim Einsatz von MMX eine enorme Geschwindigkeitssteigerung zu erwarten.
In der Vergangenheit war die Verwendung von MMX dadurch erschwert, dass kein Hochsprachencompiler Berechnungen in den MMX - Befehlssatz übersetzte. Die einzige Möglichkeit, die Multimedia Extensions doch einzusetzen, bestand darin, zumindestens die Berechnungen in Assembler zu codieren. Da dies, was die Komplexität des Codes und die Wartbarkeit anbetraf, einen kaum zu rechtfertigen Mehraufwand bedeutete, lag die Hemmschwelle zur Benutzung von MMX sehr hoch. Eine Darstellung zur Anwendung von MMX für die Bildverarbeitung gibt [5].
Inzwischen stellt Intel für verschiedene Anwendungsgebiete Libraries bereit, in denen die MMX - Befehle in komplexen Funktionen gekapselt sind, die in Hochsprachenprogramme eingebunden werden können. Neben der Intel Image Processing Library (TM), die in der Applikation zur Gussfehlererkennung eingesetzt wurde, gibt es z.B. auch eine speziell auf die eindimensionale Signalverarbeitung abgestellte Intel Signal Processing Library (TM). Die Bibliotheken sind als Dynamic Link Libraries (DLL) ausgelegt, können somit aus fast jeder Programmiersprache angesprochen werden.
Ein weiteres Hindernis bei der Arbeit mit MMX ist die Prozessorabhängigkeit des Befehlssatzes. Zwar unterstützen alle Prozessoren seit dem Pentium MMX die MMX - Befehle, doch wurde der Befehlssatz seit dem mehrfach erweitert und verändert. ältere Prozessoren, etwa der Pentium oder der DX4, stehen sowieso außen vor. Das erfordert es, eine Applikation, die MMX einsetzen möchte, entweder für jeden Prozessor anzupassen, oder auf einige Prozessoren zu beschränken.
Auch dieses Problem wird mit dem Einsatz einer der MMX - unterstützenden Libraries aus dem Weg geräumt. Das Programm bindet eine DLL mit dem Namen ipl.dll ein. Diese prüft - mit Hilfe einer zusätzlichen DLL - Cpuinf32.dll - welcher Prozessor installiert ist, und lädt dann zur Laufzeit eine prozessorspezifische DLL nach, die die Bibliotheksfunktionen realisiert. Diese Vorgänge laufen für die Anwendung völlig transparent ab - gleichsam "unter der Haube" - so dass sich der Entwickler darum nicht weiter kümmern muss (Abbildung 5). Ein zusätzlicher Vorteil liegt darin, dass die Anwendung die möglicherweise verbesserten Fähigkeiten künftiger Prozessoren automatisch nutzt, indem dann eine andere prozessorspezifische DLL eingebunden wird.
Abb 5: Initialisierung der MMX Bibliothek.
|
Die Intel Image Processing Library bietet Funktionen, mit denen Filter, Faltungen etc. berechnet werden können und enthält die zugehörigen Datenstrukturen. Dabei werden Bilder durch einen Header beschrieben, dem die eigentlichen Bilddaten zugeordnet werden. Die Bibliothek unterstützt zahlreiche Datenformate, z.B.
Als Datentiefe pro Bildpunkt werden 1 bit, 8 bit, 16 bit und 32 bit integer sowie 32 bit float - Werte unterstützt.
Um mit den MMX - Funktionen arbeiten zu können, müssen die Bilder, die verarbeitet werden sollen, im Datenformat der Bibliothek vorliegen. Natürlich ist es möglich, ausschließlich mit diesen Datenformaten zu arbeiten. Da die Anwendung zur Gussfehlererkennung aber ursprünglich ohne Zugriff auf die Intel Image Processing Library entwickelt worden war und andere Datenrepräsentationen nutzte, als es die Bibliothek vorsah, mussten die Bilddaten jeweils in neue Variablen umkopiert werden. Abbildung 6 stellt die einzelnen Schritte zum Aufruf als Struktogramm dar.
Abb 6: Aufruf einer MMX - Funktion.
|
Trotz des Overheads, der durch das zweimalige Umkopieren der Bilddaten und durch die Bereitstellung und Freigabe des Speichers entsteht, ließ sich damit eine große Geschwindigkeitsverbesserung erreichen. (s. hierzu Abschnitt 3)
Die Intel Library zur Bildverarbeitung steht unter [6] kostenlos zur Verfügung. Dort findet sich auch eine ausführliche Dokumentation.
Um die Ausführungsgeschwindigkeit des Programms beurteilen zu können, wurden mehrere Sequenzen von Röntgenbildern mit unterschiedlicher Anzahl von hypothetischen Gussfehlern untersucht. Die Sequenzen bestehen aus jeweils zehn Bildern bei einer Größe von 256 x 256 Pixeln, sind also kleiner als in der Praxis verwendete. Pro Bild ergab sich eine Verarbeitungszeit von etwa 0.5s.
Für die in der Praxis verwendeten Bildgrößen ergibt sich daraus eine Verarbeitungszeit von etwa 1s pro Bild auf einem Pentium III, 600 MHz. Eine realistische Sequenz aus 70 Aufnahmen ließe sich in ca. einer Minute verarbeiten. Der Rechenzeitgewinn durch die Verwendung von MMX ist dabei unabhängig von der Anzahl der hypothetischen Gussfehler. Das ist darauf zurückzuführen, dass MMX - Befehle z.B. für die Berechnung des Gradienten des Bildes eingesetzt werden. Die Rechenzeit hängt dabei nur von der Bildgröße, aber nicht von der Anzahl der hypothetischen Gussfehler ab. Abbildung 7 zeigt die Rechenzeiten für das Gesamtverfahren für Bildsequenzen aus jeweils zehn Bildern mit unterschiedlicher Anzahl hypothetischer Gußfehler.
Abb 7: Ausführungszeit abhängig von der Anzahl der hypothetischen Gussfehler.
|
Das gleiche ergibt sich, wenn man sich nur die Ausführungszeiten für die Detektion der hypothetischen Gussfehler ansieht, also den ersten Teil des Verfahrens. Die Rechenzeit steigt hier linear an, der Rechenzeitgewinn durch den Einsatz von MMX bleibt annähernd gleich. Abbildung 8 zeigt für Sequenzen von zehn Bildern die Ausführungszeit der Detektion in Abhängigkeit von der Anzahl der hypothetischen Gussfehler.
Abb 8: Ausführungszeit für den ersten Teil des Verfahrens.
|
Bei der Verfolgung der hypothetischen Gussfehler über mehrere Aufnahmen hinweg, die den abschließenden Schritt des Verfahrens darstellt, ergibt sich hingegen eine exponentielle Abhängigkeit von der Anzahl der hypothetischen Gussfehler. Hierbei gibt es keinen Unterschied durch den Einsatz von MMX, da die MMX - Befehle für diese Berechnungen nicht zum Einsatz kommen. Abbildung 9 zeigt dies wieder für Sequenzen aus zehn Bildern mit einer Bildgröße von 256 x 256 und einer unterschiedlichen Anzahl hypothetischer Gussfehler.
Abb 9: Ausführungszeit für den zweiten Abschnitt des Verfahrens.
|
Mery beschreibt in [1, 2] ein neues Verfahren zur Gussfehlererkennung in Aluminiumgussteilen. Das Verfahren wurde ursprünglich in MatLab realisiert und getestet. Aufgabe dieses Projektes war es, eine Implementierung in der Programmiersprache C++ zu erstellen. Dabei wurden folgende Ziele angestrebt:
Durch die Verwirklichung dieser Ziele erscheint es nun möglich, das Verfahren auch in einer industriellen Umgebung einzusetzen, um die Qualitätssicherung in der industriellen Herstellung von Aluminiumgussteilen zu verbessern.
Hier spielt noch ein weiterer Vorteil hinein: Die überschaubare Programmstruktur ermöglicht es, änderungen und Erweiterungen leicht durchzuführen. Somit kann zukünftig die Implementierung des Verfahrens noch verbessert werden.
Besonderes Augenmerk wurde auch darauf gerichtet, die Implementierung des eigentlichen Verfahrens unabhängig von der Benutzeroberfläche zu machen (Document - View - Architektur). Somit ist es leicht möglich, das Verfahren in vorhandene Systeme einzupassen.
Gleichzeitig ermöglicht es die Bedienoberfläche, die Verfahrensparameter auf einfache Art und Weise zu beeinflussen, und damit das Verfahren selbst zu variieren. So können verschiedene Verfahren der Kantendetektion, der Vorfilterung etc. ausgewählt werden. Dadurch werden Untersuchungen ermöglicht, in denen Qualität und Robustheit des Verfahrens bei unterschiedlichsten Bedingungen untersucht werden.
Die Geschwindigkeit der Implementierung wird als ausreichend für den industriellen Einsatz betrachtet. Auf einem PC heutiger Technologie können pro Minute über 70 Aufnahmen verarbeitet werden. Diese Geschwindigkeit wurde u.a. durch den Einsatz von MMX zur Bildverarbeitung genutzt.
Damit wurde das Ziel des Projektes, zu zeigen, dass das Verfahren industriell einsetzbar ist, erreicht.
| Herausgeber: DGfZP, Programmierung: NDT.net | START |
Beiträge