Method for computer-supported error analysis of sensors and/or actuators in a technical system

[0001] It is of enormous significance for complex technical systems or installations to be able to make statements about the dependability of the respective system or, respectively, of the installation.

[0002] It is known that statements about the dependability of an arbitrary technical system or, respectively, of an installation can be produced manually, for example by what is referred to as an error tree analysis (see DIN 25424, Part 1: Fehlerbaumanalyse: Methode und Bildzeichen; Part 2: Handrechenverfahren zur Auswertung eines Fehlerebaums) or simulatively or, respectively, analytically on the basis of models specifically produced for this purpose (see J. Dekleer and B. C. Williams, Diagnosing Multiple Faults, Elsevier Science Publishers, Artificial Intelligence, Vol. 32, 1987, pp. 97-130). For the sake of a simple presentation, only technical systems shall be mentioned below. However, technical installations are also covered in the term of technical system within the scope of this document. A complete manual determination of the influences of a technical malfunction of sensors and/or actuators is practically not possible in a complex technical system due to the linked dependencies and the different forms of realizing the control, the control system and the sensor mechanisms and/or actuator mechanisms. The analytical techniques disclosed in the Dekleer et al. reference require the production of a specific model, for which it can generally not be guaranteed that it correctly describes the system respectively under consideration. Of course, the quality of the statements is there substantially reduced. Further, a considerable disadvantage of the approaches disclosed in the Dekleer et al. reference is that the production of the model requires additional developing outlay and time. As a result thereof, a short-term investigation of alternative realizations of a technical system, which is also referred to as rapid prototyping, is prevented.

[0003] It is known to describe a technical system in a status-finite description, for example as automat. A status-finite description usually comprises statuses in which actions are implemented when the technical system is in the respective status. Further, the status-finite description usually comprises status transitions that describe possible changes of the technical system between statuses. The technical system can also implement actions in status transitions. It is known in this context in a controlled, technical system to fashion the status-finite description such that the behavior of the control of the technical system and the behavior of the controlled installation is presented as status automat. It is also not assured given these approaches that all possible influences of errors on the system are correctly identified.

[0004] Possibilities for textual description of a status automat that are processed with a computer are, for example, interlocking specification language (ISL) or control specification language (CSL), which are described in K. Nökel, K. Winkelmann, Controller Synthesis and Verification: A Case Study, in: C. Leverentz, T. Lindner, Formal Development of Reactive Systems, Lecture Notes in Computer Science (No. 891), Springer 1995, pp. 55-74.

[0005] It is also known to employ a status-finite description for generating controls with a computer and for the computer-supported documentation of properties of an error-free technical system.

[0006] One possibility for computer-supported documentation of properties of an error-free technical system employs the principle of what is referred to as model checking, this being described in J. Burch et al, Symbolic Model Checking for Sequential Circuit Verification, IEEE Trans. On Computer-Aided Design of Integrated Circuits and Systems, Vol. 13, No. 4, pp. 401-424, April 1994.

[0007] It is also known for status-finite description of a system to employ what is referred to as a finite state machine format (FSM Format) whose fundamentals are described in R. Bryant, Symbolic Boolean Manipulation with Ordered Binary-Decision Diagrams, ACM Computing Survey, Vol. 24, No. 3, pp. 293-318, September 1992. Binary decision diagrams (BDD) have the advantage of also compactly representing very extensive status systems in many instances.

[0008] The invention is thus based on the problem of specifying a method for computer-supported error analysis of sensors and/or actuators in a technical system with which the correctness of the error analysis is assured.

[0009] The method according to the present invention is implemented with a computer and comprises the following steps:

• [0010] a) a status-finite description of the technical system is determined in case of error for an error of a sensor and/or of an actuator of the system;
• [0011] b) a first set of achievable conditions is determined for the technical system;
• [0012] c) a second set of achievable conditions is determined for the error-effected technical system;
• [0013] d) a difference quantity is formed from the first set and from the second set;
• [0014] e) result statuses are determined from the difference quantity, these result statuses satisfying prescribable conditions.

[0015] The invention can be graphically described in that a model checking is implemented both for the error-free technical system as well as for a system effected with an error of a sensor and/or actuator. Due to the model checking, all achievable conditions of the error-free or, respectively, of the error-effected system are identified. A difference quantity of statuses is formed from these statuses. The statuses of the difference quantity that meet a prescribable condition, for example a safety demand made of the system, are identified for the difference quantity. These statuses represent a “dangerous” condition with respect to the prescribable condition for the error respectively being investigated.

[0016] The method assures that all “dangerous” statuses are identified for all conditions prescribable in view of the respectively investigated error, i.e. for the faulty sensor and/or actuator.

[0017] It is advantageous to implement the method for all possible errors of sensors and/or actuators that the technical system comprises. In this way, it is assured for the entire system that all “dangerous” statuses in view of prescribable conditions are identified.

[0018] It is also advantageous to allocate failure probabilities to the sensors and/or actuators and to implement the error analysis taking the failure probabilities into consideration. In this way, it is possible without greater calculating outlay in the implementation of the method with a computer to indicate for the identified statuses what the probability is that this status will in fact be reached, a risk estimate for the respectively analyzed system thus becoming extremely simple and surveyable.

[0019] For further savings in calculating time in the implementation of the method with a computer, it is also advantageous to realize the status-finite description with a finite automat in the form of a binary decision diagram (BDD).

[0020] The method, due to the above-described properties, can be very advantageously employed in the following fields:

• • [0021] given rapid prototyping of the technical system;
  • [0022] within the framework of the error diagnosis of the technical system;
  • [0023] for generating critical test cases for a commissioning and for a system test of the technical system;
  • [0024] for preventative maintenance of the technical system.

[0035] A suitable status-finite description represents the behavior of the control and the behavior of the control system as status automat. The presentation can ensue in various ways, for example in textual form upon employment of ISL or CSL.

[0036] FIG. 2 shows a simple technical system with an error-free control FS, statuses y1, y2, y3 and status transitions x1, x2 as status automat. The control S describes actuators as statuses. A controlled process P contains the description of sensors x1, x2, x3 as statuses x1, x2, x3 and status transitions y1, y2, y3.

[0037] The control S of the system reacts to measured values xj (x1, x2, x3) of sensors X. Status transitions are therefore thus triggered in the control S by sensor data. The statuses are characterized by values yi (y1, y2, y3) of status variables Y that are allocated to actuators. The setting of actuators Y in turn triggers status transitions in the controlled system, i.e. in the process P, which is expressed in the modification of the values of the sensors X.

[0038] The status automats of the control S and of the process P implements status transitions in alternation. The outputs of the one automat are the inputs of the respectively other automat.

[0039] The interface between control and controlled environment can be automatically recognized in a corresponding description. Further, it is possible—as described in detail later—to derive the value set from such a description that the individual values (statuses or, respectively, status transitions) can assume.

[0040] FIG. 3 symbolically shows an error modeling for error-effected sensors in a sensor error model SF and for error-effected actuators in an actuator error model AF.

[0041] Technically, thus, sensors X and actuators Y are connected to the interface between control S and controlled process P. A malfunction of a sensor X leads to the fact that a different, error-effected value x′j is delivered to the control S, i.e. supplied to the control S, instead of the correct measured values xj. A malfunction of an actuator is expressed in the setting of an incorrect value y′i instead of the value yi. Which sensors X and actuators Y are present and what value set is to be taken into consideration here can be derived from the status-finite description.

[0042] This allows the automated, systematic analysis of the effects of sensor and actuator errors on the behavior of a controlled system. Sensor error models SF or, respectively, actuator error models AF that describe the respective error of the sensor x and/or actuator y are inserted between the controlled process P and the control S. Exemplary models for intermittent (non-persistent), individual errors of the sensor mechanism and actuator mechanism are recited in FIG. 3.

[0043] A non-persistent, individual error of a sensor x is described by the following rule:

[0044] A non-persistent, individual actuator y is described by the following rule:

[0045] FIG. 4 shows the general sensor error model SF from FIG. 3 for the case that a non-persistent, individual error given a first sensor value x1 is present such that the first sensor value x1 either exhibits the correct, first sensor value x1 or, due to a sensor error, exhibits a second sensor value x2 that would be an incorrect value in this case. The second sensor value x2 and a third sensor value x3 are correctly measured.

[0046] An important question that must be answered is whether the combination of control S and control process P can proceed into critical conditions due to the sensor error that would be reliably precluded in the error-free case.

[0047] One possibility of producing this proof for the error-free case is offered by what is referred to as model checking, this being described in J. Burch et al, Symbolic Model Checking for Sequential Circuit Verification, IEEE Trans. On Computer-Aided Design of Integrated Circuits and Systems, Vol. 13, No. 4, pp. 401-424, April 1994. This method allows the set of achievable statuses to be identified and to examine whether statuses that, for example, infringe safety conditions are contained.

[0048] In order to be able to apply this technique for error analysis of sensors X and/or actuators Y contained in the system, the sensor error models SF or, respectively, actuator error model AF are described here by a modified control logic (see FIG. 5).

[0049] The combination of control S and controlled process P shown in

[0050] FIG. 5 behaves identically to the model shown in FIG. 4 in the error case given the first sensor values x1. However, the insertion of an explicit error model between control S and controlled process P can be foregone here. S Due to the assumed, intermittent error, status transitions indicated with x1 are inserted in the control parallel to the status transitions marked with x2.

[0051] The following situation is thus described: the second sensor value x2 and the third sensor value x3 are correctly measured. The controlled behavior is therefore unmodified for these values. Since an intermittent error is assumed, the first sensor value x1 can also be correctly reported, so that these status transitions are maintained. If a persistent exchange of the first sensor value x1 with the second sensor value x2 were assumed, then edges labeled with x1 would have to be erased. All status transitions that are marked with x2 can now also be run at the value x1. A corresponding edge is therefore supplemented in the control S. The control S reacts to the value x2 but at the location x1 of the process.

[0052] This modification of the control logic for describing errors can be formally automatically implemented by the computer for all errors that can be considered.

[0053] The questions about obtainability of critical conditions (for example safety, seizures) for the arising models can likewise be answered by applying model checking. An automatic determination of the statuses achievable in the error-effected system thus preferably ensues upon application of model checking.

[0054] Subsequently, a respected difference set of the statuses achievable in the respective error case and the statuses achievable in the error-free case is determined.

[0055] Those statuses that at least meet a condition prescribable by the user (for example, violation of a safety demand) or, respectively, that violate this condition are determined dependent on the application.

[0056] FIG. 1 shows this procedure again symbolically in a block circuit diagram. At least one sensor error model SF and/or at least one actuator error model AF is produced for the control FS and the controlled process P, a formal analysis of the status-finite description for the error-effected system ensuing, preferably by model checking, taking these into consideration.

[0057] For the result of the comparison to the error-free system and the determination “dangerous” conditions, the cause-and-effect relationships between sensor errors or, respectively actuator errors and the possible occurrence of the effect under consideration are determined and preferably portrayed in a cause-and-effect graph.

[0058] FIG. 6 shows a technical system in the form of a lift-off turntable HD of a fabrication cell FZ with which the method is to be presented in yet greater detail.

[0059] The fabrication cell FZ comprises a delivering conveyor belt FB at whose end a lift-off turntable picks up workpieces and supplies them to a robot R. The robot R places the workpiece into a press PR and places it—after being shaped—onto an outgoing belt WB. The fabrication cell FZ contains corresponding sensors X and actuators Y.

[0060] The lift-off turntable HD can move in vertical (vmov) and horizontal (hmov) direction with the assistance of two drives (not shown). Each drive can be driven in negative (minus) or positive (plus) direction or can stand still (stop).

