1994babarOS: OS/2 Tools für Bildverarbeitung und Messtechnik

Anfang der 1990-er Jahre startete ich zusammen mit meinem Vater Dr. Burghard Korneffel das Familenunternhemen trAC - Optische Comuputer Sensorik. Unser Ziel war die Entwicklung und Vermarktung innovativer, bildverabreitungsbasierter Messsysteme. Leistungsfähige PC's zum kleinen Preis sowie unsere speziellen, sich ergänzenden Fachkentnisse (Physik, Informatik), motivierten uns zu diesem Schritt.

OS/2 2.0 war Anfang der 90-er Jahre das innovativste PC- Betriebssystem. 32 bit mit Multithreading, graphischer Benutzeroberfläche und einer segmentlosen, virtueller Speicherverwaltung, die ihre Grenzen erst weit jenseits der 640KB von MS-DOS hatte (512 MB), bot es sich als Plattform für die Implementierung neuer, innovativer Messsysteme auf Basis digitaler Bildverarbeitung an. Wir entschlossen uns für den Einsatz von OS/2.

Nachteil von OS/2 war die zögerlich bis mangelnde Unterstützung durch die Software- Hersteller, speziell im technischen Bereich. Für unseren Aufgabenbereich löste ich das Problem durch selbstentwickelte, systemnahen OS/2 Tools und Bibliotheken. Meine Programmierwerkzeuge damals waren:

IBM- Editor EPM
IBM- C Compiler CSet
IBM- Projektverwaltung Workframe 2
Borland x86 Assembler TASM

32bit OS/2 Gerätetreiber für EISA- Framegrabber

Zum Einlesen von CCD Zeilenkameras mittels des 32bit EISA - Framegrabbers 3966 der Firma Data- Translation entwickelte ich einen OS/2 Gerätetreiber (protected Mode, DosDevIOCTL). Sein herausragendes Merkmal war die in einer virtuellen Speicherumgebung anspruchsvolle Implementierung der leistungsfähigen EISA- DMA- Transfers. Es gelang, bis zu 32 MB/s Bilddaten in den Arbeitsspeicher zu transferieren bei minimalem Verbrauch an CPU- Ressourcen.

Mit der selbstentwicklten OS/2- Gui KameraKonsole konnte der Gerätetreiber komfortabel konfiguriert werden.

Die eingelesenen Bilddaten legte die KameraKonsole in einem konfigurierbaren zyklischen Puffer ab. Mittels OS/2 API für Interprozesskommunikation konnte dieser sicher von Anwendungen aus anderen Prozessen eingelesen und weiterverarbeitet werden. Der zyklische Puffer war als wiederverwendbares Modul in C implementiert, genannt babnet.dll.

OS/2 Visualisierungstool "Signalvision"

Zur Darstellung von ein- und zweidimensionalen Bildsignalen aus CCD- Kameras, sowie zur graphischen Analyse von Messdaten entwicklete ich das Tool Signalvision.

Die Signalvision konnte wie ein Oszilloskop in Echtzeit das Helligkeitsprofil einer Bildzeile darstellen. Sie besaß Maus- Tools zur Ausschnittsvergößerung (Zoom), und dem Vermessen einzelner Werte im Graph (x, y).

Eine weitere Besonderheit zum damaligen Zeitpunkt war die Darstellung nahezu beliebig vieler Messdaten. Begrenzt wurde sie nur durch den verfügbaren virtuellen Speicher.

OS/2 CSV- Reader TabSelektor

Unsere Messsysteme speicherten die Messdaten in mehrspaltigen CSV- Dateien. Dank ihrer schnellen CCD- Zeilensensoren (bis zu 10.000 Bilder/sec) wuchsen schon nach wenigen Minuten wahre CSV- Monster bei einer Messung mit hunderttausenden bis millionen Datenzeilen heran. Die Analyse dieser mit Tabellenkalkulationssoftware aus dem Office- Bereich war damals nicht möglich. Das von mir entwicklete OS/2 Tool Tabselektor zusammen mit der Signalvision löste das Problem.

Der Tabselektor ermöglichte die Auswahl von zwei Spalten als x- und y- Koordinate. Danach las er die CSV- Datei ein, und sendete die gewählten Zeilen z.B. als (x, y) Koordinaten an die Signalvision. Alternativ konnten die Messdaten an ein Modul zur automatischen Analyse gesendet werden.

1994 Verkehrszähler

Im Frühjahr 1994 entwickleten wir ein erstes Messystem auf Basis der Optischen Computer Sensorik: den Verkehrszähler. Dieser war ein bildverarbeitungsbasiertes Zählsystem zur Erfassung von Verkehrsströmen auf mehrspurigen Autobahnen in Echtzeit. Bei der Erfassung wurde eine Klassifikation der Fahrzeuge nach Pkw's und Lkw's realisiert. Geschwindigkeit, Länge und Abstand zum vorausfahrenden Fahrzeug konnte für jedes gezählte Fahrzeug gemessen und aufgezeichnet werden.

Zum Zählen wurde eine CCD- Zeilenkamera mit 2048 Pixeln der Firma Schäfter Kirchoff auf einer Brücke an einem Ausleger über die zu beobachtende Fahrspur aufgehangen (Bild 1). Die Bildzeile war dabei in einem Winkel, z.B. 45° aus der Fahrtrichtung gedreht (Bild 2). Die Kamera schoss etwa 1000 Bilder pro Sekunde.

