EP1745375A1 - Method for determining deadlocks in secondary processes - Google Patents

Method for determining deadlocks in secondary processes

Info

Publication number
EP1745375A1
EP1745375A1 EP05742661A EP05742661A EP1745375A1 EP 1745375 A1 EP1745375 A1 EP 1745375A1 EP 05742661 A EP05742661 A EP 05742661A EP 05742661 A EP05742661 A EP 05742661A EP 1745375 A1 EP1745375 A1 EP 1745375A1
Authority
EP
European Patent Office
Prior art keywords
state
system model
deadlock
objects
waiting
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP05742661A
Other languages
German (de)
French (fr)
Inventor
Michael Kersten
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens 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 Siemens AG filed Critical Siemens AG
Publication of EP1745375A1 publication Critical patent/EP1745375A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/524—Deadlock detection or avoidance

Definitions

  • the invention relates to a method for determining deadlocks in concurrent processes, in which at least one object in one state is waiting for another object in a specific state, for an object-oriented system model of a reactive system.
  • UML Unified Modeling Language
  • object-oriented, computer-implemented language not only software programs but also complex technical systems, such as motor vehicles and airplanes, can be described and their functions verified. Due to the high security requirements in these areas, the combination of a standard modeling language with formal methods is desirable in order to be able to reliably detect misconduct already in the construction phase. In such systems, deadlocks in cyclic processes can also occur.
  • a deadlock is a state of processes in which at least two processes wait for resources that are assigned to the other process. As a result, both processes block each other. A jam can then only be eliminated by ending individual processes or restarting the system. Both can be very problematic in safety-critical systems.
  • Deadlocks can occur in systems that are capable of running multiple processes in parallel (multi-task systems) and in which the order of resource allocation is not fixed.
  • T. Shufer, A. Knapp and S. Merz: "Model Checking UML State Machines and Collaborations", in: Electronic Notes in Theoretical Computer Science 47 (2001), pp. 1 - 13 describes a method for demonstrating freedom from deadlocks and other model properties for relatively small systems using the methodology of model checking.
  • These are specialized computer programs that disadvantageously require a transformation of the system into a model checker input language.
  • Each state of a state machine is modeled by an individual process. For each state machine of the UML system model, two additional processes are used to output events that are stored in an event queue and to handle transitions.
  • the object of the invention is therefore to provide an improved method for determining jams in concurrent
  • Steps a) and b) are used to extract the properties of a system model that are relevant for a deadlock, and from this in step c) a state-waiting diagram is generated, which can later be statistically analyzed to find out which "waiting-on" relations exist between active objects.
  • the internal states of the active objects are described.
  • the possible deadlock situations are determined. If no deadlock situations are found, the process is complete and the result can be displayed. Otherwise, in a third phase, the accessibility of the identified possible deadlock situations is calculated by calculating the possible paths into the identified potential deadlock situations that were found in the previous phase using a search algorithm. It is then analyzed whether these paths can be executed using a heuristic simulation approach.
  • Active objects in the sense of the invention are language means used to describe processes in the system modeling language.
  • An active object in the object-oriented model corresponds to a concurrent process of the modeled technical reactive system.
  • a concurrent process can sometimes be cyclical. This is often the case with reactive systems, but is not a necessary condition for the application of the method.
  • step a) of extracting all active objects the active objects are preferably extracted from a static and dynamic structure view of the system model and stored in an object list.
  • an assigned class is then stored in a class list for each active object and the associated state diagram for specifying a state machine is evaluated for each class in the class list.
  • the specified state machines can then be saved in a state machine list.
  • the possible deadlock situations are preferably determined using a depth-first search known per se (depth-first search).
  • the availability of the identified possible deadlock situations is preferably checked heuristically by determining the activated transitions based on an initial state of the system model and selecting the activated transition that brings the system model closer to the deadlock event.
  • Activated transitions exist, for example, when the guard condition for the assigned object is true and the event of the object is in an input queue.
  • Step e) of checking all possible paths for each deadlock situation is preferably carried out iteratively until either a deadlock state is reached or all paths have been followed by a predetermined number.
  • the system model is particularly preferably described with the Unified Modeling Language UML.
  • the object is further achieved by a computer program with program code means for carrying out the method described above when the computer program is executed on a computer.
  • Figure 1 flow chart of the method according to the invention for determining deadlocks
  • Figure 2 Static system structure (class diagram) of an exemplary measuring system model
  • Figure 4 the detailed view of the behavior of the controller of the exemplary measuring system model
  • FIG. 5 detailed view of the behavior of the first sensor of the exemplary measuring system model
  • FIG. 6 detailed view of the behavior of the second sensor of the exemplary measuring system model
  • FIG. 7 detailed view of the behavior of the clock of the exemplary measuring system model
  • the starting point is a system model described graphically and object-oriented with the Unified Modeling Language UML, hereinafter referred to as the UML system model.
  • UML system model The method is equally suitable for other description languages that describe technical systems in an object-oriented manner.
  • a) the active objects of the UML system model are extracted, as well as their properties and relations.
  • the properties of the UML system model that are relevant for jamming are extracted and stored in mathematical structures, such as lists, quantities and tuples, which enable evaluation with an effective algorithm in the subsequent phases.
  • call events are viewed as consumer events and call actions as event creators. Events are only taken into account if their producers and consumers are appropriately associated.
  • a second phase b) an analysis is carried out to identify potential deadlock events.
  • This analysis can be carried out by statically evaluating a UML state diagram to find out which waiting relationships exist between the active objects. For this purpose, a state wait graph is inserted which, in contrast to the classic wait graph, shows the internal state of the active objects. The detection of cycles in the state wait graph initiates the existence and location of potential deadlocks.
  • a potential deadlock is a cyclical waiting situation between competing or parallel components of a system, each of which is within a specific state.
  • Deadlocks can be identified in a state waiting graph.
  • This is a directed graph in which each node an active object in a specific state (of the associated state diagram) and each edge represents a "wait on" relation.
  • the number of vertices of the state wait graph is the same as the number of states of all state diagrams of the model associated with active classes.
  • the number of edges depends on the transitions defined in these state diagrams.
  • the head of each edge is connected to the node waiting for a specific event.
  • the node connected to the end of the edge is a potential originator of this special event.
  • a potential deadlock situation is a situation in which two or more objects, each in a specific state, wait for each other to generate a specific event.
  • Phase b) all cycles are detected in the state waiting graph and the relevant cycles are sorted out. Cycles are not potential deadlocks, but logical errors in the corresponding state diagram, in which all nodes of the cycle are the same object. Cycles with two or more nodes of different objects, on the other hand, are potential deadlock situations if no object with more than one state is involved in the cycle. Otherwise, these are cycles with "over-involved" objects.
  • the detection of all cycles in the state waiting graph is carried out with an improved depth search algorithm (depth-first search algorithm) which is known per se and which covers all cycles of the Graphs and the division are calculated in a single pass.
  • depth-first search algorithm depth-first search algorithm
  • the remaining potential deadlock situations are then examined with regard to the outgoing edges. This is done by traversing the graph and calculating the initial degree of each node.
  • the initial degree is the number of edges coming from the node. If all nodes have an initial degree of one, there is a potential deadlock situation in the sense of the invention. If there are nodes with an initial degree of more than one, it depends on the target object of the edge pointing out of the cycle whether the examined cycle is a potential deadlock. If the target object is not involved in the considered cycle, the examined cycle is not a deadlock. Otherwise it must be checked whether the edges connect two states of the same object.
  • the potential deadlock is combined with a logical error and the logical error should be corrected before the deadlock detection is continued. Otherwise, a further cycle is recognized in the state waiting graph, which is to be evaluated later. In this case, the next phase c) can be initiated since the cycle detection ensures that all cycles are found and processed separately in the further analysis of the accessibility of the potential deadlock situations.
  • Potential deadlock situation means that it is statistically possible that a deadlock occurs. However, whether the deadlock event actually occurs during the runtime depends on dynamic aspects of the system model, which in the next phase c) analyze the accessibility of the potential deadlock situations is examined separately from phase b) of the analysis to identify potential deadlock situations.
  • phase b If no potential jamming situation is found in phase b), the system is free of jamming and the next phase c) can be skipped.
  • phase c the accessibility of the potential deadlock situations is then analyzed.
  • Each potential deadlock situation identified in phase b) is examined by calculating the possible paths into the potential deadlock situations using a search algorithm and analyzing whether these paths can be carried out using a heuristic simulation approach.
  • the search algorithm performs a specialized depth search for each relevant state diagram and stores all paths to potential deadlock situations in a path list.
  • Each path list contains all states and transitions of the respective path.
  • the path lists are used as input data for the subsequent heuristic simulation.
  • the state machines of the UML system model are executed with a simulator that implements the exact UML semantics according to the OMG standard (www.omg.org).
  • OMG standard www.omg.org
  • the sensors Sensor1, Sensor2 have a measuring unit that carries out the actual measurement and its behavior is abstracted in the measurement system model.
  • the clock has a clockwork that models the progression of time and returns the current time when called.
  • the measuring system model also abstracts from the exact functioning of the clock.
  • the clock is required by the sensors Sensor1, Sensor2 in order to stamp the measured values with time stamps.
  • the control unit is for starting the
  • Components responsible and continuously polls both sensors Sensor1, Sensor2 at system runtime can be started and stopped by the user.
  • the behavior of the user can be modeled for analysis purposes.
  • FIG. 2 shows the static system structure of the measurement system model in the form of a class diagram.
  • the plots + and - used in the class diagram represent the visibility of the element that they precede. All elements (operations and / or attributes) annotated with "+” are declared public. These are visible to all other classes that are associated with the relevant class. Elements that are annotated with "-" are private (private) and therefore only visible within the relevant class. This means that the private elements can be called by the class itself, for example in the associated state diagram, but not by other classes. In the example, all operations of the classes are public, ie declared with "+ > . Only the attributes that are used to store values are privately declared with "- ⁇ ". This corresponds to the secret principle in object-oriented modeling and means that the values of the attributes of classes can only be manipulated with their operations, and limits the danger of side effects.
  • the query is forwarded to the measuring unit via the sensor component, which carries out the actual measurement, whereby a time stamp with the command "Give time stamp" from the clock during the measurement for everyone Sensor Sensorl, Sensor2 is queried.
  • the measured values are sent via the sensors Sensor1, Sensor2 together with the time stamp to the controller and via this to the user.
  • FIG. 3 shows a block diagram of the dynamic system structure of the measurement system model. It becomes clear that the controller is used to parameterize the clock, which in turn takes the time measurements time measurement 1, time measurement 2 when measuring by sensors Sensor1, Sensor2. The measured values together with the time stamp are sent as signals measurement 1, measurement 2 to the controller and, via this, to the environment of a user.
  • FIG. 4 shows the behavioral view of the controller as a diagram. After initialization, the controller parameterizes the clock and starts it with the command
  • the first measurement (measurement 1) is triggered by the “Sensor.Request_Measured value” command.
  • FIG. 5 shows the behavioral view of the sensor 1.
  • the measurement is carried out with a request for the time stamp on the clock with the command "Request_Measured value / clock .Request_Timestamp_Sensorl".
  • FIG. 6 shows a corresponding behavioral view of sensor 2. For the explanation, what has been said is referred to.
  • FIG. 7 shows the behavioral view of the watch.
  • the state of the parameterization of the clock is carried out by the controller and a running state "running" is stimulated with the signal "Start".
  • Control unit is requested.
  • the control unit waits for the measured value and, in a loop, the control unit requests the measured value to give further measured values.
  • the state is ended by the command "Controller. Stop” to the control unit.
  • phase a) of the feature extraction the features required for the deadlock detection are extracted from the UML system model and stored in the structures shown below.
  • this part of the feature extraction can be different. However, this is not the subject of the present invention.
  • this list is run through exactly once, and the associated class for each object is saved in a class list.
  • the length of the class list is saved as number_classes.
  • the associated state diagram is analyzed and the state machine specified there is saved in the state machine list.
  • the number m is the number of actions that can be triggered by a transition.
  • the state is the state of the state machine in which the object can generate the action if the associated transition switches.
  • the target object is the object to which the call action is addressed.
  • the target event is the event of the target object, which is generated and placed in the input queue (input queue).
  • a waiting quantity table is then created. This is achieved by selecting the associated state machine from the state machine list for each object from the object list via the associated class from the class list and determining which events (events) the object is waiting for in which state and which object can generate the respective event. The information about which object can generate the respective event is taken from the actions table.
  • the waiting quantity table has the following form:
  • the object name is listed under the entry object analogous to an action table.
  • the waiting amount is like this structured that a set of object-state combinations can be saved for each state of the state machine of the object.
  • An object-state combination has the form “object. State ", in which case” object “denotes the object to be waited for and” state "the state to be waited for.
  • object 1 in state 1 waits for object 2 in state 1 and object 2 in state 2.
  • the waiting quantity is free of duplicates.
  • the results of the feature extraction are the following:
  • Object list [Ben-> object, Con-> object, Snl-> object, Sn2-> object, U-> object]
  • Class List [User-> Class, Controller-> Class, Sensorl-> Class, Sensor-> Class, Clock-> Class]
  • phase b) "potential deadlock detection”
  • a so-called state-wait graph is generated from the waiting quantity table. This is a graph, the nodes of which denote object-state combinations and the edges of which indicate "wait-on” - Denote relationships (wait-for-relations). From this graph, statements such as object 1 is waiting in
  • a potential deadlock in the sense of the method under consideration is a cyclic "wait-for" relationship with some other properties.
  • Phase b) of the analysis to identify potential deadlock situations works in two stages. In the first stage, a cycle detection is carried out on the status wait graph. The result is a lot of potential deadlock situations. In the second stage, those potential deadlock situations that have the following properties are separated from the set of potential deadlocks:
  • the method for cycle detection is based on the well-known depth-first search method.
  • FIG. 9 shows an exemplary state waiting graph for the measuring system model.
  • the final set of potential deadlocks is passed to the next phase c) of analyzing the accessibility of the potential deadlock events.
  • the "deadlock reachability analysis” serves to prove that the potential deadlocks found can be reached at runtime of the system. Again, there are various standard methods that can be used for the reachability analysis. It is particularly important for the present method that the deadlock phase - Reachability analysis does not give away the runtime advantages that result from the extremely favorable time complexity.
  • the expected time is expected to be linear to the number of edges and nodes of the state waiting graph.
  • the first step in the analysis of the reachability of the potential deadlock events is the calculation of the local paths of the objects involved. So-called Path lists constructed that can be derived from the state machines of the model. Then the execution of the model is simulated by checking which transitions are activated, ie which, based on the initial state of the model
  • Transitions can switch if and only if the guard condition is true and the event is in the input queue. Then the transition that brings the model closer to the potential deadlock situation is selected according to a suitable heuristic.
  • the simulation stops when the potential deadlock situation has been reached or all paths have been traversed a specified number of times and no potential deadlock condition could be reached. In the latter case, no statement can be made as to whether the potential state of the deadlock can still be reached.
  • Path lists have the form:
  • Path list ⁇ [(ZI, Z2), ..., (Zi, Zj)], ... ⁇ ,
  • (ZI, Z2) is an ordered pair, where ZI denotes the source state of a transition, Z2 the target state of the transition and Zj lies in the set of potential deadlock situations.
  • a model state for a model with a number n of objects is given by
  • n denotes the respective object and Z the current state of the object.
  • ES_i is the input queue of 0_i.
  • the trace set is the set of all episodes
  • M_a is the initial state of the model and M_z the last state before termination of the simulation and (O.Z_a, O.Z_b) a transition of the object O from Z_a to Z_b.
  • FIG. 10 leaves the sequence diagram for the result of the
  • a frame with rounded corners serves to visually summarize the messages involved in the deadlock.
  • the states of the objects involved in the deadlock are specified in a note box.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Disclosed is a method for determining deadlocks in secondary processes for a system model that is described in an object-oriented manner. Said method comprises the following steps: a) all active objects of the object-oriented system model are extracted; b) the transitions between the objects are identified; c) the state-waiting relations between the objects are established; d) potential deadlocks are determined as cycles of entities of two or more different objects, which wait for each other, and for each deadlock; e) all potential paths resulting in a determined deadlock are verified by means of a simulated execution of the system model.

