Die DE 100 08 020 A1 beschreibt eine Diagnosevorrichtung in einem Prozesssteuersystem, das Mehrgrößen-Regeltechniken ver- wendet, wobei ein Diagnosetool automatisch Daten, die einen Steuerungsparameter, einen Modusparameter, einen Statuspara- meter und einen Grenzwertparameter angeben, die jeder der un- terschiedlichen Einrichtungen, Kreise oder Funktionsblöcke innerhalb eines Prozesssteuersystems zugehörig sind, erfasst und speichert, die erfassten Daten verarbeitet, um zu bestim- men, welche Einrichtungen, Kreise oder Funktionsblöcke Prob- leme haben, die zu einer verringerten Leistung des Prozess- steuersystems führen, eine Liste von erfassten Problemen ei- ner 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 Automatisierungssys- tems, welche Diagnoseschnittstellen zur Bereitstellung von Diagnoseinformationen zur Diagnose der jeweiligen Komponente aufweisen, in mindestens einer Gruppe zusammengefasst werden und die Bereitstellung von Diagnoseinformationen der jeweili- gen Gruppe durch Verknüpfung der Diagnoseinformationen der in der jeweiligen Gruppe zusammengefassten Komponenten vorgese- hen 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 Diagno- seinformationen zur Diagnose der jeweiligen Komponente auf- weisen, wobei Mittel zur Bereitstellung von Diagnoseinforma- tionen der jeweiligen Gruppe durch Verknüpfung der Diagnose- informationen der in der jeweiligen Gruppe zusammengefassten Komponenten vorgesehen sind.

Der Erfindung liegt die Erkenntnis zugrunde, dass der Anteil verteilter, komponentenbasierter Automatisierungssysteme zu- nimmt und damit die Notwendigkeit besteht, diese Systeme bei Störungen diagnostizieren zu können. Diese Diagnose darf sich dabei nicht nur auf einzelne Automatisierungskomponenten be- schränken, sondern muss es ermöglichen, das ganze Automati- sierungssystem bzw. seine Subsysteme untersuchen zu können und dies möglichst mit einem einheitlichen, durchgängigen Be- dienparadigma. Der Engineering-Aufwand für die Erstellung ei- ner anlagenweiten Diagnose für ein verteiltes Automatisie- rungssystem ist üblicherweise sehr hoch, auch dadurch be- dingt, dass das Diagnosesystem bisher speziell für eine be- stimmte Anlage erstellt werden musste. Die Diagnose verteil- ter Automatisierungslösungen zielt bisher in der Regel auf die Diagnose einzelner Komponenten ab (z. B. wird die Diagno- se-Software mit der jeweiligen Hardware-Komponente mitgelie- fert) oder ist nur durch aufwändige Projektierung für die je- weilige Anlage herstellbar. Diese Projektierung wird übli- cherweise anhand des Anlagenlayouts (Papierausdruck) und der Funktionsbeschreibung der Anlage manuell von Automatisie- rungsspezialisten erstellt. Daher unterscheidet sich bisher die Diagnose einer Komponente (Diagnosetool wird vom Kompo- nentenhersteller geliefert) von der Diagnose der Anlage (wird vom. Anlagenhersteller geliefert). Die Erfindung ermöglicht sowohl eine komponentenbasierte Diagnose als auch gleichzei- tig eine Diagnose von Komponenten umfassenden Gruppen. Eine

Gruppe wird im Folgenden auch als Subsystem oder Diagnose- Subsystem bezeichnet. Die Bereitstellung der Diagnoseinforma- tionen der Gruppen kann dabei durch Verknüpfung der Diagnose- informationen der in der jeweiligen Gruppe zusammengefassten Komponenten erfolgen. Diese bietet insbesondere die Möglich- keit, 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 Er- findung auch die Möglichkeit der Anlagendiagnose, wobei die Anlagendiagnose einerseits auf einem höheren Abstraktionsle- vel als die Komponentendiagnose aufsetzt, andererseits aber auf die Komponentendiagnose aufbaut. Gemäß einer vorteilhaf- ten Ausgestaltung der Erfindung werden in mindestens einer übergeordneten Gruppe untergeordnete Gruppen bzw. untergeord- nete Gruppen und Komponenten zusammengefasst, wobei die Gene- rierung von Diagnoseinformationen der jeweiligen übergeordne- ten Gruppe durch Verknüpfung der Diagnoseinformationen der in der jeweiligen übergeordneten Gruppe zusammengefassten Grup- pen bzw Komponenten vorgesehen ist. Auf der obersten Ebene der so entstehenden Diagnosehierarchie steht das Diagnosesys- tem der Anlage bzw. des Prozesses, die somit aus Gruppen bzw.

Diagnose-Subsystemen zusammengesetzt ist, wobei diese Diagno- se-Subsysteme weitere Diagnose-Subsysteme beinhalten können.

Es entsteht ein selbstähnliches, ein fraktales System. Insbe- sondere umfasst die Fraktalität, dass die Anlagenbeschreibung wie die Komponentenbeschreibung auf denselben Schnittstellen basiert und somit durch vorhandene, für die Komponentendiag- nose entwickelte Diagnose-Tools bzw. durch deren Weiterent- wicklungen unmittelbar verarbeitet werden kann. Das ermög- licht eine einheitliche, durchgängige Bedienung, eine Redu- zierung der Kosten für Anlagen-Diagnosetool-Entwicklung und Weiterentwicklung.

Vorteilhaft ist, wenn die Schnittstellen der Automatisie- rungskomponenten, z. B. durch eine Spezifikation der PROFInet Webintegration, standardisiert beschrieben sind. Durch die standardisierten Schnittstellen der Komponenten, die auch Di- agnosefunktionalität beinhalten, kann ein Regelsystem jeweils für eine Gruppe von Komponenten durch die Verknüpfung mit den Layoutinformationen ein vollständiges Diagnosesystem erzeu- gen. Dabei stützt sich die Diagnosefunktion eines Subsystems auf die standardisierten Diagnosefunktionen der enthaltenen Automatisierungskomponenten.

Gemäß einer weiteren vorteilhaften Ausgestaltung der Erfin- dung sind die Komponenten Bestandteile eines Anlagenlayouts und erfolgt die Verknüpfung der Diagnoseinformationen in Ab- hängigkeit von im Anlagenlayout enthaltenen Informationen.

Eine Aufgabe der Anlagendiagnose ist die Erkennung von Feh- lern, die aus dem Zusammenspiel der Komponenten der Anlage entstehen. Der Anlagenhersteller definiert das Zusammenspiel der Komponenten durch die Layoutplanung der Anlage. Die vor- geschlagene Ausgestaltung der Erfindung ermöglicht es, eine Anlagendiagnose aus dem während der Anlagen-Planungsphase er- stellten digitalen Anlagenlayout per automatischer Generie- rung abzuleiten. Dies führt neben einer Verkürzung der Engi- neering-Zeiten auch zu einer Reduzierung der Fehlerwahr- scheinlichkeit bei der Erstellung des Diagnosesystems. Es wird somit ein neuartiges Verfahren vorgeschlagen, das es er- möglicht, aus Layout-Informationen ein Diagnosesystem für ein insbesondere verteiltes Automatisierungssystem inklusive sei- ner Komponenten automatisch abzuleiten, wobei dieses System das Merkmal der Fraktalität hinsichtlich seiner Diagnose- Funktionen aufweist.

Die Anlagenkomponenten werden im Anlagenlayout in logisch zu- sammengehörige Gruppen, sogenannte"Diagnose-Subsysteme", zu- sammengefasst. 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 erforderli- chen Elementen der technologischen Hierarchie (Teilanlagen, Units,...) deckungsgleich sein, insbesondere können völlig andere Aspekte, z. B. Lokalität, die Strukturierung der Diag- nose-Hierarchie bestimmen. Diese Diagnose-Subsysteme kapseln die darin enthaltenen Automatisierungskomponenten und verrin- gern somit die Komplexität der Diagnose des Gesamtsystems.

