Messgerätesoftware für elektromagnetische Spektumanalyse

Überblick:

Eine Messgerätenfamlie von ist durch die wachsende Komplexität der Anforderungen an Ihre Grenzen gestossen und wird von einer neuen abgelöst. Für die neue Gerätefamilie wurde eine neue Architektur und ein neues Bedienkonzept entwickelt, die diese anwachsende Komplexität systematisch bewältigen kann und dem Benutzer eine übersichtlichere Bedienung und vielfältigere Anzeigen der Ergebnisse (Traces) ermöglicht.

Diese Produktfamilie wird hat wird an für die unterschiedlichen Zielgruppen vielfätige Anwendungen. Analyse von Handystandards, Analyse von Netzwerkstandards, Elektromagnetische Verträglichkeitsprüfung, Vektorsignalanalyse etc. Mit der steigenden Anzahl der Anwendungen erfordert nach außen hin ein gut organisiertes Userinterface und intern eine sehr gut strukturierte Organisation der über 10.000 Parameter.

Projektbeschreibung:

Datenbank: Entwicklung einer komplexen objektorientierten Datenbank zur Verwaltung von über 10.000 Parametern. Diese Parameter bilden den Systemzustand des Geräts ab. Die Datenbank berechnet Abhängigkeiten, kann Default Werte wiederherstellen, kann den Systemzustand abspeichern bzw. wiederherstellen und stellt die grundsätzliche Funktionalität für Undo / Redo zur Verfügung.

Fernsteuerung: Die Geräte kann man nicht nur über das Grafische Userinterface bedienen, sondern auch über Remotebefehle. Diese Fernsteuerbefehle waren in der alten Gerätefamilie lediglich mit einem IEC Bus steuerbar. Durch das Einziehen einer Kommunikationszwichenschicht ist es möglich, die Fernsteuerung über LAN anzusprechen. Hausintern wurde dafür eine Hardware mit zugehörigem Windows Kernelmodetreiber entwickelt. Auf der Gegenseite entwickelten wir den entsprechenden Usermodetreiber und die Anbindung an die Firmware.

GUI: Bei der Entwicklung des graphischen Userinterfaces ist eines der wichtigsten Anforderung, dass die Einstellungen und Messwerte jederzeit aktuell sind. Dafür haben wir grafische Elemente entwickelt, die sich bei der Datenbank bei den entsprechenden Parametern anmelden und bei Änderung des Paramters automatisch aktualisiert werden. In der alten Gerätefamilie fand die Bedienung fast ausschliesslich üb Softkeys und Hardkeys statt. Diese wurde durch eine QT basierte Dialoge erweitert und damit die Übersicht gesteigert. Durch die Möglickeit von meherern Ergebnisfenstern, die auf das selbe Set von Daten beruhen rmöglicht dem Anwender neue Möglichkeiten.

Undo / Redo: Nachträglich wurde eine Undo /Redo Funktionalität realisiert, die Einzelschritte und zusammengeörige Schritte unterscheidet und einen Komfort für den Benutzer darstellt.

Save / Recall: Der Gerätezustand mittels Serialisierung der gesamten Datenbank und der Ergebnisse abgespeichert, und zu einem beliebigen Zeitpunkt wiederhergestellt werden. Hierbei ist die größte Herausforderung die Rückwärtskompatibilität.

Aufgaben:

- Entwicklung eines Usermodetreibers zur Fernsteuerung der Geräte via IEC-Bus und LAN
- Weiterentwicklung einer objektorientierten Parameterdatenbank
- Entwicklung von sich selbstaktualisierenden grafischen Komponenten
- Entwicklung der Benutzeroberfläche (Softkeys und Dialoge) mit der Bibliothek Qt4
- Mehrsprachigkeit mit Qt4
- Implementierung von Remotebefehlen
- Testentwicklung

Umgebung

Betriebssystem:Windows XP
Entwicklungsumgebung: Visual Studio

Optimierung der Bus-Systeme (Automotive)

Überblick:

1)Untersuchung – Abschlatung der Sensorik-Akutatorik von Steuergeräten
2)Untersuchung – Teilnetzbetrieb von Steuergeräten
3)Automatisierung von Fahrzeugzustandsdaten zur Codegenerierung

Die große Überschrift für dieses Projekt ist Stromsparen bei Fahrzeugzuständen im Stand, also bevor die Zündung aktiviert wird. Weiter das Verarbeiten von großen und komplexen XML Dateien.

Projektbeschreibung:

1) Bisher ist die Sensorik und Akuatorik im Fahrzeug immer voll aktiv. Das Ergebnis dieser Untersuchung liefert eine detaillierte Aussage für jedes Steuergerät der Baureihe PL6, in welchen Zuständen welche Sensoren / Aktuatoren abgeschaltet werden könnten, wieviel Strom dadurch gespart werden könnte und welche Kosten für das jeweilige Steuergerät damit verursacht werden.

2) Bisher gab es keinen Teilnetzbetrieb, d.h. wenn im Fahrzeug Kommunikation für einen beliebigen Bus (CAN, MOST, LIN, Flexray) angefordert wird, werden alle Steuergeräte an allen Bussen geweckt und brauchen Strom. Das Ergebnis dieser Untersuchung sind Konzepte für die Busarchitektur, Software und Hardware, was in diesem Bereich bis jetzt und in der näheren Zukunft technisch möglich ist, und eine Kosten/Nutzen Aufstellung der Lösungsvorschläge.

3) Eine bereits durchgeführte Untersuchung lieferte Daten über die Abhängigkeit der Fahrzeugststände und Betriebsmodi zu den Enegiezuständen, d.h. welche Funktion eines Steuergeräts soll in welchen Zuständen aktiviert werden können. Diese Daten waren als Exceldateien verfügbar. Über einen XML Export einer Quell-Datenbank (BNDB) mußte eine Abgleichmöglickkeit über die aktuellen Funktionen der Steuergeräte realisiert werden und Möglichkeiten der Konsistenzprüfung der Excelsheets geschaffen werden. Im nächsten Schritt erstellte ich eine Datenbank mit komfortablen, hierarchischen Eingabemöglichkeiten für logische Obergruppen von Funktionen, d.h. man spart Eingabearbeit und hat aussagekräftige Abfragen über die Daten zur Verfügung. Der letzte Schritt war die Erzeugung von XML-Dateien, die den Codegeneratoren Standardcore(Vektor) und Tresos(3Soft), welche den Code für alle Steuergeräte für die Bereiche Kommunikation und Function Inhibition Management erzeugt. Standardcore und Tresos sind im AUTOSAR-Projekt integriert.

Umgebung

Betriebssystem:Windows XP
Entwicklungsumgebung: Visual Studio

Gerätesimulation für den MOST-Bus (Automotive/Infotainment)

Entwicklung einer konfigurierbaren Gerätesimulationsmodellierung für ein Satellitenradio im Bereich Automotive/ Infotainment / Multimedia

Überblick:

Ziel der Gerätesimulation ist es, ohne die Geräte physikalisch vorort zu haben diese auf einem PC mit MOST-Interface (Optolyzer bzw. MOST-PCI Karte) zu simulieren. Damit kann man Geräte, die noch nicht real existieren im MOSTRing integrieren bzw. real existierende Komponenten durch die Simulation an den Testaufbauten einsparen. Mehrere simulierte Geräte können dabei mit einem MOST-Interface am MOST-Bus angebunden werden.

Projektbeschreibung:

Ziel meiner Tätigkeit war die Entwicklung der Simulation einer weiteren Systemkomponente DAB Tuner (Satellitenradio). Aus der bestehenden Spezifikation waren erst Rose RT Message-Sequence-Charts zu entwickeln, aus diesen das logische Modell, d.h. die eigentliche Simulation des Geräts zu entwickeln und die MOST-Telegramme der Funktionen in ein bestehendes Framework abzubilden. Damit man die Simulation komforabel bedienen kann, waren MFC-Panels für die MMI, die Gerätekonfiguration und das Frontpanel des Geräts zu entwickeln.

Aufgaben:

- Entwickeln von Usecases in Form von Message-Sequence-Charts in Rose RT (UsecaseView: MSC)
- Integration der MOST-Befehle in das bestehende Framework. Entwicklung eines Codegenerators in Java (Eclipse) zum Erzeugen von Frameworkcode.
- Erstellen einer XML Konfigurationsdatei. Einlesen dieser Datei mit XML Parser (Xerces für C++.)
- Abbilden der MOST-Telegramme (MOST-Mapping)
- Erstellen und einlesen einer XML Datei, welche die Gerätekonfiguration beinhaltet.
- Entwicklung des Rose RT Modells (Logical View: Interfaces, Ports, Capsules und Statecharts).
- Entwicklung der MFC Panels

Umgebung

MS - Visual C++, Rose RT, Xerces (XML Parser), Java, Eclipse, Optolyzer, Windows XP, Testboard mit Systemkomponenten und MOST Anbindung.

Integriertes Navigationssytem / Infotainment Headunit

