-
Technisches Gebiet
-
Die vorliegende Erfindung betrifft eine Steuereinheit für ein Fahrzeug sowie ein Fehlermanagementverfahren dafür.
-
Stand der Technik
-
Eine Umgebung erfordert eine große Rechenleistung. Leistung und Kosteneffizienz sind wichtige Bauelemente, jedoch ist Hochleistungsrechnen (im Englischen High Performance Computing (HPC)) im Sicherheitsbereich mit verschiedenen Problemen konfrontiert. Um die Probleme zu lösen, ist es notwendig, die Technologie anzupassen, die die Steuereinheit (ECU) nicht nutzen kann, wobei es notwendig ist, den vollen Nutzen aus innovativen Technologien zu ziehen. Eine adaptive AUTomotive-Open-System-Architecture (AUTOSAR)-Plattform verwaltet die Ressourcen und die Kommunikation dynamisch, verteilt die Anwendungsprogramme und reduziert gleichzeitig den Aufwand für die Softwareentwicklung und -integration, und ermöglicht es einem Systemintegrator, die Software sorgfältig zu integrieren, um das Fehlerrisiko zu verringern und Sicherheit zu gewährleisten. Der dynamische Betrieb des Anwendungsprogramms wird durch die im Anwendungsprogramm-Manifest festgelegten Einschränkungen begrenzt. Die dynamische Zuweisung der Ressourcen und des Kommunikationspfads während der Ausführung ist nur mit einem definierten Verfahren innerhalb eines ausgebildeten Bereichs möglich. Die Implementierung der adaptiven Plattform von AUTOSAR beschränkt die dynamische Funktion in der Konfiguration der Software auf eine Vorbestimmung von Prozessen, eine dynamische Speicherbegrenzung auf eine Startphase, Ablaufsteuerungsrichtlinien zusätzlich zur prioritätsbasierten Ablaufsteuerung, eine feste Zuweisung von Prozessen für eine zentrale Recheneinheit (CPU), einen Zugriff auf eine bestehende Datei, eine Einschränkung der Nutzung der Adaptive-Plattform (AP)-Anwendungs-Programmier-Schnittstelle (API), und die Ausführung eines autorisierten Codes.
-
[Literatur zum Stand der Technik]
-
[Patentdokument]
-
- Patentdokument 1: KR 10-2016-0076270 (veröffentlicht am 30. Juni 2016), mit dem Titel „Multicore System for Vehicle“
- Patentdokument 2: KR 10-1584213 (registriert am 5. Januar 2016), mit dem Titel „Apparatus and Method of Setting Data Communication Flow in AUTOSAR Platform“
-
Zusammenfassung der Erfindung
-
Die vorliegende Erfindung wurde gemacht, um eine Steuereinheit für ein Fahrzeug bereitzustellen, die aktiv mit einem Fehler umgeht, sowie ein Fehlermanagementverfahren dafür.
-
Eine beispielhafte Ausführungsform der vorliegenden Erfindung stellt ein Verfahren zum Verwalten eines Fehlers einer Steuereinheit für ein Fahrzeug bereit, wobei das Verfahren umfasst: Sammeln des Fehlers; Konvertieren des gesammelten Fehlers in eine Datenbank in einer Form, die für eine Diagnose und Fehlersuche erforderlich ist; und Ausführen eines Wiederherstellungsmechanismus durch Zusammenwirken eines Plattform-Zustandsmanagementclusters (PHM), eines Anweisungsmanagementclusters (SM) und eines Ausführungsmanagementclusters (EM), wobei das Sammeln des Fehlers umfasst: Sammeln eines Nutzerfehlers, der in einer Anwendung für das Fahrzeug auftritt; Sammeln eines Plattformfehlers, der in wenigstens einem von dem Plattform-Zustandsmanagementcluster (PHM), dem Anweisungsmanagementcluster (SM) und dem Ausführungsmanagementcluster (EM) auftritt; oder Sammeln eines integrierten Fehlers in Abhängigkeit davon, ob ein Netzwerkmanagementcluster (NM), ein Zeitsynchronisationscluster (TS) und ein Persistenzcluster (PER) normal betrieben werden.
-
In der beispielhaften Ausführungsform kann das Verfahren weiterhin eine periodische Überwachung umfassen, ob der Fehler auftritt.
-
In der beispielhaften Ausführungsform kann der Fehler durch Verwendung eines lokalen Host-Verfahrens von ara::com erfasst werden.
-
In der beispielhaften Ausführungsform kann der Fehler durch ein Polling-Verfahren erfasst werden.
-
In der beispielhaften Ausführungsform kann das Sammeln des integrierten Fehlers Folgendes umfassen: Aufrufen einer Anwendungsprogrammierschnittstelle zur Überprüfung, ob der Netzwerkmanagementcluster, der Zeitsynchronisationscluster und der Persistenzcluster normal betrieben werden; und Prüfen einer Antwort auf den Aufruf.
-
In der beispielhaften Ausführungsform kann das Konvertieren der gesammelten Fehler in die Datenbank Folgendes umfassen: Klassifizieren des gesammelten Fehlers in einen Fehler für eine Diagnose, einen Fehler für die Fehlersuche oder einen Fehler für das Protokoll; und Konvertieren jedes der klassifizierten Fehler in die Datenbank.
-
In der beispielhaften Ausführungsform kann das Ausführen des Wiederherstellungsmechanismus Folgendes umfassen: Überwachen von Konfigurationen in Bezug auf eine Plattformabhängigkeit; und Ausführen eines Neustarts entsprechend einem Ergebnis des Überwachens oder Unterbrechen der Anwendung.
-
In der beispielhaften Ausführungsform kann der Wiederherstellungsmechanismus unter Verwendung der gesammelten Fehler- und Kundenspezifikations-Rückrufinformationen ausgeführt werden.
-
Eine weitere beispielhafte Ausführungsform der vorliegenden Erfindung stellt eine Steuereinheit für ein Fahrzeug bereit, wobei die Steuereinheit umfasst: eine Kommunikationseinrichtung, die ausgebildet ist, um eine Kommunikation mit einer externen Einrichtung durchzuführen; einen Speicher, der zum Speichern eines Fehlermanagers ausgebildet ist; und eine Mikro-Steuereinheit, die ausgebildet ist, um die Kommunikationseinrichtung und den Speicher zu steuern, und um den Fehlermanager anzusteuern, wobei der Fehlermanager ausgebildet ist, um: einen Nutzerfehler zu sammeln, der in einer Anwendung für ein Fahrzeug auftritt, einen Plattformfehler zu sammeln, der wenigstens in einem Plattform-Zustandsmanagementcluster (PHM), einem Anweisungsmanagementcluster (SM) oder einem Ausführungsmanagementcluster (EM) auftritt, oder um einen integrierten Fehler in Abhängigkeit davon zu sammeln, ob ein Netzwerkmanagementcluster (NM), ein Zeitsynchronisationscluster (TS) und ein Persistenzcluster (PER) normal betrieben werden; den gesammelten Fehler in eine Datenbank in einer Form zu konvertieren, die für eine Diagnose und Fehlersuche erforderlich ist; und einen Wiederherstellungsmechanismus durch Zusammenwirken mit dem Plattform-Zustandsmanagementcluster (PHM), dem Anweisungsmanagementcluster (SM) und dem Ausführungsmanagementcluster (EM) durchzuführen.
-
In der beispielhaften Ausführungsform kann der Fehlermanager durch eine adaptive AUTomotive Open System Architecture (AUTOSAR)-Anwendung implementiert sein.
-
In der beispielhaften Ausführungsform kann der Fehlermanager periodisch den Netzwerkmanagementcluster NM, den Zeitsynchronisationscluster TS und den Persistenzcluster PER überwachen.
-
In der beispielhaften Ausführungsform kann der Fehlermanager durch ara::api periodisch überwachen, ob wenigstens einer der Funktionscluster einen Fehler aufweist.
-
In der beispielhaften Ausführungsform kann der Fehlermanager Kundenspezifikations-Rückrufinformationen an eine ausfallsichere Nutzerlogik der Anwendung für das Fahrzeug übermitteln.
-
Die Steuereinheit für das Fahrzeug und das Fehlermanagementverfahren gemäß den beispielhaften Ausführungsformen der vorliegenden Erfindung umfassen den Fehlermanager, der den Fehler der Plattform sammelt/verwaltet und dabei den Fehler der Plattform aktiv verarbeitet.
-
Die vorangehende Zusammenfassung ist nur illustrativ und soll in keiner Weise einschränkend sein. Zusätzlich zu den oben beschriebenen illustrativen Aspekten, Ausführungsformen und Merkmalen werden weitere Aspekte, Ausführungsformen und Merkmale durch Bezugnahme auf die Zeichnungen und die folgende detaillierte Beschreibung deutlich.
-
Figurenliste
-
Die beigefügten Zeichnungen dienen der Veranschaulichung der vorliegenden beispielhaften Ausführungsform und stellen die beispielhaften Ausführungsformen zusammen mit der detaillierten Beschreibung dar. Die technischen Merkmale der vorliegenden beispielhaften Ausführungsform sind jedoch nicht auf eine bestimmte Zeichnung beschränkt, wobei die in jeder Zeichnung offenbarten Merkmale miteinander kombiniert werden können, um eine neue beispielhafte Ausführungsform zu bilden.
- 1 ist ein Diagramm, das die Architektur einer adaptiven AUTomotive Open System Architecture (AUTOSAR)-Plattform zeigt.
- 2 ist ein Diagramm, das ein Beispiel für eine Proxy-Skelett-Dienst-orientierte Kommunikation über SOME/IP-Kommunikation zeigt.
- 3 ist ein Diagramm, das den Betrieb der adaptiven AUTOSAR-Plattform zeigt.
- 4 ist ein Diagramm zur Veranschaulichung des Betriebs einer adaptiven AUTOSAR-Plattform gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung.
- 5 ist ein Flussdiagramm, das ein Beispiel für ein Verfahren zum Betrieb eines Fehlermanagers einer Anwendung der adaptiven AUTOSAR-Plattform gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung darstellt.
- 6 ist ein Diagramm, das ein Beispiel für eine elektronisches Steuereinheit 1000 für ein Fahrzeug gemäß der beispielhaften Ausführungsform der vorliegenden Erfindung zeigt.
-
Es versteht sich, dass die beigefügten Zeichnungen nicht unbedingt maßstabsgetreu sind und eine etwas vereinfachte Darstellung verschiedener Merkmale zeigen, die die Grundprinzipien der Erfindung veranschaulichen. Die spezifischen Konstruktionsmerkmale der vorliegenden Erfindung, wie sie hierin offenbart sind, einschließlich z. B. spezifischer Abmessungen, Ausrichtungen, Positionen und Formen, sind zum Teil durch die jeweilige beabsichtigte Anwendung und Einsatzumgebung bestimmt.
-
In den Figuren beziehen sich die Bezugszeichen auf die gleichen oder gleichwertige Teile der vorliegenden Erfindung in den verschiedenen Figuren der Zeichnung.
-
Detaillierte Beschreibung
-
Nachfolgend sind die Inhalte der vorliegenden Erfindung klar und detailliert beschrieben, so dass der Fachmann die vorliegende Erfindung unter Verwendung der Zeichnungen leicht umsetzen kann.
-
Die vorliegende Erfindung kann verschiedene Modifikationen und verschiedene Formen haben, und daher sind bestimmte beispielhafte Ausführungsformen in den Zeichnungen dargestellt und im Zusammenhang detailliert beschrieben. Es ist jedoch nicht beabsichtigt, die vorliegende Erfindung auf die spezifische offengelegte Form zu beschränken, wobei bevorzugt wird, dass die vorliegende Erfindung alle Modifikationen, Äquivalenzen oder Substitutionen umfasst, die im Geist und im technischen Umfang der vorliegenden Erfindung enthalten sind. Begriffe wie „erster“ und „zweiter“ können zur Beschreibung verschiedener Bauelemente verwendet werden, wobei aber die Bauelemente durch diese Begriffe nicht eingeschränkt sind.
-
Die Begriffe werden nur verwendet, um ein Bauelement von einem anderen Bauelement zu unterscheiden. Beispielsweise kann, ohne vom Anwendungsbereich der vorliegenden Erfindung abzuweichen, ein erstes Bauelement als zweites Bauelement bezeichnet sein, und in ähnlicher Weise kann ein zweites Bauelement auch als erstes Bauelement bezeichnet sein. Wenn ein Bauelement als „gekoppelt“ oder „verbunden mit“ einem anderen Bauelement bezeichnet ist, kann ein Bauelement direkt mit dem anderen Bauelement gekoppelt oder verbunden sein, es können aber auch dazwischenliegende Elemente vorhanden sein. Wird dagegen ein Bauelement als „direkt gekoppelt“ oder „direkt verbunden mit“ einem anderen Bauelement bezeichnet, so ist davon auszugehen, dass es keine dazwischenliegenden Elemente gibt.
-
Andere Ausdrücke wie „zwischen -“ und „genau zwischen -“ oder“ angrenzend an ~“ und „direkt an ~ angrenzend“, die eine Beziehung zwischen Bauelementen beschreiben, sollten in ähnlicher Weise interpretiert werden. Die in der vorliegenden Anmeldung verwendeten Begriffe werden nur zur Beschreibung bestimmter beispielhafter Ausführungsformen verwendet und sollen die vorliegende Erfindung nicht einschränken. Die in dieser Anmeldung verwendeten Begriffe in der Einzahl schließen die Begriffe in der Mehrzahl ein, es sei denn, sie haben im Kontext eindeutig entgegengesetzte Bedeutungen.
-
Die in der vorliegenden Anmeldung verwendeten Begriffe werden nur zur Beschreibung bestimmter beispielhafter Ausführungsformen verwendet und sollen die vorliegende Erfindung nicht einschränken. Singuläre Ausdrücke, die hier verwendet werden, schließen plurale Ausdrücke ein, es sei denn, sie haben im Kontext eindeutig entgegengesetzte Bedeutungen. In der vorliegenden Anmeldung sind die Begriffe „einschließlich“ und „aufweisend“ dazu bestimmt, das Vorhandensein der in der Beschreibung beschriebenen Merkmale, Zahlen, Schritte, Operationen, Bauelemente und Komponenten oder einer Kombination davon zu bezeichnen, und schließen die Möglichkeit des Vorhandenseins oder der Hinzufügung eines oder mehrerer anderer Merkmale, Zahlen, Schritte, Operationen, Bauelemente und Komponenten oder einer Kombination davon nicht von vornherein aus. Alle hierin verwendeten Begriffe, einschließlich technischer oder wissenschaftlicher Begriffe, haben die gleiche Bedeutung, wie sie vom Fachmann im Allgemeinen verstanden wird, sofern sie nicht anders definiert sind. Begriffe, die in allgemein gebräuchlichen Wörterbüchern definiert sind, sind so auszulegen, dass sie Bedeutungen haben, die mit denen im Kontext eines verwandten Fachgebiets übereinstimmen, wobei sie nicht in idealer oder übermäßig formaler Bedeutung ausgelegt werden sollen, es sei denn, sie sind in der vorliegenden Anmeldung eindeutig definiert.
-
1 ist ein Diagramm, das die Architektur einer allgemeinen adaptiven AUTomotive Open System Architecture (AUTOSAR)-Plattform zeigt. Wie in 1 dargestellt, stellt die adaptive Plattform Funktionscluster und Basisdienste bereit.
-
Eine Softwarekomponente (SWC), die über eine Schnittstelle zur Basissoftware (BSW) formalisiert und definiert ist, ist eine Komponente der AUTOSAR-Architektur. Das BSW-Modul bietet grundlegende Standarddienste wie Buskommunikation, Speichermanagement, IO-Zugriff, Systeme und Diagnosedienste. Eine weitere Komponente von AUTOSAR ist eine Laufzeitumgebung (im Englischen Runtime Environment = RTE), die die Verbindung zwischen den SWCs oder eine Verbindung von den SWCs zur BSW steuert. Ein von AUTOSAR definierter Virtueller Funktionsbus (VFB) bietet eine konzeptionelle Grundlage für die Kommunikation zwischen den SWCs und dem BSW-Dienst. Die gesamte Kommunikation der SWC basiert auf dem VFB, und somit ist die SWC unabhängig von der ECU-Hardware. Dadurch kann die SWC in einem Projekt und auf einer Plattform wiederverwendet werden. Der VFB kann ausgeführt werden, indem er mit der für jede ECU entsprechend eingestellten BSW verbunden wird und eine speziell eingestellte RTE liefert.
-
Adaptive Anwendungen (AAs) werden auf der Basis einer AUTOSAR Laufzeit für eine Adaptive Anwendung (ARA) betrieben. Die ARA besteht aus einer Anwendungsprogrammierschnittstelle (API), die von einem Funktionscluster bereitgestellt wird, das zu einer Foundation oder Diensten gehört. Die Foundation stellt die grundlegenden Funktionen der Adaptiven Plattform (AP) und des Dienstes bereit. Alle adaptiven Anwendungen können andere adaptive Anwendungen mit Diensten versorgen.
-
Die adaptive Plattform umfasst einen funktionalen Cluster bzw. Funktionscluster zur Bereitstellung besserer Dienste. Zu den Funktionsclustern gehören ein Zeitmanagementcluster, ein Betriebssystemcluster, ein Ausführungsmanagementcluster, ein Persistenzcluster, ein Plattformzustandsmanagentcluster, ein Protokollierungs- und Verfolgungs-Cluster, ein Hardware-Beschleunigungs-Cluster und ein Kommunikationsmanagementcluster. Die Funktionscluster kommunizieren mit anderen Anwendungen über die API. Da nur die API-Implementierung definiert ist, ist der Grad der Implementierungsfreiheit des Funktionsclusters der adaptiven Plattform viel höher als der der BSW-Stapel-Implementierung, die die bestehende klassische Plattform ausgebildet.
-
Der Basisdienst umfasst einen SW-Konfigurationsmanagementdienst, einen Sicherheitsmanagementdienst und einen Diagnosedienst. Der Basisdienst kann über ara::com (im Englischen AUTOSAR Runtime for Adaptive Applications) mit Middleware-Charakter aufgerufen werden.
-
Die adaptive Plattform berücksichtigt Hardware, die von einer Maschine ausgeführt wird. Die Hardware wird durch den Einsatz verschiedener Technologien virtualisiert. Die Hardware umfasst eine oder mehrere Maschinen. Es wird nur eine AP-Instanz ausgeführt. Die Hardware besteht aus einem einzigen Chip oder mehreren Chips, auf denen die Maschinen untergebracht sind.
-
2 ist ein Diagramm, das ein Beispiel für eine Proxy-Skelett-Dienst-orientierte Kommunikation über SOME/IP-Kommunikation zeigt. Der größte Unterschied zwischen der adaptiven AUTOSAR-Plattform und der klassischen Plattform besteht in dem Kommunikationsverfahren. Die meisten der bestehenden klassischen Plattformen basieren auf einer traditionellen signalorientierten Kommunikation. Dabei basiert die adaptive Plattform auf Service-orientierter Kommunikation (SOC). Die SOC ist das Kommunikationsverfahren, das einen benötigten Dienst dynamisch zwischen dem Skelett, d. h. dem Server, der den Dienst bereitstellt, und einem Proxy, d. h. einem Client, der den Dienst konsumiert, über die Dienstentdeckung und den skalierbaren serviceorientierten MiddlewarE over IP (SOME/IP) verbindet. Ein Fahrzeuganwendungsserver ist ein System, in das die adaptive AUTOSAR-Plattform eingebaut ist und das in der Lage ist, einen intelligenten Sensor und einen intelligenten Aktor über SOME/IP entsprechend der Verwendung einer Fahrzeuganwendung frei zu überwachen und zu steuern.
-
3 ist ein Diagramm, das den Betrieb der allgemeinen adaptiven AUTOSAR-Plattform veranschaulicht.
-
Eine adaptive AUTOSAR-Anwendung 20 enthält einen Fehlermanager 21.
-
Der Fehlermanager 21 überwacht periodisch einen Fehler eines Netzwerkmanagements (NM), eines PER und eines ETC. Der Fehlermanager 21 prüft bei jedem Überwachungszyklus durch ara::api jedes Clusters, ob ein Fehler in den adaptiven AUTOSAR-Funktionsclustern 10 vorliegt.
-
Wenn ein unnormales Symptom gefunden wird, veranlasst der Fehlermanager 21 die adaptive AUTOSAR-Anwendung 30, eine Wiederherstellungsaktion durchzuführen, indem er das Plattform-Zustandsmanagement (PHM), das Anweisungsmanagement (SM) und das Ausführungsmanagement (EM) miteinander verknüpft. Dementsprechend wird die Fehleroperation abgeschlossen.
-
Das PHM führt eine Überwachungsfunktion aus. Das PHM führt eine Kontrollflussüberwachung und eine externe Überwachung durch. Die Alive-Überwachung überwacht, ob die periodische SWC periodisch gut ausgeführt wird. Eine Deadline-Überwachung überwacht, ob eine aperiodische SWC zwischen zwei gegebenen Punkten gut ausgeführt wird. Eine logische Überwachung überwacht, ob die Abfolge der SWC-Einheiten in einer vorgegebenen Reihenfolge ausgeführt wird. Eine Zustandskanalüberwachung überwacht externe Faktoren, die mit dem Zustand zusammenhängen.
-
Das PHM und das EM führen eine Fehlerlesefunktion aus. Eine Watchdog („Wachhund“)-Steuerung unterstützt den Hardware-Watchdog. Die Fehlerbehandlung verarbeitet den Fehler, nachdem der Fehler aufgetreten ist. Die Aktionen des PHM umfassen die Beendigung oder den Neustart der Anwendung, das Zurücksetzen der Plattforminstanz, den Hardware-Watchdog und eine Benachrichtigungsfunktion. Die Beendigung oder der Neustart der Anwendung bedeutet das Anhalten und den Neustart des SWC. Das Zurücksetzen der Plattforminstanz kann die Steuereinheit selbst zurücksetzen. Der Hardware-Watchdog unterstützt den Hardware-Watchdog. Die Benachrichtigungsfunktion führt eine Benachrichtigung durch, wenn ein entsprechendes Problem in der SWC auftritt, die die Sicherheitsrolle ausführt.
-
Das SM verwaltet den Zustand der Steuereinheit selbst, empfängt ein Ereignis von der adaptiven Plattform und der SWC, steuert das Ein- und Ausschalten eines Netzwerks durch Steuerung des NM und steuert das Herunterfahren und den Neustart des Systems.
-
Das EM ist für das Systemausführungsmanagement zuständig, einschließlich der Initialisierung der Plattform sowie des Starts und der Beendigung eines Anwendungsprogramms. Das EM arbeitet mit einem Betriebssystem zusammen und führt die Laufzeitplanung des Anwendungsprogramms durch. In der beispielhaften Ausführungsform kann der Überwachungszyklus festgelegt sein. Der Überwachungszyklus beträgt zum Beispiel 1 ms, 10 ms und 100 ms.
-
Das EM führt den Start und das Herunterfahren des Systems durch und steuert die Erzeugung eines Prozesses der adaptiven Plattform und der Anwendung nach dem Neustart, führt den Start und das Herunterfahren der SWC durch und steuert die Anwendung gemäß des SM.
-
Die allgemeine adaptive AUTOSAR-Plattform überwacht ein unnormales Symptom des Systems durch ein internes Modul, wie z. B. das PHM, das SM und das EM, und führt einen Neustart/Stopp der entsprechenden Anwendung durch, wenn das unnormale Symptom auftritt. Dies sind jedoch die Funktionen der jeweiligen Module, wobei der Prozess der Kombination der Funktionen zur Durchführung eines Wiederherstellungsvorgangs ab dem Punkt, an dem der Fehler im Wesentlichen auftritt, nicht enthalten ist.
-
Andererseits ergänzt die adaptive AUTOSAR-Plattform gemäß der beispielhaften Ausführungsform der vorliegenden Erfindung den nicht-implementierten Teil auf einem adaptiven AUTOSAR-Betriebssystem.
-
4 ist ein Diagramm zur Veranschaulichung eines Betriebs einer adaptiven AUTOSAR-Plattform gemäß der beispielhaften Ausführungsform der vorliegenden Erfindung. Bezugnehmend auf 4 kann eine adaptive AUTOSAR-Anwendung 200 einen Fehlermanager 210 umfassen. Der Fehlermanager 210 kann eine Fehlersammeleinheit 211, eine Fehlernachbearbeitungseinheit 212 und eine nutzerdefinierte Systemwiederherstellungseinheit 212 umfassen.
-
Die Fehlersammeleinheit 211 kann einen Nutzerfehler, einen kombinierten Fehler und einen Plattformfehler sammeln. In der beispielhaften Ausführungsform kann der Nutzerfehler von einer Fahrzeuganwendung 310 übermittelt werden. In der beispielhaften Ausführungsform kann der kombinierte Fehler von einem Netzwerkmanagement (NM) 110, einem Zeitsynchronisationsmanagement (TS) 120 und einem Persistenzmanagement (PER) 130 des adaptiven AUTOSAR-Funktionsclusters 100 übertragen werden. In der beispielhaften Ausführungsform kann der Plattformfehler von einem Plattformzustandsmanagement (PHM) 140, einem Zustandsmanagement (SM) 150 und einem Ausführungsmanagement (EM) 160 des adaptiven AUTOSAR-Funktionsclusters 100 übertragen werden.
-
Die Fehlernachbearbeitungseinheit 212 kann eine Fehlerbehebungs-Datenbank (DB), eine Log-DB und eine Diagnose-DB enthalten. In der beispielhaften Ausführungsform kann die Fehlerbehebungs-DB an das PER 130 übertragen werden. In der beispielhaften Ausführungsform kann die Protokoll-DB an die Fahrzeuganwendung 310 übertragen werden.
-
In der beispielhaften Ausführungsform kann die Diagnose-DB an ein Diagnosemodul (DIAG) 170 übertragen werden.
-
Eine nutzerdefinierte Systemwiederherstellungseinheit 213 kann einen kundenspezifischen Rückruf enthalten. In der beispielhaften Ausführungsform kann der Kundenspezifikations-Rückruf an eine nutzerdefinierte Ausfall-Sicherheits-Logik 312 übertragen werden.
-
Der Fehlermanager 210 entspricht einer Anwendung des adaptiven AUTOSAR. Die Anwendung kann die folgenden Funktionen ausführen.
-
Erstens kann der Fehlermanager 210 über ara-APIs auf das PHM 140, das SM 150 bzw. das EM 160 zugreifen.
-
Zweitens kann der Fehlermanager 210 auf die API zugreifen, die in der Lage ist, zu lesen, ob das NM 110, der TS 120 und der PER 130 einen Fehler aufweisen.
-
Drittens ist der Fehlermanager 210 die adaptive AUTORSA-Anwendung und kann immer in der Einheit eines Prozesses ausgeführt werden.
-
Viertens kann der Fehlermanager 210 überwachen, ob ein Fehler über die definierte API während eines bestimmten Zeitraums auftritt. In der beispielhaften Ausführungsform kann der Zyklus 1 s, 1 µs, 1 ms und 1 ns betragen.
-
Wenn der Fehler auftritt, schaltet der Fehlermanager 210 die Zustände der aktuell betriebenen entsprechenden Anwendungen über den SM 150 in den Shutdown-Zustand, fordert den Shutdown-Vorgang für die aktuell betriebene Anwendung über den EM 160 an und führt eine Wiederherstellungsaktion in der entsprechenden Anwendung über den PHM 140 aus.
-
Wie oben beschrieben, kann die adaptive AUTOSAR-Plattform gemäß der beispielhaften Ausführungsform der vorliegenden Erfindung den Fehler auf der Grundlage des adaptiven AUTOSAR-Betriebssystems über den Fehlermanager 210 verarbeiten.
-
Im Allgemeinen stellt das adaptive AUTSAR die SW-Funktion zur Verfügung, die in der Lage ist, einen Fehler zu verarbeiten, wobei die Technologie, die in der Lage ist, einen tatsächlichen Fehler aktiv zu verarbeiten, ist in der Betriebssystem-Spezifikation enthalten nicht. Durch die Internalisierung und Verteilung des vorgenannten Teils auf die Ebenen kann eine stabile und gleichmäßige Qualität der SW in Massenproduktion hergestellt werden. Insbesondere die Fehlerverarbeitung ist ein wesentlicher Punkt im Entwicklungsbereich der Ebenen. Dementsprechend können verschiedene Anforderungen von Ebenen und Kunden gesammelt werden, wobei der Anwendungsbereich variiert werden kann.
-
In der beispielhaften Ausführungsform kann der Fehlermanager 210 periodisch überwachen, ob ein Fehler auftritt. Zum Beispiel prüft der Fehlermanager 210 bei jedem Überwachungszyklus durch ara::api jedes Clusters, ob ein Fehler in den adaptiven AUTOSAR-Funktionsclustermodulen vorliegt. In der beispielhaften Ausführungsform kann der Fehlerüberwachungszyklus vom Nutzer eingestellt werden.
-
Die Fehlersammeleinheit 211 kann das Senden und Empfangen unter Verwendung eines lokalen Host-Verfahrens von ara::com ausführen (die der Kommunikation in Form von IPC des POSIX-Betriebssystems ähnelt und üblicherweise mit einem gemeinsamen Speicher eingerichtet ist). In der beispielhaften Ausführungsform kann die Kommunikation durch ein Polling-Verfahren erfolgen. Dies kann die Belastung des Systems reduzieren.
-
In der beispielhaften Ausführungsform kann die Fehlersammeleinheit 211 einen in der Fahrzeuganwendung 300 aufgetretenen Nutzerfehler sammeln.
-
In der beispielhaften Ausführungsform kann die Fehlersammeleinheit 211 einen Plattformfehler erfassen, der in einem Funktionscluster (FC) des adaptiven AUTOSAR auftritt.
-
In der beispielhaften Ausführungsform kann die Fehlersammeleinheit 211 umfassende Fehler sammeln. Beispielsweise kann die Fehlersammeleinheit 211 eine API aufrufen, die in der Lage ist, zu prüfen, ob die NM 110, die TS 120 und die PER 130 normal betrieben werden, und eine Antwort darauf prüfen, und wenn die Antwort nicht angemessen ist, kann die Fehlersammeleinheit 211 feststellen, dass ein integrierter Fehler auftritt.
-
Die Fehlernachverarbeitungseinheit 212 kann die gesammelten Fehler in eine Datenbank in der für die Diagnose und Fehlersuche erforderlichen Form wie folgt umwandeln.
-
Die Fehler-DB für die Diagnose ist die auf einem Fehlercode, einer Beschreibung und einem Diagnoseparameter basierende Datenbank, die an ein Diagnosegerät übertragen wird. Ein Ausgabeformular kann eine Diagnosespezifikation enthalten.
-
Die Fehler-DB für die Analyse des Systems ist die Datenbank des Fehlers für die Fehlersuche. Die Fehler-DB kann zum Beispiel ein Fehlerprotokoll über das PER 130 speichern. Ein Ausgabeformular kann die Form eines DLT haben.
-
Die DB für das Protokoll ist die Datenbank in Form eines Protokolls, damit die Fahrzeuganwendung in der Lage ist, eine entsprechende Ausnahme zu verarbeiten. Ein Ausgabeformular kann in Form von printf vorliegen.
-
Die nutzerdefinierte Systemwiederherstellungseinheit 213 kann einen Wiederherstellungsmechanismus des adaptiven AUTOSAR enthalten, der während des Zusammenwirkens mit dem PHM 140, dem SM 150 und dem EM 160 ausgeführt wird. Die Wiederherstellungsmechanismen können nur die Elemente überwachen, die vollständig durch die Plattformabhängigkeit kontrolliert werden, und eine Reaktion (Wiederherstellungsfunktionen, wie z. B. Widerlegung und Anwendungsunterbrechung) ausführen.
-
In der beispielhaften Ausführungsform kann die nutzerdefinierte Systemwiederherstellungseinheit 213 einen Körperbereich einer Rückruffunktion, die von einem Kundenunternehmen definiert wurde, und den vorliegenden „nutzerdefinierten Systemwiederherstellungsbereich“ durch Rückruf in Form eines Funktionszeigers verbinden. In der beispielhaften Ausführungsform kann das Kundenunternehmen den Wiederherstellungsvorgang auf der Grundlage des gesammelten Fehlers und der vom Kundenunternehmen festgelegten Richtlinie direkt neu definieren und verwenden.
-
Beispielsweise ist eine Logik erforderlich, die überwacht, ob die PCI-Express-Schnittstelle ausfallsicher ist. Wenn das Kundenunternehmen die entsprechende Funktion nicht einstellen kann, weil die Überwachung nicht in einer Nutzerkonfiguration des PHM 140 des adaptiven AUTOSAR widergespiegelt wird, kann ein normaler Betrieb der PCI-Express-Schnittstelle nicht beobachtet werden. Durch den vorangegangenen Teil ist es möglich, eine Funktion zur direkten Überwachung der PCI-Express-Schnittstelle durch das Kundenunternehmen hinzuzufügen, wenn der entsprechende gesammelte Fehler auftritt. Die Ausfall-Sicherheitsbereich-Kontrolllogik ist in Form des CDD des klassischen AUTOSAR aufgebaut.
-
5 ist ein Flussdiagramm, das ein Beispiel für ein Verfahren zum Betrieb des Fehlermanagers der Anwendung der adaptiven AUTOSAR-Plattform gemäß der beispielhaften Ausführungsform der vorliegenden Erfindung zeigt. Unter Bezugnahme auf die 3 bis 5 kann der Fehlermanager 210 (siehe 3) wie folgt arbeiten.
-
Der Fehlermanager 210 kann einen Fehler von wenigstens einem Funktionscluster oder einer anderen adaptiven Anwendung (S110) sammeln. Beispielsweise kann der Fehlermanager 210 das NM, das TS und das PER des Funktionsclusters regelmäßig überwachen und einen integrierten Fehler erfassen, einen Nutzerfehler von der Fahrzeuganwendung erfassen oder Plattformfehler erfassen, die vom PHM, dem SM und dem EM ausgegeben werden.
-
Der Fehlermanager 210 kann die gesammelten Nutzerfehler, integrierten Fehler, Plattformfehler und dergleichen in eine Datenbank (120) umwandeln. Beispielsweise kann der Fehlermanager 210 die Fehler zur Fehlersuche in eine Datenbank umwandeln, Fehlercodes, Beschreibungen und Diagnoseparameter, die an eine Diagnoseeinrichtung übertragen werden sollen, in eine Datenbank umwandeln oder die gesammelten Fehler in Form eines Protokolls in eine Datenbank umwandeln, so dass der gesammelte Fehler als Ausnahme in der Fahrzeuganwendung verarbeitet wird.
-
Der Fehlermanager 210 kann einen nutzerdefinierten Wiederherstellungsmechanismus der adaptiven AUTOSAR-Anwendung durch Zusammenwirken mit dem PHM, dem SM und dem EM wenigstens eines Funktionsclusters (S130) ausführen.
-
Die Schritte und/oder Vorgänge gemäß der vorliegenden Erfindung können in verschiedenen beispielhaften Ausführungsformen für verschiedene Epochen in unterschiedlicher Reihenfolge, parallel oder gleichzeitig ablaufen, wie es dem Fachmann verständlich ist. Je nach beispielhafter Ausführungsform kann ein Teil oder können die Gesamtheit der Schritte und/oder Operationen unter Verwendung von Befehlen implementiert oder ausgeführt werden, die in einem oder mehreren nicht temporären computerlesbaren Medien, einem Programm, einer interaktiven Datenstruktur und einem oder mehreren Prozessoren gespeichert sind, die einen Client und/oder einen Server steuern. Ein oder mehrere nicht temporäre computerlesbare Medien sind z. B. Software, Firmware, Hardware und/oder eine beliebige Kombination davon. Weiterhin kann die in der vorliegenden Beschreibung beschriebene Funktion des „Moduls“ durch Software, Firmware, Hardware und/oder eine beliebige Kombination davon implementiert sein.
-
6 ist ein Diagramm, das ein Beispiel für eine elektronisches Steuereinheit 1000 für ein Fahrzeug gemäß der beispielhaften Ausführungsform der vorliegenden Erfindung zeigt. Bezug nehmend auf 6 kann eine elektronische Steuereinheit (ECU) 1000 für ein Fahrzeug eine Mikrosteuereinheit (MCU) 1100, einen Speicher 1200 und eine Kommunikationseinrichtung 1300 umfassen.
-
Die MCU 1100 kann so implementiert sein, dass sie den allgemeinen Betrieb der ECU 1000 für das Fahrzeug durchführt. Die MCU 1100 kann wenigstens ein Programm steuern, indem sie wenigstens einen Befehl ausführt. Zum Beispiel kann das wenigstens eine Programm die adaptive AUTOSAR-Anwendung umfassen, die unter Bezugnahme auf die 3 bis 5 beschrieben ist.
-
Die MCU 1100 kann eine Mehrzahl von Kernen enthalten. Die Mehrzahl der Kerne kann wenigstens einen Hauptkern und wenigstens einen Unterkern umfassen.
-
Der Speicher 1200 kann implementiert sein, um wenigstens ein Programm zu speichern. Der Speicher 1200 kann einen flüchtigen Speicher oder einen nichtflüchtigen Speicher umfassen. Der Speicher 1200 kann beispielsweise ein Speichermedium wie einen Schreib-Lese-Speicher (RAM), einen Statischen Schreib-Lese-Speicher (SRAM), einen Nur-Lese-Speicher (ROM), einen Programmierbaren Nur-Lese-Speicher (PROM), einen Elektrisch-Löschbaren-Programmierbaren Nur-Lese-Speicher (EEPROM), einen NAND-Flash-Speicher und einen NOR-Flash-Speicher umfassen.
-
Die Kommunikationseinrichtung 1300 dient als Schnittstelle, die eine Kommunikation mit der Außenseite der ECU 1000 für das Fahrzeug herstellen kann. Im Allgemeinen können für die Kommunikation mit der ECU 1000 für das Fahrzeug und der externen Einrichtung der ECU 1000 für das Fahrzeug eine Controller Area Network (CAN)-Kommunikation, eine Local Interconnect Network (LIN)-Kommunikation und eine Ethernet-Kommunikation verwendet werden.
-
Ein oder mehrere nicht-transitorische computerlesbare Medien und/oder Mittel zur Implementierung/Durchführung einer oder mehrerer Operationen/Schritte/Module der beispielhaften Ausführungsformen der vorliegenden Erfindung können Controller, einschließlich anwendungsspezifischer integrierter Schaltungen (ASICs), standardmäßiger integrierter Schaltungen und Mikrocontroller, die entsprechende Befehle ausführen, und/oder einen eingebetteten Controller, feldprogrammierbare Gate-Arrays (FPGAs), komplexe programmierbare Logikbausteine (CPLDs) und gleichwertige Einrichtungen davon umfassen, wobei aber die vorliegende Erfindung nicht darauf beschränkt ist.
-
Dabei sind die Inhalte der vorliegenden Erfindung lediglich die besonderen beispielhaften Ausführungsformen zur Umsetzung der Erfindung. Die vorliegende Erfindung umfasst nicht nur konkrete und praktisch anwendbare Mittel, sondern auch technische Ideen, die abstrakte und konzeptionelle Ideen sind, die in der Zukunft als Technologien genutzt werden können.
-
Dabei können die Ausführungsformen gemäß der vorliegenden Erfindung in Form von Programmanweisungen implementiert sein, die von Computern ausgeführt werden können, und können in computerlesbaren Medien aufgezeichnet werden. Die computerlesbaren Medien können Programmanweisungen, eine Datendatei, eine Datenstruktur oder eine Kombination davon enthalten. Computerlesbare Medien können zum Beispiel Computerspeichermedien und Kommunikationsmedien umfassen, ohne darauf beschränkt zu sein. Zu den Computerspeichermedien gehören sowohl flüchtige als auch nicht flüchtige, entfernbare und nicht entfernbare Medien, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie z. B. computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten, eingesetzt werden. Zu den Computerspeichermedien gehören unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das ein Computer zugreifen kann. Kommunikationsmedien verkörpern typischerweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus, und umfassen alle Medien zur Informationsübertragung. Der Begriff „moduliertes Datensignal“ bezeichnet ein Signal, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert werden, dass Informationen in dem Signal kodiert werden. Zu den Kommunikationsmedien gehören beispielsweise verdrahtete Medien wie ein verdrahtetes Netzwerk oder eine Direktverbindung sowie drahtlose Medien wie akustische, RF-, Infrarot- und andere drahtlose Medien. Kombinationen der oben genannten Medien sollten ebenfalls in den Bereich der computerlesbaren Medien fallen.
-
Wie oben beschrieben, wurden die beispielhaften Ausführungsformen in den Zeichnungen und in der Beschreibung beschrieben und dargestellt. Die beispielhaften Ausführungsformen wurden ausgewählt und beschrieben, um bestimmte Prinzipien der Erfindung und ihre praktische Anwendung zu erläutern und dadurch einen anderen Fachmann in die Lage zu versetzen, verschiedene beispielhafte Ausführungsformen der vorliegenden Erfindung sowie verschiedene Alternativen und Modifikationen davon herzustellen und zu verwenden. Wie aus der vorstehenden Beschreibung ersichtlich ist, sind bestimmte Aspekte der vorliegenden Erfindung nicht durch die besonderen Einzelheiten der hierin dargestellten Beispiele beschränkt, und es wird daher in Betracht gezogen, dass andere Modifikationen und Anwendungen oder Äquivalente davon für den Fachmann auf dem Gebiet auftreten werden. Viele Änderungen, Modifikationen, Variationen und andere Verwendungen und Anwendungen der vorliegenden Konstruktion werden jedoch für den Fachmann nach Betrachtung der Beschreibung und der beigefügten Zeichnungen offensichtlich werden. Alle derartigen Änderungen, Modifikationen, Variationen und sonstigen Verwendungen und Anwendungen, die nicht vom Geist und Umfang der Erfindung abweichen, gelten als durch die Erfindung abgedeckt, die nur durch die folgenden Ansprüche begrenzt ist.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- KR 1020160076270 [0002]
- KR 101584213 [0002]