Gemäß einer weiteren vorteilhaften Ausgestaltung der Erfin- dung 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 de- finierbar. Das entspricht dem Zusammenfassen zusammengehöri- ger Diagnose-Subsysteme zu einem kapselndem Diagnose- Subsystem auf höherer Ebene.

Gemäß einer weiteren vorteilhaften Ausgestaltung der Erfin- dung sind die Diagnoseinformationen semantisch gleichartig aufgebaut. Auf der Grundlage der in dem Anlagen-Layout defi- nierten Diagnose-Hierarchie kann für alle Elemente der Hie- rarchie automatisch eine semantisch gleichartige Diagnose- Funktion generiert werden. Diese basiert auf folgendem Prin- zip : Die generierte Diagnosefunktion einer Komponente über- prü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 Diag- nosefunktion z. B. eines Subsystens den eigenen Status und ruft die Diagnosefunktion der zugehörigen Komponente auf. Ab- hängig von den erhaltenen Werten meldet die Diagnosefunktion gegebenenfalls einen Fehler mit Beschreibung. Damit besitzen auch die rein logischen Diagnose-Subsysteme eine Diagnose- funktion. Dieses Prinzip wird rekursiv bis zur obersten Ebene angewendet, d. h. die Diagnosefunktion eines Diagnose-

Subsystems wird so ausgeprägt, dass sie die Diagnosefunktio- nen der jeweils direkt unterlagerten Subsysteme aufruft. Ne- ben dieser Propagierung von Diagnose-Funktionsaufrufen von einer höheren Ebene zur jeweils untergeordneten Ebene der Di- agnose-Hierarchie kann im Sinne der Induktion unter Einbezie- hung der Anlagenlogik höherwertige Diagnosefunktionalität au- tomatisch generiert werden.

Vorteilhafterweise enthalten die Diagnoseinformationen Funk- tionen, welche Eingangsgrößen verknüpfen-insbesondere lo- gisch verknüpfen-und mindestens eine Ausgangsgröße als Er- gebnis 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 in- terne Informationen des jeweiligen Elements verknüpft."Multi Level Logic"bildet die Logik eines Subsystems aufbauend auf den unterlagerten,"darin enthaltenen"Elementen ab. Beim re- kursiven 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 Diagnose- funktion aufgenommen. Im Falle der Multi Level Logic wird an- hand des Anlagenlayouts ermittelt, welche Regel im gegebenen Fall einzusetzen ist, da die Multi Level Logic aus dem Zusam- menspiel verschiedener Komponenten entsteht. Es werden somit Diagnoseinformationen durch rekursive Anwendung eines Regel- system generiert, das standardisierte Diagnoseschnittstellen mit Layoutinformationen verknüpft.

Für beide Kategorien können Konsistenz-Regeln ("constraints") definiert werden bzw. als Typeigenschaft der verwendeten Kom- ponenten-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 Planungs- information von Teilen älterer Anlagen) bereits vorhanden

sein. Gemäß einer weiteren vorteilhaften Ausgestaltung der Erfindung werden den Komponenten und den Gruppen Klassen zu- geordnet, welche Funktionen und Eigenschaften der jeweiligen Komponente bzw. Gruppe festlegen. Die Definition von Geräte- klassen (bezogen auf Komponenten und Subsysteme) mit festge- legten Funktionen und Eigenschaften kann Grundlage für das Erstellen von Single und Multi Level Logic sein. Durch Anwen- dung der inhärenten bzw. darauf aufbauenden Regeln und unter Einbeziehung des Anlagenlayouts kann wie oben skizziert auto- matisch Diagnosefunktionalität abgeleitet und generiert wer- den. Die Regeln können aufgrund der Fraktalität rekursiv an- gewendet 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 ver- teiltes, komponentenbasiertes Automatisierungssystem aus Lay- out-Informationen vorgeschlagen.

Wenn gemäß einer weiteren vorteilhaften Ausgestaltung der Er- findung die Komponenten PROFInet-Komponenten sind, wird die Automatisierungsfunktionalität von sogenannten RTAutos er- bracht, so dass Diagnose-Subsysteme auf unterster Ebene die zugehörigen RTAutos kapseln.

