Verfahren zum Betrieb eines Automatisierungssystems Die Erfindung betrifft ein Verfahren zum Betrieb eines Auto ^¬ matisierungssystems, speziell eines Automatisierungssystems mit IO-Link Geräten, und ein Verfahren zur Handhabung solcher IO-Link Geräte, insbesondere in Bezug auf Konfiguration und Parametrierung .

Unter der für die PROFIBUS Nutzerorganisation e.V. eingetragenen Marke IO-Link ist ein Konzept zur einheitlichen Anbin- dung von Sensoren und Aktoren (z.B. Schaltgeräte) an eine Steuerungsebene mittels einer kostengünstigen Punkt-zu-Punkt Verbindung bekannt. Dieser Kommunikationsstandard unterhalb der Feldbusebene ermöglicht eine zentrale Fehlerdiagnose und -ortung bis zur Sensor-/Aktorebene . Als offene Schnittstelle lässt sich IO-Link in alle gängigen Feldbus- und Automatisie ^¬ rungssysteme integrieren. Im Folgenden wird auf das o.g. Kom- munikationssystem kurz als IO-Link Bezug genommen.

Die IO-Link Spezifikation (aktueller Versionsstand: V1.0, 2008/2009) beschreibt, wie IO-Link Geräte (IO-Link Devices) unterschiedlicher Gerätehersteller an eine Punkt— zu—Punkt Verbindung angeschlossen werden können. Für diese Geräte können entsprechend der Spezifikation Parameter, Diagnosen, etc. von und zu einem sogenannten IO-Link Master als übergeordneter IO-Link Einheit übertragen werden. Der Begriff Diagnose meint hier und im Folgenden einerseits eine Diagnoseinforma- tion als Ergebnis einer Überprüfung oder einer Statusabfrage des jeweiligen Gerätes und andererseits eine Beschreibung ei ^¬ ner Art und/oder eines Umfangs einer solchen Überprüfung oder Statusabfrage. Aber auch Messwerte (Ströme, Spannungen, Tem ^¬ peraturen, usw.), Statistikdaten (Betriebsstunden, usw.) Log- bücher, etc.. Die Beschreibung der IO-Link Geräte, insbesondere der jeweiligen Parameter, Diagnosen etc., erfolgt in einer dafür vorgesehenen Gerätebeschreibungsdatei (IODD). Die Gerätebeschreibung erlaubt jedoch nicht, modulare IO-Link Geräte, wie z.B. die von der Anmelderin angebotenen sogenannten Kompaktabzweige mit der Bezeichnung "SIRIUS 3RA6", zu mo ^¬ dellieren. Es können lediglich kompakte IO-Link Geräte be- schrieben werden. Informationen zur Modularität werden gerätespezifisch in nicht benötigten oder weniger relevanten Parametern oder Diagnoseinformationen (z.B. Fehlermeldungen, Lebensdauer, Endlage, etc.) gleichsam versteckt. Durch diese Einschränkung können modulare IO-Link Geräte in der Konfiguration und Diagnose einer IO-Link Engineeringsoftware (z.B. SIMATIC Step7) nur als kompaktes Gerät mit univer ^¬ seller Konfiguration, Diagnose etc. dargestellt werden. Sol ^¬ che Darstellungen sind damit oftmals irreführend oder sogar falsch. Zum Beispiel gibt eine zentrale Sammel-Fehler-LED keine Auskunft darüber, welche von mehreren Untereinheiten eines modularen IO-Link Gerätes gestört ist.

Weiterhin ist es insbesondere nicht möglich,

- die einzelnen Untereinheiten, nämlich Baugruppen oder Geräte, eines modularen IO-Link Gerätes aus einem Hardware ^¬ auswahlkatalog auszuwählen,

das modulare IO-Link Gerät durch übliche Benutzerhandlungen, wie drag & drop, zu konfigurieren und zwar weder gra- fisch noch tabellarisch,

die tatsächliche Gerätekonfiguration offline und online darzustellen,

einen Soll/Ist-Vergleich der Gerätekonfiguration durchzuführen,

- die Diagnoseanzeigen (z.B. Geräte-LEDs) der einzelnen Baugruppen/Geräte in der Online-Konfiguration darzustellen, die Größen der Prozessabbilder, nämlich des Prozessabbilds der Eingänge (PAE) und des Prozessabbilds der Ausgänge (PAA) , konsistent zu halten

- die Adresslänge und -Zuordnung abhängig vom Ausbau automa ^¬ tisch zu berechnen oder

eine Produktbild, das dem tatsächlichen Ausbau entspricht, anzuzeigen . Ein weiterer Nachteil ist, dass immer zwei unterschiedliche Entwicklungswerkzeuge für das IO-Link Engineering erforderlich sind, nämlich ein erstes Entwicklungswerkzeug, z.B. die unter der Bezeichnung STEP7 bekannte Engineeringsoftware der Anmelderin, für die Projektierung des IO-Link Masters im Automatisierungssystem und ein zweites Entwicklungswerkzeug für die Projektierung des IO-Link Masters selbst und der damit kommunikativ verbundenen IO-Link Geräte.

Im Folgenden wird zu Illustrationszwecken die Projektierung eines IO-Link Systems als Bestandteil eines Automatisierungs ^¬ systems mit den Entwicklungswerkzeugen der Anmelderin, nämlich dem unter der Bezeichnung SIMATIC Step7 bekannten Entwicklungswerkzeug (erstes Entwicklungswerkzeug) einerseits und dem unter der Bezeichnung Port Configuration Tool (S7- PCT) bekannten Entwicklungswerkzeug (zweites Entwicklungs ^¬ werkzeug) andererseits, beschrieben.

Folgende Schritte sind beim Projektieren eines IO-Link Sys ^¬ tems in der Engineeringsoftware auszuführen:

1) Konfiguration des IO-Link Masters im ersten Entwicklungswerkzeug, z.B. durch sogenanntes drag & drop eines IO-Link Masters in die Hardwarekonfiguration des ersten Entwicklungswerkzeugs, z.B. in ein dort angelegtes Automatisie ^¬ rungsgerät in Form einer speicherprogrammierbaren Steuerung oder dergleichen.

2) Parametrieren des IO-Link Masters im ersten Entwicklungswerkzeug. Hier gibt der Anwender die E/A-Adressen (Anfang und Länge) und die Diagnoseparameter des IO-Link Masters ein. Für die Bestimmung der Länge der E/A-Adressen muss der Anwender exakt Anzahl und Typ der verwendeten Ports bzw. IO-Link Geräte wissen. Bei modularen IO-Link Geräten wird das Problem dadurch verstärkt, dass die Größe der Prozessabbilder der Eingänge und der Ausgänge wiederum von den verwendeten Baugruppen/Geräten abhängt. Eine Unterstützung seitens des ersten Entwicklungswerkzeugs ist nicht gegeben, da bei modularen IO-Link Geräten die davon umfassten Untereinheiten nicht bekannt sind. Dadurch ist die Adressvergabe fehleranfällig. ) Konfiguration der IO-Link Geräte im zweiten Entwicklungswerkzeug durch Aufruf des zweiten Entwicklungswerkzeugs, z.B. direkt aus dem ersten Entwicklungswerkzeug, und durch sogenanntes drag & drop der IO-Link Geräte in eine vom zweiten Entwicklungswerkzeug umfasste Port-Konfiguration. Dafür lassen sich IO-Link Geräte, wenn verfügbar, mit einer Gerätebeschreibungsdatei integrieren. ) Parametrieren der IO-Link Geräte im zweiten Entwicklungswerkzeug durch Selektion des jeweiligen Ports/IO-Link Gerätes und Eingabe der Geräte-Parameter. Bei modularen IO- Link Geräten wird die Konfiguration umfasster Untereinheiten "versteckt" bei den Geräteparametern eingegeben. Die einzelnen Baugruppen/Geräte des modularen IO-Link Gerätes - hier und im Folgenden als Untereinheit oder IO-Link SubDevice bezeichnet - können nicht im Hardwareauswahlkatalog ausgewählt werden. Eine grafische Projektierung mittels drag & drop der einzelnen Untereinheiten ist ebenfalls nicht möglich. ) Download der Parameter in den IO-Link Master und die einzelnen IO-Link Geräte mittels des ersten Entwicklungswerkzeugs aufgrund einer vorherigen Übergabe der Parameter der IO-Link Geräte im Zusammenhang mit einer Beendigung des zweiten Entwicklungswerkzeugs. Die Parameter werden in der Datenhaltung des ersten Entwicklungswerkzeugs abgespei ^¬ chert. Beim Download werden die Geräteparameter auf eine Zentraleinheit eines Automatisierungsgerätes geladen, das diese dann beim Anlauf an den IO-Link Master und an die IO-Link Geräte überträgt. ) Diagnose des IO-Link System im ersten Entwicklungswerkzeug durch Auslesen und Anzeigen der Systemdiagnose-Informatio ^¬ nen aller erreichbaren Baugruppen. Beim IO-Link Master ist dies die Sammeldiagnoseinformation des Masters (stimmt mit dem Status einer dafür vorgesehenen LED des IO-Link Master überein) und die Diagnoseinformation der Ports/der IO-Link Geräte. Bei modularen IO-Link Geräten kann diese einzelne Diagnoseinformation nicht die evtl. unterschiedlichen Sta- ti der LEDs der einzelnen IO-Link-SubDevices (Untereinhei ^¬ ten; Abzweige) repräsentieren.

7) Um bei modularen IO-Link Geräten eine exakte Diagnosein- formation zu erhalten, muss der Anwender in das zweite

Entwicklungswerkzeug wechseln und sich dort die Geräte ^¬ diagnose anzeigen lassen. Hier wird bei modularen IO-Link Geräten der Status der LEDs durch die erhältliche Diagno ^¬ seinformation (Sammelfehler, Sammelwarnung,...) repräsen- tiert. Neben Diagnoseinformationen sind die Ein-/Ausgänge der einzelnen Untereinheiten sichtbar.

Eine erste Aufgabe des hier vorgestellten Ansatzes besteht darin, die Handhabung modularer IO-Link Geräte und deren Ver- wendung in einem Automatisierungssystem zu erleichtern.

Diese Aufgabe wird mit einem Verfahren mit den in Anspruch 1 zusammengefassten Merkmalen gelöst. Dazu ist bei einem Verfahren zum Betrieb eines Automatisierungssystems, wobei das Automatisierungssystem in kommunikativer Verbindung eine übergeordnete IO-Link Einheit, z.B. einen IO-Link Master, und zumindest ein modulares IO-Link Gerät mit einem geräteinternen Bus und darüber ansprechbaren, von dem modularen IO-Link Gerät umfassten Untereinheiten umfasst, vorgesehen, dass zur Kommunikation mit dem modularen IO-Link Gerät eine von dessen Untereinheiten ausgewählt wird und die Kommunikation nur mit dieser direkt und über diese indirekt mit den anderen Untereinheiten des modularen IO-Link Gerätes erfolgt. Eine weitere Aufgabe des hier vorgestellten Ansatzes besteht ausgehend vom Unfang und von der Komplexität der bisher erforderlichen Verfahrensschritte bei der Konfiguration und Pa- rametrierung modularer IO-Link Geräte darin, deren Handhabung bei der Konfiguration, Parametrierung und/oder Diagnose zu erleichtern .

Ein modulares IO-Link Gerät ist ein "pseudomodulares Kompakt- gerät", d.h. es umfasst mehrere hier als Untereinheiten oder Abzweige bezeichnete Module (IO-Link SubDevices), die über einen geräteinternen Bus verbunden sind. Als Beispiel kann auf das von der Anmelderin unter der Bezeichnung "Kompaktabzweig SIRIUS 3RA6" angebotene Gerät verwiesen werden. Die einzelnen Untereinheiten sind bisher aber nach außen nicht sichtbar und nicht direkt ansprechbar, nämlich weil sie keine Adresse haben, keinen Port im IO-Link Modell belegen, keine Diagnoseinformationen liefern, usw.. Durch folgende technischen Merkmale lassen sich die oben skizzierten Probleme beseitigen:

1) Erweiterung eines IO-Link Objektmodells um Untereinheiten (IO-Link SubDevices)

2) Modellierung solcher Untereinheiten in der Gerätebeschrei- bung (z.B. IODD)

3) Grafische oder tabellarische Darstellung der Modularität von modularen IO-Link Geräten in genau einem Entwicklungswerkzeug . Entsprechend wird die weitere Aufgabe mit einem Verfahren mit den in Anspruch 2 zusammengefassten Merkmalen gelöst. Dazu ist bei einem Automatisierungssystem oder einem Verfahren zum Konfigurieren oder Parametrieren eines modularen IO-Link Gerätes in einem solchen Automatisierungssystem vorgesehen, dass beim Anlegen eines modularen IO-Link Gerätes in einem

Entwicklungswerkzeug ein erstes Objekt zur Repräsentation des modularen IO-Link Gerätes, ein zweites Objekt zur Repräsenta ^¬ tion eines in dem modularen IO-Link Gerät die Untereinheiten umfassenden oder aufnehmenden IO-Link Baugruppenrahmens, ein drittes Objekt zur Repräsentation der ausgewählten und als IO-Link Kopfbaugruppe fungierenden Untereinheit und mindes ^¬ tens ein viertes Objekt für jede weitere Untereinheit des mo ^¬ dularen IO-Link Gerätes angelegt wird. Das erste, zweite, dritte und vierte Objekt oder die jeweils zugrunde liegenden Objekttypen stellen die Erweiterung eines IO-Link Objektmodells dar. Das Anlegen eines Objekts zur Repräsentation des modularen IO-Link Gerätes und eventueller weiterer Objekte erfolgt dabei mit dem Entwicklungswerkzeug für eine Automati ^¬ sierungslösung zur Steuerung und/oder Überwachung eines technischen Prozesses. Die Automatisierungslösung umfasst das Automatisierungssystem und insoweit auch das IO-Link System als Bestandteil des Automatisierungssystems mit zumindest einem IO-Link Master und einem modularen IO-Link Gerät aber auch

Software zur Festlegung der Funktionalität der einzelnen Einheiten des Automatisierungssystems und deren Konfiguration, Parametrierung, usw..

Die hier vorgeschlagene Lösung basiert darauf, dass eine der Untereinheiten die Kommunikation über IO-Link nach außen übernimmt und damit quasi als Stellvertreter für das gesamte modulare IO-Link Gerät fungiert. Diese Untereinheit wird im Folgenden zur Unterscheidung auch als Kopfbaugruppe bezeichnet. Die Kopfbaugruppe kann eine vorgegebene Untereinheit, z.B. ein Kommunikationsmodul, oder eine beliebige Unterein ^¬ heit des modularen IO-Link Gerätes sein, die die kommunikati ^¬ ve Anbindung des modularen IO-Link Gerätes übernimmt und da ^¬ mit als Kopfbaugruppe fungiert. Nur diese Kopfbaugruppe benö ^¬ tigt Informationen hinsichtlich des internen Aufbaus des IO- Link Gerätes. Auf dieser Basis werden die von dem IO-Link Gerät umfassten Untereinheiten von der Kopfbaugruppe über einen völlig internen Mechanismus angesprochen. Das Vorhandensein der Untereinheiten wirkt sich nur auf die technologischen Funktionen des modularen IO-Link Gerätes aus, indem die Funktionen dieser Untereinheiten (durch Parameter, Diagnose, Prozessabbilder, ... ) freigeschaltet oder in sonst geeigneter Weise aktiviert werden. Dafür ist die Erweiterung des IO-Link Objektmodells um solche Untereinheiten notwendig. Das erweiterte Objektmodell erlaubt an der Oberfläche genau eines Entwicklungswerkzeugs ein modu- lares IO-Link Gerät als modulares Gerät mit einer Mehrzahl von Untereinheiten hantieren zu können. Damit können im Entwicklungswerkzeug alle vom modularen IO-Link Gerät umfassten Untereinheiten im Gerätekatalog selektiert und in der Geräte ^¬ sicht dem modularen IO-Link Gerät hinzugefügt werden, z.B. durch drag & drop.

Im Folgenden werden die wesentlichen Besonderheiten des erweiterten Objektmodells und die dafür vorgesehenen Objekte beschrieben. Grundvoraussetzung des erweiterten Objektmodells ist, dass ein modulares IO-Link Gerät stets durch eine Zusam ^¬ menfassung folgender Objekte modelliert wird: ein (erstes) Objekt für ein IO-Link Gerät, ein (zweites) Objekt für einen IO-Link Baugruppenrahmen, ein (drittes) Objekt für eine IO- Link Kopfbaugruppe und mindestens ein (viertes) Objekt für eine Untereinheit des modularen IO-Link Gerätes. Im Folgenden wird nicht immer auf ein Objekt als Repräsentant einer physi ^¬ kalischen Einheit hingewiesen, so dass z.B. anstelle an sich vollständiger Ausdrücke wie "Objekt zur Modellierung des IO- Link Gerätes" kurz auch nur "IO-Link Gerät" geschrieben wird. Aus dem Kontext ergibt sich dabei jeweils, ob ein Objekt als Repräsentant der physikalischen Einheit oder die physikali ^¬ sche Einheit selbst gemeint ist.

Vorteilhafte Ausgestaltungen des Ansatzes sind Gegenstand der Unteransprüche. Dabei verwendete Rückbeziehungen weisen auf die weitere Ausbildung des Gegenstandes des Hauptanspruches durch die Merkmale des jeweiligen Unteranspruches hin; sie sind nicht als ein Verzicht auf die Erzielung eines selbstän ^¬ digen, gegenständlichen Schutzes für die Merkmalskombinatio- nen der rückbezogenen Unteransprüche zu verstehen. Des Weiteren ist im Hinblick auf eine Auslegung der Ansprüche bei ei ^¬ ner näheren Konkretisierung eines Merkmals in einem nachgeordneten Anspruch davon auszugehen, dass eine derartige Beschränkung in den jeweils vorangehenden Ansprüchen nicht vor- handen ist.

Das Objekt zur Modellierung des IO-Link Gerätes ist dasjenige Objekt, das in einer Mastersicht (IO-Link Mastersicht) zur Darstellung des IO-Link Gerätes angezeigt wird. Das Objekt zur Modellierung des IO-Link Baugruppenrahmens ist ein Container für die von dem modularen IO-Link Gerät umfassten Untereinheiten, die damit in der Gerätesicht des Entwicklungs- Werkzeugs konfiguriert werden können. Über die Relationen des Objekts zur Modellierung des IO-Link Baugruppenrahmens zu der oder jeder Untereinheit werden erste Steckplatzregeln abgebildet, nämlich solche Steckplatzregeln, die bereits beim Kombinieren eines Objekts zur Modellierung einer Untereinheit mit dem IO-Link Baugruppenrahmen geprüft werden können.

Das Objekt zur Modellierung der Kopfbaugruppe fungiert als Stellvertreter für ein modulares IO-Link Gerät. Es repräsentiert die eigentliche technologische Funktionalität des modu- laren IO-Link Gerätes und ist Träger der meisten Geräteeigenschaften (Geräteparameter, Länge der Eingangs- und Ausgangsadresse, Gerätediagnosen, usw.). Ein modulares IO-Link Gerät ist ein pseudomodulares System, d.h. es kann mit Untereinhei ^¬ ten konfiguriert werden. Anders als bei echten modularen Sys- temen haben diese aber keine eigenen Parameter und entsprechend keine eigenen Anlaufdaten. Stattdessen ändert eine Untereinheit die Eigenschaften des modularen IO-Link Gerätes und die Eigenschaften des das modulare IO-Link Gerät model ^¬ lierenden Objektes, z.B. die Sichtbarkeit von Parametern. Da- zu muss die Kopfbaugruppe Informationen darüber haben, welche Untereinheiten aktuell konfiguriert sind. Diese Information kann über Objektreferenzen aus der Gerätebeschreibung ermittelt werden. Die Kopfbaugruppe ist das einzige Objekt, für das es in jedem Fall eine physikalische Entsprechung gibt. Die Kopfbaugruppe repräsentiert das modulare IO-Link Gerät an der Oberfläche des Entwicklungswerkzeugs. Daher ist es auch das Objekt, das als Bezeichnung zum Beispiel eine Bestellnummer (MLFB) eines IO-Link Gerätes trägt und damit über den Hardwarekatalog vom Anwender erzeugt werden kann. Alle anderen Objekte (IO-Link Baugruppenrahmen, IO-Link Gerät, IO-Link Untereinheit) werden dann zusätzlich implizit erzeugt. Die zur Parametrierung, Diagnose, Adressvergabe, etc. rele ^¬ vanten Aktionen und Dialoge sind über die Kopfbaugruppe, näm ^¬ lich das Kopfbaugruppenobjekt, erreichbar. Zusätzlich umfasst das Kopfbaugruppenobj ekt die Funktionalität zur Einbindung einzelner oder mehrerer Untereinheiten und die Funktionalität zur Anbindung an den IO-Link Master, d.h. einen dafür vorgesehenen IO-Link Port (Node) . Objekte zur Verwaltung von Adressinformationen (Adressobjekte) und der IO-Link Port (Node) sind Standardobjekte und werden automatisch erzeugt, wenn die Gerätebeschreibung entsprechende Attribute enthält, ebenso wie die Verlinkung zum IO-Link Mastersystem. Eine Untereinheit eines modularen IO-Link Gerätes hat außer einem Icon in der Gerätesicht und den Standarddialogen für Projektinforma ^¬ tionen keine eigene Oberfläche, keine eigenen Geräteparameter und auch keine Beziehungen zum IO-Link System.

In einer Ausführungsform des Verfahrens ist entsprechend vor ^¬ gesehen, dass beim Anlegen eines Objekts für ein modulares IO-Link Gerät automatisch ein Objekt für die ausgewählte und als IO-Link Kopfbaugruppe fungierende Untereinheit des modu ^¬ laren IO-Link Gerätes und/oder ein Objekt für den IO-Link Baugruppenrahmen des modularen IO-Link Gerätes, insbesondere auch und ebenfalls automatisch eine Verschaltung zwischen diesen Objekten, angelegt wird. Dies reduziert auf der einen Seite ansonsten manuell erforderliche Verfahrensschritte und sichert auf der anderen Seite die Konsistenz der Darstellung des Automatisierungssystems im Entwicklungswerkzeug, indem sichergestellt ist, dass bei einem modularen IO-Link Gerät die Anbindung an IO-Link ausschließlich über die als Kopfbau- gruppe ausgewählte Untereinheit erfolgt und indem weiter si ^¬ chergestellt ist, dass Repräsentanten für das die Kopfbau ^¬ gruppe umfassende IO-Link Gerät selbst und den IO-Link Bau ^¬ gruppenrahmen zur Verfügung stehen. Der hier beschriebene Ansatz umfasst auch eine Modellierung von IO-Link Untereinheiten in der Gerätebeschreibung. Derzeit - also gemäß dem Stand der Technik - sind in der Gerätebe ^¬ schreibung nur das IO-Link Gerät und seine Eigenschaften (Pa- rameter, Diagnosen, ... ) beschrieben. Etwaige IO-Link Untereinheiten werden soweit möglich durch Geräteparameter er- fasst . Nachfolgend ist dazu eine beispielhafte Gerätebeschreibung gemäß dem Stand der Technik für das weiter oben bereits erwähnte Gerät der Anmelderin, nämlich Kompaktabzweig SIRIUS 3RA6, eingeblendet:

