Title of Invention

METHOD AND DEVICE FOR SWITCHING BETWEEN AT LEAST TWO OPERATING MODES OF A PROCESSOR UNIT

Abstract

Process and device for switching between at least two operating modes (SM, LM) of a central processing unit (100, 101) with at least two execution units (ALL) A, ALU B) for processing of programs (P1, P2, P3), whereby at least one answerback code (K2) is allocated to at least programs (P1, P2, P3), which permits differentiation between at least two operating modes (SM, LM) and switching takes place between the operating modes subject to the answerback code (K1-K4, KB) so that the central processing unit (100, 101) processes the programs (P1, P2, P3) corresponding to the allocated operating mode.

Full Text

Process and Device for Switching Between at least Two Operating Modes of a Central Processing Unit Prior Art The invention emanates from a process and a device for switching between at least two operating modes of a central processing unit as well as of a corresponding central processing unit with at least two execution units for processing of programs in accordance with the preamble of the independent claims. Such central processing units with at least two integrated execution units are also established as dual-core or multi-core architectures. Such dual-core or multi-core architectures are mainly proposed according to prior art, for two reasons: One reason is that a performance increase can be achieved in that the two execution units or cores are considered and dealt with as two arithmetic and logic units at one semi-conductor module. In this configuration, the two execution units or cores process different programs and respective tasks. This allows a performance increase to be achieved which is why this configuration is termed the performance mode. Apart from being used as super scalar processors, the second reason for implementing a dual core or multi core architecture is to increase security in that both execution units redundantly process the same program. The results of the two execution units are compared and an error can then be identified when making a comparison for a match. This configuration will henceforth be termed the safety mode. In general, the two configurations mentioned are contained exclusively in the dual or multi core architecture i.e. the arithmetic and logic unit with the at least two execution units is principally operated only in one mode: either the performance mode or the safety mode. The purpose of the invention now is to make possible a combined operation of such a dual or multi core central processing unit with regard to at least two operating types and thereby achieve an optimal switching strategy between at least two operating modes i.e. particularly between the safety mode and performance mode. Advantages of the Invention On the one hand, a redundant execution of respective tasks of the programs i.e. also of task programs, program parts i.e. code blocks or also other individual commands is desirable for reasons of security while, on the other hand, keeping completely redundant hardware available for execution of functions that are not critical to security is not desirable due to reasons of costs involved. This conflict of objectives is solved, in accordance with the invention, by optimized switching between at least two operating modes and a central processing unit. The invention thus emanates from a process and device for switching between at least two operating modes of a central processing unit with at least two execution units as well as a corresponding central processing unit. The central processing units can thereby, on the one hand, be complete cores i.e. complete CPUs or only the arithmetic and logic unit is duplicated, as in a preferred exemplary embodiment. The advantage of only duplicating the arithmetic and logic unit (ALU) and protecting the other CPU components with other error-detection mechanisms is that the visualised switching mechanism requires less of the additional chip surfaces than complete dual core architecture. Nevertheless, an adequate error cover can, however, also be achieved with the process in accordance with the invention in the safety mode and in the case of computation that is not security-relevant, a significant performance increase can be achieved in the performance mode, in equal measure for double CPU or double ALU. The invention thus emanates from a process and a device for switching between at least two operating modes of a central processing unit with at least two execution units for processing of programs, whereby, in an advantageous manner, at least one answerback code is allocated to the programs which permits a differentiation between the at least two operating modes i.e. particularly the safety mode and the performance mode and switching between the operating modes takes place subject to the answerback code so that the central processing unit processes the programs corresponding to the allocated operating mode. The term programs thereby also includes program parts i.e. code blocks that stretch completely or proportionately over several programs over task programs that are contained in the individual programs or are built by the programs right up to individual program commands, to each of which an answerback code is allocated. Thereby this type of answerback code allocation for switching between the individual operating modes at a functions level can be used particularly for controlling operation process flows in the case of a motor vehicle. On the other hand, programs or corresponding task programs, program parts or program commands that belong to an operating system of the central processing unit or represent this operating system, can be allocated to the corresponding operating mode, in an advantageous manner, through such answerback codes. Advantageously, the conditions or results arising from processing of programs are compared for a match, whereby an error is identified in the case of a deviation. It is thereby particularly advantageous if the programs are processed synchronously. The answerback code is designed in an advantageous manner at least as one bit, whereby this type of an answerback code is created by a program command, particularly by a command provided in the command record of the central processing unit such as, for example, in a write command. This answerback code can, on the one hand, be allocated to the corresponding program, program part, execution program or program command or can even be already entered or will be entered in a specific, designated memory area. Thus, subject to the answerback code, optimised switching can take place between two operating modes, particularly the performance mode and the safety mode in a dual core architecture or an architecture with only a duplicated arithmetic and logic unit i.e. a double ALU. Other advantages and beneficial designs emerge from the description as well as from the features of claims. Drawing The invention is described in further detail by means of the figures illustrated in the drawings. Figure 1 and Figure 2, thereby, each illustrate a central processing unit with a duplicated arithmetic and logic unit in which switching, in accordance with the invention, can be executed. Figure 3 illustrates switching from the safety mode to the performance mode and Figure 4 illustrates switching from the performance mode to the safety mode. By means of a number of code lines 500, Figure 5 illustrates allocation of the answerback codes to the programs, program parts, task programs or commands. Description of the Exemplary Embodiment The same elements and/or elements that have the same functions, provided nothing else is specified, have been given the same reference signs in Figures 1 and 2 of the drawings. The program-controlled unit,in accordance with the invention, as well as its components such as micro controller cores (CPU), memory units, peripheral units etc. have not been directly illustrated in Figures 1 and 2 in order to provide better clarity. However, the two arithmetic and logic units ALU A and ALU B can also correspond to complete cores i.e., CPUs in the framework of the invention so that the invention can also be used for complete dual core architectures. It is, however, preferred that only the arithmetic and logic unit be duplicated and the other components of the CPU be protected by other error-detection mechanisms. Arithmetic and logic units (ALU) in Figures 1 and 2 are respectively indicated with reference signs 1 and 2 as execution units. A respective ALU unit 1, 2 exhibits two inputs and one output. Parameters provided for execution in a test operation, can be linked directly from Bus 3 in the inputs of ALU units 1, 2 or can be previously deposited in a parameter register 8, 9 specially meant for the same. These parameter registers 8, 9 are directly linked to data bus 3. The two ALU units 1, 2 are thus fed from the same parameter registers 8, 9. It can additionally be provided that the respective parameters can already be furnished with an ECC code via the bus, this code being deposited in the register regions 8a, 9a. This means that at all locations in Figures 1 and 2 in which ECC is specified, data can be protected by using an ECC code (error correction code). Such methods for error detection are manifold, whereby the basic requirement illustrates the protection with an error-detection and/or error-correction code i.e. illustrates a signature. In the simplest case, this signature can consist of just one signature bit, for example, a parity bit. On the other hand, the protection can also be executed using more complex ED codes (error detection) such as a Berger code or a Bose-Lin code etc. or even by using a more complex ECC code such as, for example, a Hamming code etc. in order to ensure reliable error recognition through corresponding bit numbers. This can, however, also be used as a code generator, for example, a generator table (hard-wired or in the software) in order to allocate a desired code design of any length to specific input designs of bits in the framework of the address. Data security can be guaranteed therewith, particularly through the correction function. A redundant processing of security-critical programs nevertheless takes place in both execution units, i.e. here in both ALUs 1 and 2, in the security-critical mode i.e, the safety mode, whereby errors in the same are detected by a comparison for a match in accordance with the invention. Programs or tasks of respective program parts or code blocks or commands that are not relevant to security and/or not critical to security can be computed distributed across both execution units in order to increase performance, whereby the operational capacity and therewith performance, increases. This takes place in the so-called performance mode, LM. When linking the respective parameters in the ALU units 1,' 2, special care must be paid with regard to correct data input. If, e.g., the same defective parameters are linked in the two ALU units 1, 2, then an error at the ALU units' 1, 2 output will not be detectable. It must, therefore, be ensured that at least one of the ALU units 1 or 2 receives correct data input values and/or even both ALU units 1, 2 receive different but wrong data input values. This is ensured in that a check sum i.e. an ECC code, as mentioned above, is formed from the at least one input value of the ALU unit 1,2. In a specially provided comparator unit 5, 6, the ECC coding 10a, 11a from these additional data registers 10, 11 is compared with the ECC coding 8a, 9a from the original source register 8, 9. Optionally, even the input data from registers 10, 11 can be compared to that from the source registers 8, 9. If a difference emerges in the ECC coding and in the two parameters respectively, then the same is interpreted as an error and an error signal will be emitted which will be indicated, depending on circumstances, or corrected, depending on circumstances. This comparison takes place advantageously during parameter processing in the ALU units 1, 2 so that this error detection and error correction at the input side is virtually accompanied by no loss in performance. If a comparator unit 5, 6, identifies an error then the computing is repeated within the next cycle. A shadow register can, thereby, be used in order to always save the parameters of the last computation so that the same are quickly available in the event of a fault. Making this kind of a shadow register can, however, be done away with if the respective parameter registers 10, 11 are first re-described by an enable signal due to the non-existence of an error. In the case of an error, the comparator units 5, 6, supply an error signal whereby the parameter registers 10, 11 are not re-described. The ALU units 1, 2, create a result respectively at the output side. The result data and their ECC coding, respectively made available by the ALU units 1, 2, are stored in the result registers 12, 13, 12a, 13a. This result data and/or their coding are compared with one another in the comparator unit 14. An enable signal 16 is created in case an error does not exist. This enable signal 16 is linked in the release device 15 which causes the result data to be written at bus 4. Result data can then be re-processed through bus 4. The release signal 16 can further also be used to re-release registers 8 to 11 so that the next parameters from bus 3 can be read and processed in the ALU units 1,2, The result is not verified in the case of the configuration in Figure 1. Here only the result data are compared with one another in the comparator unit 14. Checking of the ECC coding, of the result data, is only possible with the configuration in Figure 2 in which not only the result data but also its ECC coding are compared with one another in the comparator unit 14. All transient errors, permanent errors as well as run-time errors are detected with the error-detection configuration specified in Figures 1 and 2. Run-time errors within an ALU unit 1, 2, are detected when the result does not reach the comparator unit 12 or reaches too late and a comparison thus takes place with a partial result. By protecting parameter registers 8, 9, 10 with an error-detection code and an error-correction code and on comparison of the end results, the respective error location and error time can be localised precisely. A transient failure can thus be reacted to very quickly in this manner. The following possibilities for error localisation consequently result. If a comparison of the result data in the comparator unit 14 yields a difference then it can be concluded that an error exists within the ALU units 1,2. If the comparison of the ECC coding in one of the comparator units 5, 6 yields a difference then it can be concluded that a defective signal from bus 3 and/or upstream components exists. If a comparison of the ECC coding in the comparator unit 14 results in a difference then one can conclude that the coding of the results is defective. Switch device UE 17 is used to switch between the safety mode mentioned, in which a redundant processing and checking takes place, and the performance mode, in which a performance increase is achieved by separate program processing. The elements 8, 9 and 1, 2 are switched in such a manner using this switch device that in the case where a redundant program processing, particularly a synchronous program processing takes place in the safety mode SM, parallel processing of different programs can be completed in the second operating mode, the performance mode LM. A switch or switching equipment can be provided for this that, on the one hand, can be localised in elements 8, 9 respectively 1, 2 or even in the switch device 17 or are additionally contained in the switching mechanism, separate from elements 8, 9, 1, 2 and 17 respectively. Coding of programs or task programs or program parts, i.e. code blocks, or also of commands, takes place through an answerback code for switching, using which one can identify whether these are security related i.e. whether the same must be processed in the safety mode SM or whether the same can be made available to the performance mode LM. This can take place through a bit in the command or the ensuing sequence can be identified by a special command. This will be described once again, in greater detail, by means of the different answerback code possibilities in Figure 5. The programs can thereby, on the one hand, comprise of application functions, in particular for control of operation process flows in a motor vehicle or switching takes place with regard to programs in which the answerback code takes place at operating system levels i.e. e.g. an allocation of entire operating system tasks. During de-coding, the switch device 17 can now identify whether the computing that now takes place is relevant to security i.e. whether it should be executed in the safety mode or not. If this is the case, then the data is passed on to both executing units 1 and 2. If this is not the case then processing continues in the performance mode and an execution unit thus receives the data made available and simultaneously the next instruction can be provided to the second execution unit, provided the same is likewise not security-relevant, so that the programs can be processed in parallel with higher operational capacity. In the first case, for example, the duration of result calculation in the case of synchronized processing on both units, is the same. The results are thus simultaneously available in a safety mode during synchronized processing. This data is now again provided with a coding at output corresponding to 12 and 13 and data and/or coding of this data, as described in Figures 1 and 2, are compared at Result A and Result B. If these match, then the data is released; otherwise one of the error reactions mentioned takes place. In the second case i.e. in the performance mode LM, if data is processed in parallel, the comparator or comparing element 14 at the output of both arithmetic and logic units is not activated and Result A and Result B are written back, one after the other, in the register bank and can also be issued one after the other as is also the case in a super scalar processor. This switching procedure in accordance with the invention is explained once again in Figures 3 and 4. Figure 3 thereby illustrates switching from the safety mode to the performance mode and Figure 4 illustrates switching from a performance mode to the safety mode. An answerback code and a corresponding switch is required in order to move from the first operating mode, here the safety mode SM to the second operating mode, here the performance mode LM. This is made clear once again in Figure 3. The execution unit 1 in block 300 is in the second operating mode, the performance mode. Similarly, the second execution unit 2 in block 310 is also in the performance mode. Likewise, elements 8 and 9 are controlled and switched respectively using the switch device 17 that is, for example, designed as a decode module and contains one such respectively. At least one answerback code is now determined in block 320 and block 321 corresponding to the program flow of the respective execution unit 1 or 2. Switching in block 330 of both execution units to the first operating mode, the safety mode SM, takes place through the answerback code. The two branches thereby run redundantly again and, in particular, synchronously via blocks 8 and 9 and the execution units 1 and 2 with regard to the programs that have been identified to be security-relevant by the answerback code so that the safety mode SM is present again. It is thereby sufficient that such an answerback code for switching is present in a program run in the performance mode i.e. in one branch, in order to operate both execution units in the safety mode. Thus, owing to circumstances, processing of the already commenced program codes of the other execution must still be processed in order to allow both to then continue processing in the safety mode. On the other hand, the safety mode can be switched to immediately and processing of the commenced program continued in a subsequent performance mode, beginning from the point of interruption. An answerback code is likewise used now corresponding to Figure 4 in order to move from the first operating mode, here the safety mode, to the second operating mode which is the performance mode. Both execution units 1 and 2 and corresponding to the branches with blocks 8 and 9 i.e. parameter switching, are in the safety mode, i.e. in the first operating mode. Verification is now run in query block 210 as to whether a switching answerback code is present or whether an answerback code present will enable switching to the performance mode. If this is not the case i.e. if no answerback code is present or the answerback code continues to indicate the safety mode, one returns to block 200 and the programs are re-processed in the safety mode. If the answerback code present or the same respectively indicates the switch then switching and/or change to the second operating mode i.e., the performance mode LM, takes place in block 220. Since the same programs are processed in parallel i.e., redundantly in the safety mode, a switch takes place here only if switching is intended due to the answerback code for both branches in the performance mode i.e. block 8 and ALU 1 as well as block 9 and ALU 2. If a completely synchronous processing takes place i.e. a simultaneous processing of programs, it is taken for granted that a non-synchronous processing of the program takes place and the faster execution unit must wait for the one lagging behind so that the switch device 17 switches only when both answerback codes are present and evaluated respectively. This kind of synchronicity for a result comparison and/or ECC comparison and result comparison according to blocks 12, 13 and 14 as well as 12a and 13a must either be forced through simultaneousness or created through waiting. The first branch i.e. block 8 and execution unit 1, in block 230 is consequently again in the performance mode and the second branch with block 9 and execution unit 2 is in block 231 through which the switch in accordance with the invention is then completed. An optimized switching between two operating modes of a central processing unit with two integrated execution units, corresponding to the task, is therewith illustrated in accordance with the invention, whereby the answerback code is brought in various ways into a program or data line section 500 or can be localized corresponding to Figure 5. Furthermore, when we speak of lines in Figure 5, the same are program lines whereby here too program lines and data lines are possible in any combination. Thus, Figure 5 illustrates, for example, program P1 from line Z1 to line Z6, P2 from line Z7 to line Z15 and P3 from line Z16 to line Z19. AP represents a task program, for example, a part of a program P1, whereby several programs e.g. P1 and P2 can together form a task program. CB illustrates a code block i.e. a part of a program that comprises of, for example, lines of two programs, here Z14 to Z18 of program P2 and P3. Similarly, this kind of code block i.e., a program part can only be a part of a program. PB3 furthermore illustrates a program command corresponding to line Z19. Lines ZS1 and ZS2 illustrate a special storage area SSB that, as a pre-determined memory area, can contain this kind of answerback code, here KB. Apart from this, K1, K2, K3 and K4 as well as KB illustrate various answerback codes that allow for the various possibilities of the computing process in accordance with the invention. There are now various possibilities with reference to this use of the answerback code: for one, the safety mode SM (as, naturally, the performance mode also) can be intended as a basic processing mode i.e., the default mode. When an answerback code is present then a corresponding switch is made to the performance mode (or vice versa to the safety mode). On the other hand, it can also be provided in accordance with the invention that an answerback code must basically be present and the corresponding mode is concluded from the content of the answerback code, i.e. particularly its bit value. A binary value, for example (or even any other value, particularly the dominant value) is then allocated to the safety mode SM and the binary value 0 (or even any other value, particularly the recessive value) is allocated to the performance mode LM. With regard to considering dominant and recessive, the result of the same is that the dominant value and, consequently, the safety mode are set, as a rule, in the case of an error or of a malfunction. Corresponding to line Z4, a binary value B1 is now present with answerback code K1 i.e. K1/B1 that, for example, indicates that the task program of lines Z4 to Z6 in program P1 can be processed in the performance mode even though, for example, program P1 must be processed in the safety mode. As can be seen from answerback codes K1, K2 and K3, these can be of different lengths so that, for example, for answerback code K2 in accordance with line Z27 3 bits, B1 to B3, make up the answerback code so that, for one, the safety mode SM or the performance mode LM are decided between with bit B1 at K2 and, for example, the bits B2 and B3 specify the line number to which this mode, for example the safety mode, applies so that the entire program P2 or even only a part of it is processed in the safety mode. Similarly, code blocks i.e., program parts that, for example, do not contain any total task i.e., can not represent any task programs, represented here with CB, are allocated to a mode by an answerback code, such as K3 here. Here, then, apart from the operating mode allocation with bit B1 at K3, for example, even a starting line or address with bits B2 and B3 at K3 and an end line or end address with bits B4 and B5 at K3 can be specified so that a special region is processed in a corresponding allocated operating mode. This kind of answerback code allocation can take place, in accordance with K4 or even in the case of individual commands PB3 in Z19 or even for any command. As illustrated, these answerback codes can thus be allocated to complete programs or task programs AP or program parts CB or even to individual program commands PB, here PB3, which then releases a corresponding switching by means of a switch device 17. The presence of this type of answerback code K1 to K4 or KB is then verified through a query in block 210 or even in blocks 320 and 321 and a switch takes place with respect to their contents. The answerback code can thereby, as illustrated here, be designed with at least one bit but can also comprise of several bits, dependent, on the one hand, on the different number of operating modes and, on the other, conditioned by additional information such as number of lines or a start or end address. In a special design, at least one program command can be provided, here PB1, PB2 or even PB3 that first creates an answerback code which shows whether processing is to take place in the first or second operating mode. The answerback code can thereby be written in a specific memory area SSB as illustrated here with KB in ZS2. This area SSB can exist in a register, in a memory that is integrated in the CPU or even in an external memory. A special command e.g., PB3 can thereby be provided that is a command which creates this answerback code KB or a command that is already present in the command record of the central processing unit. Even a command "create answerback code" can, for example, be implemented as a special command or a command already present in the central processing command record, particularly a write command, can be accessed as represented here by PB1 and PB2 so that in Z9 the write command WR writes the binary value 0 in the memory area KB, represented by WR (KB: 0) and therewith all following lines, as long as answerback code is KBO, are processed, for example, in the safety mode. The value 1 can then be entered with the same command in Z12 at PB2 through WR (KB: 1) in the memory area for answerback code KB so that, from this point onwards, the following lines can be processed e.g., in the performance mode. This means that using simple answerback code-creating commands, particularly a simple write command WR, a corresponding switch answerback code KB can then, for example, be created in a specific memory area that is regularly queried. A plurality of possibilities is thus presented in accordance with the invention, an operating mode switch in the case of a central processing unit with two execution units executed based on an answerback code. The said advantages of the invention can thus be achieved in this manner. Claims 1. Process for switching between at least two operating modes (SM, LM) of a central processing unit (100, 101) with at least two execution units (ALU A, ALL) B), for processing of programs (P1, P2, P3), characterized in that at least one answerback code (K2) is allocated to at least programs (P1, P2, P3), which permits differentiation between the at least two operating modes (SM, LM) and switching between the operating modes takes place subject to the answerback code (K1-K4, KB) so that the central processing unit (100, 101) processes the programs (P1, P2, P3) corresponding to the allocated operating mode. 2. Process according to Claim 1, characterized in that the programs (P1, P2, P3) contain task programs (AP) or form the same and that an answerback code (K1) is allocated respectively to the individual task programs (AP). 3. Process according to Claim 1, characterized in that the programs (P1, P2, P3) are composed of individual program parts (CB) or contain the same and that an answerback code (K3) is respectively allocated to the individual program parts (CB). 4. Process according to Claim 1, characterized in that the programs (P1, P2, P3) are composed of individual program commands (PB) and an answerback code (K4) is respectively allocated to the individual program commands (PB). 5. Process according to Claim 1, characterized in that the programs (P1, P2, P3) belong to an operating system of the central processing unit (100, 101) or represent the operating system. 6. Process according to Claim 1, characterized in that the programs (P1, P2, P3) are employed to control operation process flows of a motor vehicle. 7. Process according to Claim 1, characterized in that a first operating mode is provided that corresponds to a safety mode (SM) in which the two execution units (ALU A, ALL) B) redundantly process the same programs (AP, P2). 8. Process according to Claim 7, characterized in that while processing programs (AP, P2), emerging conditions or results (Result A, Result B) are compared (14) for a match and an error is detected in the case of a deviation. 9. Process according to Claim 7, characterized in that the programs (AP, P2) are processed synchronously. 10. Process according to Claim 1, characterized in that in the second operating mode that corresponds to the performance mode (LM), every execution unit (ALU A, ALU B) processes different programs (P1, P2, P3). 11. Process according to Claim 1, characterized in that the answerback code (K1, KB) is designed with at least one bit (K1/B1). 12. Process according to Claim 1, characterized in that a program command (PB1, PB2, PB3) is provided that creates an answerback code (KB) which indicates whether processing is to take place in a first or second operating mode. 13. Process according to Claim 1, characterized in that the answerback code (KB) is written in a specific memory area (SSB). 14. Process according to Claim 12 or 13, characterized in that the answerback code (KB) is created by a command (PB1, PB2) provided in a command record of the central processing unit. 15. Process according to one of Claims 12 - 14, characterized in that the answerback code (KB) is created by a write command (WR). 16. Device for switching between at least two operating modes (LM, SM) of a central processing unit (100, 101) for processing of programs (P1, P2, P3) with at least two execution units (ALU A, ALU B), whereby switch devices (8, 9) are contained through which switching can be undertaken, characterized in that the switch devices (8, 9) allocate at least one answerback code (K1-K4, KB) to the programs (P1, P2, P3) which permits a differentiation between the two operating modes (LM, SM) and the switch devices (8, 9) are designed in such a manner that the same, subject to the answerback code, switch between the operating modes and the central processing unit processes the programs corresponding to the allocated operating mode. 17. Device according to Claim 16, characterized in that at least two execution units are provided corresponding to at least duplicated arithmetic and logic units (ALU A, ALU B). 18. Central processing unit (100, 101) for processing of programs (P1, P2, P3) with at least two execution units (ALU A, ALU B), whereby switch devices (8, 9) are contained through which switching can take place between at least two operating modes (LM, SM) of the central processing unit, characterized in that these switch devices (8, 9) allocate at least one answerback code (k1-K4, KB) to the programs (P1, P2, P3) which permits differentiation between the two operating modes (LM, SM) and the switch devices (8, 9) are designed in such a manner that the same, subject to the answerback code, switch between the operating modes and the central processing unit processes the programs corresponding to the allocated operating mode. Claims 1. Process for switching between at least two operating modes (SM, LM) of a central processing unit (100, 101) with at least two execution units (ALU A, ALL) B), for processing of programs (P1, P2, P3), characterized in that at least one answerback code (K2) is allocated to at least programs (P1, P2, P3), which permits differentiation between the at least two operating modes (SM, LM) and switching between the operating modes takes place subject to the answerback code (K1-K4, KB) so that the central processing unit (100, 101) processes the programs (P1, P2, P3) corresponding to the allocated operating mode. 2. Process according to Claim 1, characterized in that the programs (P1, P2, P3) contain task programs (AP) or form the same and that an answerback code (K1) is allocated respectively to the individual task programs (AP). 3. Process according to Claim 1, characterized in that the programs (P1, P2, P3) are composed of individual program parts (CB) or contain the same and that an answerback code (K3) is respectively allocated to the individual program parts (CB). 4. Process according to Claim 1, characterized in that the programs (P1, P2, P3) are composed of individual program commands (PB) and an answerback code (K4) is respectively allocated to the individual program commands (PB). 5. Process according to Claim 1, characterized in that the programs (P1, P2, P3) belong to an operating system of the central processing unit (100, 101) or represent the operating system. 6. Process according to Claim 1, characterized in that the programs (P1, P2, P3) are employed to control operation process flows of a motor vehicle. 7. Process according to Claim 1, characterized in that a first operating mode is provided that corresponds to a safety mode (SM) in which the two execution units (ALU A, ALL) B) redundantly process the same programs (AP, P2). 8. Process according to Claim 7, characterized in that while processing programs (AP, P2), emerging conditions or results (Result A, Result B) are compared (14) for a match and an error is detected in the case of a deviation. 9. Process according to Claim 7, characterized in that the programs (AP, P2) are processed synchronously. 10. Process according to Claim 1, characterized in that in the second operating mode that corresponds to the performance mode (LM), every execution unit (ALU A, ALU B) processes different programs (P1, P2, P3). 11. Process according to Claim 1, characterized in that the answerback code (K1, KB) is designed with at least one bit (K1/B1). 12. Process according to Claim 1, characterized in that a program command (PB1, PB2, PB3) is provided that creates an answerback code (KB) which indicates whether processing is to take place in a first or second operating mode. 13. Process according to Claim 1, characterized in that the answerback code (KB) is written in a specific memory area (SSB). 14. Process according to Claim 12 or 13, characterized in that the answerback code (KB) is created by a command (PB1, PB2) provided in a command record of the central processing unit. 15. Process according to one of Claims 12 - 14, characterized in that the answerback code (KB) is created by a write command (WR). 16. Device for switching between at least two operating modes (LM, SM) of a central processing unit (100, 101) for processing of programs (P1, P2, P3) with at least two execution units (ALU A, ALU B), whereby switch devices (8, 9) are contained through which switching can be undertaken, characterized in that the switch devices (8, 9) allocate at least one answerback code (K1-K4, KB) to the programs (P1, P2, P3) which permits a differentiation between the two operating modes (LM, SM) and the switch devices (8, 9) are designed in such a manner that the same, subject to the answerback code, switch between the operating modes and the central processing unit processes the programs corresponding to the allocated operating mode. 17. Device according to Claim 16, characterized in that at least two execution units are provided corresponding to at least duplicated arithmetic and logic units (ALU A, ALU B). 18. Central processing unit (100, 101) for processing of programs (P1, P2, P3) with at least two execution units (ALU A, ALU B), whereby switch devices (8, 9) are contained through which switching can take place between at least two operating modes (LM, SM) of the central processing unit, characterized in that these switch devices (8, 9) allocate at least one answerback code (k1-K4, KB) to the programs (P1, P2, P3) which permits differentiation between the two operating modes (LM, SM) and the switch devices (8, 9) are designed in such a manner that the same, subject to the answerback code, switch between the operating modes and the central processing unit processes the programs corresponding to the allocated operating mode.

Documents:

1386-CHENP-2006 ABSTRACT.pdf

1386-CHENP-2006 CLAIMS GRANTED.pdf

1386-CHENP-2006 CORRESPONDENCE OTHERS.pdf

1386-CHENP-2006 CORRESPONDENCE PO.pdf

1386-CHENP-2006 FORM-18.pdf

1386-CHENP-2006 COMPLETE SPECIFICATION AS GRANTED.pdf

1386-chenp-2006 correspondence others-25-06-2009.pdf

1386-chenp-2006 form-26.pdf

1386-chenp-2006-abstract.pdf

1386-chenp-2006-claims.pdf

1386-chenp-2006-correspondnece-others.pdf

1386-chenp-2006-description(complete).pdf

1386-chenp-2006-drawings.pdf

1386-chenp-2006-form 1.pdf

1386-chenp-2006-form 26.pdf

1386-chenp-2006-form 3.pdf

1386-chenp-2006-form 5.pdf

1386-chenp-2006-pct.pdf

1386-chenp-2010 complete specification as granted.pdf

EXAMINATION REPORT REPLY.PDF