EP2583144A1 - Verfahren zum überprüfen einer anlage anhand von zustandsübergängen und entsprechende anlage - Google Patents

Verfahren zum überprüfen einer anlage anhand von zustandsübergängen und entsprechende anlage

Info

Publication number
EP2583144A1
EP2583144A1 EP10752294.8A EP10752294A EP2583144A1 EP 2583144 A1 EP2583144 A1 EP 2583144A1 EP 10752294 A EP10752294 A EP 10752294A EP 2583144 A1 EP2583144 A1 EP 2583144A1
Authority
EP
European Patent Office
Prior art keywords
state transition
information
current state
transition information
state
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.)
Granted
Application number
EP10752294.8A
Other languages
English (en)
French (fr)
Other versions
EP2583144B1 (de
Inventor
Michael Dallmann
Jürgen ELGER
Christiane Gast
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 EP2583144A1 publication Critical patent/EP2583144A1/de
Application granted granted Critical
Publication of EP2583144B1 publication Critical patent/EP2583144B1/de
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/045—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using logic state machines, consisting only of a memory or a programmable logic device containing the logic for the controlled machine and in which the state of its outputs is dependent on the state of its inputs or part of its own output states, e.g. binary decision controllers, finite state controllers
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • G05B23/0248—Causal models, e.g. fault tree; digraphs; qualitative physics
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/34—Director, elements to supervisory
    • G05B2219/34465—Safety, control of correct operation, abnormal states

Definitions

  • the present invention relates to a method for checking a system, in particular the interaction of system components, which can take multiple states / can.
  • the present invention relates to a corresponding system, in particular the technical data acquisition and evaluation of the states of components of the system.
  • Communication takes place, for example, by telegrams (data records) which are exchanged between the systems. But it can also be done by signals that are placed on a bus and there for all (approved) participants are available.
  • the testing of the systems involved includes syntactic information related to a message, such as: Eg permissible values and value limits within a telegram.
  • the check can also refer to semantic information regarding a message, such. As plausibility checks or a check of dependencies within a telegram.
  • semantic information can be checked, which relate to several messages (expiration-related information), such. For example, permissible sequences of telegrams or signals, permissible status transitions, etc.
  • the manual evaluation and testing takes place, for example, by logging into a logbook.
  • a local recording of logbook entries takes place in the systems involved.
  • the evaluation can only be done from the point of view of the respective system. What has happened in the overall context, is not apparent from the respective logbook entries. Rather, the entries of several systems (by hand) must be compared, which is cumbersome, time-consuming and error-prone. This means that semantics exists in the subsystem, but the overall view is missing.
  • B. a logic analyzer introduced into the computer network, which logs all messages sent over the network.
  • the disadvantage here is that although certain basic information can be recorded (eg transmitter, receiver, timestamp, data content), but that
  • the object of the present invention is thus to be able to easily and reliably check a system which can assume a plurality of states.
  • this object is achieved by a method for checking a system that can assume a plurality of states by storing one state transition transition information in the system for all defined transitions of the system from a first of the plurality of states to a second, forming a current state transition information to a current state transition of the system and automatic checking of the current state transition information based on the state transition information stored in the system.
  • processing means for forming a current state transition information to a current state transition of the system and for automatically checking the current state transition information based on the state transition information stored in the memory means.
  • all permissible state transitions are locally stored on the system itself, so that it can be checked immediately at each actual state transition, whether this is permissible or not.
  • the interaction of system components of the system which can take multiple states, to be able to easily and reliably check.
  • the state transitions then affect the individual plant components.
  • the states of the components must be recorded and checked against the underlying specification.
  • each state transition information includes first information about the first state and second information about the second state.
  • first information about the first state and second information about the second state.
  • the checking of the current state transition information can take place in the plant itself. It can thus achieve an immediate on-site review.
  • the checking may take place by a system recorder connected to the system, which records the current state transition information.
  • a system recorder connected to the system, which records the current state transition information.
  • a plant documentation is stored in the plant, in which data is provided, which are displayed to a user when it is determined during the check that the current state transition is not defined and therefore inadmissible.
  • the system documentation and thus the display for the user can be very specific to the system in this way.
  • the data from the system documentation can be used for automatic checking. Thus, for the review So not only the transition data itself, but also other data are used.
  • the multiple states may relate to types of telegrams that are communicated in the system.
  • a state transition then concerns a specific sequence of telegrams. Especially the sequence of telegrams of a certain type can provide information about the condition of an entire system.
  • the telegrams may contain further data that is used for automatic checking. It is thus possible to carry out an even more detailed check than by the sequence of the telegram types alone.
  • state transition information is recorded, for example, on a system recorder, it is favorable if time information about the current time is contained in each current state transition information. Then, a review of the system can be performed later at desired times.
  • FIG. 1 shows a schematic diagram for the integration of a system recorder into a bus system
  • FIG. 4 shows permissible status transitions in a system
  • FIG. 5 shows invalid status transitions in a system of FIG. 4
  • FIG. 5 shows invalid status transitions in a system of FIG. 4
  • a system consists, for example, of a system 1, a system 2,... And a system n.
  • the individual systems are connected via a bus 3.
  • a central system recorder 4 is also connected.
  • the system has a system documentation 5.
  • the system recorder 4 can exchange topology and semantic information via the data connection 6 with the system documentation 5.
  • the system recorder 4 is logically connected to the participating systems 1 to n (here via the bus 3) and is able to log the exchanged information and semantically interpret this data. In particular, he is able to recognize incorrect sequence sequences.
  • system recorder 4 uses its own configuration information to interpret the communication data (system documentation is not present in the system).
  • system recorder 4 can resort to a consistent and up-to-date system documentation 5, which contains, inter alia, specified messages, sequence sequences and state transitions in a current, consistent form.
  • the specifications (eg state diagram) and models contained in the plant documentation 5 are used to create a model (eg code, see FIG.
  • the job partner is valid and is used to check the messages logged by system recorder 4. With this information, it is possible to log the time sequence of the information exchange in the overall system.
  • a message can be checked for syntactic and semantic correctness, and it can be checked whether the sequence of messages (eg telegrams) is permissible.
  • FIGS. 2 and 3 show an example from intralogistics.
  • a container with the identification number 1234 is to be driven to destination A (container transport).
  • the conveyor system has a master computer 7 and a conveyor control 8.
  • the normal case (target sequence) is shown in FIG.
  • the conveyor control 8 sets in a telegram 9 a destination request (DR, Destination tion request) to the master computer 7.
  • DR Destination tion request
  • a transport order to the conveyor control 8 (DS, Destination Set)
  • TR Transport Destination Rea- ched
  • each scenario receives a scenario number.
  • the scenario "regular container transport" has the scenario number 4711.
  • a sequence number (xxx) appended to the scenario number is incremented by one With this combination of scenario number and run number, a clear assignment of the container movement to the underlying scenario is possible.
  • the container 1234 is moved with the scenario "4711, regular container transport".
  • the current sequence number is (randomly) 005. If another container 5678 were moved in parallel or after, the scenario number would also be 4711 ("regular container transport", serial number 006).
  • a DR is followed by a DS telegram and then the completion telegram TR to confirm that the task has been carried out. Due to the capacity utilization of the system, however, a new destination request may be received after the transfer order has been sent before the destination has been reached. This also represents a correct telegram sequence. All permissible state transitions, in this case telegram sequences, are shown in the diagram 12 with arrows 13.
  • the check whether a combination, ie a state transition or a telegram sequence is allowed or not, can then be done by simple bit operations. It makes sense to create this table of possible combinations from engineering, but it can also be created later for the plant recorder.
  • the system recorder 4 switches into the communication of the partners.
  • level 4 TCP / IP telegrams can be packaged via the so-called SOCKS protocol and sent to another receiver. The receiver can then read the original destination address and forward the message to the original destination.
  • the packaging takes place on the source system through a patch of socket calls that allows for specific, configurable destinations (IP address and
  • the system recorder 4 logs the telegram data or telegrams 9 ', 10', 11 ', checks them against the information stored in the model (9, 10, 11) and visualizes the result, for example, as shown in FIG 3.
  • the described Actual sequence in practice the case that for the container 1234 a destination has been requested (telegram 9 '), the host computer 7 but has too long for the destination determination and the conveyor control 8 has therefore driven the container to a default destination C. (see telegram 11 ').
  • the DR telegram from the conveyor control 8 has been sent correctly and an OK symbol 14 appears on the screen.
  • the DS telegram 10 'from the master computer 7 was not sent, which is why the error symbol 15 is displayed on the screen.
  • Transport order telegram are searched.
  • messages in the event of erroneous sequences can also be sent to defined addresses.
  • the telegram data can be sorted according to different keys. For example, contents of the telegrams (eg the container number) can be used for this purpose. In this way it can be determined what happens to individual objects in the system. For this purpose, only the address of the key field in the telegrams must be specified in the configuration.
  • the strength of the system recorder 4 is the evaluation of telegram sequences according to various criteria, in particular to verify temporal and logical consequences. In practice, mistakes in this context are only comprehensible at great expense. If the recorder 4 more semantic information before
  • Figures 4 and 5 show a (also highly simplified and incomplete) example of the traffic engineering.
  • a function carrier of a train eg a door control device
  • the off state 20 is initially reached by a transition 30 during startup. If the door control unit according to transition 31 is turned on, the device is in the initialization state 21. If the initialization runs correctly, then the door control unit is in the normal state 22 according to transition 32. If the initialization is erroneous, the device goes to error state 23 corresponding to transition 33 In the case of a slight error, a transition 34 can take place from the error state 23 to the normal state 22. From the normal state 22, the device can be shut down according to transition 35 to a shutdown state 25.
  • the device may be shut down from fault state 23 in accordance with transition 36. From the shutdown state 25, the device is turned off according to transition 37 in the off state 20. In addition, the device may be brought from the normal state 22 to a test / service state 24 through a transition 38. A corresponding transition back is marked 39 in FIG. All status transitions 30 to 39 are allowed.
  • the current state of the function carrier (here door control unit) is located as a signal on the bus used by the train, z. B. MVB bus and is visible to the communication partners.
  • the system recorder 4 knows all permissible states 20 to 25 and state transitions 30 to 39 from the system documentation 5 for a given function carrier, and tracks and logs each state change, checks them against the information stored in the model and visualizes the result, for example, according to FIG by displaying the transitions in sequence. For permissible transitions, the last transition that has taken place is colored green, for example, by markings 40 on the states concerned (here states 22 and 25).
  • FIG. 5 shows a diagram of the function carrier in the case of an impermissible status transition 41, which is dyed red, for example.
  • the message exchange can not only be written, but largely automatically checked against the system documentation and the result can be logged and visualized, so that deviations from the specification can be represented directly.
  • a model-based development and a subsequent model-based test as well as commissioning can be carried out, whereby a common consistent modeling takes place for all project phases (coupling of the development / realization phase with test / commissioning phase).
  • the plant recorder can be used not only during commissioning on the construction site, but during the composite tests in the office environment. It is also suitable for supporting virtual commissioning and for diagnostic purposes in the current system. Furthermore, the entire system can be logged automatically (in whole or in part). The content and meaning of the logged data can be seen. With the above system, among others, the following is possible:
  • Semantic information eg signal is temperature value with value range XY and occurs in place of X.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

Eine Anlage, die mehrere Zustände einnehmen kann, soll zuverlässiger überprüft werden können. Dazu wird ein Verfahren mit folgenden Schritten vorgeschlagen: Ablegen je einer Zustandsübergangsinformation (13), in der Anlage für alle definierten Übergänge der Anlage von jeweils einem ersten der mehreren Zustände (DR, DS, TR) zu einem zweiten, Bilden einer aktuellen Zustandsübergangsinformation zu einem aktuellen Zustandsübergang der Anlage und automatisches überprüfen der aktuellen Zustandsübergangssituation anhand der in der Anlage abgelegten Zustandsübergangsinformation.

Description

Beschreibung
Verfahren zum Überprüfen einer Anlage anhand von Zustands- übergängen und entsprechende Anlage
Die vorliegende Erfindung betrifft ein Verfahren zum Überprüfen einer Anlage, insbesondere des Zusammenspiels von Anlagenkomponenten, die mehrere Zustände einnehmen kann/können. Darüber hinaus betrifft die vorliegende Erfindung eine entsprechende Anlage, insbesondere die DV-technische Erfassung und Auswertung der Zustände von Komponenten der Anlage.
Ein wesentlicher Punkt bei der Inbetriebnahme von Anlagen ist der Nachweis, dass die einzelnen Systeme korrekt, d. h. gemäß Spezifikation, miteinander kommunizieren. Dies erfolgt durch einen so genannten „Black-Box-Test", d. h. es wird das Verhalten der beteiligten Systeme „von außen" (an den Schnittstellen zu den anderen Systemen) geprüft.
Kommunikation erfolgt beispielsweise durch Telegramme (Datensätze), die zwischen den Systemen ausgetauscht werden. Sie kann aber auch durch Signale erfolgen, die auf einen Bus aufgelegt werden und dort für alle (zugelassenen) Teilnehmer verfügbar sind.
Die Prüfung der beteiligten Systeme umfasst u. a. syntaktische Informationen, die sich auf eine Nachricht beziehen, wie z. B. zulässige Werte und Wertegrenzen innerhalb eines Telegramms. Die Prüfung kann sich aber auch auf semantische Informationen bezüglich einer Nachricht beziehen, wie z. B. Plausibilitätsprüfungen oder eine Prüfung von Abhängigkeiten innerhalb eines Telegramms. Weiterhin können auch semantische Informationen geprüft werden, die sich auf mehrere Nachrichten beziehen (ablaufbezogene Informationen), wie z. B. zulässige Reihenfolgen von Telegrammen oder Signalen, zulässige Statusübergänge etc. Während der Inbetriebnahme bestehen heute folgende Probleme: Es ist nicht sichergestellt, dass die vorliegenden Testunterlagen tatsächlich den aktuellen Stand der Spezifikation darstellen, z. B. aufgrund nachträglicher kurzfristiger Änderungen.
Es existieren oft mehrere Spezifikationen (für die beteiligten Systeme) . Die Konsistenz und Widerspruchsfreiheit dieser Unterlagen ist nicht sichergestellt.
Es gibt keinen automatisierten Vorgang, um die oben ge- nannten Prüfungen durchzuführen und auszuwerten. Sie erfolgen von Hand, was einen beträchtlichen Aufwand bedeuten kann, da alle oben erwähnten Kriterien der Testergebnisse mit den jeweiligen Spezifikationen verglichen und eventuelle Abweichungen herausgefunden werden müssen.
- Durch diesen händischen Vorgang besteht auch die Gefahr, Abweichungen zu übersehen.
Die händische Auswertung und Prüfung erfolgt beispielsweise durch Protokollierung in ein Logbuch. Insbesondere erfolgt beispielsweise ein lokales Mitschreiben von Logbucheinträgen (Traces, Fehlermeldungen etc.) in den beteiligten Systemen. Dabei kann die Auswertung nur aus der Sicht des jeweiligen Systems erfolgen. Was im Gesamtzusammenhang geschehen ist, ist aus den jeweiligen Logbucheinträgen nicht ersichtlich. Vielmehr müssen die Einträge mehrerer Systeme (händisch) verglichen werden, was umständlich, zeitaufwendig und fehlerträchtig ist. Dies bedeutet, dass Semantik im Teilsystem vorhanden ist, die Gesamtsicht jedoch fehlt. Um das Kommunikationsverhalten im GesamtZusammenhang zu ermitteln, wird für die Analyse z. B. ein Logik-Analysator in das DV-Netz eingebracht, der alle über das Netz gesendeten Nachrichten protokolliert. Nachteilig hierbei ist, dass zwar gewisse Basisinformationen festgehalten werden können (z. B. Sender, Empfänger, Zeitstempel, Dateninhalt) , dass aber der
Dateninhalt nur als Byte-Strom verfügbar ist und sich die Bedeutung der Daten nicht erschließt. D. h. die Semantik ist nicht vorhanden, die Gesamtsicht ist jedoch vorhanden. In den beiden Fällen (Logbuch und Logik-Analysator) wird nur der jeweilige Nachrichtenaustausch festgehalten, es existiert jedoch keine Referenz zu einer Spezifikation. D. h. aus den Protokollierungen kann noch kein Rückschluss auf Konformität mit der Spezifikation gezogen werden.
Die Aufgabe der vorliegenden Erfindung besteht somit darin, eine Anlage, die mehrere Zustände einnehmen kann, einfach und zuverlässig überprüfen zu können.
Erfindungsgemäß wird diese Aufgabe gelöst durch ein Verfahren zum Überprüfen einer Anlage, die mehrere Zustände einnehmen kann, durch Ablegen je einer Zustandsübergangsübergangsinfor- mation in der Anlage für alle definierten Übergänge der Anlage von jeweils einem ersten der mehreren Zustände zu einem zweiten, Bilden einer aktuellen Zustandsübergangsinformation zu einem aktuellen Zustandsübergang der Anlage und automatisches Überprüfen der aktuellen Zustandsübergangsinformation anhand der in der Anlage abgelegten Zustandsübergangsinforma- tionen .
Darüber hinaus wird erfindungsgemäß bereitgestellt eine Anlage, die in mehrere Zustände versetzbar ist,
umfassend eine Speichereinrichtung, in der je eine Zustandsübergangsinformation für alle definierten Zustandsübergänge der Anlage, eine Verarbeitungseinrichtung zum Bilden einer aktuellen Zustandsübergangsinformation zu einem aktuellen Zustandsübergang der Anlage und zum automatischen Überprüfen der aktuellen Zustandsübergangsinformation anhand der in der Speichereinrichtung gespeicherten Zustandsübergangsinformati- onen.
In vorteilhafter Weise sind also alle zulässigen Zustandsübergänge vor Ort auf der Anlage selbst gespeichert, sodass bei jedem tatsächlichen Zustandsübergang sofort überprüft werden kann, ob dieser zulässig ist oder nicht. Speziell ist es in einer Ausführungsform möglich, das Zusammenspiel von Anlagenkomponenten der Anlage, die mehrere Zustände einnehmen können, einfach und zuverlässig überprüfen zu können. Die Zustandsübergänge betreffen dann die einzelnen Anlagenkomponenten. Als Voraussetzung dafür sind die Zustände der Komponenten zu erfassen und gegen die zugrundeliegende Spezifikation zu prüfen.
Vorzugsweise beinhaltet jede Zustandsübergangsinformation eine erste Information über den ersten Zustand und eine zweite Information über den zweiten Zustand. Damit sind nicht nur relative Zustandsübergänge in einer Zustandsübergangsinforma- tion erfasst, sondern absolute Übergänge erfassbar.
Das Überprüfen der aktuellen Zustandsübergangsinformation kann in der Anlage selbst stattfinden. Es lässt sich damit eine unmittelbare Überprüfung vor Ort erreichen.
Alternativ kann das Überprüfen durch einen an die Anlage angeschlossenen Anlagenrekorder stattfinden, der die aktuellen Zustandsübergangsinformationen aufzeichnet. Damit kann eine Anlage auch nachträglich oder im Bedarfsfall mit einer Auf- Zeichnungsmöglichkeit ausgestattet werden.
In einer speziellen Ausführungsform wird in der Anlage eine Anlagendokumentation gespeichert, in der Daten bereitgestellt sind, welche einem Nutzer angezeigt werden, wenn bei dem Überprüfen festgestellt wird, dass der aktuelle Zustandsüber- gang nicht definiert und damit unzulässig ist. Die Anlagendokumentation und damit die Anzeige für den Benutzer kann auf diese Weise sehr spezifisch auf die Anlage ausgerichtet werden .
Die Daten aus der Anlagendokumentation können für das automatische Überprüfen genutzt werden. So können für das Überprü- fen also nicht nur die Übergangsdaten selbst, sondern darüber hinaus auch weitere Daten genutzt werden.
Bei einer speziellen Ausgestaltung des Überprüfungsverfahrens bzw. der Anlage können die mehreren Zustände Typen von Telegrammen betreffen, die in der Anlage kommuniziert werden. Ein Zustandsübergang betrifft dann eben eine spezifische Abfolge von Telegrammen. Gerade die Abfolge von Telegrammen bestimmten Typs kann eine Information über den Zustand einer gesamten Anlage liefern.
In den Telegrammen können weitere Daten enthalten sein, die für das automatische Überprüfen herangezogen werden. Es lässt sich somit eine noch detailliertere Überprüfung als durch die Abfolge der Telegrammtypen alleine durchführen.
Wenn die Zustandsübergangsinformationen beispielsweise auf einem Anlagenrekorder aufgezeichnet werden, ist es günstig, wenn in jeder aktuellen Zustandsübergangsinformation eine Zeitinformation über die aktuelle Zeit enthalten ist. Dann kann nachträglich zu gewünschten Zeitpunkten eine Überprüfu der Anlage durchgeführt werden.
Die vorliegende Erfindung wird nun anhand der beigefügten Zeichnungen näher erläutert, in denen zeigen:
FIG 1 eine Prinzipskizze zur Einbindung eines Anlagenre- korders in ein Bussystem;
FIG 2 einen Soll-Ablauf von Telegrammen bei einem Behältertransport ;
FIG 3 einen Ist-Ablauf von Telegrammen bei dem Behältertransport;
FIG 4 zulässige Statusübergänge in einem System; FIG 5 unzulässige Statusübergänge in einem System von FIG 4;
FIG 6 erlaubte Übergänge bei den Telegrammen des Behältertransports der FIG 2 und 3; und
FIG 7 die erlaubten Übergänge von FIG 6 in kodierter
Form.
Die nachfolgend näher geschilderten Ausführungsbeispiele stellen bevorzugte Ausführungsformen der vorliegenden Erfindung dar.
Gemäß FIG 1 besteht eine Anlage beispielsweise aus einem System 1, einem System 2 , ... und einem System n. Die einzelnen Systeme sind über einen Bus 3 verbunden. An den Bus 3 ist außerdem ein zentraler Anlagenrekorder 4 angeschlossen. Weiterhin verfügt die Anlage über eine Anlagendokumentation 5. Der Anlagenrekorder 4 kann mit der Anlagendokumentation 5 Topolo- gie- und Semantikinformation über eine Datenverbindung 6 austauschen .
Der Anlagenrekorder 4 ist logisch mit den beteiligten Systemen 1 bis n verbunden (hier über den Bus 3) und er ist in der Lage, die ausgetauschten Informationen zu protokollieren und diese Daten semantisch zu interpretieren. Insbesondere ist er in der Lage, nicht korrekte AblaufSequenzen zu erkennen.
In einer einfachen Ausführungsform verwendet der Anlagenrekorder 4 zur Interpretation der Kommunikationsdaten eigene Konfigurationsinformationen (Anlagendokumentation ist in der Anlage nicht vorhanden) . Bei einer Weiterentwicklung kann der Anlagenrekorder 4 auf eine konsistente und aktuelle Anlagendokumentation 5 zurückgreifen, die u. a. spezifizierte Nachrichten, AblaufSequenzen und Zustandsübergänge in aktueller, konsistenter Form enthält. Die Spezifikationen (z. B. Zustandsdiagramm) und Modelle, die in der Anlagendokumentation 5 enthalten sind, werden verwendet, um für die Inbetriebnahmephase ein Modell (z. B. Code; vgl. FIG 7) zu erstellen, das für alle beteiligten Schnitt- Stellenpartner gilt und zur Überprüfung der vom Anlagenrekor- der 4 protokollierten Nachrichten dient. Mit dieser Information ist die Protokollierung der zeitlichen Abfolge des Informationsaustausches im Gesamtsystem möglich. Es kann eine Nachricht auf syntaktische und semantische Richtigkeit über- prüft werden, und es kann überprüft werden, ob die Abfolge der Nachrichten (z. B. Telegramme) zulässig ist.
Die FIG 2 und 3 zeigen ein Beispiel aus der Intralogistik . In einem automatischen Fördersystem soll ein Behälter mit der Identifikationsnummer 1234 zum Ziel A gefahren werden (Behältertransport) . Das Fördersystem besitzt einen Leitrechner 7 und eine Fördertechniksteuerung 8. Der Normalfall (Soll- Ablauf) ist in FIG 2 dargestellt. Die Fördertechnik-Steuerung 8 stellt in einem Telegramm 9 eine Zielanfrage (DR, Destina- tion Request) an den Leitrechner 7. Dieser ermittelt das Ziel A und sendet in einem Telegramm 10 einen Transportauftrag an die Fördertechnik-Steuerung 8 (DS, Destination Set) . Diese sorgt für den Transport zum gewünschten Ziel und meldet dann in einem Telegramm 11 Vollzug (TR, Transport Destination Rea- ched) .
Um ein Szenario eindeutig zu identifizieren, erhält jedes Szenario eine Szenarionummer. Das Szenario „regulärer Behältertransport" hat im Beispiel von FIG 2 die Szenarionummer 4711. Jedes Mal, wenn das Szenario verwendet wird, d. h. jedes Mal, wenn ein weiterer Behälter transportiert werden soll, wird eine an die Szenarionummer angehängte Laufnummer (xxx) um Eins erhöht. Mit dieser Kombination aus Szenarionummer und Laufnummer ist eine eindeutige Zuordnung der Behäl- terbewegung zum zugrunde liegenden Szenarion möglich.
In dem konkreten Beispiel von FIG 3 wird der Behälter 1234 mit dem Szenario „4711, regulärer Behältertransport" bewegt. Die aktuelle Laufnummer ist (zufällig) 005. Würde parallel oder danach ein weiterer Behälter 5678 bewegt, würde die Szenarionummer ebenfalls 4711 sein („regulärer Behältertransport", Laufnummer 006) .
Letztlich bedeutet dies, dass pro Sequenz die Reihenfolge der spezifizierten Telegramme (9, 10, 11 für Soll-Ablauf in FIG 2 und 9', 10', 11' für Ist-Ablauf in FIG 3) sich an einem Zu- standsdiagramm 12 orientiert, das auf einfache Art und Weise geprüft werden kann, wie in FIG 6 ersichtlich ist. Im Normalfall (Soll-Ablauf) folgt einem DR- ein DS-Telegramm und anschließend das Vollzugstelegramm TR zur Bestätigung, dass der Auftrag durchgeführt wurde. Aufgrund der Auslastung der Anlage kann aber nach dem Abschicken des Transportauftrags eine neue Zielanfrage kommen, bevor das Ziel erreicht ist. Dies stellt ebenfalls eine korrekte Telegrammfolge dar. Alle zulässigen Zustandsübergänge, hier Telegrammfolgen, sind in dem Diagramm 12 mit Pfeilen 13 eingezeichnet. Setzt man nun die einzelnen Zustände gemäß FIG 7 in ein Bit- Muster um, wobei jeder Zustand einem Bit entspricht, können ausgehend von der Quelle Q alle möglichen Ziele Z als Bit- Kombination erfasst werden. Bei einem 32-Bit-Rechner können dadurch in einem Wort 32 mögliche Ziel-Zustände erfasst wer- den. Diese Zahl dürfte eher selten erreicht werden, da dann die Komplexität kaum überschaubar ist.
Die Prüfung, ob eine Kombination, d. h. ein Zustandsübergang bzw. eine Telegrammfolge erlaubt ist, oder nicht, kann dann durch einfache Bit-Operationen erfolgen. Sinnvollerweise sollte diese Tabelle der möglichen Kombinationen aus dem Engineering entstehen, sie kann aber auch nachträglich für den Anlagenrekorder erstellt werden. Der Anlagenrekorder 4 schaltet sich in die Kommunikation der Partner ein. Dabei ist zu unterscheiden zwischen einem Prozessbus (wo die Daten der Partner relativ einfach von mehreren Teilnehmern gelesen werden können) und einem message- orientierten System, in dem explizit Quelle und Ziel vorgegeben ist. Auch hier existieren aber Lösungen am Markt. Beispielsweise können TCP/IP-Telegramme der Ebene 4 über das so genannte SOCKS-Protokoll verpackt und an einen anderen Emp- fänger gesendet werden. Der Empfänger kann dann die ursprüngliche Zieladresse auslesen und das Telegramm an das ursprüngliche Ziel weiterleiten. Das Verpacken erfolgt auf dem Quellsystem durch einen Patch der Socket-Aufrufe, durch den für bestimmte, konfigurierbare Ziele (IP-Adresse und
-Port) diese Umsetzung vorgenommen wird.
Die Umleitung der Telegramme zum Anlagenrekorder 4 bewirkt zwar eine verzögerte Kommunikation, sie ist aber in der Regel in dem betrachteten Umfeld unkritisch, da derartige Telegram- me überwiegend in der übergeordneten Leittechnik eingesetzt werden, wo keine EchtZeitanforderungen bestehen. Gerade in dem Umfeld, wo komplexe Produktionen oder Transporte gesteuert werden, liegt ein hohes Kommunikationsaufkommen vor, bei dem immer wieder schwer nachvollziehbare Fehler auftreten.
Der Anlagenrekorder 4 protokolliert die Telegrammdaten bzw. Telegramme 9', 10', 11', prüft sie gegen die im Modell hinterlegten Informationen (9, 10, 11) und visualisiert das Ergebnis beispielsweise gemäß FIG 3. In diesem Beispiel ent- spricht die beschriebene Ist-Sequenz in der Praxis dem Fall, dass für den Behälter 1234 ein Ziel angefragt wurde (Telegramm 9' ) , der Leitrechner 7 aber zu lange für die Zielermittlung benötigt hat und die Fördertechniksteuerung 8 deshalb den Behälter zu einem Default-Ziel C gefahren hat (vgl. Telegramm 11' ) . Das DR-Telegramm von der Fördertechniksteuerung 8 wurde korrekt gesendet und ein OK-Symbol 14 erscheint am Bildschirm. Das DS-Telegramm 10' vom Leitrechner 7 wurde nicht gesendet, weswegen das Fehlersymbol 15 am Bildschirm angezeigt wird. Schließlich wurde zwar das TR-Telegramm 11' von der Fördertechniksteuerung verschickt, aber das Ziel war „C", sodass ebenfalls ein Fehlersymbol 15 auf dem Bildschirm erscheint. Darüber hinaus kann auch das falsche Ziel „C" farblich markiert sein. Mit dieser Darstellung kann nun ge- zielt nach der konkreten Ursache für das Ausbleiben des
Transportauftragstelegramms gesucht werden.
Neben dieser grafischen Visualisierung können auch Meldungen bei fehlerhaften Sequenzen an definierte Adressen abgesetzt werden .
Die Telegrammdaten können nach verschiedenen Schlüsseln sortiert werden. So können beispielsweise Inhalte der Telegramme (z. B. die Behälternummer) dazu verwendet werden. Auf diese Weise kann ermittelt werden, was mit einzelnen Objekten in der Anlage passiert. Dazu muss lediglich in der Konfiguration die Adresse des Schlüsselfelds in den Telegrammen angegeben werden. Die Stärke des Anlagenrekorders 4 ist die Auswertung von Telegrammfolgen nach verschiedenen Kriterien, um insbesondere zeitliche und logische Folgen zu verifizieren. In der Praxis sind gerade Fehler in diesem Kontext nur mit hohem Aufwand nachvollziehbar. Liegen dem Rekorder 4 weitere semantische Informationen vor
(z. B. über eine auswertbare Anlagendokumentation 5, vgl. FIG 1), kann der Rekorder 4 ausgebaut werden, um folgende, weitere Prüfungen vorzunehmen:
- Stellt das Ziel A ein gültiges Ziel in der Anlage dar (Ve- rifikation des Anlagenlayouts der Anlagendokumentation) ?
- Ist die Behälternummer 1234 formal zulässig (Verifikation anhand der Vorschrift „muss numerisch sein") in der Telegrammbeschreibung der Anlagendokumentation?
- Ist die Zielanfrage zu diesem Zeitpunkt ein zulässiges Te- legramm in diesem Szenario (erstes Telegramm in der Sequenz) ?
Die FIG 4 und 5 zeigen ein (ebenfalls stark vereinfachtes und unvollständiges) Beispiel aus der Verkehrstechnik. Ein Funk- tionsträger eines Zugs (z. B. ein Türsteuergerät) soll die dargestellten Zustände einnehmen können. Aus einem unbestimmten Anfangszustand 19 wird bei der Inbetriebnahme definitionsgemäß zunächst der Aus-Zustand 20 durch einen Ubergang 30 erreicht. Wird das Türsteuergerät gemäß Übergang 31 eingeschaltet, so kommt das Gerät in den Initia- lisierungszustand 21. Läuft die Initialisierung korrekt ab, so gerät das Türsteuergerät in den Normalzustand 22 gemäß Übergang 32. Bei fehlerhafter Initialisierung geht das Gerät entsprechend Übergang 33 in den Fehlerzustand 23. Bei geringfügigem Fehler kann ein Übergang 34 vom Fehlerzustand 23 zum Normalzustand 22 erfolgen. Aus dem Normalzustand 22 kann das Gerät gemäß Übergang 35 zu einem Shutdown-Zustand 25 heruntergefahren werden. Ebenso kann das Gerät aus dem Fehlerzustand 23 gemäß Übergang 36 heruntergefahren werden. Aus dem Shutdown-Zustand 25 wird das Gerät gemäß Übergang 37 in den Aus-Zustand 20 abgeschaltet. Darüber hinaus kann das Gerät von dem Normalzustand 22 in einen Test/Service-Zustand 24 durch einen Übergang 38 gebracht werden. Ein entsprechender Übergang zurück ist in FIG 4 mit 39 gekennzeichnet. Sämtliche Statusübergänge 30 bis 39 sind zulässig.
Der jeweils aktuelle Zustand des Funktionsträgers (hier Türsteuergerät) liegt als Signal auf dem verwendeten Bus des Zugs, z. B. MVB-Bus und ist für die Kommunikationspartner sichtbar. Der Anlagenrekorder 4 kennt zu einem gegebenen Funktionsträger alle zulässigen Zustände 20 bis 25 und Zu- standsübergänge 30 bis 39 aus der Anlagendokumentation 5 und verfolgt und protokolliert jede Zustandsänderung, prüft sie gegen die im Modell hinterlegten Informationen und visuali- siert das Ergebnis beispielsweise gemäß FIG 4, indem die stattgefundenen Übergänge der Reihe nach angezeigt werden. Bei zulässigen Übergängen wird der zuletzt stattgefundene Übergang beispielsweise durch Markierungen 40 an den betroffenen Zuständen (hier Zustände 22 und 25) grün eingefärbt. FIG 5 zeigt ein Schaubild des Funktionsträgers bei einem unzulässigen Statusübergang 41, der beispielsweise rot eingefärbt ist. In FIG 5 sind sämtliche Zustände und Zustandsüber- gänge wie in FIG 4 vorhanden. Es wird daher auf die Beschrei- bung von FIG 4 verwiesen. Zusätzlich ist, wie erwähnt nur der unzulässige Statusübergang 41 von dem Fehlerzustand 23 zu dem Aus-Zustand 20 in der Darstellung eingezeichnet. Die entsprechenden Markierungen 40 der beiden betroffenen Zustände kön- nen rot kenntlich gemacht sein. Im Beispiel von FIG 5 hat sich der Funktionsträger nach Auftreten eines Fehlers abgeschaltet, ohne den Shutdown-Vorgang zu durchlaufen. Dieser Fehler kann nun gezielt analysiert werden. Wie bei bekannten Protokollierungssystemen können generell verschiedene Level der Protokollierung (Granularität , Ausführlichkeit der Protokollierung) eingestellt werden. Außerdem können einzelne/ausgewählte oder alle Partner protokolliert werden. In einer weiteren Ausbaustufe ist denkbar, dass die Partner selber dem Rekorder noch zusätzliche (interne) Informationen zur Verfügung stellen,
wie z. B. standardisierte Diagnose, Trace-, Zustandsdaten, die über spezielle Aufrufe abgefragt werden können. Entsprechend der vorliegenden Erfindung kann der Nachrichtenaustausch nicht nur mitgeschrieben werden, sondern weitgehend automatisch gegen die Anlagendokumentation geprüft und das Ergebnis protokolliert sowie visualisiert werden, sodass sich Abweichungen von der Spezifikation unmittelbar darstellen lassen. Hierdurch kann eine modellbasierte Entwicklung und ein daran anschließender modellbasierter Test sowie eine Inbetriebnahme durchgeführt werden, wobei für alle Projektphasen eine gemeinsame konsistente Modellierung erfolgt (Kopplung der Entwicklungs- /Realisierungsphase mit Test- /Inbetriebnahmephase) .
Der Anlagenrekorder kann nicht nur während der Inbetriebnahme auf der Baustelle eingesetzt werden, sondern bereits während der Verbundtests in der Büroumgebung. Er eignet sich auch zur Unterstützung einer virtuellen Inbetriebnahme und für Diagnosezwecke in der laufenden Anlage. Ferner kann das Gesamtsystem automatisch protokolliert werden (ganz oder teilweise) . Der Inhalt und die Bedeutung der protokollierten Daten sind ersichtlich. Mit dem oben dargestellten System ist unter anderen Folgendes möglich :
- Automatische Protokollierung, Auswertung und Bewertung von Testsequenzen in ihrer zeitlichen Abfolge. Deutliche Re- duktion des manuellen Auswertungsauf ands.
Darstellung des Inhalts der Bedeutung von Nachrichten. Semantische Information (z. B. Signal ist Temperaturwert mit Wertebereich XY und tritt in Anlage an Stelle X auf) .
Überwachung von zulässigen Wertebereichen, Alarm bei Überschreitungen .
- Graphische Darstellung des Kommunikationsablaufs, z. B. als UML-Diagramm (Unified Modelling Language; Sequence
Chart)
- Graphische Darstellung des Zustands der Partner (sofern dies als Schnittstelle zur Verfügung steht) .
„Schieberegler" für den Rekorder und Nachfahren von Ergebnissen. Analog wie bei dem Schieberegler eines PC- Videoplayers kann mit einem Schieberegler ein bestimmter Zeitpunkt in der Vergangenheit selektiert werden und von dort ab alle Kommunikationsvorgänge nochmals mit allen oben genannten Informationsmöglichkeiten dargestellt werden, was die Fehlersuche sehr erleichtert. Bezugszeichenliste
1, 2, n Systeme
3 Bus
4 Anlagenrekorder
5 Anlagendokumentation
6 Datenverbindung
7 Leitrechner
8 Fördertechnik-Steuerung 9, 9', 10, 10', 11, 11' Telegramme
12 Zustandsdiagramm
13 Pfeile
14 OK-Symbol
15 Fehlersymbol
20 Aus-Zustand
21 Initialisierungszustand
22 Normalzustand
23 Fehlerzustand
24 Test/Service-Zustand
25 Shutdown-Zustand
30, 31, 32, 33, 34, 35, Übergänge
36, 37, 38, 39
40 Markierungen
41 Statusübergang
A Ziel
C Default-Ziel
Q Quelle
Z Ziele

Claims

Patentansprüche
1. Verfahren zum Überprüfen einer Anlage, die mehrere Zustän- de (20 bis 25) einnehmen kann,
gekennzeichnet durch
- Ablegen je einer Zustandsübergangsübergangsinformation in der Anlage für alle definierten Übergänge (13, 30 bis 39) der Anlage von jeweils einem ersten der mehreren Zustände zu einem zweiten,
- Bilden einer aktuellen Zustandsübergangsinformation zu einem aktuellen Zustandsübergang der Anlage und
- automatisches Überprüfen der aktuellen Zustandsübergangsin- formation anhand der in der Anlage abgelegten Zustandsüber- gangsinformationen .
2. Verfahren nach Anspruch 1, wobei jede Zustandsübergangsin- formation eine erste Information über den ersten Zustand und eine zweite Information über den zweiten Zustand beinhaltet.
3. Verfahren nach Anspruch 1 oder 2, wobei das Überprüfen durch die Anlage selbst stattfindet.
4. Verfahren nach Anspruch 1 oder 2, wobei das Überprüfen durch einen an die Anlage angeschlossenen Anlagenrekorder (4) stattfindet, der die aktuellen Zustandsübergangsinformationen aufzeichnet .
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei in der Anlage eine Anlagendokumentation (5) gespeichert wird, in der Daten bereitgestellt sind, welche einem Nutzer angezeigt werden, wenn bei dem Überprüfen festgestellt wird, dass der aktuelle Zustandsübergang (13, 30 bis 39) nicht definiert und damit unzulässig ist.
6. Verfahren nach Anspruch 5, wobei die Daten aus der Anlagendokumentation (5) für das automatische Überprüfen genutzt werden .
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die mehreren Zustände (20 bis 25) Typen von Telegrammen (9', 10' , 11' ) betreffen, die in der Anlage kommuniziert werden.
8. Verfahren nach Anspruch 7, wobei in den Telegrammen (9', 10' , 11' ) weitere Daten enthalten sind, die für das automatische Überprüfen herangezogen werden.
9. Verfahren nach Anspruch 4, wobei in jeder aktuellen Zu- standsübergangsinformation eine ZeitInformation über die aktuelle Zeit enthalten ist.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei eine Anlagenkomponente oder ein Zusammenspiel von mehreren
Anlagenkomponenten überprüft wird.
11. Anlage,
- die in mehrere Zustände (20 bis 25) versetzbar ist, gekennzeichnet durch
- eine Speichereinrichtung, in der je eine Zustandsübergangs- information für alle definierten Übergänge (13, 30 bis 39) der Anlage von einem ersten der mehreren Zustände zu einem zweiten gespeichert ist,
- einer Verarbeitungseinrichtung zum Bilden einer aktuellen Zustandsübergangsinformation zu einem aktuellen Zustands- übergang (13, 30 bis 39) der Anlage und
- zum automatischen Überprüfen der aktuellen Zustandsübergangsinformation anhand der in der Speichereinrichtung ge- speicherten Zustandsübergangsinformationen .
EP10752294.8A 2010-08-09 2010-08-09 Verfahren zum überprüfen einer anlage anhand von zustandsübergängen und entsprechende anlage Not-in-force EP2583144B1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/004857 WO2012019616A1 (de) 2010-08-09 2010-08-09 Verfahren zum überprüfen einer anlage anhand von zustandsübergängen und entsprechende anlage

Publications (2)

Publication Number Publication Date
EP2583144A1 true EP2583144A1 (de) 2013-04-24
EP2583144B1 EP2583144B1 (de) 2016-09-28

Family

ID=43629125

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10752294.8A Not-in-force EP2583144B1 (de) 2010-08-09 2010-08-09 Verfahren zum überprüfen einer anlage anhand von zustandsübergängen und entsprechende anlage

Country Status (2)

Country Link
EP (1) EP2583144B1 (de)
WO (1) WO2012019616A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1413937A1 (de) * 2002-10-21 2004-04-28 ABB Schweiz AG Anzeige eines endlichen Automaten zur Bedienerführung
US20110054639A1 (en) * 2008-02-01 2011-03-03 Luca Pazzi Method for ensuring safety and liveness rules in a state based design

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2012019616A1 *

Also Published As

Publication number Publication date
EP2583144B1 (de) 2016-09-28
WO2012019616A1 (de) 2012-02-16

Similar Documents

Publication Publication Date Title
DE102006051444B4 (de) Diagnoseverfahren und -vorrichtung für ein Feldbussystem
DE102008056114B3 (de) Verfahren und Vorrichtung zur Diagnose von Netzwerken, insbesondere von Feldbussystemen
DE19934514C5 (de) Verfahren zum Konfigurieren eines an einen Feldbus angeschlossenen Busteilnehmers
DE10204826A1 (de) System und Verfahren zur Analyse eines Netzwerks und/oder Generierung der Topologie eines Netzwerks
EP2770434B1 (de) Verfahren zur Durchführung einer Inventarisierung der an ein Steuergeräte-Testsystem angeschlossenen Hardware-Komponenten
DE2048670A1 (de) Speicherwartungsanordnung fur Daten verarbeitungsanlagen
DE102014116865B4 (de) Analysevorrichtung zur Analyse und Manipulation einer Kommunikationssequenz
EP2274874B1 (de) Überprüfung einer kommunikationsverbindung zwischen feldgeräten
DE102010003448A1 (de) Adressierungsverfahren und Kommunikationsnetzwerk mit einem solchen Adressierungsverfahren
EP2583144B1 (de) Verfahren zum überprüfen einer anlage anhand von zustandsübergängen und entsprechende anlage
DE112013006925T5 (de) Programmierbares Anzeigegerät
DE102009027168B4 (de) Verfahren zum Ermitteln einer übermittelten Telegramm-Datenlänge
DE102004033593A1 (de) Verfahren zur Simulation einer technischen Anlage
DE102005057000B4 (de) Feldbusgerät zum Einsatz in Feldbussystemen, insbesondere in Prozessleitsystemen
EP1454201B1 (de) Engineeringsystem und automatisierungssystem
DE102016105136B4 (de) Maskierung des Einflusses nichtunterstützter Feldbuskommandos
DE102014206700B4 (de) Testanordnung zum Testen mehrerer Geräte
EP4412183A1 (de) Verfahren und system zum transformieren aufgezeichneter kommunikations-daten
DE2048670C (de) Verfahren und Anordnung zur Über prüfung einer Datenverarbeitungsanlage
DE102006040986B4 (de) Verfahren zum Testen des Verhaltens von Busteilnehmern in einem Flexray-Bussystem
DE2842317C2 (de) Schaltungsanordnung für Fernmeldeanlagen, insbesondere Fernsprechvermittlungsanlagen, mit zentralen Steuereinrichtungen und peripheren Schalteinrichtungen
DE102006016016A1 (de) Fehlerdiagnosesystem und Verfahren zur Analyse und Anzeige von Fehlern zumindest eines Steuergeräts in einem Fahrzeug
DE20307101U1 (de) Automatisierungssystem mit vereinfachter Diagnose und Fehlerbehebung
EP1993014B1 (de) Verfahren zum Lokalisieren von defekten Hardwarekomponenten und/oder Systemfehlern innerhalb einer Produktionsanlage
DE102006028424A1 (de) Diagnosesystem und Diagnoseverfahren für ein Feldbussystem

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: 20130116

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 502010012479

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G05B0019045000

Ipc: G05B0023020000

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: G05B 23/02 20060101AFI20160406BHEP

Ipc: G05B 19/045 20060101ALI20160406BHEP

INTG Intention to grant announced

Effective date: 20160425

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 833274

Country of ref document: AT

Kind code of ref document: T

Effective date: 20161015

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502010012479

Country of ref document: DE

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20161228

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20160928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20161229

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20170130

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20161228

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20170128

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 502010012479

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

RAP2 Party data changed (patent owner data changed or rights of a patent transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

26N No opposition filed

Effective date: 20170629

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: SIEMENS SCHWEIZ AG, CH

Ref country code: CH

Ref legal event code: PCOW

Free format text: NEW ADDRESS: WERNER-VON-SIEMENS-STRASSE 1, 80333 MUENCHEN (DE)

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20170809

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170831

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170831

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20170831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170809

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170809

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170809

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 9

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

REG Reference to a national code

Ref country code: AT

Ref legal event code: MM01

Ref document number: 833274

Country of ref document: AT

Kind code of ref document: T

Effective date: 20170809

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170809

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20181019

Year of fee payment: 9

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20100809

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160928

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20190828

Year of fee payment: 10

Ref country code: FR

Payment date: 20190823

Year of fee payment: 10

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 502010012479

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200303

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200831

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200809