• 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)

• 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

Systementwurf, Entwicklung, der Kommunikationsschnittstelle zwischen den diversen eingebauten Drives und dem Library Controller. Die Schnittstelle zum Drive ist dabei Bestandteil des SCSI-Controllers. 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

• 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)

Projekt:

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

Zielplattform:

Arm Cortex M4 (ST S32K-Kxxx), Autosar, kundenspezifisches PCB mit kundenspezifischer Peripherie (Motoren, Sensoren, Buttons, Smart-LED-Display, etc.) zum eigentlichen Mikro-Controller.

Aufgaben

• 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

Projekt:

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

Zielplattform:

Windows 10

Aufgaben

• 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