-
Die
Erfindung betrifft ein Verfahren zur Generierung eines Systems zur
Bereitstellung von Diagnoseinformationen sowie ein solches System.
-
Die
DE 100 08 020 A1 beschreibt
eine Diagnosevorrichtung in einem Prozesssteuersystem, das Mehrgrößen-Regeltechniken
verwendet, wobei ein Diagnosetool automatisch Daten, die einen Steuerungsparameter,
einen Modusparameter, einen Statusparameter und einen Grenzwertparameter
angeben, die jeder der unterschiedlichen Einrichtungen, Kreise oder
Funktionsblöcke
innerhalb eines Prozesssteuersystems zugehörig sind, erfasst und speichert,
die erfassten Daten verarbeitet, um zu bestimmen, welche Einrichtungen,
Kreise oder Funktionsblöcke
Probleme haben, die zu einer verringerten Leistung des Prozesssteuersystems
führen,
eine Liste von erfassten Problemen einer Bedienungsperson anzeigt
und anschließend
die Verwendung von weiteren, spezifischeren Diagnosetools vorschlägt, um die
Probleme weiter einzugrenzen oder zu korrigieren.
-
Der
Erfindung liegt die Aufgabe zugrunde, die Bereitstellung von Informationen
zur Diagnose von technischen Anlagen oder technischen Prozessen
zu vereinfachen.
-
Diese
Aufgabe wird durch ein Verfahren zur Generierung eines Systems zur
Bereitstellung von Diagnoseinformationen gelöst, bei welchem Verfahren Komponenten
eines Automatisierungssystems, welche Diagnoseschnittstellen zur
Bereitstellung von Diagnoseinformationen zur Diagnose der jeweiligen Komponente
aufweisen, in mindestens einer Gruppe zusammengefasst werden und
die Bereitstellung von Diagnoseinformationen der jeweiligen Gruppe
durch Verknüpfung
der Diagnoseinformationen der in der jeweiligen Gruppe zusammengefassten
Komponenten vorgesehen wird.
-
Diese
Aufgabe wird durch ein System zur Bereitstellung von Diagnoseinformationen
gelöst,
mit in mindestens einer Gruppe zusammengefassten Komponenten eines
Automatisierungssystems, welche Diagnoseschnittstellen zur Bereitstellung
von Diagnoseinformationen zur Diagnose der jeweiligen Komponente
aufweisen, wobei Mittel zur Bereitstellung von Diagnoseinformationen
der jeweiligen Gruppe durch Verknüpfung der Diagnoseinformationen der
in der jeweiligen Gruppe zusammengefassten Komponenten vorgesehen
sind.
-
Der
Erfindung liegt die Erkenntnis zugrunde, dass der Anteil verteilter,
komponentenbasierter Automatisierungssysteme zunimmt und damit die
Notwendigkeit besteht, diese Systeme bei Störungen diagnostizieren zu können. Diese
Diagnose darf sich dabei nicht nur auf einzelne Automatisierungskomponenten
beschränken,
sondern muss es ermöglichen,
das ganze Automatisierungssystem bzw. seine Subsysteme untersuchen
zu können
und dies möglichst
mit einem einheitlichen, durchgängigen
Bedienparadigma. Der Engineering-Aufwand für die Erstellung einer anlagenweiten
Diagnose für
ein verteiltes Automatisierungssystem ist üblicherweise sehr hoch, auch
dadurch bedingt, dass das Diagnosesystem bisher speziell für eine bestimmte
Anlage erstellt werden musste. Die Diagnose verteilter Automatisierungslösungen zielt
bisher in der Regel auf die Diagnose einzelner Komponenten ab (z.
B. wird die Diagnose-Software mit der jeweiligen Hardware-Komponente
mitgeliefert) oder ist nur durch aufwändige Projektierung für die jeweilige
Anlage herstellbar. Diese Projektierung wird üblicherweise anhand des Anlagenlayouts
(Papierausdruck) und der Funktionsbeschreibung der Anlage manuell
von Automatisierungsspezialisten erstellt. Daher unterscheidet sich bisher
die Diagnose einer Komponente (Diagnosetool wird vom Komponentenhersteller
geliefert) von der Diagnose der Anlage (wird vom Anlagenhersteller
geliefert). Die Erfindung ermöglicht
sowohl eine komponentenbasierte Diagnose als auch gleichzeitig eine
Diagnose von Komponenten umfassenden Gruppen. Eine Gruppe wird im
Folgenden auch als Subsystem oder Diagnose-Subsystem bezeichnet. Die Bereitstellung
der Diagnoseinformationen der Gruppen kann dabei durch Verknüpfung der
Diagnoseinformationen der in der jeweiligen Gruppe zusammengefassten
Komponenten erfolgen. Diese bietet insbesondere die Möglichkeit,
das System zur Bereitstellung von Diagnoseinformationen bzw. die Bereitstellung
von Diagnoseinformationen automatisch zu generieren. Der Engineering-Aufwand
zur Erstellung eines Diagnosesystems wird so erheblich reduziert.
-
Wie
beschrieben stellt die Erfindung einen Zugriffsweg auf die Komponentendiagnose
bereit. Andererseits bietet die Erfindung auch die Möglichkeit
der Anlagendiagnose, wobei die Anlagendiagnose einerseits auf einem
höheren
Abstraktionslevel als die Komponentendiagnose aufsetzt, andererseits aber
auf die Komponentendiagnose aufbaut. Gemäß einer vorteilhaften Ausgestaltung
der Erfindung werden in mindestens einer übergeordneten Gruppe untergeordnete
Gruppen bzw. untergeordnete Gruppen und Komponenten zusammengefasst,
wobei die Generierung von Diagnoseinformationen der jeweiligen übergeordneten
Gruppe durch Verknüpfung
der Diagnoseinformationen der in der jeweiligen übergeordneten Gruppe zusammengefassten
Gruppen bzw. Komponenten vorgesehen ist. Auf der obersten Ebene
der so entstehenden Diagnosehierarchie steht das Diagnosesystem
der Anlage bzw. des Prozesses, die somit aus Gruppen bzw. Diagnose-Subsystemen
zusammengesetzt ist, wobei diese Diagnose-Subsysteme weitere Diagnose-Subsysteme
beinhalten können.
Es entsteht ein selbstähnliches,
ein fraktales System. Insbesondere umfasst die Fraktalität, dass
die Anlagenbeschreibung wie die Komponentenbeschreibung auf denselben
Schnittstellen basiert und somit durch vorhandene, für die Komponentendiagnose
entwickelte Diagnose-Tools bzw. durch deren Weiterentwicklungen
unmittelbar verarbeitet werden kann. Das ermöglicht eine einheitliche, durchgängige Bedienung,
eine Reduzierung der Kosten für
Anlagen-Diagnosetool-Entwicklung und Weiterentwicklung.
-
Vorteilhaft
ist, wenn die Schnittstellen der Automatisierungskomponenten, z.
B. durch eine Spezifikation der PROFInet Webintegration, standardisiert beschrieben
sind. Durch die standardisierten Schnittstellen der Komponenten,
die auch Diagnosefunktionalität
beinhalten, kann ein Regelsystem jeweils für eine Gruppe von Komponenten
durch die Verknüpfung
mit den Layoutinformationen ein vollständiges Diagnosesystem erzeugen.
Dabei stützt
sich die Diagnosefunktion eines Subsystems auf die standardisierten
Diagnosefunktionen der enthaltenen Automatisierungskomponenten.
-
Gemäß einer
weiteren vorteilhaften Ausgestaltung der Erfindung sind die Komponenten
Bestandteile eines Anlagenlayouts und erfolgt die Verknüpfung der
Diagnoseinformationen in Abhängigkeit von
im Anlagenlayout enthaltenen Informationen. Eine Aufgabe der Anlagendiagnose
ist die Erkennung von Fehlern, die aus dem Zusammenspiel der Komponenten
der Anlage entstehen. Der Anlagenhersteller definiert das Zusammenspiel
der Komponenten durch die Layoutplanung der Anlage. Die vorgeschlagene
Ausgestaltung der Erfindung ermöglicht es,
eine Anlagendiagnose aus dem während
der Anlagen-Planungsphase erstellten digitalen Anlagenlayout per
automatischer Generierung abzuleiten. Dies führt neben einer Verkürzung der
Engineering-Zeiten auch zu einer Reduzierung der Fehlerwahrscheinlichkeit
bei der Erstellung des Diagnosesystems. Es wird somit ein neuartiges
Verfahren vorgeschlagen, das es ermöglicht, aus Layout-Informationen
ein Diagnosesystem für
ein insbesondere verteiltes Automatisierungssystem inklusive seiner Komponenten
automatisch abzuleiten, wobei dieses System das Merkmal der Fraktalität hinsichtlich
seiner Diagnose-Funktionen
aufweist.
-
Die
Anlagenkomponenten werden im Anlagenlayout in logisch zusammengehörige Gruppen, sogenannte „Diagnose-Subsysteme", zusammengefasst.
Dieser Vorgang kann z. B. der Festlegung der in der Planungsphase
oft zu definierenden technologischen Hierarchie entsprechen. In
diesem Fall entfällt
eine spezifi sche Definition einer Hierarchie von Diagnose-Subsystemen
auf der Basis des Layouts. Ex ante müssen aber die Diagnose-Subsysteme nicht
mit den für
die Betriebsführung
erforderlichen Elementen der technologischen Hierarchie (Teilanlagen,
Units,...) deckungsgleich sein, insbesondere können völlig andere Aspekte, z. B.
Lokalität,
die Strukturierung der Diagnose-Hierarchie bestimmen. Diese Diagnose-Subsysteme
kapseln die darin enthaltenen Automatisierungskomponenten und verringern
somit die Komplexität
der Diagnose des Gesamtsystems. Gemäß einer weiteren vorteilhaften Ausgestaltung
der Erfindung werden auch Aufgaben und Vernetzung der Komponenten
durch das Anlagenlayout vorgegeben.
-
Vorteilhafterweise
ist die Zusammengehörigkeit
der Gruppen zur übergeordneten
Gruppe, d. h. von Diagnose-Subsystemen zur nächsthöheren Hierarchieebene, ebenfalls
im Anlagenlayout definierbar. Das entspricht dem Zusammenfassen
zusammengehöriger
Diagnose-Subsysteme zu einem kapselndem Diagnose-Subsystem auf höherer Ebene.
-
Gemäß einer
weiteren vorteilhaften Ausgestaltung der Erfindung sind die Diagnoseinformationen
semantisch gleichartig aufgebaut. Auf der Grundlage der in dem Anlagen-Layout
definierten Diagnose-Hierarchie kann für alle Elemente der Hierarchie
automatisch eine semantisch gleichartige Diagnose-Funktion generiert
werden. Diese basiert auf folgendem Prinzip: Die generierte Diagnosefunktion einer
Komponente überprüft beim
Aufruf den eigenen Status. Je nach Ergebnis meldet die Diagnosefunktion
einen Fehler inkl. Beschreibung. Auf der Ebene der nächsthöheren Ebene überprüft die generierte Diagnosefunktion
z. B. eines Subsystens den eigenen Status und ruft die Diagnosefunktion
der zugehörigen
Komponente auf. Abhängig
von den erhaltenen Werten meldet die Diagnosefunktion gegebenenfalls einen
Fehler mit Beschreibung. Damit besitzen auch die rein logischen
Diagnose-Subsysteme eine Diagnosefunktion. Dieses Prinzip wird rekursiv
bis zur obersten Ebene angewendet, d. h. die Diagnosefunktion eines
Diagnose- Subsystems
wird so ausgeprägt, dass
sie die Diagnosefunktionen der jeweils direkt unterlagerten Subsysteme
aufruft. Neben dieser Propagierung von Diagnose-Funktionsaufrufen
von einer höheren
Ebene zur jeweils untergeordneten Ebene der Diagnose-Hierarchie
kann im Sinne der Induktion unter Einbeziehung der Anlagenlogik
höherwertige
Diagnosefunktionalität
automatisch generiert werden.
-
Vorteilhafterweise
enthalten die Diagnoseinformationen Funktionen, welche Eingangsgrößen verknüpfen – insbesondere
logisch verknüpfen – und mindestens
eine Ausgangsgröße als Ergebnis
der Verknüpfung
der Eingangsgrößen bereitstellen.
Die anwendbare Anlagen- oder Systemlogik lässt sich dabei in zwei Kategorien
einteilen. „Single
Level Logic" bildet
die Logik eines Elements der Diagnose-Hierarchie ab. Dabei werden
interne Informationen des jeweiligen Elements verknüpft. „Multi
Level Logic" bildet
die Logik eines Subsystems aufbauend auf den unterlagerten, „darin
enthaltenen" Elementen ab.
Beim rekursiven Generieren der Diagnosefunktionen (diese sind z.
B. als Script ausgeprägt)
fließen dann
die Regeln in die Ausprägung
der Diagnosefunktionen ein. Im Falle der Single Level Logic werden
die definierten Regeln direkt in die Diagnosefunktion aufgenommen.
Im Falle der Multi Level Logic wird anhand des Anlagenlayouts ermittelt,
welche Regel im gegebenen Fall einzusetzen ist, da die Multi Level
Logic aus dem Zusammenspiel verschiedener Komponenten entsteht.
Es werden somit Diagnoseinformationen durch rekursive Anwendung
eines Regelsystem generiert, das standardisierte Diagnoseschnittstellen
mit Layoutinformationen verknüpft.
-
Für beide
Kategorien können
Konsistenz-Regeln („constraints") definiert werden
bzw. als Typeigenschaft der verwendeten Komponenten- oder auch Subsystemklassen
bereits vorhanden sein. Diese Regeln werden bei Anwendung der Erfindung
in der Regel als Teil einer Komponente (z. B. als sogenannte Facette)
oder Diagnose-Subsystems (z. B. bei Wiederverwendung der Planungsinformation von
Teilen älterer
Anlagen) bereits vorhanden sein. Gemäß einer weiteren vorteilhaften
Ausgestaltung der Erfindung werden den Komponenten und den Gruppen
Klassen zugeordnet, welche Funktionen und Eigenschaften der jeweiligen
Komponente bzw. Gruppe festlegen. Die Definition von Geräteklassen (bezogen
auf Komponenten und Subsysteme) mit festgelegten Funktionen und
Eigenschaften kann Grundlage für
das Erstellen von Single und Multi Level Logic sein. Durch Anwendung
der inhärenten bzw.
darauf aufbauenden Regeln und unter Einbeziehung des Anlagenlayouts
kann wie oben skizziert automatisch Diagnosefunktionalität abgeleitet
und generiert werden. Die Regeln können aufgrund der Fraktalität rekursiv
angewendet werden und damit, von kleineren Komponentengruppen ausgehend,
ein Diagnosesystem für
die ganze Anlage aufgebaut werden.
-
Die
Erfindung kann vorteilhafterweise eingesetzt werden zur Bereitstellung
von Diagnoseinformationen in einem verteilten, komponentenbasierten Automatisierungssystem.
Es wird somit insbesondere ein Verfahren für die automatische Generierung
eines funktionsfraktalen Anlagen-Diagnosesystems für ein verteiltes,
komponentenbasiertes Automatisierungssystem aus Layout-Informationen
vorgeschlagen.
-
Wenn
gemäß einer
weiteren vorteilhaften Ausgestaltung der Erfindung die Komponenten
PROFInet-Komponenten sind, wird die Automatisierungsfunktionalität von sogenannten
RTAutos erbracht, so dass Diagnose-Subsysteme auf unterster Ebene
die zugehörigen
RTAutos kapseln.
-
Vorteilhafterweise
sind Mittel zur Visualisierung der Diagnoseinformationen auf Basis
des Anlagenlayouts vorgesehen. Es wird vorgeschlagen das erfindungsgemäße System
zur Diagnose einer technischen Anlage oder eines technischen Prozesses zu
verwenden.
-
Nachfolgend
wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben
und erläutert.
-
Es
zeigen:
-
1 ein System zur Bereitstellung
von Diagnoseinformationen,
-
2 eine aus dem Anlagenlayout
abgeleitete logische Diagnosehierarchie,
-
3 den Ablauf der Generierung
von Diagnoseinformationen,
-
4 eine Diagnose-Script-Funktion,
-
5 im Anlagenlayout enthaltene
Informationen,
-
6 die Fraktalität der Diagnosefunktionalität,
-
7 die Planung eines Anlagenlayouts
mit einem CAD-System,
-
8 ein Diagnose-Netz aus
dem Anlagenlayout,
-
9 den Engineering Workflow
und
-
10 die Visualisierung von
Diagnoseinformationen.
-
1 zeigt ein System zur Bereitstellung von
Diagnoseinformationen. Ein Automatisierungssystem 5 weist
Komponenten 4 auf, welche Diagnoseschnittstellen zur Bereitstellung
von Diagnoseinformationen 1 zur Diagnose der jeweiligen
Diagnose 4 aufweisen. Die Komponenten 4 sind im
Beispielsfall in zwei Gruppen 6 zusammengefasst. Das System weist
Mittel zur Bereitstellung von Diagnoseinformationen 2 der
jeweiligen Grup pe 6 durch Verknüpfung der Diagnoseinformationen 1 der
in der jeweiligen Gruppe 6 zusammengefassten Komponenten 4 auf. Die
beiden Gruppen 6 und eine weitere Komponente 4 sind
in einer übergeordneten
Gruppe 7 zusammengefasst. Diagnoseinformationen 3 der übergeordneten
Gruppe 7 werden durch Verknüpfung der Diagnoseinformationen 1, 2 der
in der übergeordneten Gruppe 7 zusammengefassten
Gruppen 6 bzw. Komponente 4 generiert. Das System
wird im Beispielsfall verwendet zur Diagnose eines technischen Prozesses 8.
Das Automatisierungssystem 5 dient zur Automatisierung
des technischen Prozesses 8.
-
2 zeigt eine aus einem Anlagenlayout abgeleitete
logische Diagnosehierarchie am Beispiel PROFInet (genauere Erläuterung
der PROFInet-Technologie weiter unten). Eine Anlage 10 ist
in so genannte Physical Device-Objekte P aufgeteilt (auch PDev genannt).
PROFInet definiert ein Runtime-Objektmodell, das jedes PROFInet-Gerät implementieren
muss. Dabei wird jedes der Objekte des Objektmodells üblicherweise
durch ein COM-Objekt realisiert. Die Objekte im Einzelnen sind:
das Physical Device-Objekt P, welches das Gerät als Ganzes repräsentiert.
Es dient als Einstiegspunkt für
andere Geräte,
d. h. der erstmalige Kontakt mit einem PROFInet-Gerät geht über dieses
Objekt. Das Physical Device-Objekt P stellt die physikalischen Eigenschaften
der jeweiligen Komponente dar. Auf jeder Hardware-Komponente (z.
B. SPS, Antrieb, PC) existiert genau eine Instanz des Physical Device-Objekts
P. Das Logical Device-Objekt L (auch LDev genannt) repräsentiert
die Ablaufumgebung, in welcher das Anwenderprogramm abgearbeitet
wird. Die Unterscheidung zwischen Physical und Logical Device-Objekt
P bzw. L ist bei embedded Geräten
im Allgemeinen unnötig,
bei Runtime-Systemen ist diese Unterscheidung jedoch wichtig, da
z. B. zwei Soft SPS auf einem PC ablaufen können. Der PC ist in diesem
Fall das Physical Device, die Soft SPS jeweils ein Logical Device.
Das Logical Device-Objekt L besitzt Interfaces zur Abfrage des Betriebszustandes,
Uhrzeit, Sammel- und Detaildiagnose. So genannte Runtime-Automatisierungsobjekte
A (auch RT-Auto genannt) repräsentieren
die eigentliche technologische Funktionalität des Geräts. Die Interfaces der Objekte sind
somit abhängig
von der Aufgabe, die das Objekt erfüllt. Ein Interface kann sowohl
Daten (lesend und schreibend) als auch Methoden und Events enthalten.
Die konkreten Eigenschaften eines PROFInet-Geräts werden durch eine XML-Datei
beschrieben. Diese Gerätebeschreibung
enthält
für die
unterschiedlichen Objekte eines PROFInet-Gerätes deren Interfaces, die darin
enthaltenen Methoden und Daten. Damit kann insbesondere die durch
das Runtime-Automatisierungsobjekt A repräsentierte technische Funktionalität eines
Geräts
auf einfachste Art und Weise beschrieben werden. Auf der Grundlage der
in einem Anlagenlayout definierten Diagnosehierarchie wird für alle Elemente
der Hierarchie automatisch eine semantisch gleichartige Diagnose-Funktion
generiert. Am Beispiel PROFInet wird im Folgenden das Prinzip dargestellt.
Eine generierte Diagnosefunktion eines Logical Device-Objekts L überprüft beim
Aufruf den eigenen Status. Je nach Ergebnis meldet die Diagnosefunktion
einen Fehler inklusive Beschreibung. Auf der Ebene der Runtime-Automatisierungsobjekte
A überprüft die generierte
Diagnosefunktion den Status des jeweiligen Objekts und ruft die
Diagnosefunktion des zugehörigen
Logical Device-Objekts L auf. Abhängig von den erhaltenen Werten
bildet die Diagnosefunktion ggf. eine Fehlermeldung mit Beschreibung.
Auf der untersten Ebene der Diagnose-Subsysteme S ruft die generierte Diagnosefunktion
eines Subsystems S die Diagnosefunktionen der unterlagerten Runtime-Automatisierungsobjekte
A auf. Damit besitzen auch die rein logischen Subsysteme S eine
Diagnosefunktion. Dieses System wird rekursiv bis zur obersten Ebene 11 angewendet,
d. h. die Diagnosefunktion eines Diagnose-Subsystems S wird so ausgeprägt, dass
sie die Diagnosefunktionen der jeweils direkt unterlagerten Subsysteme
S aufruft. Neben dieser Propagierung von Diagnose-Funktionsaufrufen
von einer höheren Ebene
zur jeweils untergeordneten Ebene der Diagnosehierarchie kann im
Sinne der Induktion unter Einbeziehung der Anlagenlogik höherwertige
Diagnosefunktionalität
automatisch generiert werden.
-
Das
Layout der Anlage, d. h. die topologische Anordnung der Komponenten
des verteilten Automatisierungssystems wird üblicherweise in der Planungsphase
einer Anlage erzeugt. Dabei wird auch eine technologisch bedingte,
hierarchische Gliederung der Gesamtanlage in Teilanlagen, Maschinen usw.
vorgenommen (auch als Gliederung in „Subsysteme" bezeichnet). Im
Folgenden wird unterstellt, dass diese technologisch begründeten Subsysteme mit
den Diagnose-Subsystemen deckungsgleich sind. 2 verdeutlicht anhand eines Anlagenlayouts
die Aufteilung der Gesamtanlage in Subsysteme.
-
3 zeigt den Ablauf der Generierung
von Diagnoseinformationen 17, 26. Die anwendbare
Anlagen- oder Systemlogik lässt
sich in zwei Kategorien einteilen. Single Level Logic bildet die
Logik genau eines Elements 12 der Diagnosehierarchie ab.
Dabei werden interne Informationen 14 des Elements 12 verknüpft. So
besagt z. B. die Logik eines Subsystems der Klasse 13 „Tor", dass ein Systemfehler
vorliegt, wenn das Tor (z. B. aufgrund eines defekten Sensors) "AUF=1" und "ZU=1" meldet. Diese logische
Regel 15 wird in einem automatischen Generierungsschritt 16 in
einer Diagnoseinformation 17, z. B. ein Diagnose-Script,
umgesetzt.
-
So
genannte Multi Level Logic bildet die Logik eines Subsystems aufbauend
auf den unterlagerten, darin enthaltenen Elementen 18 bzw. 21 ab.
Enthält
ein Subsystem z. B. ein Element 21 der Klasse 22 „Durchflussmesser" und ein zweites
Element 18 der Klasse 19 „Ventil", so liegt ein Systemfehler vor, wenn
das Element 21 einen „Durchfluss > 0" meldet, während das zweite Element 18 die
Stellung „geschlossen" meldet. Die Eigenschaften
der Elemente 18, 21 sind mit den Bezugszeichen 20 bzw. 23 gekennzeichnet.
Wie in den Beispielen können
für beide
Kategorien Konsistenzregeln (Constraints) definiert werden bzw.
als Typeigenschaft der verwendeten Komponenten- oder auch Subsystemklassen bereits
vorhanden sein. Diese Regeln werden bei Anwendung der Erfindung
in der Regel als Teil einer Komponente (z. B. als Facette) oder
Diagnose-Subsystems (z. B. bei Wiederverwendung der Planungsinformation
von Teilen älterer
Anlagen) bereits vorhanden sein. Beim rekursiven Generieren der
Diagnosefunktionen (diese z. B. als Script ausgeprägt) fließen dann
die Regeln in die Ausprägung
der Diagnosefunktionen ein. Im Falle der Single Level Logic werden
die definierten Regeln direkt in die Diagnosefunktion aufgenommen,
in 3 die Diagnosefunktion 17.
Im Falle der Multi Level Logic wird anhand des Anlagenlayouts ermittelt,
welche Regel im gegebenen Fall einzusetzen ist, da die Multi Level
Logic aus dem Zusammenspiel verschiedener Komponenten entsteht.
-
4 zeigt ein Beispiel einer
Diagnoseinformation, welche als Diagnose-Scriptfunktion ausgeführt ist.
-
5 zeigt die im Anlagenlayout
enthaltenen Informationen. Im Ausführungsbeispiel gemäß 5 sind im Anlagenlayout
Informationen über PROFInet-Komponenten 30, über die
hierarchische Struktur 31 aus Diagnosesicht und über generische Diagnosefunktionen 32 enthalten.
-
Grundlage
für das
Erstellen von Single und Multi Level Logic ist die Definition von
Geräteklassen (Komponenten
und Subsystemen) mit festgelegten Funktionen und Eigenschaften.
Durch Anwendung der inhärenten
bzw. darauf aufbauenden Regeln und unter Einbeziehung des Anlagenlayout
kann wie oben skizziert automatisch Diagnosefunktionalität generiert
und abgeleitet werden.
-
6 zeigt die Fraktalität der Diagnosefunktionalität. Die schließlich entstandene
Diagnosehierarchie weist somit aus Anlagensicht das Merkmal der Selbstähnlichkeit
(Fraktalität)
auf. Das heisst, dass alle Elemente der Hierarchie über semantisch
gleiche, selbstähnliche
Diagnosefunktionalität 38, 40 verfügen. Dies
schließt
auch Subsysteme 35 ein, obwohl diese rein logischen Elemente
durch keine reale Automatisie rungskomponente 36 repräsentiert
werden. Dabei können
alle für
die automatische Generierung nötigen
Informationen aus dem Anlagenlayout 37, 42 abgeleitet
werden. Im Einzelnen sind dies die eingesetzten (z. B. PROFInet-)Komponenten 36,
die Zusammenfassung dieser Komponenten 36 zu Subsystemen 35 und
die weitere Diagnosehierarchie bis zur Anlagenebene. Im Anlagenlayout 37, 42 enthaltene
Informationen dienen dabei zur Generierung von Regeln 39 bzw. 41 zur
Diagnose von Komponenten 36 bzw. Subsystemen 35,
mit Hilfe von Diagnosefunktionen 38 bzw. 40.
-
7 zeigt die Planung eines
Anlagenlayouts mit einem CAD-System.
Hier wird ein Subsystem entweder durch die Definition der baumartigen Anlagenstruktur
(Knoten ist ein Subsystem, Blätter sind
Anlagenkomponenten oder wieder Subsystem-Knoten) oder durch Aggregation
definiert. Bei einem üblicherweise
zur Planung eines Anlagenlayouts verwendeten CAD-System kann die
Definition von Subsystemen zur Diagnose z. B. durch Markieren der
zu einem Subsystem gehörenden
Komponenten erfolgen. In 6 werden
die zu einem Subsystem gehörenden
Komponenten z. B. durch das Zeichnen eines die Komponenten einschließenden Polygons
(„Lasso") definiert. Dabei
kann ein Polygon weitere Polygone vollständig umschließen. Diese eingebetteten
Polygone entsprechen dann der visuellen Definition unterlagerter
Diagnose-Subsysteme.
-
8 zeigt ein aus dem Anlagenlayout
erzeugtes Diagnosenetz. Das Anlagenlayout beinhaltet bereits alle
für die
weiteren Schritte der Generierung eines Systems zur Bereitstellung
von Diagnoseinformationen nötigen
Informationen, wie z. B. die Zuordnung von Runtime-Automatisierungsobjekten 47 zu Komponenten 45 und
damit zu Subsystemen 48. Die in der Planungsphase hantierten
Komponenten besitzen neben einer topologischen Sicht (Anordnung in
der Anlage, Abmaße,
Form, etc.) auch eine Diagnosesicht. Die Verbindung der Diagnosesicht
der Komponenten mit der Hierarchie ermöglicht wie oben beschrieben
die automatische Generierung von Diagnosefunktio nalität. Aufbauend
auf der Diagnosesicht der Komponenten lassen sich in einem ersten Schritt
Diagnosefunktionen für
die umschließenden Subsysteme
generieren. Daraus werden im zweiten Schritt rekursiv Diagnosefunktionen
für weitere
Subsysteme bis hin zur Anlagenebene generiert. In die generierten
Diagnosefunktionen fließen
die für
die jeweilige Hierarchieebene bereits vorhandenen (z. B. als Klasseneigenschaft
einer Komponente) oder explizit benannten Konsistenzregeln für die Single
bzw. Multi Level Logic ein.
-
9 zeigt den Engineering
Workflow zur Generierung eines Systems zur Bereitstellung von Diagnoseinformationen.
Ausgehend von einem Anlagenlayout 50 wird automatisch in
einem mit dem Bezugszeichen 51 bezeichneten Schritt ein
XML Config File 52 erzeugt. Dieses XML-Dokument enthält die im Anlagenlayout 50 enthaltenen
Informationen über eingesetzte
PROFInet-Komponenten,
die hierarchische Struktur (Subsysteme) sowie die automatisch generierten
Diagnosefunktionen in Form von Scriptfunktionen. Das XML Config
File 52 wird z. B. von einem Anlagen-Diagnose-Server 53 geladen
und verarbeitet. Der Anlagen-Diagnose-Server 53 ist danach in
der Lage, alle Diagnose-Scriptfunktionen
auszuführen
und somit die Anlage, Subsysteme und Komponenten zu diagnostizieren.
-
10 zeigt eine prototpyische
Visualisierung aufbauend auf einem Anlagen-Diagnose-Server. Die
gezeigte Visualisierung basiert auf einem Konzept, das Grafikkomponenten
mit den Diagnose-Subsystemen verbindet und es damit ermöglicht, Störungen eines
Subsystems in der Anlagengrafik anzuzeigen. Die Implementierung
besteht aus dem Anlagen-Diagnose-Server und einer Client-Anwendung
für Visualisierungszwecke.
Die Kommunikation zwischen Client und Server erfolgt mittels Webservices
und basiert auf dem HTTP-Protokoll. Sowohl Server als auch Client
können
in einer Vielzahl unterschiedlicher Anlagen eingesetzt werden, ohne
dass Anpassungen erforderlich werden, da der Server mittels des
die nötigen
Informationen enthaltenen XML-Dokuments initialisiert wird.
-
Der
hier beschriebene Ansatz bietet nicht nur die Möglichkeit der automatischen
Generierung der Diagnosefunktionalität und damit eine erhebliche Verkürzung des
erforderlichen Engineeringaufwands, sondern zudem den Vorteil eines
durchgängigen
Diagnosekonzepts. Dieses durchgängige
Diagnosekonzept beschränkt
sich dabei nicht auf die Komponentendiagnose, sondern verringert
durch die Bildung von Subsystemen mit Diagnosefunktionalität die Komplexität der Gesamtanlage
vor allem für
den Anlagenbediener.
-
Die
Verknüpfung
der Anlagentopologie mit der daraus regelbasiert abgeleiteten Diagnosehierarchie
der Subsysteme kann auch dafür
genutzt werden, eine Diagnoseoberfläche gemäß 10 direkt abzuleiten. Die gestörten Komponenten
und die sie umschließenden
Subsysteme im Layout können
z. B. durch farbliche Markierungen hervorgehoben werden. Dies kann
auch entsprechend in der Baumdarstellung erfolgen, z. B. rekursiv
von der gestörten Komponente
beginnend aufwärts
bis zum Anlagenknoten. Durch die direkte Anwahl der im Layout als gestört markierten
Komponente per Mausklick können
ausführlichere,
komponentenbezogene Diagnoseinformationen abgerufen werden.
-
Eine
mögliche
Ausführungsmöglichkeit
der automatisch generierten Diagnosefunktionen ist das Generieren
von Scriptfunktionen. Diese Scriptfunktionen können z. B. in einem sogenannten
Anlagen-Diagnoseserver ausgeführt
werden und arbeiten die Diagnosefunktionen ab. Prinzipiell ist dieses
Konzept auch dezentral realisierbar, beispielsweise in einem Subsystem-Diagnoseserver,
der in einem PDev residiert. Dieses Konzept gewährleistet zudem, dass der Ansatz
der automatischen Generierung eines Anlagen-Diagnosesystems auch
in bereits bestehende Anlagen rückwirkungsfrei
integriert werden kann.
-
Zusammengefasst
betrifft die Erfindung somit ein Verfahren zur Generierung eines
Systems zur Bereitstellung von Diagnoseinformationen 1, 2, 3 sowie
ein entsprechendes System. Um die Bereitstellung von Informationen
zur Diagnose von technischen Anlagen oder technischen Prozessen
zu vereinfachen, wird vorgeschlagen, dass Komponenten 4 eines
Automatisierungssystems 5, welche Diagnoseschnittstellen
zur Bereitstellung von Diagnoseinformationen 1 zur Diagnose
der jeweiligen Komponente 4 aufweisen, in mindestens einer
Gruppe 6 zusammengefasst werden und dass die Bereitstellung
von Diagnoseinformationen 2 der jeweiligen Gruppe 6 durch
Verknüpfung
der Diagnoseinformationen 1 der in der jeweiligen Gruppe 6 zusammengefassten Komponenten 4 vorgesehen
wird.
-
Im
Folgenden werden Informationen zum technischen Hintergrund der Erfindung
gegeben. Diese basieren auf den im Internet (http://www.elektroniknet.de/topics/automatisieren/fachthemen
/artikel/2001/01018.htm bzw..../01027.htm) veröffentlichten Fachartikeln Georg
H. Biehler, Wolfram Gierling, "Das
Engineering-Modell" und
Joachim Feld, Ronald Lange, Norbert Bechstein, "Das Laufzeit-Modell".
-
Die
Profibus Nutzerorganisation stellte im August 2000 das Kommunikations-,
Automatisierungs- und Engineering-Modell PROFInet vor. Das Zusammenwachsen
der industriellen Automatisierung mit der IT der höher angesiedelten
Unternehmensebenen und die globale Vernetzung von Unternehmen auf
allen Ebenen über
das Internet ist ausschlaggebend dafür, dass die bekannte Profibus-Technologie
vertikal erweitert wurde. Unter dem Begriff PROFInet entstand ein
durchgängiges
Konzept für
die vertikale Daten-Integration. Dabei kommt aus Konsistenzgründen zu
den höheren
Ebenen eines Automatisierungssystems das Kommunikationsmittel Ethernet
zum Zuge, wobei die Durchgängigkeit zur
konventionellen Profibus-Technologie erhalten bleibt. Das PROFInet-Konzept
umfasst drei Aspekte: Für
die Projektierung von PROFInet-Systemen wurde ein herstellerübergreifendes
Engineering-Konzept definiert. Es baut auf einem Engineering-Objektmodell
auf, mit dem sich nicht nur Projektierungswerkzeuge entwickeln lassen,
welche die Komponenten unterschiedlicher Hersteller verwenden können, sondern
bei dem auch hersteller- bzw. anwenderspezifische Funktionserweiterungen
mittels sogenannter Facetten festgelegt werden können. So lassen sich durch
die klare Trennung zwischen der herstellerspezifischen Programmierung
der einzelnen Geräte
und dem anlagenweiten Verschalten mit einem übergeordneten Engineering-Werkzeug,
dem sogenannten Verschaltungseditor, Produkte unterschiedlicher
Hersteller in einer Anlage integrieren. Weiter spezifiziert PROFInet
ein offenes objektorientiertes Run-Time-Konzept. Das Run-Time-Konzept
legt für
die Kommunikation die im Ethernet-Sektor gängigen Mechanismen wie TCP(UDP)/IP
zugrunde. Über
dem Basismechanismus sind DCOM-Mechanismen
angesiedelt. Alternativ steht für
Anwendungsbereiche mit harter Echtzeit ein dafür optimierter Kommunikationsmechanismus
zur Verfügung.
Die PROFInet-Komponenten sind in Form von Objekten abgebildet, deren
Kommunikation durch die Mechanismen des Objektprotokolls gewährleistet
ist. Die projektierte Verschaltungen stellt die Einrichtung der
Kommunikationsbeziehungen und den Austausch der Daten zwischen PROFInet-Teilnehmern
sicher. Zudem verbirgt sich hinter dem Begriff PROFInet ein einheitliches
objektbasiertes Architekturkonzept für verteilte Automatisierungssysteme
von der E/A-Ebene
bis zur Leitebene, welches Systeme, die der konventionellen Profibus-Technologie
folgen, nahtlos in das Gesamtsystem integriert. Die Integration
von Profibus und anderer Feldbus-Systeme in ein PROFInet-System erfolgt
mittels Proxies. Ein Proxy ist ein Software-Modul, das sowohl für die Teilnehmer
am Profibus als auch gegenüber
den übrigen
PROFInet-Teilnehmern am Ethernet stellvertretend die Funktionalität von Automatisierungsobjekten
realisiert.
-
Durch
die Spezifikation der genannten drei Aspekte deckt PRO-FInet alle Life-cycle-Phasen
eines verteilten Automatisierungssystems ab. Das Thema Engineering
ist derjenige Aspekt von PROFInet, der die größten Berührungspunkte zu den Anwendern
der Technologie hat. Dies gilt gleichermaßen für die Systemdesigner wie auch
Anlagenbetreiber. Es ist auch derjenige Aspekt von PROFInet, der das
größte Kosteneinsparungspo tenzial
bei der Errichtung und dem Betrieb von Anlagen in sich birgt, da
die Kosten auf Produktebene bereits seit Jahren rückläufig sind
und das Potenzial wohl weitgehend erschöpft sein dürfte. Bei der Spezifikation
von PROFInet spielte die Vereinfachung des Handlings mit dem System
eine wesentliche Rolle. In diesem Zusammenhang kommt den Engineering-Werkzeugen ein
wichtiger Part zu. Nur mit ihrer Hilfe lassen sich noch die Kosten
der Anlagenbauer und -betreiber signifikant reduzieren. Und tatsächlich gestaltet
sich das Engineering einer Automatisierungslösung mit PROFInet aus Sicht
des Anwenders einfach. Doch je benutzerfreundlicher ein System für den Anwender ist,
desto komplexer ist es unter der Oberfläche. Das Engineering-Werkzeug
ist dynamisch erweiterbar, so dass Komponenten beliebiger Hersteller
in einem Engineering-Werkzeug reibungslos zusammen arbeiten können. Die
unterschiedlichsten Engineering-Aspekte wie Verschaltung, Parametrierung, Test,
Inbetriebnahme und Diagnose sind zur Verfügung zu stellen. Existierende
(proprietäre)
Programmier- und
Engineering-Werkzeuge müssen
sich weiterhin verwenden lassen. Bestehende Konzepte wie OLE for
Process Control (OPC) und Fieldbus Device Tool (FDT) sind zu integrieren.
PROFInet soll mit anderen DV-Verfahren im gesamten Unternehmen zusammenspielen.
Hierzu gehören
beispielsweise Management-Informationssysteme
(MIS) und Enterprise-Resource-Planning-Systeme (ERP). Auch ohne spezielle Werkzeuge
muss es möglich
sein, Daten in das PROFInet-Engineering-Modell einzuspielen oder aus
dem System in andere Applikationen wie nach Excel zu übernehmen.
Existierende Feldbusse, insbesondere Profibus-DP, müssen sich
einbinden lassen.
-
Bevor
die Eigenschaften des Engineering-Konzepts zur Sprache kommen, ist
es wichtig, die zugrundeliegenden Modelle vorzustellen. Die in vielfältiger Hinsicht
geforderte Offenheit des Systems verlangt nach einem durchgängigen Konzept,
das diesen Anforderungen Rechnung trägt. Daher liegt PROFInet ein
objektorientierter Ansatz zu Grunde – das Component Object Model
(COM) von Microsoft. Dabei werden in sich geschlossene Module erzeugt, deren
Funktionalität
nach außen über eindeutige Schnittstellen,
die Interfaces des Objektes, erreichbar ist. Ein Interface ist die
Zusammenfassung einer bestimmten Menge von Funktionen, durch die
festgelegt ist, welche Leistung von einem Server (Dienstleister)
für einen
Client (Auftraggeber) erbracht werden soll. In diesem Fall spricht
man davon, dass eine Komponente das Interface implementiert. Die
Art der Implementierung selbst wird dem Ersteller einer Komponente
aber nicht vorgeschrieben. Script-Sprachen wie Visual Basic for
Applications (VBA) können über die
ebenfalls von COM standardisierten OLE-Automation Interfaces auf
PROFInet-Objekte zugreifen.
Damit hat der Anwender eine besonders einfache Möglichkeit, den Funktionsumfang
des PROFInet-Engineering-Werkzeuges
durch eigene Erweiterungen an seine spezifischen Anforderungen anzupassen.
-
Eine
PROFInet-Automatisierungslösung
besteht zur Laufzeit aus miteinander kommunizierenden Automatisierungsobjekten,
den Runtime Automation Objects, kurz RT-Autos. Dabei handelt es
sich um Software-Komponenten, die auf den physikalischen PRO-FInet-Geräten ablaufen.
Das Zusammenspiel der RT-Autos muss mit Hilfe eines Projektierwerkzeuges
spezifiziert werden. Zu diesem Zweck haben die RT-Autos Entsprechungen
im Projektierwerkzeug, die alle notwendigen Informationen für die vollständige Projektierung
beinhalten: Die Engineering System Automation Objects (ES-Autos). Beim Übersetzen
und Laden einer Anwendung wird aus jedem ES-Auto ein entsprechendes
RT-Auto. Damit das Projektierwerkzeug weiß, auf welchem Gerät ein Automatisierungsobjekt
liegt, verfügt
es über
eine Entsprechung des Objekts in Gestalt des sogenannten Engineering
System Device (ES-Device). Genau genommen entspricht das ES-Device einem "logischen Gerät" (logical device).
Darüber
hinaus gibt es eine Zuordnung zwischen "logischen" und "physikalischen" Geräten.
Meistens findet sich hier eine "1:1"-Zuordnung, das heisst:
Zu einer Hardware (physical device) existiert genau eine Firmware. Es
ist jedoch auch möglich,
dass auf einer Hardware mehrere voneinander unabhängige Software-Pakete ab laufen.
Beispiele hierfür
sind insbesondere Geräte mit
freier Rechenleistung: ein PC mit Slot-SPS oder ein Windows-CE-Gerät mit Bedienoberfläche und SPS-Komponente.
Als Sammelbezeichnung für
alle Objekte im Kontext des Projektierwerkzeuges wird der Begriff
Engineering System Object (ES-Object) verwendet. Es umfasst alles,
was der Anwender während
der Projektierung wahrnimmt und alles, womit er hantiert. Es ist
also die "Basisklasse" für die Engineering-Objekte.
Durch das Instanzieren, Verschalten und Parametrieren der ES-Objects
entsteht das Modell der Automatisierungslösung einer konkreten Anlage.
Angestoßen
durch einen Download wird unter Auswertung des Engineering-Modells
die Runtime-Software erzeugt. Die PROFInet-Spezifikation beschreibt
ein Objektmodell, das die technischen Rahmenbedingungen für die Verwendung
von ES-Objects festlegt.
Auf dieser Basis lassen sich dann PROFInetkonforme Engineering-Systeme
realisieren. Andererseits ist nicht jeder Hersteller von PROFInet-Geräten gezwungen,
ein eigenes Projektierwerkzeug zu entwickeln und somit das Rad immer wieder
neu zu erfinden.
-
Ein
wichtiges Konzept zur Erweiterung des PROFInet-Objektmodells stellen die Facetten dar. Eine
Facette realisiert einen ganz bestimmten (Teil-)Funktionsumfang
des ES-Object und
stellt sich dem Anwender als eine spezielle Sicht auf das Objekt
dar. So betrachtet die Verschaltungsfacette lediglich die Kommunikationsbeziehungen
des Objektes zu anderen Objekten. Für die Parametrierung des Objektes
wechselt der Benutzer in die Parametrierfacette. Die Zuordnung eines
Automatisierungsobjektes zu einem physikalischen Gerät realisiert
er mit Hilfe der Gerätezuordnungsfacette.
Schließlich
werden die Verschaltungsinformationen über die Download-Facette auf die Geräte geladen.
Einige Facetten definiert der PROFInet-Standard. Andere Facetten sind
anwendungsspezifisch. Jeder Komponentenhersteller, der Automatisierungsobjekte
implementiert, kann eigene Arten von Facetten definieren. Der PROFInet-Standard
stellt sicher, dass sich diese dem ES-Object hinzufügen lassen. Als Beispiel für derartige
Facetten seien Diagnosefacetten genannt, welche die spezifischen
Diagnoseinformationen des Gerätes
in optimaler Weise darbieten. In der Gerätezuordnungsfacette ist die
Methode implementiert, welche die zu einem bestimmten Automatisierungsobjekt
kompatiblen Geräte
ermittelt. Dies bringt den Vorteil mit sich, dass das Projektierwerkzeug
nur diejenigen Geräte
anzeigen kann, auf denen das gewählte
Automatisierungsobjekt auch lauffähig ist. Bei Geräten mit
fester Funktionalität
hingegen kann der Anwender zunächst
das Gerät
auswählen,
woraufhin das Projektierwerkzeug lediglich diejenigen RT-Autos anzeigt,
die auf diesem Gerät
zur Verfügung
stehen.
-
Die
PROFInet-Spezifikation legt die Schnittstellenbeschreibungen eines
Projektierungswerkzeugs offen, wodurch jedem Hersteller ermöglicht wird,
sein eigenes PROFInet-konformes Projektierwerkzeug zu erstellen.
Da dieses Werkzeug jedoch keine herstellerspezifischen Implementierungen
enthält,
ist es jederzeit möglich,
das Werkzeug eines anderen Herstellers zu benutzen. Herstellerspezifische Teile
bindet das Engineering-Werkzeug über
definierte Schnittstellen ein. Dem Grundgedanken der COM-Programmierung
entsprechend, sind keine Implementierungen vorgeschrieben, sondern
lediglich eindeutige Schnittstellen definiert. Die PROFInet-Strategie
sorgt dann dafür,
dass die Kommunikation über
den Bus reibungslos funktioniert, lässt aber andererseits den Herstellern
alle Freiheiten, sich durch eigene Implementierungen vom Wettbewerb zu
differenzieren. Die Vorteile von PROFInet zeigen sich insbesondere
im Engineering. Indem Kommunikation nicht mehr programmiert werden
muss, sondern projektiert werden kann, vereinfacht sich die Erstellung
einer Automatisierungslösung
beträchtlich. Die
Wiederverwendung ausgetesteter Lösungen
verkürzt
Entwicklungs- und Inbetriebnahmezeiten und kann dadurch zu einer
deutlichen Kostenreduktion beitragen.
-
PROFInet
ist ein durchgängiges
Konzept für die
vertikale Daten-Integration, wobei bewusst auf Profibus-spezifische
Kommunikationsmechanismen verzichtet und stattdessen auf offene Standards
gesetzt wurde, um eine Feldbus-unabhängige Kommunikation zu ermöglichen.
Das PROFInet-Konzept definiert ein Objektmodell für das Engineering-System, das
mit der COM-Komponenten-Technologie
von Microsoft realisiert wird. Der konkrete Zusammenhang verschiedener
Komponenten ist durch XML (eXtensible Markup Language) beschrieben.
Für das
Laufzeitsystem müssen
die sieben Schichten des ISO/OSI-Referenzmodells festgelegt werden.
Für die gleichberechtigte
Kommunikation autarker Funktionseinheiten bietet sich hierzu Ethernet
mit der TCP/IP-Protokollsuite bis Layer 4 an. Darunter sind Protokolle
wie TCP, UDP oder ICMP zu verstehen, die in der IT-Landschaft unbestrittene
De-facto-Standards darstellen. Doch wie ist der Layer 7 beschaffen?
Im PROFInet-Konzept werden Komponenten ("Objekte") gebildet, die von außen nur über ihre Schnittstellen
("Interfaces") erreichbar sind.
Ein Interface ist die Zusammenfassung einer bestimmten Menge von
Funktionen und damit eine Art Vertrag. Er legt fest, welche Leistung
von einem Server (Dienstleister) für einen Client (Auftraggeber)
erbracht werden soll. In diesem Fall spricht man davon, dass eine Komponente
das Interface implementiert. Die Art der Implementierung selbst
ist dem Ersteller einer Komponente aber nicht vorgeschrieben. Es
ist daher naheliegend, auch für
die Kommunikation zur Laufzeit zwischen den Komponenten ein Objektprotokoll
einzusetzen. PROFInet nutzt in diesem Punkte Microsoft DCOM (Distributed
COM). DCOM ist die Erweiterung der COM-Technologie für verteilte
Anwendungen. Es basiert auf dem Standard DCE RPC (Distributed Computing
Environment Remote Procedure Call). Einer der wichtigsten Vorteile
von DCOM liegt darin, dass für
das Engineering und die Runtime die gleiche Komponenten-Technologie
verwendet wird. DCOM ist bisher primär auf PC-Architekturen implementiert
worden. Im Embedded-Bereich ist es nicht notwendig, das gesamte
DCOM, wie etwa innerhalb von Microsoft Windows, zu implementieren.
Es genügt,
denjenigen Teil zu implementieren, der im Netzwerk über das
sogenannte DCOM Wire Protocol sichtbar wird und als Internet Draft
veröffentlicht
wurde. Innerhalb von Embedded-Geräten kann die Programmierung
unverändert bleiben.
Insbesondere muss keine strenge COM-Architektur implementiert sein.
Alle Implementierungswege der Automatisierungsobjekte als COM-Objekte
mit entsprechenden Interfaces werden zugelassen, solange nach außen hin
der PROFInet-Objekteindruck
gewahrt bleibt. Beispielsweise werden bei einer Steuerung die Objekte
in der für
diese Steuerung notwendigen Sprache erstellt und als Bausteine zum
Ablauf gebracht.
-
Wie
im Engineering ist auch im Runtime-Modus zwar die Syntax durch die
(D)COM-Technologie definiert, die spezifischen Ergänzungen
für die
Automatisierungstechnik müssen
jedoch noch festgelegt werden (Semantik). Dazu lassen sich in PROFInet die
Interfaces der Automatisierungsobjekte abhängig von der Funktionalität, die sie
abdecken, in vier Kategorien aufteilen:
Pflicht-Interfaces:
Diese Interfaces definieren einen Standard, den alle Ressourcen
(Geräte)
einer PROFInet-basierten Automatisierungslösung implementieren müssen. Neben
den durch COM definierten Interfaces – wie die der Identifikation – gehört die Unterstützung der
Daten- und Event-Verschaltung zur Pflichtfunktionalität.
-
Optionale
Interfaces: Diese sind Optionen, die nicht jedes Gerät erbringen
muss. Wenn diese Funktion allerdings erbracht werden soll, ist die
Interface-Implementierung nach Vorlage Pflicht.
-
Gerätespezifische
Interfaces: Sind die Interfaces, welche den Zugriff auf gerätespezifische
Leistungen ermöglichen.
Diese Interfaces können
nicht standardisiert werden und sind in der Regel in Firmware implementiert.
Die Objekte, die die gerätespezifischen
Interfaces implementieren, bilden das Geräte-Objektmodell.
-
Anwendungsspezifische
Interfaces: Hier werden die benötigten
anwendungsspezifischen Automatisierungsobjekte mit Programmierwerkzeugen entwickelt,
die unter Umständen
zielsystemspezifisch sind.
-
PROFInet
definiert ein Laufzeit-Objektmodell, das jedes PRO-FInet-Gerät, das an
Ethernet betrieben wird, implementieren muss. Jedes der verfügbaren Objekte
wird durch ein DCOM-Objekt
realisiert. Dies sind im einzelnen:
Das Physical Device Objekt
(PDev): Es repräsentiert das
Gerät als
Ganzes. Es dient als Einstiegspunkt für andere Geräte, das
heisst, der erstmalige Kontakt mit einem PROFInet-Gerät geht über dieses
Objekt. Das PDev exponiert die physikalischen Eigenschaften der Komponente.
Auf jeder Hardware-Komponente (SPS,
Antrieb, PC) existiert genau eine Instanz des PDev.
-
Das
Logical Device Objekt (LDev): Es repräsentiert den eigentlichen Programmträger, das
heisst die Teile des Gerätes,
die die eigentlichen PROFInet-Knoten darstellen. Die Unterscheidung
zwischen Physical und Logical Device ist bei Embedded-Geräten im allgemeinen
zwar unnötig,
bei Runtime-Systemen auf einem PC ist diese Unterscheidung jedoch wichtig,
da zum Beispiel zwei SoftSPS auf einem PC ablaufen können. Der
PC ist in diesem Fall das Physical Device, die SoftSPS jeweils ein
Logical Device. Das Logical Device besitzt Interfaces zur Abfrage
des Betriebszustandes, Uhrzeit, Sammel- und Detaildiagnose.
-
Runtime-Automatisierungsobjekte
(RT-Auto): Sie repräsentieren
die eigentliche technologische Funktionalität des Gerätes. Die Interfaces der Objekte
sind somit abhängig
von der Aufgabe, die das Objekt erfüllt. So hat etwa ein Hubtisch
ein Interface zum Verfahren des Tisches. Ein Interface kann dabei
sowohl Daten (lesend, schreibend) als auch Methoden und Events enthalten.
-
Die
Stellvertreter von LDev beziehungsweise RT-Auto im Engineering sind
das oben beschriebene ES-Device beziehungsweise das ES-Auto. Das
wichtigste Objekt für
das Zusammenspiel mit anderen PROFInet-Geräten ist das ACCO (Active Control Connec tion
Object). Dieses Objekt dient der projektierten Einrichtung von Kommunikationsbeziehungen zwischen
Objekten. Das ACCO implementiert ein Consumer-Provider-Modell. Die
Elemente der Interfaces der RT-Autos werden über das ACCO anderen Ge-räten zur Verfügung gestellt
(Provider). Das ACCO meldet sich aber auch bei ACCOs anderer Geräte an und
versorgt die RT-Autos
seines Gerätes mit
Daten beziehungsweise Events (Consumer). Kommunikationsbeziehungen
werden immer von der Consumer-Seite aus aufgebaut. Eine Daten- oder Event-Verschaltung
0 zwischen zwei Objekten (beispielsweise zweier aufeinander folgender
Förderelemente)
kann einfach durch die Projektierung der Verbindung auf Consumer-Seite
vorgegeben werden. Das ACCO sorgt dann selbstständig für die Einrichtung der Kommunikationsbeziehung
und den Austausch der Daten. Ein wichtiger 5 Aspekt des ACCO ist
die Fehlerbehandlung. Diese umfasst die Übertragung von Quality Code
und Timestamp mit den Werten sowie der automatischen Aufschaltung
eines projektierten Ersatzwertes im Fehlerfall. Weiter die Überwachung
des Kommunikationspartners, den Reconnect nach Verbindungsverlust
sowie 0 die Diagnose und Testmöglichkeiten
für Verschaltungen.
Die Übertragung
mit DCOM ist ereignisgesteuert, das heisst, der Provider überwacht
seine Daten auf Änderung. Die
unterlagerten Schichten sorgen für
eine Sicherung der Verbindung.