Eine Auswahl interessanter Referenz-Projekte

Aufgabenstellung

Ein HFA-System (Hands Free Access) ist eine Vorrichtung zum freihändigen Öffnen eines Automobil-Kofferraum-Deckels bzw. einer Heckklappe. Es besteht aus einem Sensor-System, das spezifische Fußbewegungen im unteren Heckbereich erkennt und daraufhin den Kofferraum öffnet. Zuvor prüft das Zugangssystem des Fahrzeugs des Vorhandenseins eines gültigen Schlüssels im Heckbereich, der sich typischerweise in einer Jacken- oder Handtasche der involvierten Person befindet (Keyless Entry).

Das HFA-System soll für den universellen Einsatz an verschiedenen Fahrzeugen unterschiedlicher Hersteller mit geringen Anpassungen tauglich sein.

Aufgrund der permanenten Bereitschaft des Systems bei Stillstand des Fahrzeugs muss es mit einem extrem geringen Stromverbrauch auskommen. Außerdem muss eine hohe Sicherheit gegen Fehlauslösungen durch unspezifische Bewegungen oder elektromagnetischen Störungen gewährleistet sein.

Ausführung

Unser Ingenieurbüro unterstützte über einen Zeitraum von rund 8 Jahren ein großes Team an Ingenieuren bei unserem Kunden. Unsere Aufgaben waren im Wesentlichen die Entwicklung der Software und Anpassung an verschiedene Fahrzeuge sowie die Begleitung durch die verschiedenen Entwicklungsstufen und umfangreiche Testreihen.

Ein wesentlicher Teil der Arbeiten bestand darin, das System an verschiedene Fahrzeuge unterschiedlicher Hersteller anzupassen. Verschiedene Kommunikations-Schnittstellen (LIN, CAN, Open Collector etc.) kamen zum Einsatz. Dabei mussten unterschiedlichste Signal-Layouts berücksichtigt werden.

Auch der Stromverbrauch spielt eine entscheidende Rolle, sofern die jeweilige Komponente auch während des Stillstands des Fahrzeugs betriebsbereit sein muss. Da dies auf immer mehr Komponenten zutrifft, werden die Fahrzeughersteller hier immer restriktiver. So darf z.B. ein HFA-System im Standby-Betrieb nicht mehr als 0,1 Milliampere verbrauchen, muss aber bzgl. der Bewegungserkennung die volle Leistung erbringen.

Außerdem mussten die unterschiedlichsten Anforderungen einzelner Länder bezüglich Stör-Emission und –Immission berücksichtigt werden.

Fazit:

Die Automobil-Branche bietet sehr spezielle Herausforderungen. Aufgrund der großen Stückzahlen besteht auf der einen Seite ein sehr hoher Anspruch an Qualität und Zuverlässigkeit der Komponenten. Auf der anderen Seite besteht ein großer Preisdruck, da kleinste Einsparungen an einer Komponente sehr hohe Auswirkungen auf die Gesamtkalkulation haben.

Da die Kosten der Software-Entwicklung sich nur umlagebedingt auf die Kosten auswirken, entstehen in diesem Bereich extreme Anforderungen. Dadurch entsteht ein permanenter Optimierungsbedarf, der hohe Anforderungen an die beteiligten Ingenieure stellt.

So entsteht ein Spannungsfeld aus Produktionskosten, Performance, Störfestigkeit und Stromverbrauch.

Trotz aller Widrigkeiten ist dieses HFA-System ein großer Erfolg und wird aktuell weltweit in zahlreichen PKW-Modellen eingesetzt.

Aufgabenstellung

Die Angebotspalette des Kunden umfasst Audioverstärker, Lautsprecher und Equalizer. Diese kommen für professionelle Beschallungsaufgaben zum Einsatz.

Die Aufgabe bestand in der Entwicklung einer PC-Applikation zur Überwachung, Steuerung und Konfiguration der Komponenten. Die Applikation hat die Aufgabe, Daten für verschiedene System-Konfigurationen bereit zu stellen.

Dem Administrator sollte die Möglichkeit zur Verfügung gestellt werden, Alle Parameter wie z.B. Lautstärke, Muting, Clipping etc. live zu beeinflussen.

Ein besonderes Augenmerk wurde auf die Konfiguration der Equalizer gelegt. Hierzu werden Filter-Kennlinien graphisch dargestellt. Diese können per Maus im Graphikfenster verändert und die akustische Auswirkung sofort wahrgenommen werden.

Alle Komponenten der Anlage werden als fotoreales Abbild auf dem Bildschirm dargestellt und die Stellelemente können direkt in der Graphik bedient werden.

Alle graphischen Elemente der Anlagenkomponenten sowie die Bedienelemente und ihre Eigenschaften sollen in einer Datenbank abgelegt werden. Damit soll es möglich sein, neue Komponenten ohne Änderung der Software-Applikation hinzuzufügen und deren Definition und Integration in das Gesamtsystem ohne Programmierkenntnisse durchzuführen.

Ausführung

Die Entwicklung erfolgte unter Visual-Studio von Microsoft. Als Programmiersprache kam C++ mit der MFC-Library zum Einsatz.

Als Datenbank wurde Microsoft-Access verwendet.

Die Datenbank wurde auf mehrere DB-Dateien aufgeteilt, um eine Trennung zwischen der statischen Konfiguration der Komponenten und der kundenspezifischen Konfiguration der Anlage zu ermöglichen. Damit konnten Aktualisierungen der Produktpalette durchgeführt werden, ohne die Kunden-Konfiguration zu beeinträchtigen.

Die Ausführung der Applikation wurde modular gestaltet. Dabei wurde Wert darauf gelegt, dass die Kommunikations-Schnittstellen mit den zu steuernden Audio-Komponenten austauschbar sind.

Zu Beginn des Projekts gab es nur ein proprietäres Bus-System zur Ansteuerung der Geräte. Dazu gab es Gateways, die eine Verbindung mit dem PC über Ethernet (TCP-UDP/IP) ermöglichten.

Später kamen Komponenten hinzu, die direkt über TCP/IP angesteuert wurden.

Das Graphik-Modul für die Equalizer wurde von uns speziell für diese Anwendung entwickelt, da keine geeignete Komponente von Drittanbieters gefunden wurde.

Fazit:

Der erste Prototyp der Applikation konnte schon 6 Wochen nach Start der Entwicklung geliefert werden. Die erste Version für einen Endkunden konnte nach ca. einem halben Jahr geliefert werden.

Eine besondere Herausforderung während der gesamten Entwicklung war die Kommunikation mit den externen Komponenten, da diese anfangs im Gesamtverbund nicht immer stabil funktionierten.

Die Applikation hat sich im Laufe der Lebenszeit von fast 10 Jahren sehr stark verändert. Dies war auf die hohe Innovations-Geschwindigkeit in der Branche zurückzuführen.

Nach knapp 10 Jahren entschied sich der Kunde für eine Neu-Entwicklung, um den modernen Anforderungen gerecht werden zu können. Dazu gehörten u.a. die Verfügbarkeit auf unterschiedlichen Betriebssystemen und eine moderne Benutzeroberfläche.

Aufgabenstellung

Ziel war die Entwicklung der Firmware für einen Automobil-Funkschlüssel mit Keyless-Go und Keyless-Entry Funktion.

Zum Einsatz kamen drei verschiedene Funktechnologien:

• HF-Transceiver bidirektional
• LF-Field data transfer unidirektional
• LF-Transponder bidirektional

Neben der Basisfunktion, dem Ver- und Entriegeln der Türen über Funk, stellt der Schlüssel Ortungsfunktionen im Nahbereich für die Betriebsarten Keyless-Entry und Keyless-Go zur Verfügung. Außerdem kann der Schlüssel fahrerspezifische Daten wie z.B. Spiegel- und Sitz-Einstellungen speichern, sowie Daten für die Wartungsarbeiten in der Werkstatt.

Die besonderen Anforderungen bestehen darin, dass der Schlüssel mit einer Knopfzellen-Batterie über 6 Jahre betriebsbereit sein muss. Dies hat zur Folge, dass der eingesetzte Prozessor extrem stromsparend sein muss und daher mit minimalen Ressourcen, wie z.B. Speicher und Rechenfunktionen auskommen muss.

