• Erfassung des Ist-Zustands, der Änderungswünsche und der daraus resultierenden Requirements.
• Projektplanung und -kontrolle.
• Kommunikation mit dem Kunden.
• Mitarbeit an Teilen (Agenten und Micro-Services in Java) des Back-Ends.
• Erstellung eines Teils der Internet-Seiten in HTML, JavaScript und CSS.
• Testen der Web-GUI und der Schnittstellen zu ELO und Majesty.
• Testen der Schnittstellen von und zu Drittfirmen.
• Weiteres nach Bedarf?
• Dokumentation des Front- und Back-End.

Pflege, Wartung und Erweiterung der Funktionsendprüfsoftware für das gesamte Typen- und Variantenspektrum im Bereich Satellitentechnik.

• Fehlerbehebung in bestehenden Modulen
• Anpassung und Testen von Stored Procedures in der Datenbank
• Optimierung (Ergonomie, Zeitverhalten, Fehlerrobustheit) bestehender Module
• Entwicklung von neuen Modulen
• Testen und Debuggen der Module direkt am Prüfling
• Dokumentation (Inline-Kommentare)
• Beratung hinsichtlich der Einführung eines Versionsverwaltungssystems

• Implementierung der Schnittstelle für folgende Drive-Typen:
  • Sony AIT-2- und AIT-3-Drive
  • Seagate Viper 200 Drive
  • Quantum SDLT 320 Drive
  • HP Ultrium Gen II Drive
  • Exabyte VXA Gen II Drive
• Bestandsaufnahme/Anforderungsanalyse, Mitwirkung bei der Entwicklung der Architektur
• Erarbeitung des Designs und der notwendigen Designdokumente
• Realisierung der seriellen Schnittstelle für Projekt Sony unter C
• Inbetriebnahme und Systemtest alle angeführten Projekte
• Dokumentation (Systemdokumentation, Release Notes)

• Grundkurs: ?Objektorientierte Programmierung mit C++?, 12 Abende, 2 Semester pro Jahr

• Bestandsaufnahme/Anforderungsanalyse
• Entwicklung der Testpläne und Testanweisungen für die Firmware der Projekte ThinStor (Saturn, Paris, Scooter, ThickCrust, Hawaii, Texas, Colorado) und Zodiac in den Entwicklungsphasen EVT und DVT, sowie die Produktphase PVT
• Überwachung der Gesamttests und teilweise Durchführung der Firmware-Tests für Projekt Zodiac am Ende der DVT-Phase
• Durchführung der Tests für alle genannten Projekte in den Phasen EVT, DVT und im Einzelfall auch PVT
• Entwicklung und Aufbau von geeigneten Hilfsmitteln (Sonderanfertigunden von Adaptern und Platinen) für den Test
• Englischsprachige Kommunikation mit den Endkunden in USA und im Hause BDT (letzteres im Fall von Präsentationen von Produkten und Lösungen)
• Mitarbeit und Beratung bei der Entwicklung von Lösungsansätzen bei auftretenden Problemen
• Dokumentation (Testreports) 
• Support und Schulung der Mitarbeiter

Portierung und Erweiterung des Library-Controllers vom Z80- Prozessor auf den ARM-Prozessor unter Einsatz des Betriebssystems Nucleus+. Library- und Robotik-Controller werden dabei zu einer Einheit zusammengefasst

• Bestandsaufnahme/Anforderungsanalyse, Mitwirkung bei der Entwicklung der Architektur
• Erarbeitung des Designs und der notwendigen Designdokumente
• Realisierung eines allgemeinen Debug-Monitors und dessen Schnittstellen (Terminal, telnet, Web) nach außen unter C.
• Realisierung der seriellen Kommunikation diverser Drives.
• Realisierung Teile des Library-Controllers
• Inbetriebnahme und Systemtest alle angeführten Projekte
• Dokumentation (Systemdokumentation, Release Notes)

Konzipierung und Realisierung eines Prüfprogramms auf Basis eines in Komponententechnologie (ActiveX, COM) entwickelten Prüfrahmens (Prüfsystem NT) zur Endprüfung diverser Fahrerarbeitsplätze (Linienbusse) und Meß- Steuer- und Kontrollsysteme in Fahrzeugen.

• Bestandsaufnahme/Anforderungsanalyse, Konzepterstellung und Vereinbarung des Pflichtenhefts
• Erarbeitung des Designs und der notwendigen Designdokumente
• Realisierung der Teilmodule
• Weiterentwicklung Prüfprogramme gemäß neu hinzukommender Produkte und Kunden
• Dokumentation (Feinspezifikation, Systemdokumentation, Benutzer-Handbuch)
• Support und Schulung der Mitarbeiter

