-
TECHNISCHES GEBIET
-
Die Offenbarung betrifft eine Architektur zur Speicherverwaltung.
-
HINTERGRUND
-
Automotive Open System Architecture (AUTOSAR) ist eine Standardisierungsplattform, um auf die rasante Zunahme des Einsatzes von Embedded Software für Automotive-Elektronikkomponenten zu reagieren, bei der mehrere Automobilhersteller, Fahrzeugkomponentenhersteller, Entwicklungswerkzeuglieferanten, und Halbleiterhersteller teilnehmen.
-
Eine AUTOSAR-konforme Anwendungssoftware wird zu Softwarekomponenten (auch SWC genannt) modularisiert.
-
Eine Softwarekomponente mit gemeinsamen Funktionen basiert auf dem Konzept der Wiederverwendung einer Anwendungssoftware unter Verwendung einer Open Source, ist jedoch auf Plattformsoftware beschränkt.
-
Eine bestehende AUTOSAR-Plattform stellt standardisierte Module einer Service-Schicht, einer elektronischen Steuereinheit (ECU) und einer Mikrocontroller-Abstraktionsschicht entsprechend einer Basissoftware (BSW) bereit. In einer Anwendungsschicht sind die Konfigurationen der Anwendungssoftwarekomponente je nach Entwickler- oder Softwarearchitektur unterschiedlich.
-
Derzeit benötigt eine AUTOSAR-Plattform einen Algorithmus einer Softwarekomponente, um einen nichtflüchtigen Speicher zwischen dem nichtflüchtigen Speicher und der Softwarekomponente zuverlässig und effizient zu verwalten.
-
Genauer gesagt speichert ein nichtflüchtiger Speicher Daten wie Kilometerdaten und Fehlerdiagnosedaten, die auch nach dem Ausschalten eines Fahrzeugs nicht gelöscht werden sollten (Key Off).
-
Aufgrund der Hardwareeigenschaften (HW) des nichtflüchtigen Speichers ist die Anzahl der Lese/Schreibvorgänge begrenzt. Dementsprechend kann die Lebensdauer des nichtflüchtigen Speichers verkürzt werden, wenn viele Lese/Schreibvorgänge unnötig ausgeführt werden, und der nichtflüchtige Speicher kann während des Lebenszyklus des Fahrzeugs ausfallen. In diesem Fall wird die Zuverlässigkeit der Daten von Lese/Schreibvorgängen des nichtflüchtigen Speichers verschlechtert, was zu einem schwerwiegenden Defekt im Fahrzeug führt.
-
Da bei der Lese/Schreibverarbeitung von nicht-flüchtigen Speichern, Informationen durch Funktionsaufrufe zwischen verschiedenen Modulen der AUTOSAR-Software übertragen werden, sind ergänzende Technologien erforderlich, um die Integrität in jedem Prozess zu gewährleisten.
-
ZUSAMMENFASSUNG
-
Die Offenbarung betrifft eine Architektur zur Speicherverwaltung. Besondere Ausführungsformen beziehen sich auf eine Automotive Open System Architecture (AUTOSAR)-basierte Architektur zur Speicherverwaltung. Verschiedene Ausführungsformen beziehen sich auf eine Architektur zum Verwalten eines nichtflüchtigen Speichers (NVM) zwischen dem NVM und einer Softwarekomponente (SWC) einschließlich einer Fahrzeugsteuerungslogik.
-
Eine Ausführungsform der Offenbarung stellt eine Architektur für die Speicherverwaltung bereit, die Lese/Schreibbefehle unter Berücksichtigung einer Lebensdauer des nichtflüchtigem Speichers minimieren kann, komplementäre Logik für einen zuverlässigen Datenaustausch enthält, und als Medium für die Datenübertragung und den Empfang dient.
-
Gemäß einer Ausführungsform der Offenbarung ist eine Architektur zur Speicherverwaltung einschließlich einer Anwendungssoftwarekomponente (ASW), die konfiguriert ist, einen Algorithmus für mindestens eine Funktion auszuführen und Daten im Algorithmus zu übertragen und zu empfangen, einer Basissoftware (BSW) einschließlich eines nichtflüchtigen Speichermanagers (NvM) zum Verwalten eines nichtflüchtigen Speichers, einer Zustandsmanager-Softwarekomponente, die zur Verwaltung des NvM konfiguriert ist, und einer Laufzeitumgebung (RTE)I, die konfiguriert ist, um eine Kommunikation zwischen der ASW- und der Zustandsmanager-Softwarekomponente sowie zwischen der BSW- und der Zustandsmanager-Softwarekomponente durchzuführen, wobei beim Schreiben von Daten an den nicht-flüchtigen Speicher und beim Lesen von Daten aus dem nicht flüchtigen Speicher, die Zustandsmanager-Softwarekomponente so konfiguriert ist, dass sie einen Lesevorgang oder einen Schreibvorgang beendet, basierend auf einer Anzahl von Lesevorgängen, die größer oder gleich einer voreingestellten Anzahl von Malen oder einer Anzahl von Schreibvorgängen größer oder gleich einer voreingestellten Anzahl von Malen ist.
-
Die ASW und die Zustandsmanager-Softwarekomponente werden in einer Anwendungsschicht einer Automotive Open System Architecture (AUTOSAR)-basierten Plattform bereitgestellt.
-
Die Zustandsmanager-Softwarekomponente ist konfiguriert, um einen Vorgang des Lesens von in dem nichtflüchtigen Speicher gespeicherten Daten zu steuern, wenn ein Fahrzeug eingeschaltet wird, und einen Vorgang des Schreibens von Daten in den nichtflüchtigen Speicher zu steuern, wenn das Fahrzeug ausgeschaltet wird.
-
Wenn ein Schreibbefehl empfangen wird, ist die Zustandsmanager-Softwarekomponente so konfiguriert, dass sie eine vorbestimmte Lesefunktion (Rte_Read) aufruft, so dass die in den nichtflüchtigen Speicher zu schreibenden Daten aus der ASW gelesen und die gelesenen Daten in den nichtflüchtigen Speicher geschrieben werden.
-
Wenn die Daten durch die RTE gelesen werden, ist die Zustandsmanager-Softwarekomponente konfiguriert, um festzustellen, ob ein RTE-Fehler auftritt, und wenn festgestellt wird, dass der RTE-Fehler auftritt, um den Schreibvorgang zu beenden.
-
Bei der Steuerung des Schreibvorgangs ist die Zustandsmanager-Softwarekomponente so konfiguriert, dass sie einen Fehlerstatus-Get-Service für einen einzelnen Block aus dem NvM des BSW anfordert.
-
Beim Anfordern des Fehlerstatus-Get-Dienstes ist die Zustandsmanager-Softwarekomponente konfiguriert, um festzustellen, ob ein RTE-Fehler auftritt, und wenn festgestellt wird, dass der RTE-Fehler auftritt, um den Schreibvorgang zu beenden.
-
Bei der Steuerung des Schreibvorgangs ist die Zustandsmanager-Softwarekomponente konfiguriert, um zu bestimmen, ob ein Ergebnis des Fehlerstatus-Get-Dienstes in einem anhängigen Zustand ist, und wenn festgestellt wird, dass das Ergebnis nicht im ausstehenden, d. h. anhängigen, Zustand ist, um einen Schreibblockdienst vom NvM anzufordern, indem die gelesenen Daten als Faktor verwendet werden.
-
Wenn der Schreibblockdienst angefordert wird, ist die Zustandsmanager-Softwarekomponente konfiguriert, um zu bestimmen, ob ein RTE-Fehler auftritt, und wenn festgestellt wird, dass der RTE-Fehler auftritt, um den Schreibvorgang zu beenden, und wenn festgestellt wird, dass sich das Ergebnis im ausstehenden Zustand befindet, um den Schreibvorgang zu beenden.
-
Die Zustandsmanager-Softwarekomponente ist so konfiguriert, dass sie für einen Block, in dem das Schreiben der gelesenen Daten abgeschlossen ist, ein Flag auf „ein“ setzt, und wenn das Schreiben der Daten für alle Blöcke des NvM abgeschlossen ist, Flags initialisiert.
-
Wenn ein Lesen-Ein-Befehl empfangen wird, ist die Zustandsmanager-Softwarekomponente so konfiguriert, dass sie einen Fehlerstatus-Get-Service vom NvM anfordert, um den Status eines einzelnen Blocks des NvM zu überprüfen.
-
Beim Anfordern des Fehlerstatus-Get-Dienstes ist die Zustandsmanager-Softwarekomponente so konfiguriert, dass ermittelt wird, ob ein RTE-Fehler auftritt, und wenn festgestellt wird, dass der RTE-Fehler auftritt, wird der Lesevorgang beendet.
-
Bei der Steuerung des Lesevorgangs ist die Zustandsmanager-Softwarekomponente so konfiguriert, dass sie feststellt, ob sich ein Ergebnis des Fehlerstatus-Get-Service in einem ausstehenden Zustand befindet, wenn festgestellt wird, dass das Ergebnis nicht im ausstehenden Zustand ist, einen Leseblockdienst vom NvM anfordert, und wenn festgestellt wird, dass das Ergebnis im ausstehenden Zustand ist, den Lesevorgang beendet.
-
Wenn ein Leseblockdienst angefordert wird, wird die Zustandsmanager-Softwarekomponente so konfiguriert, dass ermittelt wird, ob der RTE-Fehler auftritt, und wenn festgestellt wird, dass der RTE-Fehler auftritt, wird der Lesevorgang beendet.
-
Die Zustandsmanager-Softwarekomponente ist so konfiguriert, dass sie für einen Block, in dem das Einlesen der Daten abgeschlossen ist, ein Flag auf „ein“ setzt, und wenn das Lesen von Daten für alle Blöcke des NvM abgeschlossen ist, Flags initialisiert.
-
Beim Empfang des Lese-Ein-Befehls ist die ASW so konfiguriert, dass sie eine vorgegebene Lesefunktion (Rte_Read) aufruft und Lesedaten an die ASW überträgt.
-
Die ASW ist so konfiguriert, dass sie die Daten über eine vorgegebene Schreibfunktion (Rte_Write) empfängt und die empfangenen Daten schreibt.
-
Figurenliste
-
Diese und/oder andere Merkmale von Ausführungsformen der Offenbarung werden aus der folgenden Beschreibung der Ausführungsformen, die in Verbindung mit den beigefügten Zeichnungen herangezogen wird, deutlich und leichter zu erkennen sein.
- 1 ist ein Diagramm, das ein Beispiel einer Architektur einer Automotive Open System Architecture (AUTOSAR)-Plattform veranschaulicht, die eine Architektur für eine Speicherverwaltung gemäß einer Ausführungsform aufweist;
- 2 ist ein Diagramm, das ein Beispiel einer Architektur für eine Speicherverwaltung gemäß einer Ausführungsform veranschaulicht;
- 3 ist ein Diagramm, das ein Beispiel für Blöcke in einer Architektur gemäß einer Ausführungsform veranschaulicht;
- 4A, 4B und 4C sind Flussdiagramme eines Schreibvorgangs einer Architektur zur Speicherverwaltung gemäß einer Ausführungsform; und
- 5A und 5B sind Flussdiagramme eines Lesevorgangs einer Architektur zur Speicherverwaltung gemäß einer Ausführungsform.
-
DETAILLIERTE BESCHREIBUNG DER ILLUSTRATIVEN AUSFÜHRUNGSFORMEN
-
Gleiche Bezugszeichen bezeichnen in der gesamten Spezifikation ähnliche Elemente. Außerdem beschreibt diese Spezifikation nicht alle Elemente gemäß Ausführungsformen der Offenbarung und Beschreibungen, die im Stand der Technik bekannt sind, auf die die Offenbarung sich bezieht, oder überlappende Abschnitte werden weggelassen. Die Ausdrücke wie „~teil“, „~element“, „~modul“, „~block“ und dergleichen können sich auf mindestens einen Prozess beziehen, der von mindestens einer Hardware oder Software verarbeitet wird. Gemäß Ausführungsformen kann eine Vielzahl von „~teilen“, „~elementen“, „~modulen“, „~blocken“ als einzelnes Element umgesetzt sein, oder ein einzelnes von einem „~teil“, „~element“, „~modul“, „~block“ kann eine Vielzahl von Elementen enthalten.
-
Es versteht sich, dass, wenn ein Element als mit einem anderen Element „verbunden“ bezeichnet wird, es direkt oder indirekt mit dem anderen Element verbunden werden kann, wobei die indirekte Verbindung eine „Verbindung“ über ein drahtloses Kommunikationsnetzwerk umfasst.
-
Es versteht sich, dass der Begriff „enthält“, wenn er in dieser Spezifikation verwendet wird, das Vorhandensein von angegebenen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen und/oder Komponenten angibt, aber das Vorhandensein oder Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon nicht ausschließt.
-
Es versteht sich, dass, obwohl die Begriffe erste, zweite usw. hier verwendet werden können, um verschiedene Elemente zu beschreiben, diese Elemente nicht durch diese Begriffe beschränkt werden sollten.
-
Es versteht sich, dass die Singularformen auch die Pluralformen einschließen sollen, sofern der Kontext nicht eindeutig etwas anderes vorschreibt.
-
Bezugszeichen, die für Verfahrensschritte verwendet werden, werden nur zur Vereinfachung der Erklärung verwendet, aber nicht, um eine Reihenfolge der Schritte zu beschränken. Sofern der Kontext nicht eindeutig etwas anderes vorschreibt, kann die schriftliche Anordnung anders ausgeübt werden.
-
Nachstehend werden ein Funktionsprinzip und Ausführungsformen unter Bezugnahme auf die beigefügten Zeichnungen ausführlich beschrieben.
-
1 ist ein Diagramm, das ein Beispiel einer Architektur einer Automotive Open System Architecture (AUTOSAR)-Plattform mit einer Architektur für eine Speicherverwaltung gemäß einer Ausführungsform veranschaulicht.
-
AUTOSAR ist eine standardisierte und offene Plattform. Dabei bedeutet „standardisiert“, dass ein Funktionsname, eine Funktion, ein Rückgabewert usw. vordefiniert sind. „Offen“ bedeutet, dass sie jedem zur Verfügung steht.
-
Wie in 1 gezeigt, ist die Plattformarchitektur von AUTOSAR eine mehrschichtige Architektur, und die Wartung des Systems ist einfach, da die Schichten getrennt sind.
-
Die AUTOSAR-Plattform, d.h. die mehrschichtige Architektur, ermöglicht eine hardwareunabhängige Softwareentwicklung und verbessert die Wiederverwendbarkeit und Skalierbarkeit.
-
Die AUTOSAR-Plattform umfasst eine Anwendungsschicht 100, eine Laufzeitumgebungs-(RTE)-Schicht 200 und eine Basissoftwareschicht 300.
-
Die Anwendungsschicht 100 ist eine Plattform, auf der eine Basissoftware (BSW) zur Ansteuerung einer elektronischen Steuereinheit (ECU) für Fahrzeuge und eine hardwareunabhängige Anwendungssoftware (ASW) integriert sind.
-
Die Anwendungsschicht 100 kann eine Mehrzahl von Softwarekomponenten (SWCs) umfassen, von denen jede eine Fahrzeugsteuerlogik umfasst.
-
Die SWC ist eine unabhängige Ausführungseinheit und kann abhängig von einem zu steuernden Objekt in eine Motorsteuerungs-Softwarekomponente, eine Batteriesteuerungs-Softwarekomponente, eine Modussteuerungs-Softwarekomponente, und eine Benutzerschnittstellen-Softwarekomponente unterteilt werden.
-
Die SWC kann auch in eine Aktuator-Softwarekomponente, eine Sensor-Softwarekomponente, eine Anwendungs-Softwarekomponente (ASW) 110, eine lo-Konverter-Softwarekomponente, eine Ressourcenmonitor-Softwarekomponente, eine Diagnose-Softwarekomponente, eine Test-Softwarekomponente, und eine ZustandsManager-Softwarekomponente 120 unterteilt werden.
-
Die ASW 110 führt einen Algorithmus für mindestens eine in einem Fahrzeug durchgeführte Funktion durch und ist für eine tatsächliche Funktion des Fahrzeugs verantwortlich.
-
Der ASW 110 ist in ein Client/Server-Protokoll oder in ein Sender/Empfänger-Protokoll unterteilt.
-
Das Client/Server-Protokoll ist eine Remote-Prozedur-Aufrufverfahren und ein weit verbreitetes Kommunikationsverfahren in einem verteilten System.
-
Im Client/Server-Protokoll ist ein Anbieter eines Remotedienstes ein Server und ein Benutzer des Remotedienstes ist ein Client. Wenn der Client nach der Initialisierung einer Kommunikation einen bestimmten Dienst anfordert, liefert der Server die erforderlichen Parameter an den Client.
-
Beispielsweise kann der Client/Server in einem Aktuator verwendet werden, um eine Funktion anzufordern und auszuführen.
-
Das Sender/Empfänger-Protokoll ist ein Nachrichtenübertragungsverfahren und ein asynchrones Kommunikationsprotokoll, bei dem ein Sender Informationen an einen einzelnen von einer Vielzahl von Empfängern sendet.
-
Beispielsweise kann der Sender/Empfänger in einem Sensor im Hinblick auf das Senden und Empfangen von Daten verwendet werden.
-
Die ASW 110 wird als „Lauffähiges“ bezeichnet, und „Lauffähiges“ (engl. „runnable“) wie oben definiert, wird von einem Betriebssystem (OS) geplant.
-
Da jede SWC nicht in der Lage ist, direkt mit Hardware oder einem Betriebssystem (d.h. OS) verbunden zu sein, kann ein Thread oder Prozess möglicherweise nicht implementiert werden. Stattdessen können einzelne Funktionen von der SWC, die während der Laufzeit ausgeführt werden, von dem „Runnable“ („Lauffähiges“) ausgeführt werden.
-
Gemäß einer Spezifikation eines virtuellen funktionalen Busses (VFB) ist das Runnable definiert als die Reihenfolge der Anweisungen, die vom RTE 200 gestartet werden können.
-
Die SWC kann eine Vielzahl von Runnables aufweisen.
-
Ein Mapping zwischen dem Betriebssystem (OS) und dem Runnable in der SWC wird durch Setzen von mindestens einer ECU erstellt. Das Mapping wird von der RTE aufgerufen und kann bei der Planung verwendet werden.
-
Die Zustandsmanager-Softwarekomponente 120 ist eine Softwarekomponente, die einen nichtflüchtigen Speichermanager (NvM) 311 und ein Fehlerdiagnoseereignis verwaltet und als Schnittstelle für das Starten/Herunterfahren der Sequenzverwaltung arbeitet.
-
Die ASW 110 und die Zustandsmanager-Softwarekomponente 120 in der Anwendungsschicht 100 können zur Verwaltung eines nichtflüchtigen Speichers verwendet werden.
-
Die RTE 200 mappt mindestens eine SWC in der Anwendungsschicht 100 unabhängig auf mindestens eine Hardware und eine ECU.
-
Durch die Verwendung der RTE 200 kann ein Signal von einem Sensor oder Aktuator gelesen werden, der mit einem anderen Controller (Steuergerät) verbunden ist, und ein Steuersignal kann ausgegeben werden.
-
Die Signallesung und -ausgabe ist verfügbar, da die RTE 200 eine gemeinsame Anwendungsprogrammierschnittstelle (Application Programming Interface, API) für eine Anwendung bereitstellt, indem sie sowohl ein externes Kommunikationsverfahren einer ECU abstrahiert, das ein Netzwerk wie ein Controller Area Network (Steuergerätenetz, CAN, FlexRay, lokales Verbindungsnetzwerk (LIN) und medienorientierter Systemtransport (MOST) und eine internes Kommunikationsverfahren verwendet.
-
Die RTE 200 kann unabhängig voneinander eine ECU mit einer Kommunikation zwischen den SWCs in der Anwendungsschicht 100 und einem Kommunikationsschnittstellen-Mapping zwischen der SWC und dem BSW bereitstellen.
-
Das heißt, die RTE 200 verbindet die ASW 110 und die BSW 300 beim Datenaustausch und Interagieren.
-
Die RTE 200 kann die ASW und Hardware trennen.
-
Die RTE 200 ist eine Umgebung, in der die VFB-Kommunikationsstruktur implementiert ist.
-
Da die Anforderungen der RTE 200 in Abhängigkeit von einer auf einer Oberseite der RTE 200 ausgeführten ASW variieren, muss die RTE 200 maßgeschneidert werden.
-
Eine endgültige RTE, der auf eine Setup-Aufgabe zugeschnitten ist, kann für jede ECU variieren.
-
Die BSW 300 bietet Dienste für eine obere Schicht, indem sie die ECU und Hardware abstrahiert.
-
Die BSW 300 umfasst eine Serviceschicht 310, eine ECU-Abstraktionsschicht (EAL) 320, eine Mikrocontroller-Abstraktionsschicht (MCAL) 330, und eine komplexe Gerätetreiberschicht 340.
-
Die Serviceschicht 310 ist eine oberste Schicht in der BSW 300 und bietet einen Dienst zur Nutzung von Mikrocontroller-Ressourcen in der Anwendungsschicht 100.
-
Während der Zugriff auf eine IO-Hardware von der EAL 320 verwaltet wird, bietet die Serviceschicht 310 verschiedene Hintergrundfunktionen (Kommunikation, Speicher und Betriebssystem (OS)) für den Systembetrieb und die Gesamtsteuerung der Module in der BSW 300.
-
Die Serviceschicht 310 kann als OS (Betriebssystem), Zeitplan-Manager, Netzwerkkommunikationsmanager, Speichermanager, Diagnosedienst, ECU-Zustandsmanager und Watchdog (Überwachung) arbeiten.
-
Das heißt, die Serviceschicht 310 kann ein Betriebssystem, einen Systemdienst, einen Speicherdienst und einen Kommunikationsdienst umfassen.
-
Da es für das Betriebssystem effizient ist, eine Hardware direkt zu steuern, liegt die Serviceschicht 310 unter der MCAL 330.
-
Der Systemdienst ist ein Satz von Funktionen und assoziierten Modulen, die gemeinsam verwendet werden können, wie eine Fehlerverwaltungsbibliothek wie eine zyklische Redundanzprüfung (CRC) und Echtzeitbetriebssystemdienst (RTOS) einschließlich Timerdienst. Der Systemdienst bietet auch einen Basisdienst eines Mikrocontrollers in den BSW und ASW Modulen.
-
Der Speicherdienst kann den NvM 311 enthalten und Abstraktionen für Speicherpositionen und Speichereigenschaften bereitstellen.
-
Außerdem verwaltet der Speicherdienst die Speicherung und das Laden von Daten im nichtflüchtigen Speicher, die Datenverifizierung mithilfe von Prüfsummen und die stabile Datenspeicherung.
-
Der Speicherdienst führt den Zugriff auf Speichercluster, Geräte bzw. Einrichtungen oder Softwarefunktionen zum Lesen und Schreiben von Daten in dem nichtflüchtigen Speicher wie einem Flash- oder elektrisch löschbaren programmierbaren Nurlesespeicher (EEPROM) durch.
-
Der NvM 311 führt eine Datenspeicherung und -wartung in dem nichtflüchtigen Speicher entsprechend den individuellen Anforderungen einer Fahrzeugumgebung durch.
-
Das heißt, der NvM 311 verwaltet nichtflüchtige Daten der EEPROM- und/oder Flash-EEPROM-Emulation.
-
Der Kommunikationsdienst kann Module für die Fahrzeugnetzwerkkommunikation wie CAN, LIN, FlexRay und MOST umfassen.
-
Die Kommunikationsdienst koppelt von der Anwendungsschicht 100 zu einem Kommunikationstreiber durch Kommunikationshardwareabstraktion. Das heißt, der Kommunikationsdienst verbindet sich mit einem Fahrzeugnetzwerk über dieselbe Schnittstelle unabhängig vom Typ des Fahrzeugnetzwerks und verwaltet das Netzwerk.
-
Die EAL 320 verbindet Treiber der MCAL 330 mit einer oberen Schicht.
-
Die EAL 320 dient dazu, die gleiche Schnittstelle zu der ASW bereitzustellen, ohne eine Hardwareschaltung zu verlagern, wenn ein externes Gerät wie ein Sensor oder Aktuator an eine ECU angeschlossen wird.
-
Die EAL 320 abstrahiert alle grundlegenden Komponenten einer ECU. Konzeptionell kann eine ECU auch einen größeren Umfang umfassen als eine Mikrosteuereinheit (MCU).
-
Die EAL 320 bietet eine hardwareunabhängige Anwendungsprogrammierschnittstelle (API).
-
Dabei kann die Hardware sowohl innere als auch äußere Komponenten eines Mikrocomputers umfassen.
-
Das heißt, die EAL 320 stellt eine API für ein Peripheriegerät bereit, um auf verschiedene Peripheriegeräte innerhalb/außerhalb des Mikrocontrollers zuzugreifen, und verbindet sich mit einem bestimmten Port oder einer bestimmten Schnittstelle des Mikrocontrollers.
-
Die EAL 320 kann Treiber für externe Geräte und Schnittstellen für interne und externe Peripheriegeräte (IO, Speicher, Watchdog, Kommunikation) bereitstellen.
-
Die EAL 320 umfasst eine I/O-Hardwareabstraktion, eine Kommunikationshardwareabstraktion, eine Speicherhardwareabstraktion und eine Onboard-Geräteabstraktion.
-
Die I/O-Hardwareabstraktion dient zur Abstraktion der Standorte von peripheren I/O-Geräten und dem ECU-Hardwarelayout und zum Ausblenden des ECU-Hardwarelayouts von einer oberen Softwareschicht.
-
Die Kommunikationshardwareabstraktion führt die Abstraktion auf einem Kommunikationscontroller und dem zugehörigen ECU-Hardwarelayout durch.
-
Die Speicherhardwareabstraktion abstrahiert eine speicherbezogene Hardware.
-
Die Speicherhardwareabstraktion kann zur Verwaltung von nichtflüchtigem Speicher verwendet werden.
-
Die Speicherhardwareabstraktion kann ein Speicherabstraktionsschnittstellenmodul (Memlf) 321 und eine Flash-EEPROM-Emulation (Fee) 322 umfassen.
-
Das Memlf 321 ermöglicht die Abstraktion in der Fee 322.
-
Das Memlf 321 kann die Abstraktion in einem EEPROM-Abstraktionsmodul (EA) ermöglichen (nicht gezeigt).
-
Das EA-Modul bietet Dienste zum Lesen, Schreiben und Löschen von Daten aus dem EEPROM und zum Vergleich eines Datenblocks im EEPROM mit einem Datenblock im Speicher (z. B. RAM).
-
Das Memlf 321 stellt dem NvM 311 eine virtuelle Partitionierung in einem einheitlichen linearen Adressraum zur Verfügung.
-
Die Fee 322 abstrahiert ein Gerät, ein spezifisches Adressierungsschema und eine Partitionierung.
-
Die Fee 322 bietet dem NvM 311 ein virtuelles Adressierungsschema, Partitionierung, und virtuelle unbegrenzte Löschzyklen.
-
Die Onboard-Geräteabstraktion abstrahiert eine onboard-bezogene Hardware.
-
Die MCAL 330 ist die unterste Schicht in der AUTOSAR-Plattform, und unterhalb der MCAL 330 kann eine Hardwareschicht (nicht gezeigt) vorgesehen sein.
-
Die MCAL 330 bietet eine Gerätetreiber-API, um MCU-Ressourcen oder Funktionen einer oberen Schicht zu nutzen.
-
Die MCAL 330 enthält einen Mikrocontroller-Treiber, Speichertreiber, Kommunikationstreiber und IO-Treiber.
-
Der Mikrocontroller-Treiber bietet eine Funktion zum direkten Zugriff auf einen Mikrocontroller und eine Peripherie-Schnittstelle.
-
Der Speichertreiber ist ein Treiber für eine Speicherzuordnung eines externen Speichergeräts und eines On-Chip-Speichers innerhalb des Mikrocontrollers.
-
Ein Flash-Treiber (Fls) 331 initialisiert einen Flash und liest und schreibt in einen Flash-Speicher.
-
Der Fls 331 kann einen Dienst zum Vergleichen eines Datenblocks mit einem Datenblock des Speichers durchführen.
-
Der Kommunikationstreiber ist ein Treiber für die Fahrzeugkommunikation und die Onboard-Kommunikation wie eine Datenverbindungsschicht aus SPI, I2C, CAN und OSI.
-
Der IO-Treiber ist ein Treiber für analoge digitale I/O wie ADC, PW und DIO usw.
-
Der komplexe Gerätetreiber (CDD) 340 unterstützt die Kompatibilität zwischen einem externen Gerät und der Plattform während des Betriebs.
-
Der CDD 340 wird zur Steuerung eines Sensors und Aktuators verwendet, der spezifische Timing-Anforderungen hat oder kein in der AUTOSAR Plattform definiertes Modul hat. Das heißt, der CDD 340 kann direkt auf den Mikrocomputer zugreifen, um den Sensor oder Aktuator zu steuern.
-
2 ist ein Diagramm, das ein Beispiel einer Architektur zur Speicherverwaltung gemäß einer Ausführungsform veranschaulicht. 3 ist ein Diagramm, das ein Beispiel von Blöcken in dem NvM gemäß einer Ausführungsform veranschaulicht.
-
Die Architektur für die Speicherverwaltung umfasst die ASW 110 und die Zustandsmanager-Softwarekomponente 120 in der Anwendungsschicht 100, die RTE 200 und den NvM 311, das Memlf 321, die Fee 322 und den Flash-Treiber (Fls) 331 in der in 1 dargestellten AUTOSAR-Plattform.
-
Die ASW 110 prüft Daten, die in die Zustandsmanager-Softwarekomponente 120 als Antwort auf eine Anforderung der Zustandsmanager-Softwarekomponente 120 geschrieben werden sollen, und überträgt die geprüften Daten.
-
Das heißt, die ASW 110 kann Daten, die über eine vorbestimmte Lesefunktion (Rte_Read) gelesen werden, an die Zustandsmanager-Softwarekomponente 120 übertragen.
-
Die ASW 110 kann Daten speichern, die von der Zustandsmanager-Softwarekomponente 120 empfangen werden.
-
Die ASW 110 kann Daten über eine vorbestimmte Schreibfunktion (Rte_Write) empfangen und die empfangenen Daten schreiben.
-
Die Zustandsmanager-Softwarekomponente 120 kann einen Vorgang zum Lesen von in einem nichtflüchtigen Speicher gespeicherten Daten oder zum Schreiben von Daten in den nichtflüchtigen Speicher steuern, wenn ein Fahrzeug ein- oder ausgeschaltet wird.
-
Genauer gesagt liest die Zustandsmanager-Softwarekomponente 120 Daten, die von der ASW 110 in den NvM 311 geschrieben werden sollen.
-
Bei der Steuerung des Schreibvorgangs kann die Zustandsmanager-Softwarekomponente 120 von dem NvM 311 der in 3 gezeigten BSW einen Fehlerstatus-Check-Service anfordern.
-
Wenn festgestellt wird, dass ein Ergebnis der Überprüfung eines Status eines einzelnen Blocks bei der Steuerung des Schreibvorgangs nicht in einem ausstehenden Zustand („pending state“) ist, kann die Zustandsmanager-Softwarekomponente 120 einen Schreibblockdienst (write block service von dem NvM 311 anfordern, indem sie die gelesenen Daten als Faktor verwendet.
-
Die Zustandsmanager-Softwarekomponente 120 kann für einen Block, in dem das Schreiben von Daten abgeschlossen ist, ein „Flag“ auf „ein“ setzen, und wenn das Schreiben von Daten für alle Blöcke abgeschlossen ist, Flags initialisieren und steuern, um auf andere Daten zu schreiben.
-
Wenn das Schreiben aller Daten in die Zustandsmanager-Softwarekomponente 120 abgeschlossen ist, ruft die Zustandsmanager-Softwarekomponente 120 eine Abschlussfunktion (NvM JobFinished) aus der BSW 300 auf.
-
Bei der Steuerung des Lesevorgangs kann die Zustandsmanager-Softwarekomponente 120 von dem NvM 311 der BSW einen Fehlerzustandsüberprüfungsdienst anfordern, um einen Status eines einzelnen Blocks zu überprüfen.
-
Wenn festgestellt wird, dass ein Ergebnis der Prüfung bei der Steuerung des Lesevorgangs nicht in einem ausstehenden Zustand ist, kann die Zustandsmanager-Softwarekomponente 120 einen Leseblockdienst von dem NvM 311 anfordern.
-
Die Zustandsmanager-Softwarekomponente 120 kann für einen Block, in dem das Auslesen von Daten abgeschlossen ist, ein Flag auf „ein“ setzen, und wenn das Auslesen von Daten für alle Blöcke abgeschlossen ist, Flags initialisieren und steuern, um andere Daten auszulesen.
-
Die Zustandsmanager-Softwarekomponente 120 führt den Lesevorgang in Hardware als Reaktion auf einen Leseblockdienst (ReadBlock-Dienst) aus.
-
Wenn das Auslesen aller Daten in der Zustandsmanager-Softwarekomponente 120 abgeschlossen ist, ruft die Zustandsmanager-Softwarekomponente 120 die Abschlussfunktion (NvM JobFinished) aus der BSW 300 auf.
-
Bei der Ausführung des Schreib- und Lesevorgangs kann die Zustandsmanager-Softwarekomponente 120 einen Rte-Fehler anhand eines Rückgabewerts einer Rte-Funktion von der RTE 200 überprüfen.
-
Beispielsweise kann die Zustandsmanager-Softwarekomponente 120 bei der Durchführung des Lesevorgangs von Daten aus der ASW 110 den Rte-Fehler anhand des Rückgabewerts der Rte-Funktion überprüfen.
-
Beim Anfordern des Fehlerstatusüberprüfungsdienstes (Get Error Status) und eines Schreibblockdiensts von dem NvM 311 während des Schreibvorgangs kann die Zustandsmanager-Softwarekomponente 120 den Rte-Fehler unter Verwendung des Rückgabewerts der Rte-Funktion von der RTE 200 überprüfen.
-
Beim Anfordern des Fehlerstatusüberprüfungsdienstes (Get Error Status) und eines Leseblockdienstes vom NvM 311 während des Lesevorgangs kann die Zustandsmanager-Softwarekomponente 120 den Rte-Fehler unter Verwendung des Rückgabewerts der Rte-Funktion von der RTE 200 überprüfen.
-
Wenn der Lesevorgang abgeschlossen ist, kann die Zustandsmanager-Softwarekomponente 120 den Rte-Fehler unter Verwendung des Rückgabewerts der Rte-Funktion von der RTE 200 überprüfen.
-
Das RTE 200 führt eine Zuordnung (ein Mapping) zwischen der ASW 110 und der Zustandsmanager-Softwarekomponente 120 durch und überträgt Daten und Funktionsaufrufdaten zwischen der ASW 110 und der Zustandsmanager-Softwarekomponente 120.
-
Die RTE 200 führt ein Mapping zwischen dem NvM 311 und der Zustandsmanager-Softwarekomponente 120 durch und überträgt und empfängt Daten zwischen dem NvM 311 und der Zustandsmanager-Softwarekomponente 120.
-
Wenn während des Schreibvorgangs oder Lesevorgangs die Anforderung des Fehlerstatusüberprüfungsdienstes für einen einzelnen Block empfangen wird, kann der NvM 311 in der BSW 300 einen Fehlerstatus für den einzelnen Block überprüfen und Informationen über den Fehlerstatus für den einzelnen Block an die Zustandsmanager-Softwarekomponente 120 übermitteln.
-
Wenn die Schreibblockdienstanforderung empfangen wird, kann der NvM 311 für jeden Block einen Datenschreibvorgang ausführen, und wenn der Datenschreibvorgang für alle Blöcke abgeschlossen ist, kann der NvM 311 die Abschlussfunktion (NvM JobFinished) zur Zustandsmanager Softwarekomponente 120 übertragen.
-
Wenn die Leseblockdienstanforderung empfangen wird, kann der NvM 311 für jeden Block einen Datenlesevorgang durchführen, und wenn der Datenlesevorgang für alle Blöcke abgeschlossen ist, kann der NvM 311 die Abschlussfunktion (NvM JobFinished) an die State Manager-Softwarekomponente 120 übertragen.
-
Das Memlf 321, die Fee 322 und der Fls 331 sind Standardmodule für einen Verwaltungsdienst für nicht-flüchtigen Speicher.
-
4A, 4B und 4C sind Flussdiagramme eines Schreibvorgangs einer Architektur zur Speicherverwaltung gemäß einer Ausführungsform.
-
Beim Empfang eines Schreib-Ein-Befehls des NvM 311 startet die Architektur einen Schreibzyklus (501).
-
Dabei wird der Schreib-Ein-Befehl bei Bedarf durch eine umfassende Ermittlung verschiedener Zustände eines Fahrzeugs angefordert und kann hauptsächlich angefordert werden, wenn das Fahrzeug ausgeschaltet ist (Key Off).
-
Die Architektur bestimmt, ob ein einzelner Block in diesem Zyklus (oder einem aktuellen Zyklus) einen Schreibblockdienst von der BSW 300 angefordert hat (502).
-
Zu der Bestimmung, ob der Schreibblockdienst angefordert wurde, gehört auch die Bestimmung, ob ein Schreibblockausführungs-Überprüfungsflag ein ist.
-
Da ein Schreibvorgang mit einer Lebensdauer des NvM 311 zusammenhängt, wird nur einmal geprüft, ob die Anzahl der Schreibblockdienste beim Empfang des Schreib-Ein-Befehls ausgeführt werden. Die Anzahl der Schreibblockdienste kann eine voreingestellte Zahl sein.
-
Wenn der Schreibblockdienst in diesem Zyklus angefordert wurde, beendet die Architektur diesen Zyklus für den entsprechenden Block.
-
Im Gegensatz dazu liest (503) die Architektur, wenn der Schreibblockdienst in diesem Zyklus nicht angefordert wurde, Daten, die an den nichtflüchtigen Speicher geschrieben werden sollen, aus der ASW 110 durch Aufruf einer vorgegebenen Lesefunktion (Rte_Read), und ermittelt dann unter Verwendung eines Rückgabewert einer Rte-Funktion, ob ein Rte-Fehler auftritt (504).
-
Daher kann während des Datenaustauschs schrittweise durch die RTE überprüft werden, ob ein Fehler auftritt, wodurch die Zuverlässigkeit der Daten verbessert wird.
-
Wenn festgestellt wird, dass der Rte-Fehler auftritt, beendet die Architektur den Schreibvorgang für den entsprechenden Block.
-
Wenn jedoch festgestellt wird, dass der Rte-Fehler nicht auftritt, fordert die Architektur von der BSW 300 einen Error Status Check-Dienst (GetErrorStatus) an, um einen Status eines einzelnen Blocks zu überprüfen, und ermittelt, ob ein Ergebnis des Error Status Check-Dienstes (GetErrorStatus) sich in einem anhängigen bzw. ausstehenden Zustand (505) (pending state) befindet.
-
Durch die voranstehenden Vorgänge wird der Dienst von dem NvM 311 nur dann angefordert, wenn kein Fehler gefunden wird, indem ein aktueller Status des NvM 311 überprüft wird, und somit kann die Zuverlässigkeit verbessert und die Lebensdauer kann verlängert werden.
-
Bei der Abfrage des Fehlerstatus-Überprüfungsdienstes (Error Status Check-Dienstes; GetErrorStatus) von der BSW 300 ermittelt die Architektur anhand eines Rückgabewerts einer Rte-Funktion (506), ob ein Rte-Fehler auftritt.
-
Wenn festgestellt wird, dass der Rte-Fehler auftritt, beendet die Architektur den Schreibvorgang für den entsprechenden Block.
-
Wenn festgestellt wird, dass sich ein Ergebnis des Fehlerstatus-Überprüfungsdienstes (GetErrorStatus) in einem ausstehenden Zustand befindet, beendet die Architektur ebenfalls den Schreibvorgang für den entsprechenden Block.
-
Wenn festgestellt wird, dass sich das Ergebnis des Fehlerstatus-Überprüfungsdienstes (GetErrorStatus) nicht in einem ausstehenden Zustand befindet und der Rte-Fehler nicht auftritt, fordert die Architektur einen Schreibblockdienst von der BSW 300 an, indem sie die gelesenen Daten als Faktor verwendet (507), und bestimmt dann unter Verwendung eines Rückgabewerts einer Rte-Funktion (508), ob ein Rte-Fehler auftritt.
-
Wenn festgestellt wird, dass der Rte-Fehler auftritt, beendet die Architektur den Schreibvorgang für den entsprechenden Block.
-
Wenn jedoch festgestellt wird, dass der Rte-Fehler nicht auftritt, setzt die Architektur ein Schreibblock-Ausführungs-Check-Flag eines einzelnen Blocks auf „ein“ (509).
-
Die Architektur bestimmt, ob die Schreibblock-Ausführungs-Check-Flags aller Blöcke ein (d.h. aktiviert) sind (510). Wenn festgestellt wird, dass die Schreibblock-Ausführungs-Check-Flags aller Blöcke ein sind, initialisiert die Architektur die Flags, so dass ein Zyklus von Anfang an durch einen nächsten Schreibbefehl (NvM Write) ausgeführt werden kann.
-
Das Flag, das eine Initialisierung erfordert, kann ein Flag für einen Schreibbefehl und ein Schreibblock-Ausführungs-Check-Flag eines einzelnen Blocks enthalten. Das heißt, die Architektur kann das Flag für den Schreibbefehl (NvM Write) und das Schreibblock-Ausführungs-Check-Flag eines einzelnen Blocks auf „aus“ (off) setzen (511).
-
Die Architektur führt einen Schreibvorgang auf den nichtflüchtigen Speicher in der Hardware aus, nachdem sie den Schreibblockdienst angefordert hat, und wenn der Schreibvorgang abgeschlossen ist, kann eine Abschlussfunktion (NvM JobFinished) von der BSW 300 aufgerufen werden.
-
Wenn der Aufruf durch die Abschlussfunktion (NvM JobFinished) ein ist (512), bestimmt die Architektur, ob ein Datenschreibvorgang erfolgreich ist (513).
-
Wenn der Datenschreibvorgang fehlschlägt, kann die Architektur den Schreibblockdienst von der BSW 300 erneut anfordern und ein Schreibabschluss-Flag (WriteComplete-Flag) des einzelnen Blocks auf „aus“ setzen(514).
-
Wenn der Datenschreibvorgang erfolgreich ist, kann die Architektur das Schreibabschluss-Flag, was angibt, dass ein endgültiger Schreibvorgang des einzelnen Blocks abgeschlossen ist, auf „ein“ setzen (515).
-
Anschließend kann die Architektur den Schreibvorgang erneut ausführen.
-
Die Architektur kann die Schreibabschluss-Flags aller einzelnen Blöcke überprüfen, und wenn die Schreibabschluss-Flags aller einzelnen Blöcke ein (aktiviert) sind (516), kann sie alle Schreibabschluss-Flags (All NvM WriteComplete Flags) auf „ein“ setzen (517).
-
Der obige Vorgang ist dafür gedacht die Energie der ECU auszuschalten, nachdem bestätigt wurde, dass der Schreibvorgang für alle einzelnen Blöcke normal abgeschlossen ist, da ein Schreibbefehl angefordert wird, wenn ein Fahrzeug abgeschaltet ist bzw. wird (Key Off).
-
Daher kann durch Empfangen von Feedback zu dem Ergebnis, das nach dem Anfordern des Schreibdienstes erhalten wurde, im Falle eines Ausfalls zusätzliche Logik hinzugefügt werden, und das Fahrzeug wird ausgeschaltet, nachdem überprüft wurde, ob der Schreibdienst aller Blöcke normaler ausgeführt ist. Dementsprechend kann die Zuverlässigkeit verbessert werden.
-
Außerdem kann durch die Steuerung des Schreibens von Daten in den nichtflüchtigen Speicher die Zuverlässigkeit und Komplementarität eines Schreibblocks in dem NvM 311 verbessert werden.
-
Die 5A und 5B sind Flussdiagramme eines Lesevorgangs einer Architektur zur Speicherverwaltung gemäß einer Ausführungsform.
-
Die Architektur bestimmt, ob ein Lesebefehl (NvM Read) ein ist (601), und wenn festgestellt wird, dass der Lesebefehl (NvM Read) empfangen wird, führt sie einen Lesezyklus durch.
-
Eine Bestimmung, ob der Lesebefehl (NvM Read) ein ist, umfasst, ob der Lesebefehl (NvM Read) empfangen wird.
-
Der Lesebefehl (NvM Read) wird bei Bedarf angefordert, indem verschiedene Zustände eines Fahrzeugs umfassend bestimmt werden, und kann hauptsächlich empfangen werden, wenn das Fahrzeug eingeschaltet wird (Key On).
-
Die Architektur bestimmt, ob ein Leseblock-Ausführungs-Check-Flag ein ist (602).
-
Die Architektur prüft, ob ein einzelner Block in diesem Zyklus einen Leseblockdienst (ReadBlock-Dienst) von der BSW 300 angefordert hat, und wenn festgestellt wird, dass der Leseblockdienst (ReadBlock-Dienst) angefordert wurde, beendet die Architektur diesen Zyklus (d.h. aktueller Zyklus) für den entsprechenden Block.
-
Da Lesen und Schreiben sich auf die Lebensdauer des NvM 311 und des nichtflüchtigen Speichers beziehen, wird nur einmal geprüft, ob die Anzahl der Leseblockdienste beim Empfang des Lesebefehls (NvM Read) ausgeführt werden.
-
Wenn festgestellt wird, dass der Leseblockdienst (ReadBlock-Dienst) nicht angefordert wurde, fordert die Architektur von der BSW 300 einen Fehlerstatus-Überprüfungsdienst (GetErrorStatus) an, um einen Status eines einzelnen Blocks zu überprüfen, und ermittelt, ob sich ein Ergebnis des Fehlerstatus-Überprüfungsdienstes (GetErrorStatus) in einem ausstehenden Zustand (pending state) befindet (603).
-
Der Dienst wird von dem NvM 311 nur angefordert, wenn kein Fehler gefunden wird, indem ein aktueller Status des NvM 311 überprüft wird, und somit kann die Zuverlässigkeit verbessert und die Lebensdauer verlängert werden.
-
Außerdem bestimmt die Architektur bei der Anforderung des Fehlerstatus-Überprüfungsdienstes (GetErrorStatus) unter Verwendung eines Rückgabewerts einer Rte-Funktion, ob ein Rte-Fehler auftritt (604).
-
Wenn festgestellt wird, dass der Rte-Fehler auftritt, beendet die Architektur einen Lesevorgang für den entsprechenden Block.
-
Wenn festgestellt wird, dass sich das Ergebnis des Fehlerstatus-Überprüfungsdienstes (GetErrorStatus) in einem ausstehenden Zustand befindet und der Rte-Fehler auftritt, beendet die Architektur den Lesevorgang für den entsprechenden Block.
-
Wenn festgestellt wird, dass sich das Ergebnis des Fehlerstatus-Überprüfungsdienstes (GetErrorStatus) nicht in einem ausstehenden Zustand befindet und der Rte-Fehler nicht auftritt, fordert die Architektur den Leseblockdienst (ReadBlock-Dienst) von der BSW 300 (605) an und bestimmt dann unter Verwendung eines Rückgabewerts einer Rte-Funktion, ob ein Rte-Fehler auftritt (606).
-
Wenn festgestellt wird, dass der Rte-Fehler auftritt, beendet die Architektur den Lesevorgang für den entsprechenden Block.
-
Wenn festgestellt wird, dass der Rte-Fehler nicht auftritt, setzt die Architektur ein Leseblock-Ausführungs-Check-Flag eines einzelnen Blocks auf „ein“ (607).
-
Die Architektur bestimmt, ob die Leseblock-Ausführungs-Check-Flags aller Blöcke ein sind (608), und wenn festgestellt wird, dass die Leseblock-Ausführungs-Check-Flags aller Blöcke ein sind, initialisiert die Architektur die Flags, so dass ein Zyklus durch einen nächsten Lesebefehl ausgeführt werden kann.
-
Dabei kann das initialisierte Flag ein Flag für einen Lesebefehl und ein Leseblock-Ausführungs-Check-Flag des einzelnen Blocks enthalten.
-
Das heißt, die Architektur kann das Flag für den Lesebefehl und das Leseblock-Ausführungs-Check-Flag des einzelnen Blocks auf „aus“ setzen (609).
-
Die Architektur führt einen Lesevorgang für den nichtflüchtigen Speicher in der Hardware aus, nachdem der Leseblockdienst angefordert wurde, und wenn der Lesevorgang abgeschlossen ist, kann eine Abschlussfunktion (NvM JobFinished) vo'n der BSW 300 aufgerufen werden.
-
Wenn in diesem Fall der Aufruf durch die Abschlussfunktion (NvM JobFinished) ein ist (610), bestimmt die Architektur, dass der Datenlesevorgang abgeschlossen ist, und bestimmt, ob der Datenlesevorgang erfolgreich ist (611).
-
Wenn festgestellt wird, dass der Datenlesevorgang fehlschlägt, fordert die Architektur von der BSW 300 einen Schreibblockdienst mit einem Anfangswert des einzelnen Blocks an und sendet den Anfangswert an die ASW 110 (612) durch Aufruf einer Schreibfunktion (Rte_Write).
-
Wenn festgestellt wird, dass die Datenleseoperation erfolgreich ist, ermittelt die Architektur einen Ergebniswert des Lesevorgangs, indem sie eine Lesefunktion (Rte_Read) aufruft, und sendet den ermittelten Ergebniswert an die ASW 110 (613). Außerdem bestimmt die Architektur unter Verwendung eines Rückgabewerts einer Rte-Funktion, ob ein Rte-Fehler auftritt (614).
-
Ob ein Fehler auftritt, kann beim Datenaustausch in der RTE schrittweise überprüft werden, wodurch die Zuverlässigkeit der Daten verbessert wird.
-
Wenn festgestellt wird, dass der Rte-Fehler auftritt, ruft die Architektur die Schreibfunktion (Rte_Write) erneut auf.
-
Wenn festgestellt wird, dass der Rte-Fehler nicht auftritt, initialisiert die Architektur ein Schreibabschluss-Flag (WriteComplete Flag) des einzelnen Blocks „aus“ (615).
-
Ein entsprechendes Flag wird beim Abschluss des Lesevorgangs initialisiert, da ein Ergebnis des Abschlusses eines Vorgangs für einen zweiten Schreibblockdienst möglicherweise nicht unterschieden werden kann, wenn eine Schreibblockoperation mehr als zweimal ausgeführt wird.
-
Die Architektur prüft die Leeabschluss-Flags (ReadComplete Flags) aller einzelnen Blöcke und ermittelt, ob die Leseabschluss-Flags aller einzelnen Blöcke ein sind (616). Wenn festgestellt wird, dass die Leseabschluss-Flags aller einzelnen Blöcke ein sind, setzt die Architektur alle Leseabschluss-Flags (alle NvM ReadComplete Flag) auf „ein“ (617).
-
Durch Empfangen von Feedback über das Ergebnis, das nach der Anforderung des Dienstes von dem NvM 311 erhalten wurde, kann im Fehlerfall eine zusätzliche Logik hinzugefügt werden, und durch die Überprüfung, ob der Dienst aller Blöcke normal in dem NvM 311 durchgeführt ist, können der ASW 110 zuverlässige Daten übermittelt werden.
-
Die Architektur kann den Lesevorgang im Falle eines Lesefehlers erneut ausführen.
-
Wenn festgestellt wird, dass ein Fehler in der RTE 200 auftritt, kann die Architektur durch einen erneuten Aufruf der Rte-Funktion auch erneut feststellen, ob ein Fehler auftritt.
-
Darüber hinaus kann die Architektur bestimmen, ob ein Fehler eine voreingestellte Anzahl von Malen auftritt.
-
Wie aus den voranstehenden Vorgängen ersichtlich ist, kann gemäß den Ausführungsformen der Offenbarung die Zuverlässigkeit der Daten durch die Überprüfung von Fehlern in allen Phasen während der Datenbewegung sichergestellt werden, wenn eine Laufzeitumgebungsfunktion und eine Basissoftwarefunktion in Bezug auf einen nichtflüchtigen Speicher verwendet werden.
-
Gemäß den Ausführungsformen der Offenbarung kann die Lebensdauer eines nichtflüchtigen Speichers erhöht werden, indem Aufrufe von Schreibblock- (WriteBlock) und Leseblock- (ReadBlock) Diensten minimiert werden.
-
Gemäß den Ausführungsformen der Offenbarung kann, wenn ein Fehler auftritt, während ein Schreibblock- (WriteBlock), ein Leseblock- (ReadBlock) und eine Laufzeitumgebungsfunktion verwendet werden, ein voreingestellter Zusatzcode verwendet werden, um eine schwerwiegende Fehlfunktion des Fahrzeugs zu verhindern und die Fehlfunktion wiederherzustellen.
-
Gemäß den Ausführungsformen der Offenbarung kann die Managementqualität des nichtflüchtigen Speichers sowie die Qualität, Marktfähigkeit, Sicherheit und Wettbewerbsfähigkeit eines Fahrzeugs verbessert werden.
-
Ausführungsformen können somit durch computerlesbaren Code/Anweisungen in/auf einem Medium, z. B. einem computerlesbaren Medium, implementiert werden, um mindestens ein Verarbeitungselement zur Implementierung irgendeiner voranstehend beschriebenen beispielhaften Ausführungsform zu steuern. Das Medium kann jedem/jeden Medium/Medien entsprechen, das/die die Speicherung und/oder Übertragung des computerlesbaren Codes ermöglicht/ermöglichen.
-
Der computerlesbare Code kann auf einem Medium aufgezeichnet oder über das Internet übertragen werden. Das Medium kann einen Nur-Lesespeicher (ROM), einen Arbeitsspeicher (RAM), Magnetbänder, Magnetplatten, Flash-Speicher, und optische Aufzeichnungsmedien umfassen.
-
Obwohl Ausführungsformen zu illustrativen Zwecken beschrieben wurden, werden Durchschnittsfachleute in dem technischen Gebiet erkennen, dass verschiedene Modifikationen, Ergänzungen und Substitutionen möglich sind, ohne vom Umfang und Grundgedanken der Offenbarung abzuweichen. Daher wurden Ausführungsformen nicht zu einschränkenden Zwecken beschrieben.