Die Kamerabilder durchliefen auf dem Weg in den Computerspeicher eine von meinem Vater Dr. Burghard Korneffel entwickelte Bildvorverarbeitungsstufe, die in analoger Rechentechnik ein Kantenextraktionsverfahren über den gesamten Dynamikbereich der CCD- Sensoren implementierte. Das Resultat zeigt Bild 3. Es setzt sich aus hunderten, hintereinander aufgenommenen Bildzeilen zusammen. Die Vorverarbeitung hat die Konturen auf den Fahrstreifen (Markierungen, Flecken, in der Sonne blitzende Steinchen) sowie der durchfahrenden Fahrzeuge auf 1, und Rest auf 0 abgebildet. Ruhende Konturen bleiben in allen Bildern nahezu ortsfest. Konturen durchfahrender Fahrzeuge wandern bedingt durch die Ausrichtung der Zeilenkamera zur Fahrtrichtung in einem Winkel < 90° schräg durch das Bild. Meine Software hatte nun die Aufgabe, anhand der "schrägen" Linien die Fahrzeuge zu erkennen (und zu zählen), sowie die Geschwindigkeit abzuschätzen.

Ich entwickelte den Verkehrszähler auf Basis der zuvor geschaffenen OS/2 Tools und C++ Bibliotheken.

GUI: OS/2 2.0 Workplace Shell
Business Layer: ca. 1000 Zeilen C++ Code

Entwicklungswerkzeuge

x86- Assembler, IBM CSet C- Compiler

Hardware

486 EISA PC mit 16 MB RAM, OS/2 2.0; Framegrabber DT3966; CCD- Zeilenkamera der Fa. Schäfter + Kirchhoff, 2048 Pixel, max. 2000 Bilder/s; spezielle von Dr. B. Korneffel entwickelte Elektronik zur Kamera- Ansteuerung und Bildvorverarbeitung

1995 Bildverarbeitungsbasierte Geschwindigkeitsmessung OptoTacho

Eine Vermarktung des Verkehrszählers erwies sich für uns im Jahr 1994 als unrealistisch. Durch unsere Vermarktungsaktivitäten und den Besuch von Fachmessen erfuhren wir jedoch vom Bedarf nach einem berührungslosen Geschwindigkeitsmessverfahren für Messaufgaben in der Fahrzeugentwicklung und im Maschinenbau.

Wir entwickelten die beim Implementieren der Geschwindigkeitsabschätzung im Verkehrszähler entstanden Ideen weiter zu einem hochgenauen Verfahren zur zeitlich hoch aufgelösten, berührungslosen Geschwindigkeitsmessung und patentierten es (Patenanmeldung: DE 44 44 661 A1 ).

Software

Das patentierte Verfahren berechnet die Geschwindigkeiten mittels statistischer Auswertung über hunderte Weglängen, die beim Verfolgen optisch sichtbarer Konturen in einem kleinen Zeitfenster ermittelt werden. Bild 2 zeigt eine Folge von Rohbildern (Zeilen) aus der analogen Bildvorverarbeitung. Die hellen, perlenschnurartigen Strukturen entstanden durch die Bewegung des beobachteten Messgutes, wobei die Vorverarbeitung die Kanten der optisch sichbaren Objekte auf den Wert 1, und den Rest auf den Wert 0 abbildete. Wir nannten die perlenschnurartigen Strukturen Konturspuren .

Ich implementierte das Verfahren durch einen hoch optimierten, rekursiven Algorithmus in C++, der die Konturspuren in den Bildreihen verfolgte und schließlich ihr Längen vermaß. Alle Konturspurlängen flossen in eine Statistik ein. Im einfachsten Fall wurde der Mittelwert aus dieser Statistik in einen Geschwindigkeitswert umgerechnet. In die Umrechnung floss der Abbildungsmaßstab und die Belichtungszeit ein.

Dank intelligenter Bildvorverarbeitung mit Analogrechentechnik, OS/2- Multithreading und hoch optimierenden C++ Compiler gelang die Implementierung des bezüglich der Rechenleistung anspruchsvollen Verfahrens mit der billigen PC- Rechentechnik der 1990er. Wir konnten in Echtzeit bis zu 1000 Messwerte/sec (t_akt, v_akt, s_akt) errechnen. Dabei blieb das System voll bedienbar: keine Sanduhr, keine blockierte Oberfläche ! Ein neues, innovatives Messsystem stand nun für die Industrie bereit.

GUI: OS/2 Workplace Shell
Business Layer: ca. 5000 Zeilen C++ Code
Data Access Layer: ca. 2000 Zeilen Assembler- und 300 Zeilen C++ Code (OS/2 Gerätetreiber für Datel pc415 Framegrabber)
Messrate: Echtzeit: 1000 Hz, Offline: 4000 Hz; Pro Sekunde wird bis zu 4000 Mal die Geschwindigkeit des Messgutes gemessen. Offline erfolgt die Berechnung auf zuvor aufgezeichneten Video- Rohdaten
Messbereich
Messgenauigkeit: Geschwindigkeit: 1 ‰, Weg: 0,1 ‰
Messkopf: CCD Zeilenkamera der Firma Reticon, 2048 Pix a 14x28 µm, 10 MHz Pixeltakt -> ca. 4000 Zeilen/sec
Bildaufbereitung: Selbstentwickelte elektronische Einheit zur Kamaraansteuerung und Signalaufbereitung. Mittels der Analogrechner- Technologie wurde ein Kantenextraktionsverfahren implementiert, das über den gesamten Dynamikbereich des CCD wirkte. Ergebnis war eine hohes Maß an Invarianz gegenüber inhomogener Bildfeldauleuchtung und abrupten Änderungen der Bildhelligkeit.
Digitale Bildverarbeitungseinheit: 19 Zoll Rack Industrie PC, i486 CPU 676 MHz, Eisa BUS (32bit), 32 MB Ram, OS/2 3.0 Warp (32bit)

Ab 1995: Hochgenaue, berührungslose Geschwindigkeitsmessung als Dienstleistung

Wer benötigt einen hochgenauen, berührungslosen Geschwindigkeitsmesser ? Die Frage wurde in zahlreichen, anspruchsvollen Messungen beantwortet, die wir als Dienstleistungen bei Partnern in der Industrie erbrachten. Im Folgenden einige Highlights:

1995 Geschwindigkeitsmessung auf nasser Fahrbahn bei Fa. Goodyear™, Luxembourg

Neu entwicklete Reifen müssen ihre Tauglichkeit bei einer Vielzahl von Fahrversuchen unter Beweis stellen, bevor sie für den Markt zugelassen werden. Die Firma GoodYear™ betreibt dazu in Luxemburg Teststrecken.

Problematisch sind Fahrversuche auf nassen Fahrbahnen. Berührungslose Messysteme wie Doppler Radar funktionieren gut auf trockner- , werden jedoch von Tröpfchen und Wellenschlag auf nasser bzw. gefluteter Fahrbahn getäuscht. Die Messdaten sind unbrauchbar.

Wir montierten den Messkopf zusammen mit einer Batterie Nebelscheinwerfer kurzerhand aufs Autodach und stellten den GoodYear™ Testingenieuren unseren Wagen zur Verfügung. Sie absolvierten damit auf der Teststrecke eine Reihe waghalsiger Fahrversuche, während wir auf dem Rücksitz die Messungen durchführten.

Die prinzipielle Lösbarkeit der Aufgabe konnten wir mit unserem Messsystem zeigen, aber es offenbarten sich in der Praxis die Notwendigkeit, eine optimale Einstellung der vielen Paramter des Messsystems für die jeweilige Aufgabenstellung zu finden. Wir zeichneten bei weiteren Testfahrten die rohen Bilddatenströme des Messkopfes auf Festplatte auf. Sie waren in den folgenden Monaten die Grundlage für die Parameteroptimierung im Labor.

Ortung schnell fahrender Gleismesszüge, DB Bahnwerk Minden

In Fahrversuchen mit dem PKW war uns die hohe Wiederholgenauigkeit unseres Geschwindigkeitsmesssystems bei der Wegmessung aufgefallen. Auf Rundfahrten von über 10 km Länge wich die wiederholt gemessene Weglänge um maximal einen Meter ab ! Diese von uns publizierten Ergebnisse weckten das Interesse von Mitarbeitern der Deutschen Bahn im Bahnwerk Minden, welche einen schnellfahrenden Gleismesszug entwickelten.

Der Gleismesszug war mit umfangreicher Sensorik bestückt, mittels der während des Befahrens feine Risse in den Schienen und Gleisverwerfungen erkannt werden konnten. Ein Problem war jedoch die Ortsbestimmung. Bei einer Geschwindigkeit von z.B. 180 km/h legte der Zug in einer Sekunde 50 m zurück. Bei einer Ortsbestimmung mit GPS im Sekundentakt würde ein Gleisbautrupp einen 50 m langen Abschnitt nach einem detektierten Haarriss absuchen müssen. In einem kilometerlangen Tunnel fällt GPS ganz aus. Hier musste der Weg aus der Anzahl der Umdrehungen einer Schleppachsen berechnet werden. Deren Genauigkeit liegt bedingt durch Schlupf und Abnutzung im % Bereich. Das bedeutet eine pro Kilometer sich aufsummierende Ungenauigkeit von +/- 5m. Je genauer die Ortsbestimmung, desto größer die Ersparnis für den Gleisbautrupp. Wir vereinbarten eine gemeinsame Versuchsfahrt.

Bei der Versuchsfahrt wurde der Sensorkopf am Wagenübergang montiert (roter Pfeil im Bild). Das Bildfeld war von Schotter und Schwellen ausgefüllt. Wir fuhren von Bahnhof zu Bahnhof und vermaßen die Strecke. Durch Vergleichen der bei der Hin- und Rückfahrt gemessenen Strecke konnten wir die Wiederholgenauigkeit abschätzen. Die bei den PKW Fahrten beobachtet Wiederholgenauigkeit konnte auch auf dem rauen Gleisbett erreicht werden. Die Messfahrt war ein voller fachlicher Erfolg.

Leider verschoben sich in der Folge die Prioritäten beim Bahn- Team, so dass dem fachlichen Erfolg kein geschäftlicher folgte.

1996 Laufruhe des Bandvortriebes einer Lackierstrasse messen (Mercedes)

Mitarbeiter von Mercedes/Bremen projektierten die Automatisierung einer Lackierstrasse mittels Industrieroboter. Die zu lackierenden Karossen sollten dabei vom vorhandenen Fließband am Lackierautomaten vorbeigezogen werden. Es wurde befürchtet, dass Schwankungen der Bandgeschwindigkeit und periodisches Kippen sich negativ auf das Lackierergebniss auswirken könnten. Wir erhielten den Auftrag, die Schwingungen und Schwankungen zu vermessen.

Die Schwankungen der Bandgeschwindigkeiten konnten vom Messsystem sofort gemessen werden. Um auch Verkippungen der Karossen zu messen, koppelten wir zwei Messsysteme, die vertikale Schwingungen am Fließband maßen. Aus der Differenz der Wegmessungen aus beiden Messsystemen konnte der Kippwinkel der Karrossenträger erfolgreich bestimmt werden. Im Bild sind die beiden gekoppelten Messsysteme zu sehen.

1997 Entwicklung eines Antiblockiersystems für Ralleywagen

Aktives Marketing verbreitete die Kunde von unserem Messsystem. Im Jahre 1997 suchten die Entwickler des Rennstalls Toyota Team Europe (TTE ™) ein Geschwindigkeitsmessystem, um den Fahrzustand ihres Rennwagens auch unter extremen Bedingungen genau zu ermitteln. Konkret ging es um die Entwicklung von Antiblokiersystemen für Ralley- Fahrzeuge.

