Februar 2008 bis Juni 2010 Testautomatisierung EXAM (Audi)
Arbeit im Team Testautomatisierung EXAM.EXAM ist ein UML-basiertes Tool zum erstellen und ausführen von Testabläufen und zum betrachten und auswerten von Ergebnissen der Testläufe im Automotive-Umfeld bei Audi. Tools: EXAM 1.3, 1.4,2.0, Modena; dSpace-Bibliotheken. Programmiersprachen Python, C, Matlab.
Aufgaben in diesem Einsatz:
1) Weiterentwicklung der Platform-Anbindung. Vor allem die Anbindung dSpace-HiLs an EXAM. Mapping von Platform-Variablen auf symbolische Namen (Shortnames) oder Postionsnamen (Full Scope Names). Weiterentwicklung des Lean Mapping (automatisches Mappen auf Grund bestehender, bereits gemappter Variablen).
2) Einführung von Unit-Tests als Werkzeug der Qualitätssicherung für den Source-Code.
3) Einsatz als ?Firefighter? (Support bei Problemen mit kritischer Auswirkung, bei denen vertiefte Python-Kenntnisse und allgemeine Programmier-Erfahrung von Nöten waren).
4) Weiterentwicklung der Anbindung Modena-EXAM. Modena ist ein State-Chart basiertes Tool, das bei Audi zum Test vom Multi-Media Interfaces verwendet wird.
5) Weiterentwicklung der Anbindung EXAM-xPC. xPC ist ein Matlab-basiertes HiL ?System.
6) Weiterentwicklung der Anbindung EXAM-Concurrent-HiL. Concurrent ist ein Echtzeit-Linux-basiertes HiL ?System.
Januar 2007 - April 2008 (nebenberuflich): Mitentwicklung einer Kaufmänischen Applikation zur Führung kleiner Firmen
Inhalte: Auftragsverwaltung, Addressverwaltung, Schriftverkehr etc. Aufgaben: Entwicklung von Komponenten des Frameworks in C#/.Net 2.0; Entwicklung des Installers und des Bootstrappers. Tools: C#/.Net 2.0, WiX (MSI), AutoIt3.
2007 Oktober bis Dezember: Testautomatisierung mit Metaedit+ (BMW)
Entwicklung einer grafischen Sprache zur Testautomatisierung im Automotive-Umfeld. Tool Metaedit+,
dSpace-Bibliotheken. Modellbasiertes Programmieren / Codegenerierung, aus dem Modell wird 100% des Codes generiert.
2007 Mai bis September: Testautomatisierung mit RTT (BMW)
State-Machine-basierte Tests auf Basis von RTT und Stateflow-Modellen.
Umfeld: Neuentwicklung Hybrid, HiL von dSpace.
Zielsetzug: Überprüfung der korrekten Reaktion einzelner Output-Signale eines Steuergerätes auf Input-Signale.
Umsetzung: Das Modell der Funktionalität einzelner Output-Signale wurde in State Machines im Stateflow-Modell abgebildet. Die korrekte Reaktion der Signale wird in Echtzeit-Python überprüft (RTT der Firma dSpace).
2007 April bis September: Standardisierungsarbeit HiL-API (BMW)
Teilnahme an der HiL-API-AG, Entwicklung von Teilaspekten der HiL-API UML-Modelle in Enterprise Architect. Zweck der Enticklung ist Standardisierung von SW-Zugriffen auf HiL-Syteme.
2007 Februar-März: Restbus-Simulation mit CAN Multimessage-Blockset Teil 2 (BMW)
Konkrete Anwendung der im Vorjahr entwickelten Software.
2007 Januar-Februar: Untersuchung der Kombination neuer dSpace- und Matlab-Releases auf Einsatzbereitschaft (BMW)
Ein altes großes Simulink-Modell wurde auf dSpace 5.1 und dSpace 5.2 zum laufen gebracht, die Anfänglichen Probleme wurden verfolgt und eingegrenzt.
2006 September-Dezember: Untersuchung UML auf Tauglichkeit als Grundlage für eine Sprache zum Austausch von Testfällen (Testaustauschformat) bei BMW
Verwendete Tools: Enterprise Architect. UML wurde als zu umfangreich und uneindeutig befunden, um es zum genannten Zweck zu verwenden.
2006 Mai-August: Aufabu eines Teststandes auf Grundlage von dSpace-HiL Midrange zum schulen neuer Mitarbeiter (BMW)
1) HW: Aufbau und Anbinden eines Steuergerätes über den dSpace CAN-Highspeed-Lowspeed Adapter.
2) Erstellen eines Layouts zum bestehenden Simulink-Modell (ISAR).
3) Erstellen der Testfälle unter Einsatz der Werkzeuge AutomationDesk und ECU-Test. Ausführende Werkzeuge: Ediabas, rtplib, FIU (ioclib).
2006 Februar-April: Restbus-Simulation mit CAN Multimessage-Blockset Teil 1 (BMW)
Entwicklung einer Restbus-Simulation auf Grundlage des CAN-Multimessageblocksets von dSpace. Zu versendende Nachrichten wurden aus zu simulierenden Steuergeräten, bestehenden Steuergeräten im Bus-System und individuell einstellbaren Filtern berechnet. Gesondert berücksichtigt wurden Zähler und Alive-Signale, wie auch Netzwerk-Botschaften.
Januar 2005 bis Dezember 2005 (nebenberuflich) Entwicklung von Finanzapplikationen auf Grundlage des jPos-Frameworks. Sprache: Java 1.4, Tools: jPos, Ant, Jython.
August 2003 bis Dezember 2005 Entwicklung einer durchgängigen Tool-Kette für Tests auf HIL-Systemen bei der BMW AG
Verbinden mehrerer SW-Systeme in eine durchgängige Tool-Kette. Zentrale SW-Komponenten: Testsequenzer TestStand von National Instruments, ECU-Test von Tracetronik, Test-Management Tool QualityCenter (ehemals TestDirector) von Mercury.
Folgende Anbindungen und Komponenten wurden erstellt:
1) Anbindung TestStand-ControlDesk (über die rtplib und Python/C API)
2) Anbindung TestStand-Ediabas (Schnittstelle in C/C++: MSVC6.0 und CVI von National Instruments)
3) Alternatives GUI für TestStand (Visual Basic 6.0).
4) Anbindung QualityCenter-ECU-Test (Visual Basic 6.0, COM, zLib, Excel, HTML). Alle Komponenten der OTAG Schnittstelle wurden implementiert.
5) Testschritttypen für ECU-Test zum Prüfen des Konzepts der austauschbarkeit der Testplatform (Python / wxPython).
6) Tests in Teststand und ECU-Test für die Telefon-Abteilung
Folgende Untersuchungen wurden durchgeführt:
1) TTCN 3 auf Einsatz als Grundlage für Testautomatisierung.
2) Vergleich von Testautomatisierungswerkzeugen ECU-Test, AutomationDesk, TestStand
2003 Januar bis Juli Komponententester für Komponenten im MOST-Ring bei der BMW AG
Tätigkeiten:
1) Anpassen des Formats des BMW - MOST - Katalogs, so dass das XML-File validierbar ist.
2) Weitere Transformationen am XML-File zu verschiedenen Zwecken, alle unter Einsatz der Programmiersprache Python.
3) Erstellen von Test-Skripts zum Testen von MOST - Komponenten unter Berücksichtigung von bestehenden MSCs.
4) Koordination mit dem Tool-Hersteller des Test-Systems 4CS.
2002 Mai bis Dezember SW-Tester für ein CAN-MOST Gateway bei der BMW AG
Tätigkeiten:
1) Technische Anleitung der ausführenden Firma und dessen Koordination mit den Anwendern (Testern bei BMW).
2) Teilspezifikation und Präzisierung der Funktionalität, des grafischen Layouts und der Ausgabe der Ergebnisse.
3) Organisation der Kommunikation mit der ausführenden Firma inklusive der Bugreports.
4) Auswertung der zu testenden Fälle unter Einsatz der Programmiersprache Python.
5) Auswertung des Speicherverbrauchs und des Speicherlayouts der Gateway-SW unter Einsatz der Programmiersprache Python.
6) Erstellen eines Alternativkonzepts (inkl. Spezifikation) zum testen des Gateways und dessen Teilweise Implementation auf Grundlage des Programms Vector CANOe Option MOST.
2002 Januar bis April Weiterbildung im kaufmännischen Bereich: Marketing, Buchhaltung, Firmenführung. Mehrere eigene Projekte in Python, Java (1.3) und C++ (MSVC 6.0).
2001 Februar bis Dezember Für die Firma Protos GmbH und deren Kunden
1) Auswahl der Komponenten für ein USB-basiertes Projekt.
2) CAN und CAN-Open Treiber auf unterschiedlicher HW.
a) Der erste Treiber war eine Anpassung des C167-Treibers von Infineon. Das Gegenstück im Netzwerk war ein CANOpen-basiertes digitales IO-Modul.
Der C167 war auf einem Board der Firma Keil. Entwicklungsumgebung: uC2 der Firma Keil.
b) CAN Treiber auf einem QNX-basierten System (Steuerrechner einer Sondermaschine). Spezifikation und Implementierung mehrerer Treiber. Netzwerkteilnehmer waren zum Teil digitale Vipa-IO-Module, zum Teil eigens entwickelte HW Boards mit komplexer Funktionalität (Multi-IOs). Die Entwicklungsumgebung war das Casetool Trice und der Watcom C++ Compiler.
c) Ansprechen der IXXAT-CAN-Karte aus einer Windows-NT basierten echtzeitfähigen Umgebung heraus (Lösun aufgrund der Karte von LP-elektronik). Dazu mußte ich den IXXAT-CAN-Treiber auf diese Umgebung anpassen. Entwiklungswerkzeuge: MSVC++, WAGO-IO-Modul.
d) Treiber für das WAGO IO Modul und das Serielle WAGO Modul. Werkzeuge: CASE-Tool Trice, MSVC++.
e) CAN-Treiber für die Ansteuerung von Servomotoren der über den Regler der Firma e-motion. Umgebung: C167/Phytec Board, Keil Entwicklungsumgebung, e-motion Regler mit der eigenen Sprache -Epos-.
Verwendete HW: WAGO-Module, VIPA-Module, IXXAT-Karten, CAN auf Infineon uC (C505, C167).
3) Entwicklung von SW Komponenten mit dem CASE-Tool Trice und C/C++.
Anmerkung: Trice wurde auf Grundlage der ROOM -Methodologie Entwickelt. Dies ist die selbe Methodologie, auf der Rose RT aufgebaut ist.
Änderungen an den Digitalen und Analogen Klassen der Virtuellen Maschine der Steuerung.
Weiter mehrere kleinere Projekte und Teilprojekte für Kunden des Auftraggebers auf Basis des CASE-Tools Trice.
September 2000 - Januar 2001
TV-Signalverarbeitung mit M2(SDA 6000).
M2 ist ein C166-Derivat mit zusätzlicher Funktionalität
1) zur Verarbeitung der TV-Teletext-Signale (und anderer Digital-kodierter Signale im Analogen TV-Signal-Fluß)
2) zur Darstellung digital generierter Bilder auf dem TV-Bildschirm (z.B. Teletext -Anzeige). Ziel des Projektes war implementation eines neuen Protokolls, das digitale Daten im Fernsehenbild zu übertragen hatte. Zuerst war ein zusätzlicher Miktokontroller dafür vorgesehen, dieser wurde dann auf Grund eines Einfalls von mir rausoptimiert und die verarbeitung wurde dem M2 überlassen (der sich ohnehin in jedem Fernseher befindet).
Meine Aufgabe bestand in mehreren klein - Projekten. Darunter hervorzuheben, mehrere Tools:
1) zum speichern des Images über die serielle Schnitstelle, mit Umwandlung und Speichern ins Flash;
2) Test - Tools für das Protokoll.
Tools: Keil, ICE von Lauterbach.
Juli 1999 Gründung eigener Firma im Dienstleistungsbereich; der Betrieb wurde Mitte 2001 eingestellt.
April 1997 - Juni 1999 bei GSM-SW Hersteller Optimay in der Entwicklung und im Technischen Support.
SW - Entwicklung unter Einsatz von C unter RTOS:
1) Entwicklung von HW-Treibern für Schnittstellen-HW (Batterie Messung, eingefügt in GSM Protokoll Stack). Umfang ca. 6 Monate.
2) Entwicklung Kundenspezifischer Methoden und Zusätze im GSM - Protokoll Stack. Diese Entwicklung war für ein GSM-Handy, auf Basis der Chipsätze GOLD und HiGOLD. Beides sind C166-Derivate, ergänzt mit zusätzlichen DSP-s und RF-Teil Anbindung. Das umfassendste Projekt war der oben genannt Batterie - Treiber (der zu kontrollieren hatte, wie Weit die Spannung der
Batterie für das funktionieren des Handys ausreichend war). Hintergrund: der AD - Wandler der für die Batteriemessung zuständig war wurde auch im Audio-Pfad des Chipsatzes verwendet. Deswegen mußte man innerhalb des Zeitrahmens von 4,6 ms an einer geeigneten Stelle die Kontrolle über den ADC übernehmen (Ist-Zustand speichern, umkonfigurieren), wieder auf geeigneter Stelle die Messung ausführen und zu Verfügung stellen, und die Kontrolle des Audio-Pfads über den ADC wiederherstelle. Dabei waren verschiedene Abhängigkeiten zu berüksichtigen (z.B. ist der Zeitpunkt zu dem das Handy sendet nicht geeignet für Messungen, da das Meßergebnis verfälscht wird).
Die genaue zeitliche Abfolge der verschiedenen Schritte wurde durch Einsatz eines der 4 HW-Interrupts die auf dem Chipsatz zu Verfügung standen geregelt (d.h. man mußte für jeden neuen Schritt auch den Interrupt umkonfigurieren - Zeit setzen, scharf machen). Zusätzliche Komplexitätsgrade kamen im Projekt hinzu, in dem:
a) der genannte HW-Interrupt auch für andere Aufgaben verwendet wurde;
b) die geeigneten Zeitpunkte innerhalb des Zeitframes für das Messen unterschiedlich waren, je nach Kanal auf dem sich das Handy befand(TCh, BCh usw.)
Die Entwicklungsumgebung bestand (auch in den nachfolgenden Projekten) aus dem HW-Board von Siemens, dem Keil-Compiler/Linker (damals noch DOS-basiert) und darauf aufbauenden firmeninternen Tools (Batch-Dateien für einen automatischen Compile/Link/Hex2Bin-Zyklus). Die Binaries wurden über die JTAG Schnittstelle ins RAM geladen und getestet. Für das Debuggen wurden ausgaben aus einem selbstgemachten Trace-Tool benutzt. Die endgültigen Tests, ob der Treiber die Funktionalität des Handys beienträchtigt wurden mit GSM-Testern durchgeführt. Während der Entwicklung waren manchmal analoge und digitale Oszyloskope von Nutzen.
3) Parallel und Anschließend zu dieser Entwicklung habe ich mehrere Firmen im Technischen Support betreut. Dabei sind meist technische Fragestellungen aufgetreten, die durch alle Ebenen des Protokoll-Stacks gingen (inklusive aller GSM-Layer, des HW-Layers und des MMI). Meist war die Test-Umgebung für die Probleme wie oben beschrieben (mit dem unterschied das das Testen auf
fertigen Produkten passierte, unter Einsatz der firmenspezifischen Flash-Tools). Zum lösen der Probleme waren nötig: ein grundlegendes Verständnis des Aufbaus des GSM-Stacks, wie auch Detailwissen über die Teile des Stacks, in denen die Probleme aufgetreten sind.
4) MS Access: Error-Report DB, die die alte Paradox-basierte DB abgelöst hat.
PC Kalibrations-SW für Mobiles (bei Produktion). Hauptsprache C, Teile in Delphi, GPIB. Einsatz von HP - GSM Teststationen.
Die grundlegende Umgebung wie oben. Ziel dieses Projektes war fein-Kalibration der RF-Teile des Mobiles
am Ende der Produktion, um optimale Sende- und Empfangsqualität zu erreichen. Dazu hat man die Charakteristik des jeweiligen RF-Teils mit einem GSM-Tester gemessen, und aufgrund der Abweichung vom Optimum die Sende- und Empfangstabellen angepaßt, und ins Flash gespeichert. Der größte Teil der Arbeit war auf der Handy-Seite. Das Programmieren des Testers geschah zum in einer Hersteller-eigenen Basic-ähnlichen Sprache.
5) Firmeninterne Schulung zum Thema Produktions (Kalibrations) - SW.
Mai 1995 - März 1997 bei der Firma Software Factory
1) MS Excel (mit VBA): PC-Client zur Auswertung von Produktionsdaten für Druckmaschinenhersteller. Abrufen der Daten via ODBC (von VMS RDBMS Server). Vielseitige Auswertung und Darstellung der Daten, dynamische Tabellen - Ansichten.
2) MS Access: Tool für Waferverwaltung für namhaften Halbleiterhersteller. Erweiterung der bestehenden Funktionalität. Erweiterung der Abfragen. Einführung neuer Sicherheitsstufen / Zugriffsrechte. Mehrere neue Masken, Erweiterung der Reports. Ständiger Kundenkontakt und Einführung vor Ort.
3) MS Access: Tool zur weltweiten Planung der Produktion für Automobil - Teile Hersteller. Erweiterung der bestehenden Funktionalität. Geschwindigkeitsoptimierung der Abfragen. Mehrere neue Masken, Reports, Grafische Darstellung erweitert. Daten/Masken Trennung. Einführung vor Ort.
4) Ansteuerung der Seriellen Schnittstelle: Erstellung einer DLL ( unter MSVC++ ) zur Steuerung der Serverseitigen seriellen Schnittstelle (RS232).
5) CAD (ProEngineer): Entwicklung mathematischer Konzepte (z.B. Besier-Kurven, Schnittbestimmung) und Umwandlung in Algorithmen.
6) TCP/IP: Entwicklung eines Clients basierend auf den Telnet- und FTP-Protokollen ( Socket - Programmierung; Dateitransfer und Ausführen komplexer Aufgaben auf der Server-Seite; Realisierung in C, in Form einer statischen Bibliothek).
7) CA Ingres - Open Road (4GL) unter Windows und Unix- ca. 10 Projekte: Erstellung und Pflege mehrerer komplexer SQL - Datenbankapplikationen. Bereiche:
Verwaltung von KKW-Daten
a) DB Erstellung, Altdaten-Übernahme/Anpassung, Reporterstellung unter Einsatz von MS Word/DDE.
b) BTX-Seitenerstellung. Zusammenführung bestehender Applikationen.
c) Tool zum aufspüren von falsch eingetragenen Datensätzen.
d) Entwicklung und Installation beim Endkunden.
e) Internes, weltweites Tool für Halbleiter - Hersteller: Internationalisierung (Deutsch/Englisch).
Januar bis April 1995 Firma EOS (Branche Rapid Prototyping)
Entwicklung eines Teststandes für die Erfassung mechanischer Meßwerte: Hardware und Datenerfassungssoftware. Verbindung DSP-uC- und Ansteuerungssoftware für Schrittmotore in MS Visual C++; Auswertung und grafische Darstellung Makro-gesteuert in MS Excel).