Methods for operating a computer system

Abstract

The invention relates to a method for operating a computer system with two identical central processing units (1, 2), each of which receives input data (l1, l2, l3, l'1, l'2, l'3), executes the same program steps, and delivers results, the results being compared to identify any errors. The method according to the invention is characterized in that a deviation in the input data (l1, l2, l3, l') is detected at least every few clock cycles. 1' , l'2, l'3) of the respective process unit (1, 2) is generated at the same cycle time (t1, t2, t3, t'1, t'2, t'3).

Description

[0001] The invention relates to a method for operating a computer system with two identical central processing units of the type defined in more detail in the preamble of claim 1.

[0002] In computer technology, and especially in the control of systems such as vehicles, it is crucial to continuously monitor their functionality. One method for continuously verifying hardware functionality is the so-called lockstep method. In this method, two identical central processing units (CPUs) with the same architecture are operated in parallel. The results generated by both CPUs based on the same input data are then compared. With functioning hardware, these results should be identical. If they are not, this indicates a hardware fault.

[0003] To reduce the effort required for two identical CPUs, DE 10 2018 214 980 A1 proposes a computer system and operating procedure that utilizes a first and a second processing unit or CPU. These two CPUs execute the same program segment in parallel, although the processing times differ. This allows for the identification of hardware problems through a comparison of verification parameters. The advantage lies in the elimination of the need for redundant, identical processing units with identical computing power. This reduces the hardware requirements.

[0004] For further information on the state of the art, reference can also be made to US 2005 / 0204194 A1 and US 2019 / 0138406 A1.

[0005] Ultimately, however, all these methods share the limitation of only being able to detect (random) hardware errors. For example, if a software error occurs in the lockstep method, leading to an incorrect result, a comparison of the results will not reveal the problem, since both CPUs will generate the incorrect result based on the same input data.

[0006] The object of the present invention is to improve the method according to the preamble of claim 1 in such a way that not only problems in the hardware but also, in particular, problems in the software can be detected by the method.

[0007] According to the invention, this problem is solved by a method with the features in claim 1, and in particular in the characterizing part of claim 1. Advantageous embodiments and further developments are described in the dependent claims.

[0008] The method according to the invention provides for a computer system with two identical central processing units, i.e., CPUs with identical architecture. As in the prior art, these each receive input data and execute the same program steps. They deliver the corresponding results, which can then be compared to identify potential errors. This is sufficient to detect hardware errors in accordance with the lockstep method described above. According to the invention, a deviation of the input data for each central processing unit is additionally generated at the same clock time, and this is done for at least a few clock cycles.

[0009] The inventive method also modifies the input data for each CPU. Within each clock cycle, the input data in one CPU differs slightly from that of the other. The results are therefore slightly different, but can be compared within a tolerance range, provided the input data remains similar.

[0010] For example, when processing video data to capture the surroundings of a vehicle, to capture an interior, to recognize gestures as control instructions, to monitor a driver's blink rate for fatigue monitoring, or similar applications, a slight shift in the video data can be used to detect potential software errors caused by output data that deviates more than tolerated when input data differs slightly.

[0011] To modify the input data simply and efficiently in this sense, a highly advantageous embodiment of the inventive method provides that the deviation of the input data is achieved by changing the clock frequency of one central processing unit relative to that of the other central processing unit. With this very simple solution, the input data remains completely unchanged; only the clock frequency of one CPU is slightly adjusted relative to that of the other. This ensures that different input data is present in each CPU at the respective clock time, and that with a correspondingly small adjustment of the clock times, the differences between these data are minimal, for example, in the case of the sequential data of video processing mentioned above.

[0012] As an alternative to changing the clock frequency, i.e., adjusting the frequency at which each CPU operates, a very advantageous alternative embodiment of the invention allows the clocking to be shifted by at least a fraction of a clock cycle while maintaining the same clock frequency. Both CPUs can thus operate at the same clock frequency. However, the clock start times for one CPU are shifted, for example, by half a clock cycle compared to the other CPU. In each clock cycle, one CPU then receives, for example, sets 1, 2, and 3 of sequential input data, while the other receives sets 2, 3, and 4, assuming the input data is supplied to both CPUs unchanged, as in the previous example.

[0013] Another way to easily modify the input data between the two CPUs when identical input data is supplied is, according to a further very advantageous embodiment of the invention, to also provide for a change in the order of tasks across a clock cycle. The computer system with its CPUs typically executes a certain number of tasks within a clock cycle. If the order of these tasks is changed, this can help, when applied in a classic lockstep, to determine at which task within the clock cycle the hardware problem occurs. It can therefore be used to locate the fault.Additionally, by shifting individual tasks across clock boundaries, a similar effect to the last described example can be achieved, so that different tasks are processed in different clock cycles and thus different input data is available for the respective task at the respective clock time.

[0014] An alternative approach, in which the input data is directly modified without having to intervene in, for example, the cycle times or, more simply, the cycle frequencies of the two central process units, can now provide that the input data is divided between the two central process units via at least one filter.