Wir wurden mit der Entwicklung und Lieferung von zwei, speziell für Ralleyfahrzeugen geeigneten Messsysteme beauftragt. Wir mussten Zeilenkamera und Beleuchtung in einem wasserfesten Gehäuse integrieren. Die Software wurde für die Bedienung über Flachbildschirm mit Touch- Display angepasst. Um Messfehler durch Kippbewegungen des Fahrzeuges bei extremen Kurvenfahrten und Bremsmanövern zu beseitigen, implementierten wir eine auf Lasertriangulation basierende Höhenmessung.

In zahlreichen Fahrversuchen unter extremen Bedingungen bewies das Messystem seine Überlegenheit gegenüber konkurrierenden Verfahren. Im Bild sieht man eine Vergleichmessung zwischen Doppler- Radar und unserem OptoTacho beim Durchfahren einer mit Wasser gefluteten Fahrbahn. Während die Messung beim Doppler- Radar im Wasserkasten ausfällt, setzte der OptoTacho unbeeindruckt von den widrigen Bedingungen seine Messung fort.

1998Ortung von Störquellen in Druckmaschienen (KBA)

In den 90-er Jahren entwickelte die Firma KBA™ eine neue, schnell laufende Rotations- Tiefdruckmaschinen mittlerer Größe. Die Druckwerke für die Farben wurden dabei nicht mehr klassisch von einer massiven, sondern modern von einer sogenannten virtuellen Welle synchron angetrieben. Realisiert wurde die virtuelle Welle durch Einzelantriebe in den Druckwerken, die durch eine Mikropozessorsteuerung präzise synchronisiert wurden. Diese Antriebstechnik ermöglichte höhere Prozessgeschwindigkeiten, wodurch die Produktivität größerer Maschienen erreicht wurde.

Bei höheren Prozessgeschwindigkeiten verschlechterte sich jedoch die Produktqualität (stufige Schnittkanten, ungenügend genaue Überlagerung der Farben). Die Suche nach den Ursachen gestaltete sich schwierig, die üblichen Messungen lieferten keine Resultate. Wir erhielten den Auftrag, die Störquellen zu finden.

Das Papier durchläuft von der Papierrolle bis zum Messer, welches die Produkte separiert, alle Prozessstufen und koppelt diese dabei mechanisch. Eine zeitlich hochaufgelößte Geschwindigkeitsmessung auf der Papierbahn, die anschließend einer Fourieranalyse unterworfen wird, sollte alle mechnischen Elemente, die auf das Papier einwirken, im Fourierspektrum als Frequenzpeaks sichtbar machen. So rollt bei einer bestimmten Geschwindigkeit die minimal unrunde Druckwalze n mal pro Sekunde auf dem Papier ab. Ein entsprechneder Peak bei n Hz sollte im Fourierspektrum der Papiergeschwindigkeit sichtbar werden. Das Problem wurde in einer ungünstigen Überlagerung der Frequenzen aller einwirkenden Baugruppen vermutet.

Wir ließen die Papierbahnen während der Messungen mit einem speziellen Muster bedrucken, durch das die Erkennung und Verfolgungn von Konturen in unserem Messsystem sichergestellt wurde. Dadruch konnten bei den Messungen die theoretisch möglichen Genauigkeiten mit dem Verfahren erreicht werden. Es gelang erstmals, die Dynamik beim Bedrucken von Papierbahnen in Tiefdruckmaschienen direkt zu beobachten.

Zusammen mit den Messtechnikern von KBA™/ Würzburg und Gruner & Jahr/ Itzehohe führten wir viele Messreihen bei unterschiedlichen Produktionsgeschwindigkeiten durch. Systematische Analysen der Messreihen brachten nach vielen Stunden harter Arbeit endlich Licht ins Dunkel. Die Zusammenarbeit mit KBA war für uns sehr erfolgreich.

2006Chip crash- elmos™

1998 ColorScan (Hoechst Trevira)

Wir stellten unsere Entwicklungsarbeiten auf der Messe Ident Vision in Stuttgart aus. Unser Stand wurde von Mitarbeitern der Firma Hoechst Trevira in Bobingen besucht, die eine automatisierte Lösung zur Qualitätssicherung beim Spinnen dicker Synthetikfasern (Monofilamente) suchten.

Die Monofilamente hatten Durchmesser im mm- Bereich. Sie dienten zur Herstellung industrieller Siebe für die Papierherstellung. Gesponnen wurden sie, indem in einem Extruder das Rohmaterial in Form von Granulat solange erwärmt wurde, bis es zähflüssig war. Dann wurde die zähflüssige Masse durch 40 Spinndüsen gepresst, die austretenden Fäden verstreckt, gekühlt und schließlich aufgewickelt. Das ganze geschah in einem kontinuierlichen Prozess, wobei 40 Fasern von den Spindüsen quer durch eine große Werkhalle zu den Rollen geführt wurden.

Qualitätsmängel waren an leichten Farbschwankungen der Fasern während der Produktion erkennbar. Es wurde ein optisches System gesucht, welches jede der frei fliegenden, millimeterdicken Fasern erfasste, und auf einem kleinen Ausschnitt der Oberfläche den Farbton analysierte.

Wir entwarfen ein Messsystem, das die Mitarbeiter von Hoechst überzeugte, und erhielten schließlich den Entwicklungsauftrag.

Um die Oberflächen aller 40 Fasern für die Messung optisch ausreichend auflösen zu können, entwickelten wir eine spezielle, hohchauflösende CCD Farbzeilenkamera mit über 7000 Pixeln (3 Streifen a 7000 Pixeln rot, grün blau). Der CCD- Chip wurde als einzelnes Exemplar direkt aus Japan eingeflogen. Die komplette Kameraelektronik musste wir zu dem brandneuen Chip selbst entwickeln. Mit einem hochwertigen Leitz 6x6 Kameraobjektiv bildete wir die Fasern auf die ca. 7cm lange Zeile scharf ab. Das Kameragehäuse fertigten wir aus massiven, gefrästen und sandgestrahlten Aluplatten.

