Method for verifying the processing of software

Abstract

In order to provide simple, fast, and reliable verification of the functioning and processing of an automation task in the form of software in a multi-channel safety-oriented automation component (1), the software (SW1) is run in one channel (K1) of the automation component (1) in an active unit (P1) of the hardware of the channel (K1), and first diversity software (SW3) redundant relative to the software (SW1) is run in a verification unit (V1) in this channel (K1), wherein in a processing step (Z1) input data (E.sub.z) associated with the software (SW1) and first output data (A.sub.z) computed by the software (SW1) in this processing step (Z1) are temporarily stored in a memory unit (M1), and the diversity software (SW3) in the verification unit (V1) computes second output data (A.sub.z) based on the stored input data (E.sub.z) independently of the processing of the software (SW1) in the active unit (P1), and the second output data (A.sub.z) computed by the diversity software (SW3) is compared with the stored first output data (A.sub.z) of the software (SW1) in order to verify the processing.

Claims

1. A method for verifying the processing of an automation task, comprising software (SW1), in a multi-channel safety-oriented automation component, comprising: processing the software (SW1) for hardware of a first active unit (P1) of at least one channel (K1); processing first diversity software (SW3), which is redundant relative to the software (SW1), in a verification unit (V1) in the at least one channel (K1); at least temporarily storing input data (Ez) and first output data (Az) computed by the software (SW1) in a processing step (Z1); computing, in the verification unit (V1), a second output data (Az) by the first diversity software (SW3) based on the at least temporarily stored input data (Ez) and independently of the processing of the software (SW1) in the first active unit (P1); and comparing the second output data (Az) computed by the first diversity software (SW3) with the at least temporarily stored first output data (Az) of the software (SW1) in order to verify the processing of the software (SW1), wherein, due to a difference in processing times, a plurality of processing steps of software (SW1) occur for each processing step of first diversity software (SW3).

2. The method according to claim 1, wherein the processing of the software (SW1) is verified after an nth processing step (Z1) of the software (SW1), where n is a positive integer greater than one.

3. The method according to claim 1, the verification unit (V1) is implemented in a diagnostics unit (D1) in the at least one channel, and the method further comprises processing the first diversity software (SW3) and diagnostics functions comprising diagnostics in the at least one channel.

4. The method according to claim 1, further comprising verifying the processing of the software (SW1) in an at least a second channel (K2) of the multi-channel safety-oriented automation component.

5. The method according to claim 4, wherein output data (Az) are computed respectively in the at least one channel (K1) and in the at least one second channel (K2) of the multi-channel safety-oriented automation component (1) in a processing step (Z2) of the second diversity software (SW2), and the method further comprises comparing the output data (Az) following the processing step (Z2), wherein, due to a difference in processing times, a plurality of processing steps of software (SW1) occur for each processing step of second diversity software (SW2).

6. The method according to claim 1, further comprising: processing a second diversity software (SW2), which is different from the software (SW1), for hardware of a second active unit (P2) of at least one second channel (K2) of the multi-channel safety-oriented automation component.

7. The method according to claim 6, wherein output data (Az) are computed respectively in the at least one channel (K1) and in the at least one second channel (K2) of the multi-channel safety-oriented automation component (1) in a processing step (Z1) of the software (SW1), and the method further comprises comparing the output data (Az) following the processing step (Z1).

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The following discussion describes the invention in more detail below with reference to FIGS. 1 through 3 which depict advantageous embodiments of the invention, this being done by way of example, schematically, and without being restricted thereto. Here

(2) FIG. 1 depicts a safety-oriented automation component of the prior art,

(3) FIG. 2 depicts a safety-oriented automation component of the prior that includes diversity software, and

(4) FIG. 3 depicts a safety-oriented automation component including verification of the automation component processing.

DETAILED DESCRIPTION OF THE EMBODIMENTS