[0015] Such a filter can therefore ensure that the input data for the two central process units is filtered. Without necessarily requiring a change in the clock frequency (although this is optional), different input data can be provided. For example, such a filter can filter out certain data from the input stream for one central process unit, while all data is fed to the other. This creates a shift in the input data, which, as described above, is then suitable for detecting software errors when comparing the results.

[0016] According to an exceptionally useful advanced training, the aforementioned sequential input data can be filtered, for example, by even or odd sequence numbers, to route the input data to one central processing unit or another. For instance, in a video sequence, all images with even sequence numbers can be sent to the first central processing unit, and all video images with odd sequence numbers to the other. This does not delay processing; however, even with slightly different input data, the functionality of the software and, through the underlying lockstep method, the hardware can also be monitored.As an alternative to such a division, for example, all data could be fed to one central process unit, while a filter during the preparation of the input data for the other central process unit deletes some of it, for example every tenth serial number or the like.

[0017] The modification of the input data, whether the input data itself or its processing (e.g., by shifting the clock frequency), can now, according to a highly advantageous embodiment of the method according to the invention, be carried out such that the degree of modification of the input data of one central process unit relative to the input data of another central process unit is predetermined depending on the programmed task and / or the fastest time for a task. The type of data and its processing can thus be taken into account accordingly. The faster the incoming data changes, the smaller the degree of modification can be chosen while still achieving a sufficient change to detect potential software errors.

[0018] As already mentioned, the results are then compared, similar to the prior art, with the addition of a specified tolerance band, so that results within this specified tolerance band are considered equal, and a conclusion is only drawn that there is an error in the software and / or hardware if the comparison results differ so greatly that the difference exceeds the size of the tolerance band.

[0019] Further advantageous embodiments of the method according to the invention also result from the exemplary embodiment and are described in more detail below with reference to the figures.

[0020] This shows: Fig. 1 a schematic representation of a computer system with two identical central processing units, their respective hardware level and a software level to illustrate a classic lockstep procedure; Fig. 2 a representation analogous to the one in Fig. 1 to explain the method according to the invention in a first embodiment; Fig. 3 the left part analogous to the representations in Fig. 1 and Fig. 2 to explain a second variant of the method according to the invention; and Fig. 4 a representation analogous to the one in Fig. 3 to explain a third variant of the method according to the invention.

[0021] In the presentation of the Fig. Figure 1 shows a schematic diagram illustrating a lockstep process known from the prior art, with two variants. The diagram shows the Fig. Figure 1 on the left and right shows two identical CPUs, 1 and 2, i.e., CPUs with identical computer architecture. Each of these CPUs, 1 and 2, is assigned a clock frequency f. This results in the clock times t1, t2, and t3 shown here as examples. The respective CPUs, 1 and 2, are also shown in the diagram. Fig. The left side is labeled HW, which stands for hardware. Between these lines is the software (SW), which runs on the respective CPUs 1 and 2. The lines labeled "Task" show individual sub-steps of the software, the so-called tasks, being processed within CPUs 1 and 2. Here, three tasks A, B, and C are shown as examples for each clock cycle.

[0022] The idea behind the lockstep method is as follows: By running the same software (SW) on two identical CPUs (1 and 2), random hardware errors can be detected by comparing the results. The boxes l1, l2, l3, represented by dashed lines, symbolize the respective input data. If everything is identical, random hardware errors can be detected by comparing the results, as indicated by the arrows in the software layer (SW). In the example shown here, the first task (A) in the second clock cycle (t2) is represented by a solid arrow; this is where the random hardware error occurred, indicated by the two explosions in the area of ​​CPUs 1 and 2. To further improve error detection and also identify systematic errors, the order of the tasks within the respective clock cycles (t1, t2, t3) can be changed.This is shown in the representation of the . Fig. Figure 1 on the right is analogous. Here too, the error is said to have occurred in task A at clock time t2. Due to the swapped order of the tasks, it can be located, for example, in CPU 2.

[0023] The problem with this lockstep method is that software errors cannot be detected. In both hardware environments, with identical architecture, identical software (SW), and identical input data l1, l2, l3, the same task is executed in such a way that it produces the same result. The software is therefore faulty in the same way in both execution cases. The result is identical, and therefore no error can be detected.

[0024] To counteract this, it is now planned to modify the input data l1, l2, l3 of the respective tasks accordingly. This can be done, for example, in the Fig. The procedure is as shown in Figure 2. Both CPUs, 1 and 2, are still built with identical architecture. However, they have different clock frequencies f, so CPU 1 operates at clock frequency f1, and CPU 2 at the different clock frequency f2. Due to the small number of tasks shown per clock cycle t1, t2, t3 or t'1, t'2, t'3, the diagram shows a relatively large deviation. In practice, a deviation in the range of 5 to 10% will typically suffice.