Auch bei der Beleuchtung musste Neuland betreten werden, denn die genauen Farbmessungen erforderten eine äußerst homogene und spektral stabile Beleuchtung. Wir entschieden uns für neu auf den Markt gekommene, ultradünne Leuchtstoffröhren, die extrem hell waren.

Kamera und Beleuchtung wurden durch einem Rahmen aus Systemprofilen fest miteinander verbunden.

Die Software für ColorScan entwicklete ich als OS/2 Anwendung komplett neu. Auf der graphischen Benutzeroberfläche wurden die von der CCD- Zeile in den Farbkanälen rot, grün, blau aufgenommenen Helligkeitsprofile als Livebilder dargestellt. Interaktiv konnte in diese hineingezoomt und pixelweise vermessen werden.

Die eigentliche Messung erfolgte jedoch vollautomatisch. Dazu detektierten speziell von mir entwickelte Bildverarbeitungsalgorithmen die einzelnen Fasern und ihre Mittelpunkte. Um diese herum wurden die Helligkeitswerte aller Pixel in einem frei definierbaren Radius gemittelt.

Die Mittelwerte der einzelnen RGB- Farbkanäle einer Faser wurden dann wiederum in einen wählbaren Farbraum wie HSV (Hue= Farbton, Saturation= Sättigung, Value= Helligkeit) umgerechnet. Farbton und Sättigung sind z.B. unabhängig von Helligkeitsschwankungen in der Beleuchtung, und wurden z.B. durch das Programm gegen die Grenzen voher definierter Toleranzbereiche geprüft.

GUI: OS/2 Workplace Shell
Business Layer: ca. 7125 Zeilen C++ Code

Hoechst teste den Prototypen umfassend und befand ihn schließlich als geeignet. Er wurde in den Prozess eingebaut. Damit Toleranzüberschreitungen nicht nur direkt am Messystem ablesbar waren, entwicklete ich im Auftrag von Hoechst noch eine Kommunikationsmodul, welches die aktuellen Messdaten und Alarme bei Toleranzüberschreitungen an einen Windows NT- Prozessleitrechner sendete.

1998-2000 Einlaufweg von Blechen in Tiefziehpressen messen (Ptr 1 Mercedes)

Im Jahre 1998 untersuchten wir für die Mercedes Benz AG die Möglichkeit, die Qualität lackierter Fahrzeugoberflächen als auch vorbehandelter Klebflächen mit unserem Farbmessystem trACS ColorScan zu überwachen. Zur genauen Ortung des Messortes in Verfahrrichtung nuzten wir unseren trACS OptoTacho.

Zunächst erfoderte die Geschindigkeitsmessung mit dem trACS OptoTacho Messmarken auf der lackierten Oberfläche. Diese Konfiguration war natürlich nicht praxistauglich. Ich entdeckte aber beim Arbeiten mit einem Positionierungslaser, daß die Speckle- Interferenzmuster, die im Laserlicht auf der lackierten Oberfläche entstanden, mitwanderten. Wir schraubten kurzerhand das Objektiv von der CCD- Zeilenkamera, und positionierten diese über den Laserspot. Nach beharrlicher experimenteller Detailarbeit konnten wir tatsächlich eine Konfiguration finden, in der die Speckle Interferenzmuster von unserem trACS OptoTacho für eine präzise Geschwindigkeitsmessung ausgewertet werden konnten.

Es zeigte sich, dass auch auf unlackierten, öligen und sogar spiegelnd verchromten Blechoberflächen (z.B. Staubsaugerrohr) genaue Geschwindigkeits- und Wegmessungen mit dieser neuen Konfiguration möglich waren. Das war eine Sensation ! Wir patentierten das Verfahren DE 196 50 177 A1, und publizierten das Ergebnis. Kurze Zeit später interessierte sich Herr Dr. Klamser und Herr Ramsperger von Mercedes Benz (Bereich Umformtechnik) für das Verfahren.

Ein altes Problem in der Umformtechnik ist die Messung des Einlaufweges. Wird ein Blech von einer Tiefziehpresse umgeformt, dann spannt man seine Seiten zunächst zwischen die Backen des Tiefziehrahmens und Niederhalters. Dann drückt der Stempel mittig das Blech in die Form. Dabei fließt das Blech von den Seiten durch die Backen des Tiefziehrahmens und Niederhalters. Den Weg, den die Außenkanten des Bleches dabei zurücklegen, nennt man Einlaufweg.

Das Diagramm in Bild 2 zeigt den empirisch ermittelten Zusammenhang zwischen der Qualität des Produktes, der benötigten Umformzeit und dem Einlaufweg. Der Einlaufweg ist während der Fertigung vieler Teile nie konstant. Die riesige Tiefziehpresse verteilt den Druck bei jedem Hub etwas anderes, der Ölfilm auf dem Blech ist nicht konstant und selbst die kristalline Mikrostruktur der Belchoberfläche variiert etwas innerhalb eines Coils. Die Gefahr von Riss- oder Faltenbildung in der Produktion besteht auch bei optimalen Einstellungen der Maschinen- und Werkzeugparameter. Durch automatisches Messen des Einlaufweges könnte die Erkennung von Gut/Schlechtteilen in der Produktion automatisiert werden.

Es gab bereits viele Versuche, den Einlaufweg zu messen (Induktiv, Laser-Triangulation auf der Blechkante). Allerdings waren diese Verfahren entweder zu ungenau, erfoderten zu große Bohrungen für die Sensorflächen oder hatten einen zu hohen apparativen Aufwand. Wir konnten mit unserem Messaufbau Herrn Dr. Klamser überzeugen, daß diese Einschränkungen für unsere Meßverfahren nicht bestanden, was sich auch in einer Patentanmeldung aus dem Jahre 1998 von ihm widerspiegelt (DE 19712664 A1 ). Er erteilte uns den Auftrag, einen Prototypen zu entwickeln.

Wir entwickelten einen Messkopf, und nannten ihn Presseneinlaufsensor Ptr1. Er fand Platz in einem kurzen Stahlrohr mit 2cm Durchmesser. Der Sensor beinhaltete auf einer mehrlagigen Platine Zeilenkamera und Laser mit Kollominator (Bild 3, 4). Die komplette Elektronik entwickelte mein Vater, Dr. B. Korneffel. Ich entwarf den mechanischen Aufbau mit dem CAD- Tool BlueCad, und passte die Software des OptoTacho an die Eigenheiten der Geschwindigkeitsmessung von Speckle- Mustern an. Die Mechanik wurde schließlich in den Werkstätten der Mercedes Benz AG nach unseren Entwürfen gefertigt.

Dr. Klamser organisierte im Stuttgarter Institut für Umformtechnik (IFU) einen Großversuch. Der Sensor wurde in ein Werkzeug, welches eine Blechwanne formte, eingebaut (Bild 6). In mehreren Meßreihen konnten wir die volle Funktion des Meßsystems unter den rauen Bedingungen im Presswerk nachweisen. Risse wurden messtechnisch erkannt. Im rohen Geschwindigkeitssignal offenbarten sie sich besonders charakteristisch, wie in Bild 7 zu sehen.

Die Versuche waren ein voller Erfolg. Eine Fortsetzung des Projektes unter Federführung von Dr. Klamser fand leider nicht mehr statt, da durch die gleichzteitig sich vollziehende Fusion von Mercedes Benz AG mit Chrysler es zu einer Neustrukturierung im Konzern kam. Innerhalb der Daimler Chrysler AG gab es keinen Raum mehr für diese Art von Entwicklungsarbeit.

2004 Ptr 2 (BMW)

Wir gaben das Projekt nicht auf. Nach einer langen Odyssey trafen wir schließlich auf Dr. Sebastian Rittmeier (BMW Ag). Im Rahmen seiner Doktor- Arbeit , bei der eine Regelung für den Anpressdruck im Ziehrahmen entwickelt werden sollte, suchte er nach einem geeigneten Presseneinlaufsensor. Wir konnten ihn von unserem System überzeugen.

Der neue, regelbare Tiefziehrahmen sollte in ein Werkzeug eingebaut werden, welches Radhäuser fertigte (Bild 7). An vier Messtellen waren Einlaufwege zu erfassen.

Die Messtellen waren sehr unzugänglich: Stahlrippen standen im Weg (Bild 8), zudem waren die Messflächen noch abgewinkelt. Über die genaue Richtung der Geschwindigkeit beim Einlaufen herrschte Unklarheit. Nach der Diskussion unzähliger Entwürfe entschloss ich mich, ein quaderförmiges Gehäuse für den Sensorkopf aus massiven Aluminiumplatten zu konstruieren (Bild 9). Um den enormen Belastungen während des Betriebes standzuhalten, wurde es mehrfach verschraubt und zusätzlich verstiftet. Im Gehäuse wurde die Elektronik an Stoßdämpfern aufgehangen.

Um den Sensor im Werkzeug in Geschwindigkeitsrichtung auszurichten, wurden die optisch aktiven Elemente in einem drehbaren Turm aus Messing eingebaut (Bild 10). Dieser konnte gegenüber dem Sensorgehäuse mit einem Servomotor verdreht werden. Die Ansteuerung des Servomotors erfolgte über die Bildschirmmaske unserer Bildverarbeitungssoftware. Vor der Messung wurde dann im Rahmen eines Justagelaufes über mehrere Pressenhübe der Turm schrittweises ferngesteuert in die optimale Richtung gedreht.

Die im Ptr 1 Prototypen eingesetzten IC's aus dem Jahre 1999 waren im Jahr 2004 nicht mehr verfügbar. So wurde eine komplette Neuentwicklung der Messkopfelektronik notwendig. Mein Vater, Dr. Burghard Korneffel, löste diese Aufgabe erfolgreich, und integrierte dabei auch gleich eine neue Ansteuerung für den Laser und den Servomotor. Eine weitere Innovation war der Datenaustausch mit dem Messrechner über 1 GBit Ehternet (mehr dazu unten).

Bild 11 zeigt die Messköpfe unmittelbar vor dem Einbau. Für jede Messtelle wurde von BMW eine Adapterplatte aus massiven Stahl angefertigt, die den Neigungswinkel der Messfläche gegenüber der Sensorebene ausglich.

In Bild 12 sind die Messköpfe im eingebauten Zustand zu sehen. Sie verschwinden vollständig im Werkzeug.

Bild 13 liefert einen Blick auf den Messplatz. Im Hintergrund die Tiefziehpresse mit eingebautem Werkzeug. Das Werkzeug ist mit vier Presseneinlaufsensoren Ptr 2 bestückt. Im Vordergrund der Schaltschrank mit vier Ptr 2 Messrechnern. Daneben der Schaltschrank mit der Steuer- und Regeltechnik für den mit Gasdruckfedern bestückten Ziehrahmen. Die Federn wirken auf einzelne Flächenelemente im Ziehrahmen. Ihre Rückstellkraft kann von der Steuer- und Regeltechnik verändert werden, wodurch der Materialfluss beim Umformvorgang beeinflusst wird. (siehe Dipl. -Witrschafts -Ing. Sebastian Rittmeier: Systemunterstütztes Umformen )

In Bild 14 ist die Rechentechnik im Detail zu sehen. Zu jedem Messkopf gab es einen Industrie- PC mit Intel Pentium 4, 3 GHz CPU, 1 GB Hauptspeicher und schneller SCSI HDD zum Verarbeiten und Auswerten der Messungen.

Für den Ptr 2 wurde die Software komplett neu entwickelt. Der Vorläufer Ptr 1 basierte noch auf den in OS/2 implementierten OptoTacho 3. Im Jahre 2004 war OS/2 jedoch reif für das Computermuseum: es hatte den Anschluss an die IP- basierte Netzwerkwelt verloren.

Den Messkopf des Ptr 1 verband ein maximal 3m langes, vieladriges Kabel mit dem Messrechner. Die Ansteuerung des Messkopfes erfolgte hier noch weitgehend analog.

Zwischen den vier geplanten Messköpfe im Ptr 2 und ihren Messrechnern mussten jedoch viel längeren Strecken überbrückt werden. Die Analogtechnik des Ptr 1 war damit überfordert. Die Lösung des Problems lieferte das Produkt IPort der kanadischen Firma Pleora, welche die Kamerasignale via 1 GBit Ethernet als TCP/IP Pakete in die Messrechner tunnelte. OS/2 Treiber für den IPort waren nicht verfügbar. Ich beschloss deshalb, die Software nach Windows XP zu portieren.

In meiner Tätigkeit als IT- Berater hatte ich bereits Erfahrungen mit dem Microsoft Visual Studio 2003 gesammelt. Die Programmierung grafischer Oberflächen in C# mit dem .NET Framework bedeutete gegenüber der OS/2 Welt einen großen Fortschritt. Auch die Ansteuerung von Datenbanken mit ADO.NET war nun ein Kinderspiel. Der Microsoft C++ Compiler als Bestandteil von Visual Studio war schließlich ausschlaggebend bei der Entscheidung für Visual Studio als neue Entwicklungsplattform.

Bei der Portierung entwickelte ich die grafische Benutzeroberfläche komplett neu in C# als Windows Forms- Anwendung. Die eigentliche Geschwindigkeitsberechnung, die bis dato durch eine hoch optimierten C++ Routine erfolgte, erfuhr ein umfassendes Refactoring, wobei die Testbarkeit des Codes im Mittelpunkt stand. An vielen Stellen wurden selbstentwickelte Bibliotheken für Standardaufgaben (z.B. Listenverarbeitung) durch C++ STL Bibliotheken ausgetauscht.

Die Mühen wurden belohnt: Die Ptr 2 Software war deutlich zuverlässiger und effizienter. Wir erreichten nun 10000 Geschwindigkeitsmessungen pro Sekunde im Echtzeitbetrieb, die Bedienung war einfacher, und die Möglichkeiten der Analyse laufender Messungen und Messdaten um viele sinnvolle Funktionen erweitert.

Es folgte eine Phase, in der viele Messungen mit dem System von Dr. Rittmeier im Rahmen der Untersuchungen zum geregelten Tiefziehen in den BMW- Werken in München und Dingolfing durchgeführt wurden. Dabei offenbarte sich das großes Potenzial des Verfahrens für den Gewinn neuer Einsichten in den Materialfluss beim Tiefziehen und seine Auswirkung auf die Qualität. Bild 16 zeigt z.B. das Geschwindigkeitsdiagramm des einlaufenden Tiefziehbleches, wobei die Geschwindigkeit starken Schwankungen unterliegt (Stick-Slip ). Die Auswirkung solcher aus Stick-Slip Effekten resultierenden Beschleunigungen und damit Kräfte wurde bis dato noch nicht untersucht, da ihre Existenz insbesondere in hochfrequenten Bereichen völlig unbekannt waren (siehe dazu Dipl. -Witrschafts -Ing. Sebastian Rittmeier: Systemunterstütztes Umformen). Die hohe, zeitliche Auflösung auch bei sehr kleinen Geschwindigkeiten durch das Messystem macht solche Effekte jetzt detailliert beobachtbar.

Entwicklung von Webanwendungen

In der trACS Optische Computersensorik betrieben wir prototypische Messsysteme bei Kunden. Eingriffe in Konfiguration während des Betriebs sind in der frühen Entwicklungsphase von Messsystemen eher die Regel als die Ausnahme. Sind die Bedingungen am Messort sehr rau, oder ist der Kunde räumlich weit entfernt, dann wünscht man sich schnell die Möglichkeit einer Fernsteuerung.

Bei der Entwicklung des Pressen Einlaufsensors Ptr entdeckte ich die ASP.NET Webanwendung als ideales Framework zur Implementierung einer solchen Fernsteuerung. Webanwendungen setzen auf weltweite Standards wie TCP/IP, http(s), HTML. Sie erfordern einen geöffneten Port 80 in der Firewall. Für eingehenden Verkehr ist dieser per Defaulteinstellung in der Regel offen. Den Kunden muß man letztlich nur von einer einzigen, allgemein bekannte Portweiterleitung überzeugen. Dank Verschlüsselung mittels integriertem https Protokoll ist keine zusätzliche Hardware für VPN Tunnel notwendig. Der administrative Aufwand für Webanwendungen ist tatsächlich minimal.

Ein weiteres Plus von Webanwendungen ist der Browser. Auch bei schlechten Verbindungen ist er sehr geduldig beim Laden einer Webseite. Und bei der Gestaltung von Webseiten kann ein Designer alle Register ziehen. Es lassen sich sehr intuitive Benutzeroberflächen aufbauen. Erleichternd kommt hinzu, das heute fast jeder in der Bedinung von Webbrowsern erfahren ist.

2005 WebForm für trAC OptoTacho

Meine erste ASP.NET Webanwendung schuf ich für den Pressen- Einlaufsensor Ptr2. Über die Weboberfläche konnte das Messsystem konfiguriert, Messungen ausgeführt und Messdaten anschließend analysiert werden.

2007 Zertifizierungstool für Porsche AG

