DE19740525C1 - Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug - Google Patents

Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug

Info

Publication number
DE19740525C1
DE19740525C1 DE19740525A DE19740525A DE19740525C1 DE 19740525 C1 DE19740525 C1 DE 19740525C1 DE 19740525 A DE19740525 A DE 19740525A DE 19740525 A DE19740525 A DE 19740525A DE 19740525 C1 DE19740525 C1 DE 19740525C1
Authority
DE
Germany
Prior art keywords
data
flash memory
operating data
control system
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE19740525A
Other languages
English (en)
Inventor
Wille Eberhard De
Michael Dr Ulm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE19740525A priority Critical patent/DE19740525C1/de
Priority to FR9811354A priority patent/FR2768529B1/fr
Priority to GB9820021A priority patent/GB2330672B/en
Priority to JP10260316A priority patent/JPH11161563A/ja
Priority to US09/154,152 priority patent/US6167338A/en
Application granted granted Critical
Publication of DE19740525C1 publication Critical patent/DE19740525C1/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11CSTATIC STORES
    • G11C7/00Arrangements for writing information into, or reading information out from, a digital store
    • G11C7/20Memory cell initialisation circuits, e.g. when powering up or down, memory clear, latent image memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/654Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Abspei­ cherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug, das einen Rechner, einen RAM-Speicher und einen Flash-Speicher enthält. Bei diesen Da­ ten handelt es sich insbesondere um Betriebsdaten, die sich während des Betriebs des Steuersystems, zum Beispiel des Kraftfahrzeug-Steuersystems, ändern können und zum Beispiel adaptive Daten zur optimierten Ansteuerung von Komponenten des Steuersystems, zum Beispiel eines automatischen Getrie­ bes, Fehlerspeicherdaten, den aktuellen Kilometerstand, die Gesamtbetriebsdauer usw. repräsentieren können. Diese Be­ triebsdaten werden während des laufenden Betriebs von dem Steuersystem ermittelt und/oder aktualisiert und in einem RAM-Speicher (Direktzugriffsspeicher) für raschen Zugriff und rasche Änderung bereitgehalten. Beim Ausschalten des Steuer­ systems werden die aktualisierten Betriebsdaten dann in einen nichtflüchtigen Speicher, zum Beispiel in einem EEPROM, ge­ speichert und beim Neustart wieder aus dem EEPROM in den RAM-Speicher eingelesen, so daß sie beim nachfolgenden Betrieb des Steuersystems berücksichtigt werden können. Allerdings benötigen EEPROMs eine relativ hohe Betriebsspannung und be­ sitzen relativ geringe Datendichte. Zudem sind sie kostenauf­ wendig.
