US20140058532A1 - Method for partial flashing of ecus - Google Patents
Method for partial flashing of ecus Download PDFInfo
- Publication number
- US20140058532A1 US20140058532A1 US13/593,093 US201213593093A US2014058532A1 US 20140058532 A1 US20140058532 A1 US 20140058532A1 US 201213593093 A US201213593093 A US 201213593093A US 2014058532 A1 US2014058532 A1 US 2014058532A1
- Authority
- US
- United States
- Prior art keywords
- memory
- code
- compartments
- reprogrammed
- defining
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0426—Programming the control sequence
Definitions
- This invention relates generally to a system and method for programming or flashing a controller and, more particularly, to a system and method for programming or flashing an electronic control unit (ECU) on a vehicle, where the method includes providing partial flashing of the code by defining compartments for code sections as separate memory segments including empty spaces and only flashing those compartments that need to be reprogrammed.
- ECU electronice control unit
- ECUs electronice control units
- controllers which control the operation of vehicle systems, such as the powertrain, climate control system, infotainment system, body systems, chassis systems, and others.
- Flashing is a well known process for uploading or programming software applications, calibration files and other content into the memory of a vehicle ECU or other programmable device.
- a bootloader is an embedded software program loaded on the ECU that provides an interface between the ECU and a computer device for uploading the software.
- the bootloader may employ asymmetric key cryptography and store a public key that must be used to decode the digital signature transferred by the computer device before uploading to or reflashing of the ECU is allowed to prevent malicious software or calibration files from being uploaded into the ECU.
- one application file may access another application file
- a variable stored in a RAM of the ECU may be used in various application files in the ECU, etc., making a change at one location in the code may require changes at one or more other locations in the code.
- the memory in vehicle ECUs is configured so that if a minor portion of one of the files needs to be corrected or data needs to added, that change may cause the position of other files or portions of code within the memory to be changed, which alters the entire code sequence in a cascading manner. Therefore, it is generally necessary to reflash the entire code in the memory even if only a small change to the code needs to be made. Reflashing the entire ECU memory may take a few minutes, where the actual change being made might only need a few seconds of programming time. For example, the programming tool that flashes the ECU memory is often connected to a vehicle's CAN bus to provide the programming and that CAN bus typically does not operate at high speed.
- a system and method are disclosed for compartmentalizing memory sections in a controller for each of the various types of digital files, where the compartments include empty memory space for additional code to be added to allow the compartments to be individually reprogrammed without affecting other memory content.
- the method includes defining a main memory in the controller that stores a plurality of different types of memory content that each include lines of code, where the main memory includes compartments having memory slots for lines of code that have been programmed and empty memory slots where lines of codes can be written into.
- the main memory is initially programmed to store desired memory content in the memory compartments.
- the reprogramming is performed to flash only the memory compartments that include the code that needs to be reprogrammed and those memory compartments that include code that is linked to the code that needs to be reprogrammed.
- FIG. 1 is a block diagram of a method for signing and verifying electronic content using a digital signature including the delivery of content and signature files from a programming source to an executing controller;
- FIG. 2 is a schematic diagram showing how electronic content and a digital signature are physically delivered to a controller in a vehicle;
- FIG. 3 is a representation of a portion of a known ECU memory including memory space for various types of files
- FIG. 4 is a representation of a portion of a known ECU RAM
- FIG. 5 is a representation of a portion of an ECU memory showing memory sections for different types of files and compartments that include a particular file and additional memory space;
- FIG. 6 is a representation of an ECU RAM including several variables where the variables are defined in compartments including extra memory space.
- asymmetric key cryptography uses digital signatures for authenticating files that are programmed into controllers.
- asymmetric key cryptography uses a pair of mathematically-related keys, known as a private key and a public key, to encrypt and decrypt a message.
- a signer uses his private key, which is known only to himself, to encrypt a message.
- the digital signature can later be decrypted by another party using the public key, which is paired to the signer's private key.
- FIG. 1 is a block diagram 40 showing a method for signing and verifying digital content using a digital signature typical for programming a vehicle ECU, including the delivery of content and signature files from a programming source to an executing controller.
- a file repository 42 creates files, collectively referred to herein as content file 44 , where the content file 44 is a binary file. It is desired to obtain a digital signature 46 for the content file 44 .
- the content file 44 is provided to a signing server 48 .
- a hash calculation is performed on the content file 44 to produce a hash code 52 .
- the hash code 52 is encrypted using the private key of the repository 42 , where the encryption produces the digital signature 46 .
- the digital signature 46 is then provided back to the repository 42 .
- FIG. 1 shows a manufacturing database 56 used by the auto manufacturer's manufacturing department for managing electronic files which are installed as “parts” in production vehicles.
- FIG. 1 likewise shows a service database 62 , used by the auto manufacturer's service department for managing electronic files which are installed as “service parts” in vehicles that are worked on in a service facility.
- the manufacturing database 56 and the service database 62 both receive copies of the content file 44 and the digital signature 46 to be used for the respective functions of the manufacturing and service departments.
- a programming tool 68 In order to actually install the content file 44 on a controller in a vehicle, a programming tool 68 is used. As shown, the programming tool 68 also receives a copy of the content file 44 and the digital signature 46 . That is, the manufacturing department could provide the content file 44 and the digital signature 46 from the manufacturing database 56 to the programming tool 68 for installation on a new production vehicle, or the service department could provide the content file 44 and the digital signature 46 from the service database 62 to the programming tool 68 for installation on a vehicle being serviced.
- the next step is for the programming tool 68 to install the content file 44 on a controller in a vehicle.
- ECU 74 is the controller that will actually use the content file 44 .
- the software on the ECU 74 consists of a bootloader, a software executable, calibration files, etc.
- the ECU 74 is assumed to have a single central processing unit (CPU). In actual vehicles, the ECU 74 could have multi-core CPUs, and each multi-core CPU would have a bootloader, a software executable, and one or more calibration files.
- the bootloader in the ECU 74 is responsible for validating and installing new software executables and calibration files. Thus, the functions described in this paragraph are performed by the bootloader in the ECU 74 .
- the programming tool 68 provides the content file 44 and the digital signature 46 to the ECU 74 .
- the digital signature 46 is decrypted by the bootloader using the public key of the repository 42 to produce a decrypted hash code 78 . Meanwhile, a hash calculation is performed on the content file 44 by the bootloader to produce a calculated hash code 84 .
- the decrypted hash code 78 is compared to the calculated hash code 84 .
- the decrypted hash code 78 matches the calculated hash code 84 , then a valid determination 88 is issued, and the content file 44 is used. If the content file 44 to be used is a software executable, the bootloader installs it as the new software executable on the ECU 74 . If the content file 44 to be used is a calibration file, the bootloader installs it as one of the one or more calibration files on the ECU 74 . If the decrypted hash code 78 does not match the calculated hash code 84 , then an invalid determination 86 is issued, and the content file 44 is not used on the ECU 74 .
- FIG. 2 is a schematic diagram showing how electronic content and digital signature files are physically delivered to a vehicle controller.
- a vehicle 36 includes the ECU 74 shown in FIG. 1 and discussed above.
- the ECU 74 could control the engine, transmission, chassis, body, infotainment, or other system on the vehicle 36 .
- the content file 44 and the digital signature 46 are provided to a central database, shown here as the manufacturing database 56 .
- the transfer of the content file 44 and the digital signature 46 to the manufacturing database 56 could take place over a company network.
- the manufacturing database 56 provides the content file 44 and the digital signature 46 to the programming tool 68 , where this transfer could be accomplished by attaching the programming tool 68 to a computer which has access to the database 56 .
- the programming tool 68 communicates with the ECU 74 via a connection 38 , which may be wired or wireless. Alternately, the programming tool 68 may need to access the ECU 74 through a network of ECUs, such as through a gateway ECU. With the connection 38 established, the content file 44 and the digital signature 46 can be downloaded from the programming tool 68 to the ECU 74 , where the bootloader can perform the security verification functions discussed previously.
- FIG. 3 is a representation of a known ECU memory 10 showing various memory slots or segments for storing different types of files that are uploaded or flashed in the memory 10 , such as, for example, in the manner discussed above.
- the memory 10 includes lines of code for the bootloader in memory segment 12 , lines of code for RO data constants in memory segment 14 , lines of application code in memory segment 16 for different and various applications, operating system (OS) code stored in memory segment 18 , and calibration files stored in memory segment 20 .
- OS operating system
- RO data constants may need to be added to the RO data constant segment 14 , for example, represented by dotted box 28 , which may change the address of the constants in the memory segment 14 below the lines of code in the dotted box 28 .
- lines of code in the application segment 16 such as those again represented by the dotted box 24 , that previously needed to address the RO data constants that have changed, will now not be able to do so.
- FIG. 4 is a representation of a known ECU RAM 30 including a memory segment 32 for storing certain variables that are addressed by the application segment 16 , and which are stored in the RAM 30 because they may change as the operating conditions of the vehicle change.
- the variables stored in the RAM 30 are those variables that change as the vehicle operates and can be, for example, pressures, temperatures, state of applications, etc. In other words, any value that changes during operation of the vehicle is stored in the RAM 30 , and all other constants and values that do not change are stored in the main memory 10 . If a new variable needs to be stored in the memory segment 32 , such as represented by dotted box 34 , then the position of those variables in the memory segment 32 below the box 34 will be changed, represented by dotted box 36 .
- the present invention proposes a programming or differential flashing scheme for overcoming the short-comings discussed above so that individual portions of code can be reflashed in an ECU memory without having to reflash the entire code stored in the ECU memory.
- the present invention compartmentalizes different sections of the code stored in the ECU memory, such as the RO data constants, the application code, the OS code, calibration files, etc.
- code as used herein usually will refer to “read-only” data and typically not modifiable data, such as variables in RAM.
- Each compartment for each separate memory portion may include empty memory sections available to write additional code into so that if a particular section is expanded during the reflash, those empty sections can be used for that expansion.
- Each compartment will be assigned a specific amount of digital memory and that compartment for a particular file will be larger than is necessary for the file to be written into. Compartmentalizing the code into separate sections including extra memory space not only allows those compartments that need to be changed to be separately reflashed, but also the compartments for the other files that may be linked to that portion of the reflashed code to be reflashed.
- the ECUs being discussed herein are single version devices having a single ID. It is also noted that when the code is reflashed and some of the empty memory sections may be filled, future reflashing can occur until all of the empty memory sections are filled. Further, the flashing tool needs to maintain a table of what sectors in the memory have been flashed by previous software versions when the flashing tool goes from one version of a particular software to another version of a particular software.
- each of the separate compartments may require its own digital signature. Alternately, a single digital signature may be used for all of the compartments that may be reflashed at a particular point in time.
- FIG. 5 is a representation of a main memory 90 in an ECU and FIG. 6 is a representation of a RAM 92 in the ECU.
- the bootloader is stored at memory section 94 and is followed by an empty memory section 96 where code is not initially stored to allow for additional lines of code to be stored if the bootloader 94 needs to be expanded.
- Following the bootloader is a series of three RO data constant files, where one of the RO data constant files is represented by memory section 98 followed by an empty memory section 100 , where code is not initially stored in the memory section 100 to allow the particular RO data file to be expanded.
- a first combination of an RO data file and its empty memory section is defined by compartment 102 .
- the RO data files Following the RO data files are three application files, where one of the application files is represented by memory section 106 followed by an empty memory section 108 where code is not initially stored.
- the first application file and its empty memory section are defined by compartment 110 and the third application file and its empty memory section are defined by compartment 112 . Only a portion of the empty memory section following the third application file is within the compartment 112 .
- an OS code file represented by memory section 116 and including an empty memory section 118 where code is not initially stored.
- calibration files represented by memory section 120 and including empty memory section 122 for additional lines of code where code is not initially stored.
- the RAM 92 includes memory sections 126 , 128 and 130 identifying three variables stored in the RAM 92 .
- Memory section 134 following section 126 , memory section 136 following memory section 128 and memory section 138 following memory section 130 are all open memory space where other variables can be added between the existing variables in the RAM 92 .
- Compartment 140 defines a combined memory section for another variable and open memory space below that variable. It is noted that a compartment in the RAM 92 may include more than one variable.
- the changes to the first application file in the dotted box 150 also required new RO constants to be added, which are stored in the first RO data file within the compartment 102 as represented by dotted box 154 .
- Changing the constants in this file required some of the open memory space for that data file to be used within the dotted box 154 . Therefore, as above, the code within the compartment 102 needs to be reflashed. Because the section of the third application file within the dotted box 152 was changed and it required using the fourth variable file in the RAM 92 , then the variable in dotted box 142 needs to be changed and therefore the compartment 140 needs to be reflashed.
- FIGS. 5 and 6 only shows that those particular lines of code affected by the example have been compartmentalized. However, this is shown only for purposes of clarity in that all, or almost all, of the sections of code in the memory 90 and the RAM 92 will be defined within a compartment and those specific compartments that are affected by a particular change needed to be made to the code will only be the ones affected by the reflashing.
Abstract
Description
- 1. Field of the Invention
- This invention relates generally to a system and method for programming or flashing a controller and, more particularly, to a system and method for programming or flashing an electronic control unit (ECU) on a vehicle, where the method includes providing partial flashing of the code by defining compartments for code sections as separate memory segments including empty spaces and only flashing those compartments that need to be reprogrammed.
- 2. Discussion of the Related Art
- Most modern vehicles include electronic control units (ECUs), or controllers, which control the operation of vehicle systems, such as the powertrain, climate control system, infotainment system, body systems, chassis systems, and others. Such controllers require special purpose-designed software in order to perform the control functions. Flashing is a well known process for uploading or programming software applications, calibration files and other content into the memory of a vehicle ECU or other programmable device. A bootloader is an embedded software program loaded on the ECU that provides an interface between the ECU and a computer device for uploading the software. The bootloader may employ asymmetric key cryptography and store a public key that must be used to decode the digital signature transferred by the computer device before uploading to or reflashing of the ECU is allowed to prevent malicious software or calibration files from being uploaded into the ECU.
- After the ECU has initially been programmed on a vehicle, it may become necessary to modify or change certain parts of the code that has been uploaded, such as changing variables, adding data, making corrections to application files, etc. For example, at the end of the vehicle production line after the ECUs have been flashed, quality control may observe minor problems or errors with the code that need to be corrected, which may only require small changes to the code. Also, there may be certain security vulnerabilities in the code, which may cause buffer memory overflow for certain input conditions or the code may be susceptible to hacking. Such a security vulnerability may need to be corrected, which also may only require a small change to the code. For example, a line of code may require an “if” condition to prevent a buffer overflow. Because the various types of files in the ECU are often connected, for example, one application file may access another application file, a variable stored in a RAM of the ECU may be used in various application files in the ECU, etc., making a change at one location in the code may require changes at one or more other locations in the code.
- The memory in vehicle ECUs is configured so that if a minor portion of one of the files needs to be corrected or data needs to added, that change may cause the position of other files or portions of code within the memory to be changed, which alters the entire code sequence in a cascading manner. Therefore, it is generally necessary to reflash the entire code in the memory even if only a small change to the code needs to be made. Reflashing the entire ECU memory may take a few minutes, where the actual change being made might only need a few seconds of programming time. For example, the programming tool that flashes the ECU memory is often connected to a vehicle's CAN bus to provide the programming and that CAN bus typically does not operate at high speed.
- In accordance with the teachings of the present invention, a system and method are disclosed for compartmentalizing memory sections in a controller for each of the various types of digital files, where the compartments include empty memory space for additional code to be added to allow the compartments to be individually reprogrammed without affecting other memory content. The method includes defining a main memory in the controller that stores a plurality of different types of memory content that each include lines of code, where the main memory includes compartments having memory slots for lines of code that have been programmed and empty memory slots where lines of codes can be written into. The main memory is initially programmed to store desired memory content in the memory compartments. Subsequently, if it is determined that code stored in the main memory needs to be reprogrammed, the reprogramming is performed to flash only the memory compartments that include the code that needs to be reprogrammed and those memory compartments that include code that is linked to the code that needs to be reprogrammed.
- Additional features of the present invention will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings.
-
FIG. 1 is a block diagram of a method for signing and verifying electronic content using a digital signature including the delivery of content and signature files from a programming source to an executing controller; -
FIG. 2 is a schematic diagram showing how electronic content and a digital signature are physically delivered to a controller in a vehicle; -
FIG. 3 is a representation of a portion of a known ECU memory including memory space for various types of files; -
FIG. 4 is a representation of a portion of a known ECU RAM; -
FIG. 5 is a representation of a portion of an ECU memory showing memory sections for different types of files and compartments that include a particular file and additional memory space; and -
FIG. 6 is a representation of an ECU RAM including several variables where the variables are defined in compartments including extra memory space. - The following discussion of the embodiments of the invention directed to a system and method for compartmentalizing memory space in an ECU to allow for partial reflashing of the ECU is merely exemplary in nature, and is in no way intended to limit the invention or its applications or uses. For example, the discussion herein is specific to a vehicle ECU. However, as will be appreciated by those skilled in the art, the system and method of the invention may have application for other types of controllers.
- Vehicle ECUs need to be programmed in a secure manner to prevent malicious hacking. One known secure digital coding technique is referred to as asymmetric key cryptography that uses digital signatures for authenticating files that are programmed into controllers. As would be well understood by those skilled in the art, asymmetric key cryptography uses a pair of mathematically-related keys, known as a private key and a public key, to encrypt and decrypt a message. To create a digital signature, a signer uses his private key, which is known only to himself, to encrypt a message. The digital signature can later be decrypted by another party using the public key, which is paired to the signer's private key.
-
FIG. 1 is a block diagram 40 showing a method for signing and verifying digital content using a digital signature typical for programming a vehicle ECU, including the delivery of content and signature files from a programming source to an executing controller. Afile repository 42 creates files, collectively referred to herein ascontent file 44, where thecontent file 44 is a binary file. It is desired to obtain adigital signature 46 for thecontent file 44. In order for thecontent file 44 to be digitally signed, thecontent file 44 is provided to asigning server 48. On thesigning server 48, a hash calculation is performed on thecontent file 44 to produce ahash code 52. Thehash code 52 is encrypted using the private key of therepository 42, where the encryption produces thedigital signature 46. Thedigital signature 46 is then provided back to therepository 42. - At this point, the
content file 44 and thedigital signature 46 both exist in therepository 42. The challenge is then to deliver thecontent file 44 and thedigital signature 46 through the various business systems used by the automotive manufacturer and install and validate thecontent file 44 on a controller in a vehicle. In general, an automotive manufacturer will have at least two organizations or departments responsible for installing software and calibration files on controllers in vehicles, namely, manufacturing and service.FIG. 1 shows amanufacturing database 56 used by the auto manufacturer's manufacturing department for managing electronic files which are installed as “parts” in production vehicles.FIG. 1 likewise shows aservice database 62, used by the auto manufacturer's service department for managing electronic files which are installed as “service parts” in vehicles that are worked on in a service facility. As shown inFIG. 1 , themanufacturing database 56 and theservice database 62 both receive copies of thecontent file 44 and thedigital signature 46 to be used for the respective functions of the manufacturing and service departments. - In order to actually install the
content file 44 on a controller in a vehicle, aprogramming tool 68 is used. As shown, theprogramming tool 68 also receives a copy of thecontent file 44 and thedigital signature 46. That is, the manufacturing department could provide thecontent file 44 and thedigital signature 46 from themanufacturing database 56 to theprogramming tool 68 for installation on a new production vehicle, or the service department could provide thecontent file 44 and thedigital signature 46 from theservice database 62 to theprogramming tool 68 for installation on a vehicle being serviced. - The next step is for the
programming tool 68 to install thecontent file 44 on a controller in a vehicle. ECU 74 is the controller that will actually use thecontent file 44. Following is a brief discussion of the architecture of the ECU 74. The software on the ECU 74 consists of a bootloader, a software executable, calibration files, etc. For the purposes of this discussion, theECU 74 is assumed to have a single central processing unit (CPU). In actual vehicles, the ECU 74 could have multi-core CPUs, and each multi-core CPU would have a bootloader, a software executable, and one or more calibration files. - The bootloader in the
ECU 74 is responsible for validating and installing new software executables and calibration files. Thus, the functions described in this paragraph are performed by the bootloader in theECU 74. Theprogramming tool 68 provides thecontent file 44 and thedigital signature 46 to theECU 74. Thedigital signature 46 is decrypted by the bootloader using the public key of therepository 42 to produce a decryptedhash code 78. Meanwhile, a hash calculation is performed on thecontent file 44 by the bootloader to produce acalculated hash code 84. Atbox 80, the decryptedhash code 78 is compared to thecalculated hash code 84. If the decryptedhash code 78 matches thecalculated hash code 84, then avalid determination 88 is issued, and thecontent file 44 is used. If thecontent file 44 to be used is a software executable, the bootloader installs it as the new software executable on theECU 74. If thecontent file 44 to be used is a calibration file, the bootloader installs it as one of the one or more calibration files on theECU 74. If the decryptedhash code 78 does not match thecalculated hash code 84, then aninvalid determination 86 is issued, and thecontent file 44 is not used on theECU 74. -
FIG. 2 is a schematic diagram showing how electronic content and digital signature files are physically delivered to a vehicle controller. Avehicle 36 includes theECU 74 shown inFIG. 1 and discussed above. TheECU 74 could control the engine, transmission, chassis, body, infotainment, or other system on thevehicle 36. Thecontent file 44 and thedigital signature 46 are provided to a central database, shown here as themanufacturing database 56. The transfer of thecontent file 44 and thedigital signature 46 to themanufacturing database 56 could take place over a company network. Themanufacturing database 56 provides thecontent file 44 and thedigital signature 46 to theprogramming tool 68, where this transfer could be accomplished by attaching theprogramming tool 68 to a computer which has access to thedatabase 56. Theprogramming tool 68 communicates with theECU 74 via aconnection 38, which may be wired or wireless. Alternately, theprogramming tool 68 may need to access theECU 74 through a network of ECUs, such as through a gateway ECU. With theconnection 38 established, thecontent file 44 and thedigital signature 46 can be downloaded from theprogramming tool 68 to theECU 74, where the bootloader can perform the security verification functions discussed previously. -
FIG. 3 is a representation of a knownECU memory 10 showing various memory slots or segments for storing different types of files that are uploaded or flashed in thememory 10, such as, for example, in the manner discussed above. When the code to be flashed is built, lines of code are first compiled, and then the lines of code are linked to each other in the various files as is necessary to operate the code. Thememory 10 includes lines of code for the bootloader inmemory segment 12, lines of code for RO data constants inmemory segment 14, lines of application code inmemory segment 16 for different and various applications, operating system (OS) code stored inmemory segment 18, and calibration files stored inmemory segment 20. - If the application code stored in the
segment 16 needs to be corrected or changed, such as for the reasons discussed above, and lines of code need to be added and/or replaced, represented by dottedbox 22, all of the lines of code in thesegment 16 below thebox 22 are moved down, represented by dottedbox 24, which changes their address defining their location in thememory 10. For those sections of code in thememory 10 that previously accessed the lines of the code in thebox 24, such as code represented by dottedbox 26, that code is now unable to access the changed code because it has a different address. Further, RO data constants may need to be added to the RO dataconstant segment 14, for example, represented by dottedbox 28, which may change the address of the constants in thememory segment 14 below the lines of code in the dottedbox 28. Thus, lines of code in theapplication segment 16, such as those again represented by the dottedbox 24, that previously needed to address the RO data constants that have changed, will now not be able to do so. -
FIG. 4 is a representation of a knownECU RAM 30 including amemory segment 32 for storing certain variables that are addressed by theapplication segment 16, and which are stored in theRAM 30 because they may change as the operating conditions of the vehicle change. Particularly, the variables stored in theRAM 30 are those variables that change as the vehicle operates and can be, for example, pressures, temperatures, state of applications, etc. In other words, any value that changes during operation of the vehicle is stored in theRAM 30, and all other constants and values that do not change are stored in themain memory 10. If a new variable needs to be stored in thememory segment 32, such as represented by dottedbox 34, then the position of those variables in thememory segment 32 below thebox 34 will be changed, represented by dottedbox 36. Therefore, those lines of code in theapplication memory segment 16, for example, also represented by the dottedbox 24 that previously needed to access the variables in the dottedbox 36 will not be able to do so because the addresses of those variables have now been changed. Thus, whenever a small change to thememory 10 or theRAM 30 is required, those changes have a cascading affect on other parts of the code stored in thememory 10, which requires that theentire memory 10, except the bootloader, be reflashed for these minor changes, as discussed above. - The present invention proposes a programming or differential flashing scheme for overcoming the short-comings discussed above so that individual portions of code can be reflashed in an ECU memory without having to reflash the entire code stored in the ECU memory. As will be discussed in detail below, the present invention compartmentalizes different sections of the code stored in the ECU memory, such as the RO data constants, the application code, the OS code, calibration files, etc. It is noted that the term “code” as used herein usually will refer to “read-only” data and typically not modifiable data, such as variables in RAM. Each compartment for each separate memory portion may include empty memory sections available to write additional code into so that if a particular section is expanded during the reflash, those empty sections can be used for that expansion. This includes both the constants that are stored in the main memory of the ECU and the variables that are stored in the ECU RAM. Each compartment will be assigned a specific amount of digital memory and that compartment for a particular file will be larger than is necessary for the file to be written into. Compartmentalizing the code into separate sections including extra memory space not only allows those compartments that need to be changed to be separately reflashed, but also the compartments for the other files that may be linked to that portion of the reflashed code to be reflashed.
- Those sections of code in the main memory of the ECU that are linked to variables stored in the RAM will be linked to a specific compartment in the RAM so that the code for the application that accesses the variable can be selectively changed to change both the code and the variables. If variables are added to the RAM, that portion of the application file that accesses the variables would be reflashed for the new order of the variables. Alternately, dummy variables that are not used can be placed in certain sections of available memory space in the RAM that are not accessed by the application codes, but can be overwritten with a usable variable if necessary.
- It is noted that the ECUs being discussed herein are single version devices having a single ID. It is also noted that when the code is reflashed and some of the empty memory sections may be filled, future reflashing can occur until all of the empty memory sections are filled. Further, the flashing tool needs to maintain a table of what sectors in the memory have been flashed by previous software versions when the flashing tool goes from one version of a particular software to another version of a particular software.
- It is further noted that the discussion above concerning secure asymmetric key cryptography flashing may or may not be employed in the technique for differential flashing discussed herein. If digital signature encryption is used in the differential flashing discussed herein, then each of the separate compartments may require its own digital signature. Alternately, a single digital signature may be used for all of the compartments that may be reflashed at a particular point in time.
-
FIG. 5 is a representation of amain memory 90 in an ECU andFIG. 6 is a representation of aRAM 92 in the ECU. In this representation of theECU memory 90, the bootloader is stored atmemory section 94 and is followed by anempty memory section 96 where code is not initially stored to allow for additional lines of code to be stored if thebootloader 94 needs to be expanded. Following the bootloader is a series of three RO data constant files, where one of the RO data constant files is represented bymemory section 98 followed by anempty memory section 100, where code is not initially stored in thememory section 100 to allow the particular RO data file to be expanded. A first combination of an RO data file and its empty memory section is defined bycompartment 102. Following the RO data files are three application files, where one of the application files is represented bymemory section 106 followed by anempty memory section 108 where code is not initially stored. The first application file and its empty memory section are defined bycompartment 110 and the third application file and its empty memory section are defined bycompartment 112. Only a portion of the empty memory section following the third application file is within thecompartment 112. Following the application files is an OS code file represented bymemory section 116 and including anempty memory section 118 where code is not initially stored. Following the OS code memory section are calibration files represented bymemory section 120 and includingempty memory section 122 for additional lines of code where code is not initially stored. - The
RAM 92 includesmemory sections RAM 92.Memory section 134 followingsection 126,memory section 136 followingmemory section 128 andmemory section 138 followingmemory section 130 are all open memory space where other variables can be added between the existing variables in theRAM 92.Compartment 140 defines a combined memory section for another variable and open memory space below that variable. It is noted that a compartment in theRAM 92 may include more than one variable. - The discussion above of how the invention compartmentalizes different sections of code, where only certain compartments will typically need to be reflashed when a particular change to the code is made can be shown by example. For this example, it has been determined that it is necessary to make changes to the first application file that was initially written in the
compartment 110 as identified by the lines of code in dottedbox 150. Theentire compartment 110 would need to be reflashed to make this modification, which in this example requires using some of the open memory space. As a result of this change to the first application file, a section of the code in the third application file represented bydotted box 152 is affected because that section of code used information that was previously stored in the first application file, which has now been changed. Therefore, the entire section of code in thecompartment 112 needs to be reflashed. Further, the changes to the first application file in the dottedbox 150 also required new RO constants to be added, which are stored in the first RO data file within thecompartment 102 as represented bydotted box 154. Changing the constants in this file required some of the open memory space for that data file to be used within the dottedbox 154. Therefore, as above, the code within thecompartment 102 needs to be reflashed. Because the section of the third application file within the dottedbox 152 was changed and it required using the fourth variable file in theRAM 92, then the variable indotted box 142 needs to be changed and therefore thecompartment 140 needs to be reflashed. - The illustration of the example discussed above for
FIGS. 5 and 6 only shows that those particular lines of code affected by the example have been compartmentalized. However, this is shown only for purposes of clarity in that all, or almost all, of the sections of code in thememory 90 and theRAM 92 will be defined within a compartment and those specific compartments that are affected by a particular change needed to be made to the code will only be the ones affected by the reflashing. - As will be well understood by those skilled in the art, the several and various steps and processes discussed herein to describe the invention may be referring to operations performed by a computer, a processor or other electronic calculating device that manipulate and/or transform data using electrical phenomenon. Those computers and electronic devices may employ various volatile and/or non-volatile memories including non-transitory computer-readable medium with an executable program stored thereon including various code or executable instructions able to be performed by the computer or processor, where the memory and/or computer-readable medium may include all forms and types of memory and other computer-readable media.
- The foregoing discussion disclosed and describes merely exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion and from the accompanying drawings and claims that various changes, modifications and variations can be made therein without departing from the spirit and scope of the invention as defined in the following claims.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/593,093 US20140058532A1 (en) | 2012-08-23 | 2012-08-23 | Method for partial flashing of ecus |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/593,093 US20140058532A1 (en) | 2012-08-23 | 2012-08-23 | Method for partial flashing of ecus |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140058532A1 true US20140058532A1 (en) | 2014-02-27 |
Family
ID=50148711
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/593,093 Abandoned US20140058532A1 (en) | 2012-08-23 | 2012-08-23 | Method for partial flashing of ecus |
Country Status (1)
Country | Link |
---|---|
US (1) | US20140058532A1 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140136826A1 (en) * | 2012-11-13 | 2014-05-15 | Electronics & Telecommunications Research Institute | Method and apparatus for updating boot loader |
WO2016087585A1 (en) * | 2014-12-05 | 2016-06-09 | Schneider Electric Automation Gmbh | Method for programming and configuring a device in a traceable manner |
DE102016221108A1 (en) * | 2016-10-26 | 2018-04-26 | Volkswagen Aktiengesellschaft | A method for updating software of a control device of a vehicle |
WO2021032132A1 (en) * | 2019-08-20 | 2021-02-25 | 华为技术有限公司 | Security protection method and device for vehicle-mounted system |
CN112748711A (en) * | 2019-10-30 | 2021-05-04 | 惠州比亚迪电池有限公司 | ECU data flashing method, device and system |
WO2021181828A1 (en) * | 2020-03-10 | 2021-09-16 | 日立Astemo株式会社 | Vehicle control device and vehicle control system |
FR3108742A1 (en) | 2020-03-30 | 2021-10-01 | Renault S.A.S | Devices and method for controlling electronic control units of a motor vehicle |
US20220019668A1 (en) * | 2020-07-14 | 2022-01-20 | Graphcore Limited | Hardware Autoloader |
US20220038905A1 (en) * | 2020-07-28 | 2022-02-03 | Subaru Corporation | Vehicle communication processor, vehicle communication control method and vehicle |
Citations (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5787367A (en) * | 1996-07-03 | 1998-07-28 | Chrysler Corporation | Flash reprogramming security for vehicle computer |
US5854937A (en) * | 1994-04-06 | 1998-12-29 | Dell U.S.A., L.P. | Method for reprogramming flash ROM in a personal computer implementing an EISA bus system |
US5857158A (en) * | 1993-12-29 | 1999-01-05 | Robert Bosch Gmbh | Control unit and device for programming it |
US6009372A (en) * | 1997-10-01 | 1999-12-28 | Cummins Engine Company, Inc. | Management of programming and memory space for an internal combustion engine control system |
US20020077739A1 (en) * | 2000-08-14 | 2002-06-20 | Brett Augsburger | Enhanced module chipping system |
US20020169524A1 (en) * | 2001-05-09 | 2002-11-14 | Mitsubishi Denki Kabushiki Kaisha | On-vehicle electronic controller |
US6493271B2 (en) * | 1992-03-17 | 2002-12-10 | Hitachi, Ltd. | Data line disturbance free memory block divided flash memory and microcomputer having flash memory therein |
US6505105B2 (en) * | 2001-01-05 | 2003-01-07 | Delphi Technologies, Inc. | Electronic control unit calibration |
US20040049669A1 (en) * | 2002-09-09 | 2004-03-11 | Schelling Todd A. | Firmware architecture supporting safe updates and multiple processor types |
US20040249558A1 (en) * | 2003-06-06 | 2004-12-09 | John Meaney | System and method for real time programmability of an engine control unit |
US6957296B2 (en) * | 1996-09-20 | 2005-10-18 | Denso Corporation | Memory writing device for an electronic device |
US20050256614A1 (en) * | 2004-05-13 | 2005-11-17 | General Motors Corporation | Method and system for remote reflash |
US20060248172A1 (en) * | 2003-06-24 | 2006-11-02 | Thomas Zurawka | Method for updating software of an electronic control device by flash programming via a serial interface and corresponding automatic state machine |
US7132923B2 (en) * | 2000-03-16 | 2006-11-07 | Honda Giken Kogyo Kabushiki Kaisha | Memory rewriting system for vehicle controller |
US20060259207A1 (en) * | 2005-04-20 | 2006-11-16 | Denso Corporation | Electronic control system for automobile |
US20070005873A1 (en) * | 2005-06-30 | 2007-01-04 | Baltes Kevin M | ECU identification retention across reprogramming events |
US20070036021A1 (en) * | 2005-07-20 | 2007-02-15 | Denso Corporation | Data reprogramming method and system |
US7210063B2 (en) * | 2002-08-27 | 2007-04-24 | Lsi Logic Corporation | Programmable device and method of programming |
US20070220504A1 (en) * | 2004-02-27 | 2007-09-20 | Johan Eker | Flash Memory Programming |
US20070227499A1 (en) * | 2006-04-04 | 2007-10-04 | Denso Corporation | Electric power generation control system |
US20080098388A1 (en) * | 2004-06-29 | 2008-04-24 | Koninklijke Philips Electronics, N.V. | Safe Flashing |
US7418542B2 (en) * | 2004-10-14 | 2008-08-26 | Sharp Kabushiki Kaisha | Rewritable, nonvolatile memory, electronic device, method of rewriting rewritable, nonvolatile memory, and storage medium having stored thereon rewrite program |
US20130151647A1 (en) * | 2011-12-09 | 2013-06-13 | Denso Corporation | Method for rewriting program, reprogram apparatus, and electronic control unit |
US20130191924A1 (en) * | 2012-01-25 | 2013-07-25 | Gianni Tedesco | Approaches for Protecting Sensitive Data Within a Guest Operating System |
US20130326126A1 (en) * | 2012-06-05 | 2013-12-05 | Denso Corporation | Electronic control unit |
US8612670B2 (en) * | 2011-11-06 | 2013-12-17 | Dsp Group Ltd. | Method and system for managing flash write |
US8813061B2 (en) * | 2012-10-17 | 2014-08-19 | Movimento Group | Module updating device |
US20150007155A1 (en) * | 2012-10-17 | 2015-01-01 | Movimento Group | Module updating device |
US20150113520A1 (en) * | 2013-10-18 | 2015-04-23 | Fujitsu Limited | Method for confirming correction program and information processing apparatus |
US20150170753A1 (en) * | 2013-12-17 | 2015-06-18 | Kyocera Document Solutions Inc. | Refresh Apparatus and Electronic Device That Ensure Simplified Refresh Process of Flash Memory |
-
2012
- 2012-08-23 US US13/593,093 patent/US20140058532A1/en not_active Abandoned
Patent Citations (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6493271B2 (en) * | 1992-03-17 | 2002-12-10 | Hitachi, Ltd. | Data line disturbance free memory block divided flash memory and microcomputer having flash memory therein |
US5857158A (en) * | 1993-12-29 | 1999-01-05 | Robert Bosch Gmbh | Control unit and device for programming it |
US5854937A (en) * | 1994-04-06 | 1998-12-29 | Dell U.S.A., L.P. | Method for reprogramming flash ROM in a personal computer implementing an EISA bus system |
US5787367A (en) * | 1996-07-03 | 1998-07-28 | Chrysler Corporation | Flash reprogramming security for vehicle computer |
US6957296B2 (en) * | 1996-09-20 | 2005-10-18 | Denso Corporation | Memory writing device for an electronic device |
US6009372A (en) * | 1997-10-01 | 1999-12-28 | Cummins Engine Company, Inc. | Management of programming and memory space for an internal combustion engine control system |
US7132923B2 (en) * | 2000-03-16 | 2006-11-07 | Honda Giken Kogyo Kabushiki Kaisha | Memory rewriting system for vehicle controller |
US20020077739A1 (en) * | 2000-08-14 | 2002-06-20 | Brett Augsburger | Enhanced module chipping system |
US6505105B2 (en) * | 2001-01-05 | 2003-01-07 | Delphi Technologies, Inc. | Electronic control unit calibration |
US20020169524A1 (en) * | 2001-05-09 | 2002-11-14 | Mitsubishi Denki Kabushiki Kaisha | On-vehicle electronic controller |
US7210063B2 (en) * | 2002-08-27 | 2007-04-24 | Lsi Logic Corporation | Programmable device and method of programming |
US20040049669A1 (en) * | 2002-09-09 | 2004-03-11 | Schelling Todd A. | Firmware architecture supporting safe updates and multiple processor types |
US20040249558A1 (en) * | 2003-06-06 | 2004-12-09 | John Meaney | System and method for real time programmability of an engine control unit |
US20060248172A1 (en) * | 2003-06-24 | 2006-11-02 | Thomas Zurawka | Method for updating software of an electronic control device by flash programming via a serial interface and corresponding automatic state machine |
US20070220504A1 (en) * | 2004-02-27 | 2007-09-20 | Johan Eker | Flash Memory Programming |
US20050256614A1 (en) * | 2004-05-13 | 2005-11-17 | General Motors Corporation | Method and system for remote reflash |
US20080098388A1 (en) * | 2004-06-29 | 2008-04-24 | Koninklijke Philips Electronics, N.V. | Safe Flashing |
US7418542B2 (en) * | 2004-10-14 | 2008-08-26 | Sharp Kabushiki Kaisha | Rewritable, nonvolatile memory, electronic device, method of rewriting rewritable, nonvolatile memory, and storage medium having stored thereon rewrite program |
US20060259207A1 (en) * | 2005-04-20 | 2006-11-16 | Denso Corporation | Electronic control system for automobile |
US20100313192A1 (en) * | 2005-04-20 | 2010-12-09 | Denso Corporation | Electronic control system for automobile |
US20070005873A1 (en) * | 2005-06-30 | 2007-01-04 | Baltes Kevin M | ECU identification retention across reprogramming events |
US20070036021A1 (en) * | 2005-07-20 | 2007-02-15 | Denso Corporation | Data reprogramming method and system |
US20070227499A1 (en) * | 2006-04-04 | 2007-10-04 | Denso Corporation | Electric power generation control system |
US8612670B2 (en) * | 2011-11-06 | 2013-12-17 | Dsp Group Ltd. | Method and system for managing flash write |
US20130151647A1 (en) * | 2011-12-09 | 2013-06-13 | Denso Corporation | Method for rewriting program, reprogram apparatus, and electronic control unit |
US20130191924A1 (en) * | 2012-01-25 | 2013-07-25 | Gianni Tedesco | Approaches for Protecting Sensitive Data Within a Guest Operating System |
US20130326126A1 (en) * | 2012-06-05 | 2013-12-05 | Denso Corporation | Electronic control unit |
US8813061B2 (en) * | 2012-10-17 | 2014-08-19 | Movimento Group | Module updating device |
US20140351803A1 (en) * | 2012-10-17 | 2014-11-27 | Movimento Group | Module updating device |
US20150007155A1 (en) * | 2012-10-17 | 2015-01-01 | Movimento Group | Module updating device |
US20150113520A1 (en) * | 2013-10-18 | 2015-04-23 | Fujitsu Limited | Method for confirming correction program and information processing apparatus |
US20150170753A1 (en) * | 2013-12-17 | 2015-06-18 | Kyocera Document Solutions Inc. | Refresh Apparatus and Electronic Device That Ensure Simplified Refresh Process of Flash Memory |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140136826A1 (en) * | 2012-11-13 | 2014-05-15 | Electronics & Telecommunications Research Institute | Method and apparatus for updating boot loader |
WO2016087585A1 (en) * | 2014-12-05 | 2016-06-09 | Schneider Electric Automation Gmbh | Method for programming and configuring a device in a traceable manner |
US20180150044A1 (en) * | 2014-12-05 | 2018-05-31 | Schneider Electric Automation Gmbh | Method for programming and configuring a device in a traceable manner |
US10599112B2 (en) * | 2014-12-05 | 2020-03-24 | Schneider Electric Automation Gmbh | Method for programming and configuring a device in a traceable manner |
DE102016221108A1 (en) * | 2016-10-26 | 2018-04-26 | Volkswagen Aktiengesellschaft | A method for updating software of a control device of a vehicle |
US20180113703A1 (en) * | 2016-10-26 | 2018-04-26 | Volkswagen Ag | Method for updating software of a control device of a vehicle |
CN107992753A (en) * | 2016-10-26 | 2018-05-04 | 大众汽车有限公司 | Method for the software of the control device of more new vehicle |
US10423401B2 (en) * | 2016-10-26 | 2019-09-24 | Volkswagen Ag | Method for updating software of a control device of a vehicle |
WO2021032132A1 (en) * | 2019-08-20 | 2021-02-25 | 华为技术有限公司 | Security protection method and device for vehicle-mounted system |
CN112422595A (en) * | 2019-08-20 | 2021-02-26 | 华为技术有限公司 | Vehicle-mounted system safety protection method and device |
CN112748711A (en) * | 2019-10-30 | 2021-05-04 | 惠州比亚迪电池有限公司 | ECU data flashing method, device and system |
WO2021181828A1 (en) * | 2020-03-10 | 2021-09-16 | 日立Astemo株式会社 | Vehicle control device and vehicle control system |
JP7320126B2 (en) | 2020-03-10 | 2023-08-02 | 日立Astemo株式会社 | Vehicle control device and vehicle control system |
FR3108742A1 (en) | 2020-03-30 | 2021-10-01 | Renault S.A.S | Devices and method for controlling electronic control units of a motor vehicle |
WO2021197864A1 (en) | 2020-03-30 | 2021-10-07 | Renault S.A.S | Devices and method for managing electronic control units of a motor vehicle |
US20220019668A1 (en) * | 2020-07-14 | 2022-01-20 | Graphcore Limited | Hardware Autoloader |
US20220038905A1 (en) * | 2020-07-28 | 2022-02-03 | Subaru Corporation | Vehicle communication processor, vehicle communication control method and vehicle |
US11653210B2 (en) * | 2020-07-28 | 2023-05-16 | Subaru Corporation | Vehicle communication processor, vehicle communication control method and vehicle |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20140058532A1 (en) | Method for partial flashing of ecus | |
US8978160B2 (en) | Method for selective software rollback | |
US9021246B2 (en) | Method to replace bootloader public key | |
US8856538B2 (en) | Secured flash programming of secondary processor | |
US8856536B2 (en) | Method and apparatus for secure firmware download using diagnostic link connector (DLC) and OnStar system | |
US8881308B2 (en) | Method to enable development mode of a secure electronic control unit | |
US20130111212A1 (en) | Methods to provide digital signature to secure flash programming function | |
US8966248B2 (en) | Secure software file transfer systems and methods for vehicle control modules | |
US8930710B2 (en) | Using a manifest to record presence of valid software and calibration | |
US20140075517A1 (en) | Authorization scheme to enable special privilege mode in a secure electronic control unit | |
CN105938433A (en) | Method for programming a control unit of a motor vehicle | |
CN102105883A (en) | Electronic device and method of software or firmware updating of an electronic device | |
US11429364B2 (en) | Software installation method | |
KR101806719B1 (en) | The electronic control unit possible auto setting of memory area according to secure boot and method for secure boot using the same | |
US11296894B2 (en) | Storage medium including computing capability for authentication | |
JP2007507020A (en) | Method for reloading software into the boot sector of a programmable read-only memory | |
US20240126886A1 (en) | Trusted Computing for Digital Devices | |
JP7464013B2 (en) | Center, OTA master, method, program, and vehicle | |
JP7320126B2 (en) | Vehicle control device and vehicle control system | |
US10353623B2 (en) | Storage device, storage control method, computer program product, and storage system | |
US20230385076A1 (en) | Method for operating a control unit on which multiple applications are executed | |
CN117677948A (en) | Method for verifying digital signature, vehicle computing unit and vehicle | |
US20240086170A1 (en) | Software update system and software update method | |
GB2592646A (en) | Software update process on a vehicle | |
KR20230105596A (en) | Firmware update management device and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GM GLOBAL TECHNOLOGY OPERATIONS LLC, MICHIGAN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DAS, DIPANKAR;RAJAPPAN, SEETHARAMAN;S., SRINATH;AND OTHERS;REEL/FRAME:028992/0886 Effective date: 20120626 |
|
AS | Assignment |
Owner name: WILMINGTON TRUST COMPANY, DELAWARE Free format text: SECURITY AGREEMENT;ASSIGNOR:GM GLOBAL TECHNOLOGY OPERATIONS LLC;REEL/FRAME:030694/0500 Effective date: 20101027 |
|
AS | Assignment |
Owner name: GM GLOBAL TECHNOLOGY OPERATIONS LLC, MICHIGAN Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WILMINGTON TRUST COMPANY;REEL/FRAME:034287/0415 Effective date: 20141017 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |