WO2006063919A2 - Erkennung und anzeige von modifikationen an softwareständen für motorsteuergerätesoftware - Google Patents

Erkennung und anzeige von modifikationen an softwareständen für motorsteuergerätesoftware Download PDF

Info

Publication number
WO2006063919A2
WO2006063919A2 PCT/EP2005/056109 EP2005056109W WO2006063919A2 WO 2006063919 A2 WO2006063919 A2 WO 2006063919A2 EP 2005056109 W EP2005056109 W EP 2005056109W WO 2006063919 A2 WO2006063919 A2 WO 2006063919A2
Authority
WO
WIPO (PCT)
Prior art keywords
software
modification
control unit
label
checksum
Prior art date
Application number
PCT/EP2005/056109
Other languages
English (en)
French (fr)
Other versions
WO2006063919A3 (de
Inventor
Thomas Burger
Achim Reuther
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP05825295A priority Critical patent/EP1825362A2/de
Publication of WO2006063919A2 publication Critical patent/WO2006063919A2/de
Publication of WO2006063919A3 publication Critical patent/WO2006063919A3/de

Links

Classifications

    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D41/00—Electrical control of supply of combustible mixture or its constituents
    • F02D41/24—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means
    • F02D41/2406—Electrical control of supply of combustible mixture or its constituents characterised by the use of digital means using essentially read only memories
    • F02D41/2425—Particular ways of programming the data
    • F02D41/2487—Methods for rewriting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02N—STARTING OF COMBUSTION ENGINES; STARTING AIDS FOR SUCH ENGINES, NOT OTHERWISE PROVIDED FOR
    • F02N11/00—Starting of engines by means of electric motors
    • F02N11/10—Safety devices
    • F02N11/101—Safety devices for preventing engine starter actuation or engagement

Definitions

  • the invention relates to a method for detecting a modification to software versions for control unit software, in particular in an engine control unit for motor vehicles with internal combustion engines (gasoline or diesel engines).
  • engine control refers to both an engine control unit and a complex of functionalities needed to control an engine.
  • control of the manifold complicated processes in modern internal combustion engines is one of the very important applications of microelectronics.
  • the regulation of the electronic ignition systems and the idling speed as well as the lambda control play an outstanding role.
  • An active engine control and an adaptive Ge ⁇ gear control are important agents for the adjustment of the sys- tems to the respective driving situation. These control mechanisms are implemented by modern engine control units.
  • the engine control units are equipped by the manufacturers with control unit software that has a precisely defined software version.
  • This original software versions can be generated at a certain time, and each egg ⁇ nen particular product stand.
  • the original software versions are supplied as a product to customers.
  • the source files are used in the stand production out labels and registered in the original software versions. This identification usually takes place by the entry of a checksum (calculated from the source code), with the aid of which a specific software version can be verified later.
  • Modifications of the supplied original software objects are recognized in that the engine control unit an Ver ⁇ equal to the checksum currently Gela which control unit software is carried out with the valid for a defined original software version checksum one in the engine control unit. If the two compared checksums are identical, is located in the engine control unit, an unmodified original Soft ⁇ ware stood. Motor operation is permitted without restrictions. If the checksum values deviate from one another, then the currently loaded ECU software is a modified software version and the engine operation is blocked.
  • these tools can change the functionalities of the software without having to resort to the source files of the original software version. H. In this case, only the machine code of the control unit software generated from the source files is modified. That means a
  • the object of the invention is to provide opportunities available which make the detection of a modification of an original software object whilst providing ons Informati ⁇ about the nature of a determined modification available.
  • a method and a control unit, in particular a motor control unit, are proposed which ensure the detection and display of a modification to a software version for a control unit software in an engine control unit.
  • a check sum is calculated for an unmodified software version (original software version) of the ECU software.
  • the calculation of the check sum by means of a given before ⁇ formulas on the basis of a ons kau in information applied standard method.
  • This checksum is used to verify a specific software version and enables the detection of changes or errors in the original software version.
  • the dard snake after Stan ⁇ calculated checksum of Originals- software object is registered as an identifier in this at a predefined memory location.
  • a predefined memory location is also provided in the original software version, the label being written during the modification of the control unit software by a tool software and indicating the type of modification.
  • An initial value which was defined during the generation of the software version, is entered in the original software version at the memory location intended for the label.
  • the initial value represents a specific string.
  • a statement as to whether the present modification can be applied ⁇ or not approved, may not be taken after the checksum test.
  • the memory location is first sen for the laser at widelyle from the currently loaded ECU software ⁇ in the engine control device after the detection of an existing modification.
  • the value of the read memory location is in tor crizology Mo ⁇ with predetermined Labels compared. This given before ⁇ label stored in the engine control unit as control values for an approved modification.
  • the value read from the memory location is identical to a given label.
  • the value read out corresponds to the initial value entered in the original software version at the memory location for the label or to an undefined value. In this way it can be determined whether the introduced in a Mo ⁇ torschen réelle ECU software has been modified with an approved tool software configuration.
  • the control unit software is configured so that upon detection ⁇ an authorized modification of the controller software position not blocking the engine operation is carried out, however, is locked in an unauthorized modification of the motor drive.
  • the inhibition of the engine operation in case of detected unauthorized modifications of the ECU software can be configured configurable (activation / deactivation). This function advantageously ensures protection against unwanted changes in the control unit software.
  • the method on which the invention is based has the advantage that it is possible to work with tools for modifying software versions, while still getting an overview of possible modifications. No checksum checks need to be disabled to maintain a consistency check, and no tools for recalculating and updating checksum entries are passed on. In addition, it is possible to configure the ECU software so that modifications are no longer allowed at all.
  • checksum check does not have to be deactivated and therefore a modification of the ECU software is always recognized.
  • the engine control unit can be equipped so that the visual display of a detected modification via a blink code of a diagnostic lamp.
  • Such visual indicator may be either integrated directly on a display in a vehicle or part of a measurement and Diagnosesys ⁇ tems or a tester.
  • For the user of a control unit is thereby directly recognizable, whether in the Mo- gate control unit is an original software version or a modifi ⁇ ed state.
  • the method ensures that the Informatio ⁇ contained in the label NEN a measurement and calibration system, or an available tester for further analysis and display available ge ⁇ represents be. This means that after the detection of a modification of the currently loaded ECU software, the read value of the label via an interface to a
  • Measuring and calibration system or tester is transmitted.
  • the data read out are displayed in the measuring and calibration system or tester.
  • implemented label is adapted to an authorized modification through a defined tool software is that it contains at least one of the following Add ⁇ formations:
  • the recognition of an unauthorized modification is given by the fact that in this case at the intended memory location for the label nor the registered in the generation of the original software version I-nitialwert is, or that at this memory location an undefined value is registered.
  • Every supplied for an authorized modification to a user tool software configuration is precisely defined and implemented in the modification of a control device software implementation of a label, which also contains about Informati ⁇ on which user the software tool verwen- he has. Also contained in the implemented label is the information about which functionalities of the control unit software have been modified by the used tool software in accordance with the specific requirements of the user.
  • a division of the control unit software into a plurality of areas can be realized, whereby in each case one check sum per area is calculated.
  • the original software version is configured so that several software areas are created. For each of these areas a separate checksum is formed. These separate checksums are ever ⁇ wells entered in the relevant field of software in a space provided location. Likewise, an initial value is generated for each area, which is entered at the location intended for the implementation of a label.
  • the verification mechanism for ⁇ He identification and display a modification of the ECU software already described above would be separately this software ranges for each in the existence of several software areas performed.
  • a Computerpro ⁇ program for modifying a ECU software would be in an engine control unit.
  • the tool software writes a label to a predefined location of the control units ⁇ software, after the controller software has been modified by the tool ⁇ software, the label indicates ⁇ fication the kinds of modes, that the label contains information DAR over whether approved or unauthorized Modifi ⁇ cation is present.
  • the tool software may also contain encrypted information about where the label location is and what the label's content is.
  • the ⁇ se encryption has the advantage that is not obvious to the user of the tool software, where and with what ⁇ In just the label is written.
  • the invention includes an engine control unit. This is loaded with respect to an original software version possibly modified ECU software.
  • the engine control unit is equipped with means for calculating the checksum of a control unit software loaded in the engine control unit. This check is performed during startup ⁇ sum calculation. Likewise, the engine control unit is provided with means which ensure the execution of a comparison between the calculated checksum and a check sum for the original software version entered in a predetermined memory location of the control unit software. Furthermore, in Motorêtge ⁇ advises means available for deciding that upon coincidence of the checksum the loaded control unit software is not modified, and that in case of non-conformity of the checksum, the charged controller software is modified.
  • the engine control unit also has means for reading out labels written by a tool software for authorized modification of the controller software.
  • the label indicates the type of modification.
  • Fig. 1 is a schematic diagram of an engine control unit
  • Fig. 2 is a schematic diagram of the method for detecting and displaying a modification to a software version of a motor controller software
  • Fig. 3 is a schematic diagram of the marking of the software prior ⁇ a motor control device software
  • 3A is a schematic diagram of the identification of the original software version of an engine control unit software.
  • Fig. 3B is a schematic diagram of marking an article modi- ed software of a motor control device ⁇ software
  • Fig. 4 is a schematic diagram of reading the information from a label.
  • Fig. 5 is a schematic diagram of the identification of the software state of an engine control unit software at Auftei ⁇ ment of the control unit software in several areas.
  • Fig. 1 the schematic diagram of a motor controller 100 is shown.
  • the signal flow 102 is from the various sensors and commandors (eg accelerator pedal adjustment, throttle position, air mass, battery voltage, intake air temperature, engine temperature, knock intensity, lambda probes) and signal flow 104 (eg, crankshaft speed, camshaft position, gear stage,
  • sensors and commandors eg accelerator pedal adjustment, throttle position, air mass, battery voltage, intake air temperature, engine temperature, knock intensity, lambda probes
  • signal flow 104 eg, crankshaft speed, camshaft position, gear stage
  • the program which the microcontroller 114 is to execute is stored in the OTP block (Open-Time Programmable Block) 116.
  • the data flow between the microcontroller 114 and the OTP block 116 takes place via the connection 118.
  • the data transfer between the microcontroller 114 and the CAN bus 122 takes place via the connection 120.
  • the CAN bus 122 makes it possible to connect all devices via a single cable to network with each other.
  • the data transfer between the microcontroller 114 and a diagnostic system 124 takes place via the connection 126.
  • the microcontroller 114 with its components realizes its functions on the basis of the ge in the OTP block 116 ⁇ preset program. After processing the signals from the sensors and setpoint generators 102, 104 in the microcontroller 114, the further signal flow from the microcontroller 114 takes place via the connections 128, 130, 132, 134 and via the input / output ports 136, 138, 140, 142 to the various Akto ⁇ ren 144 (z. B. ignition coils and spark plugs), 146 (z. B. throttle selklappensteller), 148 (z. B. injectors) and 150 (. e.g., main relay, engine tachometer, fuel pump relay, heating Lambda sensor, camshaft control, tank ventilation, intake manifold changeover, secondary air, exhaust gas recirculation).
  • microcontrollers 114 are increasingly being used with very high computational power, with the functionality of the controller software modifiable to effectively adapt to the specific needs of different users.
  • Fig. 2 the schematic diagram of the method for detecting and displaying a modification to a software version of an engine control unit software is shown.
  • the engine control unit 100 is started in step 202.
  • the checksum of the control unit software currently loaded in the engine control unit is calculated in step 204.
  • the calculated checksum of the control currently loaded in the engine Device software is compared in step 206 with the checksum entered in the original software version.
  • a decision is made as to whether the compared checksums match or not, that is, there is a yes-no branch of the procedure.
  • step 210 If the check sum calculated in step 204 and the checksum entered in the original software version are identical, then in step 210 the currently loaded control unit software is classified as not modified. As a result, engine operation is permitted in step 212.
  • step 214 If the calculated checksum is not identical to the checksum entered in the original software version, a modification of the currently loaded control unit software is detected in step 214. This detected modification can be optically signaled via a diagnostic lamp 216.
  • step 218 reads the memory location for the label.
  • step 220 the read-out value of the storage location defined for the label is compared with predetermined values for characteristic labels which are written in the modification by a tool software.
  • step 222 it is decided whether the values of the read out ⁇ NEN memory location match or not for the label with the predefined values for a characteristic label, ie, there is a further yes-no branching of the process sequence.
  • step 224 the modification is considered to be authorized and in step 226, the engine operation is allowed. Is selected from the memory location read out for the label value is identical with the data entered in the original software prior initial value or contains the memory location a non-defi ⁇ -defined value, then the modification is considered not admitted in step 228 and in step 230, in depen ⁇ For example, engine operation is not permitted by the configuration of the original ECU software.
  • the information contained in the label can be made available to a measuring and calibration system / tester for further evaluation and analysis.
  • FIG. 3 shows a schematic diagram of the identification of a software version before and after a modification.
  • Fig. 3A is an original control unit software 302 is provided with egg ⁇ ner tag 304.
  • the registered original checksum 308 is shown as a first identification feature and the initial value 310 entered at the storage location for the label is shown as a second identification feature.
  • a modified controller software 312 has been provided with a modified identifier 314.
  • the detail section 316 of this modified identification 314 indicates that the modified control unit software includes first identification feature, the registered original checksum 308 of the original software, and as a second identification feature of the registered by the software tool 318 to label ⁇ .
  • FIG. 4 shows a simplified schematic diagram for the display of the software version of a control unit software. Is recognized a modification of the ECU software at ⁇ play, in the checksum test the engine control unit, the checksum of the unmodified original ECU software and the checksum that is, the currently tax The downloaded software is not identical. This he ⁇ known modification is visually displayed via a diagnostic lamp 216. A connected measuring and calibration system / tester 404 is provided with the information read from the storage space for the label.
  • the read-out label 406 has a characteristic value entered by a tool software and contains the information that the detected modification is permitted.
  • the display 408 indicates the nature of the fixed frame ⁇ th information that an approved Modifika ⁇ tion present. This displayed information 408 about a permitted modification justifies the display 410 about an approval of the engine operation.
  • Fig. 5 the principle of marking the software version of an engine control unit software is displayed in a division of the software in several areas.
  • the MotorCon ⁇ eroarasoftware 502 with the aim of better containment of a modification che for example in three Softwareberei- 504 divided 506 and 508th Each of these software areas
  • each area in detail 511, 513 and 515 consists of its own original checksum 516, 518 and 520 and the label 522, 524, 526 entered by the tool software during a modification. This means that per software area 504, 506 and 508 a checksum exis ⁇ advantage.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Abstract

Moderne Verfahren zur Modifikation von Softwareständen in Motorsteuergeräten ermöglichen nicht mehr eine direkte Erkennung von Modifikationen an einem Softwarestand für eine Steuergerätesoftware. In der Erfindung werden in einen Original- Softwarestand einer Steuergerätesoftware an einer vordefinierten Stelle eine Checksumme (308) und ein Initialwert (310) eingetragen. Eine gegenüber dem Original-Software (302) eventuell modifizierte Steuergerätesoftware (312) wird in das Motorsteuergerät geladen. Nach dem Start des Motorsteuergerätes wird eine Checksummenprüfung der aktuell geladenen Steuergerätesoftware (312) ausgeführt. Die berechnete Checksumme der aktuell geladenen Steuergerätesoftware (312) wird mit der in den Original-Softwarestand (302) eingetragenen Checksumme (308) verglichen. Sind die beiden Checksummen nicht identisch, dann ist die aktuell geladene Steuergerätesoftware (312) modifiziert und es erfolgt das Auslesen eines durch eine Toolsoftware bei der Modifikation der Steuergerätesoftware (312) geschriebenen Labels (318) . Das Label enthält Informationen über die Art und den Umfang einer festgestellten Modifikation.

Description

Beschreibung
Erkennung und Anzeige von Modifikationen an Softwareständen für Motorsteuergerätesoftware
Gebiet der Erfindung
Die Erfindung betrifft ein Verfahren zur Erkennung einer Modifikation an Softwareständen für Steuergerätesoftware, ins- besondere in einem Motorsteuergerät für Kraftfahrzeuge mit Verbrennungsmotoren (Benzin- oder Dieselmotoren) . Dabei bezeichnet der Begriff Motorsteuerung sowohl ein Motorsteuergerät als auch einen Komplex von Funktionalitäten, die zur Steuerung eines Motors benötigt werden.
Stand der Technik
Die Steuerung der vielfältigen komplizierten Prozesse in modernen Verbrennungskraftmaschinen zählt zu den sehr wichtigen Anwendungsbereichen der Mikroelektronik. Dabei spielen beispielsweise die Regelung der elektronischen Zündsysteme und der Leerlauf-Drehzahl sowie die Lambdaregelung eine herausragende Rolle. Eine aktive Motorregelung und eine adaptive Ge¬ trieberegelung sind wesentliche Mittel zur Anpassung der Sys- teme an die jeweilige Fahrsituation. Diese Regelungsmechanis¬ men werden durch moderne Motorsteuergeräte realisiert.
Die Motorsteuergeräte werden durch die Hersteller mit einer Steuergerätesoftware ausgestattet, die einen genau definier- ten Softwarestand hat. Diese Original-Softwarestände werden zu einem bestimmtem Zeitpunkt erzeugt und stellen jeweils ei¬ nen bestimmten Produktstand dar. Die Original-Softwarestände werden als Produkt an die Kunden ausgeliefert.
Um die Original-Softwarestände jederzeit genau identifizieren zu können und die Konsistenz der Softwarestände zu gewährleisten, werden bei der Standerzeugung aus den Quelldateien heraus Kennzeichnungen erzeugt und in die Original- Softwarestände eingetragen. Diese Kennzeichnung erfolgt i. d. R. durch den Eintrag einer Checksumme (berechnet aus dem Quellcode) , mit deren Hilfe ein bestimmter Softwarestand spä- ter genau verifiziert werden kann.
Modifikationen der ausgelieferten Original-Softwarestände werden dadurch erkannt, dass im Motorsteuergerät ein Ver¬ gleich der Checksumme einer im Motorsteuergerät aktuell gela- denen Steuergerätesoftware mit der für einen definierten Original-Softwarestand gültigen Checksumme durchführt wird. Sind die beiden verglichenen Checksummen identisch, dann befindet sich im Motorsteuergerät ein unmodifizierter Originalsoft¬ warestand. Der Motorbetrieb wird ohne Einschränkungen zuge- lassen. Weichen die Checksummenwerte voneinander ab, dann ist die aktuell geladene Steuergerätesoftware ein modifizierter Softwarestand und der Motorbetrieb wird gesperrt.
Auf Grund spezifischer Anforderungen der Kunden zur Realisie- rung bestimmter Funktionalitäten der Motorsteuergerätesoftware kann eine Modifikation des Softwarestandes der Steuerge¬ rätesoftware z. B. durch den Kunden erforderlich und zugelassen sein. Um eine solche Modifikation zu ermöglichen und eine Sperrung des Motorbetriebes auszuschließen, wird daher in der Regel die Checksummenprüfung deaktiviert. Das führt jedoch dazu, dass Modifikationen, d. h. zugelassene und nicht zuge¬ lassene, nicht mehr ohne zusätzliche Aktivitäten erkannt wer¬ den.
Welche Funktionalitäten durch eine Modifikation beeinflusst wurden, kann auch bei einer aktivierten Checksummenprüfung nicht direkt rekonstruiert werden. Dazu muss der gesamte Softwarestand aus dem Motorsteuergerät ausgelesen werden und ein anschließend ein Binärvergleich zwischen dem aktuellen Softwarestand und dem Originalstand durchgeführt werden. In neuerer Zeit existieren am Markt auch Werkzeuge beziehungsweise Software-Tools, mit denen fertige Original- Softwarestände bequem funktionell modifiziert werden können und damit zugelassene Modifikationen realisierbar sind. Häu- fig werden dazu für erforderliche Modifikationen von den Herstellern weiterhin die Checksummenprüfungen deaktiviert oder Tools mit einer Funktion zum Neuberechnen und Update der Checksummeneinträge zur Verfügung gestellt.
Diese Tools können durch eine Modifikation des Softwarestandes eine Änderung der Funktionalitäten der Software herbeiführen, ohne dass auf die Quelldateien des Original- Softwarestandes zurück gegriffen werden muss, d. h. es wird dabei nur der aus den Quelldateien erzeugte Maschinencode der Steuergerätesoftware modifiziert. Das bedeutet, dass eine
Checksummenprüfung (basierend auf den aus den Originalsoft¬ wareständen berechneten Checksummen) bei Deaktivierung der Checksummenprüfung oder Neuberechnung der Checksumme im Zuge der Modifikation keine Erkennung einer Modifikation mehr er- möglicht. Daraus resultiert, dass beim Auslesen der bisheri¬ gen Kennzeichnungen der Softwarestände nicht mehr festge¬ stellt werden kann, ob eine Modifikation vorliegt und der Softwarestand verändert wurde. Das Ergebnis ist, dass die Softwarestände nicht mehr ohne weiteres vor nicht zugelasse- nen Modifikationen geschützt werden können.
Daher kann bei eventuell auftretenden Fehlfunktionen eines Motorsteuergerätes keine sofortige Diagnose getroffen werden, ob der im Motorsteuergerät befindliche Softwarestand über- haupt ein getesteter und freigegebener Originalstand ist. Die verbleibende Möglichkeit für die Erkennung einer Modifikation sowie ihrer Art und des Umfanges ist damit das aufwändige Verfahren zum Auslesen des gesamten Softwarestandes.
Aufgabe Aufgabe der Erfindung ist es, Möglichkeiten zur Verfügung zu stellen, welche die Erkennung einer Modifikation eines Original-Softwarestandes gewährleisten und gleichzeitig Informati¬ onen über die Art einer festgestellten Modifikation zur Ver- fügung stellen.
Lösung
Diese Aufgabe wird durch die Erfindungen mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Weiterbildun¬ gen der Erfindungen sind in den Unteransprüchen gekennzeichnet. Der Wortlaut sämtlicher Ansprüche wird hiermit durch Be¬ zugnahme zum Inhalt dieser Beschreibung gemacht.
Es werden ein Verfahren und ein Steuergerät, insbesondere ein Motorsteuergerät, vorgeschlagen, welche die Erkennung und An¬ zeige einer Modifikation an einem Softwarestand für eine Steuergerätesoftware in einem Motorsteuergerät gewährleisten.
Im Folgenden werden einzelne Verfahrensschritte näher be¬ schrieben. Die Schritte müssen nicht notwendigerweise in der angegebenen Reihenfolge durchgeführt werden, und das zu schildernde Verfahren kann auch weitere, nicht genannte Schritte aufweisen.
Zunächst wird für einen unmodifizierten Softwarestand (Original-Softwarestand) der Steuergerätesoftware eine Checksumme berechnet. Die Berechnung der Checksumme erfolgt mittels vor¬ gegebener Formeln auf der Grundlage eines in der Informati- onsverarbeitung angewendeten Standardverfahrens.
Diese Checksumme dient der Verifikation eines bestimmten Softwarestandes und ermöglicht das Erkennen von Veränderungen oder Fehlern im Original-Softwarestand. Die nach dem Stan¬ dardverfahren berechnete Checksumme des Originals- Softwarestandes wird in diesen an einer vordefinierten Speicherstelle als Kennzeichnung eingetragen. Für die Eintragung eines Labels wird im Original- Softwarestand ebenfalls eine vordefinierte Speicherstelle vorgesehen, wobei das Label bei der Modifikation der Steuergerätesoftware durch eine Toolsoftware geschrieben wird und die Art der Modifikation angibt.
An die für das Label vorgesehene Speicherstelle wird in den Original-Softwarestand ein Initialwert eingetragen, der bei der Generierung des Softwarestandes definiert worden ist. Der Initialwert stellt eine bestimmte Zeichenfolge dar.
Für den Betrieb eines Motorsteuergerätes wird eine gegenüber dem Original-Softwarestand eventuell modifizierte Steuergerä¬ tesoftware zur Verfügung gestellt und in das Motorsteuergerät geladen.
Beim Startvorgang des Motorsteuergerätes wird eine Checksum¬ menprüfung der im Motorsteuergerät aktuell geladenen Steuergerätesoftware ausgeführt.
Zunächst wird dabei die Checksumme der aktuell im Motorsteu¬ ergerät geladenen Steuergerätesoftware berechnet. Diese wäh¬ rend des Startvorganges des Motorsteuergerätes berechnete Checksumme wird mit der Checksumme verglichen, die für den Original-Softwarestand berechnet wurde. Durch den Checksum¬ menvergleich wird der Status der aktuell im Motorsteuergerät geladenen Steuergerätesoftware bestimmt.
Entspricht die berechnete Checksumme der für den Original- Softwarestand eingetragenen Checksumme, dann ist die aktuell geladene Steuergerätesoftware nicht modifiziert, d. h. im Mo¬ torsteuergerät befindet sich ein Originalstand der Steuerge¬ rätesoftware.
Entspricht die berechnete Checksumme nicht der für den Origi¬ nal-Softwarestand eingetragenen Checksumme, dann wird eine Modifikation der aktuell geladenen Steuergerätesoftware ge- genüber dem Original-Softwarestand festgestellt. Die Check¬ summenprüfung der Steuergerätesoftware stellt jedoch nur eine Information darüber zur Verfügung, dass eine Modifikation der Steuergerätesoftware vorliegt.
Eine Aussage darüber, ob die vorliegende Modifikation zuge¬ lassen oder nicht zugelassen ist, kann nach der Checksummenprüfung noch nicht getroffen werden.
Da bei der Checksummenprüfung noch keine Bestimmung der Art der Modifikation erfolgt ist, d. h. ob die festgestellte Mo¬ difikation eine zugelassene oder eine nicht zugelassene Modi¬ fikation darstellt, ist das Verfahren so konzipiert, dass nach dem Erkennen einer Modifikation durch die Checksummen- prüfung als nächster Schritt eine Prüfung der Zulässigkeit der festgestellten Modifikation erfolgt.
Dabei wird zunächst im Motorsteuergerät nach dem Feststellen einer vorhandenen Modifikation die Speicherstelle für das La- bei aus der aktuell geladenen Steuergerätesoftware ausgele¬ sen. Der Wert der ausgelesenen Speicherstelle wird im Mo¬ torsteuergerät mit vorgegebenen Labels verglichen. Diese vor¬ gegebenen Label sind im Motorsteuergerät als Kontrollwerte für eine zugelassene Modifikation gespeichert. Bei einer zu- gelassenen Modifikation durch eine entsprechend konfigurierte Toolsoftware ist der aus der Speicherstelle ausgelesene Wert identisch mit einem vorgegebenen Label. Bei einer nicht zugelassenen Modifikation entspricht der ausgelesene Wert dem im Original-Softwarestand an der Speicherstelle für das Label eingetragenen Initialwert oder einem nicht definierten Wert. Auf diese Weise kann festgestellt werden, ob die in ein Mo¬ torsteuergerät eingebrachte Steuergerätesoftware mit einer zugelassenen Toolsoftware-Konfiguration modifiziert wurde.
Die Steuergerätesoftware ist so konfiguriert, dass nach Fest¬ stellung einer zugelassenen Modifikation der Steuergerätesoftware keine Sperrung des Motorbetriebes erfolgt, jedoch bei einer nicht zugelassenen Modifikation der Motortrieb gesperrt wird. Die Unterbindung des Motorbetriebes im Falle von erkannten nicht zugelassenen Modifikationen der Steuergerätesoftware kann konfigurierbar (Aktivierung/Deaktivierung) ges- taltet werden. Diese Funktion gewährleistet auf vorteilhafte Weise somit einen Schutz vor ungewollten Veränderungen der Steuergerätesoftware.
Das der Erfindung zugrunde liegende Verfahren hat den Vor- teil, dass es möglich ist, mit Werkzeugen zur Modifikation von Softwareständen zu arbeiten und dabei trotzdem den Überblick über eventuelle Modifikationen zu bekommen. Dabei müssen keine Checksummenprüfungen deaktiviert werden, sodass eine Konsistenzprüfung erhalten bleibt, und auch keine Tools zum Neuberechnen und zum Update von Checksummeneinträgen weiter gegeben werden. Zudem ist es möglich, die Steuergerätesoftware so zu konfigurieren, dass Modifikationen überhaupt nicht mehr zugelassen werden.
Hinzu kommt, dass die Checksummenprüfung nicht deaktiviert werden muss und daher eine Modifikation der Steuergerätesoft¬ ware immer erkannt wird.
Die dargestellten Möglichkeiten zur Konfiguration einer Steu- ergerätesoftware stellen auch einen großen Vorteil im Hinblick auf den Know-How-Schutz und die Beurteilung von Gewährleistungsansprüchen dar, da ein Steuergerätesoftwarestand trotz ermöglichter Modifikationen geschützt werden kann.
Zur unmittelbaren Anzeige einer vorhandenen Modifikation kann das Motorsteuergerät so ausgestattet sein, dass die optische Anzeige einer festgestellten Modifikation über einen Blinkcode einer Diagnoselampe erfolgt. Eine solche optische Anzeige kann sowohl unmittelbar auf einem Display in einem Fahrzeug integriert sein oder Bestandteil eines Mess- und Diagnosesys¬ tems oder eines Testers sein. Für den Benutzer eines Steuergerätes ist dadurch direkt erkennbar, ob sich in dem Mo- torsteuergerät ein Original-Softwarestand oder ein modifi¬ zierter Stand befindet.
In einer weiteren vorteilhaften Ausgestaltung gewährleistet das Verfahren, dass die in dem Label enthaltenen Informatio¬ nen einem Mess- und Kalibrationssystem oder einem verfügbaren Tester für eine weitere Anzeige und Analyse zur Verfügung ge¬ stellt werden. Das bedeutet, dass nach der Erkennung einer Modifikation der aktuell geladenen Steuergerätesoftware der ausgelesene Wert des Labels über eine Schnittstelle an ein
Mess- und Kalibrationssystem oder Tester übertragen wird. Im Mess- und Kalibrationssystem oder Tester werden die ausgelesenen Daten angezeigt.
Bei dem Verfahren ist bei einer zugelassenen Modifikation durch eine definierte Toolsoftware das implementierte Label derart ausgebildet, dass es mindestens eine der folgenden In¬ formationen enthält:
- liegt eine zugelassene oder eine nicht zugelassene Modifi- kation vor; und/oder
- welcher Benutzer der Toolsoftware hat die Modifikation der Steuergerätesoftware ausgeführt; und/oder
- welche Funktionalitäten der Steuergerätesoftware wurden mo¬ difiziert .
Wie oben beschrieben, ist die Erkennung einer nicht zugelassenen Modifikation dadurch gegeben, dass sich in diesem Fall an der vorgesehenen Speicherstelle für das Label noch der bei der Generierung des Original-Softwarestandes eingetragene I- nitialwert befindet, oder dass an dieser Speicherstelle ein nicht definierter Wert eingetragen ist.
Jede für eine zugelassene Modifikation an einen Benutzer ausgelieferte Toolsoftware-Konfiguration ist genau definiert und realisiert bei der Modifikation einer Steuergerätesoftware die Implementierung eines Labels, welches auch die Informati¬ on darüber enthält, welcher Benutzer die Toolsoftware verwen- det hat. Ebenfalls sind in dem implementierten Label auch die Informationen darüber enthalten, welche Funktionalitäten der Steuergerätesoftware durch die verwendete Toolsoftware in Ü- bereinstimmung mit den spezifischen Anforderungen des Benut- zers modifiziert wurden.
Zum Zwecke der genaueren Eingrenzung einer Modifikation kann eine Aufteilung der Steuergerätesoftware in eine Mehrzahl von Bereichen realisiert werden, wobei dabei jeweils eine Check- summe pro Bereich berechnet wird. Dazu wird der Original- Softwarestand so konfiguriert, dass mehrere Software-Bereiche entstehen. Für jeden dieser Bereiche wird eine separate Checksumme gebildet. Diese separaten Checksummen werden je¬ weils in dem betreffenden Softwarebereich an einer vorgesehe- nen Speicherstelle eingetragen. Ebenso wird für jeden Bereich ein Initialwert generiert, der an der für die Implementierung eines Labels vorgesehenen Speichestelle eingetragen wird. Der oben bereits beschriebene Überprüfungsmechanismus für die Er¬ kennung und Anzeige einer Modifikation der Steuergerätesoft- wäre wird bei der Existenz von mehreren Softwarebereichen separat für jeden dieser Softwarebereiche durchgeführt.
Ebenfalls gehört zum Umfang der Erfindung ein Computerpro¬ gramm (Toolsoftware) zur Modifikation einer Steuergerätesoft- wäre in einem Motorsteuergerät. Die Toolsoftware schreibt ein Label an eine vordefinierte Speicherstelle der Steuergeräte¬ software, nachdem die Steuergerätesoftware durch die Tool¬ software modifiziert wurde, wobei das Label die Art der Modi¬ fikation angibt, d. h. das Label enthält Informationen dar- über, ob eine zugelassen oder eine nicht zugelassene Modifi¬ kation vorliegt. Die Toolsoftware kann auch verschlüsselte Informationen darüber enthalten, wo sich die Speicherstelle für das Label befindet und welchen Inhalt das Label hat. Die¬ se Verschlüsselung hat den Vorteil, dass für den Benutzer der Toolsoftware nicht offensichtlich ist, wo und mit welchem In¬ halt das Label geschrieben wird. Zur Erfindung gehört ein Motorsteuergerät. In dieses ist eine gegenüber einem Original-Softwarestand eventuell modifizierte Steuergerätesoftware geladen. Das Motorsteuergerät ist mit Mitteln zum Berechnen der Checksumme einer im Motorsteuerge- rät geladenen Steuergerätesoftware ausgestattet. Diese Check¬ summenberechnung wird beim Startvorgang ausgeführt. Ebenfalls ist das Motorsteuergerät mit Mitteln versehen, welche die Durchführung eines Vergleichs zwischen der berechneten Checksumme und einer in einer vorgegebenen Speicherstelle der Steuergerätesoftware eingetragen Checksumme für den Original- Softwarestand gewährleisten. Weiterhin sind im Motorsteuerge¬ rät Mittel zum Entscheiden vorhanden, dass bei Übereinstimmung der Checksummen die geladene Steuergerätesoftware nicht modifiziert ist, und dass bei Nicht-Übereinstimmung der Checksummen die geladene Steuergerätesoftware modifiziert ist .
Das Motorsteuergerät besitzt auch Mittel zum Auslesen eines durch eine Toolsoftware für eine zugelassenen Modifikation der Steuergerätesoftware geschriebenen Labels. Das Label gibt die Art der Modifikation an. Dabei sind die Mittel zum Ausle¬ sen derart ausgebildet, dass sie das Label nur bei einer festgestellten Modifikation auslesen.
Weitere Einzelheiten und Merkmale der Erfindung ergeben sich aus der nachfolgenden Beschreibung von bevorzugten Ausführungsbeispielen in Verbindung mit den Unteransprüchen. Hierbei können die jeweiligen Merkmale für sich alleine oder zu mehreren in Kombination miteinander verwirklicht sein. Die
Erfindung ist nicht auf die Ausführungsbeispiele beschränkt.
Die Ausführungsbeispiele sind in den Figuren schematisch dar¬ gestellt. Gleiche Bezugsziffern in den einzelnen Figuren be- zeichnen dabei gleiche oder funktionsgleiche bzw. hinsicht¬ lich ihrer Funktionen einander entsprechende Elemente. Im Einzelnen zeigt: Fig. 1 ein Prinzipschema eines Motorsteuergerätes;
Fig. 2 ein Prinzipschema des Verfahrens zur Erkennung und Anzeige einer Modifikation an einem Softwarestand einer MotorSteuergerätesoftware; Fig. 3 ein Prinzipschema der Kennzeichnung des Software¬ standes einer Motorsteuergerätesoftware;
Fig. 3A ein Prinzipschema der Kennzeichnung des Original- Softwarestandes einer Motorsteuergerätesoftware;
Fig. 3B ein Prinzipschema der Kennzeichnung eines modifi- zierten Softwarestandes einer Motorsteuergeräte¬ software;
Fig. 4 ein Prinzipschema des Auslesens der Informationen aus einem Label; und
Fig. 5 ein Prinzipschema der Kennzeichnung des Software- Standes einer Motorsteuergerätesoftware bei Auftei¬ lung der Steuergerätesoftware in mehrere Bereiche.
In Fig. 1 ist das Prinzipschema einer Motorsteuerung 100 dar- gestellt. Bei der Motorsteuerung 100 erfolgen der Signalfluss 102 von den verschiedenen Sensoren und Sollwertgebern (z. B. Fahrpedaleinstellung, Drosselklappenstellung, Luftmasse, Batteriespannung, Ansauglufttemperatur, Motortemperatur, Klopfintensität, Lambda-Sonden) und der Signalfluss 104 (z. B. Kurbelwellendrehzahl, Nockenwellenstellung, Getriebestufe,
Geschwindigkeit) über die Input/Output-Ports 106 und 108 und weiter von den Ports über die Verbindungen 110 und 112 zum MikroController 114 und seinen Komponenten. Im OTP-Block (O- ne-Time Programmable-Block) 116 ist das Programm gespeichert, welches der MikroController 114 ausführen soll. Der Daten- fluss zwischen MikroController 114 und OTP-Block 116 erfolgt über die Verbindung 118. Über die Verbindung 120 erfolgt der Datentransfer zwischen dem MikroController 114 und dem CAN- Bus 122. Der CAN-Bus 122 ermöglicht es, alle Geräte über ein einziges Kabel miteinander zu vernetzen. Der Datentransfer zwischen dem MikroController 114 und einem Diagnosesystem 124 erfolgt über die Verbindung 126. Der MikroController 114 mit seinen Komponenten realisiert seine Funktionen auf der Grundlage des im OTP-Block 116 ge¬ speicherten Programms. Nach der Verarbeitung der Signale von den Sensoren und Sollwertgebern 102, 104 im MikroController 114 erfolgt der weitere Signalfluss vom MikroController 114 über die Verbindungen 128, 130, 132, 134 und über die In- put/Output-Ports 136, 138, 140, 142 zu den verschieden Akto¬ ren 144 (z. B. Zündspulen und Zündkerzen), 146 (z. B. Dros- selklappensteller) , 148 (z. B. Einspritzventile) und 150 (z. B. Hauptrelais, Motordrehzahlmesser, Kraftstoffpumpenrelais, Heizung Lambda-Sonde, Nockenwellensteuerung, Tankentlüftung, Saugrohrumschaltung, Sekundärluft, Abgasrückführung) .
Auf Grund einer steigenden Anzahl ihrer zahlreichen Ein- und Ausgangsgrößen sind diese Regelungen in Kraftfahrzeugen sehr komplex, sodass zur Realisierung dieser Aufgaben moderne Regelungssysteme auf der Basis von MikroControllern 114 einge¬ setzt werden.
Da in modernen Fahrzeugen immer zahlreichere unterschiedliche Sensoren zum Einsatz kommen, deren Messdaten zeitnah berücksichtigt werden müssen, ist die Anzahl der Input-/Output- Ports 106, 108, 136, 138, 140, 142 einer Motorsteuerung 100 ständig vergrößert worden. Daher werden zunehmend Mikrocont- roller 114 mit sehr hoher Rechenleistung eingesetzt, wobei die Funktionalitäten der Steuergerätesoftware modifizierbar sind, damit sie in effektiver Weise an die spezifischen Bedürfnisse der verschiedenen Benutzer angepasst werden können.
In Fig. 2 ist das Prinzipschema des Verfahrens zur Erkennung und Anzeige einer Modifikation an einem Softwarestand einer Motorsteuergerätesoftware dargestellt. Das Motorsteuergerät 100 wird in Schritt 202 gestartet. Beim Startvorgang 202 wird in Schritt 204 die Checksumme der aktuell im Motorsteuergerät geladenen Steuergerätesoftware berechnet. Die berechnete Checksumme der aktuell im Motorsteuergerät geladenen Steuer- gerätesoftware wird in Schritt 206 mit der in den Original- Softwarestand eingetragenen Checksumme verglichen. In Schritt 208 wird entschieden, ob die verglichenen Checksummen übereinstimmen oder nicht, d. h. es erfolgt eine Ja-Nein Verzwei- gung des Verfahrensablaufes.
Sind die in Schritt 204 berechnete Checksumme und die in den Original-Softwarestand eingetragene Checksumme identisch, dann wird in Schritt 210 die aktuell geladene Steuergeräte- Software als nicht modifiziert eingestuft. Infolgedessen wird in Schritt 212 der Motorbetrieb zugelassen.
Ist die berechnete Checksumme nicht mit der in den Original- Softwarestand eingetragenen Checksumme identisch, dann wird in Schritt 214 eine Modifikation der aktuell geladenen Steuergerätesoftware erkannt. Diese erkannte Modifikation kann über eine Diagnoselampe 216 optisch signalisiert werden.
Nach der Erkennung der Modifikation erfolgt in Schritt 218 das Auslesens der Speicherstelle für das Label. In Schritt 220 wird der ausgelesene Wert der für das Label definierten Speicherstelle mit vorgegebenen Werten für charakteristische Label verglichen, welche bei der Modifikation durch eine Toolsoftware geschrieben werden.
In Schritt 222 wird entschieden, ob der Werte der ausgelese¬ nen Speicherstelle für das Label mit den vordefinierten Werten für ein charakteristisches Label übereinstimmen oder nicht, d. h. es erfolgt eine weitere Ja-Nein Verzweigung des Verfahrensablaufes.
Stimmt der ausgelesene Wert der Speicherstelle mit den Anfor¬ derungen an die charakteristischen Merkmale eines Labels ü- berein, dann wird in Schritt 224 die Modifikation als zuge- lassen eingestuft und in Schritt 226 wird der Motorbetrieb zugelassen. Ist der aus der Speicherstelle für das Label ausgelesene Wert identisch mit dem in den Original-Softwarestand eingetragenen Initialwert oder enthält die Speicherstelle einen nicht defi¬ nierten Wert, dann wird in Schritt 228 die Modifikation als nicht zugelassen eingestuft und in Schritt 230 wird in Abhän¬ gigkeit von der Konfiguration der Original- Steuergerätesoftware beispielsweise der Motorbetrieb nicht zugelassen.
Die im Label enthaltenen Informationen können einem Mess- und Kalibrationssystem/Tester für eine weitere Auswertung und A- nalyse zur Verfügung gestellt werden.
Fig. 3 zeigt ein Prinzipschema der Kennzeichnung eines Soft- warestandes vor und nach einer Modifikation.
In Fig. 3A ist eine Original-Steuergerätesoftware 302 mit ei¬ ner Kennzeichnung 304 versehen. Auf dem Detailausschnitt 306 dieser Kennzeichnung 304 sind als erstes Kennzeichnungsmerk- mal die eingetragene Original-Checksumme 308 und als zweites Kennzeichnungsmerkmal der an der Speicherstelle für das Label eingetragene Initialwert 310 dargestellt.
In Fig. 3B wurde eine modifizierte Steuergerätesoftware 312 mit einer modifizierten Kennzeichnung 314 versehen. Der Detailausschnitt 316 dieser modifizierten Kennzeichnung 314 zeigt, dass die modifizierte Steuergerätesoftware als erstes Kennzeichnungsmerkmal die eingetragene Original-Checksumme 308 der Original-Software und als zweites Kennzeichnungsmerk- mal das durch die Toolsoftware eingetragene Label 318 auf¬ weist .
Fig. 4 zeigt ein vereinfachtes Prinzipschema für die Anzeige des Softwarestandes einer Steuergerätesoftware. Wird bei¬ spielsweise bei der Checksummenprüfung im Motorsteuergerät eine Modifikation der Steuergerätesoftware erkannt, d. h. die Checksumme der nicht modifizierten Original- Steuergerätesoftware und die Checksumme der aktuell im Steu- ergerät geladenen Software sind nicht identisch. Diese er¬ kannte Modifikation wird über eine Diagnoselampe 216 optisch angezeigt. Einem angeschlossenen Mess- und Kalibrations- system/Tester 404 werden die aus dem Speicherplatz für das Label ausgelesenen Informationen zur Verfügung gestellt.
Im vorliegenden Beispiel hat das ausgelesene Label 406 einen durch eine Toolsoftware eingetragenen charakteristischen Wert und enthält die Information, dass die erkannte Modifikation zugelassen ist. Die Anzeige 408 über die Art der festgestell¬ ten Information signalisiert, dass eine zugelassene Modifika¬ tion vorliegt. Diese angezeigte Information 408 über eine zu¬ gelassene Modifikation begründet die Anzeige 410 über eine Zulassung des Motorbetriebes. In Fig. 5 wird das Prinzip der Kennzeichnung des Softwarestandes einer Motorsteuergerätesoftware bei einer Aufteilung der Software in mehrere Bereiche dargestellt. Die Motorsteu¬ ergerätesoftware 502 ist mit dem Ziel einer besseren Eingrenzung einer Modifikation beispielsweise in drei Softwareberei- che 504, 506 und 508 geteilt. Jeder dieser Softwarebereiche
504, 506 und 508 ist mit einer Kennzeichnung 510, 512 und 514 versehen. Die Kennzeichnung jedes Bereiches besteht im Detail 511, 513 und 515 aus einer eigenen Original-Checksumme 516, 518 und 520 und dem durch die Toolsoftware bei einer Modifi- kation eingetragenen Label 522, 524, 526. Das bedeutet, dass pro Softwarebereich 504, 506 und 508 eine Checksumme exis¬ tiert.
Das der Erfindung zugrunde liegende Verfahren zur Erkennung und Anzeige von Modifikationen der Steuergerätesoftware er¬ folgt in dem dargestellten Beispielfall für jeden der Softwarebereiche 504, 506 und 508.

Claims

Patentansprüche
1. Verfahren zur Erkennung einer Modifikation an einem Soft¬ warestand für eine Steuergerätesoftware in einem Steuergerät, insbesondere in einem Motorsteuergerät (100), mit folgenden Schritten: a) für einen unmodifizierten Softwarestand (Original- Softwarestand) (302) der Steuergerätesoftware wird eine Checksumme berechnet; al) die berechnete Checksumme wird in den Original- Softwarestand (302) an einer vordefinierten Speicherstelle (308) eingetragen; b) für die Eintragung eines Labels wird im Original- Softwarestand eine vordefinierte Speicherstelle (318) vorge- sehen, wobei das Label bei der Modifikation der Steuergeräte¬ software durch eine Toolsoftware geschrieben wird und die Art der Modifikation angibt; bl) an der für das Label vorgesehenen Speicherstelle (318) wird im Original-Softwarestand (302) ein Initialwert (310) vorgesehen; c) eine gegenüber dem Original-Software eventuell modifizier¬ te Steuergerätesoftware (312) wird zur Verfügung gestellt und in das Motorsteuergerät (100) geladen; d) das Motorsteuergerät (100) wird gestartet; e) beim Startvorgang des Motorsteuergerätes (100) wird eine Checksummenprüfung der im Motorsteuergerät (100) aktuell ge¬ ladenen Steuergerätesoftware (312) mit folgenden Schritten ausgeführt : el) die Checksumme der aktuell im Motorsteuergerät (100) ge- ladenen Steuergerätesoftware (312) wird berechnet; e2) die berechnete Checksumme wird mit der Checksumme (308) des Original-Softwarestands (302) verglichen; e3) entspricht die berechnete Checksumme der Checksumme (308) des Original-Softwarestands (302), dann ist die aktuell gela- dene Steuergerätesoftware (312) nicht modifiziert; e4) entspricht die berechnete Checksumme nicht der Checksumme (308) des Original-Softwarestands (302), dann wird eine Modi- fikation der aktuell geladenen Steuergerätesoftware (312) ge¬ genüber dem Original-Softwarestand festgestellt; und f) nach dem Feststellen einer Modifikation wird das Label (318) ausgelesen, um die Art der Modifikation zu bestimmen.
2. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass nach dem Erkennen einer Modifikation durch die Checksum¬ menprüfung eine Prüfung der Zulässigkeit der festgestellten Modifikation mit folgenden Schritten erfolgt: a) die Speicherstelle für das Label (318) wird aus der aktu¬ ell geladenen Steuergerätesoftware (312) ausgelesen; b) der Wert der ausgelesenen Speicherstelle (318) wird mit vorgegebenen Labels verglichen, welche als Kontrollwerte für die bei der Modifikation der Steuergerätesoftware durch eine zugelassene Toolsoftware zu schreibenden Label im Steuergerät gespeichert sind; bl) wobei bei einer zugelassenen Modifikation der ausgelesene Wert (318) einem vorgegebenen Label entspricht; b2) wobei bei einer nicht zugelassenen Modifikation der aus¬ gelesene Wert dem im Original-Softwarestand (302) an der Speicherstelle für das Label eingetragenen Initialwert (310) oder einem nicht definierten Wert entspricht.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach Feststellung einer Modifikation der Steuergeräte¬ software : al) bei einer zugelassenen Modifikation keine Sperrung des Motorbetriebes erfolgt; und a2) bei einer nicht zugelassenen Modifikation der Motortrieb gesperrt wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Anzeige einer festgestellten Modifikation über einen Blinkcode einer Diagnoselampe (216) erfolgt.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die in dem Label (318) enthaltenen Informationen einem Mess- und Kalibrationssystem oder Tester (404) für eine weitere Anzeige und Analyse zur Verfügung gestellt werden.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Label (318) derart ausgebildet wird, dass es mindes¬ tens eine der folgenden Informationen enthält: al) ob eine zugelassene oder eine nicht zugelassene Modifika¬ tion vorliegt; und/oder a2) welcher Benutzer der Toolsoftware die Modifikation der Steuergerätesoftware (312) ausgeführt hat; und/oder a3) welche Funktionalitäten der Steuergerätesoftware (312) modifiziert wurden.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur genaueren Eingrenzung einer Modifikation eine Aufteilung der Steuergerätesoftware 502) in eine Mehrzahl von Bereichen (504, 506, 508) realisiert werden kann, wobei dabei jeweils eine Checksumme (516, 518, 520) pro Bereich berechnet wird.
8. Computerprogramm (Toolsoftware) für die Modifikation einer Steuergerätesoftware in einem Motorsteuergerät dadurch gekennzeichnet, dass die Toolsoftware ein Label (318) an eine vordefinierte
Speicherstelle der Steuergerätesoftware schreibt, nachdem die
Steuergerätesoftware (312) durch die Toolsoftware modifiziert wurde, wobei das Label (318) die Art der Modifikation angibt.
9. Toolsoftware nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Toolsoftware verschlüsselte Informationen über die Speicherstelle und den Inhalt des Labels (318) enthält.
10. Motorsteuergerät (100), a) wobei in das Motorsteuergerät (100) eine gegenüber einem Original-Softwarestand (302) eventuell modifizierte Steuerge¬ rätesoftware (312) geladen ist; b) mit Mitteln zum Berechnen einer Checksumme der im Motorsteuergerät (100) geladenen Steuergerätesoftware (312) beim Startvorgang; c) mit Mitteln zum Vergleichen der berechneten Checksumme mit einer in einer vorgegebenen Speicherstelle (308) der Steuergerätesoftware eingetragen Checksumme; d) mit Mitteln zum Entscheiden, dass bei Übereinstimmung der Checksummen die geladene Steuergerätesoftware (312) nicht mo¬ difiziert ist, und dass bei Nicht-Übereinstimmung der Checksummen die geladene Steuergerätesoftware (312) modifiziert ist; e) mit Mitteln zum Auslesen eines durch eine Toolsoftware zum Modifizieren der Steuergerätesoftware geschriebenen Labels
(318), wobei das Label die Art der Modifikation angibt; und f) wobei die Mittel zum Auslesen derart ausgebildet sind, dass sie das Label nur bei einer festgestellten Modifikation auslesen.
PCT/EP2005/056109 2004-12-15 2005-11-21 Erkennung und anzeige von modifikationen an softwareständen für motorsteuergerätesoftware WO2006063919A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05825295A EP1825362A2 (de) 2004-12-15 2005-11-21 Erkennung und anzeige von modifikationen an softwareständen für motorsteuergerätesoftware

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004060333A DE102004060333A1 (de) 2004-12-15 2004-12-15 Erkennung und Anzeige von Modifikationen an Softwareständen für Motorsteuergerätesoftware
DE102004060333.2 2004-12-15

Publications (2)

Publication Number Publication Date
WO2006063919A2 true WO2006063919A2 (de) 2006-06-22
WO2006063919A3 WO2006063919A3 (de) 2007-05-24

Family

ID=36463427

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/056109 WO2006063919A2 (de) 2004-12-15 2005-11-21 Erkennung und anzeige von modifikationen an softwareständen für motorsteuergerätesoftware

Country Status (3)

Country Link
EP (1) EP1825362A2 (de)
DE (1) DE102004060333A1 (de)
WO (1) WO2006063919A2 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1918839A1 (de) * 2006-11-03 2008-05-07 Siemens Aktiengesellschaft Modifizieren eines Softwarestands einer Steuergerätesoftware für ein Steuergerät und Erkennen einer solchen Modifikation
EP2085881A1 (de) * 2008-01-23 2009-08-05 Denso Corporation Elektronische Steuereinheit zur Verwendung in einem Fahrzeug
WO2011025416A1 (en) * 2009-08-28 2011-03-03 Volvo Lastvagnar Ab Tampering detection method
WO2012069271A1 (de) 2010-11-22 2012-05-31 Beckhoff Automation Gmbh Prüfverfahren für eine integrität eines quelltextes
EP3499324A1 (de) * 2017-12-12 2019-06-19 Sick AG Verfahren zur modularen verifikation einer konfiguration eines geräts

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1860551A1 (de) 2006-05-22 2007-11-28 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Erfassung einer Modifikation eines Softwarestandes
DE102006059107A1 (de) * 2006-12-08 2008-06-12 Siemens Ag Verfahren zum softwaremäßigen Aktualisieren einer elektronischen Einrichtung, insbesondere des Auslösers von Niederspannungs-Leistungsschaltern

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884210A (en) * 1996-08-27 1999-03-16 Caterpillar Inc. Programmable engine parameter verification apparatus and method of operating same
EP1139217A2 (de) * 2000-03-14 2001-10-04 DaimlerChrysler AG Verfahren zur Abspeicherung von Daten
US20030055552A1 (en) * 2001-09-14 2003-03-20 Mark Akins Tamper detection for vehicle controller
US20030188303A1 (en) * 2001-03-30 2003-10-02 Barman Roderick A. Method and apparatus for reprogramming engine controllers

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0511737B1 (de) * 1991-03-29 1996-09-18 Cummins Engine Company, Inc. Verfahren und Vorrichtung zur Erzeugung von Kalibrierinformationen für ein elektronisches Motorsteuermodul
JP3867530B2 (ja) * 2001-08-14 2007-01-10 日産自動車株式会社 デジタルデータの改竄検出プログラム，改竄検出方法並びに改竄検出装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884210A (en) * 1996-08-27 1999-03-16 Caterpillar Inc. Programmable engine parameter verification apparatus and method of operating same
EP1139217A2 (de) * 2000-03-14 2001-10-04 DaimlerChrysler AG Verfahren zur Abspeicherung von Daten
US20030188303A1 (en) * 2001-03-30 2003-10-02 Barman Roderick A. Method and apparatus for reprogramming engine controllers
US20030055552A1 (en) * 2001-09-14 2003-03-20 Mark Akins Tamper detection for vehicle controller

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1918839A1 (de) * 2006-11-03 2008-05-07 Siemens Aktiengesellschaft Modifizieren eines Softwarestands einer Steuergerätesoftware für ein Steuergerät und Erkennen einer solchen Modifikation
EP2085881A1 (de) * 2008-01-23 2009-08-05 Denso Corporation Elektronische Steuereinheit zur Verwendung in einem Fahrzeug
US8185253B2 (en) 2008-01-23 2012-05-22 Denso Corporation Electronic control unit for use in a vehicle
US8346406B2 (en) 2008-01-23 2013-01-01 Denso Corporation Electronic control unit for use in a vehicle
WO2011025416A1 (en) * 2009-08-28 2011-03-03 Volvo Lastvagnar Ab Tampering detection method
US9031735B2 (en) 2009-08-28 2015-05-12 Volvo Lastvagnar Ab Tampering detection method
RU2622777C2 (ru) * 2009-08-28 2017-06-20 Вольво Ластвагнар Аб Способ обнаружения самовольного нарушения настройки
WO2012069271A1 (de) 2010-11-22 2012-05-31 Beckhoff Automation Gmbh Prüfverfahren für eine integrität eines quelltextes
EP3499324A1 (de) * 2017-12-12 2019-06-19 Sick AG Verfahren zur modularen verifikation einer konfiguration eines geräts
US10803163B2 (en) 2017-12-12 2020-10-13 Sick Ag Method of modular verification of a configuration of a device

Also Published As

Publication number Publication date
WO2006063919A3 (de) 2007-05-24
EP1825362A2 (de) 2007-08-29
DE102004060333A1 (de) 2006-07-06

Similar Documents

Publication Publication Date Title
EP2146262B1 (de) Verfahren zum Bestimmen fehlerhafter Komponenten in einem System
DE3904891A1 (de) Fehlerdiagnosesystem fuer ein kraftfahrzeug
EP1290511B1 (de) Verfahren und vorrichtung zur steuerung und/oder zur bestimmung einer variante einer steuerung eines systems
WO2006063919A2 (de) Erkennung und anzeige von modifikationen an softwareständen für motorsteuergerätesoftware
DE3906318A1 (de) Diagnosesystem fuer ein kraftfahrzeug
DE3841425A1 (de) Diagnosesystem fuer ein kraftfahrzeug
Boot et al. Automated test of ECUs in a hardware-in-the-loop simulation environment
DE102009018152A1 (de) Elektronisches Steuerungssystem für ein Fahrzeug
DE102005044236B4 (de) Diagnosegerät
KR20130073921A (ko) 자동차 정비 장치
DE102005003916B4 (de) Überwachen der Funktionssicherheit einer Brennkraftmaschine
DE102009007171B4 (de) Diagnosesystem und -verfahren zum Erfassen eines unsachgemäßen Eingriffs in die Software oder die Kalibrierungen eines Fahrzeugs
WO2012031812A1 (de) Kraftfahrzeug-prüfgerät und verfahren zur identifikation von kraftfahrzeugen
DE102021125867A1 (de) Automatisierte detektion von fahrzeugdatenmanipulation und mechanischen ausfällen
DE3923937C5 (de) Diagnoseeinrichtung zum Überprüfen eines elektronischen Steuersystems einer Brennkraftmaschine
EP1081362B1 (de) Verfahren zum gesteuerten Betrieb einer Brennkraftmaschine nach Fehlerdiagnose
EP4167040A1 (de) Fehlermodell-editor und diagnosewerkzeug
DE102007063053A1 (de) Fehlercodespeicherverwaltungs-Architekturkonzept mit einem dedizierten Überwachungseinheitsmodul und einem Fehlerspeicherverwaltungs-Administratormodul für einen Hochleistungs-Dieselmotor
DE4213807C2 (de) Verfahren zur Erfassung von Betriebsgrößen einer Brennkraftmaschine
DE10352071A1 (de) Verfahren zur Erkennung von unberechtigten Komponententausch
EP3073438B1 (de) Verfahren zur ermittlung einer zugehörigkeit eines fahrzeugs zu einer abgasnorm sowie fahrzeug-computer
EP1918839A1 (de) Modifizieren eines Softwarestands einer Steuergerätesoftware für ein Steuergerät und Erkennen einer solchen Modifikation
DE10238094B4 (de) Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät
EP0798456B1 (de) Verfahren zum Betrieb einer Brennkraftmaschine mit Hilfe einer Steuereinrichtung
EP1860552A1 (de) Modifizieren eines Softwarestands einer Steuergerätesoftware für ein Steuergerät und Erkennen einer solchen Modifikation

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 DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN 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

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: 2005825295

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005825295

Country of ref document: EP