Als Alternative zu EEPROMs sind allgemein auch Flash-Speicher (Flash-RAMs) bekannt, bei denen jedoch die Anzahl von Lösch- und Schreibzyklen begrenzt ist und zum Beispiel nicht mehr als etwas über 10000 betragen kann. Damit ist die Lebensdauer eines Flash-Speichers oftmals nicht ausreichend für die Ge­ samtzahl der während der Lebensdauer des Steuersystems, zum Beispiel des Kraftfahrzeug-Steuersystems, auftretenden Ein- und Ausschaltvorgänge mit entsprechenden Lösch- und Schreibvorgängen des Flash-Speichers. Beispielsweise liegt die Gesamtzahl der Ein- und Ausschaltungen eines häufig für Kurzstrecken eingesetzten Kraftfahrzeugs (zum Beispiel Taxi) bei mehreren Tausend pro Jahr, so daß über die Lebensdauer des Fahrzeugs hinweg mehrere Zehntausend Ein- und Ausschalt­ vorgänge auftreten können. Wenn Bausteine eingesetzt würden, die eine höhere Anzahl von Lösch- und Schreibzyklen ermögli­ chen würden, würde dies zu einer deutlichen Kostenerhöhung führen.
In "Flash-Technologie ersetzt EEPROMs" in Design & Elektro­ nik, Heft 18, 1995, Seiten 38 bis 41, ist ein dem Oberbegriff des Patentanspruchs 1 entsprechendes Verfahren offenbart, bei dem in einem Boot-Block-Flash-Speichersystem Parameter ge­ speichert werden. Bei sich ändernden Parametern werden die aktuellen Parameterwerte sukzessive in einen Flash- Speicherblock eingeschrieben und im bislang gültigen Parame­ ter ein Hinweis auf die Adresse des nun aktuellen Parameters gesetzt. Wenn der Parameterblock gefüllt ist, werden die ak­ tuellen Parameterwerte in einen anderen Parameterblock ko­ piert und der gefüllte Parameterblock gelöscht. Durch diese Vorgehensweise läßt sich die Anzahl von insgesamt erforderli­ chen Löschzyklen relativ gering halten. Bei einer Wiederein­ schaltung des Systems wird allerdings eine gewisse Zeit benö­ tigt, bis die jeweils aktuellen Parameterwerte gefunden sind und zur Steuerung des Steuersystems zur Verfügung stehen.
Aus der DE 42 09 905 C1 ist ein System zur Verwaltung des Speicherinhalts eines überschreibbaren EEPROM-Speichers be­ kannt, bei dem eine Verringerung der Schreibvorgänge dadurch erreicht wird, daß neu dem System zugeführte Datensätze mit entsprechenden, im Speicher bereits enthaltenen Datensätzen verglichen werden und ein Speichervorgang nur dann ausgeführt wird, wenn sich die Datensätze unterscheiden.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zur Abspeicherung und Wiedergewinnung von sich während des Be­ triebs ändernden Betriebsdaten zu schaffen, das einen raschen Betriebsstart eines mit einem geringen technischen Aufwand erfordernden, nichtflüchtigen Betriebsdaten-Speicher ausge­ statteten Steuersystems nach dessen Einschaltung ermöglicht.
Diese Aufgabe wird mit den im Patentanspruch 1 genannten Merkmalen gelöst.
Vorteilhafte Ausgestaltungen der Erfindung sind in den Un­ teransprüchen angegeben.
Die Betriebsdaten werden bei einem Betriebsstart in zwei Schritten geholt. Während der Initialisierungsphase des Steu­ ersystems, zum Beispiel einer automatischen Getriebesteue­ rung, werden zur Minimierung der Belastung des Prozessors zu­ nächst lediglich Ersatzwerte für die Betriebsdaten im RAM-Speicher aufgenommen, ohne daß ein Zugriff zu dem Flash- Speicher erfolgt. Erst während eines nachfolgenden Zeitinter­ valls, bei dem der Prozessor des Steuersystems üblicherweise bereits häufig im Leerlauf läuft, erfolgt tatsächlich ein Zu­ griff zu dem Flash-Speicher zum Auslesen der bei der letzten Systemabschaltung eingespeicherten Betriebsdaten.
Der eingesetzte Flash-Speicher kann standardmäßige Ausfüh­ rungsform aufweisen und zeichnet sich durch hohe Datendichte, geringe Betriebsspannung und kostengünstige Verfügbarkeit aus. Der Flash-Speicher wird durch ein Ringspeicherverfahren verwaltet, so daß die zu speichernden Betriebsdaten, zum Bei­ spiel die adaptiven Daten, nicht mehr auf festen Adressen liegen, sondern sequentiell, vorzugsweise in gekennzeichneten Blöcken, im Flash-Speicher abgespeichert werden. Die neuesten Werte liegen somit immer auf anderen, beispielsweise höheren Adressen als ältere Blöcke der gleichen Art. Der Flash- Speicher enthält jeweils eine Mehrzahl von Betriebsdaten der gleichen Art, die sich lediglich hinsichtlich ihres Alters unterscheiden.
Durch das Speicherverfahren wird auch eine "Historyfunktion" ermöglicht, da ältere Betriebszustände und Fehleraufzeichnun­ gen noch längere Zeit zur Verfügung stehen und zur Klärung von Fehlervorfällen oder z. B. von Garantieansprüchen herange­ zogen werden können. Wird z. B. die festgelegte, maximale Be­ triebstemperatur des Geräts überschritten, verfallen dadurch in der Regel Garantieansprüche. Ohne die längerfristige Bei­ behaltung der Aufzeichnungen älterer Betriebszustände kann solch ein überschreiten der Betriebswerte eventuell nicht nachgewiesen werden, da das Gerät hierbei zwar beschädigt wird, aber erst später, unter normalen Betriebsbedingungen ausfällt.
Ein Löschzyklus wird erst dann benötigt, wenn der Flash- Speicher (oder bei vorzugsweise vorgesehener Segmentierung des Flash-Speichers ein entsprechender Segmentblock des Flash-Speichers) gefüllt ist und keine neuen Betriebsdaten mehr aufnehmen kann. Erst in diesem Fall ist es notwendig, den Flash-Speicher zu reorganisieren, das heißt nur noch die aktuellen Daten zu übernehmen, oder diese von dem vollen Block in einen neu zu bespeichernden Segmentblock zu kopie­ ren. Durch diese Vorgehensweise ist ein Lösch- und Schreibzy­ klus erst nach einer größeren Anzahl von Ein- und Ausschal­ tungen des Steuersystems erforderlich, so daß die Lebensdauer des Flash-Speichers vervielfacht ist und für die normale Be­ nutzungsdauer des zum Beispiel im Kraftfahrzeug befindlichen Steuersystems völlig ausreicht.
Um die Anzahl von Schreibzyklen noch weiter zu verringern, wird vorzugsweise bei dem Ausschalten des Steuersystems über­ prüft, ob sich die Betriebsdaten tatsächlich während des zu­ rückliegenden Betriebs geändert haben, das heißt von denen zu Beginn des Betriebs vorliegenden Betriebsdaten abweichen. Wenn dies nicht der Fall ist, werden diese unverändert ge­ bliebenen Betriebsdaten nicht in den Flash-Speicher einge­ speichert, so daß die diesbezüglichen Schreibvorgänge unter­ bleiben und demgemäß die Zeitdauer, bis der Flash-Speicher gefüllt ist und gelöscht werden muß, entsprechend verlängert ist.
In bevorzugter Ausgestaltung werden die Betriebsdaten jeweils zusammen mit einem die Datenart charakterisierenden Kopf im Flash-Speicher eingespeichert, so daß das Steuersystem den jüngsten Wert jeder Datenart der Betriebsarten in dem Flash- Speicher durch Abfragen des Speichers und Ermitteln der an letzter Stelle (in der Reihenfolge der jeweils gleichen Be­ triebsdatenart) stehenden Kopfkennung erkennen kann.
Vorzugsweise ist der Flash-Speicher in mehrere Segmente un­ terteilt, wobei die Betriebsdaten dann jeweils vorzugsweise in einem Segment aufeinanderfolgend solange gespeichert wer­ den, bis das Segment gefüllt ist, wonach mit dem Beschreiben des nächsten Segments begonnen wird. Das gefüllte Segment kann dann ohne Störung des anderen Segments gelöscht werden, wobei dieser Löschvorgang aber vorzugsweise zurückgestellt bleibt, bis auch das oder die anderen Segmente des Flash- Speichers gefüllt sind.
Bei Beginn der Bespeicherung eines neuen oder frisch gelösch­ ten Segments werden vorzugsweise in diesem nicht nur die ak­ tuellen Betriebsdaten, sondern auch unveränderliche, für den Betrieb des Steuersystems erforderliche Daten wie etwa Her­ stellungsdaten, Stromregler-Abgleichwerte usw. gespeichert. Damit sind alle für den Betrieb des Steuersystems erforderli­ chen Daten normalerweise in einem einzigen, aktuell zum Spei­ chern und Auslesen verwendeten Segment enthalten.
Damit eine einfache Überprüfung der Segmente und Erkennung ihres Zustands möglich ist, ist jedes Segment vorzugsweise mit einer Kennung versehen, die angibt, ob es gefüllt, teil­ gefüllt oder leer ist. Ein teilgefülltes Segment stellt hier­ bei das aktuell zum Speichern verwendete, "aktivierte" Seg­ ment dar. Sofern sich ergeben sollte, daß im aktivierten Seg­ ment nicht alle benötigten Betriebsdaten enthalten sind, wird vorzugsweise auch ein älteres, deaktiviertes Segment hin­ sichtlich der benötigten Betriebsdatenart überprüft und diese aus diesem ausgelesen. Damit ist es möglich, zumindest die früher aktuellen Betriebsdaten als nun zu verwendende Be­ triebsarten zu benutzen. Diese etwas älteren Betriebsdaten sind in aller Regel besser geeignet als irgendwelche bereits vorab festgelegten Ersatzwerte.
Beim Systemstart ist es möglich, für alle oder zumindest für einen Teil der Betriebsdaten zunächst lediglich Zeiger zu setzen, die auf die entsprechende Position der Daten im Flash-Speicher hinweisen. Wenn die Betriebsdaten dann während des laufenden Betriebs tatsächlich benötigt werden, können diese unter Zugriff auf die Zeiger rasch ausgelesen und in den RAM-Speicher übernommen werden.
Vorzugsweise ist eine Sicherheitsstufe vorgesehen, bei der beim Auslesen eines Datenblocks aus dem Flash-Speicher zu­ nächst die Datenblock-Integrität überprüft wird und bei nega­ tivem Ergebnis ein früherer, intakter Datenblock derselben Betriebsdatenart ermittelt und ausgegeben wird.
Der Beginn des freien Speicherraums des Flash-Speichers läßt sich sehr rasch durch virtuelle Blockbildung und Überprüfung charakteristischer Blockstellen ermitteln.
Beim Abschalten des Steuersystems werden vorzugsweise die im RAM-Speicher enthaltenen aktuellen Werte der Betriebsdaten gesucht und zu entsprechenden Datenblöcken zusammengestellt, die vor ihrer Speicherung im Flash-Speicher jeweils mit einer die Datenart angebenden Kennung versehen werden. Bei dieser Bildung der Datenblöcke im RAM-Speicher wird bevorzugt auch die gesamte, resultierende Größe der in den Flash-Speicher zu übertragenden Daten ermittelt, so daß der Umfang der zu über­ tragenden Daten bekannt ist und z. B. das Flash-Speicher- Segment auf ausreichenden Speicherraum überprüft werden kann sowie eine rasche Speicherung der benötigten Betriebsdaten erzielbar ist.
Die Erfindung wird nachstehend anhand von Ausführungsbeispie­ len unter Bezugnahme auf die Zeichnungen näher beschrieben.
Es zeigen:
Fig. 1 den Inhalt eines Segments des Flash-Speichers bei einem Ausführungsbeispiel,
Fig. 2 die Struktur eines Datenblocks im Flash-Speicher,
Fig. 3 den Datenfluß beim normalen Betrieb sowie bei einer normalen Steuersystemabschaltung oder einer Rückset­ zung aufgrund eines Softwarefehlers,
Fig. 4 schematisch die Einspeicherung von Daten in den RAM-Speicher nach einem System-Reset,
Fig. 5 weitere Einzelheiten der Einspeicherung der Daten in dem RAM-Speicher bei einem Ausführungsbeispiel,
Fig. 6 und 7 die sukzessive Auffüllung der Segmente des Flash-Speichers mit Betriebsdaten,
Fig. 8 ein Verfahren zum raschen Auffinden des Endes eines benutzten Flash-Speicher-Blocks zum Anfügen von neuen Betriebsdaten in diesem Bereich,
Fig. 9 ein Ablaufdiagramm einer Routine, die zum Setzen von Zeigern für jede Art von Betriebsdatenblöcken dient,
Fig. 10 ein Ablaufdiagramm einer Programmroutine zur Überprü­ fung der Integrität eines Betriebsdatenblocks im Flash-Speicher,
Fig. 11 ein Ablaufdiagramm einer weiteren Programmroutine, die bei der Überprüfung der Datenblockintegrität ein­ gesetzt wird,
Fig. 12 ein weiteres Ablaufdiagramm zur Suche und Überprüfung eines Betriebsdatenblocks im Flash-Speicher,
Fig. 13 ein Beispiel für die Bildung von Datenblöcken zur Abspeicherung im Flash-Speicher bei einer Systemab­ schaltung,
Fig. 14 ein Ablaufdiagramm der Programmroutine zur Bildung der Betriebsdatenblöcke für die Abspeicherung im Flash-Speicher, und
Fig. 15 ein Ablaufdiagramm zur Veranschaulichung der Reorga­ nisation des Flash-Speichers bei gefülltem Flash-Speicherblock.
Das erfindungsgemäße Verfahren wird nachfolgend bei einem Steuersystem beschrieben, das in einem Kraftfahrzeug enthal­ ten ist und zur Steuerung des automatischen Getriebes dient. Das Verfahren ist aber auch bei anderen Steuersystemen an­ wendbar, bei denen sich das Problem der nichtflüchtigen Spei­ cherung von sich während des Betriebs ändernden Daten in Be­ triebspausen stellt.
In Fig. 1 ist ein Beispiel für den Speicherinhalt eines Flash-Speichers 1 gezeigt, der einen Bestandteil des Steuer­ systems darstellt. In dem Flash-Speicher 1 sind in dem darge­ stellten Segment, das zum Beispiel 8 Kilobyte umfaßt und bei der Adresse 0×4000 beginnt, unterschiedliche Betriebsdatenar­ ten gespeichert, nämlich feste Betriebsdaten, die lediglich einmal gespeichert werden müssen, zum Beispiel Fertigungsda­ ten, die am Abschluß der Produktionslinie gespeichert werden können, oder Stromregler-Abgleichwerte, die zum Abgleich der Getriebeautomatik-Stromregler dienen. In dem Flash-Speicher 1 werden aber auch Betriebsdaten gespeichert, die sich während des Betriebs verändern, zum Beispiel Fehlerspeicherdaten, die bisherige Gesamtbetriebsdauer angebende Zählerdaten, Adapti­ vwerte für sich adaptiv ändernde Größen usw. Wie aus Fig. 1 ersichtlich ist, werden die jeweiligen Betriebsdaten jeweils fortlaufend aufeinanderfolgend ohne Einhaltung einer bestimm­ ten Reihenfolge gespeichert, wobei die betriebsun­ veränderlichen Betriebsdaten wie etwa die Fertigungsdaten in der Regel nur einmal gespeichert werden, die die Gesamtbe­ triebsdauer angebenden Zählerdaten aber jeweils bei jedem Ausschalten des Steuersystems, das heißt des Kraftfahrzeugs, gespeichert werden. Auch die Fehlerspeicherdaten und die Ad­ aptivwerte werden jeweils beim Ausschalten des Steuersystems im Flash-Speicher gespeichert, sofern sie sich gegenüber ih­ rem Zustand beim Systemstart verändert haben sollten. Da so­ mit beim Abschalten nur Betriebsdaten, die sich geändert ha­ ben, gespeichert werden und diese ohne Einhaltung einer be­ stimmten Reihenfolge jeweils direkt an das Ende des bislang beschriebenen Flash-Speicherbereichs angehängt werden, füllt sich der Flash-Speicherbereich nur langsam auf, so daß ein entsprechend großer Zeitraum verstreicht, bis der Speicherbe­ reich gefüllt ist und ein Löschvorgang durchgeführt werden muß.
Allgemein wird der Flash-Speicherblock durch die sich ändern­ den Betriebsdaten fortschreitend belegt, solange ausreichend freier Raum bereitsteht. Falls jedoch der Speicherblock ge­ füllt ist, kann eine Reorganisation dieses zur Speicherung der Betriebsdaten eingesetzten Speicherblocks eingeleitet werden, bei der zunächst die letzte (jüngste) Kopie aller sich ändernden Betriebsdaten in einen zweiten, gegebenenfalls zuvor zu löschenden Block kopiert wird, dann die neuen, aktu­ ellen Betriebsdaten aus dem RAM-Speicher in den zweiten Block kopiert bzw. dort hinzugefügt werden, und schließlich das Steuersystem, zum Beispiel die automatische Getriebesteuer­ einheit, abgeschaltet oder ein System-Reset durchgeführt wird. Bei einem Systemstart werden die Betriebsdatenblöcke mittels Zeigeroperationen abgefragt. Die Zeiger werden hier­ bei auf den in dem jüngsten Block gefundenen Kopf (Header) der entsprechenden Betriebsdatenart gesetzt. Hierdurch wird der letzte gültige Betriebsdatenblock dieser Art bezeichnet. Die Einzelheiten der Abspeicherung und Wiedergewinnung der Daten werden im weiteren Text noch näher beschrieben.
Zu den Betriebsdaten, die im Flash-Speicher 1 abgespeichert werden, zählen nicht nur die vorstehend angegebenen Daten, sondern auch adaptive Daten (Adaptivwerte), die zum Beispiel zur Getriebesteuerung eingesetzt werden, sowie Fehlerzu­ standsaufnahmen, die sich auf einen Fehlerspeicherblock be­ ziehen können, oder Zustandsaufnahmen beispielsweise von Re­ gisterwerten, die beim Auftreten von Softwarefehlern (Software-Traps) gespeichert werden.
Damit alle diese unterschiedlichen Betriebsarten durch stan­ dardisierte Handhabungsroutinen für den Flash-Speicherzugriff in einfacher Weise gehandhabt werden können, wird eine spezi­ elle Gestaltung der Flash-Datenblöcke eingesetzt. In Fig. 2 ist die Ausgestaltung eines solchen Datenblocks 2 gezeigt, der im Betriebsdatenabschnitt des Flash-Speichers 1 gespei­ chert wird und für alle Datenarten jeweils den gleichen Auf­ bau aufweist. Der Datenblock 2 enthält am Beginn eine Kopf­ kennung HDR, dann eine Kennung "TYP", die den entsprechenden Puffer im RAM-Speicher für den Flash-Speicher-Inhalt bezeich­ net. Hieran schließt sich eine Kennung "ID" an, die zur Be­ zeichnung der Datenart dient. Der Blockabschnitt "UMF" signa­ lisiert die Anzahl von Datenbytes, die in dem Abschnitt "Daten" enthalten sind, einschließlich der zugehörigen Prüf­ summe. Der Datenabschnitt C2 enthält die Prüfsumme. Am Daten­ blockschluß enthält der Datenabschnitt "Ende" ein festgeleg­ tes Bitmuster, das dem Steuersystem das Datenblockende signa­ lisiert, woran sich noch die Blockprüfsumme BCS anschließt.
Das in Fig. 3 gezeigte Schema gibt einen Überblick über den normalen Steuersystembetrieb. Generell wird hierbei ein EEPROM-System simuliert, so daß das Steuersystem bei normalem Betrieb sich so verhält, als wäre es mit einem EEPROM-Speicher anstelle eines Flash-Speichers ausgestattet. Beim Beginn des normalen Steuersystem-Betriebs, der mit dem Be­ zugszeichen 3 angegeben ist, werden zunächst Fertigungsdaten vom Flash-Speicher in den RAM-Speicher kopiert (Blöcke 4 und 5) und anschließend während des laufenden Betriebs die Adap­ tivdaten und, soweit angebracht, auch die Fertigungsdaten angepaßt (Block 6). Wenn ein kritischer Softwarefehler auf­ tritt, der eine Rücksetzung des Steuersystems erfordert, wird zunächst eine Zustandsaufnahme der Register usw. im Flash­ speicher abgespeichert (Block 7). Die Zustandsaufnahme er­ laubt eine vereinfachte Eingrenzung des Softwarefehlers und damit seiner Behebung. Nach Durchführung der Rücksetzung (Block 8) werden die im Flash-Speicher enthaltenen, relevan­ ten Betriebsdaten in den RAM-Speicher kopiert (Block 9) und gegebenenfalls die Zustandsaufnahme angezeigt (Block 10). Wenn das Steuersystem abgeschaltet wird, zum Beispiel der Zündschalter ausgeschaltet wird, werden die Betriebsdaten (Adaptivdaten, Zustandsdaten usw.) und gegebenenfalls auch die geänderten Fertigungsdaten mittels eines Flash-Managers 11 im Flash-Speicher abgespeichert (Block 12), wonach dann die Spannungszufuhr abgeschaltet wird (Block 13).
Allgemein ist der Betrieb des Steuersystems in drei Phasen unterteilt: a) Datenholungsvorgänge vor Beginn der Durchfüh­ rung des normalen Steuersystembetriebs, b) Betriebsvorgänge während des normalen Steuersystem-Betriebs, und c) Abschalt­ vorgänge zur Einspeicherung der aktuellen, bei der nächsten Einschaltung benötigten Informationen in den Flash-Speicher. Diese Abläufe werden nachfolgend in größeren Einzelheiten erläutert.
Der Datenholungsvorgang beim Systemstart ist in zwei Ab­ schnitte unterteilt (siehe Fig. 4). Der erste Abschnitt wird während der Initialisierung des Steuersystems durchgeführt. Da das Timing des Systemstarts während dieser Initialisie­ rungsphase sehr kritisch ist, erfolgt vorzugsweise zu diesem Zeitpunkt noch kein Zugriff zu dem Flash-Speicher. Es werden daher während dieser Initialisierungsphase lediglich einige Ersatzwerte (ROM-Daten) in die entsprechenden Datenbereiche des RAM-Speichers als Ersatz für die im Flash-Speicher ent­ haltenen, korrekten Betriebsdaten eingespeichert. Somit kön­ nen die wichtigsten Abläufe zum frühestmöglichen Zeitpunkt aufgenommen werden, so daß der normale Steuersystem-Betrieb rasch erreicht wird. Das Auslesen der Betriebsdaten aus dem Flash-Speicher wird nun erst als Hintergrund-Task durchge­ führt, so daß die während dieses Zeitraums normalerweise weitgehend im Leerlauf arbeitende CPU nun zur Datenholung eingesetzt wird. Damit wird der Normalbetrieb des Steuersy­ stems geringstmöglich belastet. Über die Hintergrundfunktion "Flash auslesen" werden somit nun die jüngsten Betriebsdaten in den Adaptivblock des RAM-Speichers eingespeichert. Die im RAM-Speicher gespeicherten Betriebsdaten werden dann zur Steuerung des Normalbetriebs je nach Bedarf unter Steuerung durch das Betriebssystem eingesetzt. Da Fig. 4 aus sich selbst heraus verständlich ist, ist keine weitere Beschrei­ bung erforderlich.
Der vorstehend beschriebene Ablauf trifft für einen Kaltstart zu, bei dem die Steuersystem-Spannung zuvor abgeschaltet war. Falls eine Systemrücksetzung durch Softwaresteuerung erfolg­ te, wird zunächst überprüft, ob die im RAM-Speicher enthalte­ nen adaptiven Daten (Betriebsdaten) korrekt sind, was durch Neuberechnung ihrer Prüfsummen und durch Vergleichen der Er­ gebnisse mit der vorhergehenden Prüfsumme bewerkstelligt wird. Falls sich hierbei ergibt, daß die im RAM-Speicher ent­ haltenen Betriebsdaten korrekt sind, werden die Flash- Initialisierungsfunktion sowie die "Hintergrundfunktion Flash auslesen" nicht ausgeführt.
Bei Systemstart werden zunächst nur die relevanten Werte für die Stromregler im RAM-Speicher geladen, wobei es sich bei diesen Werten um Tabellen handelt, die Offset- und Gradien­ tenwerte für die jeweiligen Ausgangswerte der Stromregler und Temperaturkompensationswerte enthalten. Durch diese Vorge­ hensweise läßt sich die Belastung der CPU während der Initia­ lisierungsphase so gering wie möglich halten. Da hierbei noch kein Zugriff auf den Flash-Speicher stattfindet, werden, wie vorstehend ausgeführt, zunächst festgelegte Ersatzwerte ("ROM-Daten") verwendet, die einen sicheren Betrieb der Stromregler gewährleisten.
Bei den Betriebsdaten, die während des Systemstarts bei einem normalen Steuersystembetrieb (ohne Testgeräte und derglei­ chen) geholt und verwendet werden, handelt es sich insbeson­ dere um die Stromregler-Abgleichwerte, adaptive Werte zur Steuersystemsteuerung, beispielsweise zur Getriebesteuerung, um die Fehlerspeicherblockdaten, die Standard-Fehler- Zustandsdaten und um die Gesamtbetriebsdauer.
Falls sich bei der Abfrage des Flash-Speichers ergeben soll­ te, daß die gewünschten Datenblöcke nicht auffindbar sind oder daß sie fehlerhaft sind (Prüfsummenüberprüfung signa­ lisiert Fehler), werden Ersatzwerte aus einem ROM verwendet oder es werden die Daten lediglich auf Null gesetzt. Letzte­ res trifft zum Beispiel für die Gesamtbetriebsdauer oder für die Fehlerhandhabungstabellen zu. Somit können adaptive Da­ tenblöcke ohne vorherige Definition in der Anfangsphase des Starts des Steuersystems generiert werden.
In Fig. 5 ist dieser Ablauf in Form eines Flußbilds veran­ schaulicht. Wie dort gezeigt, wird zunächst jeweils ein Flash-Speicher-Block geprüft und, wenn er intakt ist, gele­ sen. Andernfalls werden die entsprechenden Ersatzwerte in den zugehörigen Adaptivblock des ROM-Speichers eingespeichert. Dieser Ablauf wird sukzessive zunächst für die Fehlerspei­ cher-Daten, dann für die Getriebe-Daten, die Stromregler- Daten und die Betriebsstundenzählerdaten, die jeweils im Flash-Speicher gespeichert sind, durchgeführt. Nach Abschluß der Datenspeicherung für die Betriebsstundenzählerdaten wird ein Signal "Zustand 5" abgegeben, das das Ende der Bespeiche­ rung des Adaptivblocks des RAM-Speichers signalisiert.
Damit ein schneller Zugriff zum Flash-Speicher durchführbar ist, wenn zum Beispiel Betriebsdaten benötigt werden, die noch nicht im RAM-Speicher gespeichert sind, ist eine Hinter­ grundfunktion vorgesehen, die den Flash-Speicher-Inhalt zur Ermittlung von dessen Zustand und der jeweils jüngsten Be­ triebsdatenblöcke analysiert. Hierbei wird jeweils ein Zeiger für jede Blockart der Betriebsdaten gesetzt, der auf die jüngsten Betriebsdaten dieser Blockart hinweist. Da dieser Vorgang im Hintergrund abläuft, wird die Leistungsfähigkeit des Systems hierdurch nicht verschlechtert. Im einzelnen er­ folgt die Analyse dahingehend, daß zunächst der aktive Flash- Block ermittelt wird, das Ende des belegten Flash- Speicherbereichs ermittelt wird, so daß die Position für eine nachfolgende Speicherung von Betriebsdaten signalisiert wird, und ein Zeiger für jede Blockart in dem aktiven, belegten Flash-Speicherbereich gesetzt wird.
Bei dem in dem Fig. 6 und 7 gezeigten Ausführungsbeispiel weist der Flash-Speicher 1 zwei Segmente 14, 15 zur Speiche­ rung der veränderlichen Betriebsdaten auf, die zum Beispiel beim Adreßbereich 0×04000 bis 0×05FFF (erstes Segment) und im Adreßbereich von 0×06000 bis 0×07FFF (zweites Segment) liegen. Die anderen Flash-Speicherabschnitte sind für andere Aufgaben reserviert. Die Anzahl der Segmente des Flash- Speichers, die für die Betriebsdatenspeicherung vorgesehen sind, kann aber auch einen anderen Wert, das heißt zum Bei­ spiel 1 oder 3 und mehr haben.
Beide Segmente werden jeweils nacheinander vollständig mit Betriebsdaten aufgefüllt, bis eine Reorganisation erzwungen wird. Damit dem Steuersystem signalisiert wird, welches Seg­ ment benutzbar ist, ist in die erste Adreßstelle entweder 0×FFFF (dies signalisiert ein leeres Segment), 0×5A5A (dies bezeichnet den Kopf eines gültigen Datenblocks und signali­ siert ein teilgefülltes Segment), oder 0×5A00 (dies signali­ siert ein volles Segment) eingeschrieben. Falls ein Segment aufgefüllt worden ist, wird nachfolgend das andere Segment zu Speicherzwecken verwendet und der erste Header des vollen Segments von 0×5A5A auf 0×5A00 geändert, so daß dieses Seg­ ment nun deaktiviert ist. Falls beide Segmente des Flash- Speichers an ihren ersten Adreßstellen (0×04000 und 0×06000) jeweils 0×FFFF enthalten, signalisiert dies, daß sich der Flash-Speicher in seinem anfänglichen Zustand befindet und beide Blöcke leer sind. Falls an der ersten Flash- Speicherzelle des Speicherblocks keine der drei gültigen Mög­ lichkeiten 0×FFFF, 0×5A5A oder 0×5A00 gefunden wird, wird der auf den Beginn des Flash-Speichers zeigende Zeiger solange inkrementiert, bis entweder eine gültige Option ermittelt wird oder das Ende des Flash-Speicherblocks erreicht wird. In den Fig. 6 und 7 sind die Adressenzustände und Speicherinhal­ te der Segmente 14 und 15 in jeweils unterschiedlichen Bele­ gungszuständen gezeigt.
Bei der Analyse des Flash-Speicherzustands gibt die Analyse­ funktion einen entsprechenden Signalwert an das Steuersystem zurück, der den Belegungszustand signalisiert.
Falls beide Flash-Speichersegmente völlig leer sein sollten oder aber fehlerhafterweise beide Segmente deaktiviert sein sollten, wird das erste Segment 14 für den nächsten Speicher­ vorgang verwendet.
Damit keine Freiräume im Flash-Speicher beim Einspeichern neuer Betriebsdatenblöcke verbleiben, wird jeweils das Ende des belegten Bereichs ermittelt, was durch die in Fig. 8 ge­ zeigte Programmroutine erfolgt.
In Fig. 8 ist ein aus sich selbst heraus verständliches Ab­ laufdiagramm eines Programms zur raschen Ermittlung des Endes des belegten Speicherbereichs in dem aktuell benutzten Flash- Speicher-Segment dargestellt. Somit können neue Daten unmit­ telbar an das Ende des bereits belegten Speicherbereichs an­ geschlossen werden. Der Flash-Speicher ist in virtuelle Blöc­ ke (Abschnitte) mit einer Größe von 256 Bytes unterteilt. Die Abtastung beginnt mit der Überprüfung der jeweils an dem Be­ ginn jedes Blocks befindlichen Zelle. Falls ermittelt wird, daß diese Zelle Daten 0×FFFF (oder sonstige, einen Leerzu­ stand signalisierende Daten) enthält, wird davon ausgegangen, daß der gesamte Block leer ist. Wenn aber ermittelt wird, daß die Zelle irgendwelche anderen Daten enthält, ist dieser Block belegt und kann nicht benutzt werden. Es wird dann der nächste virtuelle Block überprüft. Diese Untersuchung wird solange fortgesetzt, bis das Ende des für die Betriebsdaten aktuell benutzten Segments erreicht ist.
Wenn jedoch ein leerer Block ermittelt wird, wird der Ar­ beitszeiger auf den vorhergehenden, virtuellen Block (mit einem Umfang von 256 Byte) dekrementiert. Ausgehend von die­ ser Position wird der Flash-Speicher wortweise solange abge­ tastet bis eine leere Zelle (0×FFFF) ermittelt wird. Es wird dann eine vorab festgelegte Anzahl von weiteren, sich an die leere Zellen anschließende Zellen überprüft. Wenn diese eben­ falls leer sind, wird davon ausgegangen, daß der Beginn des freien Flash-Speicherbereichs erreicht ist. Die Anzahl der auf ihren Leerzustand überprüften Zellen muß ausreichend groß sein, um die gesamte Anzahl von möglichen adaptiven, von dem RAM-Speicher zugeführten Blöcken bei dem nächsten Flash- Einspeicherungsvorgang bei der Abschaltung aufnehmen zu kön­ nen. Falls sich bei der Überprüfung Zellen ergeben sollten, die nicht frei sind (zum Beispiel defekte Zellen), wird der Arbeitszeiger solange inkrementiert, bis ein ausreichend gro­ ßer freier Raum zur Verfügung steht.
Schließlich wird ein globaler, die Verfügbarkeit anzeigender Zeiger auf die erste freie Zelle des Flash-Speicherbereichs, die auf den vorhergehenden, belegten Raum folgt, gesetzt. Gleichzeitig wird nochmals bestätigt, daß der bei dem näch­ sten Speichervorgang aufzunehmende Datenumfang in den vorhan­ denen freien Flash-Speicherbereich eingespeichert werden kann. Die weiteren Programmabschnitte werden darüber, daß ausreichend großer Raum für den nächsten Speichervorgang zur Verfügung steht, informiert, indem ein entsprechendes Bit in einer Variablen fsh_blk_cnd zum Beispiel auf den Wert 1 (anfänglicher Wert = 0) gesetzt wird. Falls jedoch kein aus­ reichend großer Raum mehr in dem aktiven Flash-Segment zur Aufnahme der neuen Daten zur Verfügung stehen sollte, wird der globale, die Verfügbarkeit anzeigende Zeiger auf die letzte Wortadresse des aktiven Flash-Speicherblocks, das heißt auf 0×5FFE oder 0×7FFE gesetzt und es wird das entspre­ chende Bit in der Variablen fsh_blk_cnd auf Null gesetzt.
Die abschließende Stufe der Flash-Speicheranalyse zielt dar­ auf ab, einen Zeiger auf jede Art des Informationsblocks (Betriebsdatenblock), der durch die Angaben "TYP" und "ID" (siehe Fig. 2) festgelegt ist und in dem Flash- Speichersegment gespeichert ist, zu setzen. Diese Funktion ist durch das in Fig. 9 dargestellte Ablaufdiagramm veran­ schaulicht, das aus sich selbst heraus verständlich ist. Der Flash-Speicher wird hierbei von dem Beginn des aktiven Seg­ ments bis zur Position des globalen, die Verfügbarkeit anzei­ genden Zeigers überprüft. Wenn ein gültiger Betriebsdaten­ block-Header mit "TYP" und "ID" ermittelt wird, wird die Startadresse dieses Datenblocks in eine Tabelle zusammen mit einem entsprechenden Index für die jeweilige Datenblockart übertragen. Zusätzlich wird ein Signalbit gesetzt, das an­ gibt, daß ein Datenblock eines bestimmten Typs und einer be­ stimmten Kennung ermittelt worden ist. Falls die Angaben "TYP" und "ID" bei der weiteren Flash- Speichersegmentabfragung noch ein weiteres Mal ermittelt wer­ den sollten, wird die neue Adresse anstelle der vorhergehen­ den gespeichert. Hierbei kann auch eine Überprüfung der Da­ tenblock-Integrität durchgeführt werden. Vorzugsweise wird diese Überprüfung aber erst dann vorgenommen, wenn dieser Datenblock aus dem Flash-Speicher tatsächlich ausgelesen wer­ den soll.
Am Abschluß dieser Programmroutine ist die Zeigertabelle stets mit der letzten, das heißt neuesten Adresse der jewei­ ligen Datenblöcke versehen. Falls kein Datenblock einer be­ stimmten Art ermittelt worden sein sollte, wird in die Zei­ gertabelle ein bestimmter Wert, zum Beispiel eine Null, ein­ geschrieben, der signalisiert, daß keine gültigen Daten für diese Datenblockart im Flash-Speicher ermittelt worden ist, so daß ROM-Ersatzwerte benutzt werden müssen.
Falls bei der Überprüfung des Flash-Speichersegments nicht alle Zeiger zugeordnet werden konnten, wird vor Einschreiben des Werts "0" in der entsprechenden Position zunächst in dem anderen, deaktivierten Flash-Speichersegment nach den noch fehlenden Datenblöcken mit Hilfe des gleichen Algorithmus (Fig. 9) gesucht und die hierbei gewonnenen Ergebnisse in der Zeigertabelle eingespeichert.
Wenn ein Datenblock aus dem Flash-Speicher ausgelesen werden soll, wird zunächst seine Integrität überprüft. Dies erfolgt mittels der in Fig. 10 gezeigten Routine. Dabei wird auf die­ sen Datenblock mittels der Adresse zugegriffen, die in der Zeigertabelle gespeichert ist. Der Datenblock wird dann abge­ fragt und die Block-Prüfsumme berechnet. Diese berechnete Prüfsumme wird mit der am Ende dieses Datenblocks gespeicher­ ten Block-Prüfsumme verglichen. Falls die Überprüfung positiv ist, wird der Datenblock ausgelesen und in dem entsprechenden RAM-Puffer gespeichert. Falls sich bei der Prüfsummenüberprü­ fung ("Checksumme O.K.?") eine Diskrepanz einstellen sollte, wird der Flash-Speicher ausgehend von dem angegebenen Adress­ wert rückwärts überprüft, um den vorhergehenden Datenblock der gleichen Art (gleicher Typ und gleiche Identifikation ID) zu ermitteln. Es wird dann der Zeiger auf den vorherigen (intakten) Datenblock gesetzt und dies an die aufrufende Funktion gemeldet. Falls sich bei der Suche nach einem frühe­ ren Datenblock kein Ergebnis einstellen sollte, wird dies der aufrufenden Funktion gemeldet und dann ROM-Ersatzwerte in die entsprechenden RAM-Puffer für die adaptiven Betriebsdaten geladen.
In Fig. 11 ist der in Fig. 10 gezeigte Funktionsaufruf "sys_fsh_nxt_blk" zur Ermittlung eines früheren, intakten Datenblocks in größeren Einzelheiten gezeigt. Auch Fig. 11 ist aus sich selbst heraus verständlich und benötigt über die vorstehenden Erläuterungen hinaus keine zusätzlichen Ausfüh­ rungen.
Auch während des laufenden Betriebs des Steuersystems kann ein Zugriff auf den Flash-Speicher vorgenommen werden, um beispielsweise Datenblöcke in den RAM-Speicher zu laden, die noch nicht beim Systemstart geladen wurden, da sie nur in seltenen Fällen benötigt werden. Es können auch bei Bedarf Daten aus RAM-Puffern in den Flash-Speicher, zum Beispiel zur Aktualisierung der Daten, zurückgespeichert werden. Dies kann durch das Anwendungssystem gesteuert werden. Hierbei können auch Herstellungsdaten modifiziert werden (zum Beispiel nach einem Justierungs- oder Reparatureingriff) und diese modifi­ zierten Herstellungsdaten dann in den Flash-Speicher zurück­ gespeichert werden. Grundsätzlich ist der Ablauf bei der Su­ che und Rückspeicherung der Betriebsdaten jeweils gleich, unabhängig davon, ob es sich um Herstellungsdaten, adaptive Daten, Zustandsaufnahmen bei einem massiven Softwarefehler oder dergleichen handelt.
In Fig. 12 ist ein Ablaufdiagramm gezeigt, mit dem eine ge­ zielte Suche nach einem früheren (das heißt nicht dem aktuel­ len) Datenblock einer bestimmten Betriebsdatenart durchge­ führt werden kann. Hierbei kann angegeben werden, ob es sich um den zweitjüngsten, drittjüngsten oder noch älteren Block der bestimmten Betriebsdatenart handeln soll ("Nummer der Rückwärtssuche"). Bei diesem Ablauf wird der gleiche Flash- Suchalgorithmus wie bei demjenigen Teil des Programms, das die Daten aus dem Flash-Speicher nach einem System-Reset aus­ liest, eingesetzt.
Während des laufenden Betriebs werden die im RAM-Speicher enthaltenen, veränderlichen Betriebsdaten, zum Beispiel die Adaptivdaten, jeweils aktualisiert, so daß im RAM-Speicher bei einer Systemabschaltung die aktuellsten Werte für die Rückspeicherung in den Flash-Speicher enthalten sind.
Während des laufenden Betriebs können auch Fehler- Zustandsaufnahmen bei Auftreten von Softwarefehlern im RAM-Speicher gespeichert werden, die dann im Flash-Speicher ge­ sichert werden können. Bei den bei dieser Zustandsaufnahme gesicherten Werten kann es sich zum Beispiel um die Drehzahl, die Systemspannung, die Temperatur, den Druck usw. handeln.
Im folgenden werden Einzelheiten der Bildung und Abspeiche­ rung der Datenblöcke im RAM-Speicher und im Flash-Speicher bei einer Systemabschaltung erläutert. Während des normalen Betriebs des Steuersystems werden die veränderlichen Be­ triebsdaten, zum Beispiel die adaptiven Daten oder die Feh­ lerspeicher-Daten, in zugeordneten RAM-Puffern gespeichert. Diese Daten müssen bei der Systemabschaltung in den Flash­ speicher übertragen werden. Hierzu werden sie zunächst in das gewünschte Format der Flash-Datenblöcke gebracht. Vor der Übertragung in den Flash-Speicher werden zunächst alle rele­ vanten RAM-Puffer abgefragt und ihre Daten in einen einzigen Block zusammengefaßt. Hierbei ist es erforderlich, daß nicht nur die Daten, die in dem Flash-Speicher zu speichern sind, korrekt aus den zugehörigen RAM-Puffern ausgelesen und zusam­ mengestellt werden, sondern auch die entsprechenden zugehöri­ gen Blockbestandteile wie "Kopf", "TYP", "ID", "Ende" usw. generiert werden. Bei dieser Funktion wird der Standard- Bereich des RAMs als Ausgabeposition benutzt und zeigerorien­ tiert gearbeitet. Die RAM-Position wird normalerweise durch andere Programmteile benutzt. Da diese jedoch nicht länger laufen (die nächste Aktion nach der Flash-Speicher-Pro­ grammierung ist die System-Rücksetzung oder die Spannungsab­ schaltung), kann dieser Bereich ohne Störung der anderen Pro­ gramme verwendet werden.
In Fig. 13 ist gezeigt, wie in dem RAM-Speicher 16 die ein­ zelnen Größen ("Fehlerspeicher", "Fehler-Zustandsaufnahmen", "Getriebeadaptivwerte", "Systemwerte") in den unteren, dop­ pelt genutzten RAM-Bereich in Form von Datenblöcken mit Kopf ("Header") und Ende-Kennung ("Tail") übertragen werden. Die Datenblöcke werden nach Abschluß ihrer Generierung in den Adaptivbereich des Flash-Speichers 1, das heißt in das Seg­ ment 14 oder 15, übertragen. Hierbei weisen die Datenblöcke den in Fig. 2 gezeigten Aufbau auf. Die Arbeitsschritte zur Erzeugung der Datenblöcke und zum Einschreiben in den Flash- Speicher sind in Fig. 14 gezeigt. Die aktuelle Speicherung der Daten in den Flash-Speicher erfolgt mit einer Funktion "sys_fsh_blk_write". Falls in dem Adaptivbereich des Flash- Speichers kein ausreichender Speicherplatz zur Verfügung ste­ hen sollte, wird eine Funktion "sys_fsh_reorg" zum Reorgani­ sieren des Flash-Speichers und zum nachfolgenden Speichern der Daten aufgerufen.
Bei dem gezeigten Ausführungsbeispiel erfolgt die Auswahl der im Flash-Speicher zu speichernden Betriebsdaten in Abhängig­ keit von dem jeweils ausgewählten Modus "MODE_NORMAL", "MODE_FORCE_REORG" oder "MODE_SW_TRAP". Der Modus "MODE_NORMAL" repräsentiert den normalen Modus des Steuersy­ stems, zum Beispiel des Getriebesteuersystems, bei dem mögli­ che Standardfehler durch einen Fehler-Manager erfaßt und be­ handelt werden. Der Modus "MODE_FORCE_REORG" stellt einen Modus dar, bei dem vor der Datenspeicherung eine Reorganisa­ tion des Flash-Speichers erforderlich ist. Die bei diesen beiden Betriebsarten jeweils ausgewählten Puffer und Speicher­ inhalte sind die Fehler-Zustandsaufnahmen "ERR_SS", sofern entsprechende Kennungen gesetzt sind, der Fehlerspeicher "err_m_buf", die Getriebeadaptivwerte "trm_buf" und die Sy­ stemdaten "sys_buf", insbesondere die Gesamtbetriebsstunden­ anzahl.
Der Modus "MODE_SW_TRAP" wird bei Auftreten eines zu einer Systemrücksetzung führenden Softwarefehlers aktiviert und bewirkt die Erfassung und Speicherung einer erhöhten Anzahl von Fehlerzustandsaufnahmen "err ss_buf [0], [1], [2], [3]" sowie der Betriebsdaten "sys_buf".
Wie aus Fig. 14 ersichtlich ist, wird vor der Bildung der Datenworte für die Betriebsdaten, zum Beispiel die Getrie­ beadaptivwerte, die Fehlerspeicher-Daten oder die Ge­ samtbetriebsdauer, zunächst überprüft, ob sich diese Werte gegenüber dem vorherigen Zustand überhaupt geändert haben. Dies erfolgt durch Überprüfung, ob sich die Prüfsumme (Checksumme) der entsprechenden Daten geändert hat (siehe die jeweils oben angegebenen Entscheidungsblöcke). Nur dann, wenn sich die entsprechenden Daten gegenüber ihrem Zustand beim Systemstart geändert haben, und somit die Prüfsumme geändert ist, werden die entsprechenden Datenworte mit Kopf, Ende- Kennung und Prüfsumme erzeugt und in dem doppelt genutzten RAM-Bereich des RAM-Speichers 16 zum Einschreiben in den Flash-Speicher abgelegt.
Bei der Datenwortablage im doppelt genutzten RAM-Bereich wird ein globaler Zeiger benutzt, der anfänglich auf den Beginn desjenigen RAM-Bereichs eingestellt wird, der zum Sammeln der für den Flash-Speicher bestimmten Datenworte benutzt wird. Während der Auffüllung dieses Datenbereichs wird der Zeiger stets so nachgeführt, daß er stets auf das Ende der gesammel­ ten Daten zeigt. Die zum Einschreiben der Daten in den Flash- Speicher verantwortliche Funktion kann somit den Datenumfang, der in den Flash-Speicher zu übertragen ist, durch Vergleich der aktuellen Position des Zeigers mit dem anfänglichen Wert ermitteln.
In Fig. 15 ist der Ablauf der Funktion "MODE_FORCE_REORG" im einzelnen gezeigt.
Wenn das bislang zum Speichern verwendete Speichersegment des Flash-Speichers nicht mehr ausreicht, muß das bislang nicht benutzte, deaktivierte Flash-Speichersegment gelöscht werden, damit die neuen Daten in diesem Block gespeichert werden kön­ nen. Sowohl aus Sicherheitsgründen als auch zur Erzielung konsistenter Zeiger wird sichergestellt, daß alle notwendigen Blöcke in einem einzigen Flash-Segment (Block) enthalten sind. Daher müssen zunächst aus dem bislang benutzten Segment einigte Datenblöcke in das gerade gelöschte Segment kopiert werden. Bei diesen Datenblöcken handelt es sich um Betriebs­ daten, die nicht während des normalen Betriebs des Steuersy­ stems, sondern lediglich am Abschluß der Herstellung gespei­ chert werden. Dabei kann es sich zum Beispiel um die Strom­ regler-Abgleichwerte und um Herstellungsdaten handeln. Nach­ folgend wird der aktuelle Modus überprüft. Falls der durch Anwendungssysteme getriggerte Modus "MODE_FORCE_REORG" vorge­ geben ist, wird der Flash-Speicher einfach reorganisiert, ohne daß die aktuellen, im RAM-Speicher enthaltenen Betriebs­ datenwerte berücksichtigt werden. In diesem Modus wird der gesamte Satz der jeweils jüngsten Betriebsdatenblöcke in das nun zu benutzende Flash-Speichersegment übertragen. Demgegen­ über werden beim Normalbetrieb "MODE_NORMAL" die im RAM-Speicher enthaltenen, aktuellen Adaptivwerte und sonstigen Betriebsdaten in das neue Flash-Speichersegment übertragen. Der letzte Vorgang besteht in der Deaktivierung des gefüllten Blocks, wozu der erste Datenblock-Header von "0x5A5A" auf "0×5A00" gesetzt wird.
Falls die Zeiger für die Datenblöcke nicht konsistent sein sollten, das heißt manche Datenblöcke in demjenigen Flash- Speichersegment enthalten sein sollten, das beim Beginn der Reorganisations-Funktion gelöscht wird, werden die Daten zu­ nächst in dem RAM-Speicher vor Beginn der Flash-Spei­ chersegmentlöschung gesichert. Diese Blöcke werden anschlie­ ßend zusammen mit den neuen Datenblöcken in dem gerade ge­ löschten Flash-Speichersegment wieder gespeichert.
Die korrekte Abspeicherung der Datenblöcke im Flash-Speicher kann überprüft werden, indem die in dem RAM-Speicherabschnitt enthaltenen Datenwörter mit den gerade in den Flash-Speicher kopierten Datenwörtern insgesamt verglichen werden. Bei Über­ einstimmung ist die korrekte Abspeicherung bestätigt, bei fehlender Übereinstimmung kann der Speichervorgang wiederholt werden und/oder eine Fehlermeldung erzeugt werden.