Überblick:

Für eine Multiprozessor Infotainment-Headunit für Automobile der Oberklasse (Radio/CDPlayer/Navigation/Telefon/Car Funktionen) mußte die Problem Reports mit Traces und Debugtools analysiert und gefixt werden.

In der Guidance der Navigation, d.h. die Ausgabe der gesprochenen Texte, Anzeige der Pfeildarstellung, der Geoposition, der aktuellen Strasse/Ortschaft, Streckenliste, etc.) waren die Anforderungen erst teilweise implementiert. Diese musste weiterentwickelt werden.

Ziel war die Herstellung eines serienreifen Zustand dieser Headunit. Alle Fehler, welche die Funktionsfähigkeit des Systems so beeinträchtigen, daß das Fahrzeug zur Reparatur in die Werkstatt gebracht werden muß, sollten behoben werden. Die gewünschte Funktionalität muß von Feinheiten abgesehen korrekt implementiert und getestet werden.

Projektbeschreibung:

Zum einen waren viele kleine Fehler direkt in der Navigation zu tracen, analysieren und beheben, um Abstürze zu verhindern und um ein korrektes Verhalten beim Abfahren der Routen zu gewährleisten. D.h. die richtigen Anweisungen zur korrekten Zeit, die richtige Zeit und Entfernung bis zum erreichen des nächsten Ziels etc.

Zum anderen waren in diesem komplexen Umfeld nach dem Modultest der einzelnen Komponenten und deren Tasks vor allem Fehler in der Kommunikation und Laufzeitfehler zu analysieren, Statemachines zu korrigieren, und funktionale Fehler die durch Laufzeitabhängigkeiten der Module entstehen, bzw. eine Übersicht im Grösseren zu bewahren, um die spezialisierten Entwickler zusammenzuführen ,um gemeinsam die Analyse bzw. die Lösungen für komponentenübergreifende Fehler zu finden.

Aufgaben:

Entwicklung, Bugfixing und Test für folgende Komponenten

- Guidance der Navigation (Anzeigen von Symbolen und Ausgabe von Ansagen)
- Kommunikation zwischen Navi Module und SH3.
- Adressverwaltung, Routenplanung, Sonderziele
- Das Erkennen von Navigation und Update CDs.
- Softwareupdate aller anderen Teilsysteme via CD.
- Sprachumschaltung Cluster/ Display / Sprachausgabe

Umgebung:

PC-Seite: Rhapsody in C++ 4.1, MS VC++, Lauterbach Flashtools, DIPC Analyser (Analyse für I²C-Bus Communication), Optolyser (Analyse Software für MOST Bus), CANOE (Analyse für CAN), Rational Clearquest, Rational Clearcase Für Hitachi SH3: VxWorks shell , Tornado, Sniff, Targetserver MIPS- ASIC (Navimodule): OS9-shell (rs232 Connection zum Navi-Modul)

Sh
-

e-Business-Platform

Überblick:

Technische Entwicklung einer e-Business-Plattform für den Krankenhausbedarf an medizinischen Gütern in Europa von Krankenhaussystemen an die Bestellplattform.

Durch die Bildung von Einkaufgemeinschaften können die Kunden, z.B. Krankenhäuser günstiger einkaufen. Diese e-Business-Plattform besteht im wesentlichen aus zwei Komponenten, einer Shopkomponente und einer Ausschreibungskomponente.

Projektbeschreibung:

Für den Shop wurde eine bestehende Einkaufsplattform eingekauft und diese um die Bündelung von Kunden, um ein Einbinden von Katalogen, Onlineshops und anderer Shops und um eine Logisikkomponente erweitert.

Krankenhäuser können durch ein Webbrowser-Interface Ausschreibungen aufsetzten. An diesen Ausschreibungen können sich andere Kunden beteiligen und dadurch die Auftragsgröße vergrößern. Die Ausschreibungen werden anonymisiert veröffentlicht und Interessenten können ihr Angebot anhand eines elektronischen Fragebogens wiederum via Internet abgeben. Die ausgefüllten Fragebögen werden automatisiert nach gewichteten Kriterien bewertet. Für die auschreibenden Krankenhäuser entsteht der Vorteil reduzierter Prozesskosten. Sie werden außerdem bei der Auswertung der Angobote unterstützt. Für die Interessenten besteht der Vorteil, von einem spezailisiertem Team unterstützt zu sein, auf eine Vielzahl von Ausschreibungen zurückgreifen zu können, sowie die Reduzierung der Prozesskosten.

Aufgaben:

- Spezifikation der Ausschreibungskomponente mit den Ausschreibungsspezialisten.
- Design und Implementierung von Datenbank und Java Klassen.
- Entwicklung des Frameworks
- Einbinden von online Katalogen in die Plattform
- Einbetten von e-commerce Schnittstellen z.B. zu SAP-Systemen für die Bestellung

Umgebung:

Betriebssystem:Windows 2000
Umgebung: MS SQL Server, Java (JSP, JDBC) mit den WebServer Resin und Tomcat

Testhandler für Microchips

Überblick:

Die Microchips werden in Frames durch eine Industriestrasse aus mindestens 3 Produktionsmodulen (Loader, Handler und Unloader) gefahren.
Diese Geräte müssen synchonisiert Abläufe durchführen.
Fehler eines Geräts haben müssen von der Logik der Industriestrasse abgefangen werden.

Projektbeschreibung:

Da die Module Echtzeitanwendungen beinhalten, mußte die Kommunikation auf ein Mininimum an Daten optimiert sein. Daher wurde für eine sichere, effektive Kommunikation, die den Empfang von Befehlen und Daten bestätigt ein Kommunikationsserver entwickelt, der RPC mit darunterliegendem TCP/IP benutzt. Die Module kommunizieren nicht untereinander, sondern nur mit einem Kommunikationsserver und einem Panel-PC.

Die individuellen Module bedienen sich dann eines Basisframeworks, das garantiert , daß die Module grundlegend ähnlich aufgebaut sind und den gleichen Kommunikationsprinzipien folgen, auch wenn die eigentliche Funktion vollkommen unterschiedlich sein kann. Ein Modul kann sich für verschiedene Funktionalitäten anmelden, sodaß es ereignisgetrieben genau über das benachrichtigt wird, was es interessiert.

Dieser Panel-PC stellt das Userinterface aller Module auf einem Touchscreen- Display an und übernimmt einen Großteil des Datenmanagements der einzelnen Module und der Linie. Die größte Herausforderung beim Entwickeln des Userinterfaces war die Anforderung, daß einzelne Module beliebig in die Linie eingefügt bzw. aus der Linie entfernt werden können und das Userinterface sich automatisch und dynamisch an die momentan gültige Topologie der Linie anpaßt (incl. benutzerfreundliches Errorhandling, Rezepthandling, Statistik und internationaler Sprachumgschaltung). Jede Teiloberfläche stellt eine ausführbare Windowsanwendung (*.exe) dar, die zur Laufzeit von einer übergreifenden Windowsanwendung gestartet / beendet wird. Zur Datenverwaltung auf dem Panel-PC wurden relationale Datenbanken und ini- Files benutzt. Als Austauschformat für die internationalen Texte im Programm und Fehlermeldungen wurden Excel mit NJStar verwendet.

Die Statistik wurde als firmenübergreifende Intranetlösung mit VB.NET und IIS zur Verfügung gestellt. Im Userinterface wird die Statistik daher mit einem in der Oberfäche integriertem Webbrowser angezeigt, welcher auf parametisierten Anfragen dynamisch die entsprechenden HTML-Seiten erzeugt.

Aufgaben:

- Anbindung einer RPC-Schnittstelle von einem Windows XP Steuerrechner zu vxworks Clients.
- Anbindung eines Methodeninterfaces zum direkten Aufruf von Funktionen auf der Maschine
- Anbindung eines Dateninterfaces, welches Datengetrieben die Maschine steuert.
- Entwicklung einer Ablaufsteuerung mittels StateCharts
- ComServer, ErrorCtrl, ClusterCtrl
- Entwicklung einer Oberfläche mit Custom made OCX Controls, welche die Vorgänge im Testhandler übersichtlich darstellt.
- Implementierung einer internationalen Sprachumschaltung.

Umgebung:

Betriebssystem:vxworks, Windows 2000, Windows XP
Entwicklungsumgebung:Rhapsody, Visual Studio, Visual Basic, VB.NET, Bachmann GUI, Windriver Tornado

Java GUI Panel für vxWorks Steuergeräte

Überblick:

Diese Steuerung wird unter anderem in Windkraftwerken verwendet. Die graphische Oberfläche auf der Steuerung ermöglichst eine Wartung ohne Notebook. Das bedeutet eine Erleichterung für das Wartungspersonal.

Projektbeschreibung:

Für das bereits existierende Echtzeitsteuerungssystem unter VxWorks wird eine neue Komponente, ein Panel-PC mit Touchscreen erstellt, welches als Terminal in die Steuerungsleiste integriert werden kann. Das Visualisierungskonzept von Bachmann basiert auf Java. Als Java Virtual Machine wurde die HP ChaiAWT gewählt.

