Kommunikationsdienste

Um zyklische und azyklische Daten zwischen einem IO-Controller/Supervisor und einem IO-Device austauschen zu können, muss ein IO-Controller die erforderlichen Kommunikationswege im System-Hochlauf aufbauen. Hierzu richtet der IO-Controller eine Verbindung auf Basis der vom Engineering-System vorgegebenen Daten ein. Die Application Relation (AR entspricht der Verbindung) beinhaltet alle Daten, die zum Aufbau für diesen Datenaustausch benötigt werden. Sie kann flexibel gestaltet werden. Innerhalb einer AR sind ein oder mehrere APIs angegeben, die eine feinere Gliederung der Anwendung erlauben. Eine AR kann mehrere Kommunikations-Beziehungen (Communication Relations, CR) enthalten.

Folgende CRs sind somit für jede API möglich:

•	Ein oder mehrere IO-CRs (unterschieden nach Input, Output, Querverkehr)

•	Alarm-CR zur Weitergabe von Ereignissen

•	Record-Data-CR zum Austausch von azyklischen Datensätzen

Ein IO-Controller/Supervisor kann eine AR zu einem oder mehreren IO-Devices aufbauen. Ein IO-Device kann mit mehreren IO-Controllern Daten austauschen. Konkurrierende Schreibzugriffe auf dieselben Daten werden vom IO-Device abgewehrt.

Zyklischer Datenaustausch

Für den zyklischen Austausch der Prozess-Signale und der hochprioritären Alarme verwendet PROFINET IO den RT-Kanal. Für die Datenübertragung nutzt PROFINET IO nachfolgende Möglichkeiten:

•	RT-Kommunikation innerhalb eines Netzwerkes: Bei dieser auf Performance ausgelegten Kommunikation wird der schnelle RT-Kanal, d.h. ohne Verwendung von UDP/IP, verwendet (Ethertype 0x8892).

•	RT-Kommunikation zwischen Netzwerken: Hierfür werden zusätzlich zum schnellen RT-Kanal (Ethertype 0x8892) der Protokoll-Mechanismus über UDP/IP verwendet.

•	IRT-Kommunikation für die deterministische und taktsynchrone Datenübertragung.

Der Daten-Querverkehr (MCR = Multicast Communication Relation) basiert auf der RT-und IRT-Kommunikation und besteht aus einem Provider, der die Daten am Bus veröffentlicht, und aus einem oder mehreren Consumern, die die Daten verarbeiten.

Der Datenaustausch vom IO-Device an den IO-Controller erfolgt in einem vom IO-Controller parametrierten Raster. Den Aktualisierungszyklus vom IO-Controller zum IO-Device gibt der Projekteur im Engineering-Tool vor. Dadurch ist die gegenseitige Überwachung der Funktionsfähigkeit (Watchdog) gegeben. Alle zyklischen Daten sind Subslot granular mit einem Status versehen, der die Gültigkeit der Daten angibt.

Im Unterschied zu PROFIBUS kann die Datenübertragung bei PROFINET IO hinsichtlich der Häufigkeit optimiert werden, d.h. Daten können in unterschiedlichen Phasen übertragen werden. Um das bewerkstelligen zu können, definiert PROFINET IO einen Untersetzungsfaktor (Reduction Ratio). Er bestimmt die Häufigkeit der Datenübertragung.

Azyklischer Datenaustausch (Record Daten)

Das Lesen und Schreiben (Read/Write-Services) von Informationen kann der Anwender azyklisch durchführen. Nachfolgende Dienste werden bei PROFINET IO azyklisch abgewickelt:

•	Parametrieren der einzelnen Submodule im Systemhochlauf

•	Auslesen von Diagnoseinformationen

•	Auslesen von Identifikations-Informationen gemäß den ´Identification and Maintenance (I&M) Functions´

•	Rücklesen von I/O-Daten

Welche Daten azyklisch zu lesen oder zu schreiben sind, ist bei der Adressierung durch den Index bestimmt.

Viele Dienste sind dabei standardisiert. Hersteller spezifisch kann dies durch zusätzliche Dienste erweitert werden.

Alarme

PROFINET IO überträgt Ereignisse innerhalb eines Automatisierungsprozesses als Alarme, die vom Anwendungsprozess zu quittieren sind. Sie decken sowohl System definierte Ereignisse (wie Ziehen und Stecken von Baugruppen) als auch Anwender definierte Ereignisse (z.B. Lastspannung defekt) ab, die in der verwendeten Steuerungstechnik erkannt wurden bzw. schon im Prozess auftraten (z.B. Kesseldruck zu hoch). Folgende Ereignisse werden dabei unterschieden:

•	Prozess-Alarme: Ereignisse, die aus dem Prozess kommen und an die Steuerung gemeldet werden

•	Diagnose-Alarme: Ereignisse, die Fehlfunktionen eines Feldgerätes anzeigen

•	Maintenance-Alarme: Übermittlung von Informationen um durch vorbeugende Wartungsarbeiten den Ausfall eines Gerätes zu vermeiden

•	Hersteller spezifische Diagnosen

PROFINET definiert standardmäßig eine Reihe von Alarm-Ursachen, wie beispielsweise:

•	Pull-und Plug-Alarme treten in Zusammenhang mit modularen IO-Devices auf, wenn ein Modul gezogen bzw. gesteckt wird.

•	Return-of-Submodule-Alarme sind dann anzuwenden, wenn ein IO-Device für ein bestimmtes Input-Element wieder gültige Daten liefert.

Alarme werden zur eindeutigen Identifizierung immer über einem Slot/Subslot gemeldet. Diagnose und Prozess-Alarme kann der Anwender unterschiedlich priorisieren.