Vorteilhafterweise sind Mittel zur Visualisierung der Diagno- seinformationen 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 dar- gestellten Ausführungsbeispiele näher beschrieben und erläu- tert.

Es zeigen : FIG 1 ein System zur Bereitstellung von Diagnoseinforma- tionen, FIG 2 eine aus dem Anlagenlayout abgeleitete logische Di- agnosehierarchie, FIG 3 den Ablauf der Generierung von Diagnoseinformatio- nen, FIG 4 eine Diagnose-Script-Funktion, FIG 5 im. Anlagenlayout enthaltene Informationen, FIG 6 die Fraktalität der Diagnosefunktionalität, FIG 7 die Planung eines Anlagenlayouts mit einem CAD- System, FIG 8 ein Diagnose-Netz aus dem Anlagenlayout, FIG 9 den Engineering Workflow und FIG 10 die Visualisierung von Diagnoseinformationen.

Figur 1 zeigt ein System zur Bereitstellung von Diagnosein- formationen. Ein Automatisierungssystem 5 weist Komponenten 4 auf, welche Diagnoseschnittstellen zur Bereitstellung von Di- agnoseinformationen 1 zur Diagnose der jeweiligen Diagnose 4 aufweisen. Die Komponenten 4 sind im Beispielsfall in zwei Gruppen 6 zusammengefasst. Das System weist Mittel zur Be- reitstellung 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. Diagnoseinformatio- nen 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 gene- riert. Das System wird im Beispielsfall verwendet zur Diagno- se eines technischen Prozesses 8. Das Automatisierungssystem 5 dient zur Automatisierung des technischen Prozesses 8.

Figur 2 zeigt eine aus einem Anlagenlayout abgeleitete logi- sche Diagnosehierarchie am Beispiel PROFInet (genauere Erläu- terung 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 je- des 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) exis- tiert 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 Devi- ce-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 be- sitzt Interfaces zur Abfrage des Betriebszustandes, Uhrzeit, Sammel-und Detaildiagnose. So genannte Runtime-Automati- sierungsobjekte A (auch RT-Auto genannt) repräsentieren die

eigentliche technologische Funktionalität des Geräts. Die In- terfaces 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 de- ren Interfaces, die darin enthaltenen Methoden und Daten. Da- mit kann insbesondere die durch das Runtime-Automatisierungs- objekt A repräsentierte technische Funktionalität eines Ge- räts auf einfachste Art und Weise beschrieben werden. Auf der Grundlage der in einem Anlagenlayout definierten Diagnosehie- rarchie wird für alle Elemente der Hierarchie automatisch ei- ne 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 Beschrei- bung. Auf der Ebene der Runtime-Automatisierungsobjekte A ü- berprüft die generierte Diagnosefunktion den Status des je- weiligen Objekts und ruft die Diagnosefunktion des zugehöri- gen 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 Sub- systems 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 ausge- prägt, dass sie die Diagnosefunktionen der jeweils direkt un- terlagerten 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 wer- den.

Das Layout der Anlage, d. h. die topologische Anordnung der Komponenten des verteilten Automatisierungssystems wird übli- cherweise in der Planungsphase einer Anlage erzeugt. Dabei wird auch eine technologisch bedingte, hierarchische Gliede- rung der Gesamtanlage in Teilanlagen, Maschinen usw. vorge- nommen (auch als Gliederung in"Subsysteme"bezeichnet). Im Folgenden wird unterstellt, dass diese technologisch begrün- deten Subsysteme mit den Diagnose-Subsystemen deckungsgleich sind. FIG 2 verdeutlicht anhand eines Anlagenlayouts die Auf- teilung der Gesamtanlage in Subsysteme.

Figur 3 zeigt den Ablauf der Generierung von Diagnoseinforma- tionen 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 ver- knü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 Generie- rungsschritt 16 in einer Diagnoseinformation 17, z. B. ein Diagnose-Script, umgesetzt.