Ausführung

Auftraggeber war ein großer Automobil-Zulieferer in Deutschland, der seine Komponenten für den globalen Markt produziert.

Unsere Aufgabe bestand in der Entwicklung der Firmware in Zusammenarbeit mit einem Kernteam des Kunden. Dabei waren wir für das Software-Design und die Entwicklung des überwiegenden Teils der Funktionen verantwortlich.

Aufgrund der o.g. Anforderungen bzgl. Speichergröße und Stromverbrauch wurde die Programmierung in Assembler durchgeführt.

Um unter diesen Bedingungen ein Software-Design nach den strengen Richtlinien der Automobilbranche zu gewährleisten, mussten umfangreiche Kodier Richtlinien für den speziellen Assembler dieses Prozessors erstellt werden. Diese wurden während der gesamten Entwicklungszeit immer wieder durch Review der Software überprüft.

Um die nicht trivialen mathematischen Funktionen, die ein vectorbasiertes Ortungssystem erfordert, auf diesem kleinen Prozessor zu realisieren, musste ein spezielles Fließkommazahlen-Format entwickelt werden. Dazu dann auch die passende Library mit den grundlegenden mathematischen Funktionen.

Fazit:

Dank der außerordentlich guten Vorbereitung und der Erstellung und Überwachung der speziellen Kodier Richtlinien entstand ein qualitativ hochwertiges Produkt, dass mit relativ geringem Aufwand zur Serienreife gebracht wurde.

Aufgabenstellung

Das Ziel war die Entwicklung eines Moduls für die Konfiguration und Überwachung von Heizungssystemen. Moderne Heizungsanlagen bestehen aus mehreren Komponenten, wie z.B. Brenner, Kessel, Pumpen und Regler. Diese sind teilweise an verschiedenen Orten montiert und über ein Bus-System miteinander verbunden.

Das Fernwartungsmodul wird ebenfalls an dieses Bus-System angeschlossen und soll die Möglichkeit bieten, aus der Ferne Kontakt zu allen Komponenten des Systems aufzunehmen.

Außerdem soll es Störungen im System erkennen und dann von sich aus Kontakt mit einer Zentrale aufzunehmen, um eine zeitnahe Behebung der Störung zu gewährleisten.

Unsere Aufgabe bestand in der Entwicklung der Software für dieses Modul.

Ausführung

Zum Einsatz kam der 32-Bit-Mikroprozessor V850 des Herstellers NEC (heute Renesas). Als Betriebssystem wurde ein Echtzeit-Kernel (RTOS) eines Drittanbieters eingesetzt. Als Programmiersprache kam C zum Einsatz.

Die Architektur und das Design der Software wurden vor Beginn der Kodierung komplett in UML modelliert.

Für die Fernanbindung wurde ein GSM-Modul eines Drittanbieters verwendet.

Fazit:

Die Entwicklung lief weitgehend problemlos und das Projekt wurde termingerecht fertig gestellt.

Aufgabenstellung

Erneuerung und ggf. Ablösung der Telex-Gateway Anlage, die drei Arbeitsplätze verband und an ihre Kapazitätsgrenze gestoßen war. Eine den gefordeten Bedingungen gewachsene Lösung wurde gesucht.

Ausführung

1991:

Zum Einsatz kam eine Datenbanklösung auf Basis von Progress. Der Daten­bankserver war eine UNIX-Maschine auf PC-Basis. Zu Beginn wurden 6 Arbeitsplätze mit einer Diskless -Workstation auf PC-Basis vernetzt, die über Telnet auf die Host-basierte Datenbankanwendung zugriffen. Der Datenbankserver enthielt eine Faxkarte, über die standardisierte Briefe an die Kunden versandt werden konnten, außerdem wurde das  vorhandene Telex-Gateway integriert.

Der Server enthielt außerdem zwei Modems für Fernwartung und Tele-Arbeits­plätze.

Die Anwendung umfasste zunächst eine Adressdaten-Verwaltung und ein System zur Versendung von Mailings. Im Laufe der nächsten Jahre wurde das System sukzessiv um eine Auftragsverwaltung mit Faktura und Buchhaltungsschnitt­stelle erweitert.

