Details:

Aufgaben

Details:

Details:

Stryker entwickelt medizinische Geräte, u. a. HNO Navigationsysteme mit zielgeführter Chirurgie und Augmented Reality..

• Das Gerät erzeugt ein elektromagnetisches Feld und ist damit in der Lage aufgrund von CT und MRT Daten den Chirurgen mit seinen Instrumenten durch den Schädel zu führen

Meine Funktion:

• Blackboxtest
• Test der grafischen Darstellungen bzw. der Augmented Reality
• Schnittstellentests
• Instrumententests

Technische Anforderung:

• HNO System mit diversen externen Geräten, Chirurgische Intrumente

Stryker entwickelt medizinische Geräte, u. a. HNO Navigationsysteme mit zielgeführter Chirurgie und Augmented Reality.

Meine Funktion:

Der Automobilzulieferer Molex entwickelt u.a Wireless Charger für Volkswagen, BMW und andere OEMs

Meine Funktion:

• Weiterentwicklung des Produktions-Testsystems Cobbler in LabVIEW.
• Inbetriebnahme an Produktionsstationen.
• Einführung des V-Modells für die Cobbler Entwicklung.
• Einführung Konfigurationsmanagement und Versionsverwaltung
• Teamführung unter Einbeziehung der US Kollegen.

Für die US Traktorenhersteller Case, New Holland und John Deere werden in Berlin elektronische Steuerungen für diverse Modelle entwickelt.

Meine Funktion:

• Testspezifikationen erstellen.
• Testfälle entwickeln.
• Integrationtests und Shorttests durchführen.
• Automatisierte Testdurchführung und Reporting mit Labview.
• Hil Testsystem mit LabView und NI Komponenten aufbauen.
• Microcontroller Entwicklung mit Cortex M3.
• Erstellen eine SPI-Simulation (Slave).

Details:

• Die Produkte sind Armrests und Joysticks, die die gesamte Steuerung des Traktors beinhalten. Sie bestehen aus Bedienungseinheiten und u.a. aus Steuergeräten für Zugvorrichtungen, diversen Antrieben und den hydraulischen Einheiten. Als Bussystem wird LIN, CAN incl. J1939 verwendet.
• Für die Funktionale Sicherheit werden Testspezifikationen erstellt und ein HiL Testsystem mit LabVIEW aufgebaut. Die Integrationstests sollen automatisiert über ein NI-PXIe System mit entsprechenden Modulen (z.B. für Failure Insertion) erfolgen.

Für ein Fahrerassistenzsystem (ARA2) sollen Systemtests geplant, entwickelt und durchgeführt werden.

Details:

• Das zFAS ? zentrales Fahrerassistenzsystem (Steuergerät) enthält alle Funktionen die für das automatisierte Parken benötigt werden.
• Die Systemtests sollen für den Anhänger-Rangier-Assistent-2 durchgeführt werden. Neben der Entwicklung von Testplänen, steht die Erstellung der System-Testspezifikation aus dem System-Lastenheft heraus.

Aufbau des HiL Testplatzes, Automatisierung von SW-Tests auf dSpace Basis. Erstellen der Testspezifikation. Test Management und Reporting zu oberen Führungsebenen. Softwaretests. Bereich Elektromobilität.

Details:

• Meine Funktion: Testmanager und Tester.
• Meine Funktion: Testmanager und Tester.HEV ? Steuergerätetest der Vollhybridmodelle von Jaguar Land Rover.
• Dafür wird die Software Testumgebung neu aufgesetzt.
• Als Testsystem wird die dSpace HiL Architektur verwendet.
• Meine Aufgabe ist es, sämtliche Tools auf den host PC des HiLs zu konfi-gurieren, so dass die Tests automatisiert durchgeführt werden können. Aufgrund der SW-Requirements sind von mir die SW Testspezifikation und die dazu gehörigen Testsequenzen zu erstellen.
• Softwaretest mit Tessy ergänzt dies in den letzten Monaten.

Erstellen von automatisierten Tests, Komponententest am HiL.
Schnittstellentest DXL -> MySql

Details:

• Für den Bereich Wäschepflege (Waschmaschinen und Trockner) gibt es eine Vielzahl von Steuergeräten, die mittels Verfahrenstabellen abhängig vom Maschinentyp Programme abarbeiten.
• Der HiL simuliert über den DBus (Eigenentwicklung auf Basis CAN-Bus) die unterschiedlichen Maschinen. Eine Testsuite fragt die Zustände der Maschine ab und bewertet diese.

Meine Aufgabe

• ist es, für den automatisierten Test von Komponenten Verfahrenstabellen und Testsuite-Skripte zu entwickeln.
• Die gesamte Entwicklungsdokumentation, Systemrequirements, System-beschreibungen, Test-Cases und Test-Intends werden in DOORS gepflegt.
• Abgleich der Requirements in DOORS mit der Export Datenbank (SQL)

Erstellen von Test- und Systemdokumentationen, DOORS Vorlagen und DXL-Skripten

Details:

• Erstellen von Dokumentationen (Anforderung und Test), Prüfprotokolle, Arbeitsanweisungen und Prüfanweisungen für die Ländervarianten des Blutpumpenantriebs Ikus.
• Das Gerät Ikus kann die Funktionen des Herzen komplett übernehmen. Die Zertifizierungen in den verschiedenen Ländern sind sehr unterschiedlich, so dass die Dokumentation für das Testen sowie die Systemanforderungen entsprechend umgeschrieben werden müssen.
• Herausfordernd ist der sehr genau definierte Entwicklungs- und Dokumentationsprozess, der in der Medizintechnik aufgrund der Ansprüche an die Geräte verlangt wird.
• Die gesamte Entwicklungsdokumentation, Systemrequirements, Tests, Schnittstellenbeschreibungen, Handbücher und auch Arbeitsanweisungen werden in DOORS gepflegt.

• Erstellen von Spezifikationen aufgrund Normen.
• Erstellung der TÜV Dokumentation

Details:

• Die mobile Ampelanlage befindet sich im Endstadium der SW -Entwicklung.
• Der TÜV-Rheinland verlangt das Testen und die Testdokumentation gemäß ISO 26262.
• Das System, bestehend aus Steuer- und Prüfrechnern (jeweils Master-Slave), ist nahezu dokumentationslos, so dass ein gesamter Dokumentationsstamm aufgebaut werden muss.
• Ziel ist es, die TÜV-Zertifizierung zu bekommen.

Details:

• Die Aufgabe umfasst die Testkonzeption, Prüfplatzaufbau, Testdurchführung und Erstellen der Testdokumentation sowie Datenpflege in DOORS.
• Gemäß V-Modell und ISO26262
• Im Einzelnen werden von mir „Test Cases“ erstellt, deren Grundlage die Requirements von Ford sind. Die Test Cases müssen so aufgebaut sein, dass die Testprozeduren in den Testautomationen zu gewünschten Testzielen, also der Fehlerfindung, führen. Test-Scripting mit dem Test-Automation-Editor von der Firma Vector ist daher ein Teil meiner Aufgabe.
• In Zusammenarbeit mit indischen und amerikanischen Kollegen werden parallel zusätzliche Testumgebungen (Test Benches) definiert und aufgebaut.
• Ein wichtiges Augenmerk im Team des EE-Integrationstest ist das Verhindern von „Reintesten“ von Funktionen und Qualität.
• Testen ist eine Dienstleistung zur Fehlerfindung - Qualität und funktionale Sicherheit zu implementieren ist nicht die Aufgabe.

• Umsetzung Webapplikation von CakePHP zu Java
• Neuentwicklung einer Clientversion in C++
• Konzeption, Kundengespräche

Details:

• Das Fuhrparkmanagementsystem Oscar ist eine in CakePHP entwickelte Internetanwendung. Aufgrund der Beschränkungen, die PHP mit sich bringt, wird die Anwendung nach Java umgesetzt.
• Neben den JSP-Seiten werden zentrale Funktionalitäten in Javaklassen (Servlets) abgebildet.
• Modulare Komponenten, die unabhängig voneinander agieren, können je nach Benutzer/Mandant geschaltet werden.
• Die Datenhaltung findet auf einer SQL-Datenbank statt. Komplexe SQL-Statements entlasten so die Java Maschine
• Als neue Module wurde von mir ein Formularwesen, ein Dokumenten Management und ein Reporting entwickelt.
• Kern der Entwicklungsumgebung ist Eclipse.
• Als Datenbank wird MySQL genutzt. Die Administration der DB sowie Provider Angelegenheiten sind ebenso meine Aufgaben.
• Ticketsysteme in Benutzung sind OTRS und Mantis.
• Das System wird neben anderen von MAN genutzt.
• Die Entwicklung der Java Variante ist meine Aufgabe im Auftrag der FSP (Geltow), eine Tochter-gesellschaft des TÜV?s Rheinland.
• Eine Clientversion unter C++ ist in Planung.

• Softwaretests, Diagnosetest UDS/ODX für das MIB (Modularer-Infotainment-Baukasten) für den Volkswagen Konzern.
• Praxistests in Fahrzeugen (Prototypen), HMI-Tests.
• Flashen mit verschiedenen Tools.

Details:

• Als Mitglied des Testteams obliegte es mir die Arbeit der Softwareentwickler im Bereich Steuergerätediagnose zu testen.
• Basis hierzu was das von der Diagnoseabteilung von Volkswagen in Wolfsburg erlassenen Diagnoserichtlinien nach ODX/UDS für das MIB.
• Aus diesen Vorgaben wurde das Pflichtenheft erstellt.
• Meine Aufgabe war es, daraus eine komplette Diagnose-Softwaretest-Spezifikation mit allen nötigen Testfällen zu erstellen und Softwaretest gemäß dieser durchzuführen und zu dokumentieren.
• Mir stand ein CAN-Testturm mit den relevanten Fahrzeug Komponenten zur Verfügung, die mit dem MIB kommunizierten (Combi, Klima, Gateway etc.).
• Ergänzt wurde das durch Simulationsprogramme, die mittels CANoe andere Steuergeräte in dem CAN-Bus abbildeten.
• Ebenso kamen panasoniceigene Tools, wie z.B. eine Restbussimulation und VW-Tools zum Einsatz.
• Weitere Testaufgaben außerhalb der Diagnose waren Tests für BAP (Bedienungs- und Anzeigeprotokoll) und CAR-Interface (Aus- und Eingabeschnittstellen zu anderen Steuergeräten).
• Ad-Hoc-Tests und Shorttests ergänzten die Aufgabe.
• Tests wurden von mir auch in Fahrzeugen durchgeführt und im Rahmen des Entwicklungsprozesses permanent wiederholt und überwacht.
• Exkurs: Das MIB ist der Zentralrechner und besteht aus mehreren Komponenten: Radio (Terrestrisch, DAB, Sirius), Sound, DVD, diverse Multimediaschnittstellen, Navigation, Telefon, CAN-Bus-Überwachung, MMI/HMI (Mensch-Maschine-Schnittstelle) und Sprachinterface.

• Konzernweiter ODX Benutzersupport
• Entwicklung von Setup-Systemen (konzernweit)
• Erstellung von Software-Testspezifikation
• Softwareentwicklung in Java und C++

Details:

• Die Diagnoseabteilung von Volkswagen benutzte eine Vielzahl von Tools, je nach Verantwortlichkeiten.
• Aufgrund der schnellen Innovationswechsel war es notwendig geworden, eigene Software zu entwickeln, die die Inhalte der Diagnosevorgaben schnell in eine präsentierbare und besprechungsgeeignete Form darstellte. Konkret wurde Information aus ODX-XML-Dateien extrahiert und in PDF- und Excelformate aufbereitet.
• Eine weitere Entwicklung von mir stellte der ODX-Toolmanager dar. Anstelle externer Konvertierungstools einzeln zu verwenden, wurden diese in eine GUI zusammengefasst und von dem Toolmanager nach vorgegebenen Schritten verwendet. Neben der einfacheren Verwendung vermied man somit versionsbedingte Inkompatibilitäten der externen Tools.
• ODX ist ein weltweiter Diagnosestandard, der einfach gesagt die Diagnoseeigenschaften von Steuergeräten definiert. Jede Software kann so mit jedem Gerät kommunizieren, wenn sie sich der speziellen Information aus den ODX-Daten für das Steuergerät bedient.
• Genau letzteres macht der VAS-Tester, eine Software, die in den VAG-Werkstätten benutzt wird um Fehler im Fahrzeug zu lokalisieren. Um den ODX-Datenstand in dem VAS-Tester auf den aktuellen Stand zu halten, entwickelte ich ein Setupprogramm (Installshield), mit welchem die Aktualisierungen automatisiert erfolgten. Angewendet von der Technischen Entwicklung und dem Kundendienst von VW.
• Als weitere Aufgabe übertrug man mir das Testen von Software externer Zulieferer und teilweise den ODX Benutzersupport.