(5) FIG. 1 depicts a safety-oriented automation component 1 according to the prior art. Two channels K1, K2 are implemented therein. Each channel K1, K2 comprises an active unit P1, P2, and a diagnostics unit D1, D2. Active unit P1, P2 is, for example, a processor, a programmable logic controller (e.g., a Field Programmable Gate Array (FPGA)) or a similar component that can process data or perform calculations. Active unit P1, P2 performs an automation task implemented thereon, e.g., data manipulation, a calculation, etc. Diagnostics unit D1, D2 is implemented in the form of a programmable component, such as e.g. a processor, on which diagnostics functions are implemented as software in order to detect and handle errors in active unit P1, P2. Diagnostics unit D1, D2 thus verifies the functioning of active units P1, P2, and intervenes whenever errors are detected, e.g., by deactivating certain functions of active units P1, P2, or by transferring automation component 1 to a reliable state, optionally in connection with outputting an error message, e.g., to a higher-level controller. From input data E such as, e.g., control data or measurement parameters, each channel K1, K2 calculates output parameters A1, A2 that are compared in a comparison unit 2, e.g. a separate comparison unit or also one of active units P1, P2, and are outputted as valid output data A, e.g. control parameters, computed results, etc., if the values are equal. The hardware, here active units P1, P2, can be implemented either diversified or identically.

(6) FIG. 2 depicts an example based on FIG. 1 that includes diversity software in active units P1, P2. The software SW1 in active unit P1 of first channel K1 is faster here than the software SW2 in the active unit of second channel K2. This means that software SW1 of first channel K1e.g., when processing a given automation task, procedure, or given functiongenerally has to wait for software SW2 of second channel K2, e.g. when it processes the same automation task, procedure, or function (as indicated by dashed double arrow), since the results of processing, e.g. output data A1, A2, have to be compared after each processing. Slower software, here SW2, thus determines the speed of the automation components. Verification in the example illustrated is effected, e.g., after a complete code cycle of software SW1, SW2.

(7) FIG. 3 depicts an implementation according to the invention of a multi-channel safety-oriented automation component 1. Each channel K1, K2 here again respectively comprises an active unit P1, P2, and a diagnostics unit D1, D2. Certain diagnostics functions are again programmed in diagnostics units D1, D2 for associated active units P1, P2. The hardware of active units P1, P2 here is homogeneous, and the same software SW1 runs here in both active units P1, P2, i.e., the same software SW1 runs in both channels K1, K2 in the same active units P1, P2.

(8) Instead of software SW1, it is also possible to implement diversity software SW2 redundant relative to software SW1 running in first channel K1 in active unit P2 of second channel K2, as described, e.g., in FIG. 2, without departing from the inventive idea. Likewise, active unit P2 in second channel K2 could also be implemented as diversified hardware.

(9) Diversity software SW3 redundant relative to software SW1 in active unit P1 is now implemented and run in a verification unit V1, e.g. diagnostics unit D1, in first channel K1. The processing of diversity software SW3 in verification unit V1 is thereby decoupled in terms of time from the processing of software SW1 in active unit P1, and thus in processing is independent in terms of time from the processing of software SW1 in active unit P1. Software SW1 in active unit P1 can therefore be e.g. a real-time application, whereas diversity software SW3 in verification unit V1 exhibits a different, in general, slower run time. Diversity software SW3 is nevertheless used in verification unit V1 to verify the processing of software SW1 in active unit P1. However, given slower diversity software SW3, this can now be effected only in each n.sup.th, being a positive integer n>1, processing step Z1 of software SW1. To this end, current input data E.sub.z in first channel K1 for processing step Z1 of software SW1 and output data A.sub.z computed therefrom by software SW1 in active unit P1 of first channel K1 are temporarily stored in a memory unit M1. Diversity software SW3 in verification unit V1 reads this stored input data E.sub.z and output data A.sub.z from memory unit M1. Using this read input data E.sub.z diversity software SW3 also computes output data A.sub.z that must equal to stored output data A.sub.z of software SW1 in active unit P1 if there are no errors. The calculation of output data A.sub.z by diversity software SW3 can take longer than the calculation of output data A.sub.z in active unit P1. For example, the calculation in verification unit V1 can even be slower by a factor of 100 to 1,000 than in active unit P1. If output data A.sub.z and A.sub.z that are compared in verification unit V1 are not equal, there is an error and verification unit V1 initiates an appropriate action, e.g., transferring automation component 1 into a safe state, sending an error message, or initiating another safety-oriented action. Once verification by software SW3 in verification unit V1 is completed, the next verification of current processing step Z1 can start, whereby any intermediate input data E.sub.z and output data A.sub.z computed therefrom by software SW1 do not have to be stored in memory unit M1.

(10) If t.sub.1 is the processing time for a processing step Z1 of software SW1 in active unit P1, and t.sub.2 is the processing time for processing step Z3 of diversity software SW3 in verification unit V1, then it must apply nt.sub.1>t.sub.2.

(11) If verification unit V1, V2 is implemented in diagnostics unit D1, D2, then diversity software SW3 can run additionally apart from the diagnostics functions implemented as diagnostics software in diagnostics unit D1, D2, as indicated in FIG. 3.

(12) The same verification can be effected in parallel in second channel K2, and in each additional channel, between software SW1or SW2 in the case of diversity software in active units P1, P2and diversity software SW3 redundant relative thereto in verification unit V2 of second channel P2.

(13) The processing of software SW1 in active units P1, P2 of channels K1, K2 is therefore not retarded by the verification effected by diversity software SW3 in verification unit V1, V2. Verification of the processing by software SW1 in active units P1, P2 of both channels K1, K2 takes place in every n.sup.th processing step of software SW1.

(14) In addition, in each processing step of software SW1 in first channel K1, output data A1 generated thereby can be compared in comparison unit 2 with output data A2 generated in second channel K1 during this processing step, and this enhances the level of verification for errors. If diversity hardware is used in both channels, it is possible here for delays to occur due to the variation in run times in the various active units P1, P2, which delays, however, are not caused by the diversity software.

(15) Verification of the processing of software SW1 in automation component 1 is thus effected by time-decoupled diversity software SW3, which is implemented, for example, in diagnostics unit D1, D2, and which can monitor or verify every n.sup.th processing step of software SW1. In addition, output data A1, A2 generated by software SW1 from two channels K1, K2 can be compared in the usual way during each processing step of software SW1. As a result, the inherently poorer run-time behavior of diversity software can be compensated by the invention. It is furthermore irrelevant here whether or not diversified hardware is implemented.

(16) Processing step Z is generally considered in this regard to be a complete computing operation in active unit P1, P2 effected by software SW1, SW2 running therein, e.g., a mathematical calculation by software SW1, SW2, the execution of a function or procedure of software SW1, SW2, the processing of input data according to a predefined scheme, a complete code cycle of software SW1, SW2, etc.

(17) Active unit P1 of first channel K1, e.g., can be a processor supported by a floating-point unit FPU, and software SW1 running thereon can be a mathematical code. However, associated diagnostics unit D1 is, e.g., only a simpler processor that has only a floating-point library or a processor that does not use the FPU. Nevertheless the invention, for example, enables the high-performance FPU in active unit P1 to be checked by a low-performance floating-point library in diagnostics unit D1.

(18) Using known methods of so-called coded processing, it is possible by an essentially automated approach to produce diversity software SW3 that is redundant relative to given software SW1. Diversity software SW3 produced thereby is typically a factor of at least 100 times slower than the original software. The invention now enables even diversity software SW3 produced by coded processing to be used, and this enables the expense of producing diversity software SW3 to be substantially reduced.

(19) Despite the fact that the specification has been described only with reference to two-channel safety-oriented automation component 1, the invention can of course be applied analogously to an automation component 1 having more than two channels.