Claims (12)

1. Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug, das einen Rechner, einen RAM-Speicher (16) und einen Flash- Speicher (1) enthält, in dem Betriebsdaten unterschiedlicher Arten, die sich während des Betriebs des Steuersystems ändern können, derart speicherbar sind, daß Betriebsdaten der gleichen Art, jedoch unterschiedlichen Alters mehrfach vorhanden sind, dadurch gekennzeichnet, daß bei einer Wiedereinschaltung des Steuersystems die Betriebsdaten in dem RAM-Speicher (16) in zwei Phasen eingespeichert werden, wobei in der ersten Phase lediglich einige, vorab festgelegte Ersatzwerte in dem RAM-Speicher (16) ohne Zugriff zu dem Flash-Speicher (1) gespeichert werden und erst anschließend in der zweiten Phase, die jüngsten Betriebsdaten einer oder mehrerer Datenarten in dem Flash-Speicher (1) ermittelt in den RAM-Speicher (16) eingespeichert werden.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß beim Ausschalten des Steuersystems überprüft wird, ob die in dem RAM-Speicher (16) enthaltenen Betriebsdaten während des zurückliegenden Betriebs ab der letzten Einschaltung des Steuersystems geändert worden sind, und nur diejenigen Betriebsdaten, die sich geändert haben, in den Flash-Speicher (1) eingespeichert werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Betriebsdaten jeweils zusammen mit einem die Datenart charakterisierenden Kopf in dem Flash-Speicher (1) gespeichert werden.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Flash-Speicher (1) in mehrere Segmente (14, 15) unterteilt ist und die Betriebsdaten beim Abschalten des Steuersystems jeweils aufeinanderfolgend in einem Segment ohne Überschreiben der bisherigen Betriebsdaten solange abgespeichert werden, bis dieses Segment gefüllt ist, und anschließend die Betriebsdaten in ein nächstes Segment gespeichert werden.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß nach Auffüllung einiger oder aller Segmente ein bereits früher gefülltes Segment wieder gelöscht wird und dann in diesem jetzt gelöschten Segment Betriebsdaten, die regelmäßig unveränderlich, aber für den Betrieb des Steuersystems erforderlich sind, aus einem anderen Segment in dieses jetzt gelöschte Segment kopiert werden.
6. Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, daß jedes Segment eine Kennung aufweist, die angibt, ob es gefüllt, leer oder teilgefüllt ist.
7. Verfahren nach einem der Ansprüche 4 bis 6, dadurch gekennzeichnet, daß beim Einschalten des Steuersystems zunächst in dem gerade aktivierten Segment nach den jüngsten Betriebsdaten gesucht wird und dann, wenn nicht alle für den Betrieb benötigten Arten der jüngsten Betriebsdaten in diesem Segment gefunden werden, in einem deaktivierten Segment nach den fehlenden Betriebsdaten gesucht wird.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Flash-Speicher (1) beim Einschalten des Steuersystems abgefragt wird, die jeweils jüngsten Betriebsdaten der jeweiligen Arten ermittelt und mindestens ein Teil dieser Betriebsdaten in den RAM-Speicher (16) kopiert werden und/oder Zeiger gesetzt werden, die auf die Position und die Datenart der ermittelten Betriebsdaten hinweisen.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß beim Auslesen von Betriebsdaten aus dem Flash-Speicher (1) zunächst deren Integrität überprüft wird und, wenn diese Daten als fehlerhaft eingestuft werden, der Flash-Speicher nach früheren, intakten Betriebsdaten derselben Art durchsucht wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Flash-Speicher zur Ermittlung des Endes des mit Betriebsdaten belegten Speicherbereichs in virtuelle Blöcke unterteilt wird und blockweise überprüft wird, ob die in diesen enthaltenen Speicherbereiche leer sind oder Daten enthalten, und daß bei Ermittlung des Endes des belegten Speicherbereichs ein auf diese Stelle zeigender Zeiger gesetzt wird.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß beim Abschalten des Steuersystems die im RAM-Speicher (16) enthaltenen aktuellen Werte der Betriebsdaten gesucht und zu entsprechenden Datenblöcken zusammengestellt werden, die vor ihrer Speicherung im Flash- Speicher (1) jeweils mit einer die Datenart angebenden Kennung versehen werden.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß beim Bilden der Datenblöcke im RAM-Speicher (16) auch die resultierende Gesamtgröße der in den Flash-Speicher (1) zu übertragenden Daten ermittelt wird.
DE19740525A 1997-09-15 1997-09-15 Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug Expired - Fee Related DE19740525C1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
DE19740525A DE19740525C1 (de) 1997-09-15 1997-09-15 Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug
FR9811354A FR2768529B1 (fr) 1997-09-15 1998-09-11 Procede de mise en memoire et recuperation de donnees dans un systeme de commande, notamment dans un vehicule automobile
GB9820021A GB2330672B (en) 1997-09-15 1998-09-14 Process for storing and retrieving data in a control system, in particular in a motor vehicle
JP10260316A JPH11161563A (ja) 1997-09-15 1998-09-14 データの記憶および再生方法
US09/154,152 US6167338A (en) 1997-09-15 1998-09-15 Method for storing and retrieving data in a control system, in particular in a motor vehicle

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19740525A DE19740525C1 (de) 1997-09-15 1997-09-15 Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug

Publications (1)

Publication Number Publication Date
DE19740525C1 true DE19740525C1 (de) 1999-02-04

Family

ID=7842403

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19740525A Expired - Fee Related DE19740525C1 (de) 1997-09-15 1997-09-15 Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug

Country Status (5)

Country Link
US (1) US6167338A (de)
JP (1) JPH11161563A (de)
DE (1) DE19740525C1 (de)
FR (1) FR2768529B1 (de)
GB (1) GB2330672B (de)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0995637A1 (de) * 1998-10-19 2000-04-26 Mannesmann VDO Aktiengesellschaft Einrichtung zur Speicherung von Daten in einem Kraftfahrzeug
EP1065596A1 (de) * 1999-06-30 2001-01-03 Siemens Aktiengesellschaft Verfahren zur Organisation von Datensätzen im Arbeitsspeicher eines Datenverarbeitungsgerätes
DE10008516A1 (de) * 2000-02-24 2001-08-30 Zahnradfabrik Friedrichshafen Abstimmung des Betriebsverhaltens einer Betätigungseinrichtung
DE10040890C1 (de) * 2000-08-18 2002-01-31 Trw Automotive Electron & Comp System und Verfahren zum sicheren Hochtemperaturbetrieb eines Flash-Speichers
EP1286267A1 (de) 2001-08-17 2003-02-26 Sony International (Europe) GmbH Flash-basierter nichtflüchtiger Speicher
DE10138602A1 (de) * 2001-08-07 2003-03-06 Bosch Gmbh Robert Fahrzeugsteuergerät und Verfahren zum Betreiben eines Fahrzeugsteuergeräts
DE10222141A1 (de) * 2002-05-17 2003-11-27 Bayerische Motoren Werke Ag Verfahren zum Übermitteln von Fahrzeugdaten
DE102006003890A1 (de) * 2006-01-27 2007-08-02 Saurer Gmbh & Co. Kg Verfahren zum Speichern von Betriebszustandsdaten eines Elektromotors sowie ein Elektromotor zur Durchführung eines solchen Verfahrens
US8878661B2 (en) 2011-11-24 2014-11-04 Omron Automotive Electronics Co., Ltd. Information communication system and vehicle portable device
WO2015110280A1 (de) * 2014-01-21 2015-07-30 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum verschlüsseln, speichersystem für ein fahrzeug, kraftfahrzeug mit einem speichersystem und computerlesbares speichermedium