• Entwicklung von Analysen- und Kontrollverfahren mit CANalyser und CANape
• Durchführen von System-Integrations-Tests am HiL-Tester
• Entwicklungen mit Tasking Compiler, flashen.

Details:

• Johnson Controls entwickelte für Daimler eine Steuergerätesoftware für Hybridbatterien. Die Produktion der Batterie erfolgte ebenfalls bei Johnson Controls im ehemaligen VARTA-Batteriewerk in Hannover.
• Die von mir an einem HiL-Tester getestete Steuergerätesoftware wurde von Kollegen mit Matlab-Simulink/Targetlink, modelbasierend, erstellt. Ich kompilierte diese mit dem Tasking-Compiler und flashte sie auf das Steuergerät am HiL-Tester.
• Gemäß der von mir erstellten Testspezifikation erfolgten sowohl komplette als auch komponentenspezifische Tests mit anschließender Dokumentation. Basis bildete das Lastenheft für Hybridbatterien von der Daimler AG.
• Besonderes Augenmerk wurde auf die Sicherheitsanforderungen gelegt. Die Batterie stellte ca. 30 KW zur Verfügung, und das innerhalb von Millisekunden. Besondere Sorgfalt beim Testen der Software Funktionalitäten war gefordert und begründete den von mir ergänzend durchgeführte Test des vom Compiler erzeugten C-Codes.
• Als Analysetools verwendete ich CANalyser und CANape, aber auch speziell von Zulieferern erstellte Flashsoftware.

• Weiterentwicklung der Diagnosesoftware PanaDiag hierfür.
• Durchführen von Tests gemäß Spezifikation.
• Diagnosetests über KWP2000

Details:

• Panasonic entwickelte ein RG3 für Audi, das sogenannte Radio der dritten Generation und das UltraLow, ein abgespecktes Standard Radio für VW.

Meine Aufgabe

• bestand zuerst darin, Tests an einem HiL-Tester durchzuführen. Beim RG3 enthielt die Testspezifikation ca. 800 Testfälle, die abgearbeitet werden mussten. Für das UltraLow-Radio erstellte ich daraus eine angepasste Variante mit ca. 500 Testfällen.
• Als Testkomponenten standen mir u.a. eine Relaisbox, die Restbussimulation und ein Signalgenerator zur Verfügung. Mit der Relaisbox konnten Zustände wie Lautsprecherkurzschlüsse, Unterbrechungen, Überlastungen etc. simuliert werden.
• Die weiterführende Aufgabe war es, die Tests zu automatisieren. Hierzu entwickelte ich ein VB-Programm unter Excel, welches aus den Testfällen heraus und über die serielle Schnittstelle die Relaisbox ansteuern konnte. Die Restbussimulation lieferte die Diagnosefehler, welche als Ergebnis in das Testprotokoll in Excel geschrieben wurde.

• Weiterentwicklung der Diagnosesoftware (DiagTest) für Steuergeräte.
• Die Software testet Steuergeräte nach KWP2000 mit spezifizierbaren Parametern und wertet die Ergebnisse aus.

• Entwickelt wird ein Datenmanagementtool (ADM), welches beliebige Applikationen verschiedenster Varianten integrieren kann.
• Es dient zur Optimierung und Automatisierung von Prozessketten als ganzheitliches Konzept im Rahmen der VR-Aktivitäten von VW.

• Pflege der Internetpräsentationen
• Client-Server Applikationen
• Aufbau des bundesweiten Intranets der Rücker AG