Für einen Diagnosetester ändert sich auf den ersten Blick mit Adaptive AUTOSAR nicht viel. Eine D-PDU API wird ein zusätzliches Protokollmodul für Diagnostics over IP (DoIP) besitzen, um mit einer Adaptive AUTOSAR kommunizieren zu können. Weiterhin wird auch noch die UDS- und ISO-Spezifikation um einige neue Fähigkeiten erweitert. Ende 2019 wird die Standardisierung in der ISO abgeschlossen sein. Da bei der Standardisierung Wert auf Evolution und weitgehende Kompatibilität gelegt wurde, gibt es keine tiefgreifenden Änderungen, die hier ein neues Systemdesign in der Diagnose erfordern würden. Es ist zu erwarten, dass diese Änderungen im Laufe des Jahres 2020 in die bereits existierenden off-the-shelf-Tools für Diagnose einfließen werden.

Softwarecluster

Zunächst wird das jeweilige zu diagnostizierende Fahrzeug bei DoiP anhand der Vehicle-Identifikationsnummer (VIN) ausgewählt und dann die Kommunikation mit den einzelnen Steuergeräten über deren Diagnose-Adressen aufgebaut. Eine Herausforderung dabei ist, dass ein adaptives Steuergerät mehrere Diagnose-Adressen gleichzeitig besitzen kann, jeweils eine Diagnose-Adresse pro Softwarecluster (SWC) mit den zugehörigen DiagnosticManager. Ein adaptives Steuergerät besitzt typischerweise dann 5 bis 10 Softwarecluster und damit gleich viele Diagnose-Adressen.

In dem Beispiel in Bild 1 sind zwei (Diagnose-)Anwendungen bei ECAS gegeben. Die Erste fürs Absenken eines Fahrzeuges, um den Einstieg von Fahrgästen zu erleichtern (sog. Kneeling) und die Zweite eine Tiltfunktion zur Überschlagsverhinderung eines Busses. Diese beiden Applikationen müssen nicht gleichzeitig im Software Cluster „ECAS“ aktiv sein. Sie können nach Bedarf dynamisch zur Betriebszeit gestartet und beendet werden.

Applikationen können auch je nach Fahrzeugvariante ganz ein- oder ausgeschaltet sein. Als Beispiel ist im Beispiel ein „Lane Change Assistent“ als kostenpflichtiges Ausstattungsmerkmal dauerhaft deaktiviert oder wird erst im Laufe des Fahrzeuglebens zusätzlich aktiviert. Dies hat zur Folge, dass die Applikationen mit Diagnosefunktionen nicht mehr gleichzeitig vorhanden oder gar dauerhaft im Fahrzeug deaktiviert sind. Ein Tester muss daher mithilfe der VIN die entsprechenden Fahrzeugdaten kennen und verwalten können. Er kann dabei nicht mehr davon ausgehen, dass alle DTC-Informationen der Diagnostic -Manager eines Steuergeräts aktuell oder vorhanden sind.

Für die beiden Softwarecluster, die jeweils ihre eigene Diagnose-Adresse haben, sind entsprechend auch zwei ODX-Datentöpfe notwendig. Im Prinzip ist ein Steuergerät mit Classic AUTOSAR ein Analogon für einen Softwarecluster in Adaptive AUTOSAR. Die Verteilung der Diagnose-Anfragen auf die jeweiligen DiagnosticManager eines Softwareclusters wird durch die AUTOSAR-Umgebung automatisch sicher – gestellt. Insgesamt entsprechen diese Änderungen jedoch mehr einer Evolu tion als einer Revolution.

Interessanter wird es, wenn man die neuen Möglichkeiten eines OnBoard-Diagnosetesters in Verbindung mit einer erweiterten Diagnosefunktionalität im Fahrzeug betrachtet (Bild 2).

OnBoard-Diagnosetester

Heute ist in Classic AUTOSAR eine elektrische Komponentendiagnose üblich. Dabei wird die angeschlossene Hardware zyklisch auf Fehler überprüft und gefundene Fehler im Diagnostics-Management gespeichert. Die bei der Erstellung der Auswirkungsanalyse, also der Failure Mode and Effects Analysis (FMEA), von Fehler einer Komponente festgelegte Fehlerreaktion wird durch das Fehler-Event ausgelöst.

Beispielsweise bei einem „Stuck at High“-Fehler das Öffnen eines Low-Side-Treibers, um einen dauerhaft fehlerhaft bestromten Aktor auf einen zweiten unabhängigen Weg abschalten zu können. Damit ist zunächst das elektrische Problem auf der Komponentenebene abschließend behandelt, mit der Konsequenz, dass eine Schaltfunktion und damit mindestens ein Aktor ausfällt.

Der Ausfall eines Aktors hat natürlich Auswirkungen auf das System, in dem er eingebunden ist. Damit diese Auswirkungen korrekt berücksichtigt werden, gibt es in AUTOSAR das Konzept von Events, mit denen andere Applikationen über aufgetretene Änderungen informiert werden können. Der Ausfall dieser Schaltfunktion hat beispielsweise zur Folge, dass die Funktion „Liftachse senken“ eines Nutzfahrzeugs auf der Systemebene nicht mehr zur Verfügung steht. Auf dieser Ebene erhält die betroffene Funktion dann ebenfalls einen entsprechenden Fehlercode. Die Auswirkungen auf das System, am Beispiel ECAS, wird in der System-FMEA betrachtet und weitere Folgeaktionen per Event ausgelöst, was im ECAS-Beispiel das Sperren der Funktion „Funktionsliftachse heben“ zur Folge hat, um hier eine Reduzierung der zulässigen Zuladung durch das technisch noch mögliche Anheben der Liftachse zu vermeiden.

Der Ausfall der Systemfunktion „Liftachse“ wirkt sich unterschiedlich aufs Fahrzeug aus. Wenn die aktuelle Liftachse abgesenkt bleibt, beeinträchtigt das nur die Systemeigenschaften und führt zu einer schlechteren Lenkbarkeit, einem erhöhtem Kraftstoffverbrauch und Verschleiß der Reifen.

Im Falle des Ausfalls einer gehobenen Liftachse, ist die noch zur Verfügung stehende Nutzlast reduziert, was erhebliche Auswirkungen auf die Verfügbarkeit des Fahrzeugs und evtl. die Notwendigkeit eines OnRoad-Services des Fahrzeugs zur Ladungsreduzierung bedeutet.

Ein OnBoard-Diagnosetester sammelt hier die eintreffenden Fehlerereignisse über DoIP, trifft daraufhin Entscheidungen, wie weiter mit der Situation zu verfahren ist und steht natürlich bei Onoder Off-Road-Services für weitere Analysen zur Verfügung. Der OnBoard- Tester kann hierbei nicht nur auf originäre UDS-Diagnose-Informationen zugreifen, sondern für tiefere Analysen auch selbst als Adaptive-AUTOSAR-Applikation über die ARA::COM-Schnittstelle aktiv auf weiteren Schnittstellen von anderen Applikation zugreifen.

Die zu analysierenden Datenmengen und gegenseitige Abhängigkeiten der Steuergeräte mit ihren Applikationen in der Steuergeräte-Entwicklung steigen und machen damit die Diagnose-Entwicklung komplexer. Die klassische Trennung zwischen Steuergeräte- und (Aftersales)-Diagnose-Entwicklung in der Zukunft muss daher aufgehoben werden, um hier noch effektivere und effizientere Entwicklungen zu ermöglichen.

Diagnose-Tools Mit den Anforderungen an ein Fahrzeug, inklusive der vorgesehenen Variabilität, startet der E/E-Entwicklungsprozess (Bild 3). Stand der Technik ist hier ein Import der Spezifikationsdaten eines Anforderungs-Managementsystems in einem Fahrzeugdateneditor. In diesem Fahrzeugdateneditor wird die Architektur der Steuergeräte weiter spezifiziert und die Kommunikationsanforderungen (klassisch: eine „CAN-Matrix“) definiert. Moderne Tools ermöglichen hier sowohl die AUTOSAR-Daten (DEXT) wie auch die Diagnosedaten (ODX) gemeinsam und gleichzeitig zu spezifizieren und diese in einer gemeinsamen Datenbank zu verwalten.

Es existiert eine weitgehende Überschneidung des Inhalts dieser beiden Datenformate, zum Beispiel beim DTC und DID. Beide Formate enthalten jedoch alle notwendigen Informationen für die Steuergeräte-Entwicklung. Bei DTCs fehlen in ODX ungefähr 40 Attribute, die zur Beschreibung einen DTC im Steuergerät, wie zum Beispiel die Priorität des Fehlers und die zu verwendende Debouncing-Strategy.

Damit ein Entwickler effektiv und effizient arbeiten kann, wenn er einen DTC hinzufügt oder ändert, ist es nahezu unerlässlich, dass er hierfür nur an einer Stelle die Definitionen erzeugen und verwalten muss. Besitzt ein Tool erstmal alle notwendigen Informationen, können hieraus DEXT- und ODX-Daten generiert werden und bei späteren Änderungen werde diese auch wieder reimportiert und in das jeweils andere Format zurück exportiert. Damit ist eine Kohärenz der ODX und DEXT-Daten sichergestellt, sodass ein Funktionsentwickler für seine tägliche Arbeit nur ein Tool benötigt. Die Änderungen spiegeln sich auf Knopfdruck in beiden Welten wider.

Dieser Prozess ermöglicht die Erzeugung aller notwendigen Datenformate für die Entwicklung und den Aftersales. Zusätzlich können automatisch Test sequenzen zur Verifizierung des tatsächlichen Diagnoseverhaltens der Steuergeräte generiert werden.

Dies bringt in Verbindung mit den verschiedenen Diagnose-Layern Component, System- und Vehicle eines Adap tive AUTOSAR-Steuergeräts wirkungsvolle Diagnosemöglichkeiten direkt ins Fahrzeug. Dadurch wird ein möglichst störungsfreier Betrieb und eine hohe Zuverlässigkeit gewährleistet. Bei auftretenden Fehlern ist eine der Fahrzeugvariante angepasste, zeitnahe Diagnose gegeben. Dank einer intelligenten Problembehandlung können komplexe Funktionen wie ADAS trotz der Störung eines Teilsystems ihren bestmöglichen Funktionsumfang beibehalten.

Fazit

Die Diagnose behält sich die Voraussetzung, sich stetig steigenden Anforderungen komplexer autonomer Systeme der Zukunft anzupassen. Mit der Verfügbarkeit von High-Performance-Computern im Fahrzeug, die auch ausreichende Ressourcen für Diagnosetester besitzen, werden diese Tester ins Fahrzeug integriert. Die Diagnose wird dadurch umfangreicher und mobiler.

www.kpit.com