Families Citing this family (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6601015B1 (en) * 1998-03-02 2003-07-29 Cummins Engine Company, Inc. Embedded datalogger for an engine control system
JP4135220B2 (ja) * 1998-07-01 2008-08-20 株式会社デンソー 車両用電子制御装置
JP2000297444A (ja) * 1999-04-13 2000-10-24 Komatsu Ltd 建設機械の情報管理装置
DE50001502D1 (de) * 1999-05-21 2003-04-24 Papst Motoren Gmbh & Co Kg Verfahren zum nichtflüchtigen speichern mindestens eines betriebsdatenwerts eines elektromotors, und elektromotor zu durchführung eines solchen verfahrens
US6349250B1 (en) * 2000-10-26 2002-02-19 Detroit Diesel Corporation Clear historic data from a vehicle data recorder
DE10131300B4 (de) * 2001-07-02 2012-12-06 Robert Bosch Gmbh Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung abgelegten Daten und Mikrorechner-System
DE10256045A1 (de) * 2001-12-15 2003-06-26 Papst Motoren Gmbh & Co Kg Verfahren zur Verarbeitung von Daten bei einem elektronisch kommutierten Motor, und Motor zur Durchführung eines solchen Verfahrens
DE10163342A1 (de) * 2001-12-21 2003-07-10 Elektro Beckhoff Gmbh Unterneh Datenübertragungsverfahren, serielles Bussystem und Anschalteinheit für einen passiven Busteilnehmer
KR100785581B1 (ko) * 2003-05-20 2007-12-13 봇슈 가부시키가이샤 차량 제어 시스템의 복귀 제어 방법
US7536593B2 (en) * 2004-03-05 2009-05-19 International Business Machines Corporation Apparatus, system, and method for emergency backup
GB2433815B (en) * 2004-10-26 2009-02-25 Spansion Llc Non-volatile memory device
JP2006163933A (ja) * 2004-12-08 2006-06-22 Hitachi Ltd 制御データ記憶装置
US7634494B2 (en) * 2005-05-03 2009-12-15 Intel Corporation Flash memory directory virtualization
JP4648097B2 (ja) * 2005-06-06 2011-03-09 シャープ株式会社 レジストリ情報の修復方法および情報処理装置
DE202005012557U1 (de) * 2005-08-10 2006-12-21 Brose Fahrzeugteile Gmbh & Co. Kommanditgesellschaft, Coburg Steuerungsvorrichtung und Verstelleinrichtung eines Kraftfahrzeugs
US8117490B2 (en) * 2005-11-30 2012-02-14 Kelsey-Hayes Company Microprocessor memory management
US7876638B2 (en) * 2007-09-11 2011-01-25 Micron Technology, Inc. Storing operational information in an array of memory cells
US8661165B2 (en) 2008-10-27 2014-02-25 Lennox Industries, Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8655490B2 (en) 2008-10-27 2014-02-18 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9632490B2 (en) 2008-10-27 2017-04-25 Lennox Industries Inc. System and method for zoning a distributed architecture heating, ventilation and air conditioning network
US8463443B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8463442B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8255086B2 (en) 2008-10-27 2012-08-28 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8352081B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8295981B2 (en) 2008-10-27 2012-10-23 Lennox Industries Inc. Device commissioning in a heating, ventilation and air conditioning network
US8615326B2 (en) 2008-10-27 2013-12-24 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8560125B2 (en) 2008-10-27 2013-10-15 Lennox Industries Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9651925B2 (en) 2008-10-27 2017-05-16 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8994539B2 (en) 2008-10-27 2015-03-31 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US9261888B2 (en) 2008-10-27 2016-02-16 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8548630B2 (en) 2008-10-27 2013-10-01 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US9678486B2 (en) 2008-10-27 2017-06-13 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8600559B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. Method of controlling equipment in a heating, ventilation and air conditioning network
US8433446B2 (en) 2008-10-27 2013-04-30 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8694164B2 (en) 2008-10-27 2014-04-08 Lennox Industries, Inc. Interactive user guidance interface for a heating, ventilation and air conditioning system
US9325517B2 (en) 2008-10-27 2016-04-26 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8437877B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8892797B2 (en) 2008-10-27 2014-11-18 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8239066B2 (en) 2008-10-27 2012-08-07 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8774210B2 (en) 2008-10-27 2014-07-08 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8452906B2 (en) 2008-10-27 2013-05-28 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8600558B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8744629B2 (en) 2008-10-27 2014-06-03 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8543243B2 (en) 2008-10-27 2013-09-24 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8798796B2 (en) 2008-10-27 2014-08-05 Lennox Industries Inc. General control techniques in a heating, ventilation and air conditioning network
US8788100B2 (en) 2008-10-27 2014-07-22 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8442693B2 (en) 2008-10-27 2013-05-14 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8352080B2 (en) 2008-10-27 2013-01-08 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8802981B2 (en) 2008-10-27 2014-08-12 Lennox Industries Inc. Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system
US8655491B2 (en) 2008-10-27 2014-02-18 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US9432208B2 (en) 2008-10-27 2016-08-30 Lennox Industries Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8452456B2 (en) 2008-10-27 2013-05-28 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8762666B2 (en) 2008-10-27 2014-06-24 Lennox Industries, Inc. Backup and restoration of operation control data in a heating, ventilation and air conditioning network
US8725298B2 (en) 2008-10-27 2014-05-13 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network
US8437878B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US9152155B2 (en) 2008-10-27 2015-10-06 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8564400B2 (en) 2008-10-27 2013-10-22 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8874815B2 (en) 2008-10-27 2014-10-28 Lennox Industries, Inc. Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network
US8855825B2 (en) 2008-10-27 2014-10-07 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US9268345B2 (en) 2008-10-27 2016-02-23 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9377768B2 (en) 2008-10-27 2016-06-28 Lennox Industries Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8977794B2 (en) 2008-10-27 2015-03-10 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
JP5298345B2 (ja) * 2009-01-20 2013-09-25 日立コンシューマエレクトロニクス株式会社 テレビ受像機
US20100287217A1 (en) * 2009-04-08 2010-11-11 Google Inc. Host control of background garbage collection in a data storage device
US8447918B2 (en) 2009-04-08 2013-05-21 Google Inc. Garbage collection for failure prediction and repartitioning
US20100262979A1 (en) * 2009-04-08 2010-10-14 Google Inc. Circular command queues for communication between a host and a data storage device
US8205037B2 (en) * 2009-04-08 2012-06-19 Google Inc. Data storage device capable of recognizing and controlling multiple types of memory chips operating at different voltages
USD648641S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
USD648642S1 (en) 2009-10-21 2011-11-15 Lennox Industries Inc. Thin cover plate for an electronic system controller
JP5051214B2 (ja) * 2009-12-25 2012-10-17 株式会社デンソー 車載故障検出装置
US8260444B2 (en) 2010-02-17 2012-09-04 Lennox Industries Inc. Auxiliary controller of a HVAC system
CN102043722B (zh) * 2010-12-30 2012-06-13 重庆长安汽车股份有限公司 一种汽车总里程的存储方法
EP2503459B1 (de) * 2011-03-23 2021-01-20 Volvo Car Corporation Komplett und kompatibel-Funktion
US8918582B2 (en) 2012-09-11 2014-12-23 International Business Machines Corporation Simulating EEPROM in virtual distributed switches
US9509445B2 (en) * 2015-01-27 2016-11-29 Infineon Technologies Ag Sensor interface that provides a long package CRC to improve functional safety
CN105302577B (zh) * 2015-11-26 2019-05-07 上海兆芯集成电路有限公司 驱动执行单元的机器码产生方法以及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4209905C1 (en) * 1992-03-26 1993-05-19 Siemens Nixdorf Informationssysteme Ag, 4790 Paderborn, De Memory contents management system using EEPROM and RAM - compares new data with memory image stored in EEPROM, stores changed addresses of locations and writes corresp. contents in EEPROM

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5893893A (en) * 1990-05-29 1999-04-13 Autotronics, Inc. Device for the computerized recording of mileage and expenses in vehicles
EP0607455B1 (de) * 1992-08-11 1997-11-12 Denso Corporation Selbstdiagnosegerät eines fahrzeugs
US5404485A (en) * 1993-03-08 1995-04-04 M-Systems Flash Disk Pioneers Ltd. Flash file system
US6009370A (en) * 1993-07-26 1999-12-28 Hitachi, Ltd. Control unit for vehicle and total control system therefor
US5745864A (en) * 1994-10-04 1998-04-28 Nippondenso Co., Ltd. Vehicular information storage device and power outage-resistant storage system and method for the same
JP3693721B2 (ja) * 1995-11-10 2005-09-07 Necエレクトロニクス株式会社 フラッシュメモリ内蔵マイクロコンピュータ及びそのテスト方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4209905C1 (en) * 1992-03-26 1993-05-19 Siemens Nixdorf Informationssysteme Ag, 4790 Paderborn, De Memory contents management system using EEPROM and RAM - compares new data with memory image stored in EEPROM, stores changed addresses of locations and writes corresp. contents in EEPROM

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HAZEN, Peter, OKOTH, Isaiah: Flash-Technologie ersetzt EEPROMs, in: Design & Elektronik, Heft 18,1995, S. 38-41 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0995637A1 (de) * 1998-10-19 2000-04-26 Mannesmann VDO Aktiengesellschaft Einrichtung zur Speicherung von Daten in einem Kraftfahrzeug
EP1065596A1 (de) * 1999-06-30 2001-01-03 Siemens Aktiengesellschaft Verfahren zur Organisation von Datensätzen im Arbeitsspeicher eines Datenverarbeitungsgerätes
WO2001002961A1 (de) * 1999-06-30 2001-01-11 Infineon Technologies Ag Verfahren zur organisation von datensätzen im arbeitsspeicher eines datenverarbeitungsgerätes
DE10008516A1 (de) * 2000-02-24 2001-08-30 Zahnradfabrik Friedrichshafen Abstimmung des Betriebsverhaltens einer Betätigungseinrichtung
US6532410B2 (en) 2000-02-24 2003-03-11 Zf Friedrichshafen Ag Method coordinating operating behavior of motor vehicle device
DE10040890C1 (de) * 2000-08-18 2002-01-31 Trw Automotive Electron & Comp System und Verfahren zum sicheren Hochtemperaturbetrieb eines Flash-Speichers
DE10138602A1 (de) * 2001-08-07 2003-03-06 Bosch Gmbh Robert Fahrzeugsteuergerät und Verfahren zum Betreiben eines Fahrzeugsteuergeräts
DE10138602B4 (de) * 2001-08-07 2006-05-11 Robert Bosch Gmbh Fahrzeugsteuergerät und Verfahren zum Betreiben eines Fahrzeugsteuergeräts
EP1286267A1 (de) 2001-08-17 2003-02-26 Sony International (Europe) GmbH Flash-basierter nichtflüchtiger Speicher
DE10222141A1 (de) * 2002-05-17 2003-11-27 Bayerische Motoren Werke Ag Verfahren zum Übermitteln von Fahrzeugdaten
US7039510B2 (en) 2002-05-17 2006-05-02 Bayerische Motoren Werke Atkiengesellschaft Method of transmitting vehicle data
DE102006003890A1 (de) * 2006-01-27 2007-08-02 Saurer Gmbh & Co. Kg Verfahren zum Speichern von Betriebszustandsdaten eines Elektromotors sowie ein Elektromotor zur Durchführung eines solchen Verfahrens
US8878661B2 (en) 2011-11-24 2014-11-04 Omron Automotive Electronics Co., Ltd. Information communication system and vehicle portable device
DE102012111349B4 (de) * 2011-11-24 2015-05-13 Omron Automotive Electronics Co., Ltd. Informationskommunikationsvorrichtung und tragbare Fahrzeugeinrichtung
WO2015110280A1 (de) * 2014-01-21 2015-07-30 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum verschlüsseln, speichersystem für ein fahrzeug, kraftfahrzeug mit einem speichersystem und computerlesbares speichermedium

Also Published As

Publication number Publication date
JPH11161563A (ja) 1999-06-18
FR2768529B1 (fr) 2000-10-13
GB9820021D0 (en) 1998-11-04
FR2768529A1 (fr) 1999-03-19
US6167338A (en) 2000-12-26
GB2330672A (en) 1999-04-28
GB2330672B (en) 2002-07-24

Similar Documents

Publication Publication Date Title
DE19740525C1 (de) Verfahren zur Abspeicherung und Wiedergewinnung von Daten in einem Steuersystem, insbesondere in einem Kraftfahrzeug
DE60030876T2 (de) Bereichsverwaltung eines nichtflüchtigen Speichers mit hoher Kapazität
DE19615948C2 (de) Flash-Festkörper-Plattenspeicher-Karte
DE102005019842B4 (de) System und Verfahren zum sequentiellen Schreiben von Daten in einen Flash-Speicher
DE4040927C2 (de) Verfahren und Vorrichtung zur Fehlerspeicherung in einer Steuereinrichtung eines Kraftfahrzeugs
DE69821426T2 (de) Speicheranordung, und Datenverarbeitungssystem und -Verfahren
CH629901A5 (de) Verfahren zum steuern einer textverarbeitungseinrichtung beim speichern und lesen von text.
DE19810802A1 (de) Störungsfreies Aktualisieren von Daten
DE3743890A1 (de) Verfahren zum schnellen eroeffnen von plattendateien
DE3416939A1 (de) Verfahren zur steuerung von betriebseinrichtungen
EP1190324B1 (de) Verfahren zum gesicherten schreiben eines zeigers für einen ringspeicher
WO1987000714A1 (en) Process for compressing and expanding structurally associated multiple-data sequences, and arrangements for implementing the process
DE2400064A1 (de) Speicherpruefanordnung und diese verwendendes endgeraetsystem in einem datenverarbeitungssystem
DE19960258A1 (de) Flash-Speicher-Einheit und Verfahren zur Steuerung des Flash-Speichers
DE19839680A1 (de) Verfahren und Vorrichtung zur Veränderung des Speicherinhalts von Steuergeräten
DE102012101405B4 (de) Steuervorrichtung zum Steuern eines Datenlesens und - schreibens von und zu einem Flash-Speicher
DE10227255A1 (de) Verfahren zur Wiederherstellung von Verwaltungsdatensätzen eines blockweise löschbaren Speichers
DE19500626A1 (de) Programmierbare Steuerung und Verfahren zum Ändern ihrer Programmaufnahmefähigkeit
DE10260103A1 (de) Verfahren und Vorrichtung zur Änderung von Software in einem Steuergerät sowie entsprechendes Steuergerät
WO2004105042A1 (de) Vorrichtung und verfahren zum behandeln eines zustands eines speichers
DE10227256C1 (de) Verfahren zum Adressieren von blockweise löschbaren Speichern
DE112015002881B4 (de) Speichervorrichtung, Flash-Speicher-Steuervorrichtung und Programm
DE4392143C1 (de) Platten-Array-Vorrichtung
DE102006013759B4 (de) Verfahren und Recheneinheit zum Betreiben einer Speichereinrichtung
EP1276116B1 (de) Verfahren zur Speicherung zusammengehöriger Datensätze

Legal Events

Date Code Title Description
8100 Publication of the examined application without publication of unexamined application
D1 Grant (no unexamined application published) patent law 81
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee