DE102012020442B4 - Method for checking data using at least two checksums - Google Patents

Abstract

Method for checking data in an arithmetic unit at runtime of a program, the arithmetic unit being part of a device with safety-oriented functionality, the data (DATA) being checked with a checksum of the first type (CS2s) and with a checksum of the second type (CS1u), by calculating the checksum of the first type and the checksum of the second type at runtime of the program and in each case comparing them with a stored checksum (CS1u, CS2s), the calculation time required to calculate the checksum of the second type (CS1u) less than the calculation time required at runtime of the program Calculating the first type of checksum (CS2s), - whereby the first type of checksum (CS2s) is calculated when the program is initialized and compared with the stored checksum and the second type of checksum (CS1u) is checked several times during the cyclical check during the program runtime , in particular at regular and / or predefinable time intervals b is calculated and compared with the stored checksum, - the safety-related functionality of the device is continued if the calculated checksums (CS1u, CS2s) match the stored checksums (CS1u, CS2s), and - the device is placed in a safe state , if the calculated checksums (CS1u, CS2s) do not match the stored checksums (CS1u, CS2s), whereby no machine movements are triggered in the safe state, due to which danger to life and limb can arise.

Description

The present invention relates to a method for checking data by means of at least two checksums and a computing unit for carrying it out.

State of the art

The invention is concerned with safety-related software in which data (in particular program code and / or other static (constant) data) are located in a storage unit. The data integrity of this data must be ensured to ensure that the data are not changed during the runtime or lifetime of the device. Such applications can be found, for example, in safety PLCs.

The data can be checked cyclically. A certain degree of diagnostic coverage should be " DC “Can be achieved per test run and the test runs take place within a specified time (eg at least every 8 hours). Security is achieved in that the cyclical test detects data corruption with a predetermined probability at a predetermined cycle time. For example, a test should be achieved every 8 hours with a diagnostic coverage of 99%. This means that data corruption should be detected with a 99% probability with each run (DC = 99%).

The data integrity check can take place using redundancy information. In devices with safety-related functionality, this can be achieved through redundancy information (for example, checksums) that is added to the data to be backed up in connection with a cyclical check. Again, it is checked cyclically (e.g. every 8 hours) whether a calculated checksum still matches a stored checksum of the data. If this is the case, the safety-related function is continued. If this is not the case, the system is put into a safe state. With this e.g. Preventing danger to life and limb if the program code is corrupted, e.g. by Machine movements are triggered that should not be triggered.

In the case of safety-related software, the data integrity must always be checked. It is particularly necessary because the program code or static data usually starts from a non-volatile memory (e.g. flash memory) in a volatile memory ( R.A.M. ) is copied and this program code then from the faster R.A.M. executed or with the static data from the R.A.M. is worked out. The volatile memory ( R.A.M. ) are corrupted, ie program code information or values of the actually static data are changed by unwanted changes to the RAM memory due to software errors. In addition to program code information, static data with which the program works (eg constant variables) must also be saved.

However, the cyclical check in particular causes problems since it is carried out during the runtime of the safety-related software and therefore requires computing power from the executing computing unit, in particular the PLC, or its CPU, which is then not available for other functions.

US 2010/0 332 949 A1 describes in general the formation of two checksums for the identification of fault locations for a region of a memory. Here, a method is carried out to find faulty lines in a memory. However, this method is not carried out to check data in a computing unit at runtime of a program.

WO 2006/108 849 A1 shows a computing unit that is a computing unit of a device with safety-related functionality.

It is therefore desirable to simplify the checking of data in a computing unit.

Disclosure of the invention

According to the invention, a method for checking data by means of at least two checksums with the features of claim 1 is proposed. Advantageous embodiments are the subject of the subclaims and the following description.

The invention is based on the measure of securing the data to be backed up with at least two checksums of different types, a checksum of a first type offering a high level of security with possibly also increased computing power requirements and a checksum of the second type offering a low level of computing power requirements with possibly also reduced security. The first type of checksum is therefore designed for high security, the second type of checksum for low computing power. The checksum of the first type is preferably used during the initialization or when the software is started, the checksum of the second type is used for the cyclical check during the runtime.

Advantages of the invention

