Title of Invention

A PROCESS FOR MODIFICATION OF SOFTWARE IN A MEMORY OF A CONTROL UNIT

Abstract

A process for modification of software in a first memory of a control unit for control of operating procedures whereby the execution of old software parts is replaced by execution of new software parts and the old software parts are entered in the first memory, characterised in that the new software parts are entered in a second memory and through a first branching in the first memory the new software parts in the second memory are executed instead of the old software parts in the first memory, whereby after execution of new software parts through a second branching in the second memory, a branch-back again takes place to the first memory and the execution in the first memory of other software that are not the old software parts is resumed, whereby the old software parts remain in the first memory; a starting address of the new software parts is used as a first branching, whereby the old software parts are at least partially overwritten with this, the starting address of other software that is different from the old software parts is used as a second branching. (Figure 2)

Full Text

Process and Mechanism for Modification of Software in a Control Unit as well as of the Control Unit Prior Art The invention is with regard to a process and a mechanism for the modification of software in a first memory in a control unit as well as of the corresconding control unit and a computer program for execution of the process in accordance with the independent claims. Ever more complex functions are transferred with the help of software to individual control units, particularly in the automobile industry. It is more often necessary to incorporate modifications to the software shortly before or even after despatcfrch he end customer. The modifications to the software of a control unit are generally carried out by entering the modifications in a new software integration level and completely loading this newly-written software in the control unit, particularly by saving same in a so-called Flash-EPROM-memory i.e., by importing same through flash. Flash of a control unit in the existing scope of software lasts for example even at this point in time, for anything up to 30 minutes. This time will increase even more sharply in the future due to the high increase in functions and functionalities and therewith due to even greater software complexity and a largernumber of software packages. Thus the requirement of the invention is to reduce the time spent on flash of a control unit whereby other advantages also result. Advantages of the Invention The invention emanates from a process and a mechanism for the modification of software in a first memory of a control unit for control of operating procedures, particularly in the case of a motor vehicle, as well as of a corresponding control unit whereby the execution of old software parts is substituted by the execution of new software parts and the old software parts are entered in to the first memory. In most cases, the software modifications, particularly modification of the program codes, are small vis-a-vis the proportion of the software that does not have to be changed. What is of an advantage is that new specifically the part that is to be modified can be loaded or generally only parts of a software can be loaded in the control unit whereby these software parts can also be called patch-container in description and/or can be contained in this type of a patch-container. Thus for practical purposes only the new software parts are entered in the second memory whereby as a result of a first branching in the first memory , new software parts are executed !n the second memory instead of the eld software parts in the first memory and after the execution of the new software parts by a second branching in a second memory, a branch-back to the first memory takes place , whereby the execution of other software that is different from the oid software parts is resumed in the first memory and the oid software parts are retained in the firs: memory. This means that in order to implement the mcaification of existing software i.e., the oid software -part, a patch-administration, particularly a central one, is to be installed with which those parts cf the software that are to be modified can be specifically modified through entry and exit. The advantage of this is that the expenditure of time in the case of flash of large software segments cr software parts are reduced considerably on the one hand since for one thing, as already mentioned above, the entire software is re-written and for another, the expenditure of time can also be saved which is necessary for the modification of software, particularly for deleting and rewriting the same. Furthermore, this results in a higher flexibility in the case of modification of software and software parts and also results in a lower error-rate due to the lowest possible overwriting and/or deletion and new names for software parts. This is appropriately implemented in that the second memory i.e., the patch-container-region is only used to accept the new software parts and to link the program flow and/or the software data flow. The first branching and the second branching can be appropriately implemented by at least one interlinked list. Interlinked lists thereby present a space-saving opportunity for filing of data, software parts, in particular, which simultaneously have a chronological as well as a logical system. Since several versions could exist in this manner of comparable or same software par.s. interlinked lists present a good and suitable approach to storing versions of various software par.s as it may not be possible to determine the number of versions in advance. In the case of interlinked lists a pointer and/or link is provided for every version of a software part and fcr every software part respectively, which leads to the next version of this software part. A specific pointer status can be used for coding in those situations where the associated version is the current version of the respective software part. In a similar manner, this specific pointer status can ser/e as an identification and/or identifier for the respective software part. Relative or aosclute addresses are thereby used for links. Thus in the case of interlinked lists, a link to the storage location of the respective next logical, interrelated information unit is saved together with a stored software part and/or together with an information unit such as a data record that contains the software part, here particularly of either the next new software part or data record with the new* software part or also of the other software that follows the old software part. Thus the storage locations can also first be occupied at that point in time when the information to be stored and/or re-executed is made available. Apart from this, it is also possible to allocate the respective next free storage location to the information whereby this procedure also leads to an uninterrupted utilisation of the memory. Appropriately, a starting address of the new software part is used now as the first branching, effectively for exit from the first memory whereby the old software parts i.e., the software parts to be modified, can be at least partially overwritten. Alternatively, memory space can also be provided in the first memory for insertion of the exit address. An exit is thus set in the patch-container or to the patch-container in the first memory. As a second branching, effectively as a re-entry, it would be of advantage to use a starting address of the other software that is different from the old software parts so that after the veering around the old software parts, the other, subsequent software in the first memory can be used and/or processed uninterruptedly. Another advantage is that information is contained in the new software parts that specify which of the old software parts are to be substituted and/or such information that indicates which new software parts are to replace the old software parts. The second memory i.e. particularly every imported patch-container in a patch-table that appropriately contains the new software parts as well as additional information possibly, apart from at least one new software part, an adcress for the first branching, an address for the second branching and an address for the beginning of the old software part that is to be substituted by at least one new software part. It would be an advantage if additional information could also be contained in the patch-container such as the size of at least one new software part and/or also of at least one old software part. These elements i.e., an address for the first branching, and address for the second branching, an address for the beginning of the old software part as well as possibly the size of the new software part and/or of the old software part could be consolidated in a data record in the patch-container i.e., in the second memory of the patch-table in particular. Appropriately, the information required to replace an old software part is thus consolidated for every old software part respectively in such a data record. It would thereby be of advantage-to-implement the first memory as a first table and the second memory as a second table (patch-table) in the same memory. It would, thereby, be appropriate to divide the first memory and the second memory in equal sized software segments whereby a new software part could be imported into every software segment of the second memory. Every data record or every software segment could'then be furnished appropriately with an identification corresponding to the exemplary embodiment and this identification permits an allocation of an old software part and of the new software part that is to replace the old one. Other advantages and beneficial designs result from the description as well as from the characteristics of the claims. Drawing The invention is described further with the help of figures illustrated in the drawings. Figure 1 is of a control unit with the corresponding software where the old software parts are replaced by new software parts and Figure 2 illustrates the first memory with the control unit software as well as the patch-container in accordance with the invention and Figure 3 is an example of a possible data record in the patch-container. Description of the Exemplary Embodiment Figure 1 shows a control unit 100 with a processing unit 101, a micro controller in particular as well as a memory tool 102, particularly divided into two memories 103 and 104. These memories 103 and 104 could exist in the same memory or in different memories of the control unit 100. Corresponding new software parts are inserted Into the control unit 100 through an interface 105 that could represent a grid-bound or also a grid-iess connection, from a source 106, for example from another computer, with the second memory tool 107. Since only data that is to be modified is transferred i.e., only the new software parts and not the entire software, which results in a markedly lower transfer rate, even wireless interfaces such as radio, ultrasonic and infrared can be used. Aside of this, the grid-bound transfer can be similarly used in its place. Figure 2 is of a first memory 200 and a second memory 201, illustrated particularly in the form of a table. The first memory thereby contains cells and software segments 205 to 216. The corresponding cell addresses 205 to 216 are respectively stored in block 203. In a similar manner the second memory 201 i.e., the patch-table, contains several cells 217 to 233, as well as software segments in which the so-called patch-container can be stored. Here too corresponding addresses for respective cells are stored in block 204 i.e., stored for the respective patch-container. As can be seen in Figure 2, an exit is generated in software segment 208 in the old software parts from the first memory 200 to the patch-table 201 after the software segment 207. Thereby the old software part 208 is at least partially overwritten with the jump address i.e., the branching to the software segment 218. This means that the first modification A1 begins with a branching V1A1 from the first memory 200 to the second memory 201. After data flow of software segments 218, 219 a branch-back and/or jump back takes place from the software segment 220 with a second branching V2A1, back to the software segment 210 of the first memory. The old software parts in software segments 208 and 209 can thus be replaced by the new software parts in segments 218 and 219 i.e., they can jump around. The old software parts thereby continue to remain in segments 208 and 209 in the first memory. A second modification A2 shows an exit for example after segment 212 at the beginning of segment 223 in the second memory 201 and a jump back at the beginning of the memory segment 214. This means that the software segment 213 is replaced by the software segment 223 with regard to the software data flow through the first branching V1A2 and the jump back cr the second branching V2A2, whereby again the old software part in software segment 213 is at least partially retained. Only that part that contains the jump address for the patch-table is replaced. Information is required with regard to which software parts i.e., old software parts from memory 200, are to be modified and the manner of modification in order to create the condition just described in Figure 2. This information is loaded in patch- table 201. Using a patch-administration, the address reference between memory 200 and memory 201 is created when the control unit is re-started. The patch-administration can for example, be stored in the boot loader i.e., the start program that is processed at the time of starting the control unit. Thereby, depending on complexity, a large amount of information can be contained within the framework of the patch-administration in the patch-table in accordance with the invention. This information and these elements can be compiled in individual data records as is illustrated in Figure 3. The administrator can also be seif-implemented by the processing unit 101 of the control unit in that, the corresponding information is stored in the patch-container. A tool can be used to generate data records for the patch-table, particularly in computer 106. This tool analyses the modifications to the source codes and thereafter creates data records and software parts respectively for the patch-table. These data records are composed, for example of an exit address from the original software i.e., the old software parts, of a destination address for the patch-table i.e., a link to a patch-container, of the new software part i.e, for example a modified or new hexadecimal code, also of, for example, the size of the modified program codes i.e., the size of the old software part or also the size of the new program codes i.e., the new software part as well as of the return address in the first memory i.e., to other software that is different from the old software part, i.e., in to the original program in particular. Furthermore, an identifier or identification can be allocated to a patch-container and contained therewith in the data record. Not all the information mentioned for the implementation of the process in accordance with the invention is necessary. Thus the end address can be determined for example from the start address and the size of the software part. The utilisation of information can nevertheless translate into a time advantage since an address does not have to be computed but is indicated instead or with regard to redundant information, can enable a review of the software modifications and therewith an increase in security. Likewise, a modification in the software can be reversed using a patch-administration configured in a similar manner. This type of reversal frees up memory space in the first memory for exit addresses so that the same is not partially overwritten in case of re-utilisation,of the old software part. Block 300 in Figure 3 serves as an example of this kind of a patch-container or data record. A program address for example is specified thereby with 301, i.e., the address of the old software part to be replaced and the address in the patch table is specified with block 302. Block 303 provides the new program code in particular i.e., the new software part that is to replace the old software part. The size of the new software part i.e., the code length is specified in bit, byte or in any other quantity with block 304 and finally block 305 displays the return address to the other software parts, i.e., to the original program in the first memory 200 in particular. Apart from this, as already mentioned, an identification i.e., an identifier can be contained in a similar manner for example, instead of the code length specification or in addition to it. This type of a patch-container such as block 300 and/or the entire patch-table can be very simply loaded in to the control unit through a bus system for example, through a CAN-bus-system with the CAN-messenger. If an identification or an identifier is used, as already addressed i.e., if the same is allocated to a patch-container, one can make the modifications for example, error notifications from clients, in a very systematic manner, track down the same and also build up a history of modifications and save the same without losing on transparency from the stable, debugged program code i.e., without losing the error-free software, if a correction does not yield the desired reaction, one can easily re-establish the old status by simply taking out the patch-container. The low data rate that the process in accordance to the invention operates enables a simple correction or an upgrading of the software even via the wireless interface, as already mentioned. Another advantage is to segment the memory for the data i.e., the software into equal sized data files i.e., equal sized software segments, which can then likewise as in the case of the process described above, be interlinked with one another and be stored for the modifications in the patch-table. This means that the cells or data packages and/or the software stored in first memory 200 as well as in second memory 201 do not compulsorily have to be of the same size but is instead overseen through the addresses and the patch-administration. It can, however, be of advantage to use software segments for the first and second memories that are of the same size and to always interchange complete software segments as data records and/or replace old software parts with new ones. The invention illustrated in all its forms thus provides an incremental flash of a control unit with all the advantages mentioned. Claims 1. Process for modification of software in a first memory of a control unit for control of operating procedures whereby the execution of old software parts is replaced by execution of new software parts and the old software parts are entered in the first memory, characterised in that the new software parts are entered in a second. memory and through a first branching in the first memory the new software parts in the second memory are executed instead of the old software parts in the first memory, whereby after execution of new software parts through a second branching in the second memory, a branch-back again takes place to the first memory and the execution in the first memory of other software that are not the old software parts is resumed, whereby the old software parts remain in the first memory. 2. Process according to Claim 1 characterised in that the second memory is only used to accept the new software parts. 3. Process according to Claim 1 characterised in that the first branching and the second branching are implemented through at least one interlinked list. 4. Process according to Claim 1 characterised in that a starting address of the new software parts is used as a first branching, whereby the old software parts are at least partially overwritten with this. 5. Process according to Claim 1 characterised in that a starting address of other software that is different from the old software parts is used as a second branching. 6. Process according to Claim 1 characterised in that information is contained in the new software parts that specify which of the old software parts are to be replaced. 7. Process according to Claim 1 characterised in that information is contained in the new software parts that specifies which new software parts are to replace the old software parts. 8. Process according to Claim 1 characterised in that apart from at least one new software part, the second memory contains an address for the first branching, an address for the second branching and an address for the beginning of the old software part that is to be replaced by the at least one new software part. 9. Process according to Claim 8 characterised in that the second memory also contains the size of the new software part of which there is at least one and/or the size of the old software part of which there is at least one. 10. Process according to Claim 8 or 9 characterised in that the elements of Claims 8 and/or the elements of Claim 9 are compiled in one data record in the second memory. 11. Process according to Claim 10 characterised in that at least two old software parts and at least two new software parts are provided to replace these whereby the corresponding elements of Claims 8 and/or 9 are summarised in one data record respectively and are entered in a second memory. 12. Process according to Claim 1 characterised in that a first table is intended as the first memory and a second table is intended as the second memory in the same memory. 13. Process according to Claim 1 or 2 characterised in that the first memory and the second memory are divided into software segments of the same size, whereby a new software part can be entered in every software segment of the second memory. 14. Process according to Claim 10 or 13 characterised in that every data record or every software segment is provided with an identification. 15. Process according to Claim 14 characterised in that the identification for a software segment in the fist memory that contains an old software part and the identification for the corresponding software segment with the new software part that replaces the old software part is the same. 16. Mechanism for modification of software in a first memory in a control unit for control of operating processes whereby the execution of old software parts is replaced by the execution of new software parts and the old software parts are entered in the first memory characterised in that tools are contained that enter the new software parts in a second memory and a first branching in the first memory through which the new software parts in the second memory are executed instead of the old software parts in the first memory, whereby the tools also enter a second branching in the second memory, through which a branch-back to the first memory takes place again after execution of new software parts and the execution of other software that is different from the old software parts is resumed in the first memory, whereby the old software parts remain in the first memory. 17. Control unit with a first memory in which old software parts and other software parts that are different from the old software parts are stored characterised in that the control unit contains a second memory which contains new software parts that are to replace the old software parts characterised in that tools are contained which enter the new software parts in a second memory and a first branching in the first memory through which the new software parts in the second memory are executed instead of the old software parts in the first memory, whereby the tools also enter a second branching in the second memory through which a branch-back takes place to the first memory after execution of the new software parts and the execution of other software that is different from the old software parts is resumed in the first memory, whereby the old software parts remain in the first memory. 18. Computer program with program code for the execution of all steps according to one of Claims 1 to 15 If the program is executed on a computer, particularly in a control unit.

Documents:

1282-chenp-2005 abstract granted.pdf

1282-chenp-2005 claims granted.pdf

1282-chenp-2005 description (complete) granted.pdf

1282-chenp-2005 drawings granted.pdf

1282-chenp-2005-abstract.pdf

1282-chenp-2005-claims.pdf

1282-chenp-2005-correspondnece-others.pdf

1282-chenp-2005-correspondnece-po.pdf

1282-chenp-2005-description(complete).pdf

1282-chenp-2005-drawings.pdf

1282-chenp-2005-form 1.pdf

1282-chenp-2005-form 3.pdf

1282-chenp-2005-form 5.pdf

1282-chenp-2005-form18.pdf

1282-chenp-2005-pct.pdf