Patent Application
20060294514
The present invention is directed to automotive computers and more particularly to a system, method and computer program for broadcasting embedded code updates.
In the past years, car manufacturers have introduced more and more Information Technology into cars. More and more functions, traditionally implemented in hardware, can now be implemented with more flexibility using software programs. The engine, the brakes, the traction, the positioning system, and even the driver himself can be controlled by embedded software. A typical mid-range car has nowadays 70 or more of its functions driven by Electronic Control Units, all of them together running millions of lines of code. Bugs are one of the inherent characteristics of software. Manufacturers are under pressure to reduce the development cycle of cars. This inevitably results in insufficient testing of embedded software, and delivery of software which may still have some problems. The update and modification of embedded software is therefore more and more frequent and critical. Since software is now handling vital components, there is clearly a security exposure. This is also an exposure in term of after sales cost, because recalling large numbers of cars in order to update software under warranty is very expensive and degrades the credibility of the car manufacturer in the public's mind. Furthermore it is quite detrimental to the image of a manufacturer when cars are recalled and the recall is publicized in the public media.
In addition, car manufacturers are considering adding new optional software to cars for new added value functions. Soon it will be possible for drivers to have access to a portal managed by the car manufacturer and from this portal, to select (purchase) software options (for instance navigation functions, closest points of interest, closest hotels and restaurants, voice recognition, active cruise control, etc.), and transfer these selected software options to their car. It can also be envisioned that the success of the widely spread peer-to-peer networks, from where people download music, videos and software, will cause the emergence of peer-to-peer data networks between cars.
The consequence of the quick emergence of embedded software in cars is increasing the need for a mechanism for car manufacturers and third parties, to be able to transfer software and data to cars at any location, for example, parked, on the road, in urban areas, or in the countryside.
Today, car manufacturers still recall cars for critical software updates, and are performing “silent” updates during regular car repair and maintenance operations for minor software changes. An obvious problem with this approach is the cost:
The problem of car recall costs clearly implies a need for a software mechanism that can directly update software in cars, “in place”, without recalls.
Moreover, the process of recalling cars may become much more difficult in the near future. Car dealers will have the ability to sell cars from different car manufacturers. Car dealers flooded by software updates from many car manufacturers will not be able to orderly manage the updates. Direct communication between car manufacturers and cars is complicated when car dealers must distribute and update software. Car manufacturers are considering setting up Telematics services in order to communicate directly with cars. The problem encountered is a lack of appropriate networking infrastructure to reach cars in many various diverse locations:
The ideal solution would be a pervasive network, with a light infrastructure being inexpensive for both car manufacturers and car owners.
An object of the present invention is to download to a vehicle a more recent version of one or more embedded codes from another vehicle.
It is another object of the present invention to associate with each embedded code a code level, a Vehicle Identification Number (VIN), and a list of prerequisite hardware and software.
It is a further object of the present invention to download code by segments, in any order.
It is a further object of the present invention to concurrently download segments of a same code to different vehicles in a neighborhood in order to maximize the probability and reduce the time of obtaining complete codes.
It is a further object of the present invention to sign each segment of code with a one way hashing of the data (MD5 or SHA-1 or any similar hashing algorithm) and to encrypt the resulting hashing with the code editor private key.
According to one aspect of the invention a method for updating embedded computer programs in a vehicle is provided, the method comprises the steps of detecting and contacting one of a plurality of neighbor vehicles using wireless communication means, exchanging information with the contacted neighbor vehicle related to a plurality of computer programs embedded in the vehicle and the neighbor vehicle, requesting and retrieving from the contacted neighbor vehicle one of the plurality of computer programs based on the information previously exchanged, delivering another of the plurality of computer programs to the contacted neighbor vehicle based on the information previously exchanged, checking the validity of the delivered computer program, and installing the delivered computer program.
According to another aspect of the invention there is provided a system for updating computer programs in a vehicle comprising, means for detecting and contacting one of a plurality of neighbor vehicles using wireless communication means, means for exchanging information with the contacted neighbor vehicle related to a plurality of computer programs embedded in the vehicle and the neighbor vehicle, means for requesting and retrieving from the contacted neighbor vehicle one of the plurality of computer programs based on the information previously exchanged, means for delivering another of the plurality of computer programs to the contacted neighbor vehicle based on the information previously exchanged, means for checking the validity of the delivered computer program, and means for installing the delivered computer program.
According to yet another aspect of the invention there is provided a computer program executed on a computer system for updating embedded computer programs in a vehicle comprising the steps of detecting and contacting one of a plurality of neighbor vehicles using wireless communication means, exchanging information with the contacted neighbor vehicle related to a plurality of computer programs embedded in the vehicle and the neighbor vehicle, requesting and retrieving from the contacted neighbor vehicle one of the plurality of computer programs based on the information previously exchanged, delivering another of the plurality of computer programs to the contacted neighbor vehicle based on the information previously exchanged, checking the validity of the delivered computer program, and installing the delivered computer program.
The foregoing, together with other objects, features, and advantages of this invention can be better appreciated with reference to the following specification, claims and drawings.
The novel and inventive features believed characteristics of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative detailed embodiment when read in conjunction with the accompanying drawings, wherein:
The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the broadest scope consistent with the principles and features described herein.
Principle of the invention
Today vehicles have several embedded computers or processors, each of them executing several programs, stored as embedded software (computer program or code) in some memory in the vehicles. The objective of the present invention is to allow a first vehicle, carrying a recent version of a code, to provide other vehicles having older versions of this code with the more recent version. It is assumed that the two vehicles exchange information using point to point low range wireless communication means like Bluetooth, Infrared or any other similar wireless technology. The two vehicles can be moving, parked or blocked in traffic.
The present invention relates to the update of several embedded codes. Each code includes:
Each code is logically subdivided in a number of segments (chunks of bytes), of a reasonable and fixed size. The segmenting facilitates the transfer of large amounts of code when the communication between two vehicles cannot be maintained for a long enough period of time to transfer an entire code, of large size (several megabytes). This typically happens when the communication occurs between moving vehicles.
When two vehicles A and B establish a communication, the first message they exchange is “IOWN(Vx,Nx))”, sent from A to B and from B to A. This message comprises:
After the exchange of the IOWN messages, each vehicle is able to determine whether or not the other vehicle is carrying a more recent version of any of the codes it is carrying, and which segment(s) of code it can obtain from the other vehicle. When a vehicle determines that it can obtain one or more code segments from another vehicle, it starts a code transfer session for the selected segments of code to be obtained. The communication is peer to peer and each vehicle can act both as a server and a client for the other vehicle.
In order to prevent malicious persons from sending inappropriate or non official code to vehicles in the neighborhood, code segments are signed by the code editor. Editors are not necessarily car manufacturers. Editors can also be suppliers of car equipment, or third party providers of added value functions. The signature of a segment of code is typically a one way hashing like MD5, SHA-1 or similar code, encrypted with the private key of the editor. Segment signatures allow the car Electronic Control Units to verify both the integrity and the authenticity of each code segment received.
Code segments include a sequence number and can be downloaded in any order. The download of a given code can therefore be interrupted at any segment, and restarted either with the same vehicle or with another vehicle. Moreover the download of a given code may be performed simultaneously from several vehicles by requesting different segment numbers of a same code to each partner vehicle. This mechanism, well known in the peer to peer protocols on the Web, maximizes the probability and minimizes the time for obtaining the entire code. This is illustrated by the
Segments of code are kept in memory (buffered) until the entire code is constituted. When the code is entirely constituted, it can actually be installed on the Electronic Control Unit requiring it. Different levels of a same—incomplete—code can therefore be present in the memory buffer of a car, until a level is complete and installed. In such a circumstance, all “older” levels of the code are discarded from the buffer once a more recent level is complete and installed.
The system and method, that will be described in the following sections, is named “Automotive Network Transfer” (ANT) protocol.
Tables Used to Broadcast the Embedded Code to Other Vehicles
To broadcast embedded code to other vehicles, a vehicle needs to store a great deal of information:
Software_list Table:
A “Software_list” table 200 (
Moreover the software editor is recorded in the field “Editor” 203 to be able to retrieve when necessary the own editor's public key.
A “Prerequisite” field 204 is not fully described here, but must contain at least the Vehicle Identifier Number (VIN) to identify whether or not the code is applicable to the receiving vehicle. Although the VIN is partially structured, there are some differences between car manufacturers. Some fields of the VIN as the serial number in the year of the vehicle are replaced by wild characters to indicate that no test has to be done on this field. Prerequisite may also contain some requirements about installed features which may not be identified by the VIN in some cases, for example GPS. Other information relative to prerequisite software or software level may be set in the Prerequisite field.
The “received chunk” field 205 indicates the chunks which have been received. Its length is determined with the chunk length and the maximum size of the code to download. This value must be fixed and should be the same for all vehicles. Bit 0 of byte 0 represents the chunk 1 (first chunk) while the bit x of byte n represents the chunk(8*n+x)). Bit set to 1 indicates that the chunk has been received. If received chunk field is 128 bits in length and chunk data size is 0.5 Mbytes then the biggest code that is downloadable is 64 Mbytes.
The “Size” field 206 indicates the total size of the code.
The “Status” field 207 may take 3 different values which are “Installed”, “Installable”, when the code has been entirely received but not yet installed, or “Downloading”, all the chunks have not yet been received.
Finally, a Priority field 208, indicates the priority of the download. Fields “Software_ID”, “Version”, “Editor”, “Prereq”, “Size” and “Prty” are set by the code editor and remain unchanged during all the code broadcasting.
Chunk_list Table:
The “Chunk_list” table 210 shown in
Editor_list Table:
The “Editor_List” table shown in
Session Table and Downloadable_Software_list Table:
The tables in
The “Session” Table 300 is used to keep track of all the sessions established with other entities.
At step 401 the communication infrastructure is initialized, a server process is created to hold a request to download a program issued from the remote client and an empty session table 300 is created to record client session information.
In step 405 the vehicle is searching for an other partner:
As soon as a new partner has been detected, the physical connection handler sends a message “Partner Connected” 420 to the Session manager which sends the message IOWN 430 to the remote Session manager to give:
IOWM message comprises the “Software_list” table as a parameter. Finally the process goes into wait state 406.
When the event IOWN 410 is received from any remote session manager, a client session process 415 is launched and the session manager goes into wait state 406.
The last event handled is “Partner lost” 440 generated by the physical connection manager when the physical connection has been dropped. On receipt of this event, the session manager verifies if a Client session process exists 450 for this Connection id. If it is the case, then a “Close Session” 455 is sent to the client process in order to stop it and the resources allocated to handle this connection are freed.
Server Process
When Server process 500 is launched, it first initializes its environment 505 and goes in wait state 510 to wait for a request from a remote partner to download a new code version.
At step 520 a “GetUpdate” is received having as parameters:
Then a Lookup step 525 is performed on the Software_List table 200 to verify:
When “Session disconnect” 560 is received from a remote client session, this means that the remote client has finished the downloading of selected code. In step 565 the server process frees all resources allocated to the session and goes into wait state 510 to process the next event.
Client Process
When the Client process 600 is launched with the partner owned code status as parameter, it first initializes 605 a new entry in the “Session” table 300 and creates a new empty “Downloadable_Software_list” table 310.
Step 610 builds the list of chunks to be downloaded. Building of the Chuck list is depicted in
After building Downloadable_Software_list table 310, the first Chunk number to be downloaded is identified in step 620. In step 620 the “Downloadable_Software_list” table is scanned starting with the highest priority software and getting the first Chunk number available to be downloaded.
If a chunk is available (ready to be downloaded), the request 625 “GetChunk” is sent to the remote partner server with parameters:
Then the process goes in a wait state 645 for the next event.
if no chunk is available (ready to be downloaded), a message “Session disconnect” 630 is sent to the remote partner server and the resources allocated to the session are released in step 635. The Downloadable_Software_list table belonging to the session is destroyed and the entry corresponding to the client instance in the session table 300 is removed.
Finally the process ends in step 640.
At Step 690, the received message indicates that the requested Chunk number is not available, so the Chunk number is marked unavailable 695 in “Downloadable_Softaware_list” table 310 by turning off the bit corresponding to the Chunk number Cx. Then the process continues at step 620 (described above).
At step 650, the received message indicates the reception of the requested chunk. Checking is done at step 655 against “Software_list” table 200 to verify that the Chunk number has not already been received.
One way hashing is compared at step 665 to the hashing extracted from the signature (Csig) sent by the partner server. Signature (Csig) is decrypted using “Public key” 222 of “Editor_List” table 220 indexed by the received code identification Vx.
If both hashings do not match, then the chunk is discarded at step 675. Then the process continues with step 620.
If both hashings match, the chunk is valid. At step 670:
The process continues with step 620.
At step 680 the “Close session” message indicates that the physical connection with the partner has been lost:
At step 640 the process ends.
The procedure used to build the list of chunks (Dowloadable_Sotware_list table) to download is described herein below. This method is illustrated in
The list of codes owned by the server and received in IOWN message 410 is recorded in a temporary table named server code table
The process is launched at step 700.
At step 705 a scanning of the server code table is initialized.
At step 710 the next server code entry is selected.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood that various changes in form and detail may be made therein without departing from the spirit, and scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 05300506.2 | Jun 2005 | EP | regional |