Up to now, complex checksums (mostly CRCs) have been used for cyclical testing of safety-related devices, even with large amounts of data, although these are not necessary to achieve the required diagnostic coverage. This is due in particular to possible requirements (e.g. Hamming distances significantly larger 3 ) security when initializing or starting the software, which cannot be met with simple checksums. The invention now links a very secure checksum check at program start or during initialization and a significantly simpler checksum check (regularly or cyclically) during operation.

The invention has the advantage that the first-time data integrity check can be carried out with a significantly better probability of error detection than before, since a computing time requirement is not relevant at this point in time. The subsequent cyclical data integrity check, however, is carried out optimally in terms of computing time.

The first type of checksum is preferably a CRC checksum (cyclic redundancy check). A CRC checksum is based on a polynomial division. Such a checksum can provide higher error detection, but is also more complex to calculate. A CRC checksum has the property that the errors are more recognizable with shorter data. This is called the so-called Hamming distance, this is the minimum number of bits in which two data fields (incl. CRC ) and therefore also the number of arbitrarily distributed errors that can no longer be recognized in every case. For example, a CRC checksum according to IEC 802.3 ( CRC32 ) Diagnostic coverage of approx. 99.99999998% is achieved with large amounts of data.
CRC checksums have the property that the advantage of higher detectability of errors with shorter data when applied to large amounts of data is no longer present and, in the limit case, they only have a slightly better error detection than simple addition checksums.

The checksum of the second type is preferably an addition checksum. Addition checksums are checksums that result from the simple addition of the data. Such a checksum is very easy to calculate and requires little computing capacity. One can estimate that a simple addition checksum is only about 10% of the computing time required by one CRC32 has. Each one-bit error is recognized by means of addition checksums. Two-bit errors are no longer reliably recognized. In general, any data corruption of the data will M Checksum bits detected with a probability of 1-1 / 2 ^M. For example, if you want to achieve diagnostic coverage of 99%, a 7-bit addition checksum is sufficient.

The length of the addition checksum preferably corresponds to the internal memory access data width or the CPU-internal register width (for example 16 . 32 . 64 ... bit) of the executing the software CPU (e.g. safety CPU). It is then usually longer than required by the diagnostic coverage to be adhered to, but this can accelerate memory access and optimize the total computing time required for the checksum calculation.

       for (byte = 0; byte < nBytes; ++byte) 

        {
            checksum = crcTable[data];
        }

According to another embodiment, the checksum of the second type is a CRC checksum, the calculation of which, however, requires less computing time than the calculation of the checksum of the first type. For example, it can be shorter (for example only 8 bits). According to a further preferred embodiment, the checksum of the second type is an 8-bit CRC checksum which uses simple table accesses (table with 256 byte values) to calculate the respective subsequent byte value on the basis of the data byte value, for example according to the scheme:

       for (byte = 0; byte <nBytes; ++ byte) 

         {
            checksum = crcTable [data];
        } 

The person skilled in the software knows how the table (crcTable⌷) must be preset during initialization.

Such a procedure is particularly suitable for short checksums, since the table must have 2 ^M entries, where M is the number of checksum bits.

• • bei einer 8Bit-Prüfsumme nur 99,6% (CRC- oder Additionsprüfsumme)
• • bei einer 16Bit-Prüfsumme 99,998% (CRC- oder Additionsprüfsumme)
• • bei einer 23Bit-Prüfsumme 99,99999998 % (CRC- oder Additionsprüfsumme)

In comparison, a 16-bit or 32-bit addition checksum with comparable computational effort as a Sbittige CRC performs significantly better for long data fields: The diagnostic coverage for long data fields is approximately:

• • with an 8-bit checksum only 99.6% (CRC or addition checksum)
• • 99.998% for a 16-bit checksum (CRC or addition checksum)
• • with a 23-bit checksum 99.99999998% (CRC or addition checksum)

Assuming that the required diagnostic coverage of the cyclical integrity check should be 99%, a 7-bit (in practice 8th Bit) addition checksum. However, due to the typical organization of memories or registers in computers in multiples of 8 bits, an 8-bit calculation is the shortest checksum that is normally implemented.

The data and the checksum of the second type are preferably secured by the checksum of the first type. This ensures that corruption of the simpler checksum is reliably detected when the program starts.

A computing unit according to the invention, for example a PLC , is set up, in particular in terms of programming, to carry out a method according to the invention.

