DE10256799B3 - Programming flash EPROMs in road vehicle control electronics with microprocessor involves checking controller against equipment description in generated programming data record transferred to it - Google Patents

Programming flash EPROMs in road vehicle control electronics with microprocessor involves checking controller against equipment description in generated programming data record transferred to it

Info

Publication number
DE10256799B3
DE10256799B3 DE2002156799 DE10256799A DE10256799B3 DE 10256799 B3 DE10256799 B3 DE 10256799B3 DE 2002156799 DE2002156799 DE 2002156799 DE 10256799 A DE10256799 A DE 10256799A DE 10256799 B3 DE10256799 B3 DE 10256799B3
Authority
DE
Germany
Prior art keywords
programming
control unit
data record
step
device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE2002156799
Other languages
German (de)
Inventor
Heinrich Hawig
Ulfert Dr. Ulken
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
WABCO GmbH
Original Assignee
WABCO 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 WABCO GmbH filed Critical WABCO GmbH
Priority to DE2002156799 priority Critical patent/DE10256799B3/en
Application granted granted Critical
Publication of DE10256799B3 publication Critical patent/DE10256799B3/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60RVEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572Secure firmware programming, e.g. of basic input output system [BIOS]

Abstract

The method involves producing at least one memory image (1) in a specified memory area, generating a descriptive data record (2) containing an equipment description of the controller (4), generating a programming data record (3), reading it into a diagnostic device (9), transferring to the controller, checking the controller against the equipment description and carrying out the programming of the memory region if the check is satisfactory.

Description

  • The invention relates to a programming method for one electronically delete and writable memory in an electronic control unit, in particular for the Use in road vehicles.
  • In road vehicles with electronic controlled or regulated devices, e.g. B. electronic Anti-lock brake control, it is common for the microprocessors programmed in the electronic control devices as a mask Train microprocessors.
  • Since the appearance of 1-chip microprocessors, the above have an integrated Flash E-PROM, it has also become possible this Flash-E-PROM area also as program memory for the microprocessor to use what is primarily predominant was used for prototype development. In addition to such prototypes it is also common in series Flash-E-PROM memory as program and data storage for the Microprocessor to use.
  • At the time of filing this patent application both mask-programmed and Flash-E-PROM-programmed Microprocessors for each a specific control unit provided, this control unit then having the latest software version is the basis.
  • However, software control programs are common continuously developed, and the developed in this context The next higher (younger) software version is then in of the next series used, d. H. this new software version is then in the program memories of these next series devices included.
  • This series-oriented procedure has as a result that new software versions not developed are adopted in control units from older series, be it mask-programmed or flash-E-PROM-programmed Embodiments.
  • In contrast, it is in software engineering, especially with commercial programs for general data processing, long common "update" existing programs, d. H. they in z. B. overwrite a PC with a new, updated program version, which is then executable is.
  • Such a simple overwrite an old memory state with a new, updated one Storage status is in in road vehicles control devices used without further measures for safety reasons possible: A certain program may only be in a very specific one, to this Program suitable control unit be loaded, what as such based on the newly updated memory state is not recognizable - e.g. B. would an ABS brake control program in a gearbox control unit firstly Naturally not work and could secondly there under certain circumstances even trigger faulty operations that endanger the vehicle.
  • In addition to the required matching Assignment of control unit and control program in basic Way may also be a z. B. old ABS control program, which for a certain type of vehicle was developed, not simply by one newly developed, current ABS control program that are not overwritten For this Vehicle type is released.
  • With newer generations of microprocessors is the use of Flash E-PROM technology e.g. B. in 1-chip microprocessors continuously cheaper and larger flash E-PROM memories are now available.
  • Inspired by this development there is an increasing interest the vehicle manufacturer, including a device purchased from a control manufacturer to be able to retrofit a new program version.
  • The publication "FLASHit-Manual from version 5.3; hse.electronic; 14.08.01 "describes the use of the PC program "FLASHit", a tool for Programming of user software in a target system with one external flash memory. After starting the program (FLASHit monitor) it is determined how the target system is configured, in particular is automatically the FLASH type used is recognized, and with this knowledge the Implementation of the Programming possible (Get FLASH type data from database (PC)). Then the Programming by downloading an Intel-Hex-Filer into the target system, that with the PC a serial interface is connected. The tool can thus be used for different Target systems with different configurations of FLASH types.
  • From the DE 101 43 030 A1 A method for storing and / or updating control unit data, such as in particular a program code for sequence control of at least one control unit and / or for map control of at least one control unit of a motor vehicle, is known, in which this data is stored in a memory assigned to the control unit, such as in particular a semiconductor memory , get saved. To shorten the period of time, this document suggests reading the control unit data from the data carrier and then storing it in the memory assigned to the control unit.
  • From the US 6,181,992 B1 discloses an apparatus and method for diagnosing isolated problems from and detecting operating conditions in an automobile. A manual control unit and a central station are provided, which can work both as individual devices and are also suitable for carrying out certain functions together. Such functions are the registration and display of data in real time, the display of already recorded Data at a later point in time, the diagnosis of error states and operating parameters of control units installed in the vehicle, and the reprogramming of such control units. It is also possible to call up the service manual online.
  • From the EP 0 836 739 B1 is a method for updating an electronic erasable memory (flash EPROM memory, (there ( 4 )) of an electronic device (there ( 5 )) via a personal computer connected to the electronic device (there ( 1 )) known. In the storage area (there ( 2 )) of the personal computer is, among other things, the reprogramming code (there ( 3 )) loaded for the flash EPROM memory; there is also a memory with selectable access (there RAM memory ( 6 )) provided in which a sequence program is stored. After the communication between the personal computer and the electrical device has been established, the sequence program is stored in a memory provided in the electronic device with random access (there RAM memory ( 7 )) loaded and activated there after checking the correct transmission. Using the activated sequence program, the reprogramming code is loaded into the flash EPROM memory of the electronic device and the update process is completed by a RESET of the personal computer. In this document there are no test measures to identify the electronic device.
  • For programming you can also use a diagnostic device be used; such electronic diagnostic devices who the in car workshops for many types used by electrical / electronic maintenance work. To do this the connecting cable of the diagnostic device plugged into a diagnostic connector on the vehicle, and then the diagnostic tool according to the client / server principle communicate with an electronic control unit housed in the vehicle, being the diagnostic device the client and the control unit represents the server and communication between the two after one defined diagnostic protocol, e.g. B. the KWP2000 protocol (keyword protocol 2000 according to ISO 14230) becomes.
  • Such a conventional diagnostic device also offers the possibility, Data or programs in a control unit using a download process transferred to, so that under Use of the diagnostic device the reprogramming of a control unit equipped with a Flash-E-PROM is basically possible.
  • For example, between the diagnostic device and the control unit a dialogue takes place in which A key code based on a random number from the diagnostic device generated and from both devices checked for logical consistency. If they match Logical consistency becomes the download process (i.e. the transfer into the control unit and programming the Flash-E-PROM) opened by the diagnostic device and processed in a further dialog with the control unit.
  • With this procedure the access authorization for the Download as part of the explained Key code dialog carried out. With this Dialogue is only checked, whether diagnostic device and control unit match in their logical structure, just like the vehicle manufacturer in the diagnostic device for the ECUs provided in "his" vehicles Has.
  • The subsequent download process then takes place e.g. B. with the "memory image.hex" explained below ( 1 ), which contains no information about the control unit itself.
  • "Downloading" a new program after the above described method covers one on the content of the reprogramming code related aptitude test of the control unit for the new Program in no way, which is why there is no security per se across from offers incorrect programming.
  • By inserting further steps in the download process, e.g. B. an operator using the nameplate of the control unit or also the diagnostic device with the help of inquiries to the control unit further information such as e.g. the control unit part number receive. Based on this information, an operator or the Diagnostic device itself check, whether the control unit that for the programming is provided. In principle, one can Qualifying Examination by the operator or the diagnostic device.
  • On the one hand, this procedure has the disadvantage that the Qualifying Examination not necessarily must be done. On the other hand, the exam, e.g. B. using the control unit part number, only by comparing it with information that is not more immediate Are part of the reprogramming code. Resulting from this various sources of error, e.g. due to incorrect operation or incorrect specifications for the diagnostic device. These disadvantages impair process reliability in terms of incorrect programming, especially for a wide range of applications in car workshops.
  • The invention is therefore the object underlying a safe method of re-programming one, provided in an electronic control unit, electronically erasable and writable memory.
  • This object is achieved in the claim 1 specified invention solved; Developments and advantageous embodiments of the invention are in the subclaims specified.
  • The invention separates from the function of the diagnostic device according to the prior art, the is used there as the central test entity: in the method according to the invention, the diagnostic device of the motor vehicle workshop is also used to load the programming data in the control device, and the key code dialogue between the diagnostic device and control device explained above usually takes place, however, the decisive test on the admissibility of the control unit to the code of the new program by the control unit itself on the basis of the data transmitted to the control unit. The test actions of the diagnostic device itself can additionally take place, but as such are of little importance, since the diagnostic device is only used for data transmission in the invention.
  • The method according to the invention has the advantage that all safety-relevant tests from Program of the control unit be carried out by yourself so that mistakes be practically excluded.
  • The invention further has the advantage that they are in Field of that in auto repair shops existing maintenance personnel can be carried out, which is usually no over has special programming knowledge.
  • Another advantage of the invention is that a Manipulation of programming data safely detected by the control unit becomes.
  • A further development of the invention has the advantage that the Data for programming in the field are available as encrypted data, and that thereby the for the Know-how protection of the control unit manufacturer very important confidentiality of the object code in the distribution is preserved.
  • The invention is illustrated below of an embodiment, that is shown in the drawing, explained in more detail.
  • Show it:
  • 1 The sequence of the procedure for the safe reprogramming of control units;
  • 2 the files used in the reprogramming process, the memory image file, the description file for the control device, which is defined by a hardware number, and the programming data record file;
  • 3 the description file in extended embodiments, namely
  • 3a a description file with several hardware numbers,
  • 3b a description file in which a hardware number is restricted by a range of serial numbers,
  • 3c a description file in which a hardware number is restricted by a software number,
  • 3d a description file in which a hardware number is restricted both by a range of serial numbers and by a software number,
  • 3e a description file with several hardware numbers, in which a hardware number is restricted by several ranges of serial numbers and by several software numbers,
  • 3f a description file with two memory image files and two hardware numbers, in each of which a memory image file is assigned to a hardware number;
  • 4 a block diagram of the control unit;
  • 5 a very simplified block diagram of the vehicle electronics.
  • The block diagram after 4 shows an electronic control unit ( 4 ) with a z. B. trained as flash E-PROM electronically erasable and writable memory ( 5 ), a random access memory ( 20 ), a microprocessor ( 21 ), a process interface ( 22 ) with inputs ( 23 ) for the from the control unit ( 4 ) used sensors and outputs ( 24 ) for connecting the control unit ( 4 ) operated actuators. There is also a CAN interface ( 25 ), which has a CAN connector ( 26 ) for the CAN-H and CAN-L cables to be twisted in a CAN vehicle bus (( 10 ) 5 ) and a Flash-E-PROM programming device ( 27 ) intended. All units mentioned are in a known manner with an address and data bus ( 28 ) connected.
  • As usual, the microprocessor ( 21 ) intended to control the other units; the system program for the microprocessor ( 21 ) is in a program area ( 29 ) of the Flash-E-PROM, which takes up the higher address memory area in the exemplary embodiment. The test and programming steps explained below, which the control unit ( 4 ) in connection with the reprogramming procedure, all are performed by the system program so that the system program area ( 29 ) is not changed during operation of the control unit.
  • Using the Flash-E-PROM programmer ( 27 ) memory cells in the Flash-E-PROM ( 5 ) are deleted and written so that the control unit ( 4 ) is able to change its own memory.
  • In the address area of the Flash-E-PROM memory ( 5 ) is an area of change ( 6 ) with the address range 0080 to 008F; this area is to be overwritten with a specific data pattern in order to explain the method.
  • The Flash E-PROM memory ( 5 ) is thus designed both as a program and as a data memory in the exemplary embodiment; in other embodiments it is of course also possible to provide a plurality of flash E-PROM memories, with some of the memories being used as data memories and others as program memories. The system The program can of course also be contained in a fixed, for example mask-programmed, program memory. Of course, it is also possible to integrate some or all of the units explained in a single chip, so that parts of the electrical logic or the entire electronic logic of the control unit ( 4 ) is contained in this chip.
  • The programming procedure for at least one area, namely the area of change ( 6 ) in the Flash E-PROM memory ( 5 ) is divided into seven steps; compare to this 1 ,
  • In a first step, a memory image ( 1 ) for the area of change ( 6 ) in the Flash E-PROM memory ( 5 ) generated. Suitable programs such as compilers, assemblers, linkers, HEX converters or similar programs can be used for this purpose. For the format of the memory image file, any format can be selected that is common for diagnostic devices, for example the Motorola-S-Records format.
  • In the exemplary embodiment, the format of the file "memory image.hex" ( 1 ) to 2 B based on the Intel Hex format, which is one of the common formats of diagnostic and programming devices. This file is in the table 2a illustrated memory image, in which hexadecimal contents FF to F0 are entered in the 16 memory cells of the hex addresses 0080 to 008F; for the sake of clarity, this test pattern has been chosen for the exemplary embodiment.
  • The file "memory image.hex" ( 1 ) consists of two records, a first data record with a load offset (this determines the start address) of 0080h and a second end of file record. In the Intel Hex format, the first five bytes of a record beginning with the record mark ":" are used 2 B are simply underlined to identify the record and represent the record header; a checksum is output as the last byte of a record, this is in 2 B underlined twice.
  • With this underline marking in 2 B it is very easy to understand that the data in the first record of "memory image.hex" ( 1 ) the 16 data bytes FFh to F0h in the 2a the address order shown.
  • Corresponding 1 description data is required for the further process, and these are generated in a second step. A description data record contains a device description of the electronic control devices that are approved for programming. In the embodiment 2c is the description record as a text file "description.txt" ( 2 ) built up; it contains a hardware product number that describes a specific device version of an electronic control unit; in the following it will be referred to simply as the hardware number. At least one hardware number is entered in a description data record, as in the exemplary embodiment according to 2c is shown.
  • The term "hardware number" is understood to mean any unique identifier of a specific device status, which, for example, as in the exemplary embodiment, is determined by a numerical character string. Alternatively, for example, an alphanumeric sequence of digits or a graphic name, for example in the form of a bar code, can be selected. In the case of a graphic designation, instead of the text format, as in the exemplary embodiment, a correspondingly different file type must be selected. That in the execution game after 2c The selected text format is advantageous due to its simplicity and clarity, since its content can be derived from the text without any further explanation, which can also be commented very clearly with plain text. The data file "description.txt" ( 2 ) to 2c contains for further processing the name of the input file with which the file is to be processed, namely the file "memory image.hex" ( 1 ) to 2 B , and, as explained below, the name of the output file that represents the result of the processing.
  • Corresponding 1 is carried out using a programming data converter ( 7 ) from the memory image, the file "memory image.hex" ( 1 ) and the description data record, the file "description.txt" ( 2 ) a programming data record in the form of the file "programmierdaten.hex ( 3 ) which is done in a third step.
  • The file "programmierdaten.hex" ( 3 ) is in 2f shown, the data content in 2d and the file format in 2e are explained.
  • For the file ( 3 ) of the programming data record 2f the Intel Hex format is again selected; the data is in this "parent format" 2d in a record structure in the format 2e embedded as "daughter format". The file ( 3 ) of the programming data record contains both the information required for programming from the file ( 1 ) of the memory image as well as the device description from the file ( 2 ) of the description data record.
  • According to the format explanations under 2e a first record of type 02h is created, which is based on the assumption of a ten-digit hardware number, so that there is no need to specify a record length. According to the content of the programming data record 2d the first byte is therefore the record type "02h" and bytes two to six represent a direct implementation of the ten-digit hardware number in the file ( 2 ) of the description data record. Then follows a record of the type "06h" with the start address in 32-bit form; the fixed length of 4 bytes means that a length can also be omitted for this record type. The bytes number 7 through 11 in 2d thus represent the start address record. After 2e this is followed by a data record of the type "07h", for which the length of the data record is, of course, as "10h" is indicated, followed by the 16 data bytes of the illustrated memory map test pattern. This record reproduces the content 2d the bytes 12 to 29 represents.
  • In the file ( 3 ) of the programming data record there are two data records and an end of file record, the record headers are again simple and the end of file records are underlined twice. The parts that are not underlined represent the transferred data and these are, as directly from the first two records of the file ( 3 ) of the programming data record, the data bytes number 1 to number 29 according to the content of the programming data record 2d , Because in the file ( 3 ) the start address of the programming data record is stored in the form of a data record, it is not necessary to specify this address in the record header of the first two records; In the first record, a record length of 10h is specified and therefore bytes 1 to 16 are also there 2d contained as data, in contrast, the remaining bytes number 13 to 29 are added in the second record 2d transferred, which corresponds to a record length of 0Dh (decimal 13). The load offset in the header of the second record is l0h (decimal, depending on the data length of the first record 16 ).
  • As in 1 shown, the programming data record can, if desired, be generated by an encryption program ( 8th ) are encrypted, which has the advantage that the file ( 3 ) of the programming data record is only transferred in an encrypted form when it is forwarded below and the know-how of the control unit manufacturer contained in the object code of the program is therefore not published.
  • It is also possible to change the content of the programming data set to compress, and then encrypt if necessary.
  • The first to fourth explained Steps are usually found at the control unit manufacturer instead, they provide individual work progress on a planned one Reprogramming a device and is a temporal coordination of these individual steps for basic View not necessary.
  • To 1 the file suitable for distribution ( 3 ) of the programming data record, which, for. B. is sent by e-mail or by post, in a fifth step in a diagnostic device ( 9 ) read. This diagnostic device ( 9 ) can be in the vehicle manufacturer's production line in which the control unit ( 4 ) in a corresponding vehicle (( 18 ) to 5 ) is installed, but this is a relatively atypical case since new devices are usually delivered to the vehicle manufacturer by the control device manufacturer in a fully programmed form. This program device is typically in the workshop of a vehicle manufacturer (or a free workshop) and is used in the manner already explained above for reprogramming a control device ( 4 ).
  • In a fifth step, the programming data record ( 3 ) using data transmission means that exist between the diagnostic device ( 9 ) and the control unit ( 4 ) exist, transferred into this. Basically, the programming data record can be transferred in Intel Hex format. Typically, however, the diagnostic device already interprets the Intel Hex format of the programming data record and then transmits the content of the programming data record to the control device in a manner specified by the diagnostic protocol.
  • The transmission is particularly advantageous if the control unit ( 4 ) does not have to be expanded, nor if any manipulations have to be carried out on it. This is the case if the connection cable ( 13 ) of the diagnostic device ( 9 ) only to the diagnostic connector ( 11 ) of the vehicle ( 18 ) must be connected and the data transmission means enable a direct transfer to the control unit, as is shown below in connection with 5 is explained.
  • It should be added that instead of a diagnostic device ( 9 ) in principle also any electronic device for implementing the fifth step, the transmission of the programming data record ( 3 ) in the control unit ( 4 ) can be used, which only needs to be able to control the (possibly removed) control unit ( 4 ) via any interface ( 4 ) to make electrical contact and to handle the transmission using any protocol. The term "diagnostic device" in its expanded meaning in the sense of the invention also includes all such data transmission devices.
  • In a sixth step, the control unit checks ( 4 ) using his system program in the area ( 29 ) of the Flash E-PROM memory ( 5 ) whether it belongs to the area of the file ( 3 ) of the transmitted programming data record belongs to approved control units, and this check is carried out on the basis of the device description in the programming data record. If encryption has been carried out during the creation of programming data, the encrypted data must of course first be decrypted by the control unit before it is checked; The same also applies to data compression that may have been carried out before the data transmission.
  • Is the electronic control unit ( 4 ) in the sixth step to determine that it belongs to the area of approved devices, in a seventh and last step the area of change ( 6 ) in the Flash E-PROM memory ( 5 ) from the control unit itself in the file ( 3 ) programmed the programming data set in a certain way; As already mentioned, the control unit ( 4 ) Flash E-PROM programming device ( 27 ) used.
  • In contrast to the steps first to thirdly, which, as explained, do not necessarily belong together in terms of time, the subsequent fourth to seventh steps are carried out as an associated operation either at the vehicle manufacturer or, as explained, in a particularly advantageous manner in the workshop.
  • The individual representations of 3 show files of the description data with extended device description for the approved control units:
  • In the description data file ( 2a ) to 3a three different hardware numbers are specified, which means that all (logical OR) control units ( 4 ) are approved for programming with the device version according to these hardware numbers.
  • In the description data file ( 2 B ) to 3b a hardware number is followed by a range of serial numbers; this means that the device version described by the hardware number is limited by this range of serial numbers (logical AND); it should be added that instead of a range of serial numbers, only a single serial number can be specified.
  • In the description data file ( 2c ) to 3c The hardware number is followed by a software number that corresponds to a specific software version of the device version of a control unit specified by the hardware number ( 4 ) certainly; this means that the device version described by the hardware number is limited by the software version described by the software number (logical AND). Several software numbers can also be specified, so that the restriction refers to the selection of the specified software numbers (logical OR).
  • In the description data file ( 2d ) to 3d the hardware number follows both a range of serial numbers and a software number; This means that the device status of a control device (described by the hardware number ( 4 ) is restricted both by one or a range of serial numbers (logical AND) and by one (or in the case of several by several) software numbers (logical AND).
  • In the description data file ( 2e ) to 3e three hardware numbers are entered, and the last hardware number is restricted by two ranges of serial numbers as well as by the software versions of four software numbers.
  • Under 3f is a description data file ( 2f ), in which two memory image files and two (hardware numbers further restricted by software numbers and / or serial numbers) are specified; when the programming data record based on this description approach is executed, the one memory image is only recorded in devices with the associated one hardware number and the other memory image is only recorded in devices with the other hardware number. In this way, different devices can be programmed differently with one programming data set.
  • It should be mentioned that the description data further Equipment-, Component or software specific identifiers that can contain allow further refinement of the restrictions. For example also an identification of the microprocessor the description data to be added.
  • As explained, a description data file ( 2x ) to 2 respectively. 3a to 3f designed as a text file with individual lines of text. As already shown above, there are a number of very specific words, each of which is effective as an OP key, ie as a password for a specific operation. The operand belonging to such an operation is embedded in two quotation marks in the text below. The entire other text is freely selectable, so that a detailed plain text comment is possible within the text file.
  • As explained, the programming data converter ( 7 ) from the file ( 2 ) the description data record and the file ( 1 ) the memory dump the file ( 3 ) of the programming data record and inserts in this data processing operation the operations contained in the description data record as a "mother format" subordinate set of "daughter records", with a specific record type being defined for each operation. The assignment of a record type mentioned above (other record types can also be defined) in the programming data record to the OP key of the description data record results from the following table:
    Figure 00240001
  • It should be noted that the combination of a file describing the memory image and a file with the device description to form the file of a programming data record can also be carried out practically in another way; it is only necessary to implement the invention Lich that the programming data record includes the device description in addition to the memory image in a sufficient manner so that the compatibility check can be carried out in a clear manner in the control unit.
  • In 5 are data transfer means for transferring the file ( 3 ) of the programming data record in the electronic control unit ( 4 ). In addition to the electronic control unit ( 4 ) is, for example, an ABS control unit in the vehicle ( 16 ) and a control unit for a vehicle engine control ( 17 ) intended. According to the state of the art, these devices are connected via a CAN vehicle bus ( 10 ) connected to each other at the z. B. also the dashboard display ( 15 ) is connected in the driver's cabin.
  • From this dashboard display ( 15 ) diagnostic data about the successful or unsuccessful course of the Flash-E-PROM programming in the control unit (if necessary) 4 ) are displayed by the control unit itself.
  • To connect the diagnostic device ( 9 ) with the electronics provided in the road vehicle ( 18 ) is a 16-pin diagnostic connector on this ( 11 ) according to ISO / DIS 15031-3, on which the twisted lines CAN-H and CAN-L of the CAN vehicle bus ( 10 ) are connected (on the diagnostic connector ( 11 ) are provided for CAN H contact No. 6 and for CAN-L contact No. 14).
  • The diagnostic device ( 9 ) is first started by plugging in the connection cable ( 13 ) in the diagnostic connector ( 11 ) to the vehicle ( 18 ) connected.
  • It should be mentioned that z. B. the K line can also be used for data transmission, provided that the K line is installed at all (on the diagnostic connector ( 11 ) contact no. 7 is reserved for the K line).
  • With the connection via "CAN" explained above, it is disadvantageous that the CAN vehicle bus is present on the diagnostic connector without buffering, ie without potential isolation. To implement a potential-free CAN connection, there is the option - in 5 drawn in dashed lines - a CAN gateway ( 12 ) which should be used to connect to the diagnostic device ( 9 ) via its galvanically isolated CAN connection ( 14 ) also on a diagnostic connector ( 11 ) connected. With this solution, however, the CAN gateway ( 12 ) as an additional module in the vehicle ( 18 ) must be installed, which leads to higher basic costs.
  • To avoid these costs, the transmission between the diagnostic device ( 9 ) and the control unit ( 4 ) in the vehicle ( 18 ) also done by radio; the diagnostic connector ( 11 ) a radio module is plugged in and this is transmitted by radio from the diagnostic device ( 9 ) controlled from; this transmission path is of course electrically isolated per se.
  • By using such a radio connection, the realization of the vision is getting closer, in the not too distant future the electronic control devices in the field ( 4 ) to be re-programmed automatically "on-line" without having to visit a workshop; the radio module is fixed in the vehicle ( 18 ) is installed and is transmitted by radio directly from the diagnostic device ( 9 ) in the workshop to carry out the programming dialog. With the means explained, the invention already enables the selection of a specific device type or the selective selection of an individual control device.

Claims (12)

  1. Programming procedure for at least one area ( 6 ) in at least one electronically erasable and writable memory ( 5 ), which is used as a program memory, as a data memory or as a program and data memory for at least one microprocessor ( 21 ) in an electronic control unit ( 4 ) for use in electronics ( 18 ) Electronic control or regulation arranged on a road vehicle and features: a) In a first step, at least one memory image ( 1 ) generated for the at least one electronically erasable and writable memory (5) in a memory area defined there; b) in a second step, a description data record ( 2 ) which contains a device description of the electronic control devices approved for programming, which includes at least the hardware number of the device version of at least one electronic control device; c) in a third step, the at least one memory image ( 1 ) and the description data record ( 2 ) a programming data set ( 3 ) which contains the device description; d) in a fourth step, the programming data record ( 3 ) in a diagnostic device ( 9 ) read; e) in a fifth step, the programming data record ( 3 ) from the diagnostic device ( 9 ) using data transfer means ( 13 . 11 . 10 . 26 ) transferred to the control unit; f) in a sixth step, the control unit ( 4 ) checked whether the electronic control unit ( 4 ) to the area for the transmitted programming data record ( 3 ) approved control units, which is indicated by the device description ( 2 ) is fixed; g) belongs to the electronic control unit ( 4 ) to the area of the approved control units, in a seventh step the at least one area ( 6 ) in the at least one electronically erasable and writable memory ( 5 ) of the control unit ( 4 ) from the control unit ( 4 ) even in the through the programming data set ( 3 ) programmed in a certain way.
  2. Programming method according to claim 1, characterized in that steps a) to d) are not necessarily related in time Process at the control unit manufacturer, and subsequently steps e) to g) are carried out as a time-related process either at the vehicle manufacturer or in the workshop.
  3. Programming method according to claim 1 or 2, characterized in that the programming data record ( 3 ) in the fifth step e) sequentially into the control unit as a sequence of data segments ( 4 ) is transmitted.
  4. Programming method according to at least one of claims 1 to 3, characterized in that the device description ( 2a ) the electronic control units approved for programming comprise several hardware numbers of the device versions of one or more electronic control units.
  5. Programming method according to Claim 1 or 4, characterized in that the device status of a control device described by the hardware number is determined by a serial number or by a range of serial numbers ( 2 B ) is restricted.
  6. Programming method according to Claim 1 or 4, characterized in that the device status of a control device described by the hardware number is determined by a software number ( 2c ) or by a range of software numbers ( 2e ), which describe the software version.
  7. Programming method according to Claim 1 or 4, characterized in that the device status of a control device described by the hardware number is determined not only by a serial number or a range of serial numbers, but also by a software number or a range of software numbers ( 2e ) is restricted.
  8. Programming method according to at least one of the preceding claims, characterized in that the programming data record generated in the third step c) ( 3 ) encrypted during its generation, and is decrypted again by the control unit in fifth step e).
  9. Programming method according to at least one of the preceding claims, characterized in that the programming data record generated in the third step c) ( 3 ) compressed during its creation, and by the control unit ( 4 ) is decompressed again in the fifth step e).
  10. Programming method according to at least one of the preceding claims, characterized in that the programming data record generated in the third step c) ( 3 ) is secured by at least one checksum, which is checked by the control unit.
  11. Programming method according to at least one of the preceding claims, characterized in that the data transmission means for transmitting the programming data set ( 3 ) from the diagnostic device ( 9 ) in the control unit ( 4 ) Radio equipment can be used.
  12. Programming method according to claim 11, characterized in that the programming method automatically "on-line" for a control device located in the field ( 4 ) is carried out without visiting a workshop.
DE2002156799 2002-12-05 2002-12-05 Programming flash EPROMs in road vehicle control electronics with microprocessor involves checking controller against equipment description in generated programming data record transferred to it Active DE10256799B3 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2002156799 DE10256799B3 (en) 2002-12-05 2002-12-05 Programming flash EPROMs in road vehicle control electronics with microprocessor involves checking controller against equipment description in generated programming data record transferred to it

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE2002156799 DE10256799B3 (en) 2002-12-05 2002-12-05 Programming flash EPROMs in road vehicle control electronics with microprocessor involves checking controller against equipment description in generated programming data record transferred to it
EP20030027241 EP1426849A1 (en) 2002-12-05 2003-11-28 Method for programming flash EPROMs of an electronic control device for vehicles including a microprocessor
US10/728,722 US6799101B2 (en) 2002-12-05 2003-12-05 Method for programming flash EEPROMS in microprocessor-equipped vehicle control electronics

Publications (1)

Publication Number Publication Date
DE10256799B3 true DE10256799B3 (en) 2004-04-29

Family

ID=32049652

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2002156799 Active DE10256799B3 (en) 2002-12-05 2002-12-05 Programming flash EPROMs in road vehicle control electronics with microprocessor involves checking controller against equipment description in generated programming data record transferred to it

Country Status (3)

Country Link
US (1) US6799101B2 (en)
EP (1) EP1426849A1 (en)
DE (1) DE10256799B3 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004052438A1 (en) * 2004-10-28 2006-05-04 Agtatec Ag Service programmer for automatic doors has applications memory supplying control programs to microprocessors
DE102007018769A1 (en) * 2007-04-20 2008-10-23 Giesecke & Devrient Gmbh Access to the mass storage of a portable data carrier
DE102010040115A1 (en) * 2010-09-01 2012-03-01 Robert Bosch Gmbh Method for providing information to a controller
DE102014015445A1 (en) 2014-10-18 2015-04-02 Daimler Ag Method for coding at least one parameter in a control unit of a motor vehicle
DE102016116168A1 (en) 2016-08-30 2018-03-01 Lsp Innovative Automotive Systems Gmbh Vehicle, system and method for updating the firmware of a vehicle component

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1460496B1 (en) * 2003-03-19 2007-10-24 Robert Bosch Gmbh Peripheral chip set
DE10332452B4 (en) * 2003-07-17 2018-04-12 Continental Teves Ag & Co. Ohg Control and regulating device in a motor vehicle and method for operating the same
US7366589B2 (en) * 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
US7885739B2 (en) * 2004-08-19 2011-02-08 Spx Corporation Open-ended vehicle diagnostic device interface
US7805228B2 (en) * 2004-08-19 2010-09-28 Spx Corporation Vehicle diagnostic device
US7823169B1 (en) 2004-10-28 2010-10-26 Wheeler Thomas T Performing operations by a first functionality within a second functionality in a same or in a different programming language
US8266631B1 (en) 2004-10-28 2012-09-11 Curen Software Enterprises, L.L.C. Calling a second functionality by a first functionality
US7774789B1 (en) 2004-10-28 2010-08-10 Wheeler Thomas T Creating a proxy object and providing information related to a proxy object
US20060106508A1 (en) * 2004-11-12 2006-05-18 Spx Corporation Remote display of diagnostic data apparatus and method
US7272475B2 (en) * 2004-12-02 2007-09-18 General Motors Corporation Method for updating vehicle diagnostics software
JP2006163933A (en) * 2004-12-08 2006-06-22 Hitachi Ltd Control data storage device
US7797688B1 (en) 2005-03-22 2010-09-14 Dubagunta Saikumar V Integrating applications in multiple languages
US7861212B1 (en) 2005-03-22 2010-12-28 Dubagunta Saikumar V System, method, and computer readable medium for integrating an original application with a remote application
US8578349B1 (en) 2005-03-23 2013-11-05 Curen Software Enterprises, L.L.C. System, method, and computer readable medium for integrating an original language application with a target language application
US20070050095A1 (en) * 2005-09-01 2007-03-01 Polaris Industries Inc. Controller area network based self-configuring vehicle management system and method
US7920944B2 (en) * 2005-10-21 2011-04-05 General Motors Llc Vehicle diagnostic test and reporting method
US20070185624A1 (en) * 2006-02-07 2007-08-09 General Motors Corporation Method for remote reprogramming of vehicle flash memory
US7810140B1 (en) * 2006-05-23 2010-10-05 Lipari Paul A System, method, and computer readable medium for processing a message in a transport
US7844759B1 (en) 2006-07-28 2010-11-30 Cowin Gregory L System, method, and computer readable medium for processing a message queue
US20080046440A1 (en) * 2006-08-16 2008-02-21 Estes Philip F Method And System For Enforcing User-Defined Relational Limitations In A Recursive Relational Database Table
US7567461B2 (en) * 2006-08-18 2009-07-28 Micron Technology, Inc. Method and system for minimizing number of programming pulses used to program rows of non-volatile memory cells
US8146052B2 (en) * 2006-08-22 2012-03-27 Caterpillar Inc. Method and system for hierarchical hardware mapping for software design
KR100771823B1 (en) 2006-09-12 2007-10-30 지멘스 오토모티브 주식회사 Apparatus and method for detecting ecu of lpi
US20080103658A1 (en) * 2006-10-27 2008-05-01 Spx Corporation Scan tool software update using an image
US7970724B1 (en) 2006-12-22 2011-06-28 Curen Software Enterprises, L.L.C. Execution of a canonical rules based agent
US7949626B1 (en) 2006-12-22 2011-05-24 Curen Software Enterprises, L.L.C. Movement of an agent that utilizes a compiled set of canonical rules
US8200603B1 (en) 2006-12-22 2012-06-12 Curen Software Enterprises, L.L.C. Construction of an agent that utilizes as-needed canonical rules
US7660780B1 (en) 2006-12-22 2010-02-09 Patoskie John P Moving an agent from a first execution environment to a second execution environment
US7860517B1 (en) 2006-12-22 2010-12-28 Patoskie John P Mobile device tracking using mobile agent location breadcrumbs
US8132179B1 (en) 2006-12-22 2012-03-06 Curen Software Enterprises, L.L.C. Web service interface for mobile agents
US7698243B1 (en) 2006-12-22 2010-04-13 Hauser Robert R Constructing an agent in a first execution environment using canonical rules
US8423496B1 (en) 2006-12-22 2013-04-16 Curen Software Enterprises, L.L.C. Dynamic determination of needed agent rules
US9311141B2 (en) 2006-12-22 2016-04-12 Callahan Cellular L.L.C. Survival rule usage by software agents
US20080157920A1 (en) 2006-12-28 2008-07-03 Detroit Diesel Corporation Calibratable uds security concept for heavy-duty diesel engine
US8340855B2 (en) 2008-04-22 2012-12-25 Spx Corporation USB isolation for vehicle communication interface
WO2012018733A2 (en) 2010-08-03 2012-02-09 Spx Corporation Vehicle diagnostic, communication and signal delivery system
CN104572153A (en) * 2013-10-23 2015-04-29 上海汽车集团股份有限公司 Update data conversion method for vehicle updating
CN104714789B (en) * 2013-12-14 2018-08-03 中国航空工业集团公司第六三一研究所 A kind of design of nominal data storage method
US9219499B2 (en) 2014-05-16 2015-12-22 Robert Bosch Gmbh Run time compression method for a vehicle communication bus
US10500955B2 (en) * 2014-12-30 2019-12-10 Visteon Global Technologies, Inc. Automatic upgrade of a vehicle-based processor based on a physical component change

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6181992B1 (en) * 1993-06-25 2001-01-30 Chrysler Corporation Automotive diagnostic service tool with hand held tool and master controller
DE10143030A1 (en) * 2001-09-01 2003-03-20 Bayerische Motoren Werke Ag Method, device and computer program product for storing and / or updating control unit data of at least one control unit of a motor vehicle

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5287281A (en) * 1991-02-27 1994-02-15 Echlin Inc. Computer controlled flow of nitrous oxide injected into an internal combustion engine
US5768372A (en) * 1996-03-13 1998-06-16 Altera Corporation Method and apparatus for securing programming data of a programmable logic device
US6535138B1 (en) 1996-10-25 2003-03-18 Carrier Corporation HVAC network verification system
US6535811B1 (en) * 1999-11-03 2003-03-18 Holley Performance Products, Inc. System and method for real-time electronic engine control
US6165102A (en) * 1999-11-22 2000-12-26 Cummins Engine Company, Inc. System for controlling output torque characteristics of an internal combustion engine
US7095858B2 (en) * 2001-05-10 2006-08-22 Ranco Incorporated Of Delaware System and method for securely upgrading firmware
US6728605B2 (en) * 2001-05-16 2004-04-27 Beacon Marine Security Limited Vehicle speed monitoring system and method
DE10124699C1 (en) 2001-05-18 2002-12-19 Micronas Gmbh Circuit arrangement for improving the intelligibility of speech-containing audio signals

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6181992B1 (en) * 1993-06-25 2001-01-30 Chrysler Corporation Automotive diagnostic service tool with hand held tool and master controller
DE10143030A1 (en) * 2001-09-01 2003-03-20 Bayerische Motoren Werke Ag Method, device and computer program product for storing and / or updating control unit data of at least one control unit of a motor vehicle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FLASHit-Manual ab Version 5.3, hse-electronic, 14.08.01 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004052438A1 (en) * 2004-10-28 2006-05-04 Agtatec Ag Service programmer for automatic doors has applications memory supplying control programs to microprocessors
DE102007018769A1 (en) * 2007-04-20 2008-10-23 Giesecke & Devrient Gmbh Access to the mass storage of a portable data carrier
DE102010040115A1 (en) * 2010-09-01 2012-03-01 Robert Bosch Gmbh Method for providing information to a controller
DE102014015445A1 (en) 2014-10-18 2015-04-02 Daimler Ag Method for coding at least one parameter in a control unit of a motor vehicle
DE102016116168A1 (en) 2016-08-30 2018-03-01 Lsp Innovative Automotive Systems Gmbh Vehicle, system and method for updating the firmware of a vehicle component

Also Published As

Publication number Publication date
US6799101B2 (en) 2004-09-28
US20040148073A1 (en) 2004-07-29
EP1426849A1 (en) 2004-06-09

Similar Documents

Publication Publication Date Title
US5473540A (en) Electronic controller for vehicle
US6859699B2 (en) Network-based method and system for distributing data
US6816971B2 (en) Signature process
KR910002804B1 (en) Multi-function testor for self-diagnosis
DE19541816C2 (en) Diagnostic system for a motor vehicle
US4967143A (en) System for diagnosing anomalies or breakdowns in a plurality of types of electronic control systems installed in motor vehicles
US20070290847A1 (en) Vehicle tag used for transmitting vehicle telemetry data
CA2396339C (en) Automated vehicle inspection system
EP1034982A2 (en) Automobile control unit having different program modules
US9008897B2 (en) Method and apparatus for reading and erasing diagnostic trouble codes from a vehicle
EP0668553A1 (en) Method and apparatus for generating calibration information for an electronic engine control module
JP2005529531A (en) Method and apparatus for telematic service for vehicles
US6598114B2 (en) Electronic control unit including flash memory and method and apparatus for storing control data group into flash memory
JP3275097B2 (en) Method of configuring a computer bus adapter circuit board without using a jumper wire or switch
US8239094B2 (en) Test requirement list for diagnostic tests
US20020023223A1 (en) Authorization process using a certificate
USRE39619E1 (en) Automotive code reader
EP1181521B1 (en) Diagnostic test device for motor vehicles with programmable control devices
US6208948B1 (en) Computer-assisted diagnostic device and diagnostic process for electronically controlled systems
DE69816830T3 (en) Vehicle Service System with Web Server
DE10237715B4 (en) Device for accessing a vehicle control system via a wireless connection
US20060106514A1 (en) Open-ended PC host interface for vehicle data recorder
KR20010031683A (en) System and method for distributed computer automotive service equipment
US20100204878A1 (en) Modular Vehicular Diagnostic Tool
US8010249B2 (en) Vehicle diagnostic device

Legal Events

Date Code Title Description
8100 Publication of the examined application without publication of unexamined application
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: WABCO GMBH, 30453 HANNOVER, DE