I. Aufstieg und Markttreiber der Feldbustechnologie In den 1970er-Jahren beflügelten Fortschritte in der Mikroprozessortechnologie und die Risikokontrollstrategie „zentralisiertes Management und dezentrale Steuerung“ den Markteintritt mikroprozessorgestützter, verteilter Steuerungssysteme. Damit hielt auch die Computerkommunikationsnetzwerktechnologie, die für die Datenkommunikation zwischen Steuerungen sowie zwischen Steuerungen und Host-Rechnern eingesetzt wird, Einzug in die industrielle Automatisierung. Da die Steuerungssysteme der Automatisierungshersteller zu dieser Zeit jedoch in sich geschlossen waren, beschränkte sich die Netzwerkkommunikation auf interne Funktionen und erforderte keinen Datenaustausch mit der Außenwelt. Nach den 1980er-Jahren, mit der zunehmenden Verbreitung von Mikroprozessorchips, entstanden „intelligente“ industrielle Feldsteuergeräte wie Sensoren, Schalter und Aktoren. Die von verschiedenen Herstellern entwickelten Datenkommunikationsprotokolle, die auf den Eigenschaften ihrer Komponenten basierten, waren jedoch vielfältig und zahlreich. Einzelne Komponenten schienen zwar über umfassende „Intelligenz“ zu verfügen, doch in der Integration in das Steuerungssystem war weiterhin eine herkömmliche Kabelverbindung zur E/A-Schnittstellenkarte erforderlich, wodurch ihre vermeintlichen Vorteile nicht voll zum Tragen kamen. Um die zahlreichen „intelligenten“ Feldsteuerungskomponenten verschiedener Hersteller in ein vollständig digitales, verteiltes Steuerungssystem zu integrieren, wurde daher ein öffentlich verfügbarer und offener Netzwerkkommunikationsprotokollstandard unerlässlich. Angetrieben von dieser Marktdynamik haben Hersteller verschiedener Steuerungssysteme (einschließlich SPS und DCS) auf Basis ihrer proprietären Netzwerkkommunikationstechnologien diverse Feldbus-Kommunikationsprotokollstandards mit unterschiedlichem Offenheitsgrad vorgeschlagen. Diese Standards werden durch technologische Fortschritte kontinuierlich ergänzt und verbessert. II. Aktueller Stand der Feldbustechnologie-Standardisierung: Seit den 1980er Jahren haben die Instrumentation Society (ISA) und die Internationale Elektrotechnische Kommission (IEC) spezielle Organisationen zur Erforschung und Entwicklung von Feldbustechnologiestandards eingerichtet. Aus verschiedenen Gründen sorgte die nach über einem Jahrzehnt der Bemühungen im Jahr 2000 endlich veröffentlichte internationale Norm IEC 61158 für Verwirrung und Verlegenheit in der Automatisierungsbranche, da sie acht inkompatible Busprotokolle enthielt. Mit dem zunehmenden Einzug der IT-Technologie in die Industrie weckte Ethernet als neue Feldbustechnologie große Erwartungen. Die Veröffentlichung der dritten Ausgabe der IEC 61158 im Jahr 2003 fügte jedoch drei neue Ethernet-basierte Protokolle hinzu und erhöhte die Anzahl der Standard-Busprotokolle auf elf. Gleichzeitig werden dem Protokollset der Norm aktiv weitere neue Ethernet-basierte Protokolle hinzugefügt. III. Analyse und Reflexion zum Standardisierungsprozess der Feldbustechnologie. Die Analyse der Nutzerbedürfnisse ermöglicht es, die technischen Anforderungen und Erwartungen der Nutzer an Feldbusse grob in drei Ebenen zu unterteilen: 1) Vernetzung und Interoperabilität zwischen intelligenten Komponenten und Steuerungen (Stationen), hauptsächlich zur Ablösung herkömmlicher E/A-Kabel. Die Anforderung besteht darin, neben herkömmlichen E/A-Daten auch Alarm- und Fehlerdiagnoseinformationen bestimmter intelligenter Komponenten zu übertragen. 2) Basierend auf der Übertragung dieser Echtzeit-Überwachungsdaten benötigen die Anwender zudem eine zentrale Konfiguration des Engineering-Designs, dynamische Programmänderungen und -downloads sowie Ferndiagnose und -kalibrierung der Komponenten über das Netzwerk. 3) Durch Vernetzung und Interoperabilität möchten die Anwender das System in verschiedenen Situationen rekonstruieren können, beispielsweise bei Komponentenschäden und -austausch, Systemerweiterung und -modernisierung sowie System- oder Teil-Upgrades. Dies erfordert einen nahtlosen Zugriff auf Komponenten von Drittanbietern oder aktualisierte Produkte unter neuen technologischen Bedingungen. Aus den genannten Anforderungen geht hervor, dass die Anwender Vernetzung, Interoperabilität und Austauschbarkeit verschiedener intelligenter Komponenten und Steuerungen (Stationen) mittels Feldbustechnologie und Netzwerkdatenkommunikation erreichen möchten. Sie benötigen jedoch nicht, dass all diese Funktionen in einem einzigen, einheitlichen Netzwerk implementiert werden. So wie Internetnutzer den Zugriff auf Dienste wie E-Mail, Dateidownloads, Web-Browsing und Online-Spiele erwarten, muss das Internet kein einheitliches oder homogenes Netzwerk sein. Betrachtet man die Konstruktionsmodelle von Kommunikationsprotokollen, so beziehen sich fast alle gängigen Protokolle auf das OSI-Sieben-Schichten-Modell. Die meisten Protokolle bauen jedoch einen in sich geschlossenen, vertikal integrierten Protokollstapel auf, beginnend mit der Bitübertragungsschicht und von unten nach oben. Dies erschwert die Vernetzung oder Interoperabilität der acht Standardprotokolle auf allen Schichten, geschweige denn den Austausch von Funktionen. Tatsächlich besteht der Zweck des OSI-Schichtenmodells darin, Kommunikationseinheiten mit unterschiedlichen technologischen Elementen und Entwicklungsgeschwindigkeiten in unabhängige Schichten zu unterteilen. Dadurch kann jede Schicht sowohl einen vollständigen End-to-End-Protokollstapel bilden als auch sich unabhängig und ohne gegenseitige Einschränkungen weiterentwickeln. Beispielsweise beruht der Erfolg des Internets im bekannten Netzwerkprotokoll-Fachgebiet auf seinem Kernprotokollstapel TCP/IP. Dieser kann zahlreiche verschiedene Anwendungsschichtprotokolle (WWW, FTP, E-Mail usw.) unterstützen und ist auf verschiedenen LAN- (Ethernet, FDDI usw.) und WAN-Plattformen (Einwahlnetze, X.25 usw.) implementierbar. Die aktuelle Schwierigkeit im Standardisierungsprozess der Feldbustechnologie ist im Wesentlichen auf die anfänglich übermäßig idealistische Erwartung eines einheitlichen, vertikal integrierten und homogenen Netzwerks als Ziel des technischen Standards zurückzuführen. Dies führte nicht nur zu keinem Ergebnis, sondern sogar zu einem kontraproduktiven Ansatz mit mehreren konkurrierenden und inkompatiblen Technologien. IV. Inspiration durch die CIP-Protokollarchitektur: Die CIP-Protokollspezifikation ist eine gemeinsame Protokollspezifikation für Transport-, Anwendungs- und Benutzerschicht, die unabhängig von der Netzwerkhardware ist und auf drei völlig unterschiedlichen Netzwerktechnologieplattformen basiert: ControlNet, DeviceNet und EtherNet. Anders ausgedrückt: Es ermöglicht die Vernetzung, Interoperabilität und sogar Austauschbarkeit von Systemen in heterogenen Netzwerken. Gemäß dem OSI-Sieben-Schichten-Modell ist die Protokollstapelstruktur der CIP-Protokollarchitektur in der folgenden Abbildung dargestellt. Wie aus dem obigen Diagramm ersichtlich, besteht ein wesentlicher Unterschied zu anderen Feldbus-Kommunikationsprotokollen in der Spezifikation des „CIP Messaging“-Protokolls mit Funktionalität der Netzwerktransportschicht. Kern dieses Ansatzes ist die Abstraktion der Kommunikationsbeziehungen zwischen Anwendungsobjekten in Verbindungen und die Definition entsprechender logischer Adressspezifikationen für diese Objekte. Dadurch kann das CIP-Protokoll Verbindungen mithilfe logischer Objektadressen definieren, unabhängig von der jeweiligen Netzwerkhardware. Darüber hinaus wird eine spezifische Netzwerktechnologieplattform in ein mit der Netzwerkschnittstelle verknüpftes physisches Verbindungsobjekt abstrahiert. Dies gewährleistet, dass für CIP-Implementierungen auf verschiedenen Netzwerkplattformen lediglich das entsprechende „physikalische Verbindungsobjekt“ (z. B. „DeviceNet Link Object“, „ControlNet Link Object“ oder „Ethernet Link Object“) als Schnittstelle benötigt wird, während die Protokolle der höheren Schichten unverändert und konsistent bleiben. Dies bildet die Grundlage für die Systemvernetzung, Interoperabilität und sogar Austauschbarkeit in plattformübergreifenden, heterogenen Netzwerkumgebungen. Im Gegensatz zu vielen anderen Feldbustechnologien, die vertikal integrierte Kommunikationsprotokolle von unten nach oben aufbauen, definiert CIP Verbindungsbeziehungen nicht anhand der von der physikalischen Schicht und der Sicherungsschicht bereitgestellten Kommunikationsdienstprimitive. Stattdessen erfolgt die Definition von Verbindungsbeziehungen aufbauend auf den tatsächlichen Datenkommunikationsbedürfnissen der Benutzer und spezifischen Anwendungsbereiche der Benutzer- und Anwendungsschicht. Die Verbindungsbeziehungen werden in drei Typen unterteilt: E/A-Verbindung: Dies bezieht sich hauptsächlich auf die Kommunikationsbeziehung bei der Datenübertragung für Überwachung, Steuerung und andere Zwecke mit bestimmten Echtzeitanforderungen. Der Großteil dieser Übertragung sollte aus E/A-Daten bestehen, die üblicherweise für die Echtzeitüberwachung verwendet werden – daher der Name. Charakteristisch für diese „Verbindung“ ist, dass sie im Voraus durch Konfiguration und Zuweisung fester Ressourcen zu jedem mit der „Verbindung“ verknüpften Anwendungsobjekt und jedem Knoten der gesamten Datenverbindung mittels Konfigurationstools hergestellt werden muss. Ihr Vorteil besteht darin, dass nach dem Verbindungsaufbau alle an dieser Kommunikationsbeziehung beteiligten Anwendungsobjekte einen Konsens über den Dateninhalt erzielt haben. Daher sind alle übertragenen Daten „Metadaten“, die keine Identifizierung oder funktionale Beschreibung des Datentyps oder der Daten selbst erfordern. Dies führt zu höchster Übertragungseffizienz, und da die gesamte Datenverbindung über vorab zugewiesene Ressourcen verfügt, ist auch die Übertragungssicherheit am höchsten, wodurch die Anforderungen für die Übertragung von Echtzeit-Steuerdaten erfüllt werden. Explizite Nachricht: Verbindung: Hauptsächlich für die Übertragung von Nicht-Echtzeit-Informationen, die während der Konfiguration im Engineering-Design, der zentralen Verwaltung und Wartung, der Fehlerdiagnose und -behebung usw. benötigt werden. Sie überträgt typischerweise Daten zwischen zwei Anwendungsobjekten interaktiv über Punkt-zu-Punkt-Nachrichtenübertragung. Da sich der Dateninhalt der Nachricht mit dem Zustand und dem Interaktionsprozess beider Parteien ändert, muss die Nachricht selbst gleichzeitig eine Typkennung und eine Funktionsbeschreibung der übertragenen Daten enthalten; daher wird sie als „Explizite Nachrichtenverbindung“ bezeichnet. Charakteristisch für diese Verbindungsbeziehung ist, dass jedes Anwendungsobjekt sie dynamisch entsprechend seinen Informationsübertragungsbedürfnissen initiieren und aufbauen kann. Darüber hinaus handelt es sich um einen Punkt-zu-Punkt-Vollduplex-Kommunikationsmodus, der sich hervorragend für den interaktiven Dialog zwischen Anwendungsobjekten eignet. Nach Beendigung des Kommunikationsprozesses wird die Verbindung abgebaut und die Ressourcen werden freigegeben. Dieser Modus ist besonders geeignet für die intermittierende Datenübertragung. Brückenverbindung: Da es in großen Systemen unmöglich oder unrealistisch ist, alle Steuerungskomponenten in einem einzigen physischen Netzwerksegment zu konzentrieren, werden in der Regel mehrere miteinander verbundene Netzwerksegmente konfiguriert, die homogen oder heterogen sein können. Wenn Daten von einem Netzwerksegment zu einem anderen übertragen werden müssen, egal ob es sich um E/A-Daten oder explizite Nachrichten handelt, müssen die Zwischenknoten (Bridges) zwischen den Netzwerksegmenten die notwendigen Verbindungen für das Routing herstellen, damit eine Nachricht übertragen werden kann. In der Praxis bedeutet dies, dass jeder Knoten intern ein Back-to-Back-Verbindungsobjekt erstellen muss, das dem Link-Objekt jedes Netzwerksegments entspricht. Betrachtet man die gesamte CIP-Protokollspezifikation, so ist ihr markantestes Merkmal das abstrakte Verbindungsobjekt und sein Verbindungsklassifizierungsmodell, das perfekt auf die Anforderungen der Steuerungs- und Informationsübertragung abgestimmt ist: E/A-Verbindung, Verbindung für explizite Nachrichten und Bridged Connection. Dies macht das CIP-Protokoll zu einem echten Netzwerkkommunikationsprotokoll mit Routing-Funktionen, die unabhängig von der Netzwerkhardware sind, und zu einer zentralen technischen Spezifikation für die Vernetzung, Interoperabilität und sogar Austauschbarkeit von Systemen in heterogenen Netzwerkumgebungen. V. Fazit. Basierend auf der Untersuchung und Analyse verschiedener Feldbus-Kommunikationsprotokolle wird angenommen, dass der Feldbus-Standard nicht als einheitlicher, vertikal integrierter Standard von der Bitübertragungsschicht/Sicherungsschicht bis zur Anwendungs- und Benutzerschicht festgelegt werden sollte. Stattdessen sollte er schichtweise aufgebaut werden, entsprechend den Entwicklungs- und Veränderungscharakteristika der technischen Elemente, wobei jede Schicht sowohl interoperabel als auch unabhängig ist. Dies ermöglicht die Koexistenz und den Wettbewerb mehrerer technischer Protokolle und fördert die Vernetzung, Interoperabilität und Austauschbarkeit im Standardisierungsprozess. Der Kern des Standards könnte in der Netzwerktransportschicht angesiedelt sein, was der Funktion des TCP/IP-Protokolls entspricht. Das Verbindungsmodell in der CIP-Protokollspezifikation ist hierfür ein gutes Beispiel. Referenzen: [1] CIP Common Specification, Band 1, Version 1.0, 5. Juni 2001, ControlNet International und Open DeviceNet Vendor Association [2] EtherNet/IP Adaptation of CIP Specification, Band 2, Version 1.0, 5. Juni 2001, ControlNet International und Open DeviceNet Vendor Association