<Text id= "TI DS130 Bytel2" value=" Startertyp

<Text id= "TI DS130 BGID DS _010- 040"

value= "Direktstarter DS 0,1 ... 0,4 A" />

<Text id= "TI DS130 BGID DS _032- 125"

value= "Direktstarter DS 0, 32 • · · 1^25 A.

<Text id= "TI DS130 BGID DS _100- 400"

value= "Direktstarter DS 1 .. . 4 A" />

<Text id= "TI DS130 BGID DS _300- 1200"

value= "Direktstarter DS 3 .. . 12 A" />

<Text id= "TI DS130 BGID DS _800- 3200"

value= "Direktstarter DS 8 .. . 32 A" />

<Text id= "TI DS130 BGID RS _010- 040"

value= "Wendestarter RS 0,1 . .. 0,4 A" />

<Text id= "TI DS130 BGID RS _032- 125"

value= "Wendestarter RS 0, 32 ... 1,25 A" /

<Text id= "TI DS130 BGID RS _100- 400"

value= "Wendestarter RS 1 4 A" />

<Text id= "TI DS130 BGID RS _300- 1200"

value= "Wendestarter RS 3 12 A" />

<Text id= "TI DS130 BGID RS _800- 3200"

value= "Wendestarter RS 8 ... 32 A" />

Zur Modellierung eines modularen IO-Link Gerätes mit IO-Link wird gemäß dem hier vorgeschlagenen Ansatz nicht nur das Objektmodell sondern auch die Gerätebeschreibung erweitert und zwar zumindest um

eine Beschreibung aller Objekte des Objektmodells, nämlich IO-Link Gerät, IO-Link Baugruppenrahmen, IO-Link Kopfbaugruppe und IO-Link Untereinheit, Beschreibung der Gerätekonfiguration: Anzahl Steckplätze, steckbare Gerätetypen, usw.

verwendbare Typen von IO-Link Untereinheiten,

Beschreibung der IO-Link Untereinheit für die Darstellung im Hardwarekatalog und

Steckplatzregeln.

Hinsichtlich der Steckplatzregeln kommt in Betracht, nur sogenannte harte Steckplatzregeln abzudecken, wobei hart in diesem Zusammenhang bedeutet, dass eine Auswahl einer IO-Link Untereinheit und deren Kombination mit dem modularen IO-Link Gerät aus dem Hardwarekatalog verhindert wird.

Im Folgenden werden nur die wichtigsten Attribute beschrie- ben, die für die Abbildung des erweiterten IO-Link Objektmodells in der Gerätebeschreibung erforderlich sind. Wenn beispielhaft konkrete Werte aufgeführt werden, sind dies oftmals Werte des bereits erwähnten Gerätes, nämlich des Kompaktab ^¬ zweigs SIRIUS 3RA6. Die Geräteparameter und -diagnosen können dabei in der gleichen Art und Weise wie bereits derzeit in der Gerätebeschreibung vorgesehen beschrieben werden (Byte- Offset, Bit-Offset, Datentyp, Länge, Defaultwert, ID, ... ) .

Allgemeine Attribute aller Objekte:

VARIABLE Comment;

// Gerätespezifischer Kommentar,

// z.B. "Förderband Halle 3, Motor 12"

VARIABLE Name;

// Gerätespezifischer Name,

// z.B. "Conveyer23. Starter07"

VARIABLE MLFB;

// Bestellnummer, z.B. "3RA6234-0AA1-0BBX"

VARIABLE ObjectType;

// Typ des Objekts

VARIABLE Objectld;

// Eindeutige Identifikationsnummer des Objekts Attribute für Objekte zur Modellierung eines IO-Link Gerätes:

VARIABLE ObjectType;

// Typ des Objekts = IO_LINK_DEVICE

// (eindeutige Objekttypnummer, Konstante)

VARIABLE Objectld;

// Identifikationsnummer des Objekts,

// z.B. SIRIUS_3RA6 (eindeutige Objektnummer, Konstante) VARIABLE ContainerSize : 1 ;

// ein IO-Link-Device enthält immer ein Rack

VARIABLE TypeName;

/ / zur Anzeige im Entwicklungswerkzeug,

// z.B. "Kompaktabzweig SIRIUS 3RA6" Attribute für Objekte zur Modellierung eines IO-Link Baugrup ^¬ penrahmens :

VARIABLE ObjectType;

// Typ des Objekts = IO_LINK_DEVICE_RACK

// (eindeutige Objekttypnummer, Konstante)

VARIABLE Objectld;

// Identifikationsnummer des Objekts, z.B.

// SIRIUS_3RA6_3RA6 (eindeutige Objektnummer, Konstante) VARIABLE ContainerSize: 4;

// Anzahl der verfügbaren Steckplätze im Rack;

// beim Kompaktabzweig SIRIUS 3RA6 z.B. 4

Attribute für Objekte zur Modellierung einers IO-Link Kopf ^¬ baugruppe :

VARIABLE ObjectType;

// Typ des Objekts = IO_LINK_HEAD_DEVICE

// (eindeutige Objekttypnummer, Konstante)

VARIABLE Objectld;

// Identifikationsnummer des Objekts, z.B.

// SIRIUS_3RA6_HEAD (eindeutige Objektnummer, Konstante) VARIABLE PositionNumber;

// Die aktuelle Slotnummer der Kopfbaugruppe, beim

// Kompaktabzweig SIRIUS 3RA6 von 0 bis 3

VARIABLE UICapabilities : 0 ;

// 0 = das Modul ist virtuell und wird im

// Entwicklungswerkzeug nicht angezeigt

VARIABLE InAddressRange ;

VARIABLE OutAddressRange ;

// Größe der Ein- und Ausgangsadressen des Slaves im // Adressraum der SPS/des IO-Link Mastersystems