The implementation of the invention in the form of software is also advantageous, since this enables particularly low costs, in particular if an executing computing unit is still used for further tasks and is therefore present anyway. Suitable data carriers for providing the computer program are, in particular, floppy disks, hard disks, flash memory, EEPROMs, CD-ROMs, DVDs, etc. It is also possible to download a program via computer networks (internet, intranet, etc.).

Further advantages and refinements of the invention result from the description and the accompanying drawing.

It goes without saying that the features mentioned above and those yet to be explained below can be used not only in the combination specified in each case, but also in other combinations or on their own without departing from the scope of the present invention.

The invention is illustrated schematically in the drawing using exemplary embodiments and is described in detail below with reference to the drawing.

Figure list

• 1a and 1b each show a preferred embodiment of an arrangement of data and checksums in a memory unit, a checksum of the first type and a checksum of the second type being provided in each case.
• 2a to 2d each show a preferred embodiment of an arrangement of data and checksums in a memory unit, the checksum of the first type each consisting of three partial checksums.
• 3a and 3b each show a preferred embodiment of an arrangement of data and checksums in a memory unit, the checksum of the first type each consisting of three partial checksums and an additional partial checksum.
• 4a and 4b each show a preferred embodiment of an arrangement of data and checksums in a memory unit, the checksum of the first type and the checksum of the second type each consisting of three partial checksums.

Detailed description of the drawing

In the figures, different preferred configurations of the invention are shown using the example of data to be saved and checksums as an arrangement in a storage unit. The data to be backed up are included DATA designated. The first type of checksum ("secure checksum") is called CS_s, the second type of checksum ("unsafe checksum") is called CS_u. The checksum of the first type is preferably used for checking only once, in particular when the program is started, whereas the checksum of the second type is preferably used for checking regularly during program operation. Both checksums are available and are used. The secure checksum CS_s is complex and time-consuming. However, this is usually of minor importance when the program is started (device initialization). The simple checksum CS_u is optimal in terms of computing time, ie it does not load the safety CPU during its actual safety-related work.

In 1a is shown to be a safe checksum CS2s (e.g. 128 bit CRC ) with an uncertain checksum CS1u (e.g. 8 bit addition) is linked. The data and the checksum of the second type are preferably secured by the checksum of the first type. This is in 1b illustrated. This ensures that corruption of the simpler checksum is reliably detected during the first test run (program start).

It can be provided that the checksum of the first type and / or the checksum of the second type each comprise several partial checksums. Accordingly, the data can be divided into several partial data areas. A partial checksum is preferably assigned to each partial data area. This increases security in particular with CRC checksums of the first type, since errors in smaller amounts of data can be detected with greater certainty.

In the 2a and 2 B is shown that three partial data areas DATA1 . DATA2 and DATA3 as well as three associated safe partial checksums CS1s . CS2s and CS3s are provided. The uncertain checksum CS4u is not divided here, but on the entire data DATA directed. 2 B differs from 2a only by placing the partial data areas and partial checksums in the storage unit. The placement according to 2 B , in which the partial data areas are directly adjacent to one another, is advantageous with regard to the generation of the data, since no breaks in the code have to be made, but rather the checksums CS1s . CS2s . CS3s can be attached at the back (likewise 2d . 3b . 4a . 4b) , In 2c is illustrated that the data DATA3 and the uncertain checksum CS4u through the safe partial checksum CS3s are secured. In 2d is illustrated that each partial data area DATA1 . DATA2 and DATA3 along with the uncertain checksum CS4u through the associated secure partial checksum CS1s . CS2s respectively. CS3s is secured (for example, the uncertain checksum CS4u together with the data field DATA3 through the safe partial checksum CS3s be secured).

In the 3a and 3b it is shown that the plurality of partial checksums, each assigned to a partial data area CS1s . CS2S . CS3s together with another partial checksum CS5s form the checksum of the first kind. If a very high level of security is to be achieved, long CRC checksums are required (e.g. 128 bits). However, this can be simplified by using several shorter CRC partial checksums (e.g. 32 bits) that are relatively easy to calculate and securing them with a long additional checksum (e.g. 128 bits). The additional partial checksum is preferred CS5s only about the partial checksums CS1s . CS2S . CS3s (and preferably CS4u ) educated. However, it can also be provided that the additional partial checksum CS5s across all partial data areas DATA1 . DATA2 . DATA3 and all partial checksums CS1s . CS2S . CS3s (and preferably CS4u ) is formed.