1995:

Umstellung der Anwendung auf eine GUI-basierte Client-Server Anwendung. Der Server wurde im Laufe der Zeit immer wieder hardwaremäßig aufgerüstet, blieb aber in seiner Grundkonzeption zunächst bestehen. Die Workstations wurden jedoch durch Windows-PCs ersetzt.

2000:

Grundlegende Umstrukturierung des Datenbankservers. Nach umfang­reichen Tests mit modernen und leistungsfähigen Servermaschinen auf PC-Basis (RAID 5 und Doppelprozessor) wurde entschieden, das System auf Windows-NT umzustellen, da die Performance deutlich besser war, als mit LINUX (obwohl dies kaum jemand glauben wollte).

Fazit:

Das System hat sich im 12 jährigen Einsatz bewährt, wobei die Hardware immer wieder aufgerüstet bzw. getauscht wurde. Durch die Erweiterung der Software wurde das System kontinuierlich den aktuellen Erfordernissen angepasst, so dass es zu einem Paket mit über 150 Programmmodulen angewachsen ist.

Progress hat sich als Datenbank-System hervorragend bewährt. Es hat in diesen 12 Jahren niemals einen Datenbank-Crash gegeben, der auf die Software zurückzuführen war. Aufgrund von Serverproblemen gab es in dieser Zeit zwar einige ernsthafte Ausfälle, jedoch niemals Datenverluste (d.h. ein Backup-Restore wurde nie benötigt).

Aufgabenstellung

Bei Anlieferung von Waren soll direkt an der Rampe festgestellt werden, ob die gelieferte Ware bestellt wurde und ob sie vollständig und ordnungsgemäß geliefert wird.

Zu diesem Zweck soll dort jeder Mitarbeiter über ein mobiles Datenerfassungs-Terminal verfügen, dass über Wireless-LAN direkt auf die zentrale Datenbank zugreifen kann um so die Ware zu kontrollieren und zu erfassen.

Der von IBC übernommene Teil der Aufgabe war die Programmierung der Erfassungs-Terminals.

Ausführung

Zum Einsatz kamen moderne Datenerfassungs-Terminals des Herstellers Symbol auf Basis von Windows CE (Pocket PC) mit integriertem Barcode-Scanner und Wireless-LAN Einheit.

Die Programmierung erfolgte mittels MFC in C++. Die Datenbankanbindung erfolgte über eine proprietäre Middle-Ware Lösung des beauftragten System­hauses.

Neben diversen anderen Funktionen gab es für die Erfassung eine zentrale Maske mit mehreren Feldern, über die verschiedene Nummer erfasst werden konnten, z.B. Hersteller-Artikelnummer, NVE (Palettenkennung) oder die Wareneingangs-Nummer. Diese sind hierarchisch gegliedert, so dass bei einem normalen Ablauf zuerst die Wareneingangsnummer der Lieferung, dann die NVE einer Palette, und dann die Artikel auf dieser Palette der Reihe nach erfasst werden.

Die Besonderheit dieser Lösung bestand nun darin, dass ein Mitarbeiter jederzeit eine beliebige Art von Nummer erfassen konnte. Das Programm musste dann anhand des Barcode-Typs erkennen, um welche Hierarchie-Ebene es sich handelt. Dann musste der Erfassungsablauf entsprechend gesteuert werden.

Beispiel: Zu Beginn einer Erfassung erwartet das System die Wareneingangs-Nummer. Der Mitarbeiter scannt jedoch eine Artikelnummer. Das Programm erkennt dies und ermittelt aufgrund der Artikelnummer in der Datenbank die zugehörige Palette und über diese die Wareneingangsnummer. Sollte der Artikel in mehreren Wareneingängen oder auch auf mehreren Paletten vertreten sein, bekommt der Mitarbeiter eine Auswahlliste.

Fazit:

Das Programm hat sich aufgrund der Tatsache, dass die Nutzer sich nicht an die hierarchischen Abläufe halten müssen, sehr umfangreich und stark verästelt entwickelt. Die Konzeptphase, Realisierung und Test sind deutlich aufwendiger geworden, als ursprünglich abgeschätzt. Letztendlich ist es aber doch nach akzeptabler Zeit zum Einsatz gekommen und arbeitet problemlos.

