WO2013016831A1 - Tabellengesteuertes system - Google Patents

Tabellengesteuertes system Download PDF

Info

Publication number
WO2013016831A1
WO2013016831A1 PCT/CH2012/000162 CH2012000162W WO2013016831A1 WO 2013016831 A1 WO2013016831 A1 WO 2013016831A1 CH 2012000162 W CH2012000162 W CH 2012000162W WO 2013016831 A1 WO2013016831 A1 WO 2013016831A1
Authority
WO
WIPO (PCT)
Prior art keywords
value
output
input
check
test
Prior art date
Application number
PCT/CH2012/000162
Other languages
English (en)
French (fr)
Inventor
David Peter MÜLLER
Original Assignee
Supercomputing Systems Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Supercomputing Systems Ag filed Critical Supercomputing Systems Ag
Publication of WO2013016831A1 publication Critical patent/WO2013016831A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/045—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using logic state machines, consisting only of a memory or a programmable logic device containing the logic for the controlled machine and in which the state of its outputs is dependent on the state of its inputs or part of its own output states, e.g. binary decision controllers, finite state controllers

Definitions

  • the invention relates to control systems in which a control signal is determined as a function of a number of input data.
  • the invention relates to a control system to which high security requirements are placed, for example a traffic safety system, a signal box for railway traffic, the control of a complex manufacturing plant, etc.
  • the invention further relates in particular to a table-controlled system.
  • Logic functions can be implemented by mapping their truth table into a lookup table into a memory. Such a lookup table assigns an output value to every possible input value within an input data set.
  • a lookup table is generated offline before use, often by software.
  • Lookup tables are suitable for implementing even complicated and / or not directly accessible logic functions; In addition, they enable very fast data processing.
  • Figures 6a and 6b show examples of lookup tables according to the prior art.
  • the input value (INPUT) is optionally protected by a checksum (CHK IN). This can be checked in the input stage, and if it does not match the value expected for INPUT, an error response can be triggered, which may include, among other things, no lookup for any output value (OUT) in the table.
  • CHK IN checksum
  • the initial value is optionally backed up by a checksum.
  • This can be calculated by a suitable unit from the initial value (FIG. 6a) or it can already be stored in the table (FIG. 6b).
  • the second variant requires a bit more memory in the table, but less system processing power. As a major difference, the second variant ensures the system but against random, error-related changes in the table contents ('bit-flips') because in this case, the checksum of the output value is no longer consistent with this.
  • a consistent checksum is also calculated for a false OUTPUT value in the table, and the error can not be detected.
  • the invention is essentially characterized in that a control system has a look-up table, i. a data memory in which an input value (an address) is assigned a table value.
  • the table value corresponds to the initial value, or the output value is generated from the table value by further steps (for example, linking to other results of lookup processes).
  • the data stored in the table, as well as the table value which can be addressed by the input value also contain a check value.
  • Test data (often called “checksums”; the term “checksum” is not necessarily intended to imply that test data must be calculated by summation, but other algorithms / algorithms are also suitable for the determination) are known per se for data transmission and belong to State of the art. They are used, for example, in most commercial data transmission systems such as Ethernet etc. In safety-related systems, they are often required to secure data transmission, see eg CENELEC, standard EN 50159-1.
  • the checksum is calculated during the data transmission by the sender from the data to be transmitted and sent to the attached actual data packet to be transmitted. The receiver recalculates the checksum from the received data and compares this value with the checksum sent in the packet.
  • the test data can be determined when creating the table ('offline'); Generally, they are calculated by software. The accuracy of the test data can optionally be verified by independent software.
  • a method for determining the test data for example, mathematical methods known per se for checksums can be used.
  • a corresponding mathematical function can for example be designed such that test data of constant length are generated from bit sequences of possibly different lengths.
  • An example of such a function is CRC n, where "CRC” stands for "cyclic redundancy check” and n represents the number of bits of the check data (checksum); eg CRC 32.
  • the table value check values can be calculated on the basis of such a function known per se.
  • the table value check value depends not only on the table value but also on the input value or its check value.
  • each table value which is passed as an output value can be assigned an output value check value, which alternatively also has a predefined function of the type mentioned above could be calculated from the initial value.
  • a function may be, for example, a CRC or other known test data function.
  • an input value check value is associated with the received input value, which, for example, can likewise be determined from the input value using the predetermined function (eg CRC).
  • the table value check value does not necessarily correspond to the check function value of the table value (ie, it is not equal to the output value check value).
  • the system proposed here can be designed such that the output value test value can be determined from a combination of the input value test value with the table value test value. This is done so that the output value check value depends on both the input value check value and the table value check value, for example, so that a bit error of at least one (significant) bit of the input value check value or a bit error of the table value check value each cause the output test value no longer corresponds to the result of the application of the function to the output value.
  • the table value check value depends not only on the table value but also on the input value (ie on the address), an error in reading from the table will also produce a non-integral pair of output value / output value check value the table value read table value is correct per se.
  • linking of two data is thus here preferably understood as an operation which is designed in such a way that the result depends on both data. This can be done so that any data bit change in any of the linked data causes a change in the result of the join, or so that at least each one of them Data bit modification of significant (used) bits of one of the linked data causes a change in the result.
  • the result of the join be the same bit length as the linked data (which is of course the case with the bitwise XOR); however, other links are not excluded. It is also possible that, when linking the table value check value with the input value check value, further data are taken into account, for example selection or mask data.
  • the determination of the output value check value from the input value check value and the table value check value is preferably such that the result depends on both the input value check value and the table value check value (and possibly other data).
  • this is done in particular such that the predetermined (test value) function is not required for determining the output value test value.
  • the receiver ie, the downstream stage
  • every error case results in an output value check value that is not consistent with the output value ('start-target data backup').
  • the localization of a possible source of error within the processing chain can, if necessary, be achieved by storing the intermediate values and checking them by a suitable independent system (eg in software).
  • the logic unit is not at all capable of calculating test values, but only to combine test values. This ensures that it is not possible, for example due to a system malfunction, to assign a wrongly calculated check value to an incorrect table value - instead of the one derived by the link which correctly indicates the occurrence of a malfunction due to its inconsistency with the output value.
  • An erroneous calculation of a test value from the output value could, in principle, bypass the safety mechanism of the system - it is safely prevented by having no code for calculating test values in the system.
  • system or logic level itself may include error disclosure mechanisms, e.g. in the logic unit itself or in a paged error disclosure unit.
  • Error disclosure mechanisms include, for example, applying the check value function to the input value, or applying the check value function to the output value and comparing it to the corresponding check value.
  • Such error disclosure mechanisms may be required by the standard and may be advantageous in terms of safety, especially with regard to the possibility that two independent errors could compensate each other.
  • it can be ensured, for example, by suitable measures, that no data can flow from the error disclosure unit to the actual logic unit (feedback-free communication, unidirectional communication).
  • the inventive approach allows - be it in the system itself or in the downstream stage - an error detection by a simple comparison of the determined output value test value with the result of applying the test value function to the output value. If the result of error detection is negative, the system goes into a safe state
  • the approach thus complies with the fail-safe principle.
  • the output value (or the output data signal) or a signal derived therefrom can be used as the control signal.
  • the actual conversion of control signals in controls is not the subject of the present invention and will not be discussed in more detail here.
  • Lookup tables are commercially feasible only for input values of a limited bit width because of the combinatorial possibilities (exponential growth of the necessary memory).
  • the bit width of the output value is much less critical, since this only leads to a linear growth of the necessary memory.
  • control system (or control subsystem) can be easily used by appropriate measures also for systems in which the input data are very large and a single lookup table would be very large and therefore difficult to handle.
  • mechanisms may be provided which with the separation of input data (in particular with parallel data lines, this can also be done by a suitable device of the hardware) and / or the application of masks to the input data from the input values reduced input values or multiple partial values as addresses for a or generate multiple lookup tables. This may be accompanied by masks of relevant input value bits and the subsequent selection of a relevant lookup table from a series of lookup tables.
  • each Selection, masking or other step taken into account in determining the output value test value each Selection, masking or other step taken into account, such that the output value check value no longer matches the output value (ie no longer corresponds to the result of applying the predetermined check value function to the output value) if any step has an error.
  • the invention also relates to a corresponding method for determining a control signal.
  • a method for determining a control signal may be carried out, for example, by operating a controller of the type discussed above.
  • the method is for determining a control signal based on at least one input signal representing an input value with an input value check value and comprises the following steps:
  • this step is carried out, for example, before the runtime of the system); - reading out an output value from the data memory using the input value or a variable derived therefrom as the address;
  • the integrity control can be carried out in the system determining the output value itself and / or also in a downstream stage - for example, the element executing the control command. For example, if the result of the integrity check is negative, the output value is discarded. Depending on this, this may be accompanied by a request for retransmission of the input value, a new determination of the output value, error logging, a warning signal to the user and / or further measures. In the case of logging the error can be provided that the system is stopped when a certain error rate is exceeded, and / or that when exceeding such an error rate, a warning to the user.
  • FIG. 1 shows a basic embodiment of a system with look-up table
  • FIG. 2 shows a variant with error disclosures
  • FIG. 3 shows an embodiment with a plurality of subsystems
  • FIG. 4 shows a multi-stage system
  • FIG. 5 shows an embodiment with masking out of irrelevant bits
  • Figures 6a and 6b a system according to the prior art.
  • FIG. 1 A basic embodiment of the invention is illustrated in FIG.
  • CHK IN input value check value
  • Such may be redundant (i.e., it will not contain information that is not derivable from the actual value "INPUT"), and it may be derivable from the input value, for example, using a common method. For example:
  • the system may first use the input test value to detect errors in the data transfer from the upstream system and other errors caused by the upstream system.
  • the table contains a number of values which can be called up by the input value (the input values are quasi the, addresses') of the table.
  • CHK table value check value
  • CHK_OUT: CHK_IN XOR CHK (2)
  • the subordinate system / subordinate stage can check the security of the table, the security of the reading process from the table, and the security of the data transmission with a single error disclosure request (integrity control). If CHK OUT corresponds to the value subsequently calculated for OUT, no error has occurred:
  • This procedure ensures a continuous safety chain.
  • the receiver can check if the correct value has been read in the right place. A bit error in the table, reading or handing over of the output value will cause the error disclosure to detect an error, whereupon the value can be discarded.
  • the system may be halted or any other suitable action taken.
  • the system itself is not capable of calculating a check value-that is, the function CHK (X) is not implemented in the system. Such an implementation is also not required because the system only needs to link stored test values and received test values.
  • the system is not capable of generating a test value, it can also be ruled out with certainty that the system will erroneously pass on a calculated test value instead of the test value CHK OUT determined by the program manipulation or other error and thereby erroneously bypass the safety function.
  • error disclosure may be required, for example, by a standard.
  • FIG. 2 shows a system analogous to FIG. 1 with additional, optional error disclosure functionality.
  • the error disclosure can be done in the system itself or in a decoupled independent system.
  • the elements corresponding to FIG. 1 and associated steps are analogous to the elements / steps described above.
  • All embodiments of the inventions in particular embodiments of the systems described above and / or of the systems described below may optionally be provided with an additional mechanism which allows a permanent self-examination of the system.
  • an additional mechanism which allows a permanent self-examination of the system.
  • transmission errors are detected and monitored on the protocol layer lying deeper according to the OSI model. Single errors are corrected on this layer. If errors occur too often, the system is no longer safe.
  • the table can be read cyclically from the memory; A checksum is calculated over the read-out table and compared against the correct value. If differences occur, the table must be saved again. If differences occur too often, the system is no longer secure.
  • ECC Error Correcting Code
  • lookup tables can be combined by using a certain portion of the input value as an address for a first table and a certain other part of the input value as an address for a second table, with the output values of the two tables being rearranged on the output side can. Also for this situation, embodiments of the invention provide a secure solution.
  • FIG. 1 A corresponding scheme is shown in FIG.
  • two lookup tables (Lookup Table 1, Lookup Table 2) are combined.
  • the MASK and MASK2 masks are used to select the bits relevant for Table 1 and Table 2, respectively; With the selected bits ADDR1 or ADDR2 as addresses, the desired table value OUT1 or OUT2 is read out.
  • ADDR1: MASK1 AND INPUT (4)
  • AND is to be understood in equation (4) as a bitwise AND operation between the two operands; Bit positions at which the mask is set to '0' are simultaneously faded out of the bit sequence.
  • ADDR1 thus has a bit length which corresponds to the number of set bits in MASK1. If only a few bits are set in the mask, the bit width of the address can be significantly reduced.
  • Tables 1 and 2 contain, in addition to the table values 0UT1 and OUT2, also table value check values CHK1 and CHK2, which are calculated in advance and stored in the table. As described above with reference to FIG.
  • CHK INl F_CHK (MASK1 AND IN) (5)
  • test value is simply determined with the test value function from the selected part of the input value.
  • This is a viable option for medium security systems.
  • It has a potential disadvantage.
  • the test value is newly derived from an intermediate value MASK1 AND IN in the calculation. If this intermediate value is incorrect, then a valid checksum is erroneously generated and the protection of the data collapses.
  • Another possibility would be to use the check value CHK IN of the whole input value according to equation (2).
  • This solution solves the security problem.
  • it has the potential disadvantage that even non-relevant errors can be detected and lead to a stop. This disadvantage does not always have to be serious and can be accepted depending on the one. With this variant, the size of the tables can not be ideally reduced.
  • the check value CHK IN of the entire input value is used, but corrected by all contributions which originate from non-relevant bits of the input value. This can happen, for example, as follows:
  • CHK IN1 CHKJN XOR F_CHK (NOT (MASK 1) AND IN) (6)
  • the check value CHK IN generated by the upstream system is corrected by the masked bits. Only if the checksum transmitted by the source system, all values and the data manipulations (mask out, adjustment of the checksum) are correct, can a valid checksum be created again. In the exemplary embodiment according to equation (6), this is based on the following principle.
  • the CRC represents a standard variant for the check value calculation FCHK (X).
  • a characteristic of the CRC is that 'flipping' (inverting) a particular position in the data field always results in the same change ('delta') of the CRC.
  • the 'delta' can be technically 'added' to the existing checksum by a simple XOR operation.
  • CHK_0UT1 CHK_IN1 XOR (MASKI XOR (MASKl AND IN)) XOR CHKl
  • the XOR operation (in addition to CHK_IN1 and CHKl) with the value MASKl XOR (MASKl AND IN) also includes the masking function MASKl in the test value formation; This ensures that the correct MASKl parameter is used for masking even at runtime.
  • the output values OUT1, OUT2, ... can be linked together if necessary, for example, concatenated.
  • the Check values can be linked accordingly, for example also by concatenation or by an XOR or another operation.
  • a certain number of input value bits may come from a first device (eg, a sensor array) or otherwise be in communication with each other, and may already be disconnected from the other input bits by the hardware, for example a first table led, further bits - eg of further plants - are led on further tables.
  • the results of the table are one or more bits wide and are merged into a new input value for the subsequent stage of the cascade - the INPUT of the second stage table is the concatenate of the output values OUT1, OUT2 of the first stage.
  • the checksum of the new input value can be calculated directly from the checksums of the intermediate results. This is shown in FIG.
  • the first two lookup tables, lookup table and lookup table 2 correspond to the first stage of the cascade and the third lookup table to the second stage.
  • the output data OUTn are related and used as addresses for the second stage.
  • the test values are also linked to a CHK IN test value.
  • With the associated input values with the linked test data of the first stage the procedure analogous to FIG. 1 is again carried out in the second stage.
  • a generalization to only one table (where appropriate) in the first stage or on three or more tables in the first stage and on several tables in a second stage and on further stages in the cascade is of course possible. Applications are also conceivable in which different branches of the cascade have a different number of cascade stages.
  • one or more optional error disclosure levels may be present.
  • Such an error disclosure can, as in FIG. 2, include a comparison of the test value with a value calculated from the data value with FCHK.
  • FIG. 1 An example is explained in more detail in FIG. This example is based on the assumption that different scenarios exist. Depending on the scenario, other bits of the input data IN are relevant and are selected with a corresponding mask. In the example shown, there are two scenarios, for example in the case of an interlocking control "train from the right” and “train from the left”.
  • SELMASK selection criterion
  • the masks SELMASK1 or SELMASK2 select from the input data those bits which must have given values for the presence of Scenario 1 or Scenario 2 (for example, train has passed threshold on the left or right of the signal box).
  • the comparison with the corresponding default value SEL1 or SEL2 delivers a data bit (yes / no) SELECT1 or SELECT2. Since only one selection criterion should always be satisfied, one of the two selection steps (8) or (9) or rich m-1 selection steps suffices, in principle. However, as discussed below, redundant selection as shown may serve as an additional security feature.
  • CHK OUT1 The determination of CHK OUT1 takes place in the example shown according to:
  • CHK_OUTl CH_IN XOR (MASK1 XOR (MASK1 AND IN)) XOR
  • CHK_OUT2 CHK_IN XOR (MASK2 XOR (MASK2 AND IN)) XOR
  • the function MASKn is therefore included in the test value derivation, so that a corresponding error leads to an incorrect test value.
  • the selector (multiplexer) M uses one of the two data bits SELECT1 or SELECT2 - in the drawn example using SELECT2 - to select the relevant value pair for the selected scenario and forwards it as OUT
  • CHK_OUTn CHK_IN XOR (MASKn XOR (MASKn AND IN)) XOR CHKn
  • the system itself may not be able to calculate a check value - i. the function CHK (X) is then not implemented in the system.
  • the system according to FIG. 5 itself has an error disclosure functionality.
  • any combination of the five optional error disclosures designated FOB 1 - FOB 5 in FIG. 5 may be implemented:
  • FOB2 and FOB3 check analogous to the output-side error check according to Figure 2 that no wrong value pairs are passed from the respective table.
  • the combination with SELECTl or SELECT2 ensures that only one of the two pairs of values - namely the one corresponding to the scenario "correct" value pair "- has a suitable check value - in all non-active scenarios, this formula can even actively request that the test value does not correspond to the initial value.
  • FOB4 NOT SELECT1 XOR SELECT2
  • FOB5 corresponds to the output-side error disclosure, as it is also feasible in a downstream system.
  • FOB5 corresponds to the output-side error disclosure, as it is also feasible in a downstream system.
  • check value determination is done via a CRC function and the link to XOR, this is not necessary.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Detection And Correction Of Errors (AREA)

Abstract

Die Erfindung zeichnet sich im Wesentlichen dadurch aus, dass ein Steuerungssystem eine Lookup-Tabelle aufweist, d.h. einen Datenspeicher bei dem einem Eingangswert (einer Adresse) ein Tabellenwert zugeordnet wird. Der Tabellenwert entspricht dem Ausgangswert, oder aus dem Tabellenwert wird der Ausgangswert durch weitere Schritte (bspw. Verknüpfung mit anderen Resultaten von Lookup-Prozessen) generiert. Gemäss dem Ansatz der Erfindung enthalten die in der Tabelle gespeicherten Daten nebst dem durch den Eingangswert adressierbaren Tabellenwert auch einen Tabellenwert-Prüfwert. Dieser Tabellenwert-Prüfwert schützt sowohl den Eingangswert wie auch den Ausgangswert; wird der Ausgangswert-Prüfwert direkt aus dem Eingangswert-Prüfwert und diesem Tabellen- Prüfwert berechnet, so deckt dieser die gesamte Signalverarbeitungskette ab und garantiert die Richtigkeit und Sicherheit des gesamten Systems.

Description

TABELLENGESTEUERTES SYSTEM
Die Erfindung betrifft Steuerungssysteme, bei welchen ein Steuersignal in Funktion einer Anzahl von Eingangsdaten ermittelt wird. Die Erfindung betrifft insbesondere ein Steuerungsysstem, an welches hohe Sicherheitsanforderungen gestellt werden, beispielsweise ein Verkehrssicherungssystem, ein Stellwerk für den Eisenbahnverkehr, die Steuerung einer komplexen Fabrikationsanlage, etc. Die Erfindung betrifft im Weiteren insbesondere ein tabellengesteuertes System.
Logikfunktionen können durch die Abbildung ihrer Wahrheitstabelle in einer Lookup-Tabelle (Nachschlagetabelle) in einen Speicher implementiert werden. Eine solche Lookup-Tabelle ordnet jedem möglichen Eingangswert innerhalb einer Eingangswert-Datenmenge einen Ausgabe wert zu. Eine Lookup-Tabelle wird vor ihrem Gebrauch (offline) erzeugt, oft durch eine Software.
Lookup-Tabellen sind geeignet, auch komplizierte und/oder einer Berechnung nicht direkt zugängliche Logikfunktionen zu implementieren; ausserdem ermöglichen sie eine sehr schnelle Datenverarbeitung.
Eventuelle Bitfehler im Speicher oder in der Übertragung des Eingangswertes führen jedoch zu nicht detektierten Fehlern. Daher gilt eine Lookup-Tabelle als nicht sicher. In sicherheitsrelevanten Systemen muss daher meist auf den Einsatz des effizienten und schnellen Mittels ,Lookup-Tabelle' verzichtet werden.
Figuren 6a und 6b zeigen Beispiele für Lookup-Tabellen gemäss dem Stand der Technik. Der Eingangswert (INPUT) ist optional durch eine Prüfsumme (CHK IN) geschützt. Diese kann in der Eingangsstufe überprüft werden und bei nicht- Übereinstimmung mit dem für INPUT erwarteten Wert kann eine Fehlerreaktion ausgelöst werden, welche unter anderem beinhalten kann, dass kein Ausgangswert (OUT) in der Tabelle nachgeschlagen wird.
Der Ausgangswert wird optional wieder durch eine Prüfsumme gesichert. Diese kann durch eine geeignete Einheit aus dem Ausgangswert berechnet werden (Figur 6a) oder sie kann bereits in der Tabelle hinterlegt sein (Figur 6b). Die zweite Variante erfordert etwas mehr Speicherplatz in der Tabelle, dafür etwas weniger Rechenleistung des Systems. Als wesentlicher Unterschied sichert die zweite Variante das System aber bereits gegen zufällige, fehlerbedingte Veränderungen des Tabelleninhaltes (, Bit-Flips') da in diesem Falle die Prüfsumme des Ausgangswertes nicht mehr mit diesem konsistent ist. In der in Figur 6a gezeigten Variante wird hingegen auch für einen falschen OUTPUT-Wert in der Tabelle eine dazu konsistente Prüfsumme errechnet und der Fehler kann nicht entdeckt werden.
Beiden Varianten ist jedoch gemeinsam, dass ein der Akt des Tabellen-Lookup selbst durch keine Prüfsumme geschützt ist. Vielmehr wird das Auslesen eines , falschen' Tabellenwerts (OUT), d.h. eines nicht zur Adresse INPUT zugeordneten Tabellenwerts, in beiden Fällen ein als integer angesehenes Wertepaar OUT, CHK_OUT weitergegeben, und der Fehler wird nicht erkannt. Für sicherheitsrelevante Steuerungssysteme ist diese Einschränkung schwerwiegend und tabellenbasierte Systeme gemäss dem Stand der Technik können nur mit einigem zusätzlichem Aufwand (permanente Selbstüberprüfung; vergleich mit redundanten Systemen, etc.) eingesetzt werden.
Es ist eine Aufgabe der vorliegenden Erfindung, hier Abhilfe zu schaffen und ein sicheres, tabellengesteuertes System zu schaffen.
Diese Aufgabe wird durch die Erfindung gelöst, wie sie in den Patentansprüchen definiert ist.
Die Erfindung zeichnet sich im Wesentlichen dadurch aus, dass ein Steuerungssystem eine Lookup-Tabelle aufweist, d.h. einen Datenspeicher bei dem einem Eingangswert (einer Adresse) ein Tabellenwert zugeordnet wird. Der Tabellenwert entspricht dem Ausgangswert, oder aus dem Tabellenwert wird der Ausgangswert durch weitere Schritte (bspw. Verknüpfung mit anderen Resultaten von Lookup-Prozessen) generiert. Gemäss dem Ansatz der Erfindung enthalten die in der Tabelle gespeicherten Daten nebst dem durch den Eingangswert adressierbaren Tabellenwert auch einen Prüfwert.
Prüfdaten (oft „Prüfsummen" genannt; der Begriff „Prüfsumme" soll nicht notwendigerweise implizieren, dass die Prüfdaten durch Summenbildung errechnet werden müssen; vielmehr kommen auch andere Verfahren/Algorithmen für die Ermittlung in Frage) sind an sich für die Datenübertragung bekannt und gehören zum Stand der Technik. Sie werden beispielsweise in den meisten kommerziellen Datenübertragungssystemen wie Ethernet etc. eingesetzt. In sicherheitsrelevanten Systemen sind sie zur Sicherung der Datenübertragung oft gar vorgeschrieben, siehe z.B. CENELEC, Norm EN 50159-1. Die Prüfsumme wird bei der Datenübertragung durch den Absender aus den zu übertragenden Daten berechnet und an das eigentliche zu übertragende Datenpaket angehängt. Der Empfänger berechnet die Prüfsumme aus den erhaltenen Daten neu und vergleicht diesen Wert mit der im Paket mitgeschickten Prüfsumme.
Gemäss dem Ansatz der Erfindung werden nun Einträge in einer Lookup-Tabelle mit Prüfdaten ergänzt. Es hat sich gezeigt, dass dieser Ansatz auch die Sicherheit von Lookup-Tabellen verbessern kann, selbst wenn dabei nicht dem vorstehend beschriebenen Sender-Empfänger-Schema gefolgt wird. Daher ist gemäss der Erfindung auch eine Anwendung für - unter Umständen sicherheitsrelevante - Steuerungen möglich.
Die Prüfdaten können beim Erstellen der Tabelle (, offline') bestimmt werden; im Allgemeinen werden sie von einer Software berechnet. Die Richtigkeit der Prüfdaten kann optional durch eine unabhängige Software verifiziert werden. Als Verfahren zum Bestimmen der Prüfdaten können beispielsweise mathematische Verfahren verwendet werden, wie sie an sich für Prüfsummen bekannt sind. Eine entsprechende mathematische Funktion kann beispielsweise so ausgebildet sein, dass aus Bitfolgen von unter Umständen verschiedener Länge Prüfdaten konstanter Länge erzeugt werden. Ein Beispiel einer solchen Funktion ist CRC n, wobei„CRC" für„Cyclic Redundancy Check" steht und n die Anzahl der Bits der Prüfdaten (Prüfsumme) darstellt; bspw. CRC 32. Die Tabellenwert-Prüfwerte können auf Basis einer solchen an sich bekannten Funktion berechenbar sein.
Gemäss einem bevorzugten Ansatz ist der Tabellenwert-Prüfwert nicht nur vom Tabellenwert, sondern auch vom Eingangswert - bzw. dessen Prüfwert - abhängig. Auch in Ausführungsformen nach diesem Ansatz kann jedem Tabellenwert, der als Ausgangswert weitergegeben wird, ein Ausgangswert-Prüfwert zugeordnet werden, der alternativ auch mit einer vorgegebenen Funktion der vorstehend erwähnten Art aus dem Ausgangswert berechnet werden könnte. Eine solche Funktion kann bspw. eine CRC- oder eine andere bekannte Prüfdaten-Funktion sein. Bei dieser Gruppe von Ausführungsformen geht man davon aus, dass, wie an sich bekannt, dem empfangenen Eingangswert ein Eingangswert-Prüfwert zugeordnet ist, der bspw. ebenfalls mit der vorgegebenen Funktion (z.B. CRC) aus dem Eingangswert bestimmbar ist. Der Tabellenwert-Prüfwert entspricht dann jedoch nicht notwendigerweise dem Prüffunktionswert des Tabellenwerts (d.h. er ist nicht gleich dem Ausgangs wert-Prüfwert).
Vielmehr kann das hier vorgeschlagene System so gestaltet sein, dass der Ausgangswert-Prüfwert aus einer Verknüpfung des Eingangswert-Prüfwerts mit dem Tabellenwert-Prüfwert bestimmbar ist. Dies geschieht so, dass der Ausgangswert- Prüfwert sowohl vom Eingangswert-Prüfwert als auch vom Tabellenwert-Prüfwert abhängt, bspw. so dass ein Bitfehler mindestens eines (signifikanten) Bits des Eingangswert-Prüfwerts oder ein Bitfehler des Tabellenwert-Prüfwerts je dazu führen, dass der Ausgangswert-Prüfwert nicht mehr dem Resultat der Anwendung der Funktion auf den Ausgangswert entspricht.
Dadurch, dass der Tabellenwert-Prüfwert nicht nur vom Tabellenwert, sondern auch vom Eingangswert (d.h. von der Adresse) abhängt, wird auch ein Fehler beim Auslesen aus der Tabelle ein nicht integres Paar von Ausgangswert/Ausgangswert- Prüfwert erzeugen - selbst dann wenn der mit dem Tabellenwert ausgelesene Tabellenwert-Prüfwert an sich korrekt ist.
Unter , Verknüpfung' zweier Daten wird hier also bevorzugt eine Operation verstanden, die so ausgebildet ist, dass das Resultat von beiden Daten abhängt. Dies kann so geschehen, dass jede Datenbit-Änderung in einer der verknüpften Daten eine Änderung des Resultats der Verknüpfung bewirkt oder so, dass mindestens jede Datenbit-Änderung von signifikanten (verwendeten) Bits einer der verknüpften Daten eine Änderung des Resultats bewirkt. Beispiele für Verknüpfungen in diesem Sinn: sind (bitweises) XOR oder auch ,Concatenate'. Für manche Anwendungen ist bevorzugt, dass das Resultat der Verknüpfung dieselbe Bitlänge aufweist wie die verknüpften Daten (was beim bitweisen XOR natürlich der Fall ist); andere Verknüpfungen sind jedoch nicht ausgeschlossen. Ebenfalls ist möglich, dass bei der Verknüpfung des Tabellenwert-Prüfwerts mit dem Eingangswert-Prüfwert noch weitere Daten berücksichtigt werden, beispielsweise Selektions- oder Maskendaten.
In der Beschreibung der Ausführungsbeispiele wird als Verknüpfungsfunktion jeweils die Operation XOR (verstanden als bitweises ausschliessliches ,oder') verwendet; eine Verallgemeinerung auf andere Verknüpfungsfunktionen ist - sofern nichts andere vermerkt - jedoch jeweils ohne weiteres möglich.
Ganz allgemein ist die Bestimmung des Ausgangswert-Prüfwerts aus dem Eingangswert-Prüfwert und dem Tabellenwert-Prüfwert bevorzugt so, dass das Resultat sowohl vom Eingangswert-Prüfwert als auch dem Tabellenwert-Prüfwert (und eventuell von anderen Daten) abhängt. Durch die hier vorgeschlagene geeignete Wahl der Formel für Eingangs- und Tabellenwert-Prüfwert geschieht das insbesondere so, dass für das Bestimmen des Ausgangswert-Prüfwerts die vorgegebene (Prüfwert-) Funktion nicht benötigt wird.
Der Empfänger (d.h. die nachgeordnete Stufe) kann anhand der durch Verknüpfungen abgeleiteten Prüfwerte bestimmen, ob ein Fehler vorliegt. Aufgrund des bevorzugten Vorgehens mit zu einem Ausgangswert-Prüfwert verknüpften Eingangswert-Prüfwert und Tabellenwert-Prüfwert würden sich jegliche Fehler auf den Ausgangswert-Prüfwert auswirken und können so erkannt werden: Fehlerhafte Datenübertragung von der vorgeschalteten Stufe (führen zu einem nicht passenden Eingangswert-Prüfwert);
Fehlerhafte Adressierung der Tabelle (ein nicht zum Eingangswert/Eingangswert-Prüfwert passender Tabellenwert/Tabellenwert- Prüfwert wird ausgewählt);
Fehlerhafter Tabelleneintrag (Tabellenwert oder Tabellenwert-Prüfwert sind falsch und führen daher zu einem inkonsistenten Ausgangswert-Prüfwert);
Fehlerhafte Datenübertragung an die nachgeschaltete Stufe (führt zu nicht passendem Ausgangswert-Prüfwert).
Das bedeutet, dass das vorgeschlagene Vorgehen zu einer lückenlosen Sicherheitskette führen und eine Steuerung mit Lookup-Tabelle sicher machen würde. Bekannte Systeme gemäss dem Stand der Technik verwenden nicht diese Sicherungsmethode, sondern verlassen sich z.B. auf mehrere unabhängige Implementierungen der Logikfunktion (redundante Systeme) oder auf aufwändige Selbst-Überprüfungen der verwendeten Rechenwerke und Tabellen.
Jeder Fehlerfall führt im vorgeschlagenen System zu einem nicht mit dem Ausgangswert konsistenten Ausgangswert-Prüfwert (, Start-Ziel Datensicherung'). Die Lokalisierung einer allfälligen Fehlerquelle innerhalb der Verarbeitungskette (Fehleroffenbarung) kann bei Bedarf mittels einer Speicherung der Zwischenwerte und ihrer Überprüfung durch ein geeignetes unabhängiges System (z.B. in Software) erreicht werden. Gemäss gewissen Ausführungsformen ist die Logikeinheit gar nicht befähigt, Prüfwerte zu berechnen, sondern nur Prüfwerte zu verknüpfen. Dadurch wird sichergestellt, dass nicht aufgrund einer System-Fehlfunktion beispielsweise zu einem falschen Tabellenwert ein fälschlicherweise passend berechneter Prüfwert beigeordnet werden kann - anstatt dem durch die Verknüpfung abgeleiteten, welcher korrekterweise durch seine Inkonsistenz mit dem Ausgangswert das Auftreten einer Fehlfunktion aufzeigt. Eine fälschliche Berechnung eines Prüfwertes aus dem Ausgangswert könnte im Prinzip den Sicherheitsmechanismus des Systems umgehen - sie wird sicher verhindert, indem kein Code zur Berechnung von Prüfwerten im System vorhanden ist.
Gemäss alternativen Ausführungsformen kann das System bzw. die Logikstufe selbst Fehleroffenbarungsmechanismen aufweisen, z.B. in der Logikeinheit selbst oder in einer ausgelagerten Fehleroffenbarungseinheit. Solche
Fehleroffenbarungsmechanismen beinhalten bspw. die Anwendung der Prüfwert- Funktion auf den Eingangswert, oder die Anwendung der Prüfwert-Funktion auf den Ausgangswert und den Vergleich mit dem entsprechenden Prüfwert. Solche Fehleroffenbarungsmechanismen können von der Norm gefordert und sicherheitstechnisch von Vorteil sein, insbesondere im Hinblick auf die Möglichkeit, dass sich zwei voneinander unabhängige Fehler gegenseitig kompensieren könnten. Im Falle einer ausgelagerten Fehleroffenbarungseinheit kann bspw. durch geeignete Massnahmen sichergestellt sein, dass keine Daten von der Fehleroffenbarungseinheit an die eigentliche Logikeinheit fliessen können (Rückwirkungsfreie Kommunikation; unidirektionale Kommunikation).
Der erfindungsgemässe Ansatz ermöglicht - sei es im System selbst oder in der nachgeordneten Stufe - eine Fehlererkennung durch einen einfachen Vergleich des ermittelten Ausgangswert-Prüfwerts mit dem Resultat der Anwendung der Prüfwert- Funktion auf den Ausgangswert. Bei negativem Resultat der Fehlererkennung kann das System in einen sicheren Zustand gehen Der Ansatz entspricht also dem fail- safe-Prinzip.
Bei positivem Resultat der Fehlerkontrolle kann der Ausgangswert (bzw. das Ausgangswert-Datensignal) oder ein daraus abgeleitetes Signal als Steuersignal verwendet werden. Das eigentliche Umsetzen von Steuersignalen in Steuerungen ist nicht Gegenstand der vorliegenden Erfindung und soll hier nicht eingehender diskutiert werden.
Lookup-Tabellen sind aufgrund der kombinatorischen Möglichkeiten nur für Eingangswerte einer begrenzten Bitbreite kommerziell praktikabel (exponentielles Wachstum des notwendigen Speichers). Die Bitbreite des Ausgangswertes ist wesentlich weniger kritisch, da diese nur zu einem linearen Wachstum des notwendigen Speichers führt.
Das vorstehend beschriebene Steuerungssystem (bzw. Steuerungs- Teilsystem) kann ohne weiteres durch geeignete Massnahmen auch für Systeme verwendet werden, bei denen die Eingangsdaten sehr umfangreich sind und eine einzige Lookup-Tabelle sehr gross und daher schwierig zu handhaben würde. Insbesondere können Mechanismen vorgesehen sein, welche mit dem Auftrennen von Eingangsdaten (insbesondere bei parallelen Datenleitungen kann das auch durch eine geeignete Einrichtung der Hardware geschehen) und/oder der Anwendung von Masken auf die Eingangsdaten aus den Eingangswerten reduzierte Eingangswerte oder mehrere Teilwerte als Adressen für eine oder mehrere Lookup-Tabellen generieren. Das kann mit Maskierungen von relevanten Eingangswert-Bits und der nachgeschalteten Selektion einer relevanten Lookup-Tabelle aus einer Reihe von Lookup-Tabellen einher gehen. Dabei wird gemäss einer hier vorgeschlagenen besonderen Ausführungsformen bei der Bestimmung des Ausgangswert-Prüfwerts jeder Selektions-, Maskierungs- oder sonstiger Schritt berücksichtigt, derart, dass der Ausgangswert-Prüfwert nicht mehr zum Ausgangswert passt (d.h. nicht mehr dem Resultat der Anwendung der vorgegebenen Prüfwert-Funktion auf den Ausgangswert entspricht) wenn irgend ein Schritt einen Fehler aufweist.
Nebst einer Steuerung der vorstehend diskutierten Art betrifft die Erfindung auch ein entsprechendes Verfahren zum Ermitteln eines Steuersignals. Ein solches Verfahren kann beispielsweise durch Betreiben einer Steuerung der vorstehend diskutierten Art ausgeführt werden. Das Verfahren dient dem Ermitteln eines Steuersignals auf Basis mindestens eines einen Eingangswert mit einem Eingangswert-Prüfwert repräsentierenden Eingangssignals und weist die folgenden Schritte auf:
- zur- Verfügung-Stellen eines Datenspeichers mit einer Mehrzahl von adressiert abgelegten Ausgangswerten, wobei jedem Ausgangswert ein Tabellenwert-Prüfwert zugeordnet ist (dieser Schritt wird bspw. vor der Laufzeit des Systems ausgeführt); - Auslesen eines Ausgangswertes aus dem Datenspeicher unter Verwendung des Eingangswerts oder einer daraus abgeleiteten Grösse als Adresse;
- Bestimmen eines Ausgangswert-Prüfwerts aus einer Verknüpfung des Eingangswert-Prüfwerts mit dem Tabellenwert-Prüfwert;
Optionales Durchführen einer Integritätskontrolle (Fehleroffenbarung) mit einem Vergleich des Ausgangsprüfwerts mit dem Resultat der Anwendung einer vorgegebenen Funktion auf den Ausgangswert, und
Ggf. Bei einem positiven Resultat der Integritätskontrolle, Verwenden des Ausgangswerts oder eines daraus abgeleiteten Signals als Steuersignal. Dabei kann die Integritätskontrolle im den Ausgangswert ermittelnden System selbst und/oder auch in einer nachgeordneten Stufe — bspw. dem den Steuerbefehl ausführenden Element durchgeführt werden. Bei einem negativen Resultat der Integritätskontrolle wird der Ausgangswert beispielsweise verworfen. Je nach dem kann dies mit einer Anforderung einer erneuten Übermittlung des Eingangswerts, einer erneuten Bestimmung des Ausgangswerts, einer Fehlerprotokollierung, einem Warnsignal an den Benutzer und/oder mit weiteren Massnahmen einhergehen. Im Falle einer Protokollierung des Fehlers kann vorgesehen sein, dass das System beim Überschreiten einer gewissen Fehlerquote angehalten wird, und/oder dass beim Überschreiten einer solchen Fehlerquote eine Warnung an den Benutzer erfolgt.
Nachfolgend werden Prinzipien der Erfindung und Prinzipien von speziellen Ausführungsformen der Erfindung anhand von schematischen Zeichnungen eingehender beschrieben. In den Zeichnungen bezeichnen gleiche Kennzeichnungen gleiche oder analoge Elemente. Es zeigen:
- Figur 1 eine Basis- Ausführungsform eines Systems mit Lookup-Tabelle;
- Figur 2 eine Variante mit Fehleroffenbarungen;
Figur 3 eine Ausführungsform mit einer Mehrzahl von Teilsystemen,
Figur 4 ein Mehrstufiges System;
Figur 5 eine Ausführungsform mit Ausmaskierung von irrelevanten Bits; und Figuren 6a und 6b ein System gemäss dem Stand der Technik.
Eine Basis-Ausführungsform der Erfindung ist in Figur 1 illustriert. Einem beispielsweise von einem vorgeschalteten System an das System übermittelten Eingangswert (INPUT) ist wie an sich aus dem Stand der Technik bekannt ein Eingangswert-Prüfwert (CHK IN) zugeordnet. Ein solcher kann redundant sein (d.h. er enthält dann keine Informationen, die nicht aus dem eigentlichen Wert , INPUT' ableitbar sind), und er kann beispielsweise mit einem gängigen Verfahren aus dem Eingangswert ableitbar sein. Es kann beispielsweise gelten:
CHK JN:=F_CHK(INPUT)=CRCn(INPUT) ( 1 )
Wie an sich aus dem Stand der Technik bekannt, kann das System den Eingangswert-Prüfwert zunächst dazu verwenden, Fehler bei der Datenübertragung vom vorgeschalteten System her und eventuell vom vorgeschalteten System verursachte andere Fehler zu erkennen.
Die Tabelle (Lookup Table) enthält eine Mehrzahl von Werten, die durch den Eingangswert abrufbar sind (die Eingangswerte sind quasi die , Adressen') der Tabelle.
Im Unterschied oder zusätzlich dazu ist gemäss dem hier beschriebenen Aspekt der Erfindung auch dem in der Tabelle gespeicherten Tabellenwert OUT ein Tabellen wert-Prüfwert CHK zugeordnet. Dieser ist sowohl vom Tabellenwert als auch vom Eingangswert abhängig, d.h. CHK:=f(OUT,INPUT). Wenn ein Tabellenwert ausgelesen und als Ausgabewert an ein nachgeordnetes System weitergegeben wird, verknüpft das System gleichzeitig auch den Eingangswert- Prüfwert CHK IN mit dem Tabellenwert-Prüfwert CHK, zum Beispiel:
CHK_OUT:=CHK_IN XOR CHK (2)
Dabei sind die vorgängige (offline-) Bestimmung des Tabellenwert-Prüfwerts und die Verknüpfungsfunktion (hier: XOR) so gewählt, dass gilt:
CHK_OUT=F_CHK(OUT) (3)
Daher kann das nachgeordnete System/die nachgeordnete Stufe die Sicherheit der Tabelle, die Sicherheit des Ausleseprozesses aus der Tabelle und die Sicherheit der Datenübermittlung mit einer einzigen Fehleroffenbarungsabfrage (Inegritätskontrolle) prüfen. Entspricht CHK OUT dem nachträglich für OUT berechneten Wert, ist kein Fehler aufgetreten:
FOB: CHK_OUT?=F_CHK(OUT).
Durch dieses Vorgehen ist eine durchgehende Sicherheitskette gewährleistet. Der Empfänger kann prüfen, ob an der richtigen Stelle der richtige Wert gelesen wurde. Ein Bitfehler in der Tabelle, beim Auslesen oder beim Weiterreichen des Ausgabewerts wird bewirken, dass die Fehleroffenbarung einen Fehler detektiert, worauf der Wert verworfen werden kann. Je nach Systemeinstellung und - Programmierung - kann als Folge davon das System angehalten oder eine andere geeignete Massnahme getroffen werden. In einer speziellen Gruppe von Ausführungsformen kann vorgesehen sein, dass das System selbst nicht befähigt ist, einen Prüfwert zu berechnen -d.h. die Funktion CHK(X) ist im System nicht implementiert. Eine solche Implementation wird auch nicht benötigt, da das System nur abgespeicherte Prüfwerte und empfangene Prüfwerte miteinander verknüpfen muss. Wenn das System nicht zur Prüfwertbildung befähigt ist, kann auch mit Sicherheit ausgeschlossen werden, dass das System aufgrund eines Programmier- Manipulier- oder sonstigen Fehlers fälschlicherweise einen berechneten Prüfwert anstelle des auf die beschriebene Art bestimmten Prüfwerts CHK OUT weitergibt und dadurch irrtümlich die Sicherheitsfunktion umgeht.
In einer anderen Gruppe von Ausführungsformen kann das System selbst auch eine Fehleroffenbarungsfunktionalität haben und beispielsweise eingangsseitig durch die Abfrage CHK_rN?=F_CHK(INPUT) und/oder ausgangsseitig durch die Abfrage CH _OUT?=F_CHK(OUT) eventuelle Fehler detektieren; eine solche Fehleroffenbarung kann beispielsweise durch eine Norm gefordert sein. Insbesondere gibt es Normen, die verlangen, dass keine Wertepaare (Wert;Prüfwert) versandt werden, die nachweislich des Prüfwert-Tests falsch sind.
Das entsprechende Vorgehen ist in Figur 2 illustriert. Figur 2 zeigt ein zu Figur 1 analoges System mit zusätzlicher, optionaler Fehleroffenbarungs-Funktionalität. Die Fehleroffenbarung kann im System selbst oder in einem abgekoppelten unabhängigen System erfolgen. Die Figur 1 entsprechenden Elemente und damit verbundenen Schritte sind analog zu den vorstehend beschriebenen Elementen/Schritten.
Eine erste, eingangsseitige Fehleroffenbarungs-Stufe FOB1 beinhaltet die Abfrage CHKJN?==F_CHK(INPUT), während eine zweite Fehleroffenbarungs-Stufe mit der Abfrage CHK_OUT?=F_CHK(OUT) sicherstellt, dass keine falschen Wertepaare (Wert; Prüfwert) versandt werden. Das System kann beide Fehleroffenbarungs- Stufen FOBn (n=l, 2) oder auch nur eine der beiden Stufen aufweisen, und eine angemessenen Massnahme wie beispielsweise ein Ausschalten des Systems kann ergriffen werden.
Alle Ausführungsfoimen der Erfindungen, insbesondere Ausführungsformen der vorstehend beschriebenen und/oder der nachstehend beschriebenen Systeme können optional mit einem zusätzlichen Mechanismus versehen sein, der eine permanente Selbstprüfung des Systems ermöglicht. So kann beispielsweise ermöglicht sein, dass wie das an sich für andere sichere Systeme bekannt ist, Übertragungsfehler auf der gemäss dem OSI Modell tiefer liegenden Protokollschicht erkannt und überwacht werden. Einzelne Fehler werden auf dieser Schicht korrigiert. Treten zu oft Fehler auf, so ist das System nicht mehr sicher.
Im Fall der sicheren Lookup-Tabelle kann die Tabelle bspw. zyklisch aus dem Speicher ausgelesen werden; über die ausgelesene Tabelle wird eine Prüfsumme gerechnet und gegen den korrekten Wert verglichen. Treten Differenzen auf, so muss die Tabelle neu gespeichert werden. Treten zu oft Differenzen auf, so ist das System nicht mehr sicher.
Es ist auch möglich, Error Correcting Code (,ECC) Memory zu verwenden, welches auf der tiefer liegenden Schicht einzelne Fehler erkennt und korrigiert. Treten zu viele ECC-Fehler auf, so ist das System nicht mehr sicher, und es muss bspw. entsprechend reagiert werden. Oft besteht die Situation, dass nicht alle Bits eines Eingangswertes Einfluss auf bestimmte Bits eines Ausgabewertes haben. Das System lässt sich dann quasi in unabhängige Teilsysteme aufteilen. (Mathematisch kann eine solche Unabhängigkeit die Darstellbarkeit einer übergeordneten Looup-Tabelle in Form einer Blockdiagonalmatrix bedeuten). Eine solche Aufteilung ist oft vorteilhaft, um allzu umfangreiche Tabellen mit entsprechend grossem Aufwand für die Vorberechnung und Speicherung zu vermeiden. In einer solchen Situation können Lookup-Tabellen kombiniert werden, indem ein bestimmter Teil des Eingangswerts als Adresse für eine erste Tabelle und ein bestimmter anderer Teil des Eingangswerts als Adresse für eine zweite Tabelle verwendet wird, wobei die Ausgabewerte der beiden Tabellen ausgangsseitig wieder aneinander gehängt werden können. Auch für diese Situation bieten Ausführungsformen der Erfindung eine sichere Lösung.
Ein entsprechendes Schema ist in Figur 3 dargestellt. Im dargestellten Ausführungsbeispiel werden zwei Lookup-Tabellen (Lookup Table 1 ; Lookup Table 2) kombiniert. Mit den Masken MAS Kl und MASK2 werden die für Tabelle 1 bzw. Tabelle 2 relevanten Bits ausgewählt; mit den ausgewählten Bits ADDR1 bzw. ADDR2 als Adressen wird der gewünschte Tabellen wert OUT1 bzw. OUT2 ausgelesen.
ADDR1 :=MASK1 AND INPUT (4)
AND ist in Gleichung (4) als bitweise UND-Verknüpfung zwischen den beiden Operanden zu verstehen; Bit-Positionen, an welchen die Maske auf ,0' gesetzt ist werden gleichzeitig aus der Bitfolge ausgeblendet. ADDR1 weist also eine Bitlänge auf, welche der Anzahl gesetzter Bits in MASK1 entspricht. Sind nur wenige Bits in der Maske gesetzt, so kann die Bit-Breite der Adresse so signifikant reduziert werden. Die Tabellen 1 und 2 enthalten je nebst den Tabellen werten 0UT1 bzw. OUT2 auch im Voraus berechnete, in der Tabelle abgespeicherte Tabellenwert-Prüfwerte CHK1 bzw. CHK2. Diese werden wie vorstehend anhand von Figur 1 beschrieben mit dem Eingangswert-Prüfwert CHK_IN zu einem Ausgabewert-Prüfwert verknüpft, so, dass der Ausgabewert-Prüfwert CHK OUT1 dem berechneten Prüfwert F_CHK(CHK_OUTl), resp. CHK_OUT2 dem Prüfwert F_CHK(CHK_OUT2) entspricht.
Der Prüfwert CHK IN enthält Information sämtlicher Bits von ΓΝ. Nur die mit der MASK n selektierten Bits sind jedoch relevant für den Lookup, d.h. über den Wert der anderen Bits wird vorzugsweise nichts angenommen. Als Prüfwert ist daher mit Vorzug ein reduzierter Eingangswert-Prüfwert CHK INl zu verwenden. Dies wird für Tabelle 1 durch den dargestellten Zwischenschritt mit der Funktion CHKJNl :=F(MASK1, IN, CHK_IN) bewirkt.
Gemäss einer ersten Möglichkeit gilt dabei:
CHK INl := F_CHK(MASK1 AND IN) (5)
D.h. der Prüfwert wird einfach mit der Prüfwert-Funktion aus dem ausgewählten Teil des Eingangswerts bestimmt. Für Systeme mittlerer Sicherheit ist das eine gangbare Möglichkeit. Sie hat jedoch einen potentiellen Nachteil. Der Prüfwert wird nämlich neu aus einem Zwischenwert MASK1 AND IN der Berechnung abgeleitet. Ist dieser Zwischenwert falsch, so wird fälschlicherweise eine gültige Prüfsumme erzeugt, und der Schutz der Daten fällt in sich zusammen. Eine andere Möglichkeit wäre, gemäss Gleichung (2) den Prüfwert CHK IN des ganzen Eingangswerts zu verwenden. Diese Lösung löst das Sicherheitsproblem. Sie hat jedoch den potentiellen Nachteil, dass auch nicht relevante Fehler detektiert werden und zu einem Anhalten führen können. Dieser Nachteil muss nicht immer schwerwiegend sein und kann je nach dem in Kauf genommen werden. Mit dieser Variante kann die Grösse der Tabellen nicht ideal reduziert werden.
Gemäss einer dritten Möglichkeit wird der Prüfwert CHK IN des ganzen Eingangswerts verwendet, jedoch um alle Beiträge korrigiert, die von nicht relevanten Bits des Eingangswerts stammen. Das kann bspw. wie folgt geschehen:
CHK IN1 := CHKJN XOR F_CHK(NOT(MASK 1 ) AND IN) (6)
Der vom vorgeschalteten System erzeugte Prüfwert CHK IN wird um die ausmaskierten Bits korrigiert. Nur wenn sowohl die vom Quellsystem übertragene Prüfsumme, sämtliche Werte und die Datenmanipulationen (ausmaskieren, Anpassung der Prüfsumme) korrekt sind, kann so wieder eine gültige Prüfsumme entstehen. Im Ausführungsbeispiel gemäss Gleichung (6) beruht das auf folgendem Prinzip. Die CRC stellt eine Standardvariante für die Prüfwert-Berechnung FCHK(X) dar. Eine Eigenschaft der CRC ist, dass das , flippen' (invertieren) einer bestimmten Position im Datenfeld immer zu derselben Veränderung (,delta') der CRC führt. Das ,delta' kann technisch durch eine einfache XOR-Operation zur bestehenden Prüfsumme dazu .addiert' werden. Mit anderen Worten: unabhängig vom Wert eines Datenfeldes führt das Invertieren von bit-Position ,η' zu demselben ,delta', welches zur aktuellen CRC mit der XOR-Operation dazu , addiert' werden kann. Für die gewünschte Reduktion der CRC muss also für jede Bit-Position ,η' der Ausdruck ,ΝΟΤ (MASK(n)) AND IN(n)' berechnet werden - falls dieser Wert , 1 ' ist, muss das Bit IN(n) auf ,0' gesetzt werden und die CRC muss um ,delta(n)' korrigiert werden. Das führt zu Gleichung (6).
Die Bestimmung des Ausgabewert-Prüfwerts CHK OUT1 aus dem reduzierten Eingangswert-Prüfwert CHK_IN1 und dem Tabellen-Prüfwert CHKl erfolgt dann gemäss Gleichung (7):
CHK_0UT1 :=CHK_IN1 XOR (MASKl XOR (MASKl AND IN)) XOR CHKl
(7)
Durch die XOR-Verknüpfung (zusätzlich zu CHK_IN1 und CHKl ) mit dem Wert (MASKl XOR (MASKl AND IN)) wird auch die Maskierungsfunktion MASKl in die Prüfwertbildung einbezogen; damit wird sichergestellt, dass auch zu Laufzeit der richtige Parameter MASKl für die Maskierung verwendet wird.
Die hier anhand von Lookup-Tabelle 1 beschriebenen Schritte werden für Lookup- Tabelle 2 analog vorgenommen.
Eine Verallgemeinerung auf drei oder mehr Tabellen ist selbstverständlich möglich. Für eine dritte und mögliche weitere Tabellen werden zusätzliche Masken MASK3, ... MASKk auf den Eingangswert und analog zu obigem Vorgehen auch auf die Prüfwertberechnung angewandt.
Auf der Ausgangsseite können die Ausgabewerte OUT1 , OUT2, ... bei Bedarf miteinander verknüpft, bspw. aneinandergehängt (concatenate) werden. Auch die Prüfwerte können entsprechend verknüpft werden, bspw. ebenfalls durch Aneinanderhängen oder durch ein XOR oder eine andere Operation.
Viele logische Abfragen, z.B. in der Sicherungstechnik, entsprechen UND- oder ODER-Verknüpfungen einer grossen Anzahl von Signalen/Bits. Solche und viele andere Schaltungen können durch kaskadierte Look-up Tabellen wesentlich effizienter implementiert werden. Eine bestimmte Anzahl von Eingangswert-Bits (z.B. 20) können von einer ersten Anlage (bspw. einer Sensorgruppe) stammen oder auf eine andere Weise miteinander in Verbindung sein und bspw. schon durch die Hardware von den anderen Input-Bits getrennt sein - wird auf eine erste Tabelle geführt, weitere Bits - bspw. von weiteren Anlagen - werden auf weitere Tabellen geführt. Die Resultate der Tabelle sind ein oder mehrere Bits breit und werden zu einem neuen Eingangswert für die nachfolgende Stufe der Kaskade zusammengeführt - der INPUT der Tabelle der zweiten Stufe ist die Aneinanderhängung (,concatenate') der Ausgangswerte OUT1 , OUT2 der ersten Stufe. Die Prüfsumme des neuen Eingangswertes kann direkt aus den Prüfsummen der Zwischenresultate berechnet werden. Das ist in Figur 4 dargestellt. Die beiden ersten Lookup-Tabellen ,Lookup Table und ,Lookup Table 2' entsprechen der ersten Stufe der Kaskade und die dritte Lookup-Tabelle (Lookup Table) der zweiten Stufe.
Das auf Basis der Eingangsdaten INPUTn mit zugeordneten Eingangs-Prüfwerten CHK INn (n=l , 2) durchgeführte Verfahren entspricht dem anhand Figur 1 beschriebenen Verfahren. Die Ausgangsdaten OUTn werden zusammengehängt und als Adressen für die zweite Stufe verwendet. Auch die Prüfwerte werden zu einem Prüfwert CHK IN verknüpft. Mit den verknüpften Eingangswerten mit den Verknüpften Prüfdaten der ersten Stufe wird in der zweiten Stufe erneut das zu Figur 1 analoge Verfahren durchgeführt. Eine Verallgemeinerung auf nur eine Tabelle (soweit sinnvoll) in der ersten Stufe oder auf drei oder mehr Tabellen in der ersten Stufe sowie auf mehrere Tabellen in einer zweiten Stufe sowie auf weitere Stufen in der Kaskade ist selbstverständlich möglich. Es sind auch Anwendungen denkbar, in welchen verschiedene Äste der Kaskade eine unterschiedliche Anzahl von Kaskadenstufen aufweisen.
Sofern eine Trennung der Eingangswert-Bits der beiden Eingabewerte INPUT1 und INPUT2 einem Datenverarbeitungsschritt entsprechen und daher auch mit Sicherheitsmerkmalen zu überprüfen ist, kann das vorstehend anhand Figur 3 beschriebene Verfahren verwendet werden, um das Zwischenergebnis zu bestimmen.
Auch in den Ausführungsformen der Figuren 3 und 4 können eine oder mehrere optionale Fehleroffenbarungsstufen vorhanden sein. Eine solche Fehleroffenbarung kann wie in Figur 2 einen Vergleich des Prüfwertes mit einem aus dem Datenwert mit FCHK berechneten Wert beinhalten.
Wenn der Input eine gewisse Grösse (20-30 bit) überschreitet, wird die Look-up Tabelle unpraktikabel gross. Für die meisten Logikschaltungen sind unter bestimmten Bedingungen sehr viele Bits irrelevant (don't care). Daher kann folgendes Vorgehen gewählt werden:
Ist eine bestimmte Bedingung erfüllt, so werden die irrelevanten Bits ausmaskiert.
- Es können verschiedene Bedingungen nebeneinander definiert und ausgewertet werden; am Schluss wird die korrekte Antwort gewählt. Dabei ist zu beachten, dass die verschiedenen Bedingungen so definiert werden müssen, dass für jeden möglichen Eingangswert genau eine (und nur eine) Bedingung erfüllt ist.
Ein Beispiel wird in Figur 5 näher erläutert. Dieses Beispiel beruht auf der Annahme, dass verschiedene Szenarien existieren. Je nach Szenario sind andere Bits der Eingangsdaten IN relevant und werden mit einer entsprechenden Maske ausgewählt. Im gezeichneten Beispiel existieren zwei Szenarien, beispielsweise bei einer Stellwerksteuerung„Zug von rechts" und„Zug von links".
Das zutreffende Szenario wird durch das Ausmaskieren bestimmter relevanter Bits (SELMASK) und deren Vergleich mit einem Selektionskriterium (SEL) bestimmt. In vielen Anwendungen wird es am praktikabelsten sein, für alle Selektionskriterien dieselbe SELMASK zu verwenden, damit immer genau ein Selektionskriterium erfüllt ist.
SELECT1 -SELMASK 1 AND IN ?= SEL1 (8)
bzw.
SELECT2 :=SELMASK2 AND IN ?= SEL2 (9)
Die Masken SELMASK1 bzw. SELMASK2 wählen aus den Eingangsdaten diejenigen Bits aus, die für das Vorliegen von Szenario 1 bzw. Szenario 2 vorgegebene Werte haben müssen (bspw. Zug hat Schwelle links bzw. rechts des Stellwerks überfahren). Der Vergleich mit dem entsprechenden Vorgabewert SEL1 bzw. SEL2 liefert ein Datenbit (ja/nein) SELECT1 bzw. SELECT2. Da immer nur ein Selektrionskriterium erfüllt sein soll, reicht im Prinzip einer der beiden Auswahlschritte (8) oder (9) - bzw. reichen m-1 Auswahlschritte. Wie nachstehend noch erläutert kann jedoch ein wie dargestellt redundantes Auswählen als zusätzliches Sicherheitsmerkmal dienen.
Die Auswahl der für Szenario 1 bzw. Szenario 2 relevanten Datenbits erfolgt wie vorstehend anhand von Figur 3 diskutiert mit entsprechenden Masken MASK1 bzw. MASK2: ADDRn:=MASKn AND IN (n=l , 2(,...)). Anhand der Adresse wird aus der Lookup-Tabellen n (Lookup Table 1 ; Lookup Table 2) ein Wert OUTn ausgelesen, dem erfindungsgemäss ein Prüfwert CHKn zugeordnet ist.
Die Bestimmung von CHK OUT1 erfolgt im dargestellten Beispiel gemäss:
CHK_OUTl :=CH _IN XOR (MASK1 XOR (MASK1 AND IN)) XOR
(SELMASK1 XOR (SELMASK1 AND IN)) XOR CHK1 (8a)
Analog für CHK_OUT2:
CHK_OUT2:=CHK_IN XOR (MASK2 XOR (MASK2 AND IN)) XOR
(SELMASK2 XOR (SELMASK2 AND IN)) XOR CHK2 (8b)
Wie im Ausführungsbeispiel von Figur 3 wird also die Funktion MASKn in die Prüfwertableitung mit einbezogen, so dass ein entsprechender Fehler zu einem falschen Prüfwert führt. Aus den Wertepaaren 0UT1 |CHK_0UT1 und OUT2|CHK_OUT2 wählt der Selektor (Multiplexer) M anhand eines der beiden Datenbits SELECT1 oder SELECT2 - im gezeichneten Bespiel anhand von SELECT2 - das für das ausgewählte Szenario relevante Wertepaar aus und gibt es als OUT|CHK_OUT weiter. Da hier zusätzlich auch der Auswahlprozess (Select) mit einbezogen wird, fuhren Fehler bei der Auswahl-Maske SELMASKn oder bei deren Anwendung auf die Eingangsdaten IN ebenfalls zu einem falschen Prüfwert. Damit ist auch der Wert des Selektions-Signales in der Prüfsumme und die Funktion des Multiplexers abgesichert. Diese Ausdehnung der Prüfabdeckung auf den Multiplexer bedingt jedoch, dass sämtliche aktiven Bit-Positionen der Selektionsmasken auch in den Bit- Masken für die Adressen der Lookup-Tabellen gesetzt sind.
Sollte dies zu einer zu grossen Anzahl von relevanten Eingangsbits einer Tabelle führen, so wäre der gesamte Selektionsvorgang aus der in (8a 8b) gezeigten Formel zu entfernen:
CHK_OUTn:=CHK_IN XOR (MASKn XOR (MASKn AND IN)) XOR CHKn
(9)
In diesem Fall ist die korrekte Funktion des Multiplexers durch andere geeignete Massnahmen sicher zu stellen.
Das nachgeschaltete System kann wie in vorstehenden Beispielen durch den Test FOB: CHK_OUT?=F_CHK(OUT) die Sicherheit sämtlicher vorangegangener Datenübermittlungs- und auswertungsschritte prüfen.
Optional kann wie in den anderen Ausführungsformen das System selbst nicht befähigt sein, einen Prüfwert zu berechnen - d.h. die Funktion CHK(X) ist dann im System nicht implementiert.
Alternativ kann auch . das System gemäss Figur 5 selbst eine Fehleroffenbarungsfunktionalität aufweisen. Insbesondere kann eine beliebige Kombination der fünf in der Figur 5 mit FOB 1 - FOB 5 bezeichneten optionalen Fehleroffenbarungen implementiert sein:
FOB 1 : F_CHK(IN) ?= CHK IN (eingangsseitige Fehlerprüfung)
FOB2: (F_CHK(OUTl) ?= CHK_OUTl) XOR SELECTl
FOB3: (F_CHK(OUT2) ?= CHK OUT2) XOR SELECT2
FOB2 und FOB3 prüfen analog zur ausgangsseitigen Fehlerprüfung gemäss Figur 2 , dass keine falschen Wertepaare aus der jeweiligen Tabelle weitergegeben werden. Durch die Verknüpfung mit SELECTl bzw. SELECT2 wird sichergestellt, dass nur eines der beiden Wertepaare - nämlich das entsprechend dem Szenario„richtige" Wertepaar" - einen passenden Prüfwert aufweist - bei allen nicht-aktiven Szenarien kann durch diese Formel sogar aktiv gefordert werden, dass der Prüfwert nicht dem Ausgangswert entspricht. FOB4: NOT SELECT1 XOR SELECT2
Mit FOB4 wird bei der Anwendung des Selektionskriteriums Redundanz geschaffen. Eines der beiden Datenbits SELECT1 , SELECT2 muss den Wert„true" bzw.„Ja" haben - und nur eines darf diesen Wert haben. Bei mehr als 2 Szenarien gilt weiterhin, dass nur genau ein Selektionskriterium erfüllt sein darf.
FOB5: F CHK(OUT) ?= CHK OUT
FOB5 entspricht der ausgangsseitigen Fehleroffenbarung, wie sie auch in einem nachgeschalteten System durchführbar ist. Bezüglich der Nützlichkeit bzw. der Erfordernis einer solchen Fehleroffenbarung wird auf die vorstehende Beschreibung von Figur 2 verwiesen.
Jede dieser Fehleroffenbarungsfunktionalitäten kann auch ohne die jeweils anderen Fehleroffenbarungsfunktionalitäten implementiert werden; selbstverständlich können diese Funktionalitäten auch in Kombination implementiert werden, oder es sind beliebige Unterkombinationen möglich.
Obwohl in den hier beschriebenen Beispielen die Prüfwertbestimmung über eine CRC -Funktion und die Verknüpfung mit XOR erfolgt, ist das keine Notwendigkeit.

Claims

PATE TANSPRÜCHE
Steuerung mit einem Signalempfänger und Mitteln, die in Abhängigkeit von in empfangenen Signalen enthaltenen Daten ein Steuerungssignal generieren, wobei die Mittel eine Logikeinheit aufweisen, die in Abhängigkeit von einem Eingangswert einen Ausgangswert bestimmt, wobei das Steuersignal in Abhängigkeit vom Ausgangswert generierbar ist, dadurch gekennzeichnet, dass die Logikeinheit eingerichtet ist, einem Eingangswert einen vorbestimmten, in einem Datenspeicher abgelegten Tabellenwert zuweisen, und dass jedem Tabellenwert ein im Datenspeicher abgelegter Tabellenwert- Prüfwert zugeordnet ist und dass der Ausgangswert dem Tabellenwert entspricht oder aus diesem abgeleitet wird, wobei der Tabellenwert-Prüfwert sowohl vom Tabellenwert als auch vom Eingangswert abhängig ist.
Steuerung nach Anspruch 1 , wobei jedem Eingangswert ein Eingangswert- Prüfwert zugeordnet ist, dadurch gekennzeichnet, dass die Logikeinheit befähigt ist, aus einer Verknüpfung eines Eingangswert-Prüfwerts oder eines daraus abgeleiteten Werts mit dem Tabellenwert-Prüfwert einen Ausgangswert-Prüfwert zu bestimmen, wobei der Ausgangswert-Prüfwert einem Wert entspricht, der mittels einer vorgegebenen Funktion aus dem Ausgangswert berechenbar ist.
3. Steuerung nach Anspruch 2, dadurch gekennzeichnet, dass der Tabellenwert- Prüfwert ohne Kenntnis des Eingangswerts oder Eingangswert-Prüfwerts nicht eindeutig aus dem Ausgangswert bestimmbar ist.
4. Steuerung nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die Logikeinheit nicht befähigt ist, aus dem Ausgangswert den Ausgangswert- Prüfwert zu berechnen.
Steuerung nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass die Verknüpfung von Eingangswert-Prüfwert und Tabellen-Prüfwert eine bitweise XOR-Operation ist.
Steuerung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Logikeinheit eingerichtet ist, auf den Eingangswert eine Mehrzahl von verschiedenen Masken anzuwenden, um eine entsprechende Mehrzahl von Adressen zu einer Mehrzahl von Tabellen zu bestimmen, jeder Adresse einen im Datenspeicher abgelegten Ausgangs-Teilwert zuzuweisen und die Ausgangs-Teilwerte zu einem gemeinsamen ersten Ausgangswert zu verknüpfen.
Steuerung nach Anspruch 6, dadurch gekennzeichnet, dass die Logikeinheit befähigt ist, aus einer Verknüpfung eines Eingangswert-Prüfwerts oder eines davon abgeleiteten Werts mit dem Tabellenwert-Prüfwert einen Ausgangswert- Teilwert-Prüfwert zu bestimmen, wobei vorzugsweise der Eingangswert- Prüferwert umgerechnet wird, indem die Beiträge von irrelevanten Bits des Eingangswerts kompensiert werden.
Steuerung nach Anspruch 6 oder 7, dadurch gekennzeichnet, dass die Logikeinheit befähigt ist, den ersten Ausgangswert als Eingangswert einer weiteren Stufe zu verwenden, wobei in der weiteren Stufe dem ersten Ausgangswert ein zweiter Ausgangswert zugewiesen und ein erster Ausgangswert-Prüfwert mit einem Tabellenwert-Prüfwert der weiteren Stufe zu einem zweiten Ausgangs-Prüfwert der weiteren Stufe verknüpft wird.
Steuerung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Logikeinheit eingerichtet ist, auf den Eingangswert eine Mehrzahl von verschiedenen Masken anzuwenden, um eine entsprechende Mehrzahl von Adressen zu bestimmen, jeder Adresse einen im Datenspeicher abgelegten Ausgangs-Teilwert zuzuweisen und mittels eines Selektionskriteriums zu bestimmen, welcher der Ausgangs-Teil werte relevant ist und diesen als Ausgangswert zu bestimmen.
10. Steuerung nach Anspruch 9, dadurch gekennzeichnet, dass jedem Ausgangs- Teilwert ein Tabellenwert-Prüfwert zugeordnet ist, und dass ein Ausgangs- Teilwert-Prüfwert durch eine Verknüpfung eines Eingangswert-Prüfwerts mit dem Tabellenwert-Prüfwert und vorzugsweise der entsprechenden Maske und/oder einer Selektionsmaske oder aus einem davon abgeleiteten Wert bestimmbar ist.
Steuerung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass bei der Bestimmung eines Ausgangswert-Prüfwerts aus dem Tabellenwert-Prüfwert jeder Schritt bei der Verarbeitung des Eingangswerts zum Ausgangswert berücksichtigt wird, derart, dass ein Bitfehler bei irgend einem der Schritte einen Fehlerhaften Ausgangswert- Prüfwert bewirkt. Verfahren zum Ermitteln eines Steuersignals auf Basis mindestens eines einen Eingangswert mit einem Eingangswert-Prüfwert repräsentierenden Eingangssignals, aufweisend die Schritte: zur- Verfügung-Stellen eines Datenspeichers mit einer Mehrzahl von adressiert abgelegten Ausgangswerten, wobei jedem Ausgangswert ein Tabellen wert-Prüfwert zugeordnet ist;
Auslesen eines Ausgangswertes aus dem Datenspeicher unter Verwendung des Eingangswerts oder einer daraus abgeleiteten Grösse als Adresse;
Bestimmen eines Ausgangswert-Prüfwerts aus einer Verknüpfung des Eingangswert-Prüfwerts mit dem Tabellenwert-Prüfwert.
13. Verfahren nach Anspruch 12, gekennzeichnet durch die weiteren Schritte:
- Durchführen einer Integritätskontrolle mit einem Vergleich des Ausgangsprüfwerts mit dem Resultat der Anwendung einer vorgegebenen Funktion auf dem Ausgangswert, und
Bei einem positiven Resultat der Integritätskontrolle, Verwenden des Ausgangswerts oder eines daraus abgeleiteten Signals als Steuersignal.
PCT/CH2012/000162 2011-07-29 2012-07-11 Tabellengesteuertes system WO2013016831A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CH1267/11 2011-07-29
CH01267/11A CH705315A1 (de) 2011-07-29 2011-07-29 Tabellengesteuertes System.

Publications (1)

Publication Number Publication Date
WO2013016831A1 true WO2013016831A1 (de) 2013-02-07

Family

ID=46514039

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CH2012/000162 WO2013016831A1 (de) 2011-07-29 2012-07-11 Tabellengesteuertes system

Country Status (2)

Country Link
CH (1) CH705315A1 (de)
WO (1) WO2013016831A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2853465A1 (de) 2013-09-27 2015-04-01 Siemens Schweiz AG Logikschaltung und Verfahren zum Ersetzen eines zwangsgeführten Sicherheitsrelais

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3743438A1 (de) * 1987-12-21 1989-06-29 Siemens Ag Verfahren und einrichtung zum steuern des uebergangs eines endlichen automaten von einem momentanzustand in einen folgezustand
US7543216B1 (en) * 1998-03-16 2009-06-02 Actel Corporation Cyclic redundancy checking of a field programmable gate array having an SRAM memory architecture

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3743438A1 (de) * 1987-12-21 1989-06-29 Siemens Ag Verfahren und einrichtung zum steuern des uebergangs eines endlichen automaten von einem momentanzustand in einen folgezustand
US7543216B1 (en) * 1998-03-16 2009-06-02 Actel Corporation Cyclic redundancy checking of a field programmable gate array having an SRAM memory architecture

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2853465A1 (de) 2013-09-27 2015-04-01 Siemens Schweiz AG Logikschaltung und Verfahren zum Ersetzen eines zwangsgeführten Sicherheitsrelais

Also Published As

Publication number Publication date
CH705315A1 (de) 2013-01-31

Similar Documents

Publication Publication Date Title
EP3069202B1 (de) Sicherheitssteuerung mit konfigurierbaren eingängen
EP1802019B1 (de) Erkennung von Fehlern bei der Übermittlung von Daten
EP2814193B1 (de) Verfahren und system zur erkennung von fehlern bei der übertragung von daten von einem sender zu zumindest einem empfänger
EP1631014B1 (de) Verfahren und Vorrichtung zur Busankopplung sicherheitsrelevanter Prozesse
DE2724409A1 (de) Datenverarbeitungssystem
WO2016034349A1 (de) Verfahren zur seriellen übertragung eines rahmens über ein bussystem von einem sender zu mindestens einem empfänger und teilnehmerstation für ein bussystem
EP1811722B1 (de) Verfahren und Vorrichtung zur Umwandlung mehrkanalig vorliegender Nachrichten in eine einkanalige sichere Nachricht
EP3414632B1 (de) Verfahren und vorrichtung zum überwachen einer datenverarbeitung und -übertragung in einer sicherheitskette eines sicherheitssystems
DE102014105207A1 (de) Verfahren zum Betreiben eines Kommunikationsnetzwerks und Kommunikationsnetzwerk
EP2837142B1 (de) Verfahren zum übertragen von prozessdaten in einer automatisiert gesteuerten anlage
WO2013016831A1 (de) Tabellengesteuertes system
DE102012213040A1 (de) Decoder für physikalisch nicht klonbare Funktionen mittels Schwellendekodierung und entsprechendes Verfahren
DE2161169A1 (de) Schaltungsanordnung zum Erzeugen von Abfragemustern für die Fernüberwachung der Verstärkerstellen von PCM-Übertragungsleitungen
EP3550748A1 (de) Verfahren zur erkennung von datenverfälschungen bei einer datenübertragung über eine fehlersichere kommunikationsverbindung
EP3709113B1 (de) Datenintegritätsprüfverfahren
DE102016113322A1 (de) Slave-Steuerung für Ethernet-Netzwerk
EP1737132A1 (de) Verfahren zur Berechnung von CRC-Prüfwerten und Logikschaltung
DE102012100818B3 (de) Verfahren zur Datenübertragung in einem Feldbussystem
DE102019215115B4 (de) Verfahren zur sicheren Kommunikation zwischen einem Master und einem Slave eines Bussystems
DE202006016012U1 (de) Systemarchitektur für eine Firmware
WO2023020807A1 (de) Automatisches erkennen und korrigieren von speicherfehlern in einem sicheren mehrkanaligen rechner
EP2246761A1 (de) Schnittstelle und Verfahren zum sicheren Ändern von Parametern einer fehlersicheren industriellen Automatisierungskomponente
EP1763168A1 (de) Verfahren zum Erzeugen von Datentelegrammen, die CRC-Sicherungsanhänge aufweisen, welche eine verringerte Restfehlerwahrscheinlichkeit bieten
WO2022207213A1 (de) Datenverarbeitungsverfahren
DE102012001624B4 (de) Störungstolerantes Saftey-at-Work System

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12735438

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12735438

Country of ref document: EP

Kind code of ref document: A1