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 KraftfahrzeugInfo
- 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
Links
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11C—STATIC STORES
- G11C7/00—Arrangements for writing information into, or reading information out from, a digital store
- G11C7/20—Memory cell initialisation circuits, e.g. when powering up or down, memory clear, latent image memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates 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.
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)
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)
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)
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)
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エレクトロニクス株式会社 | フラッシュメモリ内蔵マイクロコンピュータ及びそのテスト方法 |
-
1997
- 1997-09-15 DE DE19740525A patent/DE19740525C1/de not_active Expired - Fee Related
-
1998
- 1998-09-11 FR FR9811354A patent/FR2768529B1/fr not_active Expired - Fee Related
- 1998-09-14 GB GB9820021A patent/GB2330672B/en not_active Expired - Fee Related
- 1998-09-14 JP JP10260316A patent/JPH11161563A/ja not_active Withdrawn
- 1998-09-15 US US09/154,152 patent/US6167338A/en not_active Expired - Fee Related
Patent Citations (1)
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)
Title |
---|
HAZEN, Peter, OKOTH, Isaiah: Flash-Technologie ersetzt EEPROMs, in: Design & Elektronik, Heft 18,1995, S. 38-41 * |
Cited By (15)
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 |