In the 4a and 4b is shown that three partial data areas DATA1 . DATA2 and DATA3 as well as three associated safe partial checksums CS1s . CS2s and CS3s and three associated uncertain partial checksums CS4u . CS5u and CS6u are provided. The total effort of a checksum check is almost independent of how many partial data fields a data set is divided into. An initialization or check of the checksum is only required for each partial data field. In the case of relatively large partial data fields, however, this can be neglected in comparison to the formation of the respective checksum. For this reason, the simpler checksum check can optionally be broken down into several smaller partial data fields. This does not result in an increase in the diagnostic coverage if, as an assumption of an addition checksum, it is assumed that only a detection of 1-1 / 2 ^{M is} achieved for the partial data field. However, this can significantly reduce the likelihood that data corruption will remain undetected without complex and complex algorithms. Since all checksums of the k Sub data fields CS4u , ..., CS6u would have to be falsified undetected, this probability increases to 1-1 / 2 ^(kM) with the number k of the checksums.

Claims (14)

Method for checking data in an arithmetic unit at runtime of a program, the arithmetic unit being part of a device with safety-related functionality, the data (DATA) being checked with a checksum of the first type (CS2s) and with a checksum of the second type (CS1u), by calculating the checksum of the first type and the checksum of the second type at runtime of the program and comparing each with a stored checksum (CS1u, CS2s), the calculation time required to calculate the checksum of the second type (CS1u) less than the calculation time required at runtime of the program Calculating the first type of checksum (CS2s), - The checksum of the first type (CS2s) is calculated during the initialization of the program and compared with the stored checksum and the checksum of the second type (CS1u) is calculated several times during the cycle of the program, in particular at regular and / or specifiable time intervals and compared with the stored checksum, - The safety-related functionality of the device is continued when the calculated checksums (CS1u, CS2s) match the stored checksums (CS1u, CS2s), and - whereby the device is put into a safe state if the calculated checksums (CS1u, CS2s) do not match the stored checksums (CS1u, CS2s), whereby no machine movements are triggered in the safe state, due to which danger to life and limb arises can. Procedure according to Claim 1 , whereby the checksum of the first type (CS2s) is calculated less frequently than the checksum of the second type (CS1u) at program runtime. Procedure according to Claim 1 or 2 , the first type of checksum (CS2s) being a CRC checksum. Procedure according to Claim 3 , wherein the checksum of the second type (CS1u) is a CRC checksum, the length of which is shorter than that of the checksum of the first type (CS2s). Procedure according to one of the Claims 1 to 4 , wherein the checksum of the second type (CS1u) is an addition checksum, the length of which preferably corresponds to the internal memory access data width or a register width of a processor of the computing unit executing the program. Method according to one of the preceding claims, wherein the checksum of the first type (CS2s) is calculated via the data (DATA) and via the checksum of the second type (CS1u). Method according to one of the preceding claims, the data (DATA) being divided into a plurality of partial data areas (DATA1, DATA2, DATA3) and a partial checksum of the first type (CS1s, CS2s, CS3s) for each of the plurality of partial data areas (DATA1, DATA2, DATA3). and / or a partial checksum of the second type (CS4u, CS5u, CS6u) is calculated. Procedure according to Claim 7 , wherein a further partial checksum of the first type (CS5s) is calculated via the respective partial checksum of the first type (CS1s, CS2s, CS3s) for each of the plurality of partial data areas (DATA1, DATA2, DATA3). Method according to one of the preceding claims, wherein the data to be checked are copied from a non-volatile memory to a volatile memory of the computing unit before the check and the data in the volatile memory are checked. Method according to one of the preceding claims, wherein a diagnostic coverage achievable by the checksum of the first type (CS2s) is higher than a diagnostic coverage achievable by the checksum of the second type (CS1u). Method according to one of the preceding claims, wherein a predetermined diagnostic coverage can be achieved from the checksum of the first type (CS2s) and / or from the checksum of the second type (CS1u). Computing unit which is set up to carry out a method according to one of the preceding claims. Safety PLC with an arithmetic unit Claim 12 , whereby the safety PLC is the device with safety-related functionality. Machine-readable storage medium with a computer program stored on it with program code means that a computing unit after Claim 12 or a safety PLC after Claim 13 to initiate a procedure according to one of the Claims 1 to 11 to be carried out when the machine-readable storage medium is loaded into a memory of the computing unit and the program code means are executed.

Images