[0061] The lift-off turntable HD has sensors X for vertical (vpos) and horizontal (hpos) position acquisition that can distinguish the positions x0 (bottom), x1 (middle) and x2 (top). In addition, a further sensor (part_on_table) (not shown) acquires the presence of a workpiece WS on the lift-off turntable HD.

[0062] The initial position AP of the lift-off turntable HD is at the lower, left stop (x0, x0) without workpiece WS (see FIG. 7). When a workpiece WS falls from the delivering conveyor belt FB onto the lift-off turntable HD, then the target position ZP of the lift-off turntable HD is at the upper right (x2, x2).

[0063] The lift-off turntable HD dare never assume a different horizontal position then x0 (left stop) in combination with the vertical position x0 (bottom) since it would otherwise collide with the delivering conveyor belt FB (forbidden area VB).

[0064] A description of the status automat of the control FS of the lift-off turntable HD in CSL is recited below:

[0065]

CSLxtClasses table
	Types
	bool	=[no, yes];
	posType	=[x0, x1, x2];
	movType	=[stop, plus, minus];
Class pcd
StateVariables
	input  vpos	: posType default x0;
	input hpos	: posType default x0;
	input part_on_table	: bool  default no;
	output vmov: movType default stop;
	output hmov: movType default stop;
Transitions
start_up	:=	(part_on_table = yes / \ vpos = x0)
	==>	(** vmov = plus);
rotate	:=	(part_on_table = yes / \ vpos = x1 / \ hpos < x2)
	==>	(** hmov = plus);
stophigh	:=	(part_on_table = yes / \ vpos = x2)
	==>	(** vmov = stop);
stop 45	:=	(part_on_table = yes / \ hpos = x2)
	==>	(** hmov = stop);
rotate_back		:=(part_on_table = no / \ vpos = x2 / \
	/ \ hpos = x2) ==> (** hmov minus);
start_down	:=(part_on_table = no / \ hpos x0 / \
	/ \ vpos = x2) ==> (** hmov = stop / \
	/ \ ** vmov = minus);
stoplow	:=(part_on_table = no / \ vpos = x0)
	==> (** vmov = stop);
End /* Class pcd_control*/
End table
CSLInstances i
	table : pcd;
End i

[0066] The control logic of the lift-off turntable HD determines the above description in CSL. The head of the CSL description declares data types (value ranges) of the status variables. The subsequent declaration of the status variables uses these type declarations and additionally determines starting values. On the basis of the declaration of status variables as input or output, a determination can be made as to whether it is a matter of a status variable that represents the process condition or whether it encodes the statuses control FS. Input variables of the control FS encode process conditions. Output variables of the control FS encode control conditions.

[0067] The line “input vpos: posType default x0” declares a status variable having the name “vpos” that can assume the values x0, x1 and x2 (the values of the type posType) and whose initial values is x0.

[0068] The transitions serve for describing the control logic. Transitions are triggered by value combinations of the input variables of the control FS that represent process conditions—i.e. the position of the lift-off turntable HD in the vertical (vpos) and the horizontal (hpos) motion direction and the presence of a workpiece WS on the lift-off turntable HD (part_on_table). The values of the output variables vmov and hmov are modified by the transitions that use the control logic. They describe the statuses of the control. Their values are modified only by status transitions of the control, i.e. by the logic impressed on the control.

[0069] These information can be automatically taken from the CSL description. A distinction can be made between inputs of the control (inputs, sensor data) and outputs of the control (outputs: actuator commands). Moreover, the respectively possible values can be recognized (type declarations).

[0070] Even after the translation of the CSL description in what is referred to as the Finite State Machine format (FSM format), the information are essentially preserved. This FSM format represents the status-finite description in the form of what are referred to as binary decision diagrams (BDD) that have the advantage of also representing very extensive status systems in compact form in many instances R. Bryant, Symbolic Boolean Manipulation with Ordered Binary-Decision Diagrams, ACM Computing Survey, Vol. 24, No. 3, pp. 293-318, September 1992 presents an overview of binary decision diagrams (BDD).

[0071] A process model for describing the reactions of the controlled process is required in addition to the control logic described in CSL in order, for example, to enable statements about the set of achievable statuses. This can ensue in the framework of model checking with the assistance of what are referred to as assumptions. Since model checking is usually also employed in the framework of formal verification of the error-free control, these assumptions are usually already present and can be re-employed in the framework of this analysis.

[0072] The assumptions describe how the positions of the lift-off turntable HD and the presence of a workpiece WS can vary dependent on the motion direction and the current position. The below assumption

• [0073] (‘table.vmov’=stop/\‘table.vpos’=x0)/\
• [0074] x(‘table.vpos’=x0) presents that the vertical position is x0 in the next status when the vertical motion has stopped and the current vertical position down is (x0). This assumption is based on the situation that the positions do not change when no motion occurs.

[0075] Possible assumptions, i.e. conditions, for the above-described control FS are described below:

• [0076] process:=g (((‘table.vmov’=stop/\‘table.vpos’=x0)/\
• [0077] /\x(‘table.vpos’=x0)\/(‘table.vmov’=stop/\
• [0078] /\‘table.vpos’=x1)/\x(‘table.vpos’=x1)
• [0079] \/(‘table.vmov’=stop/\‘table.vpos’=x2)/\
• [0080] /\x(‘table.vpos’=x2)
• [0081] \/(‘table.vmov’=plus/\‘table.vpos’=x0)/\
• [0082] /\x(‘table.vpos’=x0\/‘table.vpos’=x1)\/
• [0083] \/(‘table.vmov’=plus/\‘table.vpos’=x1)/\
• [0084] /\x(‘table.vpos’=x1/\‘table.vpos’=x2)\/
• [0085] \/(‘table.vmov’=plus/\‘table.vpos’=x2)/\
• [0086] /\x(‘table.vpos’=x2)\\(‘table.vmov’=minus/\
• [0087] /\‘table.vpos’=x0)/\x(‘table.vpos’=x0)\/
• [0088] \/(‘table.vmov’=minus/\‘table.vpos’=x1)/\
• [0089] /\x(‘table.vpos’=x0\/‘table.vpos’=x1)\/
• [0090] \/(‘table.vmov’=minus/\‘table.vpos’=x2)/\
• [0091] /\x(‘table.vpos’=x1 \/‘table.vpos’=x2))/\
• [0092] /\((‘table.hmov’=stop/\‘table.hpos’=x0)/\
• [0093] /\x(‘table.hpos’=x0)\/(‘table.hmov’=stop/\
• [0094] /\‘table.hpos’=x1)/\x(‘table.hpos’=x1)\/
• [0095] \/(‘table.hmov’=stop/\‘table.hpos’=x2)/\
• [0096] /\x(‘table.hpos’=x2)\/(‘table.hmov’=plus/\
• [0097] /\‘table.hpos’=x0)/\x(‘table.hpos’=x0\/
• [0098] \/‘table.hpos’=x1)\/(‘table.hmov’=plus
• [0099] /\‘table.hpos’=x1)/\x(‘table.hpos’=x1\/
• [0100] \/‘table.hpos’=x2)\/(‘table.hmov’=plus/\
• [0101] /\‘table.hpos’=x2)/\x(‘table.hpos’=x2)\/
• [0102] \/(‘table.hmov’=minus/\‘table.hpos’=x0)/\
• [0103] /\x(‘table.hpos’=x0)\/(‘table.hmov’=minus/\
• [0104] /\‘table.hpos’=x1)/\x(‘table.hpos’=x0\/
• [0105] \/‘table.hpos’=x1)\/(‘table.hmov’=minus/\
• [0106] /\‘table.hpos’=x2)/\x(‘table.hpos’=x1\/
• [0107] \/‘table.hpos’=x2))/\((‘table.vpos’=x0/\
• [0108] /\‘table.hpos’=x0/\‘table.vmov’=stop/\
• [0109] /\‘table.hmov’=stop/\
• [0110] /\‘table.part_on_table’=no/\
• [0111] /\x(‘table.part_on_table’=yes))/\
• [0112] \/(‘table.vpos’=x2/\‘table.hpos’=x2/\
• [0113] /\‘table.vmov’=stop/\‘table.hmov’=stop/\
• [0114] /\‘table.part_on_table’=yes/\
• [0115] /\x(‘table.part_on_table’=no))\/
• [0116] \/(‘table.part_on_table’=yes/\
• [0117] /\x(‘table.part_on_table’=yes))\/
• [0118] \/(‘table.part_on_table’=no/\
• [0119] /\x(‘table.part_on_table’=no)))).

