WO2005081650A2 - A system and a method for communication with an electronic unit in vehicles - Google Patents

A system and a method for communication with an electronic unit in vehicles Download PDF

Info

Publication number
WO2005081650A2
WO2005081650A2 PCT/SE2005/000254 SE2005000254W WO2005081650A2 WO 2005081650 A2 WO2005081650 A2 WO 2005081650A2 SE 2005000254 W SE2005000254 W SE 2005000254W WO 2005081650 A2 WO2005081650 A2 WO 2005081650A2
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
unit
communication
memory
interface unit
Prior art date
Application number
PCT/SE2005/000254
Other languages
French (fr)
Other versions
WO2005081650A3 (en
Inventor
Joachim Fritzson
Thomas Nilsson
Mikael SÖDERBERG
Original Assignee
Movimento Ab
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 Movimento Ab filed Critical Movimento Ab
Publication of WO2005081650A2 publication Critical patent/WO2005081650A2/en
Publication of WO2005081650A3 publication Critical patent/WO2005081650A3/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/008Registering or indicating the working of vehicles communicating information to a remotely located station
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841Registering performance data

Definitions

  • the present invention relates to a system for communication with at least one electronic unit in a vehicle, which system comprises an interface unit arranged to communicate with said at least one electronic unit, and at least one replaceable memory unit that can be connected to the interface unit.
  • the present invention relates to a method for communication with at least one electronic unit in a vehicle.
  • microcomputers are being used to an increasing extent.
  • the microcomputers are used to control various functions in the vehicle, for example the ignition system, air-conditioning system, steering and braking system.
  • a number of microcomputers, so-called ECUs (Electronic Control Units) are comprised for this purpose in a number of so- called nodes, and are programmed to carry out the tasks they are intended to perform.
  • Each node is function-related; it can, for example, comprise an ECU and a relay.
  • Each ECU therefore comprises a memory area that is used to store the software that carries out the programming.
  • these nodes are interconnected in one or more vehicle networks, which networks can be of any known type, for example MOST (Media Oriented Systems Transport) which is a fibre network, CAN (Control Area Network), or LIN (Local Interconnect Network) which is a simpler single-wire system, and also wireless transmission.
  • the network or networks can, in certain cases, be co-ordinated and controlled by a central ECU, which thus functions as a communication hub in the network. In other cases, this central ECU is omitted, and the relevant ECU is addressed directly for communication via the network. For various reasons, it is important that communication can be established with the vehicle, both when any faults are to be diagnosed and when the software in one or more of the ECUs is to be replaced by new software.
  • fault codes are created that are stored in a memory in the ECU.
  • the fault codes exceed a certain number, which can be from one and upwards, the driver of the vehicle is given a fault indication and is recommended to contact a service workshop.
  • new software is to be added, this may be because the previous software was faulty, or because new functions have been added. In certain cases, the vehicle's performance or characteristics can be changed by new software being added.
  • OBD On Board Diagnostics
  • Physical protocol means a predefined description of electrical levels, for example when a signal is to be interpreted as a one or a zero, which pulse edges are acceptable, and the like.
  • High-level protocol means a function that decodes the meaning of the bits.
  • Interface means the interface between the vehicle and the external equipment that is used.
  • the high-level protocol for OBD is intended for diagnosis. OBD is common to most vehicle manufacturers at present, but certain dialectical differences can occur. There is also a further development that is designated OBD II.
  • a vehicle model-specific hand-held unit equipped with the communication protocol that is required for communication with the vehicle concerned.
  • This hand-held unit thus comprises both so-called firmware, comprising a high-level protocol which is specific for the vehicle model, such as OBD or some equivalent.
  • the software that is to be updated is supplied via a replaceable memory card, for example of the SD (Secure Digital) type, which is a currently generally-occurring form of replaceable memory which is used, among other things, for digital cameras.
  • SD Secure Digital
  • An object of the present invention is to provide a secure system and a method for handling communication with at least one electronic unit in a vehicle, with the system and the method being able to be used with more than one vehicle manufacturer.
  • the memory unit comprises a protected memory area, which protected memory area in turn comprises a unique identity and vehicle model-specific means for establishing communication with said at least one electronic unit in the vehicle concerned, via the interface unit.
  • a method of the type mentioned in the introduction comprises, in addition, the steps of: receiving vehicle-specific software that is stored partly in an open memory module and partly in a locked memory module in a memory unit; connection of the memory unit to an interface unit; connection of the interface unit to the vehicle; introductory communication between the interface unit and the vehicle; verification that the information in the open memory module and the locked memory module is authentic by vehicle-specific information in the locked memory module being used to carry out a verification of the electronic unit of the handshaking type; and continued communication in the event of a positive verification.
  • This object is also achieved by an interface unit and a memory unit as described above.
  • the present invention has a number of advantages in comparison to what has been known previously. Among other things, the following can be mentioned:
  • Cheaper equipment means that more small service workshops can carry out services that require communication with at least one electronic unit in a vehicle.
  • the ability to use equipment for vehicles from more than one vehicle manufacturer results in an additional saving.
  • Simpler handling of software provides a more versatile system for both vehicle manufacturers and service workshops. As more small service workshops are able to handle communication with at least one electronic unit in a vehicle, the vehicle owner has a larger number of service workshops that can be used when such communication is required. Increased data security.
  • Figure 1 shows schematically a vehicle network
  • FIG 2 shows schematically the system according to the invention
  • Figure 3 shows schematically how the system according to the invention obtains data externally.
  • ECUs Electronic Control Units
  • nodes for controlling various functions in the vehicle, for example the ignition system, air-conditioning system, steering and braking system.
  • Each node 1 , 1', 1" is function-related; it can, for example, like the node 1 , comprise an ECU 2 and a relay 3, as indicated in Figure 1.
  • Other nodes 1', 1" can comprise other functional devices 3', 3" connected to respective ECUs 2', 2".
  • Each ECU 2, 2', 2" comprises a memory area 4, 4', 4" that is used for storing the software that carries out the programming.
  • nodes 1 , 1 ', 1" are interconnected in a vehicle network 5, which network 5 can, for example, be any one of the previously known types: MOST, which is a fibre network, CAN or LIN, which is a simpler single-wire system.
  • MOST which is a fibre network
  • CAN CAN
  • LIN which is a simpler single-wire system.
  • the system comprises, with reference also to Figure 2, an interface unit, preferably in the form of a portable unit 6 that comprises OBD (On Board Diagnostics), that is a physical protocol, a high-level protocol and an interface as described above, or any generally known variant thereof, with the communication with a vehicle 7 being established using a link 8 defined by the protocol.
  • OBD On Board Diagnostics
  • the system also comprises a replaceable memory card 9 of the SD (Secure Data) type, which is a previously known type, which memory card 9 is inserted in an opening 10 in the portable unit 6 designed for the purpose, whereby contact is established in a known way between the portable unit 6 and the memory card 9.
  • a microcomputer 11 in the portable unit 6 is arranged to handle the communication to and from the SD card 9. Such a microcomputer 11 is of a previously known type and is not described here in greater detail.
  • a memory card 9 of the SD type comprises an open readable and writable memory module 12, and a locked memory module 13 that is only accessible by the vehicle manufacturer.
  • the open memory module 12 is provided with a completely or partially encrypted version of the software that is to be supplied to the vehicle 7, while the locked memory module 13 is provided with a specific readable unique identity and a secret high-level protocol that is specific to the model or make of vehicle concerned.
  • the high- level protocol makes possible communication with the vehicle 7 concerned, provided that it is a vehicle for which that high-level protocol is intended.
  • the completely or partially encrypted software in the open memory module 12 of the SD card 9 consists of a bit string, with the encrypted part being decrypted by a secret decryption mechanism in the hardware.
  • the software is matched with the unique identity and is sent to the vehicle 7 via, for example, the OBD protocol in the portable unit via the link 8, with the OBD's high-level protocol decoding the commands.
  • the software is matched with the unique identity of the SD card 9, only the relevant SD card 9, for which that software is intended, can be used.
  • the now decoded bit string is received by one or, where appropriate, several ECUs 2 in the vehicle 7, where the transmitted commands or instructions are recognized and a handshake procedure takes place to verify the correct operation of the security mechanisms.
  • the vehicle network 5 in Figure 2 corresponds to the vehicle network 5 in Figure 1 , with the vehicle network 5 being illustrated more schematically in Figure 2.
  • one or more of the microcomputers 2, 2', 2" comprised in the network 5 are thereafter updated automatically, a process that is carried out relatively quickly, particularly if the vehicle 7 is equipped with a fast network such as the fibre optic MOST.
  • the handheld unit 6 is itself equipped with indication equipment 14, such as light-emitting diodes or a display, where the ongoing process can be followed.
  • indication equipment 14 such as light-emitting diodes or a display
  • a handheld computer of the PDA type (not shown) can be connected to the handheld unit 6 and thereby constitute a so-called MMI (Man Machine Interface) for more complex procedures.
  • MMI Man Machine Interface
  • the handheld unit 6 can also be used to read off fault codes in the vehicle 7, either in association with updating the software or separately.
  • the SD card 9 can also be provided, where appropriate, with the software that is required for "resetting" the fault codes.
  • the handheld unit 6 can also be provided with input devices 15, such as buttons or a touch-sensitive display, via which the user can, for example, confirm the transmission of new software or the resetting of fault codes.
  • the SD card 9 is provided, now with reference also to Figure 3, by the respective vehicle manufacturer 16, 17, 18 or by a representative appointed by the manufacturer, who supplies the relevant secret high-level protocol and a unique identity to the respective locked memory module 13.
  • a service workshop 19 applies for an SD card from the respective manufacturer 16, 17, 18 or representative who, after the required authorization has been confirmed, allocates the service workshop 19 a unique user identity and an SD card 9, which SD card 9 has a unique identity that is associated with the unique user identity of the service workshop 19.
  • the user at the service workshop 19 logs on to the home page of the vehicle manufacturer via the Internet 21 with his unique user identity using a suitable computer 20. If all the logging-on data is correct, the user can transfer the required encrypted software to his computer 20.
  • a read and write unit 22 for the SD card designed for the purpose is connected to the user's computer 20, using which the encrypted information obtained can, in addition, be transferred to the SD card 9.
  • the unique serial number for the handheld unit 6 can constitute part of the encryption/decryption procedure. In this way, even greater assurance can be achieved that it is the correct user, correct software, and correct hardware in the hands of the correct person.
  • each encryption is unique for each user, with the user's identity being matched with the identity of the SD card 9.
  • a checksum added to the unique identity can be a constant value. If an unauthorized user should manage to access the information, it is still necessary for decryption to be carried out.
  • the encryption is carried out by a secret high-level protocol in combination with a unique identity that is entered into a locked memory area 13 on the SD card 9, it is well protected. Only when communication has been established with the relevant ECU 2, 2', 2" (one or more) in the vehicle 7, is the bit stream decoded, for which reason only the vehicle 7 and no other obtains the decoded software.
  • only service workshops 19 approved by the respective vehicle manufacturers, 16, 17, 18 are provided with the ability to log on to the home page on the Internet 21 that is designed for downloading software. These approved service workshops 19 are, in addition, the only ones that obtain the requisite SD cards 9.
  • the SD card 9 can also be completely empty initially, with all the information being obtained via the Internet 21 prior to each loading in. Accordingly, the locked memory area 13 on the SD card 9 is automatically unlocked via a key on the vehicle manufacturer's 16, 17, 18 home page. The information in the whole memory 12, 13 of the SD card 9 is first erased. The information that is intended for the locked area 13, that is the unique identity and the secret high-level protocol, is transferred via the Internet 21 and installed in this locked area 13. Other information is transferred via the Internet 21 and installed in the open module 12 of the memory area. In this way, the service workshop 19 can have a single SD card 9 which is loaded with data via the Internet 21 before each operation, regardless of which make or model of vehicle is concerned. All the service workshop 19 needs to have is an approved user identity for each vehicle manufacturer 16, 17, 18 concerned.
  • the service workshop 19 has obtained authorization from a vehicle manufacturer 16 to handle software as described above.
  • the service workshop 19 is in possession of an SD card 9 which is associated with the vehicle manufacturer's 16 vehicle model 23, and authorization to transfer encrypted software from the vehicle manufacturer's 16 home page via the Internet 21.
  • the service workshop 19 transfers the software that is to be updated in the vehicle model 23 in encrypted form to the computer 20 of the PC type arranged at the service workshop 19 via the Internet 21.
  • the service workshop 19 logs on to the home page of the vehicle manufacturer 16 with its unique user identity with which the unique identity of the SD card 9 is associated.
  • the encrypted software is then transferred from the PC 20 to the SD card 9 via previously known equipment 22 designed for the purpose.
  • the SD card 9 is then inserted, with reference to Figure 2, in the portable unit 6, which in turn is connected to the vehicle via the OBD link 8.
  • the SD card 9 now communicates with the microcomputer 11 in the portable unit 6, which microcomputer 11 forwards the communication to an ECU 2 in the vehicle. So-called handshaking now takes place, which means that the ECU 2 accepts the communication.
  • the ECU 2 is instructed to carry out measures for updating the software in one or more nodes 1 , 1 ', 1", after which the new software is transferred.
  • all communication or at least part of the communication between the handheld unit 6 and the vehicle 7 is encrypted by a communication encryption mechanism in such a way that an outsider cannot listen to the data traffic between the handheld unit 6 and the vehicle 7.
  • the communication encryption and corresponding decryption are carried out using an encryption/decryption algorithm in the secret high-level protocol and using a corresponding encryption/decryption algorithm in each ECU 2, 2', 2" concerned, with the encryption/decryption algorithm being of a self-updating kind.
  • An example of such a encryption/decryption algorithm is so-called "rolling codes", such as for example are used when a car door or some other door, such as a garage door, is unlocked via a radio signal.
  • the code that was used cannot be used again, and instead new codes are used the whole time.
  • a relatively large number of codes are stored in a code list.
  • a certain number of consecutive codes in the code list for example ten codes, are accepted by the receiver.
  • the transmitter can then send codes at random nine times, without being perceived by the receiver, without the system ceasing to function, as the tenth code is also accepted.
  • the receiver perceives a correct code that is to be found among the ten acceptable codes, the accepted code is deleted from the list.
  • the ten consecutive codes in the code list going forward from the most recently accepted code are now the ones that are accepted.
  • the invention is not limited to the embodiment described above, but can be varied freely within the scope of the following patent claims.
  • the use of the OBD described above is not necessary, but other common communication standards can be used.
  • One alternative is to connect directly to the MOST network, whereby a faster communication is obtained than when OBD is used, as OBD utilizes the slower, relative to MOST, CAN network.
  • the software can be sent stored on a diskette, CD, DVD or other data storage media.

Abstract

The present invention relates to a system for communication with at least one electronic unit (2, 2’, 2’’) in a vehicle (7), which system comprises an interface unit (6) arranged to communicate with said at least on electronic unit (2, 2'’ 2'’), and at least one replaceable memory unit (9) that can be connected to the interface unit (6). The memory unit (9) comprises a protected memory area (13), which protected memory area (13) in turn comprises a unique identity and vehicle model-specific means for establishing communication with said at least one electronic unit (2, 2’, 2’’) in the vehicle (7) concerned, via the interface unit (6). The invention also relates to an interface unit and a memory unit according to the system, and a method for utilizing the system.

Description

Vehicle interface
TECHNICAL FIELD
The present invention relates to a system for communication with at least one electronic unit in a vehicle, which system comprises an interface unit arranged to communicate with said at least one electronic unit, and at least one replaceable memory unit that can be connected to the interface unit.
The present invention relates to a method for communication with at least one electronic unit in a vehicle.
BACKGROUND ART
Within the vehicle industry, microcomputers are being used to an increasing extent. The microcomputers are used to control various functions in the vehicle, for example the ignition system, air-conditioning system, steering and braking system. A number of microcomputers, so-called ECUs (Electronic Control Units), are comprised for this purpose in a number of so- called nodes, and are programmed to carry out the tasks they are intended to perform. Each node is function-related; it can, for example, comprise an ECU and a relay. Each ECU therefore comprises a memory area that is used to store the software that carries out the programming. In addition, these nodes are interconnected in one or more vehicle networks, which networks can be of any known type, for example MOST (Media Oriented Systems Transport) which is a fibre network, CAN (Control Area Network), or LIN (Local Interconnect Network) which is a simpler single-wire system, and also wireless transmission. The network or networks can, in certain cases, be co-ordinated and controlled by a central ECU, which thus functions as a communication hub in the network. In other cases, this central ECU is omitted, and the relevant ECU is addressed directly for communication via the network. For various reasons, it is important that communication can be established with the vehicle, both when any faults are to be diagnosed and when the software in one or more of the ECUs is to be replaced by new software. When any fault is detected by an ECU, which is in contact the whole time with the other nodes comprised in the vehicle network, or when a service interval is exceeded, fault codes are created that are stored in a memory in the ECU. When the fault codes exceed a certain number, which can be from one and upwards, the driver of the vehicle is given a fault indication and is recommended to contact a service workshop. In the case when new software is to be added, this may be because the previous software was faulty, or because new functions have been added. In certain cases, the vehicle's performance or characteristics can be changed by new software being added.
At a service workshop, communication with the relevant ECU is usually established via OBD (On Board Diagnostics) which comprises a physical protocol, a high-level protocol and an interface. Physical protocol means a predefined description of electrical levels, for example when a signal is to be interpreted as a one or a zero, which pulse edges are acceptable, and the like. High-level protocol means a function that decodes the meaning of the bits. Interface means the interface between the vehicle and the external equipment that is used. The high-level protocol for OBD is intended for diagnosis. OBD is common to most vehicle manufacturers at present, but certain dialectical differences can occur. There is also a further development that is designated OBD II. In order to establish this communication, certain equipment is required, preferably of the PC type, which is specific for each make of vehicle, as the vehicle manufacturer as a rule ensures that only the equipment that he supplies is compatible with the make of vehicle concerned. For reasons of security, the vehicle manufacturer usually places restrictions on how the software is handled, so that it cannot be misused. US 5541840 shows a system for diagnosing problems and updating software in a vehicle. The system comprises a main unit of PC type and a hand-held unit, which can be used together or individually.
On the basis of the above, there is therefore a handling problem with this type of vehicle service, as a small service workshop probably does not have the resources or licences that are required to buy in the equipment that is needed to handle data communication with a vehicle of a certain make, for which reason in many cases this type of service is reserved only for franchised workshops. Even greater problems arise when a small service workshop wants to handle data communication with vehicles of several different makes. For this, a licence for handling software is required from each vehicle manufacturer, and in addition the vehicle-specific equipment is required for each make, which quickly adds up to a large quantity of expensive equipment.
In particular, when software is to be updated for all instances of a certain vehicle model, for example when a systematic fault has arisen, the franchised workshops will quickly be fully booked, as all vehicles of a certain type will be recalled for updating the software.
Concerning updating software, the use of a vehicle model-specific hand-held unit, equipped with the communication protocol that is required for communication with the vehicle concerned, is currently already known. This hand-held unit thus comprises both so-called firmware, comprising a high-level protocol which is specific for the vehicle model, such as OBD or some equivalent. The software that is to be updated is supplied via a replaceable memory card, for example of the SD (Secure Digital) type, which is a currently generally-occurring form of replaceable memory which is used, among other things, for digital cameras. In this way, several different items of software can be updated for a vehicle model, for example on different occasions, by different replaceable memory cards being used that have been prepared for the purpose.
The problem concerning vehicle-specific equipment remains here, and also the handling problem connected with the vehicle manufacturer-dependent software.
DISCLOSURE OF INVENTION
An object of the present invention is to provide a secure system and a method for handling communication with at least one electronic unit in a vehicle, with the system and the method being able to be used with more than one vehicle manufacturer.
This object is achieved by a system of the type mentioned in the introduction, which system, in addition, is characterized in that the memory unit comprises a protected memory area, which protected memory area in turn comprises a unique identity and vehicle model-specific means for establishing communication with said at least one electronic unit in the vehicle concerned, via the interface unit.
This object is also achieved by a method of the type mentioned in the introduction, which method comprises, in addition, the steps of: receiving vehicle-specific software that is stored partly in an open memory module and partly in a locked memory module in a memory unit; connection of the memory unit to an interface unit; connection of the interface unit to the vehicle; introductory communication between the interface unit and the vehicle; verification that the information in the open memory module and the locked memory module is authentic by vehicle-specific information in the locked memory module being used to carry out a verification of the electronic unit of the handshaking type; and continued communication in the event of a positive verification. This object is also achieved by an interface unit and a memory unit as described above.
Preferred embodiments are described in the independent patent claims.
The present invention has a number of advantages in comparison to what has been known previously. Among other things, the following can be mentioned:
Cheaper equipment means that more small service workshops can carry out services that require communication with at least one electronic unit in a vehicle. The ability to use equipment for vehicles from more than one vehicle manufacturer results in an additional saving. Simpler handling of software provides a more versatile system for both vehicle manufacturers and service workshops. As more small service workshops are able to handle communication with at least one electronic unit in a vehicle, the vehicle owner has a larger number of service workshops that can be used when such communication is required. Increased data security.
BRIEF DESCRIPTION OF DRAWINGS
The invention will now be described in greater detail with reference to the attached drawings, in which
Figure 1 shows schematically a vehicle network;
Figure 2 shows schematically the system according to the invention; and Figure 3 shows schematically how the system according to the invention obtains data externally.
MODES FOR CARRYING OUT THE INVENTION
A number of electronic units in the form of microcomputers, so-called ECUs (Electronic Control Units) are comprised in a number of so-called nodes for controlling various functions in the vehicle, for example the ignition system, air-conditioning system, steering and braking system. Each node 1 , 1', 1" is function-related; it can, for example, like the node 1 , comprise an ECU 2 and a relay 3, as indicated in Figure 1. Other nodes 1', 1" can comprise other functional devices 3', 3" connected to respective ECUs 2', 2". Each ECU 2, 2', 2" comprises a memory area 4, 4', 4" that is used for storing the software that carries out the programming. In addition, these nodes 1 , 1 ', 1" are interconnected in a vehicle network 5, which network 5 can, for example, be any one of the previously known types: MOST, which is a fibre network, CAN or LIN, which is a simpler single-wire system.
If a need arises to communicate with the vehicle electronics, for example to update the software in one or more microcomputers 2, 2', 2", a system according to the invention is used. The system comprises, with reference also to Figure 2, an interface unit, preferably in the form of a portable unit 6 that comprises OBD (On Board Diagnostics), that is a physical protocol, a high-level protocol and an interface as described above, or any generally known variant thereof, with the communication with a vehicle 7 being established using a link 8 defined by the protocol.
The system also comprises a replaceable memory card 9 of the SD (Secure Data) type, which is a previously known type, which memory card 9 is inserted in an opening 10 in the portable unit 6 designed for the purpose, whereby contact is established in a known way between the portable unit 6 and the memory card 9. A microcomputer 11 in the portable unit 6 is arranged to handle the communication to and from the SD card 9. Such a microcomputer 11 is of a previously known type and is not described here in greater detail. A memory card 9 of the SD type comprises an open readable and writable memory module 12, and a locked memory module 13 that is only accessible by the vehicle manufacturer. The open memory module 12 is provided with a completely or partially encrypted version of the software that is to be supplied to the vehicle 7, while the locked memory module 13 is provided with a specific readable unique identity and a secret high-level protocol that is specific to the model or make of vehicle concerned. The high- level protocol makes possible communication with the vehicle 7 concerned, provided that it is a vehicle for which that high-level protocol is intended. The completely or partially encrypted software in the open memory module 12 of the SD card 9 consists of a bit string, with the encrypted part being decrypted by a secret decryption mechanism in the hardware. The software is matched with the unique identity and is sent to the vehicle 7 via, for example, the OBD protocol in the portable unit via the link 8, with the OBD's high-level protocol decoding the commands. As the software is matched with the unique identity of the SD card 9, only the relevant SD card 9, for which that software is intended, can be used. The now decoded bit string is received by one or, where appropriate, several ECUs 2 in the vehicle 7, where the transmitted commands or instructions are recognized and a handshake procedure takes place to verify the correct operation of the security mechanisms. The vehicle network 5 in Figure 2 corresponds to the vehicle network 5 in Figure 1 , with the vehicle network 5 being illustrated more schematically in Figure 2. Depending upon the purpose, one or more of the microcomputers 2, 2', 2" comprised in the network 5 are thereafter updated automatically, a process that is carried out relatively quickly, particularly if the vehicle 7 is equipped with a fast network such as the fibre optic MOST.
The handheld unit 6 is itself equipped with indication equipment 14, such as light-emitting diodes or a display, where the ongoing process can be followed. Alternatively, a handheld computer of the PDA type (not shown) can be connected to the handheld unit 6 and thereby constitute a so-called MMI (Man Machine Interface) for more complex procedures. When the communication has been established, the handheld unit 6 can also be used to read off fault codes in the vehicle 7, either in association with updating the software or separately. The SD card 9 can also be provided, where appropriate, with the software that is required for "resetting" the fault codes. In addition, the handheld unit 6 can also be provided with input devices 15, such as buttons or a touch-sensitive display, via which the user can, for example, confirm the transmission of new software or the resetting of fault codes.
The SD card 9 is provided, now with reference also to Figure 3, by the respective vehicle manufacturer 16, 17, 18 or by a representative appointed by the manufacturer, who supplies the relevant secret high-level protocol and a unique identity to the respective locked memory module 13. A service workshop 19 applies for an SD card from the respective manufacturer 16, 17, 18 or representative who, after the required authorization has been confirmed, allocates the service workshop 19 a unique user identity and an SD card 9, which SD card 9 has a unique identity that is associated with the unique user identity of the service workshop 19. When an SD card 9 is to be provided with new software, the user at the service workshop 19 logs on to the home page of the vehicle manufacturer via the Internet 21 with his unique user identity using a suitable computer 20. If all the logging-on data is correct, the user can transfer the required encrypted software to his computer 20. A read and write unit 22 for the SD card designed for the purpose is connected to the user's computer 20, using which the encrypted information obtained can, in addition, be transferred to the SD card 9. Only the SD card 9 that has the unique identity that is associated with the unique user identity via which the encrypted software has been obtained, can be used for the later decryption of software that was encrypted when communication was established with the vehicle 7 concerned. Where appropriate, in the event of extreme requirements for high security, the unique serial number for the handheld unit 6 can constitute part of the encryption/decryption procedure. In this way, even greater assurance can be achieved that it is the correct user, correct software, and correct hardware in the hands of the correct person.
The security of the system is high, as the information transmitted via the Internet 21 is completely or partially encrypted, and each encryption is unique for each user, with the user's identity being matched with the identity of the SD card 9. For example, a checksum added to the unique identity can be a constant value. If an unauthorized user should manage to access the information, it is still necessary for decryption to be carried out. When the encryption is carried out by a secret high-level protocol in combination with a unique identity that is entered into a locked memory area 13 on the SD card 9, it is well protected. Only when communication has been established with the relevant ECU 2, 2', 2" (one or more) in the vehicle 7, is the bit stream decoded, for which reason only the vehicle 7 and no other obtains the decoded software. In addition, only service workshops 19 approved by the respective vehicle manufacturers, 16, 17, 18 are provided with the ability to log on to the home page on the Internet 21 that is designed for downloading software. These approved service workshops 19 are, in addition, the only ones that obtain the requisite SD cards 9.
The SD card 9 can also be completely empty initially, with all the information being obtained via the Internet 21 prior to each loading in. Accordingly, the locked memory area 13 on the SD card 9 is automatically unlocked via a key on the vehicle manufacturer's 16, 17, 18 home page. The information in the whole memory 12, 13 of the SD card 9 is first erased. The information that is intended for the locked area 13, that is the unique identity and the secret high-level protocol, is transferred via the Internet 21 and installed in this locked area 13. Other information is transferred via the Internet 21 and installed in the open module 12 of the memory area. In this way, the service workshop 19 can have a single SD card 9 which is loaded with data via the Internet 21 before each operation, regardless of which make or model of vehicle is concerned. All the service workshop 19 needs to have is an approved user identity for each vehicle manufacturer 16, 17, 18 concerned.
An upgrading of software in a vehicle 7 can be carried out in the following way, first with reference to Figure 3:
The service workshop 19 has obtained authorization from a vehicle manufacturer 16 to handle software as described above. For this purpose, the service workshop 19 is in possession of an SD card 9 which is associated with the vehicle manufacturer's 16 vehicle model 23, and authorization to transfer encrypted software from the vehicle manufacturer's 16 home page via the Internet 21. The service workshop 19 transfers the software that is to be updated in the vehicle model 23 in encrypted form to the computer 20 of the PC type arranged at the service workshop 19 via the Internet 21. Here, the service workshop 19 logs on to the home page of the vehicle manufacturer 16 with its unique user identity with which the unique identity of the SD card 9 is associated. The encrypted software is then transferred from the PC 20 to the SD card 9 via previously known equipment 22 designed for the purpose.
The SD card 9 is then inserted, with reference to Figure 2, in the portable unit 6, which in turn is connected to the vehicle via the OBD link 8. The SD card 9 now communicates with the microcomputer 11 in the portable unit 6, which microcomputer 11 forwards the communication to an ECU 2 in the vehicle. So-called handshaking now takes place, which means that the ECU 2 accepts the communication. In the continued communication, the ECU 2 is instructed to carry out measures for updating the software in one or more nodes 1 , 1 ', 1", after which the new software is transferred.
In an alternative embodiment, all communication or at least part of the communication between the handheld unit 6 and the vehicle 7 is encrypted by a communication encryption mechanism in such a way that an outsider cannot listen to the data traffic between the handheld unit 6 and the vehicle 7. For this purpose, the communication encryption and corresponding decryption are carried out using an encryption/decryption algorithm in the secret high-level protocol and using a corresponding encryption/decryption algorithm in each ECU 2, 2', 2" concerned, with the encryption/decryption algorithm being of a self-updating kind. An example of such a encryption/decryption algorithm is so-called "rolling codes", such as for example are used when a car door or some other door, such as a garage door, is unlocked via a radio signal. The code that was used cannot be used again, and instead new codes are used the whole time. A relatively large number of codes are stored in a code list. A certain number of consecutive codes in the code list, for example ten codes, are accepted by the receiver. The transmitter can then send codes at random nine times, without being perceived by the receiver, without the system ceasing to function, as the tenth code is also accepted. When the receiver perceives a correct code that is to be found among the ten acceptable codes, the accepted code is deleted from the list. The ten consecutive codes in the code list going forward from the most recently accepted code are now the ones that are accepted.
The invention is not limited to the embodiment described above, but can be varied freely within the scope of the following patent claims. The use of the OBD described above is not necessary, but other common communication standards can be used. One alternative is to connect directly to the MOST network, whereby a faster communication is obtained than when OBD is used, as OBD utilizes the slower, relative to MOST, CAN network.
Concerning the replaceable memories of the SD card 9 type, as mentioned in the description, these can be of many other known kinds, such as a so-called memory stick, portable PC or PDA (Personal Digital Assistant). The requirement is that there is a unique identity stored and that a secure memory area is available. For increased security, the respective vehicle manufacturer 16, 17, 18 can alternatively only provide completely ready-programmed SD cards 9, whereby the facility to access software via the Internet is removed.
There are a number of other variants of how the software is to be transferred to the respective service workshop 19. For example, the software can be sent stored on a diskette, CD, DVD or other data storage media.

Claims

1. System for communication with at least one electronic unit (2, 2', 2") in a vehicle (7), which system comprises an interface unit (6) arranged to communicate with said at least one electronic unit (2, 2', 2"), and at least one replaceable memory unit (9) that can be connected to the interface unit (6), characterized in that the memory unit (9) comprises a protected memory area (13), which protected memory area (13) in turn comprises a unique identity and vehicle model-specific means for establishing communication with said at least one electronic unit (2, 2', 2") in the vehicle (7) concerned, via the interface unit (6).
2. System according to claim 1, characterized in that the memory unit comprises an open memory area (12) which in turn comprises software, which software can be communicated to the vehicle (7) concerned, via said vehicle model-specific means for establishing communication.
3. System according to any one of the preceding claims, characterized in that the interface unit (6) is separate from the vehicle and can be connected to any vehicle (7) that is arranged to communicate according to the communication standard for which the interface unit (6) is arranged.
4. System according to any one of the preceding claims, characterized in that the memory unit (9) comprises software with a unique identity and a high-level protocol, and in that an interface unit (6) comprises a physical protocol.
5. System according to any one of the preceding claims, characterized in that the communication between the interface unit
(6) and the electronic unit (2, 2', 2") is encrypted, for which purpose there are corresponding encryption/decryption algorithms in the interface unit (6) and the electronic unit (2, 2', 2") .
6. Interface unit arranged for communication with at least one electronic unit (2, 2', 2") in a vehicle (7), characterized in that the interface unit (6) further is arranged to be connected to a replaceable memory unit (9) which comprises vehicle model-specific means for establishing communication with the vehicle concerned.
7. Memory unit arranged for communication with at least one electronic unit (2, 2', 2") in a vehicle (7) via an interface unit (6), to which the memory unit (9) is arranged to be connected in such a way that it is replaceable, characterized in that the memory unit (9) comprises vehicle model- specific means for establishing communication with the vehicle (7) concerned.
8. Method for communication with at least one electronic unit (2, 2', 2") in a vehicle (7), with the electronic unit (2, 2', 2") being connected to an interface unit (6), characterized in that the method comprises the steps of: storing vehicle-specific software partly in an open memory module (12) and partly in a locked memory module (13) in a memory unit (9); connection of the memory unit (9) to the interface unit (6); introductory communication between the interface unit (6) and the electronic unit (2, 2', 2"), comprising verification that the information in the open memory module (12) and the locked memory module (13) is authentic by vehicle-specific information in the locked memory module (13) being used to carry out a verification of the electronic unit (2) of the handshaking type; and continued communication in the event of a positive verification.
9. Method according to claim 8, characterized in that the continued communication comprises transferring new software to one or more electronic units (2, 2', 2").
10. Method according to claim 8, characterized in that the continued communication comprises reading off fault codes in one or more electronic units (2, 2', 2").
11. Method according to any one of claims 8-10, characterized in that the memory unit is replaceable.
12. Method according to any one of claims 8-11, characterized in that the provision of the software is carried out via the Internet.
13. Method according to any one of claims 8-12, characterized in that the communication between the interface unit (6) and the vehicle (7) is encrypted.
14. Method according to any one of claims 8-13, characterized in that the information in one or both of the open memory module (12) and the locked memory module (13) in the memory unit (9) can be updated any number of times.
PCT/SE2005/000254 2004-02-26 2005-02-24 A system and a method for communication with an electronic unit in vehicles WO2005081650A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0400480-0 2004-02-26
SE0400480A SE0400480L (en) 2004-02-26 2004-02-26 vehicle Interface

Publications (2)

Publication Number Publication Date
WO2005081650A2 true WO2005081650A2 (en) 2005-09-09
WO2005081650A3 WO2005081650A3 (en) 2005-11-17

Family

ID=32067263

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2005/000254 WO2005081650A2 (en) 2004-02-26 2005-02-24 A system and a method for communication with an electronic unit in vehicles

Country Status (2)

Country Link
SE (1) SE0400480L (en)
WO (1) WO2005081650A2 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006120154A1 (en) * 2005-05-12 2006-11-16 Siemens Vdo Automotive Ag Method for exchanging data
WO2009037046A1 (en) * 2007-09-13 2009-03-26 Robert Bosch Gmbh Method and controller for monitoring the function of an internal combustion engine
CN106209910A (en) * 2016-08-29 2016-12-07 上海航盛实业有限公司 A kind of method for security protection of inter-vehicle information system
US11783302B2 (en) * 2020-05-07 2023-10-10 Blackberry Limited Authorization of vehicle repairs

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5365436A (en) * 1993-01-14 1994-11-15 Navistar International Transportation Corp. Electronic management system for heavy-duty trucks
US5737711A (en) * 1994-11-09 1998-04-07 Fuji Jukogyo Kabuishiki Kaisha Diagnosis system for motor vehicle
US5781125A (en) * 1995-08-12 1998-07-14 Bayerische Motoren Werke Aktiengesellschaft Arrangement for the wireless exchange of data between a servicing device and a control unit in a motor vehicle
US20020120856A1 (en) * 2000-02-25 2002-08-29 Ernst Schmidt Signature process
US20030055552A1 (en) * 2001-09-14 2003-03-20 Mark Akins Tamper detection for vehicle controller
US20030225485A1 (en) * 2002-03-23 2003-12-04 Andreas Fritz Method and apparatus for accepting data

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5365436A (en) * 1993-01-14 1994-11-15 Navistar International Transportation Corp. Electronic management system for heavy-duty trucks
US5737711A (en) * 1994-11-09 1998-04-07 Fuji Jukogyo Kabuishiki Kaisha Diagnosis system for motor vehicle
US5781125A (en) * 1995-08-12 1998-07-14 Bayerische Motoren Werke Aktiengesellschaft Arrangement for the wireless exchange of data between a servicing device and a control unit in a motor vehicle
US20020120856A1 (en) * 2000-02-25 2002-08-29 Ernst Schmidt Signature process
US20030055552A1 (en) * 2001-09-14 2003-03-20 Mark Akins Tamper detection for vehicle controller
US20030225485A1 (en) * 2002-03-23 2003-12-04 Andreas Fritz Method and apparatus for accepting data

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006120154A1 (en) * 2005-05-12 2006-11-16 Siemens Vdo Automotive Ag Method for exchanging data
WO2009037046A1 (en) * 2007-09-13 2009-03-26 Robert Bosch Gmbh Method and controller for monitoring the function of an internal combustion engine
CN106209910A (en) * 2016-08-29 2016-12-07 上海航盛实业有限公司 A kind of method for security protection of inter-vehicle information system
US11783302B2 (en) * 2020-05-07 2023-10-10 Blackberry Limited Authorization of vehicle repairs

Also Published As

Publication number Publication date
SE0400480L (en) 2005-08-27
WO2005081650A3 (en) 2005-11-17
SE0400480D0 (en) 2004-02-26

Similar Documents

Publication Publication Date Title
US8527485B2 (en) Method and system for processing information relating to a vehicle
EP1582961B1 (en) Controlling data access to electronic control units in vehicles
US9613467B2 (en) Method of updating and configuring a scan tool
US9464905B2 (en) Over-the-air vehicle systems updating and associate security protocols
US8269601B2 (en) Multiuser vehicle utilization system and electronic key thereof
US20090177352A1 (en) System and Method for Motor Vehicle Diagnosis and Vehicle Reception
US20020019877A1 (en) Method and system for transmitting data
DE19502373C2 (en) Anti-theft method for motor-driven motor vehicles
US20040148073A1 (en) Method for programming flash EEPROMS in microprocessor-equipped vehicle control electronics
US20110093639A1 (en) Secure Communications Between and Verification of Authorized CAN Devices
US20080150685A1 (en) Vehicle key for bi-directional communication with vehicle
EP2043054A1 (en) Wireless flashable remote control
EP2757497B1 (en) Vehicular electronic control device
JP2002507165A (en) Method for the initialization of a theft protection system in a car
JPH09152970A (en) Method and apparatus for programming of data to respective vehicle components
JP2004314949A (en) Portable device for changing data, and data changing device
US10803681B2 (en) Server side security preventing spoofing of vin provisioning service
US20080278282A1 (en) Motor Vehicle Control Device Data Transfer System And Process
CN102474530A (en) Method for configuring infotainment applications in motor vehicle
US8694982B2 (en) Dynamic software configuration
WO2005081650A2 (en) A system and a method for communication with an electronic unit in vehicles
CN108292452B (en) Automatic configuration of a remote technical data transmission of a motor vehicle
US8689323B2 (en) Method for activating functions of a tachograph
JP2009123226A (en) Operation system of vehicle mounting control apparatus, and vehicle mounting control apparatus
US20180137271A1 (en) Method, Server, Firewall, Control Device, and System for Programming a Control Device of a Vehicle

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 KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA 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 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

DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase