Sascha Schäfer, Home

Dr.-Ing. Sascha Schäfer

Arbeitsgebiet(e)

  • Sensorminimale Diagnose für ein Brennstoffzellensystem

zur Liste

Forschung

Im Rahmen meiner Forschungstätigkeit beschäftige ich mich mit dem Thema “Sensorminimale Diagnose für ein Brennstoffzellensystem”.

Das Forschungsprojekt wird in Zusammenarbeit mit der Adam Opel AG durchgeführt.

Im Zuge der Entwicklung von Brennstoffzellensystemen als Fahrzeugantrieb vom Einsatz in Prototypen in Richtung Serienfertigung, ist es nötig, den Kostenfaktor noch stärker zu berücksichtigen. Im Bereich der Fahrzeug-Controls bestehen Möglichkeiten zur Einsparung bei der benötigten Sensorik und Aktorik.

Sensoren werden für Regelungszwecke und Diagnosefunktionen verwendet. Diese Diagnosen sind zum einen aufgrund von FMEA-Untersuchungen motiviert, zum anderen dienen sie dem Bauteilschutz und der einfacheren Fehlersuche im Service.

Eine Reduzierung der Sensorzahl kann dazu führen, dass die Regelungsfunktionen zwar noch aufrecht erhalten werden können, aber eine Fehlerdiagnose nicht mehr durchführbar ist.

Durch die Anwendung moderner regelungstechnischer Verfahren soll die Diagnosequalität bei gleichzeitiger Verminderung der Sensorzahl noch verbessert werden. Ziel ist es, durch die Entwicklung eines Diagnosekonzeptes, auch bei minimierter Sensorzahl, relevante Fehler in Sensoren, Aktoren und im Prozess selbst, sicher erkennen und klassifizieren zu können.

Stimulation und Automatisierung sicherheitsrelevanter Softwarefunktionstests

Desweiteren beschäftige ich mich mit dem Thema “Stimulation und Automatisierung sicherheitsrelevanter Softwarefunktionstests”.

Die eingebettete Software zur Regelung und Diagnose komplexer Systeme wird in einem modernen Entwicklungsprozess (z.B. V-Modell) mittels Rapid Prototyping erstellt. Hierbei wird der Code unter Verwendung einer grafischen Programmieroberfläche (z.B. Simulink) erzeugt. Der Code wird dann über einen mehrstufigen Compiler/Linker-Prozess automatisiert in Maschinencode umgesetzt (AutoCode-Generierung).

Zum heutigen Stand kann dabei eine völlige Fehlerfreiheit des Prozesses und der daran beteiligten Hard-/Software nicht garantiert werden. Die Funktionsfähigkeit des Endproduktes muss daher durch Tests nachgewiesen werden. Dies ist insbesondere für die von der Regelungssoftware ausgeführten sicherheitsrelevanten Funktionen unerlässlich. Da solche Tests sowohl die Simulation der Softwarefunktionen, als auch von Fehlern an Komponenten (z.B. Sensoren, Relais) einschließen muss, werden die Tests sehr aufwendig, so dass eine manuelle Durchführung nicht sinnvoll ist. Des weiteren ist eine automatisierte Durchführung auch aus Dokumentations- und Reproduktionsgründen vorzuziehen. Aufgabe des Projekts ist es eine Umgebung zu schaffen, die automatisierte Tests möglich macht und dabei bei der Erzeugung von Testvektoren und der Organisation der Tests unterstützt.

Im Hinblick auf die entstehenden Kosten zur Fehlerbehebung, ist es nahe liegend mit den Tests im Entwicklungsprozess so früh wie möglich zu beginnen und diese in möglichst allen Entwicklungsstufen durchzuführen. Das bedeutet, dass bereits die Spezifikation zu prüfen ist. In diesem Zusammenhang kann die grafisch programmierte Funktion (das Simulink-Modell) als ausführbare Spezifikation bezeichnet werden, und man spricht hier von MIL (Model in the Loop) Tests. Die auf dieser Ebene erzeugten Tests sollen dann ebenso auf SIL (Software in the Loop), PIL (Processor in the Loop) und HIL (Hardware in the Loop) Ebene verwendet werden können. Beim HIL-Ansatz wird die fertige Software auf dem Seriensteuergerät 'in the loop' mit einer Simulation des Prozesses getestet, d.h. dass auch Fehler in dem Compiler/Linker-Prozess erkannt werden können.