Profinet IO erlaubt die Anbindung von dezentraler Peripherie an einen Controller und kann somit als direkter Nachfolger von Profibus DP gesehen werden. Profinet IO beschreibt den gesamten Datenaustausch zwischen Geräten mit Steuerungs- oder Regelungs-Funktionalität als IO-Controller und den Feldgeräten als IO-Devices für den zyklischen Datenaustausch sowie die Parametrierung und Diagnose. Dazu verwendet Profinet IO Ethernet-basierte Protokolle, folgt dem Producer-/Consumer-Modell und eignet sich je nach Konformitätsklasse für Buszykluszeiten von mehreren ms bis herunter zu 31,25 μs.

Feldgeräte in einem unterlagerten Feldbus-Strang können über einen IO-Proxy (Stellvertreter für ein unterlagertes Bussystem) in das Profinet-IO-System eingebunden werden. Damit können bestehende Profibus- und andere Feldbus-Systeme einfach in ein Profinet-IO-System eingebunden und weiterverwendet werden.

Die Anwendungen mit Profinet IO können in vier Klassen eingeteilt werden:

• In der Klasse A (CC-A) sind nur die eingesetzten Geräte zertifiziert. Für die Netzwerkinfrastruktur genügt ein Herstellerzertifikat. Darum kann auch eine Strukturierte Verkabelung oder für mobile Teilnehmer ein Wireless Local Area Network eingesetzt werden.^[2] Typische Anwendungen findet man in Infrastrukturbauten (z. B. Autobahn- oder Eisenbahntunnel) oder in der Gebäudeautomation.
• Die Klasse B (CC-B) schreibt vor, dass auch die Netzwerkinfrastruktur zertifizierte Produkte umfasst und nach den Richtlinien von Profinet IO aufgebaut ist. Geschirmte Kabel erhöhen die Robustheit und Switches mit Managementfunktionen erleichtern die Netzwerkdiagnose und erlauben das Erfassen der Netzwerktopologie wie dies für die Kontrolle einer Fertigungslinie oder Maschine erwünscht ist. Die Prozessautomation verlangt eine erhöhte Verfügbarkeit, die durch eine Medien- und Systemredundanz erreicht werden kann.
• Mit der Klasse C (CC-C) können mit einer zusätzlichen Bandbreitenreservierung und der Synchronisation der Anwendungen z. B. Positioniersysteme realisiert werden.
• Bei der Klasse D (CC-D) wird Profinet über Time-Sensitive Networking (TSN) genutzt. Dabei können dieselben Funktionen wie bei der CC-C erreicht werden.^[3] Anders als bei CC A&B findet bei CC-D die komplette Kommunikation (zyklische und azyklisch) zwischen Controller und Device auf Ethernet Schicht 2 statt. Hierzu wurde das Remote Service Interface (RSI) eingeführt.

Profinet Geräte können die folgenden Rollen einnehmen:

• IO-Controller ist eine Steuerung, die die Automatisierungsaufgabe kontrolliert.
• IO-Device ist ein Feldgerät, das von einem IO-Controller kontrolliert und gesteuert wird. Ein IO-Device besteht aus mehreren Modulen und Submodulen. Die Submodule enthalten die einzelnen Eingangs- und Ausgangssignale zum Prozess.
• IO-Supervisor ist ein Engineering-Werkzeug, typischerweise basierend auf einem PC, um die einzelnen IO-Devices zu parametrieren und diagnostizieren.^[4]

Ein minimales Profinet-IO-System besteht aus mindestens einem IO-Controller, der ein oder mehrere IO-Devices kontrolliert. Zusätzlich können optional ein oder mehrere IO-Supervisoren für das Engineering der IO-Devices bei Bedarf temporär zugeschaltet werden.

Sind zwei IO-Systeme in demselben IP-Netzwerk, können die IO-Controller sich auch ein Eingangssignal als shared-input teilen, in dem sie auf dasselbe Submodul in einem IO-Device lesend zugreifen. Dies vereinfacht die Kombination einer SPS mit einer getrennten Sicherheitssteuerung oder einer Bewegungsregelung. Ebenso kann ein ganzes IO-Device als shared-device geteilt werden, in dem einzelne Submodule eines IO-Device unterschiedlichen IO-Controllern zugeordnet werden.

Jedes Automatisierungsgerät mit einer Ethernetschnittstelle kann gleichzeitig die Funktionalität eines IO-Controllers und eines IO-Devices erfüllen. Wenn nun eine Steuerung für eine Partnersteuerung als IO-Device auftritt und gleichzeitig als IO-Controller seine Peripherie kontrolliert, ist eine Koordination der Aufgaben zwischen Steuerungen ohne zusätzliche Geräte realisierbar.

Zwischen einem IO-Controller und einem IO-Device wird eine Application-Relation (AR) aufgebaut. Über diese AR werden Communication-Relations (CR) mit unterschiedlichen Eigenschaften festgelegt:

• Record Data CR für den azyklischen Parametertransfer
• IO Data CR für den zyklischen Prozessdatenaustausch
• Alarm CR für die Signalisation von Alarmen in Echtzeit

Zyklische Daten (IO Data CR): Der Inhalt des zyklischen Datenverkehrs sind die Daten, die die Zentraleinheit an die Peripheriegeräte schickt, damit sie an den Ausgängen ausgegeben werden können sowie die Daten, die ein Peripheriegerät als an seinen Eingängen einliest und zur Verarbeitung an die Zentraleinheit schickt. In der Regel geht also in jedem Zyklus ein solches „zyklisches“ Datenpaket von der Zentraleinheit als „Provider“ an das Peripheriegerät als „Consumer“ und unabhängig davon ein Datenpaket vom Peripheriegerät als „Provider“ an die Zentraleinheit als „Consumer“.

Die Basis hierfür ist ein kaskadierbares Real-Time-Konzept, d. h. für jede zyklische CR kann eine unterschiedliche Zykluszeit festgelegt werden. Diese Grundfunktion wird als „RT“ (Real Time) bezeichnet.^[5] Der zyklische Datenverkehr kann je nach Anforderung zusätzliche Eigenschaften ausweisen. Bei einem taktsynchronen Datenaustausch werden die Anwendungsfunktionen auf den Profinet Datenzyklus synchronisiert um keine Zeit bei der Datenübergabe zu verlieren. Bei einem isochronen Datenzyklus wird der zyklische Datenaustausch von mehreren zyklischen CR in beide Richtungen synchronisiert. Dies wird als „IRT“ (Isochronous Real Time)^[6] bezeichnet.

Für die zyklischen Daten wird bei Profinet eine möglichst effiziente Übertragung im Hinblick auf die Bandbreite angestrebt. Deshalb setzt der zyklische Verkehr direkt auf der Ebene der MAC-Adressen auf und enthält keine IP-Adressen, um die Headerlänge des Datenpakets (und damit auch die Gesamtlänge und die Verarbeitungszeit im Gerät) kleinzuhalten. Da die Automatisierungsaufgaben für Profinet IO in aller Regel lokal begrenzt sind (eine Maschine/Anlage), kann man den Verlust der Routingfähigkeit, den man durch den Verzicht auf IP-Headerinformationen in Kauf nimmt, verschmerzen.

Azyklische Parameterdaten (Record Data CR): Daneben gibt es im Datenaustausch zwischen Zentraleinheit und Peripheriegerät auch den azyklischen Datenverkehr, der für Ereignisse genutzt wird, die sich nicht ständig wiederholen. Beispiele für azyklischen Datenverkehr sind das Senden von Parametrierungs- und Konfigurationsdaten beim Anlauf eines Peripheriegeräts an das Gerät oder das Senden einer Diagnosemeldung vom Peripheriegerät zur Zentraleinheit im laufenden Betrieb.

Azyklische Daten nutzen das UDP/IP oder das RSI Protokoll.

Azyklische Alarmdaten (Alarm CR): Alarme sind spezielle azyklische Nachrichten die bei Bedarf vom Peripheriegerät an den Controller übertragen werden. Diese sind zeitkritisch und werden somit wie die zyklische Daten direkt über Ethernet übertragen. Im Gegensatz zu den zyklischen Daten müssen diese aber vom Empfänger bestätigt werden.

Das Projektieren eines IO-Systems ist vom „look and feel“ nahezu identisch wie bei Profibus gehalten:

• Die Eigenschaften eines IO-Devices werden vom Gerätehersteller in einer GSD-Datei (General Station Description) beschrieben^[7]. Als Sprache hierfür wird die GSDML (GSD Markup Language) – eine XML-basierte Sprache – verwendet. Die GSD-Datei dient einer Engineeringsumgebung als Grundlage für die Planung der Konfiguration eines Profinet-IO-Systems.
• Alle Profinet-Feldgeräte ermitteln ihre Nachbarn. Somit können Feldgeräte ohne zusätzliche Hilfsmittel und Vorkenntnisse im Fehlerfall getauscht werden. Durch Auslesen dieser Informationen kann die Anlagentopologie zur besseren Übersichtlichkeit grafisch dargestellt werden.
• Durch Unterstützung des Tool Calling Interfaces (TCI) kann sich jeder Feldgeräte-Hersteller in eine beliebige TCI-fähige Entwicklungsumgebung einklinken und „seine“ Feldgeräte parametrieren und diagnostizieren ohne die Entwicklungsumgebung verlassen zu müssen. Individuell eingestellte Daten können herstellerübergreifend geladen (bspw. über TCI) und in einem Parameter-Server automatisch archiviert werden. Das Nachladen erfolgt beim Gerätetausch ebenfalls automatisch.

Profisafe definiert wie sicherheitsgerichtete Geräte (Not-Aus-Taster, Lichtgitter, Überfüllsicherungen, …) über Profinet mit Sicherheitssteuerungen so sicher kommunizieren, dass sie in sicherheitsgerichteten Automatisierungsaufgaben bis SIL3 (Safety Integrity Level) eingesetzt werden können.^[8] Es realisiert die sichere Kommunikation über ein Profil, d. h. über ein besonderes Format der Nutzdaten und ein spezielles Protokoll. Profisafe ist für Profinet und Profibus in der Norm IEC 61784-3-3 festgelegt und bildet die Grundlage für OPC UA Safety.^[9][10]

Hochverfügbarkeit ist eine der wichtigsten Anforderungen in der industriellen Automatisierung sowohl in der Fabrik- und in der Prozessautomatisierung. Durch gezieltes anfügen von Redundanz für kritische Elemente kann die Verfügbarkeit eines Automatisierungssystems erhöht werden. Dabei kann zwischen System- und Medienredundanz unterschieden werden.

Das IT-Sicherheitskonzept^[11] für PROFINET geht von einem Defense-in-Depth^[12] Ansatz aus. Die Produktionsanlage wird dabei durch einen mehrstufigen Perimeter, u. a. Firewalls, gegen Angriffe, insbesondere von außen, geschützt. Darüber hinaus ist innerhalb der Anlage eine weitere Absicherung durch Unterteilung in Zonen unter Einsatz von Firewalls möglich. Zusätzlich wird durch einen Security-Komponententest die Festigkeit der Profinet-Komponenten gegen Überlastung in einem definierten Umfang sichergestellt.^[13] Dieses Konzept wird durch organisatorische Maßnahmen in der Produktionsanlage im Rahmen eines Security Management-Systems nach ISO 27001 unterstützt.

PROFIdrive ist das modular aufgebaute Geräteprofil für Antriebsgeräte.^[15] Es wurde in den 1990er Jahren von Herstellern und Anwendern gemeinsam entwickelt und deckt seither in Verbindung mit Profibus und ab der Version 4.0 zusätzlich auch mit Profinet die gesamte Spanne von einfachsten bis zu anspruchsvollsten Antriebslösungen ab.

PROFIenergy ist ein Profil für das Energiemanagement in Produktionsanlagen.^[16] Es steuert über Profinet den Verbrauch der elektrischen Energie von Automatisierungsequipement in der Fertigung wie z. B. Roboter-Montagezellen, Laserschneideanlagen oder Teilsystemen wie Lackieranlagen. Die Steuerung des Energieverbrauchs selbst erfolgt über standardisierte Kommandos, die bei geplanten und ungeplanten Unterbrechungen in der Fertigung für das Ein- und Ausschalten der Geräte angewandt werden. Mit dem Einsatz von PROFIenergy werden keine externen festverdrahteten Systeme für das Ein- und Ausschalten von Automatisierungsgeräte mehr benötigt. Mit PROFIenergy ist auch die Erfassung von Energiewerten definiert, so dass überlagerte Energiemonitoringsysteme einheitlich einlesen können.