// z.B. beim Kompaktabzweig: 8 = 8 Byte, 16 = 16 Byte VARIABLE PARAMETER_17 ;

// Ein Geräteparameter des IO-Link Gerätes, analog der

// Spezifikation der IODD

VARIABLE DIAGNOS I S_27 ;

// Eine Gerätediagnose des IO-Link-Devices ,

// analog Spezifikation der IODD

Attribute für Objekte zur Modellierung einers IO-Link Unter- einheit:

VARIABLE ObjectType;

// Typ des Objekts = IO_LINK_SUB_DEVICE

// (eindeutige Objekttypnummer, Konstante)

VARIABLE Objectld;

// Identifikationsnummer des Objekts, z.B.

// SIRIUS_DIRECTSTARTER_3_12A

// (eindeutige Objektnummer, Konstante)

VARIABLE PositionNumber:

// die aktuelle Slotnummer des Moduls, beim

// Kompaktabzweig SIRIUS 3RA6 von 0 bis 3

VARIABLE TypeCode;

// u.a. für die Parametrierung . Z.B.

// Bit 15 == 1

// (Baugruppe nicht parametrierbar)

// Bit 15 == 0

// (Baugruppe ist parametrierbar) VARIABLE FWMainVersion : 1 ;

VARIABLE FWVersion: "V1.0";

// Firmwareversion

VARIABLE UICapabilities : 1 ;

// 1 = das Modul wird im Entwicklungswerkzeug angezeigt

Auf Basis des hier beschriebenen erweiterten IO-Link Objektmodells und der ebenfalls erweiterten, das erweiterte IO-Link Objektmodell abbildenden Gerätebeschreibung kann im Entwick- lungswerkzeug ein modulares IO-Link Gerät mit allen davon um- fassten Untereinheiten dargestellt werden. Die Darstellung umfasst zumindest eine Möglichkeit zur Diagnose einzelner IO- Link Untereinheiten mit der Anzeige der Ergebnisse der Diagnose. Sodann umfasst die Darstellung eine Anzeige eines Aus- baus und/oder einer Konfiguration des modularen IO-Link Gerätes mit seinen Untereinheiten und zwar tabellarisch und/oder grafisch. Schließlich umfasst die Darstellung auch eine Unterstützung des Hardwarekatalogs bei der Geräteauswahl. Durch die Erweiterung des Objektmodells und der Gerätebe ^¬ schreibung für IO-Link sowie der grafischen Darstellung im Entwicklungswerkzeug ist es nun zumindest möglich,

die einzelnen Untereinheiten eines modularen IO-Link Gerätes aus einem Hardwareauswahlkatalog auszuwählen,

- das modulare IO-Link Gerät durch drag & drop zu konfigu ^¬ rieren (grafisch oder tabellarisch) ,

eine jeweils tatsächliche Gerätekonfiguration offline und online darzustellen,

einen Soll/Ist-Vergleich der Konfiguration durchzuführen, - von den einzelnen Untereinheiten erhaltene oder erhältliche Diagnoseinformationen an der jeweiligen Untereinheit in der Hardwarekonfiguration darzustellen,

die Größen der Prozessabbilder der Eingänge und der Ausgänge (PAE bzw. PAA) konsistent zu halten,

- die Adresslänge und -Zuordnung abhängig vom Ausbau automa ^¬ tisch zu berechnen,

ein Produktbild, das dem tatsächlichen Ausbau entspricht, anzuzeigen und eine vollständige und korrekte Kundendokumentation anzu ^¬ zeigen .

Dadurch wird die gesamte Projektierung eines IO-Link Systems für den Kunden effizienter und weniger fehleranfällig. Insgesamt werden weniger Schritte für die Projektierung benötigt und die Projektierung des gesamten IO-Link Systems kann nun durchgängig mit einem Entwicklungswerkzeug erfolgen. Damit ergeben sich in einem Entwicklungswerkzeug der Anmelde ^¬ rin die folgenden erforderlichen Schritte beim Projektieren eines IO-Link Systems, wobei sich bei anderen Entwicklungs ^¬ werkzeugen ähnliche oder vergleichbare Abläufe ergeben wer ^¬ den :

1) Konfiguration des IO-Link Masters

Alle von der Anmelderin verfügbaren IO-Link Master sind bereits im Hardwareauswahlkatalog enthalten. Eine Auswahl eines konkreten IO-Link Masters erfolgt z.B. durch drag & drop des ausgewählten Gerätes in die Hardwarekonfiguration.

Die Parameter des IO-Link Masters können sodann im Entwicklungswerkzeug über ein Eigenschaftsfenster des den IO-Link Masters repräsentierenden Objekts eingestellt werden.

2) Konfiguration der IO-Link Geräte

Alle von der Anmelderin verfügbaren IO-Link Geräte sind bereits im Hardwareauswahlkatalog enthalten. Zertifizierte Ge ^¬ räte von Drittanbietern lassen sich mittels ihrer in der Fachterminologie als IODD bezeichneten Gerätebeschreibungsda ^¬ tei in die vom Entwicklungswerkzeug verwendete Datenbasis in ^¬ tegrieren. Die Auswahl eines konkreten IO-Link Gerätes erfolgt z.B. durch drag & drop des ausgewählten Gerätes in eine Konfigurationsapplikation .

Die Parameter des IO-Link Gerätes können sodann im Entwicklungswerkzeug über ein Eigenschaftsfenster des das IO-Link Gerät repräsentierenden Objekts eingestellt werden. 3) Konfiguration der IO-Link Untereinheiten

IO-Link Untereinheiten (Subdevices, Abzweige) können im Hardwareauswahlkatalog ausgewählt werden. Eine grafische Projek ^¬ tierung mittels drag & drop der einzelnen IO-Link Unterein- heiten ist nun möglich.

Modulare IO-Link Geräte werden in der Gerätesicht der Hard ^¬ warekonfiguration konfiguriert. Da hier Anzahl und Typ der verwendeten IO-Link Geräte und der Untereinheiten bekannt sind, können ein Anfang und eine Länge eines Datenbereichs mit E/A-Adressen automatisch bestimmt werden.