Description

Verfahren zur Bestimmung von Verklemmungen in nebenläufigen ProzessenProcedure for determining deadlocks in concurrent processes
Die Erfindung betrifft ein Verfahren zur Bestimmung von Verklemmungen (Deadlocks) in nebenläufigen Prozessen, bei denen mindestens ein Objekt in einem Zustand auf ein anderes Objekt in einem bestimmten Zustand wartet, für ein objektorientiert beschriebenes Systemmodell eines reaktiven Systems .The invention relates to a method for determining deadlocks in concurrent processes, in which at least one object in one state is waiting for another object in a specific state, for an object-oriented system model of a reactive system.
Für die Entwicklung und Konstruktion reaktiver Systeme hat sich die sogenannte Unified-Modeling-Language UML zu einer Standardmodellierungssprache auf dem Gebiet des objektorientierten Designs entwickelt. Mit dieser grafischen objektorientierten computerimplementierten Sprache lassen sich nicht nur Softwareprogramme, sondern auch komplexe technische Systeme, wie zum Beispiel Kraftfahrzeuge und Flugzeuge beschreiben, und deren Funktionen verifizieren. Auf Grund der hohen Sicherheitsanforderungen in diesen Gebieten ist die Kombination einer Standardmodellierungssprache mit formalen Methoden erwünscht, um Fehlverhalten bereits in der Kontruktionsphase sicher erkennen zu können. In solchen Systemen kann es auch zu Verklemmungen (Deadlocks) in zyklischen Prozessen kommen. Ein Deadlock ist in der Informatik ein Zustand von Prozessen, bei dem mindestens zwei Prozesse untereinander auf Betriebsmittel warten, die dem jeweils anderen Prozess zugeteilt sind. Hierdurch blockieren sich beide Prozesse gegenseitig. Eine Verklemmung kann dann nur durch Beendigung einzelner Prozesse oder Neustart des Sy stems beseitigt werden. Beides kann in sicherheitskritischen System sehr problematisch sein.For the development and construction of reactive systems, the so-called Unified Modeling Language UML has developed into a standard modeling language in the field of object-oriented design. With this graphic, object-oriented, computer-implemented language, not only software programs but also complex technical systems, such as motor vehicles and airplanes, can be described and their functions verified. Due to the high security requirements in these areas, the combination of a standard modeling language with formal methods is desirable in order to be able to reliably detect misconduct already in the construction phase. In such systems, deadlocks in cyclic processes can also occur. In computer science, a deadlock is a state of processes in which at least two processes wait for resources that are assigned to the other process. As a result, both processes block each other. A jam can then only be eliminated by ending individual processes or restarting the system. Both can be very problematic in safety-critical systems.
Deadlocks können bei Systemen eintreten, die fähig sind mehrere Prozesse parallel ablaufen zu lassen (Multitasksysteme) und bei denen die Reihenfolge der Betriebsmittelvergabe nicht festgelegt ist. Beispielsweise aus T. Schäfer, A. Knapp und S. Merz: "Model Checking UML State Machines and Collaborations", in: Electronic Notes in Theoretical Computer Science 47 (2001) , pp. 1 - 13 ist ein Verfahren zum Nachweis der Deadlock- Freiheit sowie anderer Modell-Eigenschaften für relativ kleine Systeme mit der Methodik des Model-Checking beschrieben. Dies sind spezialisierte Computerprogramme, die nachteilig eine Transformation des Systems in eine Modelchecker-Eingabesprache erfordern. Dabei wird jeder Zustand eines Zustandsautomatens durch einen individuellen Prozess modelliert. Für jeden Zustandsautomaten des UML- Systemmodells dienen zwei zusätzliche Prozesse zum Ausgeben von Ereignissen, die in einer Ereigniswarteschlange abgespeichert sind, und zur Behandlung von Transitionen. Für die Überprüfung objektorientierter Systemmodelle ist jedoch eine aufwendige Transformation in die verfügbaren Modellierungsspräche mit stark eingeschränkter Modellierungsmächtigkeit erforderlich. Ein großes Problem stellt auch die Berücksichtigung der Datentypen von objektorientierten Modellen dar, die zu einem sehr großen Zustandsraum führen. Dadurch ist die Größe der prüfbaren Systemmodelle beschränkt.Deadlocks can occur in systems that are capable of running multiple processes in parallel (multi-task systems) and in which the order of resource allocation is not fixed. For example from T. Schäfer, A. Knapp and S. Merz: "Model Checking UML State Machines and Collaborations", in: Electronic Notes in Theoretical Computer Science 47 (2001), pp. 1 - 13 describes a method for demonstrating freedom from deadlocks and other model properties for relatively small systems using the methodology of model checking. These are specialized computer programs that disadvantageously require a transformation of the system into a model checker input language. Each state of a state machine is modeled by an individual process. For each state machine of the UML system model, two additional processes are used to output events that are stored in an event queue and to handle transitions. To check object-oriented system models, however, a complex transformation into the available modeling languages with severely restricted modeling power is required. A major problem is also the consideration of the data types of object-oriented models, which lead to a very large state space. This limits the size of the system models that can be checked.
Aufgabe der Erfindung ist es daher, ein verbessertes Verfahren zur Bestimmung von Verklemmungen in nebenläufigenThe object of the invention is therefore to provide an improved method for determining jams in concurrent
Prozessen für objektorientiert beschriebene Systemmodelle von reaktiven Systemen zu schaffen.To create processes for object-oriented described system models of reactive systems.
Die Aufgabe wird gelöst durch die Schritte:The task is solved by the steps:
a) Extrahieren aller aktiven Objekte des objektorientierten Systemmodells;a) extracting all active objects of the object-oriented system model;
b) Feststellen mindestens der von den aktiven Objekten konsumierten und/oder produzierten Ereignissen, derb) determining at least the events consumed and / or produced by the active objects, the
Transitionen zwischen den Objekten und von Wächterbedingungen von Zustandsautomaten des UML-Systemmodells zur Beschreibung des Systemmodells zur Beschreibung des Zustandsverhaltens der Objekte;Transitions between the objects and guardian conditions of state machines of the UML system model for description the system model to describe the state behavior of the objects;
c) Erzeugen der Zustands-Warte-Relationen zwischen den aktiven Objekten aus den Ereignissen als Liste von Objekten, die in einem definierten Zustand auf ein anderes Objekt in einem definierten Zustand warten;c) generating the state-waiting relationships between the active objects from the events as a list of objects which are waiting in a defined state for another object in a defined state;
d) Ermitteln möglicher Verklemmungs-Situationen als Zyklen aufeinander wartender Instanzen von zwei oder mehr unterschiedlichen Objekten, wobei in dem Zyklus kein Objekt mit mehr als einem Zustand involviert ist und keines der Objekte des Zyklus auf ein Objekt außerhalb des Zyklus wartet; und für jede Verklemmungs-Situation;d) determining possible deadlock situations as cycles of waiting instances of two or more different objects, with no object with more than one state being involved in the cycle and none of the objects in the cycle waiting for an object outside the cycle; and for every deadlock situation;
e) Überprüfen aller möglichen Pfade die zu einer ermittelten Verklemmungs-Situation führen und aus den Zustandsautomaten des UML-Systemmodells abgeleitet werden, durch simulierte Ausführung des UML-Systemmodells unter Berücksichtigung der Ereignisse und aktivierten Transitionen zur Analyse der Erreichbarkeit der ermittelten möglichen Verklemmungs-Situationen .e) Checking all possible paths that lead to a determined deadlock situation and are derived from the state machines of the UML system model by simulated execution of the UML system model, taking into account the events and activated transitions to analyze the accessibility of the determined potential deadlock situations.
Mit einem solchem Verfahren ist der Nachweis der Deadlock- Freiheit für große objektorientierte Systemmodelle technischer reaktiver Systeme mit vielen parallelen Komponenten unter Berücksichtigung komplexer Datentypen möglich.With such a method, it is possible to prove the freedom from deadlocks for large object-oriented system models of technical reactive systems with many parallel components, taking complex data types into account.
Gemäß der vorliegenden Erfindung wird ein mehrstufigesAccording to the present invention, a multi-stage
Prüfverfahren vorgeschlagen. Mit den Schritten a) und b) werden die für einen Deadlock relevanten Eigenschaften eines Systemmodells extrahiert und hieraus im Schritt c) ein Zustands-Warte-Diagramm erzeugt, das später statistisch analysiert werden kann, um herauszufinden, welche "Warte- Auf"-Relationen zwischen aktiven Objekten existieren. Dabei werden die internen Zustände der aktiven Objekte beschrieben. In einer zweiten Phase werden die möglichen Verklemmungs- Situationen ermittelt. Sofern keine Verklemmungs-Situationen gefunden wurden, ist das Verfahren beendet und das Ergebnis kann dargestellt werden. Ansonsten erfolgt in einer dritten Phase die Analyse der Erreichbarkeit der ermittelten möglichen Verklemmungs-Situationen durch Berechnung der möglichen Pfade in die erkannten potentiellen Verklemmungs- Situationen, die in der vorhergehenden Phase aufgefunden wurden, unter Verwendung eines Suchalgorhithmus . Dann wird analysiert, ob diese Pfade durch einen heuristischen Simulationsansatz ausführbar sind.Test procedure suggested. Steps a) and b) are used to extract the properties of a system model that are relevant for a deadlock, and from this in step c) a state-waiting diagram is generated, which can later be statistically analyzed to find out which "waiting-on" relations exist between active objects. The internal states of the active objects are described. In a second phase, the possible deadlock situations are determined. If no deadlock situations are found, the process is complete and the result can be displayed. Otherwise, in a third phase, the accessibility of the identified possible deadlock situations is calculated by calculating the possible paths into the identified potential deadlock situations that were found in the previous phase using a search algorithm. It is then analyzed whether these paths can be executed using a heuristic simulation approach.
Aktive Objekte im Sinne der Erfindung sind in der Systemmodellierungssprache verwendete Sprachmittel zur Beschreibung von Prozessen. Ein aktives Objekt im objektorientierten Modell entspricht einem nebenläufigen Prozess des modellierten technischen reaktiven Systems. Ein nebenläufiger Prozess kann unter Umständen zyklisch sein. Dies ist bei reaktiven Systemen häufig der Fall, aber keine notwendige Bedingung für die Anwendung des Verfahrens.Active objects in the sense of the invention are language means used to describe processes in the system modeling language. An active object in the object-oriented model corresponds to a concurrent process of the modeled technical reactive system. A concurrent process can sometimes be cyclical. This is often the case with reactive systems, but is not a necessary condition for the application of the method.
Vorzugsweise werden im Schritt a) des Extrahierens aller aktiven Objekte die aktiven Objekte aus einer statischen und dynamischen Struktursicht des Systemmodells extrahiert und in einer Objekt-Liste gespeichert.In step a) of extracting all active objects, the active objects are preferably extracted from a static and dynamic structure view of the system model and stored in an object list.
Vorteilhaft ist, wenn dann für jedes aktive Objekt eine zugeordnete Klasse in einer Klassen-Liste abgespeichert wird und für jede Klasse in der Klassen-Liste das zugehörige Zustandsdiagramm zur Spezifikation eines Zustandsautomaten ausgewertet wird. Die spezifizierten Zustandsautomaten können dann in einer Zustandsautomaten-Liste abgespeichert werden.It is advantageous if an assigned class is then stored in a class list for each active object and the associated state diagram for specifying a state machine is evaluated for each class in the class list. The specified state machines can then be saved in a state machine list.
Auf diese Weise wird eine mathematische Listenstruktur bereitgestellt, die eine effektive analytische Auswertung ermöglicht. Die Ermittlung der möglichen Verklemmungs-Situationen erfolgt vorzugsweise mit einem an sich bekannten Tiefensucheverfahren (Depth-First-Search) .In this way, a mathematical list structure is provided, which enables an effective analytical evaluation. The possible deadlock situations are preferably determined using a depth-first search known per se (depth-first search).
Die Überprüfung der Erreichbarkeit der ermittelten möglichen Verklemmungs-Situationen erfolgt vorzugsweise heuristisch, in dem ausgehend von einem initialen Zustand des Systemmodells die jeweils aktivierten Transitionen ermittelt werden und diejenige aktivierte Transition ausgewählt wird, welche das Systemmodell näher an das Verklemmungs-Ereignis heranbringt.The availability of the identified possible deadlock situations is preferably checked heuristically by determining the activated transitions based on an initial state of the system model and selecting the activated transition that brings the system model closer to the deadlock event.
Aktivierte Transitionen liegen beispielsweise dann vor, wenn die Wächterbedingung für das zugeordnete Objekt wahr ist und das Ereignis des Objektes in einer Eingabewarteschlange liegt.Activated transitions exist, for example, when the guard condition for the assigned object is true and the event of the object is in an input queue.
Vorzugsweise wird der Schritt e) des Überprüfens aller möglichen Pfade für jede Verklemmungs-Situation (Phase C) , solange iterativ durchgeführt, bis entweder ein Verklemmungs- Zustand erreicht ist oder alle Pfade eine festgelegte Anzahl durchlaufen wurden.Step e) of checking all possible paths for each deadlock situation (phase C) is preferably carried out iteratively until either a deadlock state is reached or all paths have been followed by a predetermined number.
Das Systemmodell wird besonders bevorzugt mit der Unified- Modeling-Language UML beschrieben.The system model is particularly preferably described with the Unified Modeling Language UML.
Die Aufgabe wird weiterhin durch ein Computerprogramm mit Programmcodemitteln zur Durchführung des oben beschriebenen Verfahrens gelöst, wenn das Computerprogramm auf einem Rechner ausgeführt wird.The object is further achieved by a computer program with program code means for carrying out the method described above when the computer program is executed on a computer.
Die Erfindung wird nachfolgend an Hand der beigefügten Zeichnungen beispielhaft näher erläutert. Es zeigen:The invention is explained in more detail below with reference to the accompanying drawings. Show it:
Figur 1 - Flussdiagramm des erfindungsgemäßen Verfahrens zur Bestimmung von Verklemmungen; Figur 2 - Statische Systemstruktur (Klassendiagramm) eines beispielhaften Messsystemmodells;Figure 1 - flow chart of the method according to the invention for determining deadlocks; Figure 2 - Static system structure (class diagram) of an exemplary measuring system model;
Figur 3 - Dynamische Systemstruktur des beispielhaften Messsystemmodells aus Figur 2;Figure 3 - Dynamic system structure of the exemplary measurement system model from Figure 2;
Figur 4 - der Detailansicht des Verhaltens des Controllers des beispielhaften MesssystemmodellsFigure 4 - the detailed view of the behavior of the controller of the exemplary measuring system model
Figur 5 - Detailansicht des Verhaltens des ersten Sensors des beispielhaften Messsystemmodells;FIG. 5 - detailed view of the behavior of the first sensor of the exemplary measuring system model;
Figur 6 - Detailansicht des Verhaltens des zweiten Sensors des beispielhaften Messsystemmodells;FIG. 6 - detailed view of the behavior of the second sensor of the exemplary measuring system model;
Figur 7 - Detailansicht des Verhaltens der Uhr des beispielhaften Messsystemmodells;FIG. 7 - detailed view of the behavior of the clock of the exemplary measuring system model;
Figur 8 - Detailansicht des Verhaltens des Benutzers des beispielhaften Mess- SystemsFigure 8 - Detailed view of the behavior of the user of the exemplary measurement system
Figur 9 - Zustands-Warte-Graph eines beispielhaftenFigure 9 - State waiting graph of an exemplary
Durchlaufs zur Erkennung potentieller Verklemmungen;Run to detect potential deadlocks;
Figur 10 - Sequenzdiagramm zur Darstellung desFigure 10 - sequence diagram to illustrate the
Analyseergebnisses des erfindungsgemäßen Verfahrens amAnalysis result of the method according to the invention on
Beispiel des Messsystemmodells.Example of the measuring system model.
Die Figur 1 lässt ein Flussdiagramm des erfindungsgemäßen mehrphasigen Verfahrens zur Bestimmungen von Verklemmungen1 shows a flow diagram of the multiphase method according to the invention for determining deadlocks
(Deadlocks) in nebenläufigen Prozessen erkennen.Detect (deadlocks) in concurrent processes.
Ausgangspunkt ist ein mit der Unified-Modeling-Language UML grafisch und objektorientiert beschriebenes Systemmodell, nachfolgend UML-Systemmodell genannt. Das Verfahren ist gleichermaßen für andere Beschreibungssprachen geeignet, die technische Systeme objektorientiert beschreiben. In einer ersten Phase a) erfolgt eine Extraktion der aktiven Objekte des UML-Systemmodells, sowie deren Eigenschaften und Relationen. Die für eine Verklemmung relevanten Eigenschaften des UML-Systemmodells werden dabei extrahiert und in mathematische Strukturen, wie zum Beispiel Listen, Mengen und Tupel abgespeichert, die eine Auswertung mit einem effektiven Algorithmus in den nachfolgenden Phasen ermöglichen.The starting point is a system model described graphically and object-oriented with the Unified Modeling Language UML, hereinafter referred to as the UML system model. The method is equally suitable for other description languages that describe technical systems in an object-oriented manner. In a first phase a) the active objects of the UML system model are extracted, as well as their properties and relations. The properties of the UML system model that are relevant for jamming are extracted and stored in mathematical structures, such as lists, quantities and tuples, which enable evaluation with an effective algorithm in the subsequent phases.
Bei der Extraktion werden alle aktiven Klassen des UML- Systemmodells hinsichtlich ihrer Kommunikationseigenschaften analysiert. Konkret bedeutet dies, dass für jede aktive Klasse ein Satz von erzeugten Ereignissen und konsumierten Ereignissen berechnet und in Erzeuger-Ereignis-Listen und Verbraucher-Ereignis-Listen abgespeichert wird. In dieserDuring extraction, all active classes of the UML system model are analyzed with regard to their communication properties. Specifically, this means that a set of generated events and consumed events is calculated for each active class and stored in producer event lists and consumer event lists. In this
Hinsicht werden Aufruf-Ereignisse als Verbraucher-Ereignisse und Aufrufaktionen als Erzeuger von Ereignissen angesehen. Ereignisse werden nur dann berücksichtigt, wenn ihre Erzeuger und Verbraucher geeignet assoziiert sind.In this regard, call events are viewed as consumer events and call actions as event creators. Events are only taken into account if their producers and consumers are appropriately associated.
In einer zweiten Phase b) erfolgt eine Analyse zur Erkennung potentieller Verklemmungs-Ereignisse. Diese Analyse kann durch statische Auswertung eines UML-Zustandsdiagramms erfolgen, um herauszufinden, welche Warte-Relationen zwischen den aktiven Objekten existieren. Für diesen Zweck wird ein Zustands-Warte-Graph eingefügt, der im Unterschied zum klassischen Wartegraphen den internen Zustand der aktiven Objekte wiedergibt. Die Detektion von Zyklen in dem Zustands- Warte-Graphen initiiert die Existenz und den Ort potentieller Verklemmungen.In a second phase b) an analysis is carried out to identify potential deadlock events. This analysis can be carried out by statically evaluating a UML state diagram to find out which waiting relationships exist between the active objects. For this purpose, a state wait graph is inserted which, in contrast to the classic wait graph, shows the internal state of the active objects. The detection of cycles in the state wait graph initiates the existence and location of potential deadlocks.
Eine potentielle Verklemmung ist eine zyklische Wartesituation zwischen konkurrierenden oder parallelen Komponenten eines Systems, die sich jeweils innerhalb eines spezifischen Zustands befinden. Die potentiellenA potential deadlock is a cyclical waiting situation between competing or parallel components of a system, each of which is within a specific state. The potential
Verklemmungen können in einem Zustands-Warte-Graphen erkannt werden. Dies ist ein gerichteter Graph, in dem jeder Knoten ein aktives Objekt in einem spezifischen Zustand (des zugeordneten Zustandsdiagramms) und jede Kante eine "Warteauf"-Relation darstellt. Die Anzahl der Scheitelpunkte des Zustands-Warte-Graphen ist die gleiche wie die Anzahl von Zuständen aller Zustandsdiagramme des Modells, die aktiven Klassen zugeordnet sind. Die Anzahl der Kanten hängt von den in diesen Zustandsdiagrammen definierten Transitionen ab. Der Kopf jeder Kante ist mit dem auf ein spezifisches Ereignis wartenden Knoten verbunden. Der mit dem Ende der Kante verbundene Knoten ist ein potentieller Urheber dieses speziellen Ereignisses.Deadlocks can be identified in a state waiting graph. This is a directed graph in which each node an active object in a specific state (of the associated state diagram) and each edge represents a "wait on" relation. The number of vertices of the state wait graph is the same as the number of states of all state diagrams of the model associated with active classes. The number of edges depends on the transitions defined in these state diagrams. The head of each edge is connected to the node waiting for a specific event. The node connected to the end of the edge is a potential originator of this special event.
Die Analyse potentieller Verklemmungs-Situationen startet mit der Erzeugung eines Zustands-Warte-Graphen. Dies wird durch Berechnung der in der Phase der Extraktion der aktivenThe analysis of potential deadlock situations starts with the generation of a state waiting graph. This is done by calculating the active in the extraction phase
Objekte und deren Eigenschaften und Relationen, zum Beispiel durch Berechnung von Konsumenten- und Produzenten-Listen durchgeführt. Nach Erzeugung des gesamten Zustands-Warte- Graphen des Systems können potentielle Verklemmungs- Situationen detektiert werden. Eine potentielle Verklemmungs- Situation ist eine Situation, in dem zwei oder mehrere Objekte jeweils in einem spezifischen Zustand gegenseitig auf die Erzeugung eines bestimmten Ereignisses warten.Objects and their properties and relations, for example by calculating consumer and producer lists. After generating the entire state-waiting graph of the system, potential deadlock situations can be detected. A potential deadlock situation is a situation in which two or more objects, each in a specific state, wait for each other to generate a specific event.
Bei dem erfindungsgemäßen Verfahren werden nunmehr in derIn the method according to the invention are now in the
Phase b) alle Zyklen in dem Zustands-Warte-Graphen detektiert und die relevanten Zyklen aussortiert. Dabei sind Zyklen keine potentiellen Deadlocks, sondern logische Fehler in dem korrespondierenden Zustandsdiagramm, bei denen alle Knoten des Zykluses dasselbe Objekt sind. Zyklen mit zwei oder mehr Knoten unterschiedlicher Objekte sind hingegen potentielle Deadlock-Situationen, wenn kein Objekt mit mehr als einem Zustand in dem Zyklus involviert ist. Andernfalls handelt es sich um Zyklen mit "über-beteiligten" Objekten. Die Detektion aller Zyklen in dem Zustands-Warte-Graphen wird mit einem verbesserten an sich bekannten Tiefensuchalgorithmus (Depth- First-Search Algorhythm) durchgeführt, der alle Zyklen des Graphen und die Aufteilung in einem einzigen Durchlauf berechnet. Die Erkennung logischer Fehler und Zyklen mit "über-beteiligten" Objekten wird unter Verwendung von Mengen- Operationen (Set-Operations) durchgeführt. Anschließend werden die verbleibenden potentiellen Deadlock-Situationen hinsichtlich der abgehenden Kanten untersucht. Dies wird durch Durchquerung des Graphen und Berechnung des Ausgangsgrades von jedem Knoten durchgeführt. Der Ausgangsgrad ist die Anzahl der vom Knoten abgehenden Kanten. Wenn alle Knoten einen Ausgangsgrad von eins haben, liegt eine potentielle Deadlock-Situation im Sinne der Erfindung vor. Falls Knoten mit einem Ausgangsgrad von mehr als eins vorhanden sind, hängt es von dem Zielobjekt der aus dem Zyklus herausweisenden Kante ab, ob der untersuchte Zyklus ein potentieller Deadlock ist. Wenn das Zielobjekt nicht in den betrachteten Zyklus involviert ist, handelt es sich bei dem untersuchten Zyklus nicht um einen Deadlock. Andernfalls muss überprüft werden, ob die Kanten zwei Zustände des gleichen Objektes verbinden. Falls bei dieser Überprüfung festgestellt wird, dass die Kanten zwei Zustände des gleichen Objektes verbinden, wird der potentielle Deadlock mit einem logischen Fehler kombiniert und der logische Fehler sollte korrigiert werden, bevor die Deadlock-Erkennung weitergeführt wird. Ansonsten wird ein weiterer Zyklus in dem Zustands- Warte-Graphen erkannt, der später auszuwerten ist. In diesem Fall kann die nächste Phase c) initiiert werden, da die Zyklendetektion sicherstellt, dass alle Zyklen aufgefunden und separat in der weiteren Analyse der Erreichbarkeit der potentiellen Verklemmungs-Situationen abgearbeitet werden.Phase b) all cycles are detected in the state waiting graph and the relevant cycles are sorted out. Cycles are not potential deadlocks, but logical errors in the corresponding state diagram, in which all nodes of the cycle are the same object. Cycles with two or more nodes of different objects, on the other hand, are potential deadlock situations if no object with more than one state is involved in the cycle. Otherwise, these are cycles with "over-involved" objects. The detection of all cycles in the state waiting graph is carried out with an improved depth search algorithm (depth-first search algorithm) which is known per se and which covers all cycles of the Graphs and the division are calculated in a single pass. The detection of logical errors and cycles with "over-involved" objects is carried out using set operations. The remaining potential deadlock situations are then examined with regard to the outgoing edges. This is done by traversing the graph and calculating the initial degree of each node. The initial degree is the number of edges coming from the node. If all nodes have an initial degree of one, there is a potential deadlock situation in the sense of the invention. If there are nodes with an initial degree of more than one, it depends on the target object of the edge pointing out of the cycle whether the examined cycle is a potential deadlock. If the target object is not involved in the considered cycle, the examined cycle is not a deadlock. Otherwise it must be checked whether the edges connect two states of the same object. If this check determines that the edges connect two states of the same object, the potential deadlock is combined with a logical error and the logical error should be corrected before the deadlock detection is continued. Otherwise, a further cycle is recognized in the state waiting graph, which is to be evaluated later. In this case, the next phase c) can be initiated since the cycle detection ensures that all cycles are found and processed separately in the further analysis of the accessibility of the potential deadlock situations.
Potentielle Verklemmungs-Situation (Deadlock) bedeutet, dass es statistisch möglich ist, dass ein Deadlock auftritt. Ob das Deadlock-Ereignis tatsächlich während der Laufzeit eintritt hängt jedoch von dynamischen Aspekten des Systemmodells ab, die in der nächsten Phase c) der Analyse der Erreichbarkeit der potentiellen Verklemmungs-Situationen separat von der Phase b) der Analyse zur Erkennung potentieller Verklemmungs-Situationen untersucht wird.Potential deadlock situation means that it is statistically possible that a deadlock occurs. However, whether the deadlock event actually occurs during the runtime depends on dynamic aspects of the system model, which in the next phase c) analyze the accessibility of the potential deadlock situations is examined separately from phase b) of the analysis to identify potential deadlock situations.
Falls keine potentiellen Verklemmungs-Situation in der Phase b) aufgefunden werden, ist das System verklemmungsfrei und die nächste Phase c) kann übersprungen werden.If no potential jamming situation is found in phase b), the system is free of jamming and the next phase c) can be skipped.
In der Phase c) erfolgt dann die Analyse der Erreichbarkeit der potentiellen Verklemmungs-Situationen. Hierbei wird jedes in der Phase b) erkannte potentielle Verklemmungs-Situation untersucht, indem die möglichen Pfade in die potentiellen Verklemmungs-Situationen unter Verwendung eines Suchalgorithmus berechnet und dahingehend mit einem heuristischen Simulationsansatz analysiert werden, ob diese Pfade ausführbar sind. Der Suchalgorithmus führt eine spezialisierte Tiefensuche für jedes relevante Zustandsdiagramm durch und speichert alle Pfade zu potentiellen Verklemmungs-Situationen in einer Pfadliste. Jede Pfadliste enthält alle Zustände und Transitionen des jeweiligen Pfades.In phase c), the accessibility of the potential deadlock situations is then analyzed. Each potential deadlock situation identified in phase b) is examined by calculating the possible paths into the potential deadlock situations using a search algorithm and analyzing whether these paths can be carried out using a heuristic simulation approach. The search algorithm performs a specialized depth search for each relevant state diagram and stores all paths to potential deadlock situations in a path list. Each path list contains all states and transitions of the respective path.
Die Pfadlisten werden als Eingangsdaten für die nachfolgende heuristische Simulation genutzt. In der Simulation werden die Zustandsautomaten des UML-Systemmodells mit einem Simulator ausgeführt, der die exakte UML-Semantik gemäß OMG-Standard (www.omg.org) implementiert. Neben sehr speziellen Merkmalen, wie die Warteschlangenlänge und die Untersuchungsreihenfolge von in den Semantiken definierten Ausdrücken müssen die folgenden Aspekte des Modells berücksichtigt werden:The path lists are used as input data for the subsequent heuristic simulation. In the simulation, the state machines of the UML system model are executed with a simulator that implements the exact UML semantics according to the OMG standard (www.omg.org). In addition to very special features, such as the queue length and the examination sequence of expressions defined in the semantics, the following aspects of the model must be taken into account:
Wächterbedingungen, Ereignisparameterwerte und Atributwerte.Guard conditions, event parameter values and attribute values.
Für den Fall, dass eine oder mehrere Pfade in eine potentielle Deadlock-Situation vorhanden sind, ist es ausreichend, einen ausführbaren Pfad während der Simulation aufzufinden. Der andere Fall ist wesentlich aufwendiger. Wenn alle Pfade der Pfadliste einmal ausgeführt wurden und dabei kein ausführbarer Pfad aufgefunden wurde kann nicht gefolgert werden, ob ein ausführbarer Pfad vorhanden ist oder nicht. Auch nach theoretisch unendlich vielen Ausführungen kann nicht mit abschließender Sicherheit ausgesagt werden, dass die nächste Ausführung nicht in eine potentielle Deadlock- Situation führt. Es wird daher vorgeschlagen, die Simulation nach einer festlegbaren Anzahl n von Ausführungen abzubrechen .In the event that one or more paths exist in a potential deadlock situation, it is sufficient to find an executable path during the simulation. The other case is much more complex. When all paths in the path list have been executed once and in the process no executable path was found, it cannot be concluded whether an executable path exists or not. Even after the theoretically infinite number of executions, it cannot be said with certainty that the next execution will not lead to a potential deadlock situation. It is therefore proposed to cancel the simulation after a definable number n of executions.
Der Nachteil dieses heuristischen Simulationsansatzes ist, dass die Nichtexistenz von Deadlocks nicht bewiesen werden kann, falls potentielle Verklemmungs-Situationen vorliegen, die in der Phase c) nicht erreichbar sind, d. h. bei denen kein ausführbarer Pfad nach einer Anzahl n Simulationen aufgefunden wurde. In diesem Ausnahmefall hilft nur eine aufwendige Suche über einen vollständig ungefalteten Zustandsraum zur Modellprüfung.The disadvantage of this heuristic simulation approach is that the non-existence of deadlocks cannot be proven if there are potential deadlock situations that cannot be reached in phase c). H. in which no executable path was found after a number of n simulations. In this exceptional case, only a time-consuming search over a completely unfolded state space helps to test the model.
In der letzten Phase d) werden die Analyseergebnisse dann dargestellt. Dies kann beispielsweise mit einem erweiterten UML-Sequenzdiagramm erfolgen.In the last phase d) the analysis results are then presented. This can be done, for example, with an extended UML sequence diagram.
Das erfindungsgemäße Verfahren wird nachfolgend an Hand eines Beispiels eines Mess-Systemmodells beschrieben, das aus einem ersten und zweiten Sensor Sensorl und Sensor2, einerThe method according to the invention is described below using an example of a measurement system model, which consists of a first and second sensor Sensor1 and Sensor2, one
Steuerungseinheit Controller sowie einer Uhr besteht. Die Sensoren Sensorl, Sensor2 verfügen über eine Messeinheit, die die eigentliche Messung durchführt und deren Verhalten im Mess-Systemmodell abstrahiert wird. Die Uhr verfügt über ein Uhrwerk, dass das Fortschreiten der Zeit modelliert und bei Aufruf den aktuellen Zeitpunkt zurückliefert. Auch von der exakten Funktionsweise der Uhr wird im Mess-Systemmodell abstrahiert. Die Uhr wird von den Sensoren Sensorl, Sensor2 benötigt, um die Messwerte mit Zeitstempeln zu versehen. Die Steuerungseinheit Controller ist für das Starten derControl unit controller and a clock exists. The sensors Sensor1, Sensor2 have a measuring unit that carries out the actual measurement and its behavior is abstracted in the measurement system model. The clock has a clockwork that models the progression of time and returns the current time when called. The measuring system model also abstracts from the exact functioning of the clock. The clock is required by the sensors Sensor1, Sensor2 in order to stamp the measured values with time stamps. The control unit is for starting the
Komponenten zuständig und fragt zur Laufzeit des Systems immer wieder beide Sensoren Sensorl, Sensor2 ab. Das System kann durch den Benutzer gestartet und gestoppt werden. Das Verhalten des Benutzers kann zu Analysezwecken modelliert werden .Components responsible and continuously polls both sensors Sensor1, Sensor2 at system runtime. The system can be started and stopped by the user. The behavior of the user can be modeled for analysis purposes.
Die Figur 2 lässt die statische Systemstruktur des Mess- Systemmodells in Form eines Klassendiagramms erkennen.FIG. 2 shows the static system structure of the measurement system model in the form of a class diagram.
Die im Klassendiagramm verwendeten Zeichnen + und - stehen für die Sichtbarkeit des Elements, dem sie vorangestellt sind. Alle mit „+" annotierten Elemente (Operationen und/oder Attribute) sind als öffentlich (public) deklariert. Diese sind für alle anderen Klassen, die mit der betreffenden Klasse assoziiert sind, sichtbar. Elemente, die mit „-" annotiert sind, sind privat (private) und deshalb nur innerhalb der betreffende Klasse sichtbar. D. h., dass die privaten Elemente zwar von der Klasse selbst zum Beispiel im zugehörigen Zustandsdiagramm aufgerufen werden können, aber nicht von anderen Klassen. Im Beispiel sind alle Operationen der Klassen öffentlich, d. h. mit „+> deklariert. Nur die Attribute, die zum Speichern von Werten dienen sind privat mit ,,-■" deklariert. Dies entspricht dem Geheimnisprinzip in der objektorientierten Modellierung und bewirkt, dass die Werte der Attribute von Klassen nur mit deren Operationen manipuliert werden können, und schränkt die Gefahr von Seiteneffekten ein.The plots + and - used in the class diagram represent the visibility of the element that they precede. All elements (operations and / or attributes) annotated with "+" are declared public. These are visible to all other classes that are associated with the relevant class. Elements that are annotated with "-" are private (private) and therefore only visible within the relevant class. This means that the private elements can be called by the class itself, for example in the associated state diagram, but not by other classes. In the example, all operations of the classes are public, ie declared with "+ > . Only the attributes that are used to store values are privately declared with "- ■ ". This corresponds to the secret principle in object-oriented modeling and means that the values of the attributes of classes can only be manipulated with their operations, and limits the danger of side effects.
Es wird deutlich, dass der Benutzer in einer Anfrage "Gebe_Messwert" für zwei Werte Wert 1, Wert2 stellt, die dieser vom Controller als Parameter zurückerhält. Der Controller startet den Messprozess mit dem Befehl "+Start()" und fordert Messwerte des ersten und zweiten Sensors Sensorl, Sensor2 an (Gebe_Messwert_Sensorl, Gebe_Messwert_Sensor2) .It becomes clear that the user in a query "Give_Measured value" sets value 1, value 2 for two values, which the controller receives back as a parameter. The controller starts the measuring process with the command "+ Start ()" and requests measured values from the first and second sensors Sensorl, Sensor2 (Gebe_Messwert_Sensorl, Gebe_Messwert_Sensor2).
Die Anfrage wird über die Komponente Sensor an die Messeinheit weitergeleitet, die die eigentliche Messung durchführt, wobei ein Zeitstempel mit dem Befehl "Gebe Zeitstempel" von der Uhr bei der Messung für jeden Sensor Sensorl, Sensor2 abgefragt wird. Die Messwerte werden über die Sensoren Sensorl, Sensor2 zusammen mit dem Zeitstempel an den Controller und über diesen an den Benutzer zurückgeschickt .The query is forwarded to the measuring unit via the sensor component, which carries out the actual measurement, whereby a time stamp with the command "Give time stamp" from the clock during the measurement for everyone Sensor Sensorl, Sensor2 is queried. The measured values are sent via the sensors Sensor1, Sensor2 together with the time stamp to the controller and via this to the user.
Die Figur 3 lässt ein Blockdiagramm der dynamischen Systemstruktur des Mess-Systemmodells erkennen. Es wird deutlich, dass der Controller zur Parametrierung der Uhr genutzt wird, die ihrerseits die Zeitmessungen Zeitmessung 1, Zeitmessung 2 bei der Messung durch die Sensoren Sensorl, Sensor2 vornimmt. Die Messwerte werden zusammen mit dem Zeitstempeln als Signale Messung 1, Messung 2 an den Controller und über diesen an die Umgebung eines Benutzers zurückgeschickt .FIG. 3 shows a block diagram of the dynamic system structure of the measurement system model. It becomes clear that the controller is used to parameterize the clock, which in turn takes the time measurements time measurement 1, time measurement 2 when measuring by sensors Sensor1, Sensor2. The measured values together with the time stamp are sent as signals measurement 1, measurement 2 to the controller and, via this, to the environment of a user.
Das Verhalten der einzelnen Systemelemente ist wie folgt:The behavior of the individual system elements is as follows:
Die Figur 4 lässt die Verhaltenssicht des Controllers als Diagramm erkennen. Nach der Initialisierung parametrisiert der Controller die Uhr und startet diese mit dem BefehlFIG. 4 shows the behavioral view of the controller as a diagram. After initialization, the controller parameterizes the clock and starts it with the command
"Start/Uhr . Start" . Weiterhin wird die erste Messung (Messung 1) durch den Befehl "Sensor.Anfrage_Messwert" angestoßen. Anschließend wird der Messwert des ersten Sensors abgefragt (Gebe_Messwert_Sensorl (Messwert) /Messwert l:=Messwert) und die zweite Messung (Messung 2) durch den zweiten Sensor (Sensor2) mit dem Befehl "Sensor2.Anfrage_Messwert" angestoßen. Von der zweiten Messung (Messung 2) erfolgt eine Rückkopplung zur ersten Messung (Messung 1) mit den Anfragen "Gebe_Messwert_Sensor2 (Messwert) /Messwert 2 :=Mess-wert" der erneuten Anfrage des Messwerts bei Sensorl durch den Befehl "Sensorl .Anfrage_Messwert" sowie gegebenenfalls die Weitergabe der Messwerte an den Benutzer durch den Befehl "Benutzer. Gebe_Messwert (Messwert 1, Messwert 2)"."Start / Clock. Start". Furthermore, the first measurement (measurement 1) is triggered by the "Sensor.Request_Measured value" command. The measured value of the first sensor is then queried (Gebe_Messwert_Sensorl (measured value) / measured value l: = measured value) and the second measurement (measurement 2) is initiated by the second sensor (Sensor2) with the command "Sensor2.Anfrage_Messwert". From the second measurement (measurement 2) there is a feedback to the first measurement (measurement 1) with the requests "Give_Measured value_Sensor2 (measured value) / measured value 2: = measured value" of the new request for the measured value from Sensorl using the command "Sensor request. Measured value" and, if necessary, the transmission of the measured values to the user by the command "User. Give_measured value (measured value 1, measured value 2)".
Diese Schleife wird solange durchlaufen, bis Stoppsignale für die Uhr, den Sensorl und den Sensor2 ausgeschickt werden (Stop/Uhr. Stop) ; Sensorl .Stop; Sensor2. Stop). Die Figur 5 lässt die Verhaltenssicht des Sensorsl erkennen. Nach Initialisierung erfolgt die Messung mit einer Anfrage nach dem Zeitstempel bei der Uhr mit dem Befehl "Anfrage_Messwert/Uhr .Anfrage_Zeitstempel_Sensorl" . Das Ergebnis des Zustands Hole_Zeit ist die Weitergabe des Zeitstempels an den Sensorl zur Verknüpfung mit dem Messwert Sensorl (Gebe_Zeitstempel/Aktuell :=Messeinheit . MessungO; Controller .Gebe_Messwert_Sensorl (Aktuell) .This loop is run through until stop signals for the clock, Sensor1 and Sensor2 are sent (Stop / Uhr. Stop); Sensorl .Stop; Sensor2. Stop). FIG. 5 shows the behavioral view of the sensor 1. After initialization, the measurement is carried out with a request for the time stamp on the clock with the command "Request_Measured value / clock .Request_Timestamp_Sensorl". The result of the Hole_Zeit state is the forwarding of the time stamp to the Sensorl for linking with the measured value Sensorl (Gebe_Zeitstempel / Aktuell: = measuring unit. MeasurementO; controller .Gebe_Messwert_Sensorl (current).
Nach Erhalt des Stopp-Signals "Sensorl .Stop" wird der Zustand "Messen" beendet.After receiving the stop signal "Sensorl .Stop", the state "Measure" is ended.
Die Figur 6 lässt eine entsprechende Verhaltenssicht des Sensors2 erkennen. Für die Erläuterung wird das vorher gesagte verwiesen.FIG. 6 shows a corresponding behavioral view of sensor 2. For the explanation, what has been said is referred to.
Die Figur 7 lässt die Verhaltenssicht der Uhr erkennen. Nach Initialisierung erfolgt der Zustand der Parametrierung der Uhr durch den Controller und es wird mit dem Signal "Start" ein laufender Zustand "laufend" angeregt. Dieser Zustand gibt einen Zeitstempel an den Sensorl (Sensorl .Gebe_Zeitstempel (Zeitstempel) ) weiter und beantwortet die Anfrage nach einem Zeitstempel durch den Sensor2 durch Setzen des Zeitstempels auf die aktuelle Uhrzeit des Uhrwerks (Anfrage_Zeitstempel_Sensor2/Zeitstempel :=Uhrwerk.aktuelle_Ze it()). Solange ein Zustand "Anfrage_l" noch eine Anfrage nach einem Zeitstempel durch einer der Sensoren Sensorl, Sensor2 feststellt, wird mit den Befehlen "Anfrage_Zeitstempel_Sensor2/Zeitstempel :=Uhrwerk.Aktuelle_Ze it" der Zeitstempel für den Sensor2 festgestellt und dem Sensor2 mit dem BefehlFIG. 7 shows the behavioral view of the watch. After initialization, the state of the parameterization of the clock is carried out by the controller and a running state "running" is stimulated with the signal "Start". This state passes on a time stamp to the sensor (Sensor.Gebe_Zeitstempel (time stamp)) and answers the request for a time stamp by Sensor2 by setting the time stamp to the current time of the clockwork (request_Zeitstempel_Sensor2 / Zeitstempel: = Uhrwerk.aktuelle_Ze it ()) , As long as a state "Inquiry_1" still detects an inquiry for a time stamp by one of the sensors Sensor1, Sensor2, the commands "Inquiry_TimeStamp_Sensor2 / Timestamp: = Clockwork.Actual_Time" determine the time stamp for Sensor2 and Sensor2 with the command
"Sensor2.Gebe_Zeitstempel (Zeitstempel) " ein Zeitstempel zugeordnet ."Sensor2.Gebe_Zeitstempel (timestamp)" is assigned a timestamp.
Ansonsten wird mit dem Befehl "Stop" der Zusand gestoppt. Die Verhaltenssicht des Benutzers ist in der Figur 8 dargestellt. Nach der Initialisierung wird im Zustand "Starte" durch den Befehl "Controller .Start" die Steuerungseinheit gestartet und der Zustand "Beobachter" aufgerufen, indem das Ereignis "Gebe-Messwert" von derOtherwise, the delivery is stopped with the "Stop" command. The behavioral view of the user is shown in FIG. 8. After initialization, the "Controller .Start" command starts the control unit in the "Start" state and the "Observer" state is called up by the "Send measured value" event from the
Steuerungseinheit abgefordert wird. In dem anschließenden Zustand "Beobachter2" wird auf den Messwert von der Steuerungseinheit gewartet und in einer Schleife durch die Anfrage "Gebe-Messwert" von der Steuerungseinheit weitere Messwerte abgefordert. Der Zustand wird durch den Befehl "Controller. Stop" an die Steuerungseinheit beendet.Control unit is requested. In the subsequent state "Observer2", the control unit waits for the measured value and, in a loop, the control unit requests the measured value to give further measured values. The state is ended by the command "Controller. Stop" to the control unit.
Für dieses beispielhafte Mess-Systemmodell wird nun zurückkommend auf die Figur 1 auf die Phasen a) bis d) im einzelnen eingegangen.For this exemplary measurement system model, returning to FIG. 1, phases a) to d) will be discussed in detail.
In der Phase a) der Merkmalsextraktion werden die für die Deadlock-Detektion benötigten Merkmale aus dem UML- Systemmodell extrahiert und in den im folgenden dargestellten Strukturen gespeichert.In phase a) of the feature extraction, the features required for the deadlock detection are extracted from the UML system model and stored in the structures shown below.
Zunächst wird unter Berücksichtigung der statischen und dynamischen Struktursicht (Klassen- und Objektdiagramme) ermittelt, welche Komponenten des Systems bei der Analyse zu berücksichtigen sind. Da dies von der Art des UML- Systemmodells abhängt, muss das UML-Systemmodell in einer speziellen Form (UML-Dialekt) vorliegen. Im vorliegendem Beispiel wird von der Erzeugung der einzelnen Komponenten des Systems abstrahiert. Es wird davon ausgegangen, dass beim Start des Gesamtsystems alle aktiven Objekte erzeugt werden und über alle Eigenschaften verfügen, die im Klassendiagramm für die zugehörigen Klassen modelliert wurden. Die Links (Instanzen der Assoziationen zwischen den Klassen) zwischen den Objekten haben die Eigenschaften, die die zugehörigen Assoziationen im Klassendiagramm tragen. Ferner wird davon ausgegangen, dass bei der Instanziierung von Objekten, die ihnen durch Kompositionsbeziehungen zugeordneten Objekten ebenfalls instanziiert werden. Deshalb sind alle im Objektdiagramm dargestellten Objekte gerade die in der Detektion zu berücksichtigenden.First, taking into account the static and dynamic structure view (class and object diagrams), it is determined which components of the system are to be considered in the analysis. Since this depends on the type of UML system model, the UML system model must be available in a special form (UML dialect). In the present example, the generation of the individual components of the system is abstracted. It is assumed that when the entire system is started, all active objects are created and have all the properties that were modeled in the class diagram for the associated classes. The links (instances of the associations between the classes) between the objects have the properties that the associated associations have in the class diagram. It is also assumed that when objects are instantiated, the objects assigned to them by composition relationships are also instantiated. Therefore, all objects shown in the object diagram are precisely those to be taken into account in the detection.
Je nach Einsatzgebiet der Unified Modeling Language bzw. dem entsprechenden UML-Profil kann dieser Teil der Merkmalsextraktion unterschiedlich ausfallen. Dies ist jedoch nicht Gegenstand der vorliegenden Erfindung.Depending on the application of the Unified Modeling Language or the corresponding UML profile, this part of the feature extraction can be different. However, this is not the subject of the present invention.
Nachdem aus dem Objektdiagramm alle aktiven Objekte extrahiert und in einer Objekt-Liste gespeichert wurden, wird diese Liste genau einmal durchlaufen, und zu jedem Objekt die dazugehörige Klasse in einer Klassen-Liste gespeichert. Die Länge der Klassen-Liste wird als Anzahl_Klassen gespeichert. Dann wird zu jeder Klasse in der Klassen-Liste, d. h. den aktiven Klassen, das dazugehörige Zustandsdiagramm analysiert und der dort spezifizierte Zustandsautomat in der Zustandsautomaten-Liste gespeichert.After all active objects have been extracted from the object diagram and saved in an object list, this list is run through exactly once, and the associated class for each object is saved in a class list. The length of the class list is saved as number_classes. Then for each class in the class list, i.e. H. the active classes, the associated state diagram is analyzed and the state machine specified there is saved in the state machine list.
Anschließend werden alle Objekte an Hand der zugeordneten Klassen in der Klassen-Liste hinsichtlich ihrer produzierten Aktionen untersucht. Dazu muss jeweils der richtige Zustandsautomat aus der Zustandsautomaten-Liste selektiert werden und alle Transitionen der Reihe nach untersucht werden. Jede Transition kann 0 bis n=beliebig viele Aktionen auslösen. Von den verschiedenen Typen der Aktionen, die in der UML-Sprache definiert sind, werden vom Verfahren nur die Aufruf-Aktionen (Call Actions) berücksichtigt. Ferner kann das Verfahren optional auch Signal-Aktionen (Send Aktions) berücksichtigen. Da in der Regel je nach Art der Modellierung nur einer der beiden Typen von Aktionen verwendet werden, wird das Verfahren nachfolgend nur hinsichtlich der Aufruf- Aktionen beschrieben. Die gefundenen Aufruf-Aktionen werden in einer Aktionen- Tabelle gespeichert, die wie folgt aufgebaut ist:Then all objects are examined with the help of the assigned classes in the class list with regard to their produced actions. To do this, the correct state machine must be selected from the state machine list and all transitions examined in turn. Each transition can trigger 0 to n = any number of actions. Of the various types of actions that are defined in the UML language, only the call actions are taken into account by the method. The method can also optionally take signal actions (send actions) into account. Since only one of the two types of actions is generally used, depending on the type of modeling, the procedure is described below only with regard to the call actions. The call actions found are saved in an action table, which is structured as follows:
Objekt Aktion Objekt 1 { [Zustand, Zielobjekt, Zielereignis] , ... }Object Action Object 1 {[state, target object, target event], ...}
Dabei ist in der Aktionen-Tabelle unter dem Eintrag Objekt der Objektnahme zu finden und unter dem Eintrag Aktion eine Menge von 0 bis m Aktionen, die jeweils aus den Komponenten Zustand, Zielobjekt und Zielereignis bestehen. Die Anzahl m ist die Anzahl der Aktionen, die durch eine Transition ausgelöst werden können. Der Zustand ist der Zustand des Zustandsautomaten, in dem das Objekt die Aktion erzeugen kann, wenn die dazugehörige Transition schaltet. Das Zielobjekt ist das Objekt, an dass die Aufruf-Aktion adressiert ist. Das Zielereignis ist das Ereignis (Event) des Zielobjekts, das dabei erzeugt und in dessen Eingabe Warteschlange (Input-Queue) gelegt wird.You can find in the Actions table under the Object of object entry entry and under the Action entry a set of 0 to m actions, each consisting of the components state, target object and target event. The number m is the number of actions that can be triggered by a transition. The state is the state of the state machine in which the object can generate the action if the associated transition switches. The target object is the object to which the call action is addressed. The target event is the event of the target object, which is generated and placed in the input queue (input queue).
Danach wird eine Wartemengen-Tabelle erzeugt. Diese ergibt sich, indem für jedes Objekt aus der Objekt-Liste über die dazugehörige Klasse aus der Klassen-Liste der zugehörige Zustandsautomat aus der Zustandsautomaten-Liste selektiert und festgestellt wird, auf welche Ereignisse (Events) das Objekt in welchem Zustand wartet und welches Objekt das jeweilige Ereignis erzeugen kann. Die Information, welches Objekt das jeweilige Ereignis erzeugen kann, wird aus der Aktionen-Tabelle entnommen.A waiting quantity table is then created. This is achieved by selecting the associated state machine from the state machine list for each object from the object list via the associated class from the class list and determining which events (events) the object is waiting for in which state and which object can generate the respective event. The information about which object can generate the respective event is taken from the actions table.
Die Wartemengen-Tabelle hat die folgende Form:The waiting quantity table has the following form:
Objekt WartemengeObject waiting quantity
Objekt 1 [Zustand 1, (Objekt 2. Zustand 1, Objekt 2. ZustandObject 1 [state 1, (object 2nd state 1, object 2nd state
2)], [Zustand 2, (Objekt 3. Zustand 2)] ...2)], [State 2, (Object 3. State 2)] ...
Dabei ist unter dem Eintrag Objekt analog zu einer Aktionen- Tabelle der Objektname verzeichnet. Die Wartemenge ist so strukturiert, dass zu jedem Zustand des Zustandsautomaten des Objekts eine Menge von Objekt-Zustandskombinationen gespeichert werden kann. Eine Objekt-Zustandskombination hat die Form „Objekt. Zustand", wobei hierbei "Objekt" das Objekt bezeichnet, auf das gewartet wird und "Zustand" den Zustand, auf den gewartet wird.The object name is listed under the entry object analogous to an action table. The waiting amount is like this structured that a set of object-state combinations can be saved for each state of the state machine of the object. An object-state combination has the form “object. State ", in which case" object "denotes the object to be waited for and" state "the state to be waited for.
In der oben genannten Tabelle wartet zum Beispiel das Objekt 1 in Zustand 1 auf das Objekt 2 in Zustand 1 und das Objekt 2 in Zustand 2. Wie jede andere Menge in der Mathematik ist auch die Wartemenge frei von Duplikaten.In the above table, for example, object 1 in state 1 waits for object 2 in state 1 and object 2 in state 2. Like any other quantity in mathematics, the waiting quantity is free of duplicates.
Nach Erstellung der Wartemengen-Tabelle werden alle Ergebnisse der Merkmalsextraktion in einer Struktur „Modell- Merkmale" zusammengefasst, die einen effizienten Zugriff auf alle Merkmale zuläßt und diese in den anderen Phasen b) , c) und d) zur Verfügung stellt.After the waiting quantity table has been created, all the results of the characteristic extraction are summarized in a "model characteristics" structure, which allows efficient access to all characteristics and makes them available in the other phases b), c) and d).
Für das beispielhafte Messsystemmodell sind die Ergebnisse der Merkmalsextraktion die folgenden:For the exemplary measurement system model, the results of the feature extraction are the following:
Anzahl-Klassen = 5Number classes = 5
Objekt-Liste = [Ben->Objekt, Con->Objekt, Snl->Objekt, Sn2- >Objekt, U->Objekt]Object list = [Ben-> object, Con-> object, Snl-> object, Sn2-> object, U-> object]
Klassen-Liste = [Benutzer->Klasse, Controller->Klasse, Sensorl->Klasse, Sensor->Klasse, Uhr->Klasse]Class List = [User-> Class, Controller-> Class, Sensorl-> Class, Sensor-> Class, Clock-> Class]
Aktionen-Tabelle:Actions table:
Objekt Aktion Ben ([Start, Con, Start])Object action Ben ([Start, Con, Start])
Con ([Parametrierung, U, Start], [Messungl, Sn2, Anfrage_Messwert] , [Messung2, Ben, Gebe_Messwert] , [Messung2, Snl, Anfrage_Messwert] , [Messung2, Uhr, Stop], [Messung2, Snl, Stop], [Messung2, Sn2, Stop]) SnlCon ([parameterization, U, start], [measurement1, Sn2, request_measured value], [measurement2, Ben, give_measured value], [measurement2, Snl, request_measured value], [measurement2, clock, stop], [measurement2, snl, stop], [Measurement2, Sn2, Stop]) snl
([Messen, U, Anfrage _Zeitstempel_Sensorl] , [Hole_Zeit, Con,([Measure, U, request _Timestamp_Sensorl], [Get_Time, Con,
Gebe_Messwert-Sensorl] )Gebe_Messwert-Sensorl])
Sn2 ([Messen, U, Anfrage-Zeitstempel_Sensor2] , [Hole_Zeit,Sn2 ([Measure, U, request timestamp_Sensor2], [Get_Time,
Con, Gebe_Messwert_Sensor2] )Con, Gebe_Messwert_Sensor2])
U ([Laufend, Snl, Gebe_Zeitstempel] , [Anfrage_Eins, Sn2,U ([Ongoing, Snl, Give_time stamp], [Inquiry_One, Sn2,
Gebe_ZeitStempel] )Give_time stamp])
Wartemengen-Tabelle :Waiting quantity table:
Objekt Wartemenge Ben [Beobachte, (Con.Messung2) ] , [Beobachte2, (Con.Messung2) ]Object Waiting quantity Ben [Observe, (Con.Messung2)], [Observer2, (Con.Messung2)]
Con [Parametrierung, (Ben. Starte) ] , [Messungl, (Snl.Hole_Zeit) ] , [Messung2, (Ben.Beobachte2) ] Snl [Messen, (Con.Messung2) ] , [Hole_Zeit, (U. Laufend)] Sn2 [Messen, (Con.Messungl) ] , [Hole_Zeit, (U.Anfrage_Eins) ] U [Parametrierung, (Con. Parametrierung) ] , [Laufend, (Sn2.Messen) ] , [Anfrage_Eins, (Sn2.Messen, Con .Messung2) ] ,Con [parameterization, (start)], [measurement, (snl.holder_time)], [measurement2, (observation.2)] snl [measurement, (measurement.2)], [hole_time, (currently)] Sn2 [Measure, (Con.Messungl)], [Get_Time, (U.Request_One)] U [Parameterization, (Con.Measurement)], [Ongoing, (Sn2.Measure)], [Inquiry_One, (Sn2.Measure, Con .Measurement2)],
Nach der Erstellung der Wartemengen-Tabelle werden diese Merkmale in der Struktur „Modell-Merkmale" zusammengefasst und den weiteren Phasen b) , c) und d) des Verfahrens zur Verfügung gestellt. Hierdurch wird ein effizienter Zugriff auf die verschiedenen Merkmale ermöglicht.After the waiting quantity table has been created, these characteristics are summarized in the "model characteristics" structure and made available to the other phases b), c) and d) of the method. This enables efficient access to the various characteristics.
In der Phase b) „Potentielle Deadlock Detektion" wird aus der Wartemengen-Tabelle ein sogenannter Zustands-Wartegraph (State-Wait-Graph) erzeugt. Dies ist ein Graph, dessen Knoten Objekt-Zustandskombinationen bezeichnen und dessen Kanten „Warte-Auf"-Beziehungen (Wait-For-Relations) bezeichnen. Aus diesem Graph lassen sich Aussagen wie Objekt 1 wartet inIn phase b) "potential deadlock detection", a so-called state-wait graph is generated from the waiting quantity table. This is a graph, the nodes of which denote object-state combinations and the edges of which indicate "wait-on" - Denote relationships (wait-for-relations). From this graph, statements such as object 1 is waiting in
Zustand 1 auf Objekt 2 in Zustand 1, etc. treffen. Analog zu den Wartemengen sind die Kantenmengen von Graphen duplikatsfrei. Dies vereinfacht die Anwendung von Algorithmen auf Graphen und verringert deren Komplexität.Hit state 1 on object 2 in state 1, etc. The edge quantities of graphs are analogous to the waiting quantities duplicate free. This simplifies the application of algorithms to graphs and reduces their complexity.
Eine potentielle Verklemmungs-Situation (Deadlock) im Sinne des betrachteten Verfahrens ist eine zyklische „Warte-Auf"- Beziehung mit einigen weiteren Eigenschaften.A potential deadlock in the sense of the method under consideration is a cyclic "wait-for" relationship with some other properties.
Die Phase b) der Analyse zur Erkennung potentieller Verklemmungs-Situationen arbeitet in zwei Stufen. In der ersten Stufe wird eine Zyklenerkennung auf dem Zustands- Warte-Graph durchgeführt. Das Ergebnis ist eine Menge potentieller Verklemmungs-Situationen. In der zweiten Stufe werden diejenigen potentiellen Verklemmungs-Situationen aus der Menge der potentiellen Deadlocks ausgesondert, welche die folgenden Eigenschaften aufweisen:Phase b) of the analysis to identify potential deadlock situations works in two stages. In the first stage, a cycle detection is carried out on the status wait graph. The result is a lot of potential deadlock situations. In the second stage, those potential deadlock situations that have the following properties are separated from the set of potential deadlocks:
a) ein Objekt ist mit mehreren Zuständen am Deadlock beteiligt; b) es existiert eine Kante zu einem Objekt, das am Deadlock nicht beteiligt ist; c) nur ein Objekt ist am Deadlock beteiligt.a) an object is involved in the deadlock with several states; b) there is an edge to an object that is not involved in the deadlock; c) only one object is involved in the deadlock.
Alle nicht ausgesonderten Verklemmungs-Situationen bilden die endgültige Menge der potentiellen Deadlocks.All deadlock situations that are not sorted out form the final set of potential deadlocks.
Das Verfahren zur Zyklenerkennung basiert auf dem allgemein bekannten Tiefensucheverfahren (Depth-First-Search) .The method for cycle detection is based on the well-known depth-first search method.
Die Figur 9 lässt einen beispielhaften Zustands-Wartegraphen für das Messsystemmodell erkennen.FIG. 9 shows an exemplary state waiting graph for the measuring system model.
Nach der Zyklenerkennung ist die Menge der potentiellen Deadlocks wie folgt:After the cycle detection, the amount of potential deadlocks is as follows:
( (Ben.Beobachte2, Con.Messung2) , (Con.Messungl, Snl.Hole Zeit, U. Laufend, Sn2.Messen)) Nach Aussonderung ist die Menge potentieller Deadlocks reduziert wie folgt:((Ben.Beobachte2, Con.Messung2), (Con.Messungl, Snl.Hole Zeit, U. Ongoing, Sn2.Messen)) After discarding, the amount of potential deadlocks is reduced as follows:
( (Con.Messungl, Snl .Hole_Zeit, U. Laufend, Sn2. Messen))((Con.Messungl, Snl .Hole_Zeit, U. Ongoing, Sn2. Messen))
Die potentielle Verklemmungs-Situation (Ben.Beobachte2, Con.Messung2) wurde ausgesondert, weil eine Kante im Zustands-Wartegraphen von Con.Messung2 nach Sn2.Hole_Zeit existiert und deshalb für ihn die oben genannte Bedingung b) erfüllt ist, d. h. dass eine Kante zu einem Objekt existiert, das am Deadlock nicht beteiligt ist.The potential deadlock situation (Ben.Beobachte2, Con.Messung2) was eliminated because there is an edge in the state wait graph from Con.Messung2 after Sn2.Hole_Zeit and therefore the above-mentioned condition b) is fulfilled for him. H. that there is an edge to an object that is not involved in the deadlock.
Die finale Menge potentieller Deadlocks wird an die nächste Phase c) der Analyse der Erreichbarkeit der potentiellen Verklemmungs-Ereignisse übergeben.The final set of potential deadlocks is passed to the next phase c) of analyzing the accessibility of the potential deadlock events.
Die „Deadlock-Erreichbarkeitsanalyse" dient dem Nachweis, dass die gefundenen potentiellen Deadlocks zur Laufzeit des Systems erreichbar sind. Auch hier gibt es verschiedenen Standardverfahren, die zur Erreichbarkeitsanalyse eingesetzt werden können. Besonders wichtig für das vorliegenden Verfahren ist, dass in der Phase der Deadlock- Erreichbarkeitsanalyse nicht die Laufzeitvorteile, die durch die äußert günstige Zeitkomplexität resultieren, verschenkt werden. Die erforderliche Zeit verhält sich voraussichtlich linear zu der Anzahl der Kanten und Knoten des Zustands- Wartegraphen .The "deadlock reachability analysis" serves to prove that the potential deadlocks found can be reached at runtime of the system. Again, there are various standard methods that can be used for the reachability analysis. It is particularly important for the present method that the deadlock phase - Reachability analysis does not give away the runtime advantages that result from the extremely favorable time complexity.The expected time is expected to be linear to the number of edges and nodes of the state waiting graph.
Aus diesem Grunde werden bei der Erreichbarkeitsanalyse in der Phase c) Heuristiken eingesetzt. Es werden neben den Ereignissen (Events) und Aktionen (Actions) an den Transitionen (Transitions) auch Wächter-Bedingungen (Guard- Conditions) der Zustandsautomaten berücksichtigt.For this reason, heuristics are used in the reachability analysis in phase c). In addition to the events and actions at the transitions, the conditions of the state machine are also taken into account.
Der erste Schritt der Analyse der Erreichbarkeit der potentiellen Verklemmungs-Ereignisse ist die Berechnung der lokalen Pfade der beteiligten Objekte. Dazu werden sogenannte Pfad-Listen konstruiert, die aus den Zustandsautomaten des Modells abgeleitet werden können. Anschließend wird die Ausführung des Modells simuliert, indem ausgehend vom initialen Zustand des Modells geprüft wird, welche Transitionen jeweils aktiviert sind, d. h. welcheThe first step in the analysis of the reachability of the potential deadlock events is the calculation of the local paths of the objects involved. So-called Path lists constructed that can be derived from the state machines of the model. Then the execution of the model is simulated by checking which transitions are activated, ie which, based on the initial state of the model
Transitionen schalten können. Transitionen können genau dann schalten, wenn die Wächter-Bedingung wahr ist und das Ereignis in der Eingabewarteschlange liegt. Dann wird nach einer geeigneten Heuristik jeweils diejenige Transition ausgewählt, die das Modell näher an die potentielle Verklemmungs-Situation heranbringt .Can switch transitions. Transitions can switch if and only if the guard condition is true and the event is in the input queue. Then the transition that brings the model closer to the potential deadlock situation is selected according to a suitable heuristic.
Die Simulation bricht ab, wenn die potentielle Verklemmungs- Situation erreicht wurde oder alle Pfade eine festgelegte Anzahl n mal durchlaufen wurden und kein potentieller Zustand der Verklemmung erreicht werden konnte. Im letzteren Fall kann keine Aussage gemacht werden, ob der potentielle Zustand der Verklemmung noch erreicht werden kann.The simulation stops when the potential deadlock situation has been reached or all paths have been traversed a specified number of times and no potential deadlock condition could be reached. In the latter case, no statement can be made as to whether the potential state of the deadlock can still be reached.
Bei der Erreichbarkeitsanalyse werden Pfadlisten und Spuren- Mengen (Traces set) generiert. Dabei haben Pfadlisten die Form:In the reachability analysis, path lists and trace sets are generated. Path lists have the form:
Pfadliste = {[(ZI, Z2) , ..., (Zi, Zj ) ] , ...},Path list = {[(ZI, Z2), ..., (Zi, Zj)], ...},
wobei (ZI, Z2) ein geordnetes Paar ist, bei dem ZI den Quellzustand einer Transition, Z2 den Zielzustand der Transition bezeichnet und Zj in der Menge der potentiellen Verklemmungs-Situationen liegt.where (ZI, Z2) is an ordered pair, where ZI denotes the source state of a transition, Z2 the target state of the transition and Zj lies in the set of potential deadlock situations.
Ein Modellzustand für ein Modell mit einer Anzahl n von Objekten ist gegeben durchA model state for a model with a number n of objects is given by
< 0_1.Z, ..., 0_n.Z, 0_1.A_1, ..., 0_n.A_m, ES_1, ... ES_n >,<0_1.Z, ..., 0_n.Z, 0_1.A_1, ..., 0_n.A_m, ES_1, ... ES_n>,
wobei 0_i, 1 < i <n, m >= n das jeweilige Objekt bezeichnet und Z den jeweils aktuellen Zustand des Objektes. A_j , 1 <= j <= m ist der aktuelle Wert des jeweiligen Attributs des betreffenden Objektes undwhere 0_i, 1 <i <n, m> = n denotes the respective object and Z the current state of the object. A_j, 1 <= j <= m is the current value of the respective attribute of the relevant object and
ES_i ist die Eingabewarteschlange von 0_i .ES_i is the input queue of 0_i.
D. h. zu jedem Modellzustand gehört der Zustand (alle Attributwerte) sowie die Eingabewarteschlange aller Objekte.I.e. the state (all attribute values) and the input queue of all objects belong to each model state.
Die Spuren-Menge ist die Menge aller FolgenThe trace set is the set of all episodes
{ [M_a, (O.Z_a, O.Z_b), M_z]},{[M_a, (O.Z_a, O.Z_b), M_z]},
wobei M_a der initiale Zustand des Modells ist und M_z der letzte Zustand vor Abbruch der Simulation und (O.Z_a, O.Z_b) eine Transition des Objektes O von Z_a nach Z_b.where M_a is the initial state of the model and M_z the last state before termination of the simulation and (O.Z_a, O.Z_b) a transition of the object O from Z_a to Z_b.
Die Ausführung von Aktionen, das Auftreten von Ereignissen etc. wird nicht mit aufgezeichnet, sondern ist an der Änderung des Modellzustandes erkennbar.The execution of actions, the occurrence of events etc. is not recorded, but can be recognized by the change in the model state.
Die Ergebnisse der Erreichbarkeitsanalyse am Beispiel des Messsystemmodells sind wie folgt:The results of the reachability analysis using the example of the measuring system model are as follows:
Eingabe:Input:
Menge der potentiellen Verklemmungs-Situationen nach Aussonderung = { {Con.Messungl, Snl .Hole_Zeit, U. Laufend, Sn2.Messen} }Set of potential deadlock situations after separation = {{Con.Messungl, Snl .Hole_Zeit, U. Laufend, Sn2.Messen}}
Ausgabe:Output:
Pfadliste_Ben = { (Starte, Beobachte) } Pfadliste_Con = { (Parametrierung, Messungl) } Pfadliste_Snl = { (Messen, Hole_Zeit) } Pfadliste_Sn2 = { } Pfadliste U = { (Parametrierung, Laufend) } Spuren_Menge={<Ben. Starte, Con. Parametrierung, Snl. Messen, Sn2. Messen, U. Parametrierung, Con.A.Messwertl=99.9, Con.A.Messwert2=99.9, Snl .A.Aktuell=999, U.A. Zeitstempel=999, Ben.ES=[], Con.ES=[], Snl.ES=[], Sn2.ES=[], U.ES=[]>, (Ben. Starte, Ben. Beobachte) , <Ben. Beobachte,Pathlist_Ben = {(start, observe)} Pathlist_Con = {(parameterization, measurement)} Pathlist_Snl = {(measure, get_time)} Pathlist_Sn2 = {} Pathlist U = {(parameterization, ongoing)} Spuren_Menge = {<Ben. Start, con. Parameterization, Snl. Measure, Sn2. Measure, U. parameterization, Con.A.Messwertl = 99.9, Con.A.Messwert2 = 99.9, Snl .A.Aktuell = 999, UA timestamp = 999, Ben.ES = [], Con.ES = [], Snl .ES = [], Sn2.ES = [], U.ES = []>, (user start, user watch), <user. watch
Con. Parametrierung, Snl.Messen, Sn2.Messen, U. Parametrierung, Con.A.Messwertl=99.9, Con.A.Messwert2=99.9, Snl.A.Aktuell=999, U.A. Zeitstempel=999, Ben.ES=[], Con.ES= [Start] , Snl.ES=[], Sn2.ES=[], U.ES=[]>,Con. Parameterization, Snl.Messen, Sn2.Messen, U. Parametrierung, Con.A.Messwertl = 99.9, Con.A.Messwert2 = 99.9, Snl.A.Actuell = 999, U.A. Timestamp = 999, Ben.ES = [], Con.ES = [Start], Snl.ES = [], Sn2.ES = [], U.ES = []>,
(Con. Parametrierung, Con.Messungl) , <Ben. Beobachte, Con. essungl, Snl.Messen, Sn2.Messen, U. Parametrierung, Con.A.Messwert1=99.9, Con.A.Messwert2=99.9, Snl.A.Aktuell=999, U.A. Zeitstempel=999, Ben.ES=[], Con.ES=[], Snl.ES=[Anfrage_Messwert] , Sn2.ES=[], U.ES= [Start] >,(Con. Parameterization, Con.Messungl), <Ben. Watch, Con. essungl, Snl.Messen, Sn2.Messen, U. parameterization, Con.A.Messwert1 = 99.9, Con.A.Messwert2 = 99.9, Snl.A.Actuell = 999, U.A. Timestamp = 999, Ben.ES = [], Con.ES = [], Snl.ES = [request_measured value], Sn2.ES = [], U.ES = [Start]>,
(U. Parametrierung, U. Laufend), <Ben. Beobachte, Con.Messungl, Snl.Messen, Sn2.Messen, U. Laufend, Con.A.Messwertl=99.9, Con.A.Messwert2=99.9, Snl .A.Aktuell=999, U.A. Zeitstempel=999, Ben.ES=[], Con.ES=[], Snl .ES= [Anfrage_Messwert] , Sn2.ES=[], U.ES=[]>, (Snl.Messen, Snl .Hole_Zeit) , <Ben. Beobachte, Con.Messungl, Snl .Hole_Zeit, Sn2.Messen, U. Laufend, Con.A.Messwertl=99.9, Con.A.Messwert2=99.9,(U. parameterization, U. ongoing), <Ben. Observe, Con.Messungl, Snl.Messen, Sn2.Messen, U. Ongoing, Con.A.Messwertl = 99.9, Con.A.Messwert2 = 99.9, Snl .A.Actuell = 999, U.A. Timestamp = 999, Ben.ES = [], Con.ES = [], Snl .ES = [request_measured value], Sn2.ES = [], U.ES = []>, (Snl.Messen, Snl .Hole_Zeit) , <Ben. Observe, Con.Messungl, Snl .Hole_Zeit, Sn2.Messen, U. Ongoing, Con.A.Messwertl = 99.9, Con.A.Messwert2 = 99.9,
Snl.A.Aktuell=999, U.A. Zeitstempel=999, Ben.ES=[], Con.ES=[], Snl.ES=[], Sn2.ES=[], U.ES= [Anfrage_Zeitstempel_Sensorl] >}Snl.A.Actuell = 999, U.A. Timestamp = 999, Ben.ES = [], Con.ES = [], Snl.ES = [], Sn2.ES = [], U.ES = [request_timestamp_Sensorl]>}
In der Phase d) werden die Analyseergebnisse dann dargestellt. Die Visualisierung des Verfahrensergebnisses richtet sich an den Systementwickler mit fundierten UML- Kenntnissen und Erfahrungen in der Systemmodellierung. Wesentliches Darstellungsmittel ist dabei das bekannteThe results of the analysis are then presented in phase d). The visualization of the process result is aimed at the system developer with in-depth knowledge of UML and experience in system modeling. The main means of representation is the known one
Sequenzdiagramm, in dem sehr gut dargestellt werden kann, nach welcher Sequenz von Nachrichten die Deadlocksituation eintritt.Sequence diagram in which it can be very well represented after which sequence of messages the deadlock situation occurs.
Die Figur 10 lässt das Sequenzdiagramm für das Ergebnis derFIG. 10 leaves the sequence diagram for the result of the
Erreichbarkeitsanalyse anhand des untersuchten beispielhaften Messsystemmodells erkennen. Im Beispiel wurde für die Darstellung der an der Verklemmungs-Situation beteiligten Nachrichten das graphischeRecognize reachability analysis based on the examined measuring system model. In the example, the graphic was used to display the messages involved in the deadlock situation
Symbol <->- verwendet, welches für den Stereotyp «deadlock» steht.Symbol <-> - used, which stands for the stereotype «deadlock».
Ein Rahmen mit abgerundeten Ecken dient, dazu, die am Deadlock beteiligten Nachrichten optisch zusammenzufassen. Zusätzlich werden in einem Notizkasten die Zustände der am Deadlock beteiligten Objekte angegeben. A frame with rounded corners serves to visually summarize the messages involved in the deadlock. In addition, the states of the objects involved in the deadlock are specified in a note box.