Aufgabenstellung

Ablösung einer TK-Anlage der Telekom, die ca. 8 Jahre alt war und die geforderten Aufgaben nicht mehr erfüllte.

Hauptproblempunkt war, dass die Unternehmensgruppe aus mehreren nach außen unabhängig erscheinenden Firmen bestand, die aber ein und den selben Mitarbeiter­stamm besaßen. Die Lösung mit der bestehenden Anlage bestand darin, jedem Mitarbeiter für jede der drei Firmen für die er arbeitete jeweils ein separates Telefon auf den Schreibtisch zu stellen. Da die Gruppe weitere Firmen integrieren wollte, war die Lösung unpraktikabel und bis dahin auch schon technisch und wirtschaftlich sehr aufwendig.

Zur Größenordnung: Die Anlage umfasste ca. 50 Nebenstellen mit ca. 40 Amtsleitungen.

Die neue Lösung sollte sich nicht nur wirtschaftlich rechnen, sondern auch Wünsche der Mitarbeiter bezüglich der Signalisierung und Displayanzeige von Anrufen erfüllen.

Ausführung

Nach umfangreicher Konzeptarbeit kam eine Ericsson Businessphone 250 Anlage zum Einsatz, die durch komplexe Programmierung und Ausschöpfung aller Möglich­keiten die Anforderungen des Auftraggebers erfüllte.

Durch eine sehr ausgefeilte Planung und umfangreiche Tests im Vorfeld wurde es möglich, die Installation der Anlage und der gesamten Verkabelung an einem Wochenende durchzuführen, so dass keine Beeinträchtigung des Betriebs durch die Umstellung erfolgte.

Nach erfolgreicher Einführung des neuen Systems wurde dann sehr bald eine CTI-Anbindung an die vorhandene Datenbank realisiert, um die Handhabung der Anlage für die Mitarbeiter noch bequemer zu machen. Die Anwender konnten damit z.B. aus Ihrer Kundenmaske auf Knopfdruck die Nummer des Kunden wählen.

Zudem bot das neue System die Möglichkeit einer Auswertung des Telefonierverhaltens und die Daten konnten allen Mitarbeitern direkt am PC als grafische Auswertung zur Verfügung gestellt weden.

Fazit:

Die Akzeptanz der neuen Anlage war hervorragend, die meisten Mitarbeiter haben das System schon am ersten Tag als Erleichterung Ihrer Arbeit empfunden. Die Flexibilität und Zuverlässigkeit der Anlage hat auch in den nachfolgenden Jahren immer wieder überzeugt.

Die Telefon-Statistik wurde von den meisten Mitarbeitern gerne genutzt und als wertvolle Information, und keinesfalls als Überwachung betrachtet.

Aufgabenstellung

Gewünscht war die Integration von Telefax- und Voice-Mail Diensten in ein Groupware-System (MS -Exchange und Outlook). Der Benutzer sollte eine persönliche Faxnummer erhalten. Seine eingehenden Faxe, sowie Sprachnachrichten der Mailbox seines Telefons sollten dabei wie eine E -Mail in seinem Posteingangs-Ordner erscheinen.

Ausführung

Ausgangssituation war die Nutzung eines MS-Exchange Server und Outlook-Clients Systems ausschließlich zur Verarbeitung von E-Mails.

Um die gewünschte Funktionalität zu erreichen wurde als ISDN-Anbindung eine PCI-Karte mit 2 S0 (4 Sprachkanäle) verwendet, die über eine Softwarelösung von Envox in das vorhandene System eingebunden wurde. Envox ist ein System zur freien Programmierung von UMS-Lösungen mit einer graphischen Oberfläche. Es ist sehr vielfältig und unterstützt alle gängigen Kommunikations -Schnittstellen, wie z.B. SMTP, DLL, ODBC, TCP/IP.

Die ISDN-Karte wurde als Nebenstelle in die TK-Anlage integriert. Die TK-Anlage wurde so programmiert, dass alle Durchwahlnummern, die mit 7 oder 9 begannen, auf die ISDN-Karte umgeleitet wurden. Damit bestand die Möglichkeit, jeder Nebenstelle eine eigene Fax und Voice -Mail Nummer zu vergeben.