• Entwicklung der Firmware für das Produkt RAPID-6. Hauptbe-standteil war die Ansteuerung eines Schrittmotors, der über PWM und einen TI-Treiber gefahren wird, wobei noch zwei über einen dreistufigen Wipp-Schalter (1-0-2) umschaltbare Betriebsarten implementiert wurden. Zusätzlich kann über einen DIP-Schalter noch (unabhängig von der gewählten Betriebsart) ein Potentiometer für die Drehzahlreglung über AD-Wandler zugeschaltet werden. Eine LED zeigt dabei stets an, ob das Gerät gerade aktiv oder ausgeschaltet ist. Betriebsart 2 (Automatik) schaltet das Gerät von Betriebsart 1 (Dauer) in einen zyklischen Modus, bei dem der Motor immer eine Stunde läuft und dann drei Stunden Pause folgen. Danach beginnt der Zyklus von vorne.
• Zielplattform: Embedded Firmware auf einem PIC-Prozessor ohne Betriebssystem.
  • Einarbeitung in das Produkt und dessen Bestandteile (Prozessor dsPIC33CK256MP505, Motortreiber DRV8436RGER, etc.)
  • Ermittlung und Einrichtung der notwendigen Microchip-Entwicklungsumgebung.
  • Konfiguration des Boards (GPIO, ADC, Timer, etc.) über MCC
  • Implementierung der spezifizierten Funktionalitäten.
  • ?Test und Dokumentation (nur im Quell-Code).

• Einarbeitung in das Produkt und die Entwicklungsumgebung.
• Fuzzy-Suche: Suche nach einer geeigneten Lösung für eine Fuzzy-Suche für die vom OCR-Scan-System gelieferten Text-Ergebnisse. Dabei fiel die Wahl aufgrund der sehr guten Kombination von Geschwindigkeit, Flexibilität und dem sparsamen Umgang mit den Ressourcen auf meilisearch. Es wurde eine Vorfilterung/Plausibilitätsprüfung eingebaut, die es erlaubt, mit herstellerspezifischen Parameterprofilen nach der Reihenfolge der diesen Profilen zugeordneten Prioritäten auf die jeweiligen Nummernkreise der Hersteller optimal einzugehen und so die Suche zu beschleunigen und zugleich die Qualität der ?Matches? zu verbessern. Meilisearch liest dazu einmalig (und bei Änderung) die vorhandene sqlite-Datenbank ein und indiziert die darin gespeicherten ca. 560000 Artikelnummern. Zusätzlich zur Berücksichtigung herstellerspezifischer Eigenheiten bei den Nummern wird noch auf die Verwechselbarkeit diverser Zeichen-Paare, speziell bei OCR, eingegangen.
• Erweiterung der vorhandenen Worker und Helper zum Scannen von Datamatrix-Codes um einen weiteren, der es erlaubt QR-Codes und lineare Barcodes zu erkennen. Ziel ist es hier, die IDs von Mitarbeitern und von Instrumenten-Charges, die in sogenannten Körben zur Reinigung und Neukommissionierung in die Lagerschränke angeliefert wer-den zu erfassen. Zu Beginn der Arbeit wird dabei die ID des Mitarbeiters erfasst und bei Start der Bearbeitung eines Korbinhalts wird dazu der auf dem Korb befindliche Barcode gescannt.
• Erweiterung um einen weiteren Worker/Helper zum parallelen permanenten Scannen (?Direct Scan?) innerhalb eines frei definierbaren rechteckigen Bereichs im Kamerasichtfeld. Dieses feste und ?dumme? Scannen, vorbei an der Objekterkennung, geschieht typischer Weise alle 1 ? 4 Sekunden und i. d. R. bildmittig und eher am unteren Bildrand. Für die Umsetzung werden vom bereits vorhandenen Camera-Worker die eingehenden Frames einfach kopiert und auf den definierten Ausschnitt zurecht geschnitten, dann noch in Graustufen umgerechnet und mit einer festen Objekt-ID versehen in dieselbe Queue geschickt, in die auch die Objekterkennung ihrerseits die ermittelten Objekt-Frames schickt. Damit das alles auch ?seamless?, als gleich wie die bestehenden Funktionen lief, bedurfte es einiger Anpassungen im gRPC-System und im GUI-Teil (Dart). Um ?Dauerfeuer? mit derselben Artikel-Nummer zu vermeiden wurde noch eine konfigurierbare artikelnummernspezifische zeitlich Entprellung eingebaut.
• Probehalber Einbau des Software-Tokens SoftHSM auf einem Gerät, um den Weg für die Einbindung des bereits verbauten Secure Elements (Microchip ATTEC608C) zu ebnen. Nach ein bis zwei Tagen war das Software-Token einsatzbereit und es konnten z. B. Dateien damit verschlüsselt werden.
• Einbindung des verbauten Hardware-Secure-Elements Microchip ATTEC608C. Ziel war es den Chip so weit zu konfigurieren, dass er mit dem hauseigenen Connect-Service zusammenarbeitet, also aus dessen Sicht wie ein fertiges Token (pkcs11-Provider/TPM) arbeitet. Da sich im Hause niemand wirklich mit den Chips auskannte und man eigentlich davon ausging, dass sie bereits einem solchen Provider gleichkommen würden, war hier sehr viel Recherche und Testen notwendig. Am Ende stellte sich heraus, dass die Chips alles andere als fertige pkcs11-Provider darstellen und dass darüber hinaus bereits von Microchip fertig vorprovisionierte Chips bestellt und eingebaut wurden. Mit diesen war es also unmöglich, eigene Zertifikate aufzuspielen und die Konfiguration der Slots nach eigenen Wünschen zu gestalten. Während der Tests stellte ich auch fest, dass die libcryptoauth. so, mit der auf die Funktionen des Chips zugegriffen wird, nicht nur deshalb immer Fehler lieferte, weil der Chip bereits ?locked? war, sondern dass dar-über hinaus auch intern mit relativen Pfaden gearbeitet wurde, wo dies einfach nicht korrekt war (etc/.. und var/..). Der Build-Prozess war dann auch noch so konfiguriert, dass wichtige API-Funktionen gar nicht vorhanden oder nur mit Dummy-Funktionen hinterlegt waren bzw. auf das Standardinterface umgeleitet wurden. Im Ergebnis musste ich die Library patchen und den Build-Prozess anpassen. Das Projekt ist hier jetzt auf einem Stand, auf dem es funktionieren müsste. Die für das Testen, Auslesen und die Beschreibung der Config-Area notwendigen Skripte sind alle vorhanden und tun das Richtige, sofern es nicht durch den Chip selbst blockiert wird.
• Weiter kam ich leider nicht mehr, weil es an dieser Stelle ein vorläufigen Halt bei der Weiterentwicklung neuer Features gab.
• Parallel zur Einbindung des ATTEC608C sollte ich auch noch nach möglichen Alternativen auf dem Markt Ausschau halten und für die in die engere Wahl kommenden Kandidaten eine vergleichende Bewertung erstellen. Als geeignetsten Kandidaten stellte sich dabei der Infineon SLB9673 heraus. Dieser wäre auch ein bereits fertig konfigurierbares TPM gewesen. Die übrigen Kandidaten erwiesen sich als zu unflexible oder auch überhaupt unpassend hinsichtlich der Features und/oder Bauform.
• Test und Dokumentation aller Erweiterungen und Nachforschungen.