Claims

Patentansprüche claims
1. Verfahren zur Bestimmung von Verklemmungen (Deadlocks) in nebenläufigen Prozessen, bei denen mindestens ein Objekt in einem Zustand auf ein anderes Objekt in einem bestimmten Zustand wartet, für ein objektorientiert beschriebenes Systemmodell eines reaktiven Systems mit den Schritten:1. A method for determining deadlocks in concurrent processes, in which at least one object in one state is waiting for another object in a specific state, for an object-oriented described system model of a reactive system with the steps:
a) Extrahieren aller aktiven Objekte des objektorientierten Systemmodells;a) extracting all active objects of the object-oriented system model;
b) Feststellen mindestens der von den aktiven Objekten konsumierten und/oder produzierten Ereignissen, der Transitionen zwischen den Objekten und von Wächterbedingungen von Zustandsautomaten des Systemmodells zur Beschreibung des Zustandsverhaltens der Objekte;b) determining at least the events consumed and / or produced by the active objects, the transitions between the objects and guard conditions of state machines of the system model for describing the state behavior of the objects;
c) Erzeugen der Zustands-Warte-Relationen zwischen den aktiven Objekten aus den Ereignissen als Liste von Objekten, die in einem definierten Zustand auf ein anderes Objekt in einem definierten Zustand warten;c) generating the state-waiting relationships between the active objects from the events as a list of objects which are waiting in a defined state for another object in a defined state;
d) Ermitteln möglicher Verklemmungs-Situationen als Zyklen aufeinander wartender Instanzen von zwei oder mehr unterschiedlichen Objekten, wobei in dem Zyklus kein Objekt mit mehr als einem Zustand involviert ist und keines der Objekte des Zyklus auf ein Objekt außerhalb des Zyklus wartet, und für jede Verklemmungs-Situation:d) determining possible deadlock situations as cycles of waiting instances of two or more different objects, in which no object with more than one state is involved in the cycle and none of the objects in the cycle is waiting for an object outside the cycle, and for each deadlock -Situation:
e) Überprüfen aller möglichen Pfade, die zu einer ermittelten Verklemmungs-Situation führen und aus den Zustandsautomaten des Systemmodells abgeleitet werden, durch simulierte Ausführung des Systemmodells untere) Checking all possible paths that lead to a determined deadlock situation and are derived from the state machine of the system model by simulating the execution of the system model below
Berücksichtigung der Ereignisse und aktivierten Transitionen zur Analyse der Erreichbarkeit der ermittelten möglichen Verklemmungs-Situation .Consideration of events and activated transitions to analyze the accessibility of the determined possible deadlock situation.
2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass im Schritt a) des Extrahierens aller aktiven Objekte die aktiven Objekten aus einer statischen und dynamischen Struktursicht des Systemmodells extrahiert und in einer Objekt-Liste gespeichert werden.2. The method according to claim 1, characterized in that in step a) extracting all active objects, the active objects are extracted from a static and dynamic structure view of the system model and are stored in an object list.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass für jedes aktive Objekt eine zugeordnete Klasse in einer Klassen-Liste abgespeichert wird und für jede Klasse in der Klassen-Liste das zugehörige Zustandsdiagramm zur Spezifikation eines Zustandsautomaten ausgewertet wird und die spezifizierten Zustandsautomaten in einer Zustandsautomaten-Liste abgespeichert werden.3. The method according to claim 1 or 2, characterized in that for each active object an assigned class is stored in a class list and for each class in the class list the associated state diagram for specifying a state machine is evaluated and the specified state machines in a state machine list can be saved.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Ermittlung der möglichen Verklemmungs-Situationen mit einem an sich bekannten Tiefensucheverfahren (Depth-First-Search) erfolgt.4. The method according to any one of the preceding claims, characterized in that the determination of the possible deadlock situations is carried out using a depth-first search method known per se (depth-first search).
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Überprüfung der Erreichbarkeit der ermittelten möglichen Verklemmungs- Situationen heuristisch erfolgt, in dem ausgehend von einem initialen Zustand des Systemmodells die jeweils aktivierten Transitionen ermittelt werden und diejenige aktivierte Transition ausgewählt wird, welche das Systemmodell näher an die Verklemmungs-Situation heran bringt.5. The method according to any one of the preceding claims, characterized in that the check of the accessibility of the determined possible deadlock situations is carried out heuristically by determining the respectively activated transitions based on an initial state of the system model and selecting the activated transition that the System model brings closer to the deadlock situation.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass aktivierte Transitionen vorliegen, wenn die Wächterbedingung für das zugeordnete Objekt wahr ist und das Ereignis des Objektes in einer Eingabewarteschlange liegt. 6. The method according to claim 5, characterized in that activated transitions are present if the guard condition for the assigned object is true and the event of the object is in an input queue.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Schritt e) des Uberprüfens aller möglichen Pfade für jede Verklemmungs-Situation solange iterativ durchgeführt wird, bis entweder ein Verklemmungs- Zustand erreicht ist oder alle Pfade eine festgelegte Anzahl (n) durchlaufen wurden.7. The method according to any one of the preceding claims, characterized in that step e) of checking all possible paths for each deadlock situation is carried out iteratively until either a deadlock state is reached or all paths run through a predetermined number (n) were.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Systemmodell mit der Unified-Modeling-Language beschrieben wird.8. The method according to any one of the preceding claims, characterized in that the system model is described with the unified modeling language.
9. Computerprogramme mit Programmcodemitteln zur Durchführung des Verfahren nach einem der vorhergehenden Ansprüche, wenn das Computerprogramm auf einem Rechner ausgeführt wird. 9. Computer programs with program code means for performing the method according to one of the preceding claims, when the computer program is executed on a computer.
EP05742661A 2004-05-04 2005-05-02 Method for determining deadlocks in secondary processes Withdrawn EP1745375A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004021975A DE102004021975A1 (en) 2004-05-04 2004-05-04 Method for determining deadlocks in concurrent processes
PCT/EP2005/051986 WO2005109196A1 (en) 2004-05-04 2005-05-02 Method for determining deadlocks in secondary processes

