WO2006035064A2 - Verfahren zur beschreibung von speicherinhalten und zur beschreibung des transfers von speicherinhalten - Google Patents

Verfahren zur beschreibung von speicherinhalten und zur beschreibung des transfers von speicherinhalten Download PDF

Info

Publication number
WO2006035064A2
WO2006035064A2 PCT/EP2005/054921 EP2005054921W WO2006035064A2 WO 2006035064 A2 WO2006035064 A2 WO 2006035064A2 EP 2005054921 W EP2005054921 W EP 2005054921W WO 2006035064 A2 WO2006035064 A2 WO 2006035064A2
Authority
WO
WIPO (PCT)
Prior art keywords
memory
segments
transfer
describing
contents
Prior art date
Application number
PCT/EP2005/054921
Other languages
English (en)
French (fr)
Other versions
WO2006035064A3 (de
Inventor
Martin Laichinger
Joerg Haecker
Andreas Aberfeld
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP05789521A priority Critical patent/EP1797500A2/de
Priority to US11/663,512 priority patent/US20080133823A1/en
Publication of WO2006035064A2 publication Critical patent/WO2006035064A2/de
Publication of WO2006035064A3 publication Critical patent/WO2006035064A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/202—Non-volatile memory
    • G06F2212/2022—Flash memory

Definitions

  • the present invention relates to a method for describing memory contents and for describing the transfer of memory contents.
  • the invention further relates to corresponding computer programs and computer program products.
  • a vehicle control device such as.
  • An engine control unit for motor vehicles must be adapted to the application, ie the engine.
  • individual control parameters, characteristics, maps, etc. are adjusted, ie a hardware of the controller is software-adapted to a particular engine (application).
  • the resulting effects are measured or evaluated in a measuring process.
  • the so-called application data is usually stored in non-volatile memories (flash memory) in conventional production control units.
  • the application data are typically contiguous in a corresponding data area in the memory area of the control unit. For a particular application, several such data areas (segments), each with different functionalities, are created.
  • a segmentation of the memory area is conventionally carried out according to functional criteria.
  • data is transferred to writable memory areas and changed there.
  • the effects of the changed data e.g. on the running or exhaust properties of a motor are measured.
  • these data are generally transferred to non-volatile and non-writable (ROM) or large-segment memory areas.
  • ROM non-volatile and non-writable
  • the way in which such data pass from one memory area to another is currently firmly coded in the usual application tools and specifically tailored to each individual application concept. Smallest changes to the application concept make immediate changes to the application tool necessary.
  • the invention seeks to enable the most general possible description of information in a Steuer ⁇ device memory.
  • the available memory area should be optimally utilized and a fast and reliable data transmission (Transfer between different segments of the memory area).
  • the invention proposes a method for the description of memory contents and for the description of the transfer of memory contents with the features of patent claim 1 and a control unit with the features of patent claim 6.
  • the invention further proposes a correspondingly designed computer program and a correspondingly designed computer program product according to claims 7 and 8, respectively.
  • ECU application concepts can now be described holistically.
  • Application tools can be variable, representing an emulation concept depending on the selected description.
  • the way of exchanging information, for example flash programming, copying, etc. no longer has to be firmly coded.
  • the only prerequisite according to the invention is that the described methods are implemented in the application tool.
  • segments of the memory area can be described with elements based on all of the known types of descriptions. It is quite possible to describe different segments with similar data. For example. It is also conceivable memory segments for a memory layout, or Pages of the application concept or segments within the application data.
  • code or data can be components of a flash memory.
  • such a computer program is able to transfer any memory contents with the described interfaces and / or the described methods for transfer without changing its code.
  • FIG. 1 shows an example of a currently customary application system including an application tool
  • FIG. 2 is a schematic diagram showing a preferred embodiment of a description of a memory layout according to the present invention
  • FIG. 3 shows a diagram for illustrating a preferred embodiment of a description of an application concept according to the present invention.
  • FIG. 1 shows schematically a currently customary application system including an application tool.
  • a control device By means of an application tool designated as a whole by 10, a control device, designated here in its entirety by 20, is to be set.
  • non-volatile control device memory flash memory 22
  • program code code
  • data SG data
  • the data in the non-volatile memory 22 serves as backup data in the event that data has been lost in a volatile memory, such as a RAM 24, for example due to a power interruption.
  • the RAM 24 would be initialized with the data in the flash memory 22.
  • Part of this data area may contain measurement configurations, for example for a start measurement.
  • the data in the RAM 24 are to be changed and are intended to work within the scope of the application.
  • 2 areas are created in the RAM, namely a reference page 25 and a working page 26. Further pages are possible. Between these two areas 25, 26, it is possible to switch over under the control of the application tool 10 (switching means are shown schematically and designated by 30, 31). Data is essentially adjusted on the working side 26, whereby the effects of such adjustments on the reference page 25 can be verified.
  • the work page 26 can be transferred as the process progresses again and again as a new reference page or used to provide new backup data.
  • a portion of the regions 25, 26 may contain measurement configurations 28.
  • the mirroring of the reference page is denoted by 25 ', the mirroring of the working page by 26'.
  • the reference page 25 in the RAM 24 may include the difference (difference data) between the area 22a and the data of the mirror 25 '.
  • the working page 26 may include difference data regarding the SG data and the mirror 26 '.
  • the reflection of the code memory area 22b in the flash memory 22 is designated 22b.
  • the mirroring of the measurement configurations that may be provided in the RAM is indicated at 28 '.
  • the mirroring serves for the verification, the visualization and the saving of the work result.
  • the verification can be carried out, for example, by expSummens.
  • the application tool is conventionally hard-coded.
  • Emulation concepts are only possible with a concerted tool change.
  • An update of the SG data can be accomplished via a logical connection 32 between the application tool 10 and the flash memory 22, an update of the code data via a logical connection 33.
  • the logical connections can be in the form of physical connections.
  • the updates of code and data can be done independently.
  • the present invention illustrates how the abovementioned segments (segmentation according to physical criteria or non-physical criteria) and in particular an exchange of information between the different segments can be described.
  • a control device application concept can be described completely according to the invention.
  • Application tools can be variably formed according to the invention, i. H. depending on this description represent the emulation concept. How an information exchange has to be made concretely, or takes place, for example by means of a flash process, copying process etc., does not have to be permanently coded.
  • the only prerequisite according to the invention is that the described methods are implemented in the application tool.
  • the segments of a control device memory are described with elements based on the sum of the known descriptions.
  • purely physical segments logical or virtual segments can be described.
  • Interfaces are described for the exchange of information with or between these segments. These Descriptions may be included, for example, in an ASAM or MSR description file.
  • segments There is a representation of the description of the segments. Elements are described based on the sum of the known descriptions. Different segments may well be described here (for example memory segments for a memory layout of the control device, pages of the application concept or even segments within the application data). In this case, it is conceivable in particular that one segment is part of another segment. For example, a code segment and / or a data segment could be part of a flash segment. The following are exemplary features of such a description listed, depending on the purpose or specific circumstances, one or the other feature may be optional:
  • RAM RAM buffered, ROM, Flash, EEPROM etc.
  • Segmentation information (segment segment, entire segment, cross-segment, virtual segment),
  • control unit automatically supplementing missing information if necessary
  • - type of execution eg external low-level flash process, internal flash Process, simple copying of memory contents, etc.
  • Reference numeral 100 thus represents a typical memory image of a control device.
  • volatile memory areas RAM areas 105
  • nonvolatile memory areas flash areas 110
  • ROM area 106 a ROM area 106
  • FIG. 1 the description of the entire flash memory area 110 is given.
  • FIG. 111 ' the description of a physical segment within flash memory area 110 is further characterized.
  • the descriptions at 110 ', 111' are exemplary of the holistic description of the memory map provided in accordance with the invention.
  • a code storage area 210 ie software for controlling the control unit functions, for example
  • a data area 220 in which, for example, control units; and / or motor parameters are stored. Further Characteristics of these areas, again in list form, are given at 210 'and 220'.
  • the flash control area is denoted here by 310, the RAM memory area by 340. Details regarding the flash memory are shown in Figure 3 at 355 in list form.
  • the ROM area is denoted by 320 in FIG. 3 and 330 by an external RAM area.
  • FIG. 3 shows different methods for transmitting or transferring memory units between different memory areas.
  • Transfer methods are supported in the controller, i. There is great flexibility with regard to the numerous transfer methods that can be used.
  • Such a transfer method using only a copy operation, is described for example in method 7.
  • data in the internal RAM 350 is copied from the reference side to the working side (see also Fig. 1, reference numerals 25, 26).
  • the corresponding copy command is indicated at 300 under method 7 with "XCP-Comand COPY_CAL_PAGE ().
  • the invention comprises two main components.
  • a general description of the information stored in the control unit is realized as a segment object for various purposes by combining the known special methods, for example description of memory layout, application concept (supplemented by transfer methods) and data differentiation.
  • a description of transfer methods from, to and between the individual segments is also shown. in this connection
  • These transfer methods represent defined interfaces between segments in the control unit memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

Verfahren zur Beschreibung von Inhalten eines Speichers und zur Beschreibung eines Transfers von Inhalten eines Speichers oder Speicherbereiches eines Fahrzeug- Steuergeräts, mit folgenden Schritten: - Beschreibung von Segmenten eines Speicherbereiches des Speichers mit seinen Eigenschaften, wobei die Segmente als physikalische Segmente und/oder logische Segmente und/oder funktionale Segmente ausgebildet sind, - Definition von Schnittstellen und/oder Methoden zum Transfer von Speicherinhalten von, aus und/oder zwischen den Segmenten, wobei die Schnittstellen und/oder Methoden Art und Weise, Zeitpunkt und weitere Randbedingungen des Transfers beschreiben.

Description

Verfahren zur Beschreibung von Speicherinhalten und zur Beschreibung des Transfers von Speicherinhalten
Die vorliegende Erfindung betrifft ein Verfahren zur Beschreibung von Speicherinhalten und zur Beschreibung des Transfers von Speicherinhalten. Die Erfindung betrifft ferner entsprechende Computerprogramme und Computerprogrammprodukte.
Stand der Technik
Die Funktionalität eines Fahrzeugsteuergerätes, wie bspw. eines Motorsteuergerätes für Kraftfahrzeuge, muss an die Anwendung, d.h. den Motor angepasst werden. Hierzu werden einzelne Regelparameter, Kennwerte, Kennfelder etc. verstellt, d.h. eine Hardware des Steuergeräts wird softwaremäßig an einen bestimmten Motor angepasst (Applikation) . Anschließend werden die hieraus resultierenden Auswirkungen in einem Messvorgang gemessen bzw. ausgewertet. Das Ergebnis dieser Anpassung, die sogenannten Applika¬ tionsdaten, sind in herkömmlichen Seriensteuergeräten üblicherweise in nichtflüchtigen Speichern (Flash-Speicher) gespeichert. Die Applikationsdaten liegen typischerweise zusammenhängend in einem entsprechendem Datenbereich im Speicherbereich des Steuergeräts . Für eine bestimmte Applikation werden mehrere derartiger Datenbereiche (Segmente) mit jeweils unterschiedlichen Funktionalitäten angelegt.
Eine Segmentierung des Speicherbereichs erfolgt herkömm¬ licherweise nach funktionalen Kriterien.
Im Rahmen der Applikation werden Daten in beschreibbare Speicherbereiche ausgelagert und dort verändert. Die Auswirkungen der geänderten Daten, z.B. auf die Lauf- oder Abgaseigenschaften eines Motors, werden gemessen. Bei Arbeitsende oder bei fertigapplizierten Teilfunktionen werden diese Daten in der Regel in nichtflüchtige und nichtschreibbare (ROM) oder groß segmentierte Speicherbe¬ reiche transferiert. Die Art und Weise, wie derartige Daten von einem Speicherbereich in einen anderen gelangen, ist derzeit in den üblichen Applikationstools fest codiert und speziell auf jedes individuelle Applikationskonzept zugeschnitten. Kleinste Änderungen am Applikationskonzept machen unmittelbar Änderungen am Applikationstool notwendig.
Die Erfindung strebt an, eine möglichst allgemeine Beschreibung von Informationen in einem Steuer¬ gerätespeicher zu ermöglichen. Hierbei soll der zur Verfügung stehende Speicherbereich optimal ausgenutzt werden und eine schnelle und zuverlässige Datenübertragung (Transfer zwischen unterschiedlichen Segmenten des Speicherbereichs) ermöglichen.
Vorteile der Erfindung
Die Erfindung schlägt ein Verfahren zur Beschreibung von Speicherinhalten und zur Beschreibung des Transfers von Speicherinhalten mit den Merkmalen des Patentanspruchs 1 sowie ein Steuergerät mit den Merkmalen des Patentanspruchs 6 vor. Die Erfindung schlägt ferner ein entsprechend ausgebildetes Computerprogramm und ein entsprechend ausgebildetes Computerprogrammprodukt gemäß den Ansprüchen 7 bzw. 8 vor.
Erfindungsgemäß lassen sich Steuergeräte-Applikations¬ konzepte nun ganzheitlich beschreiben. Applikationstools können variabel, in Abhängigkeit der gewählten Beschreibung ein Emulationskonzept darstellen. Die Art und Weise des Informationsaustausches, bspw. Flashprogrammierung, Kopiervorgang etc., muss nicht mehr fest codiert sein. Voraussetzung ist erfindungsgemäß lediglich, dass die beschriebenen Methoden im Applikationstool implementiert sind.
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche.
Es ist bevorzugt, dass die Segmente des Speicherbereiches mit Elementen basierend auf sämtlichen der bekannten Beschreibungsarten beschrieben werden können. Hierbei ist es durchaus möglich, unterschiedliche Segmente mit gleichartigen Daten zu beschreiben. Bspw. ist es auch denkbar, Speichersegmente für ein Memory-Layout, oder Seiten des Applikationskonzeptes oder Segmente innerhalb der Applikationsdaten zu beschreiben.
Es ist ferner in vorteilhafter Weise möglich, dass ein Segment Bestandteil eines weiteren Segments ist. Hierbei kann bzw. können bspw. Code oder Daten Bestandteile eines Flash-Speichers sein.
Es ist bevorzugt, dass die Beschreibung des Inhalts eines Speichers oder Speicherbereiches und/oder die Schnittstelle und/oder Methoden zum Transfer in einer einheitlich definierten Form einem Computerprogramm, beispielsweise einem in einem Steuergerät oder einem Applikationstool implementierten Computerprogramm, zur Verfügung gestellt wird bzw. werden.
In besonders vorteilhafter Weise ist ein derartiges Computerprogramm in der Lage, beliebige Speicherinhalte mit den beschriebenen Schnittstellen und/oder den beschriebenen Methoden zum Transfer ohne Änderung seines Codes zu transferieren.
Figurenbeschreibung
Die Erfindung wird nun weiter anhand der beigefügten Zeichnung beschrieben. In dieser zeigt
Figur 1 ein Bespiel eines derzeit üblichen Applikations¬ systems einschließlich eines Applikationstools,
Figur 2 ein schematisches Schaubild zur Darstellung einer bevorzugten Ausführungsform einer Beschreibung eines Speicher-Layouts gemäß der vorliegenden Erfindung, und Figur 3 ein Schaubild zur Darstellung einer bevorzugten Ausführungsform einer Beschreibung eines Applikations¬ konzepts gemäß der vorliegenden Erfindung.
In Figur 1 ist ein derzeit übliches Applikationssystem einschließlich eines Applikationstools schematisch darge¬ stellt.
Mittels eines insgesamt mit 10 bezeichneten Appli- kationstools ist ein Steuergerät, hier insgesamt mit 20 bezeichnet, einzustellen.
In einem nichtflüchtigen Steuergerätespeicher (Flash- Speicher) 22 sind Programmiercode („Code") und Daten bzw. Steuergerätedaten („SG-Daten") enthalten. Die SG-Daten sind hierbei in einem Bereich 22a, der Code in einem Bereich 22b gespeichert. Die Daten in dem nichtflüchtigen Speicher 22 dienen als Backup-Daten für den Fall, dass es in einem flüchtigen Speicher, etwa einem RAM 24 bspw. aufgrund einer Spannungsunterbrechung zu Datenverlusten gekommen ist. In diesem Fall würde der RAM 24 mit den Daten im Flash- Speicher 22 initialisiert. Ein Teil dieses Datenbereiches kann Messkonfigurationen, bspw. für eine Startmessung enthalten.
Die Daten in dem RAM 24 sind zu verändern, und dienen dem Arbeiten im Rahmen der Applikation. In dem RAM sind hierbei 2 Bereiche angelegt, nämlich eine Referenzseite 25 und eine Arbeitsseite 26. Weitere Seiten sind möglich. Zwischen diesen beiden Bereichen 25, 26 kann gesteuert durch das Applikations-Tool 10 umgeschaltet werden (Umschaltmittel sind schematisch dargestellt und mit 30, 31 bezeichnet) . Daten werden im wesentlichen auf der Arbeitsseite 26 verstellt, wobei die Auswirkungen derartiger Verstellungen auf der Referenzseite 25 verifiziert werden können. Die Arbeitsseite 26 kann bei fortschreitendem Arbeitsvorgang immer wieder als neue Referenzseite übertragen oder zur Bereitstellung neuer Backup-Daten verwendet werden. Ein Teil der Bereiche 25, 26 kann Messkonfigurationen 28 ent¬ halten.
In dem Applikations-Tool 10 ist jeweils eine Spiegelung der veränderbaren Daten, der Messkonfigurationen und des Codes enthalten. Die Spiegelung der Referenzseite ist mit 25', die Spiegelung der Arbeitsseite mit 26' bezeichnet. Es sei angemerkt, dass die Referenzseite 25 im RAM 24 die Differenz (Differenzdaten) zwischen dem Bereich 22a und den Daten der Spiegelung 25'beinhalten bzw. darstellen kann. Entsprechend kann die Arbeitsseite 26 Differenzdaten bezüglich der SG-Daten und der Spiegelung 26' beinhalten.
Die Spiegelung des Code-Speicherbereiches 22b in dem Flash- Speicher 22 ist mit 22b bezeichnet. Die Spiegelung der Meßkonfigurationen, die in dem RAM vorgesehen sein können, ist mit 28' bezeichnet.
Die Spiegelung dient der Verifikation, der Visualisierung und dem Speichern des Arbeitsergebnisses. Die Verifikation kann bspw. durch PrüfSummenaustausch durchgeführt werden.
Das Applikationstool ist herkömmlicherweise fest codiert.
Hier sei beispielsweise auf die in Fachkreisen bekannte Speicherseitenverwaltung des Applicationstools INCA verwiesen. Änderungen des Applikationskonzeptes bzw.
Emulationskonzeptes sind dort nur bei gleichzeitiger abgestimmter Tooländerung möglich. Ein Update der SG-Daten ist über eine logische Verbindung 32 zwischen dem Applikationstool 10 und dem Flash-Speicher 22 bewerkstelligbar, ein Update der Code Daten über eine logische Verbindung 33. Die logischen Verbindungen können in Form physikalischer Verbindungen ausgebildet sein. Die Updates von Code und Daten können unabhängig voneinander erfolgen.
Bei bekannten Lösungen handelt es sich in der Regel um Beschreibungen von physikalischen Gruppierungen (RAM, ROM, EEPROM, Flash, etc.), logischen Gruppierungen (CODE, DATA, VARIABLES, etc.) und funktionalen Gruppierungen (Arbeits¬ und Referenzseite von Applikationssystemen) . Eine Beschrei¬ bung des Informationsaustausches zwischen den einzelnen Gruppierungen existiert nicht, und ist deshalb in den Applikationstools fest codiert. Auch hier sei auf die bekannte Speicherseitenverwaltung des Applikationstools INCA verwiesen. Ferner bekannt sind Beschreibungen von Speichersegmenten nach ASAM MCD 2MC Vl.X. Hierbei handelt es sich um die Beschreibung von Speichersegmenten, deren Typ und der Art der speicherbaren Information. Diese enthält beispielsweise eine Bezeichnungsinformation, z.B. ID Text, etc., eine Lokalisierungsinformation, z.B. Startadresse, Länge, Offset, etc., eine Information zum Speicher-Typ, RAM, ROM, Flash, etc. Ferner sind Informationen bzgl. der Inhaltsart (oder Daten, Variable) sowie weitere Informationen, beispielsweise bzgl. eines Zugriffes für verschiedene Applikationsschnittstellen, möglich.
Dies sei anhand des bekannten Speicherseitenver- waltungskonzeptes des Applikationstools INCA noch einmal verdeutlicht. Dieses umfasst ein paralleles Applikationskonzept mit Emulatortastkopf (Target) . Hierbei sind auch toolseitige Bestandteile des Applikationssystems darstellbar. Der Informationsaustausch wird repräsentiert durch Funktionen wie etwa Download, Kopieren, Flash- Programmieren etc. Der Informationsaustausch ist fest codiert, er weist keinerlei Flexibilität auf. Anpassungen auf einer Seite, bspw. auf Seiten des Steuergeräts, führen unmittelbar zu einem Änderungsaufwand auf der anderen Seite, d.h. auf der Seite des Applikationstools.
Mit der vorliegenden Erfindung wird dargestellt, wie die oben genannten Segmente (Segmentierung nach physikalischen Kriterien bzw. nicht physikalischen Kriterien) und insbesondere ein Informationsaustausch zwischen den unterschiedlichen Segmenten beschrieben werden kann. Mit einer derartigen Darstellung von Methoden zum Infor¬ mationsaustausch zwischen den Segmenten läßt sich erfindungsgemäß ein Steuergeräte-Applikationskonzept ganz¬ heitlich beschreiben. Applikationstools können erfindungs¬ gemäß variabel ausgebildet werden, d. h. in Abhängigkeit dieser Beschreibung das Emulationskonzept darstellen. Wie ein Informationsaustausch konkret zu erfolgen hat, bzw. erfolgt, beispielsweise mittels Flashprozess, Kopiervorgang etc. muß nicht fest kodiert sein. Voraussetzung ist erfindungsgemäß lediglich, dass die beschriebenen Methoden im Applikationstool implementiert sind.
Erfindungsgemäß werden die Segmente eines Steuergeräte- Speichers mit Elementen basierend auf der Summe der bekannten Beschreibungen beschrieben. Hierbei können je nach Bedarf oder Anwendung rein physikalische Segmente, logische oder virtuelle Segmente beschrieben werden. Für den Informationsaustausch mit bzw. zwischen diesen Segmenten werden Schnittstellen beschrieben. Diese Beschreibungen können beispielsweise in einer ASAM- oder einer MSR-Beschreibungsdatei enthalten sein.
Es erfolgt eine Darstellung der Beschreibung der Segmente. Mit Elementen basierend auf der Summe der bekannten Beschreibungen werden die Segmente beschrieben. Hierbei können durchaus unterschiedliche Segmente beschrieben werden (beispielsweise Speichersegmente für ein Memory- Layout des Steuergeräts, Seiten des Applikationskonzeptes oder auch Segmente innerhalb der Applikationsdaten) . Hierbei ist insbesondere denkbar, dass ein Segment Bestand¬ teil eines anderen Segments ist. Zum Beispiel könnte ein Code-Segment und/oder ein Daten-Segment ein Bestandteil eines Flash-Segments sein. Im Folgenden sind beispielhaft Merkmale einer solchen Beschreibung aufgeführt, wobei je nach Zweck bzw. konkreten Gegebenheiten das eine oder andere Merkmal optional sein kann:
- Bezeichnungsinformation (ID, Text, etc.),
- Lokalisierungsinformation (Startadresse, Länge, Offset, intern, extern, etc. ),
- Information zu Speicher-Typ (RAM, RAM gepuffert, ROM, Flash, EEPROM etc.),
- Zugriffsart (Lesen und/oder Schreiben) ,
- Informationen zur Segmentierung (Segmentausschnitt, ganzes Segment, segmentübergreifend, virtuelles Segment) ,
- Information zur Ansprechbarkeit in Abhängigkeit von der Segmentierung (beispielsweise segmentübergreifend als Ganzes oder jeweils einzeln ansprechbar oder bei Segment¬ ausschnitt direkt ansprechbar, wobei das Steuergerät falls erforderlich fehlende Informationen selbstständig ergänzt) ,
- Information zur Inhalts-Art (Code, Online- oder Offline- Daten, Variablen, etc.)
- Informationen für Zugriff über verschiedene Applikationsschnittstellen (Mappinginformation,etc. ) - Initialisierungsart, sofern nicht als Autotransfermethode beschrieben, weitere Attribute (Fallback-, Working-, Reference-, Startup-Seite, etc.)
Es folgt eine Beschreibung erfindungsgemäß verwendbarer Transfermethoden. Für den Informationsfluß von Inhalten von, zu oder zwischen den nach bekannten Methoden beschriebenen Segmenten werden Schnittstellen definiert, die Art und Weise, Zeitpunkt und weitere Randbedingungen des Informationsflusses beschreiben. Im folgenden sind Merkmale einer solchen Beschreibung aufgeführt, wobei je nach Zweck oder konkreten Gegebenheiten das eine oder andere Merkmal optional sein kann: - Bezeichnungsinformation (ID, Text, etc.),
- Source- und Destination-Segment (Ausgangs- und Ziel- Segment) ,
- Ausführungsinformation (automatisch, manuell) ,
- Ausführungszeitpunkt (Startphase, Betriebsphase, Stop- phase, sonstige Phasen bzw. Triggerereignisse) ,
- Ausführungsrandbedingungen / -beschränkungen (bestimmte Betriebszustände, beispielsweise v=0km/h, Gültigkeit von Gruppierungsinhalten, zum Beispiel Daten im RAM durch Spannungsverlust nicht mehr gültig, etc.), - Ausführungsart (beispielsweise externer Low-Level-Flash- Prozess, interner Flash-Prozess, einfaches Kopieren von Speicherinhalten, etc.), welche je nach verwendetem Inter¬ face unterschiedlich sein kann,
- Ausführungsdetails, sofern erforderlich, welche je nach verwendetem Interface unterschiedlich sein können
(beispielsweise externer Low-Level-Flash-Prozess mit Job- language bzw. Jobsprache, Kommunikation-Interface-Kommando mit XCP Page-Copy-Befehl, etc.) . Ein konkretes Ausführungsbeispiel einer erfindungsgemäß vorgesehenen Beschreibung eines Speicher-Layouts ist in
Figur 2 dargestellt. Man erkennt hier drei verwendete
Beschreibungsarten, nämlich die Beschreibung gemäß Memory- Layout (bei 100) , die Beschreibung gemäß Funktionalität
(bei 200) und die Beschreibung gemäß der Applikation bzw. aus Applikationssicht (bei 300) . Bezüglich der einzelnen
Ausgestaltungen der jeweiligen Beschreibungen wird insbesondere auf die Erläuterungen in Figur 2 verwiesen. Es sei auch hier noch einmal darauf hingewiesen, dass die einzelnen Beschreibungsarten sich nicht gegenseitig ausschließen. Mit Bezugszeichen 100 wird somit ein typisches Speicherabbild eines Steuergeräts dargestellt. Man erkennt insbesondere flüchtige Speicherbereiche (RAM- Bereiche 105) , nicht flüchtige Speicherbereiche (Flash- Bereiche 110) und einen ROM-Bereich 106. Unterhalb der Beschreibung des Memory-Layouts sind in Listenform weitere Charakteristika des dargestellten Memory-Layouts angegeben. Bei 110' ist die Beschreibung des gesamten Flashspeicherbereiches 110 angegeben. Mit 111' ist die Beschreibung eines physikalischen Segments innerhalb des Flashspeicherbereiches 110 näher charakterisiert. Die Beschreibungen bei 110', 111' sind beispielhaft für die erfindungsgemäß vorgesehene ganzheitliche Beschreibung des Speicherabbildes .
Die bei 200 angegebene Beschreibung eines Speicher-Layouts gemäß seiner Funktionalität ist in zwei wesentliche Bereiche unterteilt, nämlich einem Bereich 210 zur Speicherung von Code, d.h. beispielsweise Software zur Steuerung der Steuergerätefunktionen, und einen Datenbereich 220, in dem beispielsweise Steuergeräte; und/oder Motorparameter gespeichert sind. Weitere Charakteristika dieser Bereiche, wiederum in Listenform, sind bei 210' und 220' angegeben.
Bei 300 ist die Beschreibung des Speicher-Layouts aus Applikationssicht beschrieben. Auch hier sind spezielle Charakteristika bei 300' in Listenform angegeben.
Die Beschreibung einer erfindungsgemäß realisierbaren Beschreibung eines Applikationskonzepts ist in Figur 3 dargestellt. Hier sind auch bevorzugte Transfermethoden zur Übertragung von Daten zwischen den einzelnen Segmenten dargestellt. Bezüglich der Einzelheiten wird wiederum auf die Erläuterungen in Figur 3 verwiesen.
Man erkennt die verschiedenen Speicherbereiche des Steuergeräts, wie sie bereits unter Bezugnahme auf die Figuren 1 und 2 beschrieben wurden. Der Flash-Steuerbereich ist hier mit 310, der RAM-Speicherbereich mit 340 bezeichnet. Einzelheiten bzgl. des Flash-Speichers sind in Figur 3 bei 355 in Listenform aufgezeigt. Der ROM-Bereich ist in Figur 3 mit 320, ein externer RAM-Bereich mit 330 bezeichnet.
In Figur 3 sind unterschiedliche Verfahren zur Übertragung bzw. zum Transfer von Speichereinheiten zwischen verschiedenen Speicherbereichen dargestellt.
Erfindungsgemäß wesentlich ist, dass sämtliche
Transfermethoden im Steuergerät unterstützt werden, d.h. bzgl. der zahlreich verwendbaren Transfermethoden große Flexibilität besteht.
Verschiedene einsetzbare Transfermethoden sind bei 300 in Listenform angegeben. Die unterschiedlichen Transfermethoden sollen anhand einiger Beispiele angegeben werden. Bzgl. der hier nicht im einzelnen diskutierten Transfermethoden wird auf die expliziten Erläuterungen in Figur 3 (bei 300) verwiesen. Sollen beispielsweise Daten von der Referenzseite in dem internen RAM 350 in den entsprechenden Bereich des Flash-Speichers 310 transferiert werden (dort als "Seite 1 Backup-DataPage" bezeichnet) , wird die mit 360 bezeichnete Transfermethode 5 verwendet. Diese Transfermethode erfordert eine entsprechende Programmierung des Flash-Speichers 310, wie durch die Charakterisierung "XCP-Comand, SET_REQUEST (Store_Cal_Req) unter Methode 5 bei 300 angegeben. Ein einfacher Low Level Flash zum Transfer von Daten in den (nicht flüchtigen) Flash-Speicher 310 wäre hier zwar auch möglich, wird jedoch aus Sicherheitsgründen nicht bevorzugt.
Eine derartige Transfermethode, unter Verwendung lediglich eines Kopiervorgangs, ist beispielsweise bei Methode 7 beschrieben. Hier werden Daten im internen RAM 350 von der Referenzseite auf die Arbeitsseite kopiert (siehe auch Figur 1, Bezugszeichen 25, 26) . Der entsprechende Kopierbefehl ist bei 300 unter Methode 7 angegeben mit "XCP-Comand COPY_CAL_PAGE () .
Zusammenfassend seien noch einmal der Kern und die Vorteile der vorliegenden Erfindung herausgestellt: Die Erfindung umfasst zwei Hauptbestandteile. Zunächst ist erfindungs¬ gemäß eine allgemeine Beschreibung der im Steuergerät gespeicherten Information als Segmentobjekt für verschiedene Zwecke durch Kombination der bekannten speziellen Methoden realisiert, beispielsweise Beschreibung Memory-Layout, Applikationskonzept (ergänzt durch Transfermethoden) und Datendifferenzierung. Es ist ferner eine Beschreibung von Transfermethoden von, nach und zwischen den einzelnen Segmenten dargestellt. Hierbei stellen diese Transfermethoden definierte Schnittstellen zwischen Segmenten im Steuergerätespeicher dar. Mit diesen Beschreibungen läßt sich das im Steuergerät implementierte Applikationskonzept beschreiben. Ein Applikationstool kann dieses anhand der Beschreibung darstellen und umsetzen, ohne speziell kodiert werden zu müssen, sofern die beschriebenen Transfermethoden unterstützt werden.
Als Vorteil ergibt sich insbesondere, dass ein herkömmlich nicht zu vermeidender Abstimmungsaufwand zwischen Steuergeräteherstellern und Toolherstellern entfällt. Jedes Tool, welches die beschriebenen Methoden unterstützt, ist ohne eine vorherige Abstimmung einsetzbar. Ferner kann ein Applikations-/Emulationskonzept individuell im Steuergerät den zur Verfügung stehenden Ressourcen (Speicher, Interfaces bzw. Schnittstellen, ...) angepaßt werden, und entsprechend dem Entwicklungsstand adaptiert werden dies ebenfalls ohne die Notwendigkeit einer Abstimmung mit Toolherstellern. Individuelle Kundenwünsche können ohne Berücksichtigung möglicher Auswirkungen auf das zu verwendende Applikationstool erfüllt werden. Ein Toolhersteller muß seinerseits nur eine universelle Standardlösung pflegen. Das bezüglich eines Steuergerätes jeweils anzuwendende Applikations-/Emulationskonzept ist aus standarisierten Transfermethoden zusammenstellbar. Die Fehleranfälligkeit sinkt durch einen höheren Reifegrad in diesem Zusammenhang einsetzbarer Standardmodule. Erweiterungen erfolgen lediglich durch Ergänzung weiterer Transfermethoden bzw. Erweiterungen mit weiteren Standardmodulen. Als besonders vorteilhaft erweist sich, das technisch erforderliche Anpassungen bei immer kürzer werdenden Entwicklungszyklen gegenüber herkömmlichen Lösungen leichter durchführbar sind, da sie steuergeräteseitig flexibel sind und toolseitig nur Teilanpassungen benötigt werden.

Claims

Ansprüche
1. Verfahren zur Beschreibung von Inhalten eines Speichers und zur Beschreibung eines Transfers von Inhalten eines Speichers oder Speicherbereiches eines Fahrzeug- Steuergeräts, mit folgenden Schritten:
- Beschreibung von Segmenten eines Speicherbereiches des Speichers mit seinen Eigenschaften, wobei die Segmente als physikalische Segmente und/oder logische Segmente und/oder funktionale Segmente ausgebildet sind,
- Definition von Schnittstellen und/oder Methoden zum Transfer von Speicherinhalten von, aus und/oder zwischen den Segmenten, wobei die Schnittstellen und/oder Methoden Art und Weise, Zeitpunkt und weitere Randbedingungen des Transfers beschreiben.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Segmente des Speicherbereiches mit Elementen basierend auf sämtlichen der bekannten Beschreibungsarten beschrieben werden.
3. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, das ein Segment Bestandteil eines weiteren Segments ist.
4. Verfahren in einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Beschreibung des Inhalts eines Speichers oder Speicherbereiches und/oder die Schnittstelle und/oder Methoden zum Transfer in einer einheitlich definierten Form einem Computerprogramm zur Verfügung gestellt wird.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass das Computerprogramm beliebige Speicherinhalte mit den beschriebenen Schnittstellen und/oder den Methoden zum Transfer ohne Änderung seines Codes transferieren kann.
6. Steuergerät, insbesondere für ein Kraftfahrtzeug, dadurch gekennzeichnet, dass es einen Speicher aufweist, dessen Inhalt nach einem der vorstehenden Verfahren beschrieben und/oder transferiert werden kann.
7. Computerprogramm mit Programmcode-Mitteln, um sämt¬ liche Schritte des Verfahrens nach einem der Ansprüche 1 bis 5 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Rechnereinheit ausge¬ führt wird.
8. Computerprogrammprodukt mit Programmcode-Mitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um das Verfahren nach einem der Ansprüche 1 bis 5 durch¬ zuführen, wenn das Computerprogrammprodukt auf einem Computer oder auf einer entsprechenden Rechnereinheit aus¬ geführt wird.
PCT/EP2005/054921 2004-09-30 2005-09-29 Verfahren zur beschreibung von speicherinhalten und zur beschreibung des transfers von speicherinhalten WO2006035064A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05789521A EP1797500A2 (de) 2004-09-30 2005-09-29 Verfahren zur beschreibung von speicherinhalten und zur beschreibung des transfers von speicherinhalten
US11/663,512 US20080133823A1 (en) 2004-09-30 2005-09-29 Method For Describing Memory Contents And For Describing The Transfer Of Memory Contents

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE102004048195 2004-09-30
DE102004048195.4 2004-09-30
DE102005001430A DE102005001430A1 (de) 2004-09-30 2005-01-12 Verfahren zur Beschreibung von Speicherinhalten und zur Beschreibung des Transfers von Speicherinhalten
DE102005001430.5 2005-01-12

Publications (2)

Publication Number Publication Date
WO2006035064A2 true WO2006035064A2 (de) 2006-04-06
WO2006035064A3 WO2006035064A3 (de) 2006-07-06

Family

ID=35985276

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/054921 WO2006035064A2 (de) 2004-09-30 2005-09-29 Verfahren zur beschreibung von speicherinhalten und zur beschreibung des transfers von speicherinhalten

Country Status (4)

Country Link
US (1) US20080133823A1 (de)
EP (1) EP1797500A2 (de)
DE (1) DE102005001430A1 (de)
WO (1) WO2006035064A2 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008063466A1 (de) * 2008-12-17 2010-02-25 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Antriebssytems und nach dem Verfahren arbeitendes Antriebssystem
DE102008063468A1 (de) * 2008-12-17 2010-02-25 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Antriebssystems und nach dem Verfahren arbeitendes Antriebssystem
DE102010063773A1 (de) * 2010-12-21 2012-07-12 Endress + Hauser Wetzer Gmbh + Co. Kg Feldgerät mit einem semi-permanenten elektronischen Speicher und Verfahren zum Betreiben eines solchen Feldgerätes
US20130111212A1 (en) * 2011-10-28 2013-05-02 GM Global Technology Operations LLC Methods to provide digital signature to secure flash programming function
US8930710B2 (en) * 2011-10-28 2015-01-06 GM Global Technology Operations LLC Using a manifest to record presence of valid software and calibration
DE102012016169A1 (de) 2012-08-14 2013-02-28 Daimler Ag Verfahren zur Daten-Aktualisierung eines Steuergeräts
US9430220B2 (en) * 2014-07-22 2016-08-30 GM Global Technology Operations LLC Method, medium, and apparatus for re-programming flash memory of a computing device

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19625619A1 (de) * 1996-06-26 1998-01-02 Siemens Ag Verfahren zum Abspeichern von Daten
DE19836748C1 (de) * 1998-08-13 2000-04-20 Siemens Ag Verfahren zum Applizieren von Steuerdaten eines elektronischen Kraftfahrzeug-Steuergeräts
DE10138602A1 (de) * 2001-08-07 2003-03-06 Bosch Gmbh Robert Fahrzeugsteuergerät und Verfahren zum Betreiben eines Fahrzeugsteuergeräts
DE10159480A1 (de) * 2001-12-04 2003-06-26 Daimler Chrysler Ag Steuervorrichtung

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6546477B1 (en) * 1999-09-20 2003-04-08 Texas Instruments Incorporated Memory management in embedded systems with dynamic object instantiation
US7035948B1 (en) * 2001-03-19 2006-04-25 Transdimension, Inc. System and method for USB controllers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19625619A1 (de) * 1996-06-26 1998-01-02 Siemens Ag Verfahren zum Abspeichern von Daten
DE19836748C1 (de) * 1998-08-13 2000-04-20 Siemens Ag Verfahren zum Applizieren von Steuerdaten eines elektronischen Kraftfahrzeug-Steuergeräts
DE10138602A1 (de) * 2001-08-07 2003-03-06 Bosch Gmbh Robert Fahrzeugsteuergerät und Verfahren zum Betreiben eines Fahrzeugsteuergeräts
DE10159480A1 (de) * 2001-12-04 2003-06-26 Daimler Chrysler Ag Steuervorrichtung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"ASAM Schnittstellen" ELEKTRONIK INDUSTRIE, Bd. 9, 1999, Seiten 90-93, XP002291529 *

Also Published As

Publication number Publication date
US20080133823A1 (en) 2008-06-05
DE102005001430A1 (de) 2006-04-13
EP1797500A2 (de) 2007-06-20
WO2006035064A3 (de) 2006-07-06

Similar Documents

Publication Publication Date Title
WO2006035064A2 (de) Verfahren zur beschreibung von speicherinhalten und zur beschreibung des transfers von speicherinhalten
DE10308545A1 (de) Verfahren und Vorrichtung zum Aktualisieren eines verteilten Programms
DE102007059524B4 (de) Verfahren zum Erzeugen einer Betriebssoftware auf einem Steuergerät für ein Kraftfahrzeug sowie Steuergerät
EP3776222B1 (de) Verfahren zum bereitstellen von anwendungsdaten zumindest einer auf einem steuergerät eines fahrzeugs ausführbaren anwendung, verfahren zum kalibrieren eines steuergeräts, steuergerät und auswerteeinrichtung
EP0500973B1 (de) EEPROM und Verfahren zum Ändern einer Initialisierungsroutine im EEPROM
DE10106504A1 (de) Verfahren und Vorrichtung zum Emulieren von Steuer- und/oder Regelfunktionen eines Steuer- oder Regelgeräts
DE102018202446A1 (de) Verfahren zum Modularisieren einer Softwarearchitektur
EP1889128B1 (de) Verfahren und vorrichtung zur umschaltung bei einem speicher für ein steuergerät
DE19911794B4 (de) Verfahren und Vorrichtung zur Absicherung bei Veränderung des Speicherinhalts von Steuergeräten
DE102011007714A1 (de) Architektur für einen gemeinsam genutzten Speicher
DE19931184A1 (de) Verfahren und Vorrichtung zur Veränderung des Speicherinhalts von Steuergeräten
EP2456124A1 (de) Geberschnittstellenengineering
EP0265636A1 (de) Multiprozessor mit mehreren mit Cache-Speichern ausgerüsteten Prozessoren und einem gemeinsamen Speicher
DE102008023873A1 (de) Verfahren zum Betrieb eines Antriebssystems
DE19963475A1 (de) Verfahren und Vorrichtung zur Steuerung von Betriebsabläufen in einem Fahrzeug sowie zur Bereitstellung von Daten diesbezüglich
DE112009001842T5 (de) Steuervorrichtung, Steuerverfahren und Computerprogramm
EP2490086B1 (de) Verfahren zum Betrieb eines Automatisierungssystems und nach dem Verfahren arbeitendes Computerprogramm
EP0296149B1 (de) Verfahren zur Datenänderung im Parameterspeicher eines Kraftfahrzeug-Reglers
DE102018123563A1 (de) Verfahren zur Zwischenkernkommunikation in einem Mehrkernprozessor
EP1137991B1 (de) Verfahren und vorrichtung zur steuerung von prozessen in einem fahrzeug
EP2455831A1 (de) Engineering einer Datenkommunikation
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
DE102009024019A1 (de) Fehlererkennungscode-Speichermodul
DE102016207768A1 (de) Vorrichtung und Verfahren zum Bereitstellen einer Menge von Modultypen
DE19748181B4 (de) Verfahren zum Prüfen einer Funktion oder Einrichtung eines Fahrzeugs

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2005789521

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200580033114.5

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2005789521

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11663512

Country of ref document: US

WWR Wipo information: refused in national office

Ref document number: 2005789521

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11663512

Country of ref document: US

WWW Wipo information: withdrawn in national office

Ref document number: 2005789521

Country of ref document: EP