[0120] FIG. 8 shows a status space ZR of the lift-off turntable HD and the motion of the error-free lift-off turntable HD in the status space ZR, as derives after the implementation of the model checking on the status-finite description of the error-free control FS with the indicated assumptions.

[0121] The rows respectively show a value pair for the triad of the variables (vpos, hpos, part_on_table). A value pair for the dyad of the variables (vmov, hmov) with the respective, above-defined value sets is respectively shown in the columns.

[0122] Shaded circles in the status space ZR mark “forbidden” or, respectively, “dangerous” conditions in view of the safety condition. Bold-face circles in the status space ZR mark statuses that the lift-off turntable HD can assume according to the above description. These were determined by the model checking. Status transitions in the status space ZR are indicated with arrows.

[0123] FIG. 9 shows the status space ZR of the lift-off table HD and the movement of the liftoff turntable HD in the status space ZR when the sensor “part_on_table” incorrectly reports a workpiece WS. The same designations are employed in FIG. 9 as in FIG. 8. It can be clearly seen that statuses can occur for this error case that cannot be achieved in the error-free system. These statuses are referenced VZ in FIG. 9.

[0124] Failure probabilities that respectively describe the probability for the occurrence of an error at the sensor x or, respectively, actuator y are allocated to the individual sensors x and/or actuators y. By linking compound probabilites for the occurrence of errors of various sensors and/or actuators and for the occurrence of various statuses, a very simple risk estimate for the technical system can ensue on the basis of this procedure. Details for calculating dependent probabilities for the occurrence of error may be found in DIN 25424, Part 1: Fehlerbaumanalyse: Methode und Bildzeichen; Part 2: Handrechenverfahren zur Auswertung eines Fehlerebaums.

[0125] The error analysis thus ensues taking the failure probabilities into consideration.

[0126] The method is preferably implemented for all possible errors of the existing sensors and/or actuators.

[0127] The invention is not limited to the particular details of the method and apparatus depicted and other modifications and applications are contemplated. Certain other changes may be made in the above described method and apparatus without departing from the true spirit and scope of the invention herein involved. It is intended, therefore, that the subject matter in the above depiction shall be interpreted as illustrative and not in a limiting sense.

[0128] The following publications were cited in the framework of this document:

• [0129] [1] DIN 25424, Part 1: Fehlerbaumanalyse: Methode und Bildzeichen; Part 2: Handrechenverfahren zur Auswertung eines Fehlerebaums
• [0130] [2] J. Dekleer und B. C. Williams, Diagnosing Multiple Faults, Elsevier Science Publishers, Artificial Intelligence, Vol. 32, 1987, pp. 97-130
• [0131] [3] K. Nökel, K. Winkelmann, Controller Synthesis and Verification: A Case Study, in: C. Leverentz, T. Lindner, Formal Development of Reactive Systems, Lecture Notes in Computer Science (No. 891), Springer 1995, pp. 55-74
• [0132] [4] J. Burch et al, Symbolic Model Checking for Sequential Circuit Verification, IEEE Trans. On Computer-Aided Design of Integrated Circuits and Systems, Vol. 13, No. 4, pp. 401-424, April 1994.
• [0133] [5] R. Bryant, Symbolic Boolean Manipulation with Ordered Binary-Decision Diagrams, ACM Computing Survey, Vol. 24, No. 3, pp. 293-318, September 1992.