Publications (1)

Publication Number Publication Date
EP1745375A1 true EP1745375A1 (en) 2007-01-24

Family

ID=34967422

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05742661A Withdrawn EP1745375A1 (en) 2004-05-04 2005-05-02 Method for determining deadlocks in secondary processes

Country Status (5)

Country Link
US (1) US20080092147A1 (en)
EP (1) EP1745375A1 (en)
JP (1) JP4637175B2 (en)
DE (1) DE102004021975A1 (en)
WO (1) WO2005109196A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101338A1 (en) * 2005-10-31 2007-05-03 Microsoft Corporation Detection, diagnosis and resolution of deadlocks and hangs
US7958512B2 (en) * 2005-10-31 2011-06-07 Microsoft Corporation Instrumentation to find the thread or process responsible for an application failure
JP2008282165A (en) * 2007-05-09 2008-11-20 Toshiba Mitsubishi-Electric Industrial System Corp Batch control apparatus and batch control method
US10283978B2 (en) * 2016-06-27 2019-05-07 Lg Chem, Ltd. Diagnostic system for a battery system
US10108767B1 (en) * 2016-09-30 2018-10-23 Cadence Design Systems, Inc. Methods, systems, and computer program product for implementing deadlock detection with formal verification techniques in an electronic design

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2027934C (en) * 1989-12-22 1994-06-21 Cherie C. Barnes Accelerated deadlock detection in congested data transactions
US5734837A (en) * 1994-01-14 1998-03-31 Action Technologies, Inc. Method and apparatus for building business process applications in terms of its workflows
US5832484A (en) * 1996-07-02 1998-11-03 Sybase, Inc. Database system with methods for parallel lock management
CN1266512A (en) * 1997-05-08 2000-09-13 艾瑞迪公司 Hardware acceleration for an object-oriented programming language
EP0938045A1 (en) * 1998-02-19 1999-08-25 IMEC vzw Method and apparatus for efficient verification using a generalised partial order analysis
US20050237949A1 (en) * 2000-12-21 2005-10-27 Addessi Vincent M Dynamic connection structure for file transfer
US7715819B2 (en) * 2001-08-03 2010-05-11 The Boeing Company Airborne security manager
EP1343079A1 (en) * 2002-03-07 2003-09-10 Infix Software-Systeme GmbH Method, software product and system for universal computer-based information processing
US7337290B2 (en) * 2003-04-03 2008-02-26 Oracle International Corporation Deadlock resolution through lock requeing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JIE WU ET AL: "A Petri-net-based collision and deadlock avoidance scheme for FMS", EMERGING TECHNOLOGIES AND FACTORY AUTOMATION, 1995. ETFA '95, PROCEEDI NGS., 1995 INRIA/IEEE SYMPOSIUM ON PARIS, FRANCE 10-13 OCT. 1995, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US LNKD- DOI:10.1109/ETFA.1995.496691, vol. 2, 10 October 1995 (1995-10-10), pages 511 - 520, XP010160421, ISBN: 978-0-7803-2535-7 *