[0025] The effect is that different tasks are run with different input data l1, l2, l3. They therefore have different prerequisites and, even when functioning correctly, deliver similar but not identical results. These results can still be compared by specifying a corresponding tolerance band. If the results lie within this tolerance band—for example, the result of task A in CPU 1 equals the result of task A in CPU 2 ± this tolerance value—the results are still considered "equal." Only if the deviation is greater than the specified tolerance band is an error inferred. This error is typically not detected solely in the hardware, as in the classic lockstep method, but also in the software due to the different input data. Accordingly, the representation of the Fig. 2 of the errors within the comparison arrow are shown as an explosion, here in task B in the respective second clock time t2 or t'2, which is larger due to the changed frequency f2.

[0026] Here too, the principle of the classic lockstep method can be implemented in parallel, so that random hardware errors can still be detected, analogous to the lockstep method. It is also possible to change the order of the tasks accordingly to additionally detect systematic errors and thus improve error detection for hardware errors, as per the lockstep method. This is illustrated in the diagram of the Fig. 2 on the right analogous to the representation in Fig. 1 shown.

[0027] Another possibility, with otherwise identical input data l1, l2, l3, to change the input data for at least some of the tasks, is to leave the clock frequency f of the respective CPUs 1, 2 unchanged, but to shift the start time of the clock cycles, for example by one-third of the respective clock time. In the representation of the Fig. Figure 3 illustrates this accordingly. The respective clock times t1, t2, t3 of the second CPU 2 begin offset by the time interval Δt from those of CPU 1. In practice, this means that the first execution of task C with input data l1 occurs in the first CPU 1, while the first execution with input data l2 occurs in the second CPU 2. The effect and the resulting detectability of software errors correspond to those shown in the illustration of Fig. 3 on the left. Here too, it would be conceivable to swap the tasks in their order, but this is not shown again for the sake of simplicity.

[0028] If the frequencies f1, f2 of the two CPUs 1, 2 are not to be changed, or the clock times t1, t2, t3 are not to be shifted in their start time, then alternatively, or in principle also in addition to one of these methods, the input data l1, l2, l3 themselves can be manipulated. In the representation of the Fig.Figure 4 illustrates this accordingly. CPU 1 receives the input data l1, l2, l3 as before. CPU 2 operates at the same frequency f and the same clock times t1, t2, t3, which start at the same time. However, tasks A, B, and C are provided with different input data l'1, l'2, l'3. This can be achieved, for example, through filtering. For instance, some data can simply be deleted from a data stream. If sequential data is involved, such as when processing video data, the input data stream could also be divided so that input data l1, l2, l3 correspond to the images with an even order, and input data l'1, l'2, l'3 correspond to those with an odd order. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] DE 10 2018 214 980 A1

[0003] US 2005 / 0204194 A1

[0004] US 2019 / 0138406 A1

[0004]

Claims

[1] Method for operating a computer system with two identical central processing units (1, 2), each of which receives input data (l1, l2, l3, l' 1' , l'2, l'3), execute the same program steps and deliver results, comparing the results to identify possible errors, characterized by that in at least some cycles a deviation of the input data (l1, l2, l3, l' 1' , l'2, l'3) of the respective process unit (1, 2) at the same cycle time (t1, t2, t3, t'1, t'2, t'3). [2] Method according to claim 1, characterized by that the deviation of the input data (l1, l2, l3, l'1, l'2, l'3) is achieved by changing the clock frequency (f, f1, f2) of one process unit (1) compared to that of the other process unit (2). [3] Method according to claim 1, characterized by that the deviation of the input data (l1, l2, l3, l' 1', l'2, l'3) is achieved by shifting the clock times (t1, t2, t3) at the same clock frequency (f) by at least a portion (Δt) of a clock cycle (t1, t2, t3). [4] Method according to claim 1, 2 or 3 characterized by that the deviation of the input data (l1, l2, l3, l' 1' , l'2, l'3) is achieved by changing the order of tasks (A, B, C) across at least one clock boundary. [5] Method according to one of claims 1 to 4, characterized by that the deviation of the input data (l1, l2, l3, l' 1' , l'2, l'3) is achieved by the input data (l1, l2, l3, l' 1' , l'2, l'3) are divided between the two central processing units (1, 2) via at least one filter. [6] Method according to claim 5, characterized by that for sequential input data (l1, l2, l3, l' 1' , l'2, l'3) a division of the input data (l1, l2, l3, l' 1', l'2, l'3) to the two central processor units (1, 2) on the basis of even and odd serial numbers. [7] Method according to claim 5, characterized by that the input data (l1, l2, l3) to one of the central processing units (1) pass through a filter which deletes or modifies at least one data record from these input data (l1, l2, l3), while the input data (l'1 l'2, l'3) to the other of the central processing units (2) remain unfiltered. [8] Method according to one of claims 1 to 7, characterized by that a degree of change of the input data (l1, l2, l3, l' 1' , l'2, l'3) of a central processing unit (1) with respect to the input data (l1, l2, l3, l' 1' , l'2, l'3) of the other central processing unit (2) depending on the programmed task and / or the shortest time period within which a task (A, B, C) can be processed. [9] Method according to one of claims 1 to 8; characterized by that the results are compared, with results within a given tolerance band being considered equal.

Images