Moderne Prozessgeräte verfügen über eigene Intelligenz und können in Automatisierungssystemen einen Teil der Informationsverarbeitung bzw. der Gesamtfunktionalität übernehmen. Für die Integration in ein Profinet-System^[17] wird neben der erhöhten Verfügbarkeit auch ein Zweileiter-Ethernet benötigt.

Profinet verwendet in den verschiedenen Schichten des OSI-Modells die folgenden Protokolle:

Schichten 1-2: Nur Full-Duplex mit 100 MBit/s elektrisch (100BASE-TX) oder optisch (100BASE-FX) nach IEEE 802.3 sind als Geräteanschluss erlaubt. Autocrossover ist für alle Anschlüsse obligatorisch damit auf den Einsatz von gekreuzten Kabeln verzichtet werden kann. Aus IEEE 802.1Q wird das VLAN mit Priority Tagging verwendet. Alle Echtzeitdaten erhalten damit die größtmögliche Priorität 6 und werden darum mit einer minimalen Verzögerung von einem Switch weitergeleitet.

Das Profinet-Protokoll kann mit jedem Ethernet-Analysewerkzeug aufgezeichnet und dargestellt werden. Wireshark decodiert in der aktuellen Version auch die Profinet-Telegramme.

Das Link Layer Discovery Protocol (LLDP) ist mit zusätzlichen Parametern erweitert worden, so dass neben der Erkennung der Nachbarn auch die Laufzeit der Signale auf den Verbindungsleitungen mitgeteilt werden kann.

Schichten 3-6: Für den Verbindungsaufbau und die azyklischen Dienste wird entweder das Remote Service Interface (RSI)-Protokoll oder das Remote Procedure Call (RPC)-Protokoll eingesetzt. Das RPC-Protokoll wird über User Datagram Protocol (UDP) und Internet Protocol (IP) mit dem Einsatz von IP-Adressen verwendet. Das Address Resolution Protocol (ARP) wird dazu mit der Erkennung von doppelten IP-Adressen erweitert. Für die Vergabe der IP-Adressen wird obligatorisch das Discovery and basic Configuration Protocol (DCP) eingesetzt. Optional kann dazu auch das Dynamic Host Configuration Protocol (DHCP) eingesetzt werden. Mit dem RSI-Protokoll werden keine IP-Adressen verwendet. Somit kann das Internet-Protokoll im Betriebssystem des Feldgeräts für andere Protokolle wie zum Beispiel OPC Unified Architecture (OPC UA) genutzt werden.

Schicht 7: Um die Dienste des Fieldbus Application Layers (FAL) zu erreichen, sind verschiedene Protokolle definiert. Das RT (Real-Time) Protokoll für Anwendungen der Klassen A & B mit Zykluszeiten in der Größenordnung von 1–10 ms. Das IRT (Isochronous Real-Time) Protokoll für die Anwendungsklasse C erlaubt Zykluszeiten unter 1 ms für Anwendungen in der Antriebstechnik. Dies kann mit denselben Diensten auch über Time-Sensitive Networking (TSN) erreicht werden.

Die Funktionalitäten des Profinet IO werden mit unterschiedlichen Technologien und Protokollen realisiert:

Die Grundfunktion des Profinet IO ist der zyklische Datenaustausch zwischen dem IO-Controller als Produzent und mehreren IO-Devices als Konsumenten der Ausgangsdaten (englisch Output-Data) und der IO-Devices als Produzenten und dem IO-Controller als Konsument der Eingangsdaten (englisch Input-Data). Jede Kommunikationsbeziehung IO data CR zwischen dem IO-Controller und einem IO-Device definiert die Anzahl der Daten und die Zykluszeiten.

Alle Profinet-IO-Geräte müssen die Gerätediagnose und die sichere Übertragung der Alarme über die Kommunikationsbeziehung für Alarme Alarm CR unterstützen.

Zusätzlich können mit jedem Profinet-Gerät über die azyklische Kommunikationsbeziehung Record Data CR Geräteparameter gelesen und geschrieben werden. Der Datensatz für die eindeutige Identifikation eines IO-Device, die Identification and Maintenance Data Set 0 (I&M 0), muss von allen Profinet-IO-Geräten zwingend eingebaut werden. Optional können weitere Informationen in einem normierten Format als I&M 1-4 abgelegt werden.