So genannte Multi Level Logic bildet die Logik eines Subsys- tems aufbauend auf den unterlagerten, darin enthaltenen Ele- menten 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 Re- geln 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 Tei- len ä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 Di- agnosefunktionen ein. Im Falle der Single Level Logic werden die definierten Regeln direkt in die Diagnosefunktion aufge- nommen, in Figur 3 die Diagnosefunktion 17. Im Falle der Mul- ti Level Logic wird anhand des Anlagenlayouts ermittelt, wel- che Regel im gegebenen Fall einzusetzen ist, da die Multi Le- vel Logic aus dem Zusammenspiel verschiedener Komponenten entsteht.

Figur 4 zeigt ein Beispiel einer Diagnoseinformation, welche als Diagnose-Scriptfunktion ausgeführt ist.

Figur 5 zeigt die im Anlagenlayout enthaltenen Informationen.

Im Ausführungsbeispiel gemäß Figur 5 sind im Anlagenlayout Informationen über PROFInet-Komponenten 30, über die hierar- chische Struktur 31 aus Diagnosesicht und über generische Di- agnosefunktionen 32 enthalten.

Grundlage für das Erstellen von Single und Multi Level Logic ist die Definition von Geräteklassen (Komponenten und Subsys- temen) 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.

Figur 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 se- mantisch 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 Anla- genlayout 37,42 enthaltene Informationen dienen dabei zur Generierung von Regeln 39 bzw. 41 zur Diagnose von Komponen- ten 36 bzw. Subsystemen 35, mit Hilfe von Diagnosefunktionen 38 bzw. 40.

Figur 7 zeigt die Planung eines Anlagenlayouts mit einem CAD- System. Hier wird ein Subsystem entweder durch die Definition der baumartigen A-nlagenstruktur (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 Figur 6 werden die zu einem Subsystem gehörenden Komponenten z. B. durch das Zeichnen eines die Komponenten einschließen- den Polygons ("Lasso") definiert. Dabei kann ein Polygon wei- tere Polygone vollständig umschließen. Diese eingebetteten Polygone entsprechen dann der visuellen Definition unterla- gerter Diagnose-Subsysteme.

Figur 8 zeigt ein aus dem Anlagenlayout erzeugtes Diagnose- netz. Das Anlagenlayout beinhaltet bereits alle für die wei- teren Schritte der Generierung eines Systems zur Bereitstel- lung von Diagnose. informationen nötigen Informationen, wie z. B. die Zuordnung von Runtime-Automatisierungsobjekten 47 zu Komponenten 45 und damit zu Subsystemen 48. Die in der Planungsphase hantieren Komponenten besitzen neben einer to- pologischen Sicht (Anordnung in der Anlage, Abmaße, Form, <BR> <BR> etc. ) auch eine Diagnosesicht. Die Verbindung der Diagnose- sicht der Komponenten mit der Hierarchie ermöglicht wie oben beschrieben die automatische Generierung von Diagnosefunktio-

nalität. Aufbauend auf der Diagnosesicht der Komponenten las- sen sich in einem ersten Schritt Diagnosefunktionen für die umschließenden Subsysteme generieren. Daraus werden im zwei- ten Schritt rekursiv Diagnosefunktionen für weitere Subsyste- me bis hin zur Anlagenebene generiert. In die generierten Di- agnosefunktionen fließen die für die jeweilige Hierarchieebe- ne bereits vorhandenen (z. B. als Klasseneigenschaft einer Komponente) oder explizit benannten Konsistenzregeln für die Single bzw. Multi Level Logic ein.

Figur 9 zeigt den Engineering Workflow zur Generierung eines Systems zur Bereitstellung von Diagnoseinformationen. Ausge- hend 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 Anla- gen-Diagnose-Server 53 ist danach in der Lage, alle Diagnose- Scriptfunktionen auszuführen und somit die Anlage, Subsysteme und Komponenten zu diagnostizieren.

Figur 10 zeigt eine prototpyische Visualisierung aufbauend auf einem Anlagen-Diagnose-Server. Die gezeigte Visualisie- rung 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 Kommu- nikation zwischen Client und Server erfolgt mittels Webservi- ces und basiert auf dem HTTP-Protokoll. Sowohl Server als auch Client können in einer Vielzahl unterschiedlicher Anla- gen 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 Engine- ringaufwands, sondern zudem den Vorteil eines durchgängigen Diagnosekonzepts. Dieses durchgängige Diagnosekonzept be- schränkt sich dabei nicht auf die Komponentendiagnose,'son- dern verringert durch die Bildung von Subsystemen mit Diagno- sefunktionalität die Komplexität der Gesamtanlage vor allem für den Anlagenbediener.

Die Verknüpfung der Anlagentopologie mit der daraus regelba- siert abgeleiteten Diagnosehierarchie der Subsysteme kann auch dafür genutzt werden, eine Diagnoseoberfläche gemäß Fi- gur 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 Anla- genknoten. 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 gene- rierten Diagnosefunktionen ist das Generieren von Scriptfunk- tionen. Diese Scriptfunktionen können z. B. in einem soge- nannten Anlagen-Diagnoseserver ausgeführt werden und arbeiten die Diagnosefunktionen ab. Prinzipiell ist dieses Konzept auch dezentral realisierbar, beispielsweise in einem Subsys- tem-Diagnoseserver, der in einem PDev residiert. Dieses Kon- zept gewährleistet zudem, dass der Ansatz der automatischen Generierung eines Anlagen-Diagnosesystems auch in bereits be- stehende Anlagen rückwirkungsfrei integriert werden kann.

Zusammengefasst betrifft die Erfindung somit ein Verfahren zur Generierung eines Systems zur Bereitstellung von Diagno- seinformationen 1, 2,3 sowie ein entsprechendes System. Um

die Bereitstellung von Informationen zur Diagnose von techni- schen Anlagen oder technischen Prozessen zu vereinfachen, wird vorgeschlagen, dass Komponenten 4 eines Automatisie- rungssystems 5, welche Diagnoseschnittstellen zur Bereitstel- lung von Diagnoseinformationen 1 zur Diagnose der jeweiligen Komponente 4 aufweisen, in mindestens einer Gruppe 6 zusam- mengefasst werden und dass die Bereitstellung von Diagnosein- formationen 2 der jeweiligen Gruppe 6 durch Verknüpfung der Diagnoseinformationen 1 der in der jeweiligen Gruppe 6 zusam- mengefassten 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 Engi- neering-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 Automat- sierung 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 bekann- te Profibus-Technologie vertikal erweitert wurde. Unter dem Begriff PROFInet entstand ein durchgängiges Konzept für die vertikale Daten-Integration. Dabei kommt aus Konsistenzgrün- den zu den höheren Ebenen eines Automatisierungssystems das Kommunikationsmittel Ethernet zum Zuge, wobei die Durchgän- gigkeit zur konventionellen Profibus-Technologie erhalten bleibt. Das PROFInet-Konzept umfasst drei Aspekte : Für die Projektierung von PROFInet-Systemen wurde ein herstellerüber- greifendes Engineering-Konzept definiert. Es baut auf einem Engineering-Objektmodell auf, mit dem sich nicht nur Projek- tierungswerkzeuge entwickeln lassen, welche die Komponenten unterschiedlicher Hersteller verwenden können, sondern bei

dem auch hersteller-bzw. anwenderspezifische Funktionserwei- terungen mittels sogenannter Facetten festgelegt werden kön- nen. 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 integ- rieren. Weiter spezifiziert PROFInet ein offenes objektorien- tiertes 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 Anwendungsbe- reiche mit harter Echtzeit ein dafür optimierter Kommunikati- onsmechanismus 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 Kommu- nikationsbeziehungen und den Austausch der Daten zwischen PROFInet-Teilnehmern sicher. Zudem verbirgt sich hinter dem Begriff PROFInet ein einheitliches objektbasiertes Architek- turkonzept für verteilte Automatisierungssysteme von der E/A- Ebene bis zur Leitebene, welches Systeme, die der konventio- nellen Profibus-Technologie folgen, nahtlos in das Gesamtsys- tem integriert. Die Integration von Profibus und anderer Feldbus-Systeme in ein PROFInet-System erfolgt mittels Pro- xies. Ein Proxy ist ein Software-Modul, das sowohl für die Teilnehmer am Profibus als auch gegenüber den übrigen PROFI- net-Teilnehmern am Ethernet stellvertretend die Funktionali- tät von Automatisierungsobjekten realisiert.

Durch die Spezifikation der genannten drei Aspekte deckt PRO- FInet alle Life-cycle-Phasen eines verteilten Automatisie- rungssystems ab. Das Thema Engineering ist derjenige Aspekt von PROFInet, der die größten Berührungspunkte zu den Anwen- dern der Technologie hat. Dies gilt gleichermaßen für die Systemdesigner wie auch Anlagenbetreiber. Es ist auch derje- nige 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 Jah- ren rückläufig sind und das Potenzial wohl weitgehend er- schö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 Enginee- ring-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 erweiter- bar, so dass Komponenten beliebiger Hersteller in einem Engi- neering-Werkzeug reibungslos zusammen arbeiten können. Die unterschiedlichsten Engineering-Aspekte wie Verschaltung, Pa- rametrierung, Test, Inbetriebnahme und Diagnose sind zur Ver- fü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 zusam- menspielen. 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 vorzu- stellen. 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 eindeu- tige Schnittstellen, die Interfaces des Objektes, erreichbar ist. Ein Interface ist die Zusammenfassung einer bestimmten Menge von Funktionen, durch die festgelegt ist, welche Leis- tung von einem Server (Dienstleister) für einen Client (Auf- traggeber) erbracht werden soll. In diesem Fall spricht man davon, dass eine Komponente das Interface implementiert. Die Art der Implementierung selbst wird dem Ersteller einer Kom- ponente 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 ein- fache 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 Projektier- werkzeug, die alle notwendigen Informationen für die voll- ständige Projektierung beinhalten : Die Engineering System Au- tomation 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 Au- tomatisierungsobjekt liegt, verfügt es über eine Entsprechung des Objekts in Gestalt des sogenannten Engineering System De- vice (ES-Device). Genau genommen entspricht das ES-Device ei- nem"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 Sammelbezeich- nung für alle Objekte im Kontext des Projektierwerkzeuges wird der Begriff Engineering System Object (ES-Object) ver- wendet. Es umfasst alles, was der Anwender während der Pro- jektierung wahrnimmt und alles, womit er hantiert. Es ist al- so die"Basisklasse"für die Engineering-Objekte. Durch das Instanzieren, Verschalten und Parametrieren der ES-Objects entsteht das Modell der Automatisierungslösung einer konkre- ten Anlage. Angestoßen durch einen Download wird unter Aus- wertung 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 PROFInet- konforme 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 reali- siert 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 ande- ren Objekten. Für die Parametrierung des Objektes wechselt der Benutzer in die Parametrierfacette. Die Zuordnung eines Automatisierungsobjektes zu einem physikalischen Gerät reali- siert 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 imp- lementiert, 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 Diag- noseinformationen des Gerätes in optimaler Weise darbieten.

In der Gerätezuordnungsfacette ist die Methode implementiert, welche die zu einem bestimmten Automatisierungsobjekt kompa- tiblen 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 Schnittstellenbeschrei- bungen 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 Enginee- ring-Werkzeug über definierte Schnittstellen ein. Dem Grund- gedanken der COM-Programmierung entsprechend, sind keine Imp- lementierungen vorgeschrieben, sondern lediglich eindeutige Schnittstellen definiert. Die PROFInet-Strategie sorgt dann dafür, dass die Kommunikation über den Bus reibungslos funk- tioniert, lässt aber andererseits den Herstellern alle Frei- heiten, sich durch eigene Implementierungen vom Wettbewerb zu differenzieren. Die Vorteile von PROFInet zeigen sich insbe- sondere im Engineering. Indem Kommunikation nicht mehr pro- grammiert werden muss, sondern projektiert werden kann, ver- einfacht sich die Erstellung einer Automatisierungslösung be- trächtlich. Die Wiederverwendung ausgetesteter Lösungen ver- kürzt Entwi cklungs-und Inbetriebnahmezeiten und kann dadurch zu einer deutlichen Kostenreduktion beitragen.

PROFInet ist ein durchgängiges Konzept für die vertikale Da- ten-Integration, wobei bewusst auf Profibus-spezifische Kom- munikationsmechanismen verzichtet und stattdessen auf offene

Standards gesetzt wurde, um eine Feldbus-unabhängige Kommuni- kation zu ermöglichen. Das PROFInet-Konzept definiert ein Ob- jektmodell 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 Laufzeit- system müssen die sieben Schichten des ISO/OSI-Referenz- modells festgelegt werden. Für die gleichberechtigte Kommuni- kation autarker Funktionseinheiten bietet sich hierzu Ether- net 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 darstel- len. 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 nahelie- gend, 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 Anwendun- gen. Es basiert auf dem Standard DCE RPC (Distributed Compu- ting Environment Remote Procedure Call). Einer der wichtigs- ten 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 implemen- tiert 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 sicht- bar wird und als Internet Draft veröffentlicht wurde. Inner- halb von Embedded-Geräten kann die Programmierung unverändert

bleiben. Insbesondere muss keine strenge COM-Architektur imp- lementiert sein. Alle Implementierungswege der Automatisie- rungsobjekte als COM-Objekte mit entsprechenden Interfaces werden zugelassen, solange nach außen hin der PROFInet- Objekteindruck gewahrt bleibt. Beispielsweise werden bei ei- ner Steuerung die Objekte in der für diese Steuerung notwen- digen 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 Er- gä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 auftei- len : Pflicht-Interfaces : Diese Interfaces definieren einen Stan- dard, den alle Ressourcen (Geräte) einer PROFInet-basierten Automatisierungslösung implementieren müssen. Neben den durch COM definierten Interfaces-wie die der Identifikation-ge- hö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äte- spezifischen Interfaces implementieren, bilden das Geräte- Objektmodell.

Anwendungsspezifische Interfaces : Hier werden die benötigten anwendungsspezifischen Automatisierungsobjekte mit Program- mierwerkzeugen entwickelt, die unter Umständen zielsystemspe- zifisch 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 physikali- schen 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 ei- gentlichen Programmträger, das heisst die Teile des Gerätes, die die eigentlichen PROFInet-Knoten darstellen. Die Unter- scheidung zwischen Physical und Logical Device ist bei Embed- ded-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 Detaildi- agnose.

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 Aufga- be, die das Objekt erfüllt. So hat etwa ein Hubtisch ein In- terface zum Verfahren des Tisches. Ein Interface kann dabei sowohl Daten (lesend, schreibend) als auch Methoden und E- vents enthalten.

Die Stellvertreter von LDev beziehungsweise RT-Auto im Engi- neering 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 Einrich- tung 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 (Consu- mer). Kommunikationsbeziehungen werden immer von der Consu- mer-Seite aus aufgebaut. Eine Daten-oder Event-Verschaltung zwischen zwei Objekten (beispielsweise zweier aufeinander folgender Förderelemente) kann einfach durch die Projektie- rung der Verbindung auf Consumer-Seite vorgegeben werden. Das ACCO sorgt dann selbstständig für die Einrichtung der Kommu- nikationsbeziehung und den Austausch der Daten. Ein wichtiger Aspekt des ACCO ist die Fehlerbehandlung. Diese umfasst die Übertragung von Quality Code und Timestamp mit den Werten so- wie der automatischen Aufschaltung eines projektierten Er- satzwertes im Fehlerfall. Weiter die Überwachung des Kommuni- kationspartners, den Reconnect nach Verbindungsverlust sowie die Diagnose und Testmöglichkeiten für Verschaltungen. Die Übertragung mit DCOM ist ereignisgesteuert, das heisst, der Provider überwacht seine Daten Änderung. Die unterlager- ten Schichten sorgen für eine Sicherung der Verbindung.