HP’s CHaiAWT ist eine Java-VM, die komfortabel zu portieren ist. Es mußten also eine spezifizierte Menge von Funktionen unter VxWorks geschrieben werden, die von den Hardwaregerätetreibern bedient werden. Mit Ausnahme des Grafiktreibers ist das Aufrufkonzept vollständig event-basiert. Zur Ergänzung der numerischen Folienastatur, die in das Gerät eingebaut ist, wurde noch ein virtuelles Keyboard, das man über die Folientastatur startet entwickelt und auf dem Touchsceen erscheint.

Die einzelnen Treiber werden als Module (nicht als VxWorks-Treiber) erstellt und ausschließlich von der Java-VM und dem AWT genutzt. Für die Grafikansteuerung wird ein Framebuffer Treiber erstellt. Der Touch-Screen Controller wird über die serielle Schnittstelle mit Hilfe eines DataModul FIT-10 I/F DM Inteface Boards angesteuert. Ein Maschinenpanel wird über die Parallele Schnittstelle (Matrix, Interruptgetrieben) angesteuert und intern mit den Daten des Maus-, Touch- und Keyboard Controllers verknüpft.

Entwicklung eines virtuellen Touch Screen Keyboards in Java. Dieses unterstützt internationale Keyboardbelegungen, individuelles Design durch selbstentwickelte Komponenten und freie Skalierbarkeit. Sie greift direkt in AWT Eventmechanismus ein, erzeugt also KeyEvents, wie eine echte Tastatur

Aufgaben:

Folgende Komponenten waren zu integrieren:
Graphics-Controller Savage4 (S3) in VIA TwisterT PN133 Chipset.
DMC FIT-10 Touch-Screen Controller über RS 232.
PS2/Maus und Keyboard
Externes Panel(Keyboard) über parallele Schnittstelle
Touchscreen,
Anbindung von HP’s ChaiAWT (eine Java Virtual Machine)
Entwicklung einer virtuellen Tastatur in Java AWT.

Umgebung:

Betriebssystem:Windows XP, VxWorks
GNU C++-Compiler, MS-VC++ Umgebung, VxWorks, S3 ETX-Board,DMC Touch- Screen Controller, Serielle- u. Parallele Schnittstelle, Java 1.1.8, JBuilder

Partikelmeßdatenerfassung und Auswertung

Überblick:

In Reinräumen werden mit Notebooks die Daten der Partikelmessungen aufgenommen.
Diese Daten werden werden dann mittels sicherer Transaktionen an eine Server Datenbank übertragen.
Um mit diesen Daten eine Qualitätskontrolle der Reinräume zu realisieren, wurden Sie im Intranet als parametrierbare Diagramme mit Warn- und Alarmgrenzen im Intranet als Applet zur Verfügung gestellt.

Aufgaben:

- Erstellen des Notebook-Clients zur Datenaufnahme. - Design der Server Datenbank - Implementierung der Server-Datenbank - Ausarbeitung eines sicheren Transaktionskonzept und der Implementierung in Java. - Implementierung von Übersichten und Grafiken.

Umgebung:

Betriebssystem:Windows XP,
Umgebung: Oracle, Java (JBuilder, Application und JDBC)

Leitfaden zur Altbausarnierung

Überblick:

Redesign und Erweiterung eines im Internet frei verfügbaren Programms, mit dessen Hilfe sich Hauseigentümer detailliert über Sarnierungsmassnahmen deren Kosten und Nutzen erkundigen können.

Projektbeschreibung:

Für einen Prototyp eines Java-Applets wurde die Klassenarchitektur redesigned, sodaß die Navigation und Funktionalität von Panels in einer systematischen und wiederverwendbare Struktur untergebracht sind und das Programm sowohl als Applet, wie auch als Applikation verwendet werden kann. Das resultierende Programm wurde um ein Diagramm- und Druckkomponenten erweitert und im Internet als Applet bzw. als downloadbare Applikation zur Verfügung gestellt.

Aufgaben:

- Redesign der Navigation
- Ermöglichen, daß das gleiche Java Programm sowohl als Applet als auch als Applikation starten kann.
- Implementieren von Diagrammen
- Trennnung von Daten und Anzeige
- Implementieren einer Druckkomponenete
- Abspeichern der Daten mittels Serialisierung der Applikationsdaten.

Umgebung:

Betriebssystem:Windows XP
Umgebung: Java (JBuilder, Application / Applet), HTML