Datenbank: 26 Tabellen, MS SQL Server 2005 Express
Data Layer: 60 TSQL Stored Procedures
Business Logic: 8016 Zeilen C# Code
GUI: 40 ASP.NET WebForms
Framework: .NET 2.0, Visual Studio 2005/8

Im Frühsommer 2007 erhielt ich den Auftrag, den Prototypen eines Werkzeuges zur Unterstützung des Zertifizierungsprozesses von CAD Workstations bei der Porsche AG Weissach zu implementieren. Das Werkzeug sollte die Softwareinstallationen auf den Computern abbilden und die für die Zertifizierung notwendige Testse verwalten. Zudem beinhaltete es ein Ticketsystem, über das Mitarbeiter Probleme beim Betrieb der Arbeitsstationen melden und dokumentieren konnten.

Ich entwickelte das System zusammen mit einem erfahrenen Webdesigner. Wir mussten Editoren für frei definierbare Test- Workflows (genannt Testszenarien) implementieren, welche aus einer Folge von Testschritten bestanden. Zu jedem Testschritt können Dateianhänge angelegt werden.

Für die Durchführung der Tests rufen die Mitarbeiter alle auszuführenden Testschritte in der WebForm Testprozess ab. Zu jedem Testschritt können Testdaten heruntergeladen werden. Der Tester dokumentiert das Ergebnis durch klicken auf einen der drei Zustandsbuttons OK, Workaround und Fehler.

2010Godel Beton Laborprogramm

Datenbank: 94 Tabellen, MS SQL Server 2008 Professional
Data Layer: 11 SQL To Linq Datenbank- Contexte
Business Logic: 34393 Zeilen C# Code
GUI: 81 ASP.NET WebForms
Framework: .NET 4.0, Visual Studio 2010

Die Firma Godel Beton produziert Beton für viele Großbaustellen im Land. Bei der notwendige Überwachung der Produktqualität im firmeneigenen Labor fällt eine erhebliche Menge an auszuwertenden Messdaten an (Druckfestigkeiten von Betonproben, Sieblinien etc.). Die Erfassung und Auswertung der Messdaten erfolgte in MS- Excel.

Bedingt durch das massive Wachstum der Firma und dem damit einhergehenden steigenden Volumen an Messdaten stieß die "Excel- Lösung" an ihre Grenzen. Die am Markt gebotenen Lösungen genügten nicht den Anforderungen wie:

Mehrbenutzerbetrieb
Zugriff von mehreren Standorten aus über getunneltes Intranet oder aus dem Internet
Auslegung für bis 20 Werke und 20000 Proben im Jahr
Implementierung spezieller Analysen

So entschloss man sich im Jahr 2009, ein eigenes Laborprogamm zu entwickeln. Mit den Entwicklungsarbeiten wurde ich beauftragt.

Ich wählte die Architektur der Webanwendung und als Framework ASP.NET Webforms. Insbesondere folgende Merkmale von ASP.NET Webanwendungen förderten den Erfolg des Projektes:

Weiterentwicklung im laufenden Betrieb auf einem zentralen Webserver (agile Softwareentwicklung)
Unterstützung bei der Implementierung komplexer, editierbarer Tabellen durch asp:GridView Controls und ViewState
Unterstützung bei der Implementierung von Workflows durch ASP.NET SessionState, HTML- Hyperlinks
Unterstützung bei der Gestaltung der Benutzeroberflächen durch sog. MasterPages
Vereinfachte Fernwartung durch standardisierten verschlüsselten Zugriff mittels https aus dem Internet. Dies vereinfachte auch den Zugriff von Filialen des Labors auf das in der Zentrale gehostete Laborprogramm

Zusammen mit den Mitarbeitern der Firma analysierten wir die bestehende Excel- Lösung. Ich modellierte die Daten dabei direkt im Datenbankdiagramm von MS Sql Server Managment Studio 2008. Es entstand ein Datenmodel mit 94 Tabellen.

Den Data Access Layer implementierte ich erstmals anstelle Stored Procedures mit dem objektrelationalen Mapper SQL To Linq von Microsoft. Zusammen mit dem, seit .NET 3.5 in C# implementierten LINQ (Language INtegrated Query) gelingt der Datenbankzugriff dierekt aus der Programmiersprache. Viel Code, der üblicherweise zum Aufbau und Senden der SQL Datenbankbefehle mit den klassischen Bibliotheken zu programmieren ist, konnte eingespart werden, da diesen LINQ auf dem SQL To Linq ORM komplett kapselt.

public override IQueryable filterImpl(IQueryable srcTab)
{
   bool geprüft = RValue == 1 ? true : false;
   return srcTab.Where(r => r.prüflast_in_KN.HasValue == geprüft);
}

2015 Gesteinskörnung Statistiktool

GUI: 5 RAZOR Views
Business Logic: 1978 Zeilen C# Code
Data Layer: Entity Framework Modell über 15 Tabellen

Webbasiertes Tool zur statistischen Auswertung der Sieblinien von Gesteinskörnungs- Proben im Labor eines Betonwerkes. Das Tool wurde mittels ASP.NET MVC, Entity Framework 5 und MS SQL Server implementiert.

Mit dem Tool kann ein neuer Bericht in mehreren Schritten erstellt werden (Workflow). Mittels ASP.NET MVC Pattern gelang die Abbildung des Workflows hervorragend. Für die einzelnen Schritte (Sorte wählen, Betrachtunszeitraum definieren etc.) wurden einzelne Views angelegt, welche die Zustände im Workflow der Berichtserstellung repräsentieren. Mit den serverseitigen Actions der Controller erfolgte die Implementierung der Zuständsübergänge. Die letztendlich konfigurierte statistische Analyse erfolgt asynchron auf dem Server. Auch hier konnte dank dem MVC- Pattern ein klar strukturierte Prozessfortschrittsanzeige implementiert werden, durch welche die laufende Analyse auf dem Server intuitiv steuerbar ist (Bild 2).