Also Published As

Publication number Publication date
US20080092147A1 (en) 2008-04-17
JP2007536661A (en) 2007-12-13
JP4637175B2 (en) 2011-02-23
WO2005109196A1 (en) 2005-11-17
DE102004021975A1 (en) 2005-12-01

Similar Documents

Publication Publication Date Title
DE60017457T2 (en) PROCEDURE FOR ISOLATING AN ERROR IN ERROR MESSAGES
DE69317982T2 (en) Method and system for real-time data collection and display device
DE60115007T2 (en) IMPROVED PROGRAMMABLE CORE MODEL WITH INTEGRATED GRAPHIC TROUBLESHOOTING FUNCTIONALITY
DE60106799T2 (en) Probabilistic diagnosis, especially for embedded remote applications
DE69025543T2 (en) Power measurement in an extended finite state machine
DE69900810T2 (en) Method and device for testing event-controlled programs
DE69029983T2 (en) Performance improvement device for rule-based expert system
DE19860061B4 (en) System for combinatorial equivalence testing
US7386521B2 (en) Automatic test program generation using extended conditional constraint satisfaction
DE69734545T2 (en) Method and device for improving the portability of an object-oriented interface between different environments
US8739129B1 (en) Multi-domain unified debugger
DE69031538T2 (en) System and method for collecting software application events
DE102006050112A1 (en) Requirement description e.g. test specification, creating method for embedded system i.e. motor vehicle control device, involves automatically representing modules, and assigning to classes in particular unified modeling language classes
DE112017002645T5 (en) Executable logic for processing encrypted data in networks
DE102006019292A1 (en) Modeling programmable devices
EP3451202B1 (en) Method for generating a model of a technical system which can be run on a test device and a test device
DE112012004499T5 (en) Testing Transaction Applications
WO2013076250A1 (en) Simulation processes, simulation system and computer program product for controlling a production automation system with service-oriented architecture
WO2005109196A1 (en) Method for determining deadlocks in secondary processes
EP2648094B1 (en) Method and system for creating a source code for a computer program for executing and simulating a process
DE10038499A1 (en) Formal verifying method for development in data processor involves executing verification algorithm using one limit of signal envelope, and limiting state-space search by using verification algorithm
EP3306295A1 (en) Method and device for testing electronic controls, in particular for testing of automobile control systems
DE112018006331B4 (en) Test case generation device, test case generation method and test case generation program
US20090259454A1 (en) Automatic test program generation using extended conditional constraint satisfaction
DE10324594A1 (en) Method for providing improved simulation capabilities of a dynamic system outside of the original modeling environment

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060920

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20070906

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111201