Jeder Mitarbeiter hatte folglich eine eigene Fax- und Voice-Mail Nummer, auf der man ihn erreichen konnte.

Da der Mitarbeiter die Mailbox-Funktionen an seinem Telefon steuern wollte, so dass die Anrufe z.B. bei Abwesenheit oder besetzt auf die Mailbox laufen, wurde hier erst einmal die Mailbox -Funktionalität der Telefonanlage verwendet. Anlagenintern wurde jedoch die Mailbox auf die entsprechende Nummer umgeleitet, so dass diese Anrufe über die ISDN-Karte verfügbar waren.

Die Envox-Software wurde so programmiert, dass eingehende Anrufe aufgrund Ihrer Zielrufnummer dem entsprechenden Mitarbeiter zugeordnet werden konnten. Die Faxe oder Voice-Mails wurden zunächst als Dateien auf dem Server abgelegt. Ein weiterer Thread verarbeitete die Dateien so, dass diese je nach Wunsch der Zielperson entweder über SMTP als E-Mail empfangen, oder aber bei Faxen wahlweise auch auf einem Drucker seiner Wahl ausgegeben werden konnten.

Fazit:

Die Konzeption des Systems hat sich hervorragend bewährt. Aufgrund der vier verfügbaren Kanäle gab es im Vergleich zur Ausgangssituation (6 verschiedene Faxgeräte mit je einer festen Nummer) keine Kapazitätsprobleme mehr . Die Mitarbeiter schätzten es sehr, die Faxe direkt an Ihren Platz zu bekommen, anstatt in einem zentralen Postfach danach wühlen zu müssen und es wurde sehr einfach einen Fax an einen Kollegen weiterzuleiten. Die Zufriedenheit mit dem Gesamsystem litt nicht darunter, dass die Envox-Software sich als nicht besonders zuverlässig erwies (bei ca. 200 Faxen pro Tag konnte es zu mehreren Abstürzen pro Woche kommen), da dies durch entsprechende Programmierung des Gesamtsystems abgefangen werden konnte.

Aufgabenstellung

Gefordert war die Erfassung von Daten über eine serielle LWL-Ankopplung mit einer 64-Bit PCI -Karte. Die Datenübertragungsrate sollte mind. 400 Mbyte / sec. betragen, was sich schon im Grenzbereich des 64-Bit PCI-Busses bewegt.

Die Aufgabe von IBC bestand darin, einen Treiber für diese Karte unter Windows-NT zu schreiben. Es war klar, dass diese Datenmenge nicht in Echtzeit von irgendeiner Anwendung verarbeitet werden konnte, daher beschränkte sich die Anforderung auf einen Burst-Fall, in dem ein vorhandener Puffer mit der geforderten Geschwindig­keit beschrieben werden sollte.

Ausführung

Der Treiber musste so ausgelegt werden, dass die Daten nicht, wie üblich, zwischen Kernel-Buffer und User-Buffer hin und her kopiert, sondern direkt per Busmaster-DMA in den Userbuffer übertragen werden.

Der Puffer musste also gelockt werden, so dass er außerhalb der virtuellen Speicher­verwaltung permanent im RAM verfügbar war. Ein weiteres Problem war, dass der Pufferspeicher aufgrund des virtuellen Speicherkonzepts moderner Betriebssysteme nicht linear im physikalischen Speicher liegt sondern aus vielen verstreuten Segmenten besteht. Bei DMA-Transfer kommt dies zum Tragen, da hier keine MMU-Unterstützung existiert. Der DMA-Controller muss also mit einer Segment-Liste des Puffers versorgt werden.

Fazit

Alle Anforderungen wurden erfüllt. Eine Erfassungskarte für dieses Projekt wurde neu entwickelt und das Gesamtprojekt termingerecht abgewickelt.

Aufgabenstellung

Der Endkunde plante ein Redesign der Elektronik zur Steuerung seiner Industrie-Waagen. Die bisherige Steuerung war rein analog und sollte jetzt durch eine Mikro­prozessorlösung ersetzt werden.

Der Auftrag zur Entwicklung und Fertigung der Hardware und Software ging an ein Systemhaus im Raum Aachen, die Software-Entwicklung wurde im Unterauftrag von IBC ausgeführt.

Die besondere Anforderung lag darin, dass die Waage mit der gesetzlich geforderten Genauigkeit Waren auf einem sich bewegenden Förderband wiegen sollte. Dazu war die Nutzung von speziellen Regel- und Filter­algorithmen notwendig. Das Know-How dazu wurde vom Auftraggeber geliefert.

In der Planungsphase war noch unklar, ob das neue digitale System besser oder zumindest genauso gut wie das alte analoge System funktionieren kann.

Ausführung

Die neu entwickelte Platine enthielt einen Mikrocontroller Typ C166 zur Steuerung und einen Signalprozessor Typ C40 von Texas Instruments für die Berechnung der Filteroperationen.

Um die Weitergabe der gewonnen Daten zu ermöglichen, war der Steuerungsprozessor mit einem CAN -Bus Interface ausgestattet.

Die Waage musste verschiedene Betriebsarten unterstützen. Die gesetzlichen Auflagen mussten genau beachtet werden, da eine Abnahme des Systems vom PTB erforderlich war.

Fazit:

Die Parametrierung der Filter stellte eine hohe Herausforderug dar. Es waren einige Modifikationen der Filteralgorithmen erforderlich, bevor das System alle Erwartungen erfülen konnte.

Aufgabenstellung

Es sollte ein System zur Erfassung von Schwingungsmessungen an Turbinen­schaufeln z.B. für Generatoren im Kraftwerksbereich entwickelt werden. Das grundlegende Konzept und das Know-How wurde von RWE und ABB geliefert, die gleichzeitig Auftraggeber waren.

Für die Datenerfassung sollten zwei bis vier optische oder magnetische Sensoren eingesetzt werden, die den Lauf der Schaufelspitzen verfolgen. Die Schwingungen sollten dann über eine Fourier-Transformation (FFT) nachgewiesen werden.

Ausführung

Die Realisierung wurde in einem Team von 3 Personen durchgeführt, wobei die Software -Entwicklung wie auch die Konzepte für die Entwicklung von Hardware der IBC Geschäftsführer Peter Clemens persönlich übernommen hat.

Die Hardware bestand aus einer selbstentwickelten Zählerkarte, die über 5 Kanäle mit je 30 MHz Taktfrequenz die Zeitmessung der Schaufelimpulse durch­führte. Die Datenverarbeitung erfolgte auf einer zugekauften DSP-Karte, die als Einsteckkarte für den PC ausgeführt war. Zusätzlich wurde eine Erfassungskarte für analoge Messgrößen entwickelt, die der Korrelation der Schwingungsdaten mit diversen Betriebsgrößen diente.

Das Erfassungssystem war eine UNIX-Maschine auf PC-Basis. Die Kommunikation mit der DSP-Karte erfolgte über einen selbstentwickelten Treiber.

Die Datenerfassung war so ausgelegt, dass der Signalprozessor eine Vor­ver­ar­beitung der Daten durchführte und diese dann über den Treiber auf der UNIX-Maschine zur Verfügung stellte. Dort konnte ein Anwendungsprogramm die Daten Online darstellen und / oder auf Datei ablegen.

Da die Auswertung über FFT aus Performancegründen online nicht möglich war, erfolgte diese durch Zurückladen der Daten auf die DSP-Karte um dort von einem anderen Programmteil bearbeitet zu werden.

Die Roh- und Spektraldaten konnten über verschieden grafische Tools visualisiert werden.

Fazit:

Die Entwicklung der Software lief zügig und problemlos ab, die Hardware-Entwicklung stellte zu Beginn einige konzeptionelle Probleme, da zu dieser Zeit die Entwicklung schneller Zähler nicht ganz trivial war. Die dann gefundene Lösung lief dann aber stabil und problemlos.

Die Tests gestalteten sich schwierig, da die Sensoren unerwartete Probleme machten. Diese wurden aber dann weitgehend gelöst und das System über vier Jahre lang erfolgreich eingesetzt.