EP1664947A2 - Prozessrechner-schnittstelle auf der basis einer beschreibungs- oder auszeichnungssprache, insbesondere xml - Google Patents

Prozessrechner-schnittstelle auf der basis einer beschreibungs- oder auszeichnungssprache, insbesondere xml

Info

Publication number
EP1664947A2
EP1664947A2 EP04766806A EP04766806A EP1664947A2 EP 1664947 A2 EP1664947 A2 EP 1664947A2 EP 04766806 A EP04766806 A EP 04766806A EP 04766806 A EP04766806 A EP 04766806A EP 1664947 A2 EP1664947 A2 EP 1664947A2
Authority
EP
European Patent Office
Prior art keywords
xml
mode
drive
computer
interface according
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
EP04766806A
Other languages
English (en)
French (fr)
Inventor
Mathias Monse
Gunther Kraus
Harold Meis
Thomas Tschaftary
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.)
Baumueller Anlagen Systemtechnik GmbH and Co
Original Assignee
Baumueller Anlagen Systemtechnik GmbH and Co
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 Baumueller Anlagen Systemtechnik GmbH and Co filed Critical Baumueller Anlagen Systemtechnik GmbH and Co
Publication of EP1664947A2 publication Critical patent/EP1664947A2/de
Withdrawn legal-status Critical Current

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/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0423—Input/output

Definitions

  • the invention relates to a universally usable interface for process computers, which can be, for example, regulators or controls for electric drives.
  • the interface is used for the information technology or communication coupling of the process computers, drive controllers or the like to other computer nodes, which can be, for example, operator terminals, control center and / or diagnostic computers, other process computer nodes or hierarchically higher-level controls.
  • the specialist article "Info portal for cross-plant process visualization and management via the Internet” (authors: Andreas Kitzler and Werner Feiten) is known from a summary of the conference proceedings on the "SPS IPC-Drives" congress held in Nuremberg in November 2001.
  • a communication structure is proposed therein in which a plurality of mutually independent automation systems, cells or systems can be combined, monitored, visualized and the like via an information portal.
  • the information portal can be accessed via the Internet.
  • the communication between the automation cells (so-called Supervisory Control And Data Acquisition - SCADA) on the one hand and the central web server of the information portal on the other hand takes place via standard interfaces based on the expandable markup language XML.
  • every automation system is provided with a so-called XML agent for communication with the information portal based on TCP-IP.
  • Management should be able to evaluate various automation cells or SCADA systems in a qualified manner via the web.
  • the individual sensor data can be transported via the web from the information portal, it must first be collected at the level that is specific to them, processed there and made available to the information portal via the XML agents.
  • a computer network with diagnostic computer nodes is known from the older international patent application PCT / EP2003 / 050 349 (WO2004 / 014 022), which communicates with process computer nodes, in particular drive controllers, via XML-based communication interfaces (there called "communication computer nodes" or "communication module”).
  • the communication computer node is with a software module with the function of an information broker for parameters described, the task of which is to provide an XML-based parameter interface for access to the parameters of the process computer node.
  • An XML-based protocol defined with the help of an XML schema is used as the protocol, which communicates with a client of the computer network via TCP / IP. The functions of reading and writing parameters from or to the process computer node are implemented.
  • the present invention is based on this earlier registered invention and represents a further, possibly generalized embodiment of the process computer interface described in the earlier application as a communication computer node.
  • the disclosure of the older application does not contain the teaching of “operating” the process computer as it were via universal controls of its process control functions.
  • no mechanisms are shown which could ensure sufficient transparency and security in the transmission of the XML protocols.
  • the invention has for its object to provide a universal process computer, in particular drive interface, which can be adapted for different process and process computer technologies, or the process computer interface should be independent of the technology and hardware currently used in the process computer and in the Date ⁇ transmission technology.
  • markup languages in particular the XML (eXtensible Markup Language) based on SGML (Standardized Generalized Markup Language)
  • XML eXtensible Markup Language
  • SGML Standardized Generalized Markup Language
  • a generally valid interface is formed, with which in theory any process computer and thus the one controlled by it can be controlled technical-physical process, in particular electrical drive processes can be controlled and operated.
  • the functional interface according to the invention entire processes can be triggered in the process to be controlled, including data processing processes in the process computer, by interpreting information prepared with the markup language or, for example, XML protocols upon receipt in the interface.
  • a controller assigned to an axis can be synchronized with another drive by means of an XML document.
  • the source information for this is in the order received as an XML description from the interface.
  • the interface according to the invention does not necessarily have to be integrated in the process computer. It can also run as an external software module on any hardware that has a communication link to the process computer.
  • FIG. 1 shows a block-like representation of the internal basic structure of the interface according to the invention
  • FIG. 2 uses a time diagram to select an operating state and then activate and deactivate it
  • FIG. 3 shows the time sequence of the communication sequence in the “speed mode” operating state when accelerating and braking an electric drive
  • FIG. 4 shows the temporal communication sequence when the position of the electric drive changes in the “position mode” operating state
  • FIG. 5 shows the temporal communication sequence in the case of a cyclical subscription for diagnostic purposes
  • FIG. 7 shows a block diagram with a signal flow for a controller sign-of-life monitoring by means of the interface according to the invention
  • Figure 8 is a schematic Ethemet network structure, in which the interface according to the invention can be used and
  • FIG. 9 shows a further internal software structure of the interface according to the invention designed as a communication PC and XML server.
  • the functionalities of the interface according to the invention intended for electric drives can be divided into the three sub-modules or sub-areas "operation", “diagnosis” and “configuration”.
  • the drive can be made up of one Drive controller or a drive control, a power section connected downstream of this, for example with a power amplifier and current or converter, and an electric motor.
  • the aim of the "Operation" area or submodule is to control the drive functions.
  • the XML documents in this area provide all drive-specific functions that are required for operating the drive in this application.
  • An associated software module contains state machines that reflect the current state of the drive and influence the state of the drive through the specified XML requests.
  • a communication connection for example a TCP / IP socket connection, is established for the communication of a client computer node with the interface submodule "Operation" as a server, via which XML documents can be transmitted.
  • the interface submodule on the client and / or, for example, on a drive controller triggers a communication error that leads to a defined shutdown response if the drive is in an inactive operating state, disconnecting the connection does not trigger an error reaction.
  • the operating status of the drive can basically be divided into four different categories: production, set-up, service and initialization. There are different operating states in each category, which can be preselected according to Fig. 2 by an XML request and possibly configured. The selected operating state can be activated or deactivated with the help of a subsequent start / stop order.
  • the operating state is to be preselected.
  • the XML order "order" is transmitted to the interface submodule and its successful processing is confirmed by the response "OK”.
  • the operating state is preselected. It can then be activated with the activation message "SW_Start”. Successful processing is confirmed with "OK”. Similarly, the operating state can be deactivated with "SW_STOP".
  • the drive In the "Speed_Mode" operating state, the drive is in a speed control and accelerates to a predetermined speed.
  • the XML request "Speed_Mode” is accepted by the operator submodule or function manager, provided that there is no error state and the previous state has been deactivated. If the drive is already in the "Speed_Mode” state and is activated, the following “Speed_Mode” can be used “Jobs the rotational speed of the drive are changed. The" Speed_Mode "jobs are processed sequentially. Fig. 3 shows an example of acceleration and braking in "Speed_Mode".
  • the XML command "Position_Mode” is accepted by the interface submodule "Operation” if there is no error condition and the previous status has been deactivated. If the drive is already in the "Position_Mode” state and is activated, the position of the drive can be changed with subsequent "Position_Mode” jobs.
  • the Position_Mode orders are processed sequentially. 4 shows an example of changing the position in the "Position_Mode".
  • a pre-selected operating state can be activated with the activation command 1 , SW_Start ".
  • Activation command SW_Start ":
  • An activated operating state can be deactivated with the deactivation command "SW_Stop". If the drive is not in the activated state, an error message is generated.
  • - ⁇ Mode> "controller_orf_at_standstiH”: The controller is braked to a standstill with the braking ramp ⁇ Acceleration_max> and then switched off.
  • ⁇ Mode> "controller_on”: The controller is braked to a standstill with the braking ramp ⁇ Acceleration_max> and remains switched on.
  • the aim of the "Diagnostics" area or sub-module is to provide information on drive diagnostics.
  • the client e.g. control center process
  • the client can subscribe to a grouping of any information from the information provided by the drive. These are then transferred to the control center process in a configurable time interval or when changes are made.
  • a separate communication connection to the "Diagnostics" interface module is established for each subscription.
  • the maximum number of simultaneous subscriptions to the "Diagnostics" interface module is limited.
  • the following example table shows examples of the information supplied by the "Diagnostics" interface module.
  • the "Diagnostics" interface submodule can send the diagnostic information in two different ways: cyclical subscription and event-based subscription.
  • FIG. 5 shows the communication flow for a cyclical subscription. After the Connection, the subscription is requested by a "Subscription Request” message. After the order has been successfully processed, a data message “Data” is sent immediately. The data is then sent in a predetermined time frame. A “Subscription Cancel” message ends the subscription and the communication connection.
  • Event based subscription In the "Event-based subscription" mode, the subscribed information is only transmitted when there is a change, but not more than a configurable period of time. To ensure that slight fluctuations in numerical values do not result in constant message transmission, the data is only sent if it exceeds more than an internal tolerance threshold from 6 shows the communication sequence for an event-based subscription.
  • the subscription After the connection has been successfully established, the subscription is requested by a “Subscription_Request_Event” message. After the order has been successfully processed, a data message "Data" is sent immediately. After that, the data is only sent when one or more of the subscribed parameters are changed - but at a maximum with the frequency specified in ⁇ Refresh_Time>.
  • a change indicator (change_flag) is transmitted for the event-based subscription, which indicates whether a parameter has changed compared to the last message.
  • the Life Check Manager ensures that communication between the control center process and the MDS controller is functional. A breakdown in the communication connection and a failure of the devices involved can thus be detected. Sign-of-life messages are exchanged between the control center process and the MDS controller.
  • the Life Check Manager receives the sign of life messages from the control center process and passes the information on to the MDS controller. This sends feedback to the Life Check Manager. The feedback is packaged in an XML sign-of-life message and sent to the control center process. 7 shows the signal flow of the sign-of-life messages.
  • the MDS controller monitors whether it regularly receives a Life_Check telegram from the XML server. If the telegram fails due to a communication fault or the failure of the XML server or control center process, the MDS controller brings the drive into a safe state and reports an error. The reply to the Life_Check telegram that is sent to the XML server serves as a sign of life for the MDS controller. If there is no response due to a communication fault or a failure of the MDS controller, no Life_Check_Response message is sent to the control center process. The latter can therefore notice the failure of the MDS controller or the communication fault and react appropriately. If the XML server fails, no sign-of-life messages are forwarded. Both the control center process and the MDS controller can react and bring the drive into a safe state.
  • Numerical values are used as the sign of life message, which the control center process sends to the XML server in an understandable manner according to the user's specifications.
  • the numerical value is passed through to the MDS controller and sent back to the control center process in the Life_Check_Response message. This checks whether the received value is the same as the one sent and increments the next value to be sent by 1.
  • the sign-of-life monitoring can be configured with the aid of a configuration message "Life_Check_lnitialize".
  • the time period must be defined by a controller and bindingly specified to the XML server ( ⁇ Timeout> in milliseconds) after which the MDS controller reacts in the event of a sign of life failure from the XML server or control center process.
  • the response to a sign of life failure can be configured in various operating states.
  • the stop processes listed in connection with the deactivation command "SW_Stop" apply to the reaction.
  • a default behavior is provided that applies to all operating states not explicitly listed in the configuration message.
  • FIG. 8 schematically shows a network structure with Ethernet as a possible example of use for the drive interface according to the invention.
  • the function of the XML server can be integrated in the G-Drive controller or in the other drive, so that the additionally required Ethernet connection and computer hardware are not required.
  • FIG. 9 shows the software modules relevant for the XML interface or server in the design as a communication PC.
  • the three servers "Function Manager”, “Subscription Manager” and “Life Check Manager” are available on a specific TCP port for communication with the controller and can be addressed using an XML-based protocol Specification of the XML-based protocol of the three servers and the associated communication processes can be seen from the explanations above, in addition the data and log messages required by the Baudis diagnostic system are provided by the XML server.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer And Data Communications (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Schnittstelle für Prozessrechner, insbesondere Regler oder Steuerungen elektrischer Antriebe, zu deren informationstechnischer Kopplung mit sonstigen Rechnerknoten, beispielsweise Bedienterminal, Leitstands- und/oder Diagnose-Rechner, Intemet­-Clients, andere Prozessrechnerknoten oder übergeordnete Steuerungen, welche Schnittstelle folgendes aufweist: einen oder mehrere, dem oder den sonstigen Rechnerknoten zugeordnete Kommunikations-Ports, einen oder mehrere Funktions-Ports für den oder die anzukoppelnden Prozessrechner, einen oder mehrere Submodule, die jeweils programm- und/oder schaltungstechnisch den Kommunikations- und Funktions-Ports zur bidirektionale Datenkommunikation und/oder zur Datenverarbeitung zwischengeordnet und zur Bedienung beziehungsweise Ansteuerung des oder der anzukoppelnden Prozessrechner, zu deren Konfiguration und/oder Diagnose nebst der von diesen beeinflussten technisch-physikalischen Prozessen über das oder die Funktions-Ports ausgebildet, und eine oder mehrere, auf der Basis einer Beschreibungs- oder Auszeichnungssprache, insbesondere XML (eXtensible Markup Language), programmierte Einrichtungen zur Annahme, Bestätigung und Verarbeitung von über das oder die Kommunikations-Ports empfangenen Auftragsdokumenten, die in der genannten Sprache beschrieben sind, wobei zur Ausführung der Auftragsdokumente beziehungsweise deren Umsetzung in Prozessrechner-Ansteuersignale das oder die Submodule jeweils mit der genannten Einrichtung integriert oder koppelbar oder gekoppelt sind.

Description

Prozessrechner-Schnittstelle auf der Basis einer Beschreibungs- oder Auszeichnungssprache, insbesondere XML
Die Erfindung betrifft eine universell einsetzbare Schnittstelle für Prozessrechner, die beispielsweise Regler oder Steuerungen elektrischer Antriebe sein können. Die Schnittstellte dient zur informationstechnischen bzw. kommunikativen Kopplung der Prozessrechner, Antriebsregler oder dergleichen mit sonstigen Rechnerknoten, welche beispielsweise Bedienterminals, Leitstands- und/oder Diagnoserechner, andere Prozessrechnerknoten oder hierarchisch übergeordnete Steuerungen sein können.
Aus einem zusammenfassenden Tagungsband zu dem im November 2001 in Nürnberg stattgefundenen Kongreß „SPS IPC-Drives" ist der Fachartikel „Info-Portal für anlagenübergreifende Prozessvisualisierung und -management via Internet" (Autoren: Andreas Kitzler und Werner Feiten) bekannt. Darin wird eine Kommunikationsstruktur vorgeschlagen, bei welcher mehrere, voneinander unabhängige Automatisieruπgssysteme, -zellen oder -anlagen über ein Informationsportal kombinierbar, überwachbar, visualisierbar und dergleichen sind. Auf das Informationsportal lässt sich über das Internet zugreifen. Die Kommunikation zwischen den Automatisierungszellen (sog. Supervisory Control And Data Acquisition - SCADA) einerseits und dem zentralen Webserver des Informationsportals andererseits erfolgt über Standard-Schnittstellen auf der Basis der erweiterbaren Auszeichnungssprache XML. Dazu ist jedes Automatisierungssystem mit einem sogenannten XML-Agenten zur Kommunikation mit dem Informationsportal auf der Basis von TCP-IP versehen. So soll ein Management über das Web verschiedene Automatisierungszellen bzw. SCADA- Systeme qualifiziert auswerten können. Allerdings müssen die einzelnen Sensordaten, bevor sie vom Informationsportal über das Web transportiert werden können, zunächst auf der für sie spezifischen Ebene gesammelt, dort aufbereitet und dem Informationsportal über die XML-Agenten zur Verfügung gestellt werden.
Aus der älteren internationalen Patentanmeldung PCT/EP2003/050 349 (WO2004/014 022) ist ein Rechnemetzwerk mit Diagnoserechnerknoten bekannt, welcher mit Prozessrechnerknoten, insbesondere Antriebsregler, über XML-basierte Kommunikationsschnittstellen (dort „Kommunikationsrechnerknoten" oder „Kommunikationsmodul" genannt) kommuniziert. Der Kommunikationsrechnerknoten ist mit einem Softwaremodul mit der Funktion eines Informations-Brokers für Parameter beschrieben, dessen Aufgabe die Bereitstellung einer XML-basierten Parameterschnittstelle für den Zugriff auf die Parameter des Prozessrechnerknotens ist. Als Protokoll kommt ein mit Hilfe eines XML-Schemas definiertes XML-basiertes Protokoll zum Einsatz, welches über TCP/IP mit einem Client des Rechnmetzwerks kommuniziert. Es sind die Funktionen des Lesens und Schreibens von Parametern von bzw. auf den Prozessrechπerknoten realisiert. Die vorliegende Erfindung setzt auf diese frühere angemeldete Erfindung auf und stellt eine weitere, gegebenenfalls verallgemeinernde Ausgestaltung der in der älteren Anmeldung als Kommunikationsrechnerknoten beschriebenen Prozessrechnerschnittstelle dar. Zur Offenbarung der vorliegenden Erfindung wird deshalb ergänzend auf den Kommunikationsrechnerknoten bzw. Kommunikationsmodul betreffenden Teil der älteren Anmeldung verwiesen. Die Offenbarung der älteren Anmeldung enthält allerdings nicht die Lehre, den Prozessrechner über universelle Ansteuerungen seiner Prozesskontrollfunktionen gleichsam zu „bedienen". Zudem sind keine Mechanismen aufgezeigt, welche für ausreichend Transparenz und Sicherheit bei der Übertragung der XML-Protokolle sorgen könnten.
Der Erfindung liegt die Aufgabe zugrunde, eine universelle Prozessrechner-, insbesondere Antriebsschnittstelle zu schaffen, welche für unterschiedliche Prozess- und Prozessrechnertechnologien anpassbar ist, bzw. die Prozessrechnerschnittstelle soll unabhängig von der im Prozessrechner und bei der Dateπ- Übertragungstechnologie gerade eingesetzten Technologie und Hardware sein.
Zur Lösung wird erfindungsgemäß die im Patentanspruch 1 angegebene Prozessrechner-Schnittstelle vorgeschlagen. Optionale Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Ansprüchen.
Mit der Verwendung von Auszeichnungssprachen, insbesondere der auf SGML (Standardized Generalized Markup Language) basierenden XML (eXtensible Markup Language) wird der Vorteil erzielt, dass sich - im Unterschied zu HTML - auch eigene Befehle vereinbaren lassen, gleichzeitig aber jedoch von moderner Webtechnologie und leicht und übersichlich zu bedienenden Benutzeroberflächen Gebrauch gemacht werden kann. Mit der Erfindung wird eine allgemein gültige Schnittstelle gebildet, mit der sich theoretisch jeder beliebige Prozessrechner und damit der davon kontrollierte technisch-physikalische Prozess, insbesondere elektrische Antriebsvorgänge steuern und bedienen läßt. Mit der erf dungsgemäßen funktionalen Schnittstelle lassen sich im zu kontrollierenden Prozess, einschließlich Datenverarbeitungsprozesse im Prozessrechner, ganze Abläufe auslösen, indem mit der Auszeichnungssprache aufbereitete Informationen oder beispielsweise XML-Protokolle nach Empfang in der Schnittstelle interpretiert werden. Bei einer Vielzahl miteinander zu synchronisierender, elektrischer Antriebe beispielsweise lässt sich ein einer Achse zugeordneter Regler mittels eines XML-Dokuments auf einen anderen Antrieb synchronisieren. Die Quellinformationen dafür stehen in dem als XML-Beschreibung von der Schnittstelle erhaltenen Auftrag. Mit der Erfindung lässt sich vom bisher eingefahrenen Weg, bestimmte Parameter wie Ruckbegrenzung oder Beschleunigung über irgendwelche Adressen bzw. ID-Nummern fest benennen zu müssen, aufgrund der erfindungsgemäßen Verwendung von Auszeichnungssprachen, insbesondere XML, abgehen.
Gemäß einer besonderen Erfindungsausbildung ist die Schnittstelle in XML formuliert, wobei - entsprechend einer Client Server-Architektur - zwischen dem Schnittstellen- Modul als Server und einem sonstigen Rechnerknoten als Client XML-Dokumente verwendet werden.
Damit über die Schnittstelle ein Zugang zu den Parametern des Prozessrechners, beispielsweise Antriebsreglers, gegeben ist, kann es zweckmäßig sein, die einen oder mehreren Funktionsports als Parameterschnittstelle auszubilden (siehe unten sowie Zeichnungen).
Nach einer weiteren vorteilhaften Ausbildung muss die er indungsgemäße Schnittstelle nicht zwangsläufig in dem Prozessrechner integriert sein. Sie kann auch als externes Softwaremodul auf einer beliebigen Hardware laufen, welche eine Kommunikationsverbindung zum Prozessrechner besitzt.
Weitere Einzelheiten, Merkmale, Merkmalskombinationen nebst Unterkombinationen, Vorteile und Wirkungen auf der Basis der Erfindung ergeben sich aus der nachfolgenden Beschreibung von beispielhaften Ausführungsformen der Erfindung und den Zeichnungen. Diese zeigen in: Figur 1 eine blockartige Darstellung internen Grundstruktur der erfindungsgemäßen Schnittstelle, Figur 2 anhand eines Zeitdiagramms die Vorwahl eines Betriebszustandes sowie dessen anschließende Aktivierung und Deaktivierung,
Figur 3 den zeitlichen Ablauf der Kommunikationsfolge im Betriebszustand „Speed-Mode" beim Beschleunigen und Bremsen eines elektrischen Antriebs,
Figur 4 den zeitlichen Kommunikationsablauf bei einer Veränderung der Lage des elektrischen Antriebs im Betriebszustand „Position- Mode",
Figur 5 den zeitlichen Kommunikationsablauf bei einem zyklischen Abonnement zu Diagnosezwecken,
Figur 6 den zeitlichen Kommunikationsablauf bei einem eventbasierten Abonnement zu Diagnosezwecken,
Figur 7 ein Blockschaltbild mit einem Signalfluss für eine Regler- Lebenszeichen-Überwachung mittels erfindungsgemäßer Schnittstelle,
Figur 8 eine schematische Ethemet-Netzstrul tur, worin die erfindungsgemäße Schnittstelle einsetzbar ist und
Figur 9 eine weitere interne Softwarestruktur der als Kommunikations-PC und XML-Server ausgeführten, erfindungsgemäßen Schnittstelle.
Gemäß Figur 1 können die Funktionalitäten der erfindungsgemäßen, für elektrische Antriebe gedachten Schnittstelle in die drei Submodule oder Teilbereiche „Bedienung", „Diagnose" und „Konfiguration" aufgeteilt werden. Der Antrieb kann sich aus einem Antriebsregler oder einer Antriebssteuerung, einem diesem nachgeschalteten Leistungsteil beispielsweise mit Leistungsverstärker und Strom- oder Umrichter, und einem Elektromotor zusammensetzen.
Funktionalitäten im Bereich „Bedienung"
Ziel des Bereichs beziehungsweise Submoduls „Bedienung" ist die Ansteuerung der Antriebsfunktionen. Die XML-Dokumente in diesem Bereich stellen alle antriebsspezifischen Funktionen zur Verfügung, die für den Betrieb des Antriebs im vorliegenden Anwendungsfall erforderlich sind.
Ein zugehöriges Softwaremodul enthält Zustandsautomaten, die den momentanen Zustand des Antriebs widerspiegeln und den Zustand des Antriebs durch die spezifizierten XML-Aufträge beeinflussen. Für die Kommunikation eines Client-Rechnerknotens mit dem Schnittstellen-Submodul „Bedienung" als Server wird eine Kommunikationsverbindung, beispielsweise TCP/IP- Socketverbindung; hergestellt, über die XML-Dokumente übertragen werden können. Optional können weitere parallele Versuche, eine Verbindung zum Submodul „Bedienung" aufzubauen, abgewiesen werden. Befindet sich der Antrieb in einem aktivierten Betriebszustand und wird die Verbindung zum Schnittstellen-Submodul „Bedienung" geplant oder ungeplant beendet, löst das Schnittstellen-Submodul am Client und/oder beispielsweise an einem Antriebsregler einen Kommunikationsfehler aus, der zu einer definierten Abschaltreaktion führt. Befindet sich der Antrieb in einem inaktiven Betriebszustand, löst ein Verbindungsabbau keine Fehlerreaktion aus.
Der Betriebszustaπd des Antriebs kann grundsätzlich in vier verschiedene Kategorien eingeteilt werden: Produktion, Rüsten, Service und Initialisierung. In jeder Kategorie gibt es verschiedene Betriebszustände, die gemäß Fig.2 durch jeweils einen XML- Auftrag vorgewählt und evtl. konfiguriert werden können. Mit Hilfe eines nachfolgenden Start/Stop-Auftrags kann der gewählte Betriebszustand aktiviert bzw. deaktiviert werden.
Wenn die dazugehörige Rückmeldung, OK oder eine Fehlernachricht, abgesetzt ist, bedeutet das, dass der Auftrag syntaktisch gültig ist und im momentanen Zustand des Antriebs zulässig ist. Alle Aufträge werden sequentiell verarbeitet. Erst danach werden weitere Aufträge angenommen.
Beim Ausführungsbeispiel ist der Betriebszustand vorzuwählen. Der XML-Auftrag „Auftrag" wird an das Schnittstellen-Submodul übermittelt und dessen erfolgreiche Abarbeitung durch die Rückantwort „OK" bestätigt. Damit ist der Betriebszustand vorgewählt. Er kann anschließend mit Hilfe der Aktivierungsnachricht „SW_Start" aktiviert werden. Die erfolgreiche Abarbeitung wird durch „OK" bestätigt. Analog kann der Betriebszustand durch „SW_STOP" deaktiviert werden.
Nachfolgend werden einige mögliche Betriebszustände des Antriebs sowie die dazugehörigen XML-Aufträge genannt. Weitere Betriebszustände sind je nach Anwendungsfall möglich:
Betriebszustand „ldle_Mode"
Nach dem Einschalten befindet sich der Regler im Initialisierungszustand „ldle_Mode". Hier ist keine Bewegung des Antriebs möglich. Mit Hilfe des XML- Auftrags „ldle_Mode" kann der Antrieb in den Initialisierungszustand zurückgesetzt werden. Der XML-Auftrag „ldle_Mode" wird vom Bedienungs-Submodul ( in Fig. 9 „Function-Manager" genannt) akzeptiert, sofern kein Fehlerzustand vorliegt und der vorherige Zustand deaktiviert worden ist. Befindet sich der Antrieb bereits im „ldle_Mode", wird ein nachfolgender Auftrag zum Wechsel in den „ldle_Mode" ignoriert. Im Gegensatz zu allen anderen Betriebszuständen braucht der Initialisierungszustand weder durch „SW_Start" aktiviert, noch durch „SW_Stop" deaktiviert werden.
XML-Auftrag „ldle_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für den XML-Auftrag , Jdle_ ode" -> <!- Autor: T. Tschaftary, 27.01.03 - <!- Version 1.0 -> <m_function xmlns:xs ="http://www.w3.org/2001 XMLSchema-inst4ϊnce" xmlns='<m_function_namesρ<ιce" xsd:schemaLocation="m_funotion_namespacel.xsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <reques > <Idle_Mode/> </request> < m function>
Antwort auf den XML-Auftrag „ldle_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für die XML-Antwort „Idle_Mode" ~> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 - <m_function xmlns:xsd- 'http://www.w3.org/2001 XMLSchema-instance" xmlns="m_function_namespace" xsd:schemaLocation="m_fimction_namespacel .xsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date> <time>09:l 3:24:126 time> </ sg-header> <response> <Idle_Mode> <Tdle_Mode> <Ok > oder <Error>000K Error> </Idle_Mode> </Idle_Mode> </response> < m function>
Betriebszustand „Follow-Mode"
Im Betriebszustand „Follow_Mode" befindet sich der Antrieb in einer an sich bekannten Folgeregelung. Der XML-Auftrag „Follow_Mode" wird vom Schnittstellen- Submodul „Bedienung" ateeptiert sofern kein Fehlerzustand vorliegt und der vorherige Zustand deaktiviert worden ist. Befindet sich der Antrieb bereits im „Follow_Mode" wird ein nachfolgender Auftrag zum Wechsel in den „Follow_Mode" ignoriert.
XML-Auftrag „Followjvlode":
<?xml veιsion="1.0" encoding=,cISO-8859-l"?> <!- Beispiel für den XML-Auftrag „Follow_Mode" — > <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_runction xmlns:xsd- 'http://www.w3.org/2001 XMLSchema-instance" xmlns="m_function_namespace" xsd:schemaLo∞tion="m_function_namespacel .xsd"> <msg-header> <drive>D001</drive> <date>27.01.03 date> <time>09:13:24:126</time> </msg-header> <request> <Follow_Mode/> </request < m_fünction>
Antwort auf den XML-Auftrag „Follow_Mode": <?xml version="1.0" encodmg='1SO-8859-l"?> <!- Beispiel für die XML-Antwort „Follow_Mode" -> <!- Autor: T. Tschaftary, 27.01.03 - <!- Version 1.0 -> <m_runction xmlns:xsd="http://www. w3.org/2001 XMLSchema-instance" xmlns="m_fünction_namespace" xsd:schemaLocation="m_function_naτnesρace 1.xsd"> <msg-header> <drive>D00K/drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <response> <Follow_Mode > < Follow_Mode > <Ok/> oder <Error>0001< Error> </ Follow_Mode > </ Follow_Mode > < response> </m function>
Betriebszustand „Speed_Mode"
Im Betriebszustand „Speed_Mode" befindet sich der Antrieb in einer Drehzahlregelung und beschleunigt auf eine vorgegebene Drehzahl.
Der XML-Auftrag „Speed_Mode" wird vom Bedienungs-Submodul beziehungsweise Function-Manager akzeptiert, sofern kein Fehlerzustand vorliegt und der vorherige Zustand deaktiviert worden ist. Befindet sich der Antrieb bereits im Zustand „Speed_Mode" und ist er aktiviert, kann mit nachfolgenden „Speed_Mode" Aufträgen die Drehgeschwindigkeit des Antriebs verändert werden. Die Abarbeitung der „Speed_Mode"-Aufträge erfolgt sequentiell. Fig. 3 zeigt ein Beispiel für das Beschleunigen und Bremsen im „Speed_Mode".
Dem XML-Auftrag „Speed_Mode" müssen folgende Daten übergeben werden:
a) Grundsätzlich werden numerische Werte mit 8 Stellen vor dem Komma (führende Nullen) und 4 Stellen hinter dem Komma dargestellt.
XML-Auftrag „Speed_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für den XML-Auftrag „Speed_Mode" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xrιύns:xsd- 'http://www.w3.org/2001/XMLSchema-instance" xmlns- 'm_function_namespace" xsd:schemaLocation="mjEiιnction_namespacel,xsd"> <msg-header> <drive>D00 l</drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <request> <Speed_Mode> <Velocity>2C Velocity> <Acceleration_max>l 0< Acce1eration_max > <Jerk_max>1000</ Jerk_max > </Speed_Mode> </reques > </τa function> Antwort auf den XML- Auftrag „Speed Mode" <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Antwort „Speed_Mode" <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org 2001/XMLSchema-instance" xmlns="m_function_namespace" xsd:schemaLocation="m_function_namespacel.xsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date> <time>09: 13:24: 126</time> </msg-header> <response <Speed_Mode> <Speed_Mode> <Ok > oder <Error>000K Error> </Sρeed_Mode> </Speed_Mode> </response> </m function>
Betriebszustand „Position Mode" Im Betriebszustand „Position_Mode" befindet sich der Antrieb in einer Lageregelung und fährt die vorgegebene Lage an.
Der XML-Auftrag „Position_Mode" wird vom Schnittstellen-Submodul „Bedienung" at<zeptiert, sofern kein Fehlerzustand vorliegt und der vorherige Zustand deaktiviert worden ist. Befindet sich der Antrieb bereits im Zustand „Position_Mode" und ist er al tiviert, kann mit nachfolgenden „Position_Mode" Aufträgen die Lage des Antriebs verändert werden. Die Abarbeitung der Position_Mode Aufträge erfolgt sequentiell. Das Zeitdiagramm gemäß Fig. 4 zeigt ein Beispiel für das Verändern der Lage im „Position_Mode".
Dem XML-Auftrag J,Position_Mode" müssen folgende Daten übergeben werden:
XML-Auftrag „Position_Mode": <?xml version="1.0" encoding="ISO-8859-l"? <!— Beispiel für den XML-Auftrag „PositkmJVfode" — > <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org/2001 XMLSchema-instance" xmlns="m_rαnction_namespace" xsd:schemaLocation="m_function_namespace 1.xsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date> <time>09: 13:24: 126</time> </msg-header> <request> <Position _Mode> <Mode>absolut</Mode> <Setposition>90</Setpositiori> <Direction_of_rotation>positive<Λ_)irection_of_rotation> <Velocity_max>10< Velocity_max> <Acceleration_max>l 0< Acceleration_max> < Position _M°de> </request> <Λn_function> 5 Antwort auf den XML-Auftrag Position_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Antwort „Position_Mode" — >0 <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org/2001/XMLSchema-instance" xmlns="m_fünction_namespace" 5 xsd:schemaLocation="rn_fünction_namespacel .xsd"> <msg-header> <drive>D001</drive> <date>27.01.03<7date>0 <time>09:13:24:126</time> </msg-header> <response> <Position _Mode> <Position _Mode>5 <Ok > oder <Error>0001</Error> ^Position _Mode> •Position Mode> </response> < m_function>0 Betriebszustand „Ref_Point Mode"
Im Betriebszustand „Ref_Point_Mode" führt der Antrieb vollautomatisch eine an sich bekannte Referenzpunktfahrt aus. Der XML-Auftrag „Ref_Point_Mode" wird vom Schnittstellen-Submodul „Bedienung"5 al zeptiert, sofern kein Fehlerzustand vorliegt und der vorherige Zustand deaktiviert worden ist. Befindet sich der Antrieb bereits im „Ref_Point_Mode wird ein nachfolgender Auftrag zum Wechsel in den „Ref_Point_Mode" ignoriert. Dem XML-Auftrag „Ref_Point__Mode" müssen folgende Daten übergeben werden:
< vorhanden ist, oder falls kein Geber mit Absolutschπittstelle eingesetzt wird. 3 Dieses Tag ist nur relevant, falls ein Getriebe zwischen Geber und Mechanik vorhanden ist, oder falls kein Geber mit Absolutschnittstelle eingesetzt wird.
XML-Auftrag „Ref_Point_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für den XML-Auftrag „ ef_Point_Mode" - <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org2001/XMLSchema-instance" xrnlns="m_function_na espace" xsd:schemaLocation="m_function_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <request> <Ref_Point_Mode> <Axis>ιubber_cylinder<VΑxis> <Velocity_max>l 0</Velocity_max> <Acceleration_max>10</Acceleration_max> </Ref_Point_Mode> </request> </m_function> Antwort auf den XML-Auftrag „Ref_Point_Mode": <?xml version="1.0" encoding='lSO-8859-l"?> <!- Beispiel für die XML-Antwort „Ref_Point_Mode" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xrnlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xmlns="m_function_namespace" xsd:schemaLocation="m_function_namespacel.xsd"> <msg-header> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <response> <Ref_Point_Mode> < Ref_Point_Mode > <Ok > oder <Error>0001</Error> </ Ref_Point_Mode > </ Ref_Point_Mode > </response> </m function>
Betriebszustand „Notch_Position_Mode"
Im Betriebszustand „Notch_Position_Mode" führt der Antrieb vollautomatisch eine Rastwinkelfahrt aus.
Der XML-Auftrag „Notch_Position_Mode" wird vom Schnittstellenmodul „Bedienung" al zeptiert, sofern kein Fehlerzustand vorliegt und der vorherige Zustand deaktiviert worden ist. Befindet sich der Antrieb bereits im „Notch_Position_Mode", wird ein nachfolgender Auftrag zum Wechsel in den „Notch_Position_Mode" ignoriert. XML-Auftrag „Notch_Position_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für den XML-Auftrag ,J fotch_Position_Mode" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!~ Version 1.0 -> <m_function xrnlns:xsd="http://www.w3.org 2001/XMLSchema-inst∞ce" xmlns— im_fünction_niamespace" xsd:schemaLocation- 'm_function_namespacel .xsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date <time>09:13:24:126</time> </msg-header> <request> <Notch_Position_Mode/> </request> </m_function>
Antwort auf den XML-Auftrag „Notch_Position_Mode": <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Antwort „Notch_Position_Mode" — > <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www.w3.org 2001/XMLSchema-instance" xmlns="m_fimction_namespace" xsd:schemaLocation="m_runction_namespacel.xsd"> <msg-header> <drive>D001</drive> <date 27.01.03</date> <time>09:13:24:126 /time> </msg-header> <response> <Notch_Position_Mode> <Notch_Position _Mode > <Ok > oder <Error>0001< Error> </Notch_Position _Mode> < Notch_Position _Mode> </response> < m_function>
Allgemeine XML-Nachrichten
Das Aktivierungs-Kommando „SW_Start"
Mit Hilfe des Aktivierungs-Kommandos 1,SW_Start" kann ein vorgewählter Betriebszustand aktiviert werden. Aktivierungs-Kommando „SW_Start":
<?xml version="1.0" encoding="ISO-8859-l"? <!- Beispiel für das Aktivierungs-Kommando "SW_Start" — > <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org 2001/XMLSchema-instance" xmlns— 'm_functionjnamespace" xsd:schemaLocaü^n- 'mJunction_narnespaceLxsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <request> <SW_Start/> </request> < m_function>
Antwort auf das Aktivierungskommando „SW_Start: <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für die XML-Antwort „SW_Start" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlnsrxsd- 'http://www.w3.org/2001/XMLSchema-instance" xmlns="m_function_namespace" xsd:schemaLocation="m_function_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <response> < SW_Start> < SW_Start> <Ok/> oder <Error>000 K/Error> / SW_Start > < SW Start > </response> </m function>
Das Deaktivierungs-Kommando „SW_Stop"
Mit Hilfe des Deaktivierungs-Kommandos „SW_Stop" kann ein aktivierter Betriebszustand deaktiviert werden. Befindet sich der Antrieb nicht im aktivierten Zustand wird eine Fehlermeldung generiert. Mit diesem Kommando können folgende Stop-Vorgänge gesteuert werden: - <Mode>="controller_off": Der Regler wird sofort ausgeschaltet, der Antrieb wird drehmomentenfrei und trudelt aus. In diesem Fall ist der Parameter <Acceleration_max> optional. - <Mode>="controller_orf_at_standstiH": Der Regler wird mit der Bremsrampe <Acceleration_max> bis Stillstand abgebremst und anschließend ausgeschaltet. - <Mode>="controller_on": Der Regler wird mit der Bremsrampe <Acceleration_max> bis Stillstand abgebremst und bleibt eingeschaltet.
Dem Deaktivierungs-Kommando „SW_Stop" müssen folgende Daten übergeben werden:
Deaktivierungs-Kommando „SW_Stop": <?xml version="1.0" encoding='TSO-8859-l"?> <!— Beispiel für das Deaktivierungs-Kommando "SW_Stop" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org/2001/XMLSchema-instance" xmlns=''m_function_namespace" xsd:schemaLocation="m_function_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <request> <SW_Stop> <Mode>controller_on< Mode> <Acceleration_max>20</Acceleration_max> </SW_Stop> </request> < m_fimction>
Antwort auf das Deaktivierungskommando „SW_Stop: <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für das Deaktivierungs-Kommando „SW Stop" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd="http://www. w3.org/2001 XMLSchema-inst4ance" xmlns="m_function_namesρace" xsd:schemaLocation="m_function_namespace 1.xsd"> <msg-header> <drive>D001</drive> <date>27.01.03</date> <time>09:13:24:126</time> </msg-header> <response> < SW_Stop > < SW_Stop > <Ok/ oder <Error>000K/Error> / SW_Stop > </ SW Stop > </response> </m_fiιnction>
Das Bestätigungs-Kommando „SW_Acknowledge"
Das Bestätigungs-Kommando „SW_Acknowledge" dient zum Bestätigen aller Warnungen, die vom Antrieb gesendet werden. Ein „SW_Acknowledge" wird vom Function-Manager nicht bestätigt. Bestätigungs-Kommando „SW_Acknowledge":
<?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für das Bestätigungs-Kommando "SW_Acknowledge" -> <!- Autor: T. Tschaftary, 27.01.03 -> <!- Version 1.0 -> <m_function xmlns:xsd- 'http://www.w3.org/2001/XMLSchema-instance" xmlns="mj£unction_naιnespace" xsd: schemaLocation="m_fünction_namespace 1 ,xsd"> <msg-header> <drive>D00K/drive> <date>27.01.03</date> <time>09:13:24:126</time> < msg-header> <request> < SW_Acknowledge/> </request> </m function>
Funktionalitäten im Bereich „Diagnose"
Ziel des Bereichs oder Submoduls „Diagnose" ist die Bereitstellung von Informationen zur Antriebsdiagnose.
Der Client (beispielsweise Leitstandsprozess) kann aus den vom Antrieb zur Verfügung gestellten Informationen eine Gruppierung von beliebigen Informationen abonnieren. Diese werden dann in einem konfigurierbarem Zeitintervall oder bei Änderung an den Leitstandsprozess übertragen.
Für jedes Abonnement wird eine eigene Kommunikations-Verbindung zum Schnittstellenmodul „Diagnose" aufgebaut. Die maximale Anzahl von gleichzeitig laufenden Abonnements am Schnittstellenmodul „Diagnose" ist begrenzt. Die nachstehende beispielhafte Tabelle zeigt Beispiele für die vom Schnittstellenmodul „Diagnose" gelieferten Informationen.
Tabelle: Vom Antrieb zur Verfügung gestellte Informationen (Beispiel)
Das Schnittstellen-Submodul „Diagnose" kann die Diagnoseinformationen auf zwei verschiedene Arten versenden: Zyklisches Abonnement und Eventbasiertes Abonnement.
Zyklisches Abonnement
Im Modus „Zyklisches Abonnement" werden die abonnierten Informationen in fest definierten Zeitabständen an den Client gesendet. Hier spielt es keine Rolle, ob sie sich seit dem letzten Abfragezeitpunkt geändert haben. Fig. 5 zeigt den Kommunikationsablauf bei einem zyklischen Abonnement. Nach erfolgreichem Herstellen der Verbindung wird das Abonnement durch eine „Subscription Request"- Nachricht beauftragt. Nach erfolgreicher Verarbeitung des Auftrags wird sofort eine Daten Nachricht „Data" verschickt. Danach werden die Daten in einem vorgegebenen Zeitraster versendet. Eine „Subscription Cancel"-Nachricht beendet das Abonnement und die Kommunikationsverbindung.
XML-Auftrag zum Beauftragen eines zyklischen Abonnements: <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für den XML-Auftrag „Subscription_Request_Cyclic" — > <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xrrüns:xsd="http://www.w3.org/2001/XMLSchema-instance" xmlns="m_subscriρtion_naτnesρace" xsd:schemaLocation="m_subscriptioη_namespacel.xsd"> <msg-header <drive>D00K/drive> <date>28.01.03</date> <time>10:27:46:395</time> < msg-header> <request> <Subscription_Request_Cycliθ <Refresh_Time>500< Reftesh_Time> <Data> <Active_Mode/> <!- Beispiele aus Tabelle 3-1 <Error_No > <Error_Type/> <Error Index/>
< Data> Subscription_Request_Cyclic > </requesO < m_subscription>
Antwort auf den XML-Auftrag „Subscription_Request_Cyclic": <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Antwort „Subscription_Request_Cyclic" — > <!~ Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xmlns:xsd="http://www. w3.org 2001 XMLSchema-instance" xmlns="m_subscription_namespace" xsd:schemaLocation="m_subscription_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>28.01.03</date> <time>10:27:46:395</time> </msg-header> <response> <Subscription_Request_CycliO <Subscription_Request_Cyclic> <Ok/> oder <Eιror>ErrorNo0001</Error> </Subscription_Request_Cycliθ </Subscription_Request_Cyc1ic> < response> < m_subscription>
XML-Auftrag zum Versenden der Daten in einem zyklischen Abonnement: <?xml version="l .0" encoding="ISO-8859-l"?> <!— Beispiel für den XML-Auftrag „Subscription_Data_Cyclic" -> <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscriρtion xmlns:xsd="httρ://www.w3.org/2001/XMLSchema-instoce" xmlns="m_subscription_n,amespace" xsd:schemaLocation="m_subscription_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>28.01.03 date> <time>10:27:46:395</time> </msg-header> <request> <Subscription_Data_Cyclic> <Data> <Active_Mode <!- Beispiele aus Tabelle 3-1 -!> <Value>Follow_Mode< Value> ^Active Modo <Error_No> <Value>0</Value> < Error_No> <Error_Type> <Value>no_type</Value> </Error_Type> <Error_Index> <Value>no_index< Value> </Error Index>
< Data> </Subscription_Data_Cyclic> </request < m_subscription>
XML-Auftrag zum Beenden eines zyklischen Abonnements: <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für den XML-Auftrag „Subscription_Cancel" — > <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xmlns:xsd="http://www. w3.org/2001/XMLSchema-instance" xmlns="m_subscription_namespace" xsd:schemaLocation="m_subscription_namespace1.xsd"> <msg-header> <drive>DO0K/drive> <date>28.01.03</date> <time>10:27:46:395</time> </msg-header> <requesr> </Subscription_Cancel> </request> <Λn_subscription>
XML-Antwort auf den XML-Auftrag „Subscription_Cancel": <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Antwort „Subscription_Cancel" — > <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xmlns:xsd="http://www. w3.org/2001/XMLSchema-instance" xmlns="m_subscription_namespace" xsd:schemaLocation- 'm_subscription_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>28.01.03</date> <time>l 0:27:46:395</time> </msg-header> <response> <Subscription_Cancel> < Subscription_Cancel> <Ok > oder <Error>ErrorNo0001< Error> </Subscription> </ Subscription_Cancel> </response> m_subscription>
Eventbasiertes Abonnement Im Modus „Eventbasiertes Abonnement" werden die abonnierten Informationen nur bei Änderung übertragen, jedoch nicht öfter als eine konfigurierbare Zeitspanne. Damit geringfügige Schwankungen bei numerischen Werten nicht zu einem ständigen Nachrichtenversand führen, werden die Daten nur gesendet, falls sie mehr als eine interne Toleranzschwelle vom letzten Wert abweichen. Die Fig 6 zeigt den Kommunikationsablauf bei einem eventbasierten Abonnement. Nach erfolgreichem Herstellen der Verbindung wird das Abonnement durch eine „Subscription_Request_Event"-Nachricht beauftragt. Nach erfolgreicher Verarbeitung des Auftrags wird sofort eine Daten Nachricht „Data" verschickt. Danach werden die Daten nur bei Änderung von einem oder mehrerer abonnierter Parameter verschickt - maximal jedoch mit der in <Refresh_Time> angegebenen Frequenz.
Zusätzlich zu den Werten der Parameter wird beim eventbasierten Abonnement ein Änderungskennzeichen (change_flag) übertragen, das anzeigt, ob sich ein Parameter gegenüber der letzten Nachricht verändert hat.
XML-Auftrag zum Beauftragen eines eventbasierten Abonnements: <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für den XML-Auftrag „Subscription_Request_Event" — > <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xmlns:xsd="http://www. w3.org 2001/XMLSchema-instance" xmlns="m_subscription_namespace" xsd:schemaLocation="m_subscription_namespacel.xsd"> <msg-header> <drive>D001</drive> <date>28.01.03</date> <time>10:27:46:395</time> </msg-header> <request> <Subscription_Request_Event> <Refresh_Time>500</Refresh_Time> <Data> <Active_Mode/> <!— Beispiele aus Tabelle 3-1 — !> <Error_No/> <Error_Type^ <Error_lndex/> </Data> < Subscription_Request_Event> </reques£> < m_subscription> Antwort auf den XML-Auftrag „Subscription_Request_Event": <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für die XML-Antwort „Subscription_Request_Event" -> <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xmlns:xsd="http://www.w3.org 2001/XMLSchema-instance" xmlns="m_subscription_n<Ηnespace" xsd:schemaLocation- 'm_subscription_namespace 1.xsd"> <msg-header> <drive>D00K/drive> <date>28.01.03</date> <time>10:27:46:395</time> < msg-header> <response> <Subscription_Request_Event> <Subscription_Request_Event> <Ok > oder <Error>ErrorNo0001< Error> </Subscription_Request_Event> </Subscription_Request_Event> </response> < m_subscripti on>
XML-Nachricht zum Versenden der Daten in einem eventbasierten Abonnement: <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Nachricht „Subscription_Data_Event" — > <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 -> <m_subscription xmlns:xsd- 'http://www.w3.org/2001/XMLSchema-inst.ance" xmlns="m_subscription_namespace" xsd:schemaLocation="m_subscription_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>28.01.03</date> <time>10:27:46:395</time> </msg-header> <requesf> <Subscription_Data_Event> <Data> <Active_Mode> <!— Beispiele aus Tabelle 3-1 -!> <Value>Follow_Mode</Value> <Change_Flag>True<Change_F1ag> < Active_Mode> <Error_No> <Value>0< Value> <Change_FIag>False<Change_Flag> < Error_No> <Error_Type> <Value>no_type</Value> <Change_Flag>False<Change_Flag> < Error_Type> <Error_Index> <Value>no_index</Value> <Change_Flag>False<Change_Flag> </Error Index> Data> </Subscription_Data_Event> </xequest> </m_subscription>
XML-Auftrag zum Beenden eines zyklischen Abonnements: <?xm1 version="l .0" encoding="lSO-8859-l "7> <!— Beispiel für den XML-Auftrag „Subscription_Cancel" -> <!- Autor: T. Tschaftary, 28.01.03 -> <!- Version 1.0 --> <m_subscription xmlns:xsd- 'http://www.w3,org/2001/XMLSchema-instance" xmlns="m_subscription_namespace" xsd:schemaLocation="m_subscription_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>28.01.03</date> <time>l 0:27:46:395</time> < msg-header> <requesf> </Subscription_Cancel> </request> </m_subscription>
Funktionalitäten im Bereich „Konfiguration" Ziel des Bereichs „Konfiguration" ist die Bereitstellung von Funktionen, mit deren Hilfe ein Antrieb konfiguriert werden kann. Mit Hilfe von XML-Dokumenten sollen allen für den Betrieb eines Antriebs notwendigen Konfigurationen eingestellt werden können.
Im Folgenden werden beispielhaft einige Funktionen genannt:
• Motor konfigurieren • Leistungsteil konfigurieren • Geber konfigurieren • Regelung konfigurieren • Filter konfigurieren
Spezifikation der XML-Schnittstelle des Life-Check-Managers
Der Life-Check-Manager stellt sicher, dass die Kommunikation zwischen dem Leitstandsprozess und dem MDS-Regler funktionsfähig ist. Ein Zusammenbruch der Kommunikationsverbindung sowie ein Ausfall der beteiligten Geräte kann so erkannt werden. Zwischen dem Leitstandsprozess und dem MDS-Regler werden Lebenszeichennachrichten ausgetauscht. Der Life-Check-Manager empfängt die Lebenszeichennachrichten vom Leitstandsprozess und gibt die Information an den MDS-Regler weiter. Dieser sendet eine Rückmeldung an den Life-Check-Manager. Die Rückmeldung wird in eine XML-Lebenszeichennachricht verpackt und an den Leitstandsprozess geschickt. Fig. 7 zeigt den Signalfluss der Lebenszeichennachrichten.
Der MDS-Regler überwacht, ob er regelmäßig ein Life_Check-Telegramm vom XML- Server gesendet bekommt. Fällt das Telegramm aufgrund einer Kommunikationsstörung oder dem Ausfall des XML-Servers oder Leitstandsprozesses aus, bringt der MDS-Regler den Antrieb in einen sicheren Zustand und meldet einen Fehler. Als Lebenszeichen für den MDS-Regler dient die Antwort auf das Life_Check- Telegramm, das an den XML-Server geschickt wird. Bleibt die Antwort aufgrund einer Kommunikationsstörung oder eines Ausfalls des MDS-Reglers aus, wird auch keine Life_Check_Response-Nachricht an den Leitstandsprozess verschickt. Dieser kann somit den Ausfall des MDS-Reglers oder die Kommunikationsstörung bemerken und geeignet darauf reagieren. Fällt der XML-Server aus, werden keine Lebenszeichennachrichten weitergeleitet. Sowohl der Leitstandsprozess als auch der MDS-Regler können reagieren und den Antrieb in einen sicheren Zustand bringen.
Als Lebenszeichennachricht werden numerische Werte verwendet, die vom Leitstandsprozess an den XML-Server für diesen verständlich nach den Vorgaben des Anwenders verschickt werden. Der numerische Wert wird bis zum MDS-Regler durchgereicht und in der Life_Check_Response-Nachricht an den Leitstandsprozess zurückgeschickt. Dieser prüft, ob der empfangene Wert gleich dem gesendeten ist, und inkrementiert den nächsten zu verschickenden Wert um 1. Die Lebenszeichenüberwachung kann mit Hilfe einer Konfigurationsnachricht „Life_Check_lnitialize" konfiguriert werden. Hier muss die Zeitspanne durch eine Steuerung definiert und verbindlich dem XML-Server vorgegeben werden (<Timeout> in Millisekunden), nach der der MDS-Regler bei einem Ausfall des Lebenszeichen vom XML-Server bzw. Leitstandsprozess reagiert. Zusätzlich kann die Reaktion auf einen Ausfall des Lebenszeichens in verschiedenen Betriebszuständen konfiguriert werden. Für die Reaktion gelten die im Zusammenhang mit dem Deaktivierungs-Kommando „SW_Stop" aufgeführten Stop-Vorgänge. Zur einfacheren Bedienung ist ein Default- Verhalten vorgesehen, das für alle nicht explizit in der Konfigurationsnachricht aufgeführten Betriebszustände gilt.
XML-Auftrag „Life_Check_lnitialize" für die Konfiguration der Lebenszeichenüberwachung:
<?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für den XML-Auftrag „Life_Check_Initidize" -> <!- Autor: T. Tschaftary, 29.01.03 -> <!- Version 1.0 -> <m_life_check xmlns:xsd="http://www. w3.org/2001 XMLSchema-instance" xmlns="m_life_check_niimespace" xsd:schemaLocation="m_life_check_namespacel.xsd" <msg-header> <drive>DO0 K/drive> <date>29.01.03</date> <time l 1 : 10:21 :674 /time> </msg-header> <request> <Life_Check_Initialize> <Timeout>500</Timeout> <Error_Reaction> <Speed_Mode> <Mode>controller_off<Mode/> <Sρeed_Mode> <default> <Mode>controller_off_at_stand_still<Mode/> <Acceleration_max>30</Acceleration_max> </default> </Error_Reaction> < Life_Check_Initialize> </requesr </m_life_check> Antwort auf den XML-Auftrag „Life_CheckJnitialize": <?xml version="1.0" encoding="ISO-8859-l"?> <!- Beispiel für die XML-Antwort „Life_Check Initialize" -> <!- Autor: T. Tschaftary, 29.01.03 -> <!- Version 1.0 -> <m_life_check xmlns:xsd="http://www. w3.org/2001/XMLSchema-instance" xmlns="m_life_check_namespace" xsd:schemaLocation="m life_check_namespacel .xsd"> <msg-header> <drive>D00K/drive> <date>29.01.03</date> <time>ll:10:21:674</time> </msg-header> <response> <Life_Check_Initialize> < Life_Check_Initialize > <0sJ> oder <Error^ErrorNo0001< Eτror> <l Life_Check_Initialize > <l Life_Check_Mtialize > /response> </m_live_check>
XML-Nachricht zur Weiterleitung des Lebenszeichen: <?xml version="1.0" encoding='1SO-8859-l"?> <!- Beispiel für den XML-Auftrag ,,Life_Check_Msg" -> <!- Autor: T. Tschaftary, 29.01.03 -> <!- Version 1.0 -> <m_life_check xmlns:xsd="http://www. w3.org 2001/XMLSchema-instance" xmlns="m_life_check_namespace" xsd:schemaLocation="m_life_check_namespacel .xsd"> <msg-header> <drive>D001</drive> <date>29.01.03< date> <time>ll:10:21:674</time> </msg-header> <request> <Life_Check_Msg>5< Life_Check_Msg> </request> </m life check>
Antwort auf den XML-Auftrag „Life_Check_Msg": <?xml version="1.0" encoding="ISO-8859-l"?> <!— Beispiel für die XML-Antwort „Life_Check_Msg" — > <!- Autor: T. Tschaftary, 29.01.03 -> <!- Version 1.0 -> <m_life_check xmlns:xsd="http://www. w3.org/2001 XMLSchema-instance" xmlns="m_life_check_namespace" xsd:schemaLocation="m_life_check_namespacel.xsd"> <msg-header> <drive>D00K/drive> <date>29.01.03</date> <time>l 1:10:21 :674</time> </msg-header> <response> <Life_Check_Msg>5</Life_Check_Msg> </response> </m live check>
Die Fig. 8 zeigt schematisch eine Netzstruktur mit Ethernet als ein mögliches Einsatzbeispiel für die erfindungsgemäße Antriebsschnittstelle. Durch den Einsatz von Switches zwischen einem Teilnetzen mit Leitstand und einem Teilnetz mit Antriebsregler MDS.G-Drive und erfindungsgemäßen XML-Server kann eine gegenseitige Beeinflussung minimiert werden. Vor jedem Antriebs-Regler ist zumindest logisch, was die Kommunikation in XML betrifft, ein externer XML-Server geschaltet. Alternativ ist die Konzentration der XML-Server auf einen PC möglich. Am Kommunikationsablauf ändert sich dadurch nichts.
Die Funktion des XML-Servers kann im Antriebsregler G-Drive oder im sonstigen Antrieb integriert sein, so dass die zusätzlich benötigte Ethemetverbindung und Rechnerhardware entfällt.
Die Fig. 9 zeigt die für die XML-Schnittstelle beziehungsweise -Server relevanten Softwaremodule in der Ausführung als Kommunikations-PC. Für die Kommunikation mit der Steuerung stehen die drei Server „Function-Manager", „Subscription-Manager" und „Life-Check-Manager" an einem bestimmten TCP-Port zur Verfügung, die über ein XML-basiertes Protokoll angesprochen werden können. Die Spezifikation des XML- basierten Protokolls der drei Server, sowie der dazugehörigen Kommunikationsabläufe gehen aus obigen Ausführungen hervor. Zusätzlich werden die vom Diagnosesystem Baudis benötigten Daten sowie Log-Nachrichten durch den XML-Server bereitgestellt.
Bezugszeichenliste
MDS - Antriebsregler
G-Drive - Antriebsregler mit baulich integriertem Schnittstellenserver Baudis - Diagnoserechnerknoten

Claims

Patentansprüche
1. Schnittstelle für Prozessrechner, insbesondere Regler oder Steuerungen ele-ktrischer Antriebe, zu deren informationstechnischer Kopplung mit sonstigen Rechnerknoten, beispielsweise Bedienterminal, Leitstands- und/oder Diagnose- Rechner, Internet-Clients, andere Prozessrechnerknoten oder übergeordnete Steuerungen, welche Schnittstelle folgendes aufweist: einen oder mehrere, dem oder den sonstigen Rechnerknoten zugeordnete Kommunikations-Ports, einen oder mehrere Funktions-Ports für den oder die anzukoppelnden Prozessrechner, einen oder mehrere Submodule, die jeweils programm- und/oder schaltungstechnisch den Kommunikations- und Funktions-Ports zur bidirektionale Datenkommunikation und/oder zur Datenverarbeitung zwischengeordnet und zur Bedienung beziehungsweise Ansteuerung des oder der anzukoppelnden Prozessrechner, zu deren Konfiguration und/oder Diagnose nebst der von diesen beeinflussten technisch-physikalischen Prozessen über das oder die Funktions-Ports ausgebildet, und eine oder mehrere, auf der Basis einer Beschreibungs- oder Auszeichnungssprache, insbesondere XML (eXtensible Markup Language), programmierte Einrichtungen zur Annahme, Bestätigung und Verarbeitung von über das oder die Kommunikations-Ports empfangenen Auftragsdokumenten, die in der genannten Sprache beschrieben sind, wobei zur Ausführung der Auftragsdokumente beziehungsweise deren Umsetzung in Prozessrechner-Ansteuersignale das oder die Submodule jeweils mit der genannten Einrichtung integriert oder koppelbar oder gekoppelt sind.
2. Schnittstelle nach Anspruch 1 , dadurch gekennzeichnet, dass das oder die Kommunikations-Ports über Protokolle der TCP/IP-Familie, einschließlich UDP/IP, vorzugsweise auf der Basis des Ethernet ausgebildet sind,
3. Schnittstelle nach Anspruch 1 oder 2, gekennzeichnet durch die Implementierung eines oder mehrerer Zustandsautomaten, die programm- und/oder schaltungstechnisch zur Widerspiegelung des momentanen Betriebszustands des Prozessrechnerknotens und/oder eines letzterem zugeordneten technisch-physikalischen Prozesses eingerichtet und mit der genannten Einrichtung zur Annahme, Bestätigung und Verarbeitung von Auftragsdokumenten gekoppelt oder integriert sind, um den Betriebszustand entsprechend dem Auftragsdokument zu beeinflussen.
4. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass in der Einrichtung zur Annahme, Bestätigung und Verarbeitung von Auftragsdokumenten die Vorwahl eines Betriebszustandes für den Prozessrechner implementiert ist.
5. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass in der Einrichtung zur Annahme, Bestätigung und Verarbeitung von Auftragsdokumenten die Ausführung eines Aktivierungs- Kommandos zur Aktivierung eines Betriebszustandes des Prozessrechnerknotens und/oder des von ihm beeinflussten technischphysikalischen Prozesses implementiert ist.
6. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass in der Einrichtung zur Annahme, Bestätigung und Verarbeitung von Auftragsdokumenten die Ausführung eines Deaktivierungs- Kommandos zur Deaktivierung eines Betriebszustandes des Prozessrechnerknotens und/oder des von ihm beeinflussten technischphysikalischen Prozesses implementiert ist.
7. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das oder die Submodule zur sequentiellen Verarbeitung eingegangener Auftragsdokumente jeweils mit anschließender Bestätigung ausgebildet sind.
8. Schnittstelle nach einem der vorangehenden Ansprüche, gekennzeichnet durch eine Realisierung als Stand-Alone-Kommunikationsrechnerknoten oder als mittels Soft- und/oder Firmware realisiertes Kommunikationsmodul zum Ablauf auf der Hardware eines oder mehrerer der sonstigen Rechnerknoten.
9. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Kommunikationsport zur Ausführung von Protokollen ausgebildet ist, die mit einer Beschreibungs- oder Auszeichnungssprache, insbesondere XML (eXtensible Markup Language), realisiert sind.
10. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Funktions-Port zum Arbeiten mit einer seriellen Kommunikationsverbindung zu einem oder mehreren Prozessrechnerknoten ausgebildet ist.
11. Schnittstelle nach einem der vorangehenden Ansprüche, gekennzeichnet durch eine Ausbildung als Zusatzbaukomponente und/oder Zusatz-Softwaremodul für einen jeweiligen Prozessrechnerknoten oder eine bauliche Integration mit einem Prozessrechnerknoten.
12. Schnittstelle nach einem der vorangehenden Ansprüche, gekennzeichnet durch eine Einrichtung oder Programmierung des oder der Submodule derart, dass sie zumindest zeitweise als Server gegenüber den sonstigen, dann Client bildenden Rechnerknoten dienen.
13. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass ein Diagnose-Submodul als Server zur Erlangung und Bereitstellung von Prozessdiagnosedaten derart ausgebildet ist, dass letztere von einem anfordernden Clieπt-Rechnerknoten aus gruppierbar sind und in vom Client aus einstellbaren Zeitintervallen an den Client gesendet werden.
14. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass ein Diagnose-Submodul als Server zur Erlangung und Bereitstellung von Prozessdiagnosedaten derart ausgebildet ist, dass letztere von einem anfordernden Client-Rechnerknoten aus gruppierbar sind und nur bei Eintritt von deren Änderung übertragen werden, jedoch nicht öfter als nach von einem sonstigen, Client bildenden Rechnerknoten aus einstellbaren Zeitintervallen.
15. Schnittstelle nach Anspruch 14, gekennzeichnet durch eine Einstellung des Diagnose-Submoduls derart, dass Prozessdaten nur bei Abweichung um eine voreingestellte Toleranzschwelle gesendet werden.
16. Schnittstelle nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zur Ausfallerkennung der Komunikationsverbindung mit sonstigen Rechnerknoten einer der Submodule zum Empfang, zur Konvertierung und anschließenden Weiterleitung von Auftragsdokumenten an den oder die zugeordneten Prozessrechner sowie zum Empfang von Reaktionssignalen des oder der Prozessrechner und deren Umsetzung in ein oder mehrere Rückmeldungsdokumente an den oder die sonstigen Rechnerknoten ausgebildet ist.
EP04766806A 2003-09-16 2004-09-16 Prozessrechner-schnittstelle auf der basis einer beschreibungs- oder auszeichnungssprache, insbesondere xml Withdrawn EP1664947A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10343123 2003-09-16
PCT/EP2004/052198 WO2005029208A2 (de) 2003-09-16 2004-09-16 Prozessrechner-schnittstelle auf der basis einer beschreibungs- oder auszeichnungssprache, insbesondere xml

Publications (1)

Publication Number Publication Date
EP1664947A2 true EP1664947A2 (de) 2006-06-07

Family

ID=34352920

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04766806A Withdrawn EP1664947A2 (de) 2003-09-16 2004-09-16 Prozessrechner-schnittstelle auf der basis einer beschreibungs- oder auszeichnungssprache, insbesondere xml

Country Status (2)

Country Link
EP (1) EP1664947A2 (de)
WO (1) WO2005029208A2 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1806637A1 (de) * 2005-12-12 2007-07-11 Siemens Aktiengesellschaft Verfahren zum Betrieb eines Automatisierungsgerätes und Automatisierungsgerät

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999019782A1 (en) * 1997-10-13 1999-04-22 Rosemount Inc. Communication technique for field devices in industrial processes
DE20004400U1 (de) * 2000-03-09 2001-07-19 Cooper Power Tools GmbH & Co., 73463 Westhausen Betriebsnetzwerksystem

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2005029208A8 (de) 2006-05-18
WO2005029208A2 (de) 2005-03-31
WO2005029208A3 (de) 2005-11-17

Similar Documents

Publication Publication Date Title
EP1305930B1 (de) System und verfahren zur übertragung von opc-daten über datennetze, insbesondere internet, mit asynchroner datenverbindung
EP3353610B2 (de) Verbindungseinheit, überwachungssystem und verfahren zum betreiben eines automatisierungssystems
EP1527554B1 (de) Rechnernetzwerk mit diagnoserechnerknoten
EP1436677B1 (de) Verfahren zur inbetriebnahme eines bedien- und beobachtungssystems von feldgeräten
EP3648416B1 (de) Automatisierungsgerät mit integrierter netzwerk-analyse und cloud-anbindung
EP3632052B1 (de) Moduleinheit zum verbinden eines datenbusteilnehmers
DE3236812A1 (de) Fernwirksystem
DE10211939A1 (de) Kopplungsvorrichtung zum Ankoppeln von Geräten an ein Bussystem
EP1221075A1 (de) Vorrichtung zum steuern von sicherheitskritischen prozessen
DE10304903A1 (de) Vorrichtung zur Automatisierung und/oder Steuerung von Werkzeug- oder Produktionsmaschinen
WO2000045563A1 (de) System und verfahren zum bedienen und beobachten eines automatisierungssystems über internet mit asymmetrischer internetverbindung
EP1283632A2 (de) Verfahren und Anordnung zur Übertragung von Daten
WO2007128836A1 (de) Bediengerät zum informationsaustausch mit einem feldgerät in einem automatisierungssystem
EP2203821B1 (de) Verfahren zur sicheren datenübertragung und gerät
EP3100121B1 (de) Verfahren und vorrichtung zum sicheren abschalten einer elektrischen last
EP2099164B1 (de) Sicherheitsvorrichtung zur sicheren Ansteuerung angeschlossener Aktoren
EP3528064B1 (de) Steuerungssystem und zugehöriges verfahren zur inbetriebnahme, steuerung und überwachung für stromversorgungskomponenten
EP3122016A1 (de) Automatisierungsnetzwerk und verfahren zur überwachung der sicherheit der übertragung von datenpaketen
DE10112843A1 (de) System und Verfahren zur Verteilung von Automatisierungsdaten (Automation Data Distrubution, abgekürzt: ADD)
EP2075655A1 (de) Sicherheitssteuerung
EP2913727B1 (de) Verfahren zur Übermittlung von Nachrichten über ein Rückwandbus-System eines modularen industriellen Automatisierungsgeräts
EP1664947A2 (de) Prozessrechner-schnittstelle auf der basis einer beschreibungs- oder auszeichnungssprache, insbesondere xml
EP1353246B1 (de) Sicherheitsschalteranordnung
WO2004055610A1 (de) System und verfahren zur überwachung von technischen anlagen und objekten
EP1690390B1 (de) Verfahren zur übertragung von daten über einen datenbus sowie system und gateway zur durchführung des verfahrens

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

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: TSCHAFTARY, THOMAS

Inventor name: MEIS, HAROLD

Inventor name: KRAUS, GUNTHER

Inventor name: MONSE, MATHIAS

R17D Deferred search report published (corrected)

Effective date: 20060302

R17D Deferred search report published (corrected)

Effective date: 20060518

DAX Request for extension of the european patent (deleted)
R17D Deferred search report published (corrected)

Effective date: 20060302

R17D Deferred search report published (corrected)

Effective date: 20060518

17Q First examination report despatched

Effective date: 20070315

17Q First examination report despatched

Effective date: 20070315

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