• Clarification of customer requirements
• Driving of customer requirements to L3 SW considering the ADAS process
• Review of derived L3 SW requirements with SW Developers and SW Validation Engineers
• Planning of feature implementation for every release
• Creating of work packages for SW Developers based on L3 requirements considering ADAS process
• Creating of work packages for SW Validation Engineers based on L3 requirements considering ADAS process
• Tracking of the feature implementation for every release incl. regular status reporting to SWPM.

Für das Lenksteuergerät soll die Software-Anforderungen und die Hardware/Software Interface in DOORS erstellt werden.

Die Softwareentwicklung umfasst die Erweiterung und Implementierung des MOST Funktionskatalogs, die MOST-Kommunikation mit der RSE, den Decoder der TMC-Nachrichten und die dafür notwendige Generierung und Auswertung der Komponententests.

Der Schwerpunkt liegt dabei auf der Sicherstellung der Qualitätssicherungsumfänge in der  Entwicklung von Endgeräte-SW für Telematik-Anwendungen und der anschließenden Absicherung der Endgeräte-SW durch Integrationstests und automatische Generierung von grafische Test-Reports und Statistiken durch Perl Skripte und Gnuplot. Der Fokus liegt dabei auf den Endgeräten aus dem Automotive-Bereich zur Navigation und zur Auftragsübermittlung an den LKW-Fahrer.

Das Ziel der XFCD Service ist, dem Kunden Verkehrsinformationen mit deutlich verbesserter Qualität zu liefern. Statt in regelmäßigen Abständen Positionsdaten, an ein Traffic Information Center (TIC) zu senden, welches die Daten sammelt und die Verkehrsinformationsnachrichten generiert, senden die XFCD-Fahrzeuge komplette Verkehrsereignismeldungen an die TIC. Außerdem ist XFCD nicht auf Autobahnen beschränkt, sondern liefert Informationen für das gesamte Straßennetz. Die XFCD Methode spart Kosten der Kommunikation, da Nachrichten nur in relevanten Situationen geschickt werden

Die Aufgabe umfasst:

• Konzeptentwurf
• Erstellung der Machbarkeitsstudie
• Erstellung der Produktspezifikation
• Erstellung des Terminplans
• Abstimmung mit den Lieferanten
• Test und Freigabe

Die Aufgabe umfasst:

• Erstellung der Testspezifikationen.
• Erstellung von Testskripten (4CS, Perl, C++).
• Testdurchführung: Einerseits durch Simulation der HU und Stressen des DUT. Andererseits durch Simulation der Eingabe des Benutzers am Bedienteil des gesamten voll verbauten Systems. Der Test-Ablauf wird durch die Betätigung der Tasten des Bedienteils an der Bedieneroberfläche des Programms bestimmt, das in einer eigens dafür entwickelten Basic ähnlichen Sprache aufzeichnet.
• Verwaltung der automatisch generierten Testberichte und Verfolgung des Fortschritts der Beseitigung eventuell aufgetretener Fehler.
• Definition und Durchführung von Testszenarien für den System- bzw. Stresstest

Die Aufgabe umfasst:

• Entwicklung von Testmodulen in C++, die auf die Ziel-Hardware implementiert wird, um Software-Module der Zielhardware zu stimulieren und testen.
• Erstellung von Testskripten (VBScript, Perl), um die Testmodule über das Netzwerk anzusteuern.
• Verwaltung der automatisch generierten Testberichte und Verfolgung des Fortschritts der Beseitigung der eventuell aufgetretenen Fehler.
• Definition und Durchführung von Testszenarien für den System- bzw. Stresstest

Die Aufgabe umfasst:

• Entwicklung von Teststrategien für Infotainment-Steuergeräte.
• Erstellung von Testskripten und Entwicklung von Testprogrammen mit dem Ziel, die Konformität des Infotainment-Steuergerätes (sowohl auf Netzwerk- als auch auf Applikationsebene) mit dem MOST-Funktionskatalog zu prüfen.
• Verwaltung der automatisch generierten Testberichte und Verfolgung des Fortschritts die der Beseitigung eventuell aufgetretener Fehler.
• Definition und Durchführung von Testszenarien für den System- bzw. Stresstest.
• Erstellung der Dokumentation

Das Client-Programm soll über eine TCP/IP Verbindung die Nachrichten des in einer Ziel-Hardware angesiedelten Servers anzeigen, aufgetretenen Fehler farblich kenntlich machen und Nachrichten aus verschiedenen Quellen synchronisieren. Die Filterfunktionalität sorgt dafür, dass nur bestimmte  Nachrichten angezeigt werden können. Protokollierung der Nachrichten in einer Datei in verschiedenen Formaten soll gewährleistet sein

• Das System soll zyklisch mit veränderter Zünddauer, Startkurven und in unterschiedlichen Abschaltstadien dem Stresstest unterzogen werden. Dabei werden zusätzlich unterschiedliche Startkurven, Batterie-Zustände und Umweltbedingungen simuliert. Die dadurch gewonnenen Daten werden protokolliert und mit einem Software-Tool automatisch ausgewertet und grafisch dargestellt.
• Die Applikationsebene der verschiedenen Komponenten des Systems werden auf ihre MOST Funktionalität und auf ihre Konformität mit dem offiziellen MOST Funktionskatalog geprüft. Als Schwerpunkt soll hier die Navigation (FBlock 0x52) fungieren.
• In einem beliebig aufgebauten Most-Ring wird das Verhalten des NetworkMasters in Echtzeit überwacht. Hierzu wird u. a. geprüft, ob es beim Aufbau des Netzes zu einem Doppeleintrag von FBlockID/InstID in der CentralRegistry kommt. Ferner wird die Einhaltung der Spezifikationsszenarien, Reaktionszeiten und Zeitüberschreitungen überwacht.
• Das Unterspannungsverhalten eines beliebigen MOST Systems soll geprüft und auf die Einhaltung der Spezifikationen getestet werden. Hierzu kommt die „dynamische Startkurve“ zum Einsatz. Ziel ist es, eine beliebige Startkurve zu bestimmen, die das System destabilisiert. Ausgegangen von drei Startkurven (Schnell-, Normal- und Kaltstartkurve) wird das System bei jedem Zyklus abwechselnd mit einer Startkurve gestresst. Zunächst wird die Startkurve inkrementell in der Spannung und/oder Verweildauer der einzelnen Spannungsstufen, unter Einhaltung der vorgegebenen Grenzwerte, verändert und das System damit belastet. Währendessen läuft im Hintergrund die Überwachung des Systems. Sollte dadurch ein Systemfehlverhalten festgestellt bzw. provoziert werden, so kommt ein Verfahren zum Einsatz, bei dem die Zuordnung des Fehlerbildes zu der angewandten Startkurve festgelegt wird.
• Entwicklung eines Tools zur automatischen Auswertung der Rekorderdateien des OptoLyzers. Das Tool kann die Formate OPD und OP2 im online als auch im offline Betrieb bearbeiten. Ferner ist das Tool in der Lage, eine online Synchronisierung der eignen Traces mit dem des OptoLyzers herzustellen.

Für ein Fahrerinformationssystem soll ein Software-Tool entwickelt werden, mit dessen Hilfe die Leistung des Targets bei den verschiedenen Softwareversionen automatisch gemessen, verglichen und protokolliert werden kann. Das Tool besteht aus drei Programmen: Performance Navigator, Performance Tracer und Performance Control. Der Performance Navigator übernimmt die Simulation der Eingabe des Anwenders. Diese Eingabe wird stattdessen aus einer XML-Konfigurationsdatei gelesen, die die Ablaufsteuerung beschreibt. Durch die Instrumentierung des Codes ist es für den Performance Tracer dann möglich, die Timestamps der Traces der vorgegebenen Codestellen zu sammeln und in eine Datei auf dem Target abzulegen. Das Performance Control Programm läuft auf dem PC und hat die Aufgabe, die auf dem Target gespeicherten Daten zu downloaden, zu bearbeiten und auszuwerten und zu präsentieren. Ferner steuert das Performance Control Programm den Messablauf auf dem Target

Für die verschiedensten Komponenten eines Fahrerinformationssystems sollen verschiedene  Testkonzepte und Testabläufe entwickelt werden, die die Leistung und Zuverlässigkeit dieser Komponenten überprüft ( u. a. die serielle Schnittstelle, IrDa , Flash File System, Sound-Treiber ...). Die Testprogramme sollen automatisch ablaufen und die Ergebnisse protokollieren.