Die Parameter jeder IO-Link Untereinheit können im Entwicklungswerkzeug über ein Eigenschaftsfenster des die IO-Link Untereinheit repräsentierenden Objekts eingestellt werden.

4) IO-Link Diagnose

Die Diagnoseinformationen aller Baugruppen werden ausgelesen und angezeigt. Bei einer für einen IO-Link Master abgerufenen Diagnoseninformation ist dies die Sammeldiagnose des Masters (die Diagnoseinformation korrespondiert mit dem Status einer LED auf dem IO-Link Master) oder eine Diagnoseinformation bezüglich der für den IO-Link Master erreichbaren IO-Link Geräte .

5) Diagnose modularer IO-Link Geräte

Bei modularen IO-Link Geräten korrespondiert ein jeweiliger Status der Geräte-LEDs mit den entsprechenden von der Diagno ^¬ seinformation umfassten Daten (Sammelfehler, Sammelwarnung, etc.) . Die Diagnoseinformationen und ein Status der Ein/Aus ^¬ gänge der einzelnen Untereinheiten sind sichtbar.

Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand der Zeichnung näher erläutert. Einander entsprechende Gegen- stände oder Elemente sind in allen Figuren mit den gleichen Bezugszeichen versehen. Es zeigen

FIG 1 ein Automatisierungssystem mit mehreren IO-Link Geräten,

FIG 2 ein IO-Link Gerät in einer Ausführungsform als modu- lares IO-Link Gerät,

FIG 3 eine Darstellung von IO-Link Geräten durch ein Ent- wicklungswerkzeug und

FIG 4 ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Anlegen von Objekten in dem Entwicklungswerkzeug für IO-Link Geräte.

FIG 1 zeigt schematisch stark vereinacht ein Automatisie ^¬ rungssystem 10 zur Steuerung und/oder Überwachung eines nicht näher dargestellten industriellen technischen Prozesses 12. Das Automatisierungssystem 10 umfasst zumindest ein Automati- sierungsgerät 14, z.B. eine speicherprogrammierbare Steue ^¬ rung. Dieses umfasst zur Anbindung von Sensoren und/oder Aktoren über den als IO-Link bekannten Kommunikationsstandard einen IO-Link Master 16. An den IO-Link Master 16 sind in an sich bekannter Art und Weise über Punkt-zu-Punkt Verbindungen IO-Link Geräte 18, 20, 22 angeschlossen. Bei zumindest einem der angeschlossenen IO-Link Geräte 18, 20, 22 handelt es sich um ein modulares IO-Link Gerät 20, das - wie FIG 2 schema ^¬ tisch vereinfacht zeigt - eine Mehrzahl von IO-Link Untereinheiten umfasst. FIG 2 zeigt darüber hinaus, dass das IO-Link Gerät 20 ein oder mehrere IO-Link Untereinheiten 24, 26, 28 umfassen kann, von denen genau eine als Kopfbaugruppe 24 fungiert. Zur Aufnahme der Untereinheiten 24, 26, 28 weist das IO-Link Gerät 20 Steckplätze auf und innerhalb des IO-Link Gerätes 20 verläuft in einem Baugruppenrahmen 30 zu jedem Steckplatz ein geräteinterner Bus 32, so dass alle von einem IO-Link Gerät 20 umfassten Untereinheiten kommunikativ verbunden und speziell für die Kopfbaugruppe erreichbar sind. Der IO-Link Master 16, die IO-Link Geräte 18, 20, 22 und die zur kommunikativen Verbindung dieser Einheiten vorgesehenen Punkt-zu-Punkt Verbindungen bilden zusammen das IO-Link System (FIG 1), in dem der IO-Link Master 16 als übergeordnete Einheit fungiert. Zur Kommunikation mit dem IO-Link Master 16 wird eine von der Untereinheiten 24, 26, 28 des modularen IO- Link Gerätes 20 als Kopfbaugruppe 24 ausgewählt. Die Kommuni ^¬ kation mit dem IO-Link Master 16 erfolgt nur mit dieser Kopfbaugruppe 24 direkt. Alle von dem modularen IO-Link Gerät 20 umfassten Untereinheiten 24, 26, 28 sind in dem IO-Link System über diese Kopfbaugruppe 24 indirekt, nämlich ausgehend von der Kopfbaugruppe 24 über den geräteinternen Bus 32, erreichbar . Zur Konfiguration, Parametrierung, Diagnose, usw. von IO-Link Geräten wird ein als Software verfügbares Entwicklungswerkzeug 34 (FIG 1) verwendet. Diese Software kann auf einem Pro ^¬ grammiergerät 36 (FIG 1) oder dergleichen ausgeführt werden, das zumindest temporär direkt oder indirekt, z.B. über Inter- net, an das Automatisierungssystem 10 anschließbar ist. Das Programmiergerät 36, z.B. ein Personalcomputer, weist dafür in an sich bekannter Art und Weise einen Speicher 38 und eine Verarbeitungseinheit nach Art eines Mikroprozessors (nicht dargestellt ) auf . Wenn das Entwicklungswerkzeug 34 in den Speicher 38 geladen ist, kann es durch die Verarbeitungseinheit ausführt werden.

FIG 3 zeigt dazu schematisch vereinfacht eine mögliche Dar ^¬ stellung des IO-Link Objektmodells. Gezeigt ist, dass beim Anlegen eines modularen IO-Link Gerätes 20 mit dem Entwicklungswerkzeug 34 ein erstes Objekt 40 zur Repräsentation des modularen IO-Link Gerätes 20, ein zweites Objekt 42 zur Rep ^¬ räsentation des in dem modularen IO-Link Gerät 20 die Untereinheiten 24,26, 28 umfassenden oder aufnehmenden IO-Link Baugruppenrahmens 30, ein drittes Objekt 44 zur Repräsentati ^¬ on der ausgewählten und als IO-Link Kopfbaugruppe 24 fungie ^¬ renden Untereinheit und mindestens ein viertes Objekt 46 für jede weitere Untereinheit 26, 28 des modularen IO-Link Gerä ^¬ tes 20 angelegt wird.

In FIG 3 ist auch ersichtlich, dass die Anbindung des modula- ren IO-Link Gerätes 20 an das IO-Link System (FIG 1) nur über die das modulare IO-Link Gerät 20 nach außen repräsentierende Kopfbaugruppe 24, nämlich das für die IO-Link Kopfbaugruppe 24 generierte dritte Objekt 44 erfolgt. Ein fünftes Objekt 48 stellt eine Punkt-zu-Punkt Verbindung zwischen dem IO-Link Master und dem modularen IO-Link Gerät 20 dar. Der IO-Link Master 16 wird durch ein sechstes Objekt 50 repräsentiert. Die Darstellung durch das Entwicklungswerkzeug 34 und die der Darstellung zugrunde liegenden Verknüpfungen der einzelnen Objekte bewirkt die kommunikative Erreichbarkeit der IO-Link Kopfbaugruppe 24 im IO-Link System und speziell durch den IO- Link Master 16. Selbstverständlich kann ein komplexes IO-Link System eine Mehrzahl von IO-Link Geräten 18, 20, 22 und ebenfalls eine Mehrzahl von modularen IO-Link Geräten 20 umfass- ten. Je nach Art und Umfang des IO-Link Systems bezieht sich dessen Darstellung durch das Entwicklungswerkzeug 34 auf eine entsprechende Mehrzahl der jeweiligen Objekte.

Bei einer besonderen Ausführungsform des Softwarewerkzeugs 34 werden beim Anlegen eines Objekts 40 für ein modulares IO- Link Gerät 20 das Objekt 44 für die IO-Link Kopfbaugruppe 24 und/oder das Objekt 42 für den IO-Link Baugruppenrahmen 30 automatisch angelegt. Das Anlegen eines Objekts 40 für ein modulares IO-Link Gerät 20 erfolgt zum Beispiel indem der Verwender des Softwarewerkzeugs in einem Hardwarekatalog das jeweilige modulare IO-Link Gerät 20 auswählt und mittels heu ^¬ te üblicher Bedienhandlungen, z.B. drag&drop, in der Automatisierungslösung platziert.

Das Softwarewerkzeug 34 in einer solchen oder einer anderen Ausführungsform ist nicht separat dargestellt, nachdem es sich insoweit nur um zusätzliche oder alternative Software ^¬ funktionalität des Softwarewerkzeugs 34 handelt. Bei einer weiteren Ausführungsform des Softwarewerkzeugs 34 ist vorge- sehen, dass beim automatischen Anlegen eines Objekts 42 für den IO-Link Baugruppenrahmen 30 automatisch Objekte 46 für von dem den IO-Link Baugruppenrahmen 30 aufnehmbare Untereinheiten 26, 28 angelegt werden. Des Weiteren ist optional für die Funktionalität des Softwarewerkzeugs 34 vorgesehen, dass beim automatischen Anlegen von Objekten 42, 44, 46 ebenfalls automatisch eine Verschaltung zwischen den automatisch angelegten Objekten 42, 44, 46 erfolgt. Die insoweit angelegte Verschaltung entspricht der in FIG 3 schematisch dargestell- ten Verschaltung und macht zum Beispiel ausgehend von dem Ob ^¬ jekt 44 zur Repräsentation der Kopfbaugruppe 24 das Objekt 42 zur Repräsentation des IO-Link Baugruppenrahmens 30 und mit ^¬ telbar die Objekte 40, 46 zur Repräsentation des modularen IO-Link Gerätes 20 und/oder zur Repräsentation der von dem IO-Link Baugruppenrahmen 30 umfassten oder von dem IO-Link Baugruppenrahmen 30 aufnehmbaren Untereinheiten 26, 28 zugänglich .

FIG 4 macht diesen Aspekt, also die diesbezügliche Funktiona- lität des Softwarewerkzeugs 34, schematisch vereinfacht an ^¬ hand eines Flussdiagramms deutlich: Beim Anlegen von Objekten (erster Funktionsblock 52) mit dem Softwarewerkzeug 34 wird überprüft, ob es sich bei dem angelegen Objekt oder bei dem Objekttyp, der zum Anlegen eines Objektes ausgewählt wurde, um ein Objekt 40 zur Repräsentation eines modularen IO-Link Gerätes 20 handelt. Ist dies der Fall wird zu einem zweiten Funktionsblock 54 verzweigt, mit dem automatisch Objekt 42 für den IO-Link Baugruppenrahmen 30 angelegt wird. Wenn es sich bei dem Softwarewerkzeug 34 um ein Softwarewerkzeug 34 in der oben bereits beschriebenen besonderen Ausführungsform handelt, wird in einem optionalen vierten Funktionsblock 56 überprüft, um was für einen IO-Link Baugruppenrahmen 30, für den als Repräsentant das Objekt 42 angelegt wurde, es sich handelt und es werden sodann (fünfter Funktionsblock 58) au- tomatisch Objekte 46 für von dem IO-Link Baugruppenrahmen 30 umfasste oder von dem IO-Link Baugruppenrahmen 30 aufnehmbare Untereinheiten 26, 28 angelegt. Wenn der durch das Objekt 42 repräsentierte physikalische IO-Link Baugruppenrahmen 30 noch keine gesteckten Untereinheiten 26, 28 aufweist, werden als Objekte 46 gleichsam Platzhalterobjekte erzeugt; wenn der 10- Link Baugruppenrahmen 30 an einzelnen oder allen Steckplätzen bereits Untereinheiten 26, 28 aufweist, können die automa- tisch erzeugten Objekte in Ansehung der tatsächlich gesteckten Untereinheiten 26, 28 erzeugt werden, indem für diese z.B. Daten aus der jeweiligen Gerätebeschreibung übernommen werden .