• Embedded Firmware ohne Betriebssystem
  • Einarbeitung in das Produkt und dessen Firmware (C-Code und funktionale Bedienung)
  • Identifizierung der für die Änderung notwendigen Stellen im Code
  • Implementierung der Erweiterung
  • Test und Dokumentation (nur im Quell-Code)

• Einarbeitung in die Geheimhaltung und die damit verbundenen Protokolle
• Einarbeitung in das Kommunikationssystem selbst (aus Systemsicht).
• Einarbeitung in das vom Auftraggeber-Konsortium vorgegebenen Test-Bett.
• Mitarbeit an der Erstellung der Testdokumentation, welche an den Auftraggeber auszuliefern ist. Tools: Visual Studio 2022 (C#), MySQL, XML, Altova StyleVision und Migra-Doc PDFSharp
• Erstellung automatisierter Tests mit Hilfe von National Instruments Teststand
• Automatischer Import der Testergebnisse manueller Tests in die MySQL-Datenbank
• Evaluierung zweier unterschiedlicher Import-Tools für die manuellen Tests (Teststand vs. Excel)
• Erstellung eines Konverters mit GUI, der die XML-Ausgabedatei des Kommunikationssystems einliest und daraus ebenfalls eine XML-Datei erstellt, welche Informationen für die eigentlichen automatisierten Tests enthält (Datenbeschreibungen und Kommandobeschreibungen). Dieser Konverter wurde in Python erstellt.
• Dokumentation der Konverter-Software (Inline-Kommentare und User?s Guide in MS-Word)

• Embedded Micro-Controller unter Windows CE 2009
  • Einarbeitung in das Build-System und die Tool-Chain
  • Einarbeitung in die bisherige Applikation und deren grundlegende Architektur
  • Einarbeitung in die cloud-basierte fiskaly SignDE API und die dafür benötigten Libaries für die verwendeten Schnittstellen (JSON und XML)
  • Erarbeitung einer Architektur (Grob- und Feinspezifikation) gemäß der üblichen Architektur, bei der jedes Kassensystem über zwei Ebenen/DLLs eingebunden wird. Die oberste Ebene/DLL beinhaltet dabei die mehr oder weniger immer gleich aussehende Logik hin zu den oberen Applikationsschichten, während die untere Ebene/DLL eine Art Abstraktion hin zur eigentlichen TSE, dem Abrechnungs- und Buchungssystem darstellt. Der Verbund dieser beiden DLLs wird aus Anwendungssicht Fiskaldrucker genannt.
  • Erstellen dieser beiden DLLs unter Anpassung der Ablauflogik auf der oberen Ebene an die fiskaly API. Erstellen der Kommunikationsschicht (untere DLL) für das Senden von Requests und den Empfang der entsprechenden Server-Antworten dazu. Dabei wurde eine Fehlerbehandlung von Kommunikationsfehlern unten, wie auch auf der oberen Ebene eingebaut. Die frühere Hardware-Lösung verlangte an dieser Stelle natürlich teilweise nach anderen Prüfungen und Reaktionen.
  • Erstellen von printf-Debug-Ausgaben, da Debugging bei diesem System anders nicht möglich war.
  • Anpassung weiterer Teile des Gesamtsystems, wie z. B. DB-Einträge, neue globale Variablen und Strukturen, teils konstant, teils nur lesbar, etc. Einbindung des neuen Fiskaldruckers an verschiedenen zentralen Stellen der Software, um z. B. Status- und Einstellungsseiten korrekt funktionieren lassen zu können.
  • Test des Gesamtsystems am lebenden Objekt
  • Dokumentation der Software (Inline-Kommentare)

• Einarbeitung in das Build-System und die Tool-Chain.
• Einarbeitung in die LIN-APP
• Teile der bestehenden Software LIN-APP waren zu groß, die Metriken wurden nicht eingehalten. Folglich sollten diese Teile weiter unterteilt und dabei gleichzeitig die Gesamtarchitektur klarer strukturiert und besser nach Aufgaben unterteilt werden. Dies sollte zunächst als Grobspezifikation erstellt werden.
• Anpassen des in C geschriebenen Quell-Code an die neue Einteilung der LIN-APP.
• Validieren der Änderungen mittels eines kundenspezifischen Test-Tools für den LIN-Bus.
• Anpassung des Detailed-Design der LIN-APP in CodeBeamer.
• Nach Einführung der Axivion Suite als neues Tool zur statischen Analyse des Codes, mussten im Anschluss an die Anpassung der Architektur dann noch einzelne Module und Funktionen, den gefundenen Regel-Verletzungen entsprechen geändert werden. Auch danach war natürlich wieder eine Validierung der durchgeführten Änderungen mit-tels des LIN-Test-Tools, sowie die Anpassung des Detailed-Design in CodeBeamer notwendig.
• Dokumentation der Software (Inline-Kommentare).

• Embedded Linux
• Abarbeitung der Tickets (Aufgaben, User-Stories und Bug-Reports) in Azure Devops.
• Erstellung neuer Funktionen/Erweiterung von Funktionen, aus GUI-Sicht, teils bis hinunter ins Betriebssystem, wo dann der Kommunikationspartner im Backend z. B. Linux-Shell-Skripte waren, die als Service liefen.
• Auffinden der Ursachen für gefundene Fehler, sowie deren Behebung.
• Testen der gemachten Änderungen in der Simulation und auf der Original-Hardware.
• Drei Male pro Woche Online-Abstimmungen.
• Einmal alle drei Wochen Sprint-Demo und Sprint-Planung.

Erstellung eines Grob- und Feinkonzepts für die Embedded Software ICS (Interactive Charging Port). Hierbei handelt es sich um ein Innovationsprojekt.

• Arm Cortex M4 (ST S32K-Kxxx), Autosar, kundenspezifisches PCB mit kundenspezifischer Peripherie (Motoren, Sensoren, Buttons, Smart-LED-Display, etc.) zum eigentlichen Mikro-Controller.
  • Erstellung eines Grobkonzepts (gewählte Sprache: UML) der Software-Architektur auf Basis der vorhandenen Primary Features und Use Cases.
  • Erstellung eines Feinkonzepts (gewählte Sprache: UML) der Software-Architektur auf Basis der vorhandenen Primary Features und Use Cases
  • Wöchentliche Online-Abstimmungen

Testautomatisierung für das Mehrwertmodul (MWM) des SmartMeter-Gateway CONEXA

• Einarbeitung in das Produkt und die Testumgebung (proprietäre Tools, Postman, XMind). Mitarbeit beim Testkonzept.
• Spezifikation neuer Testfälle, Review bestehender Testfälle in XMind.
• Implementierung neuer Testfälle in Postman.
• Durchführung und Dokumentation der Testfälle mit Postman.

Zielplattform:

Windows 10

Aufgaben

• Einarbeitung in das Produkt und die Testumgebung (proprietäre Tools, NUNIT, Postman).  Einarbeitung in diverse Protokollschichten (TLS, HDLC, SML, WMBUS)

• Spezifikation neuer Testfälle, Review bestehender Testfälle.

• Implementierung neuer Testfälle in C# mit Hilfe von nunit

• Anpassung der XML-Profile gemäß der Testfall-Spezifkationen.

• Erweiterung bzw. Anpassung der vorhandenen, in C# geschriebenen, Testumgebung inklusive des Simulators für HDLC-Zähler.

• Anpassung des Protokoll-Stacks des Simulators an neue Tarifanwendungsfälle und an ein neues Anwendungsfeld.

• Durchführung und Dokumentation der Testfälle mit Testlink gemäß der Testpläne. 

• Bewertung und Dokumentation der Ergebnisse, ggf. Erstellung von Bug-Tickets. 

• Dokumentation der Software (Inline-Kommentare und Textdokumente)

Zielplattform:

Linux / Embedded Linux

Aufgaben

• Einarbeitung in M-Bus, Modbus

• Portierung der Kommunikation mit den M-Bus-Zählern auf die neue Plattform

• Portierung der Kommunikation mit den Modbus-Zählern auf die neue Plattform 

• Anpassung bzw. Entwicklung der untersten Schichten zur Hardware.

• Anpassung und Erweiterung der Web-GUI (PHP, JavaScript, HTML).

• Gleichzeitige Optimierung der Architektur und Software während der o. g. Arbeiten. 

• Dokumentation selbst entwickelten bzw. angepassten Komponenten.

• Integrationstest aller selbst entwickelten bzw. angepassten Komponenten im Zusammenspiel mit dem Gesamtsystem.

• Dokumentation der Software (Inline-Kommentare und Textdokumente).

Zielplattform:

Windows 7/10

Aufgaben

• Einarbeitung in National Instruments Testlink.

• Spezifikation neuer Testfälle, hauptsächlich für die Produktfamilien Termina, Selekta und Luna

• Implementierung der neuen Testfälle im Editor des NI-Tools Testlink

• Erweiterung bzw. Anpassung der vorhandenen, in C# geschriebenen, Windows-DLL (Layer zwischen der zu prüfenden Kunden-Hardware und Testlink) an die neu hinzugekommenen Produkte und Funktionen.

• Test und Bug-Fixing, sowohl der Testscripte, als auch der DLL-Funktionen.

• Durchführung und Dokumentation der Testfälle mit Testlink gemäß der Testpläne.. 

• Bewertung und Dokumentation der Ergebnisse.

• Dokumentation der Software (Inline-Kommentare und Textdokumente).

Zielplattform:

Windows 7/10

Aufgaben

• Konzipierung einer Windows-GUI-Anwendung für die Ansteuerung und den Test des Produkts theSendaB.

• Entwurf eines SQL-Datenbank-Designs für die o. g. Anwendung.

• Implementierung der o. g. Anwendung unter C# unter Verwendung von WPF.

• Test und Bug-Fixing der fertigen Anwendung.

• Dokumentation der Software (Inline-Kommentare und Textdokumente)

Zielplattform:

Windows 7, Linux (Debian VM unter vmware), Embedded Linux / FAMOS (auf HD62-Targets mit Arm-Quadcore).

Aufgaben

• Einarbeitung in das Build-System und die Tool-Chain.

• Bug-Fixing gemäß vorhandener Tickets.

• Untersuchung der Ursachung für Performance-Probleme unter Verwendung geigneter Tools (top, sysmon).

• Evaluieren und Integrieren (in das Build-System) dieser Tools, sofern noch nicht Bestandteil des Linux-Systems auf dem Target, hier speziell htop, oprofile und perf. Es mussten diverse Libraries, Binaries und andere Dateien nachinstalliert werden, teils manuell, teils über "make menuconfig".

• Durchführen von Testläufen und Durchführen von Profiling-Traces unter bestimmten Bedingungen. Auswerten (z. B. mit Hilfe eines eigens dafür geschriebenen awk-Skripts) und Dokumentieren der Ergebnisse bis hinauf auf C++-Quellcode-Level.

• Bewertung und Dokumentation der Ergebnisse.

• Dokumentation der Software (Inline-Kommentare und Textdokumente).

Kameraanbindung, speziell Video- und CAN-Daten für das Projekt ProViu Mirror, inkl. Movable Object Detection.

• Implementierung der Schnittstellen für Video- und CAN-Daten, wie sie von der Videoprozessierungssoftware der IGD vom fraunhofer-Institut geliefert wurden. Das Projekt wurde als „Continuous Integration“-Prozess durchgeführt.
• Test der Software.
• Konvertieren vorhandener Videodateien in ein für IGD passendes Format (zu Testzwecken). Hierzu kam g-streamer (gst-launch-1.0) zum Einsatz. Bei den Videos wurden folgende Parameter geändert: Auflösung, Aspektverhältnis, Farbformat und der Datei Container (Ziel: MKV)
• Mitwirkung bei der Durchführung diverser Testfahrten imt dem LKW zur Verifizierung des von IGD entwickelten Algorithmus für die Erkennung von statischen und beweglichen Objekten
• Sichtung des Videomaterials, Auswertung der Testreihen inkl. Dokumentation.
• Suche nach Fehlern in der Software, die sporadisch zu Abstürzen führten.
• Dokumentation der Software und der Einrichtung der Entwicklungsumgebung (Inline Kommentare und Textdokumente).

Arbeitsplattform:

Windows 7 unter Cypress EZ USB Suite / SDK.

Zielplattform:

Proprietär CYUSB3KIT-003.

Aufgaben

• Integration / Implementierung der Anbindung des Cypress USB-Boards (CYUSB3KIT003) an einen OmniVision Kamera-Sensor (OV490) über ein zwischengeschaltetes TI Serializer-/Deserialiter-Board (SV600905).

• Programmierung einer steuerbaren PWM über GPIO-50.

• Programmierung der Set- und Get-Funktionen für den Zugriff auf Register über I²C. - 

• Programmierung der Host-Call-Funktionen zum Setzen und Lesen der Register des Kamera-Sensors über I²C.

• Initialisierung des TI-Boards über I²C.

• Initialisierung des Kamera-Sensors über I²C.

• Erstellung diverser Testfunktionen zum Zweck der Integration.

• Test der Software.

• Code-Review zusammen mit einem weiteren Mitarbeiter.

• Einweisung zweier Mitarbeiter (Projektübergabe).

• Dokumentation (Inline-Kommentare und Text-Dokumente).

Projekt:

Weiterentwicklung eines hauseigenen, Excel-basierenden Testsystems für Embedded-Linux-Targets und Integration mit dem mvTAFTestsystem von MontaVista und den Ferret-Testservern von Mentor Graphics.

Zielplattform:

Windows 7, Linux (Ubuntu), Embedded Linux (Targets).

Aufgaben ? eher allgemeiner Natur, im Test:

• Durchspielen und Validierung einer Setup- und Build-Anleitung für das Root-File-System eines bestimmten Targets.

• Mitwirkung an der Optimierung, Erweiterung und Kategorisierung neuer TestRequirements und Test-Cases.

• Untersuchung der bestehenden Testsysteme und Erarbeiten einer geeigneten Architektur für deren möglichst einfache und effiziente Integration in den ?Continuous Integration?-Prozess, welcher für alle Projekte angewandt wurde.

• Untersuchung der neu importierten Test-Cases auf mehreren Targets mit unterschiedlicher Architektur und (der Versuch der) Auswahl geeigneter Test-Suites als Standardtests. Hierbei stellte es sich heraus, dass dies nicht so einfach umgesetzt werden kann und praktisch bei jedem Projekt neu durchgeführt werden muss. Das Linux Test Project (ltp) lässt sich noch am allgemeinsten einsetzen

Aufgaben (Implementierung, hauptsächlich in VBA umgesetzt):

• Anpassung und Erweiterung des hauseigenen internen Testsystems, basierend auf einem Testplan in Form einer Excel-Tabelle und darin eingebetteter VBA-Makros. Über bestimmte Spalten vorselektierbare Test-Cases werden dabei in eine CSV-Datei exportiert und diese im Anschluss dann mit WinSCP auf das betreffende Target hochgeladen, wo dann die Tests mit Hilfe des eigenen Test-Runners durchgeführt werden. Die eigentlichen Testfunktionen liegen in Form von Shell-Skripten und Binaries bereits auf dem Target vor. Die Ergebnisse sind am Ende wieder in einer CSV-Datei, und werden vom Target heruntergeladen und in das Excel-Arbeitsblatt importiert. Diese herkömmliche Test-Methode sollte erhalten bleiben und verbessert werden. Es findet jetzt ein Tracking der Test-Cases selbst, sowie der Testläufe in einer MySQLDatenbank statt. Darüber hinaus wurde die Performance verbessert und es können nun keine Dubletten (Test-Case-IDs) mehr vorkommen. Externe Shell-Skripte wurden integriert und sind damit überflüssig geworden.

• Integration der bei Mentor Graphics bereits vorhandenen Tests, welche durch die Übernahme von XSe durch Mentor Graphics nun zusätzlich verfügbar wurden. Diese Tests wurden für das mvTAF-Testsystem von MontaVista erstellt. mvTAF ist komplett in Python entwickelt und bildet eine mächtige Engine um definierte Test-Suiten (bestehend aus Test-Units, bestehend aus Test-Cases) auf quasi beliebigen Targets ablaufen zu lassen und die Ergebnisse am Ende einzusammeln. Da das eigentliche ?RunCommand? frei definierbar ist, kann es sich bei der ausgeführten Testfunktion wiederum um Pythonoder Shell-Skripte oder auch native Binaries handeln. Sowohl für Konfiguration von mvTAF selbst, als auch für die Definition von Test-Cases, Test-Units und Test-Suites werden XML-Dateien verwendet. Auch die Test-Ergebnisse kommen am Ende als XMLDatei zurück.

Für die Integration wurden ganz grob folgende Funktionen erstellt:

• Automatischer Start und Import der Ergebnisse der bisher bereits vorhandenen TestCases (herkömmliches Test-Runner-System). Hierbei müssen aus Excel heraus entsprechende Python- und XML-Skripte generiert werden und mittels WinSCP auf den sogenannten mvTAF-Host (Linux-Rechner, auch als VM) geladen werden, um sodann den Test ebenfalls mittels WinSCP anzustoßen und nach dessen Beendigung dann die Resultate wieder herunterzuladen und nach Excel zu importieren. Im Hintergrund sorgt der mvTAF-Host dafür, dass die gewünschten Test-Suites auf die zu testenden Targets hochgeladen und dort ausgeführt werden und dass die Resultate am Ende an zentraler Stelle für den Download verfügbar sind.

• Import aller bei Mentor Graphics vorhandenen Test-Cases und Test-Units in den ExcelTestplan. Hierzu mussten alle Verzeichnisse des Test-Repositories gescannt und nach eben diesen Elementen gesucht und die gewünschten Informationen daraus nach Excel importiert werden. Importiert wurden dabei mehr als 7200 Test-Cases, darunter etwa 1200 alleine vom Linux Test Project (ltp).

• Auto Automatischer Start und Import der Ergebnisse der auf diese Weise importierten Test-Cases (mvTAF Test-System). Hierbei müssen aus Excel heraus entsprechende XML-Skripte generiert bzw. Werte darin angepasst werden und mittels WinSCP auf den sogenannten mvTAF-Host geladen werden, um sodann den Test ebenfalls mittels WinSCP anzustoßen und nach dessen Beendigung dann die Resultate wieder herunterzuladen und nach Excel zu importieren. Im Hintergrund sorgt der mvTAF-Host (LinuxRechner als VM) dafür, dass die gewünschten Test-Suites auf die zu testenden Targets hochgeladen und dort ausgeführt werden und dass die Resultate am Ende an zentraler Stelle für den Download verfügbar sind.

• Da es jetzt zwei verschiedene Test-Gruppen (herkömmliche interne Test-Cases und die von Mentor importierten) und bei der ersten der beiden zwei Untermodi (herkömmlicher Test-Runner und mit mvTAF) gibt, wurde hierfür ein Start- und Auswahldialog erstellt, welcher beim Klicken auf den Startbutton erscheint und dem Benutzer ermöglicht, die entsprechenden Einstellungen vorzunehmen, um den Test dann anschließend zu starten. Über die Config-Seite (s. u.) kann noch ausgewählt werden, ob die Auswahl der auszuführenden Test-Cases per Test-Case oder per Test-Suite erfolgen soll.

• Bis dato benötigte externe Windows-Shell-Skripte wurden eliminiert und durch direkte WinSCP-Calls aus VBA heraus ersetzt -> Die Excel-Datei funktioniert jetzt praktisch autark. Das Excel-Arbeitsbuch wurde um eine Config-Seite ergänzt, in der sich die neuen Funktionen konfigurieren lassen. Dort werden u. a. auch die IP-Adresse bzw. der DNSName, sowie die Login-Daten und der SSH-Key für den mvTAF-Host und das Target hinterlegt UND im Fall der Kennwörter verschlüsselt. Weitere Properties bestimmen das Detailverhalten des Gesamtsystems. Für diese Properties gibt es eine Reihe von setzbaren Eigenschaften, wie z. B. Default, MustExist, EmptyAllowed und es findet bei jeder Änderung eine Validierung statt. Durch die Standardisierung können neue Properties sehr schnell hinzugefügt und bestehende in ihrem Verhalten verändert oder gelöscht werden. ? Alle im Excel-Arbeitsbuch vorhandenen Test-Cases werden vor dem Start jedes Testlaufs und bei jedem Speichern validiert und auch auf Dubletten bei den Test-Case-IDs hin überprüft. Wird ein Fehler gefunden, erscheint eine entsprechende Meldung und das Speichern wird verhindert ? so lange bis der Fehler behoben ist. Auf diese Weise bleibt die Eindeutigkeit und die Integrität der Test-Cases erhalten ? auch bei umfangreichen Imports.

• Beim Start jedes Testlaufs finden eine Reihe von Überprüfungen beim Testsystem selbst statt. mvTAF-Host und das Target werden angepingt und es wird geprüft, ob der mvTAF-Daemon auf beiden läuft. Tritt ein Fehler auf, dann wird dieser angezeigt und der Test nicht gestartet.

• Für jeden Testlauf werden (per Default) detaillierte Trace-Ausgaben in eine ASCII-Datei geschrieben. Deren Namen setzt sich aus dem Basisnamen der Excel-Datei selbst und einem Zeitstempel zusammen. Aktionen außerhalb von Testläufen werden in eine standardisierte Log-Datei mit stets gleichem Namen geschrieben.

• Dokumentation (Inline-Kommentare, PowerPoint-Dokument, Visio-Dokument)

Zielplattform:

Linux (Ubuntu).

Aufgaben:

• Entwicklung der Basisfunktionalität des Testclients nach Grobspezifikation: Der Testclient wartet auf den Anstoß seitens des Testservers und lädt sodann eine XML-Datei, in welcher die Parameter für den Testlauf stehen. Einer dieser Parameter ist der Name des Testscripts, welches in Python geschrieben ist. Dieses Script wird vom Testclient geladen und über den Python-Interpreter gestartet. Die Testergebnisse werden nach Beendigung des Testlaufs von Python an den Testclient zurückgeliefert. Hierzu ist es notwendig, daß aus C++ heraus Python-Klassen und -Funktionen verwendet werden können und umgekehrt. Um diese Funktionalität zu erreichen, wurde auf die BoostBibliotheken zurückgegriffen. Die eigentlichen Prüffunktionen sind identisch mit den für InHome selbst verwendeten Funktionen und befinden sich in einer bereits vorhandenen Bibliothek.

• Dokumentation (Inline-Kommentare)

Neuentwicklung des Controllers, hier der Firmware, für die drei Komponenten der InHome-Plattform: Tastenmodul, Videomodul und Audiomodul (Steuereinheit).

• Mitwirkung beim Design des Gesamtsystems, bestehend aus Audiomodul (Steuereinheit), Tastenmodul (Bedienteil) und Videomodul.
• Erstellen eines Lastenheftes für das Tastenmodul und das Videomodul.
• Erstellen der Firmware für das Tastenmodul und das Videomodul.
• Dokumentation (Inline-Kommentare)
• Inbetriebnahme und Test des Gesamtsystems nach Fertigstellung aller Komponenten.
• Support und Schulung eines Mitarbeiters für die weitere Betreuung und Wartung der Software.
• Support bei der Erstellung einer Sonderfirmware für die Inbetriebnahme neuer Displays.

Neuentwicklung des Controllers, hier der Firmware, für die drei Komponenten der InHome-Plattform: Tastenmodul, Videomodul und Audiomodul (Steuereinheit).

Zielplattform:

Arm Cortex M0, Freescale Kinetis-L (KL-14) unter freeRTOS.

Aufgaben:

• Mitwirkung beim Design des Gesamtsystems, bestehend aus Audiomodul (Steuereinheit), Tastenmodul (Bedienteil) und Videomodul.

• Erstellen eines Lastenheftes für das Tastenmodul und das Videomodul.

• Erstellen der Firmware für das Tastenmodul und das Videomodul.

• Dokumentation (Inline-Kommentare)

• Inbetriebnahme und Test des Gesamtsystems nach Fertigstellung aller Komponenten.

• Support und Schulung eines Mitarbeiters für die weitere Betreuung und Wartung der Software.

• Support bei der Erstellung einer Sonderfirmware für die Inbetriebnahme neuer Displays

• Fehlerbehebung im bestehenden Webserver-Modul

• Testen und Debuggen des Moduls unter den bekannten Fehlerbedingungen Dokumentation (Inline-Kommentare)

• Beratung hinsichtlich der Machbarkeit und weiteren Vorgehensweise

ARM unter Nucleus+

• Realisierung eines allgemeinen Debug-Monitors und dessen Schnittstellen (Terminal, telnet, Web) nach außen unter C.
• Realisierung der seriellen Kommunikation diverser Drives.
• Realisierung Teile des Library-Controllers
• Mitarbeit und CE an diversen Teilen des Library-Controllers, u. a. Webserver mit GUI, Datenbank, Robotik, BOST-Routinen, IPv6, SNMP, iSCSI, etc.
• Inbetriebnahme und Systemtest alle angeführten Projekte
• Dokumentation (Systemdokumentation, Release Notes)

• Bestandsaufnahme/ Anforderungsanalyse
• Entwicklung der Testpläne und Testanweisungen für die Firmware der Projekte FlexStor und FlexStor II in den Entwicklungsphasen EVT und DVT, sowie die Produktphase PVT
• Überwachung der Gesamttests und teilweise Durchführung der Firmware-Tests für alle Projekte und Phasen
• Entwicklung und Aufbau von geeigneten Hilfsmitteln (Sonderanfertigungen von Adaptern und Platinen) für den Test
• Englischsprachige Kommunikation mit den Endkunden in USA
• Mitarbeit und Beratung bei der Entwicklung von Lösungsansätzen bei auftretenden Problemen
• Dokumentation (Testreports)
• Support und Schulung der Mitarbeiter