Für die Echtzeitdaten (zyklische Daten und Alarme) werden die Profinet-RT-Telegramme direkt über Ethernet übertragen. Für die Übertragung der azyklischen Daten wird UDP/IP verwendet.

Neben den Grundfunktionen der Klasse A müssen Geräte der Klasse B zusätzliche Funktionalitäten unterstützen. Diese Funktionalitäten unterstützen vor allem die Inbetriebnahme, den Betrieb und den Unterhalt eines Profinet-IO-Systems und sollen die Verfügbarkeit des Profinet-IO-Systems erhöhen.

Zwingend erforderlich ist die Unterstützung der Netzwerkdiagnose mit dem Simple Network Management Protocol (SNMP). Ebenso muss das Link Layer Discovery Protocol (LLDP) zur Nachbarschaftserkennung inklusive der Erweiterungen für Profinet von allen Geräten der Klasse B unterstützt werden. Dazu gehört auch das Sammeln und zur Verfügung stellen von Ethernet-Port bezogener Statistik für den Netzwerkunterhalt. Mit diesen Mechanismen kann die Topologie eines Profinet-IO-Netzwerkes jederzeit ausgelesen und der Zustand der einzelnen Verbindungen überwacht werden. Bei einer bekannten Netzwerktopologie kann eine automatische Adressierung der Teilnehmer über ihre Position in der Topologie aktiviert werden. Dies vereinfacht beim Unterhalt den Gerätetausch erheblich, da keine Einstellungen mehr vorgenommen werden müssen.

Speziell für Anwendungen in der Prozessautomation und Verfahrenstechnik ist eine hohe Verfügbarkeit des IO-Systems wichtig. Darum sind für Geräte der Klasse B mit den vorhandenen Beziehungen und Protokollen spezielle Abläufe definiert worden. Damit kann eine Systemredundanz mit zwei IO-Controllern, die gleichzeitig auf dieselben IO-Devices zugreifen, realisiert werden. Zusätzlich gibt es einen vorgeschriebenen Ablauf Dynamic Reconfiguration (DR), wie man mit der Hilfe dieser redundanten Beziehungen die Konfiguration eines IO-Device verändern kann, ohne die Kontrolle über das IO-Device zu verlieren.

Für die Funktionalitäten der Conformance Class C (CC-C) wird vor allem das Isochronous-Real-Time (IRT) Protokoll eingesetzt.

Mit der Bandbreitenreservierung wird ein Teil der verfügbaren Übertragungsbandbreite von 100 MBit/s exklusiv für die Echtzeitaufgaben reserviert. Dabei wird ein Verfahren ähnlich einem Zeitmultiplexverfahren eingesetzt. Die Bandbreite wird in feste Zykluszeiten eingeteilt, die wiederum in Phasen aufgeteilt werden. Die rote Phase ist exklusiv für Echtzeitdaten der Klasse C reserviert, in der orangen Phase werden die zeitkritischen Meldungen übertragen und in der grünen Phase werden die weiteren Ethernet-Meldungen transparent durchgeleitet. Damit maximale Ethernet-Telegramme noch transparent durchgeleitet werden können, muss die grüne Phase mindestens 125 μs lang sein. Somit sind Zykluszeiten unter 250 μs in Kombination mit unverändertem Ethernet nicht möglich.

Um kürzere Zykluszeiten bis herab zu 31,25 μs zu erreichen, werden als Option die Ethernet-Telegramme der grünen Phase in Fragmente zerlegt. Diese kurzen Fragmente werden nun über die grüne Phase übertragen. Dieser Mechanismus der Fragmentierung ist für die anderen Teilnehmer am Ethernet transparent und somit nicht erkennbar.

Für die Realisierung dieser Buszyklen für die Bandbreitenreservierung braucht es eine genaue Uhrensynchronisation aller beteiligten Geräte inklusive der Switch mit einer maximalen Abweichung von 1 μs. Diese Uhrensynchronisation wird mit dem Precision Time Protocol (PTP) nach der Norm IEC 61588 realisiert. Alle an der Bandbreitenreservierung beteiligten Geräte müssen somit in derselben Zeitdomäne sein.

Für Anwendungen der Lageregelung für mehrere Achsen oder für Positioniervorgänge nach dem Antriebsprofil PROFIdrive der Applikationsklassen 4–6 muss nicht nur die Kommunikation zeitgerecht erfolgen, sondern auch die Aktionen der verschiedenen Antriebe an einem Profinet müssen koordiniert und synchron erfolgen. Die Taktsynchronisation des Anwendungsprogrammes auf den Buszyklus erlaubt es Kontrollfunktionen zu realisieren, die synchron auf verteilten Geräten ausgeführt werden.

Wenn mehrere Profinet-Geräte in einer Linie (Daisy Chain) angeschlossen sind, besteht die Möglichkeit den zyklischen Datenaustausch mit dem Dynamic-Frame-Packing (DFP) weiter zu optimieren. Zu diesem Zweck legt der Controller alle Ausgangsdaten für alle Devices in einen einzigen IRT-Frame. Jedes Device nimmt am vorbeikommenden IRT-Frame die für das Device bestimmten Daten heraus, der IRT-Frame wird also immer kürzer. Für die Daten von den verschiedenen Devices zum Controller wird der IRT-Frame dynamisch zusammengesetzt. Die große Effizienz des DFP liegt darin, dass der IRT-Frame immer nur so umfangreich wie notwendig ist und die Daten vom Controller zu den Devices gleichzeitig mit den Daten von den Devices zum Controller in Vollduplex übertragen werden können.

Die Klasse D bietet dem Anwender die gleichen Dienste wie die Klasse C, mit dem Unterschied, dass diese Dienste mit den durch IEEE definierten Mechanismen des Time-Sensitive Networking (TSN) erbracht werden.

Als Ersatz für die Internet Protokolle wird das Remote Service Interface (RSI) verwendet. Damit wird diese Anwendungsklasse D unabhängig von IP-Adressen implementiert. Der Protokollstack wird kleiner und unabhängig von zukünftigen Internetversionen (IPv6).

Das TSN ist keine konsistente, abgeschlossene Protokolldefinition, sondern eine Sammlung von unterschiedlichen Protokollen mit unterschiedlichen Ausprägungen die für jede Anwendung fast beliebig zusammengestellt werden können. Für den Einsatz in der industriellen Automation wird ein Subset in der IEC/IEEE Norm 60802 „Joint Profile TSN for Industrial Automation“ zusammengestellt. Ein Subset wird in der Profinet Spezifikation Version 2.4 für die Realisierung der Klasse D verwendet.^[22]

In dieser Spezifikation werden zwei Anwendungen unterschieden:

• isochroner, zyklischer Datenaustausch mit kurzer, begrenzter Latenzzeit (Isochronous Cyclic Real Time) für Anwendungen in Motion-Control und verteilter Regelungstechnik
• zyklischer Datenaustausch mit begrenzter Latenzzeit (Cyclic Real Time) für allgemeine Automatisierunsgaufgaben

Für den isochronen Datenaustausch müssen die Uhren der Teilnehmer synchronisiert werden. Dazu werden die Festlegungen des Precision Time Protocol nach IEC 61588 für die Zeitsynchronisation mit TSN^[23] entsprechend angepasst.

Die Telegramme werden gemäß den im VLAN-Tag vorgesehenen Prioritäten in Queues eingereiht. Durch den Time-Aware-Shaper (TAS)^[24] wird nun ein Takt vorgegeben, mit dem die einzelnen Queues in einem Switch abgearbeitet werden. Dies führt zu einem Zeitschlitzverfahren, wo die isochronen, zyklischen Daten mit höchster Priorität, die zyklischen Daten mit der zweiten Priorität vor allen azyklischen Daten übertragen werden. Dies reduziert die Latenzzeit und auch den Jitter für die zyklischen Daten. Dauert ein Daten-Telegramm mit kleiner Priorität zu lange, kann dieses von einem zyklischen Daten-Telegramm mit hoher Priorität unterbrochen und nachher weiter übertragen werden. Dieses Verfahren wird als Frame Preemption^[25] bezeichnet und ist bei CC-D obligatorisch.