-
VERWEISE AUF VERWANDTE ANMELDUNGEN
-
Diese Anmeldung beansprucht die Priorität und den Vorteil des Anmeldedatums der vorläufigen
US-Patentanmeldung Nr. 62/859,508 , die am 10. Juni 2019 eingereicht wurde, die den Titel „Industrial Control System Architecture for Real-Time Simulation and Control“ („Industrielle Steuerungssystemarchitektur für Echtzeitsimulation und -Steuerung“) trägt und deren gesamte Offenbarung hiermit ausdrücklich durch Bezugnahme hierin aufgenommen ist.
-
TECHNISCHES GEBIET
-
Diese Patentanmeldung bezieht sich im Allgemeinen auf Industrie- und Prozessleitsysteme und insbesondere auf ein Industriesteuerungssystem, das eine Simulation der Prozesssteuerung und/oder eine tatsächliche Prozesssteuerung zur Laufzeit unter Verwendung virtualisierter Komponenten bereitstellt.
-
STAND DER TECHNIK
-
Prozess- oder industrielle Steuerungssysteme, wie diejenigen, die in Chemie-, Erdölindustrie- oder anderen industriellen Prozessanlagen zur Herstellung von physischen Produkten aus Materialien verwendet werden, beinhalten üblicherweise eine oder mehrere Prozesssteuerungen, die über analoge, digitale oder kombinierte Analog-/Digital-Busse oder über eine drahtlose Kommunikationsverbindung oder ein Drahtlos-Netzwerk mit einem oder mehreren Feldgeräten gekoppelt sind. Die Feldgeräte, wobei es sich z. B. um Ventile, Ventil-Stellungsregler, Switch und Geber (z. B. Temperatur-, Druck-, Füllstands- und Durchflusssensoren) handeln kann, befinden sich in der Prozessumgebung und übernehmen üblicherweise physische oder Prozesssteuerungs-Funktionen, wie z. B. das Öffnen oder Schließen von Ventilen, das Messen von Prozessparametern usw. zum Steuern von einem oder mehreren Prozessen innerhalb der Prozessanlage oder des Systems. Intelligente Feldgeräte, wie beispielsweise die Feldgeräte, die mit dem bekannten FOUNDATION® Fieldbus-Protokoll konform sind, können auch Steuerberechnungen, Alarmfunktionen und andere Steuerfunktionen ausführen, die üblicherweise in der Steuerung implementiert sind. Die Prozesssteuerungen, die zentral angeordnet sein können, aber auch verteilt in der Anlagenumgebung angeordnet sein können, empfangen Signale, die Prozessmessungen der Feldgeräte und/oder andere Informationen zu den Feldgeräten anzeigen, und führen eine Steuerungsanwendung aus, die beispielsweise verschiedene Steuermodule ausführt, die Prozesssteuerungsentscheidungen treffen, auf Grundlage der empfangenen Informationen Steuersignale erzeugen und sich mit den in den Feldgeräten ausgeführten Steuermodulen oder Blöcken koordinieren, wie beispielsweise HART®-, WirelessHART®- und FOUNDATION® Fieldbus-Feldgeräte. Die Steuermodule in der Steuerung senden die Steuersignale über die Kommunikationsleitungen oder -verbindungen zu den Feldgeräten, um dadurch den Betrieb mindestens eines Teils der Prozessanlage oder des Systems zu steuern.
-
Informationen von den Feldgeräten und der Steuerung werden in der Regel von den Steuerungen über eine Datenautobahn einem oder mehreren anderen Hardwaregeräten, wie z. B. Bediener-Workstations, PCs oder Rechenvorrichtungen, Daten-Historians, Berichtsgeneratoren, zentralisierten Datenbanken oder anderen zentralisierten administrativen Rechenvorrichtungen bereitgestellt, die sich in der Regel in Steuerungsräumen oder an anderen Orten entfernt von der raueren Anlagenumgebung befinden. Jedes dieser Hardwaregeräte ist in der Regel über die gesamte Prozessanlage oder einen Teil der Prozessanlage hinweg zentralisiert. Diese Hardwaregeräte führen Anwendungen aus, die es beispielsweise einem Ingenieur ermöglichen, Teile des Prozesses zu konfigurieren, oder es einem Bediener ermöglichen, Funktionen in Bezug auf die Steuerung eines Prozesses und/oder den Betrieb der Prozessanlage auszuführen, wie z. B. das Ändern von Einstellungen der Prozesssteuerungsroutine, das Modifizieren des Betriebs der Steuermodule innerhalb der Steuerungen oder der Feldgeräte, das Anzeigen des aktuellen Prozesszustands, das Anzeigen von Alarmen, die von Feldgeräten und Steuerungen erzeugt werden, das Simulieren des Prozessbetriebs zu Personalschulungszwecken oder das Testen der Prozesssteuerungssoftware, das Führen und Aktualisieren einer Konfigurationsdatenbank usw. Die von den Hardwaregeräten, Steuerungen und Feldgeräten verwendete Datenautobahn kann einen leitungsgebundenen Kommunikationsweg, einen drahtlosen Kommunikationsweg oder eine Kombination aus leitungsgebundenen und drahtlosen Kommunikationswegen beinhalten.
-
Das von Emerson Process Management verkaufte DeltaVTM-Steuerungssystem beispielsweise beinhaltet mehrere Anwendungen, die in verschiedenen Geräten gespeichert sind und von verschiedenen Geräten an verschiedenen Stellen innerhalb einer Prozessanlage ausgeführt werden. Eine Konfigurationsanwendung, die sich in einer oder mehreren Workstations oder Rechenvorrichtungen befindet, ermöglicht es dem Benutzer, Prozesssteuerungsmodule zu erstellen oder zu ändern und diese Prozesssteuerungsmodule über eine Datenautobahn auf dedizierte verteilte Steuerungen herunterzuladen. Typischerweise bestehen diese Steuerungsmodule aus kommunikativ miteinander verbundenen Funktionsblöcken, die Objekte in einem objektorientierten Programmierprotokoll sind, das Funktionen innerhalb des Steuerungsschemas auf der Basis von Eingaben ausführt und die Ausgaben an andere Funktionsblöcke innerhalb des Steuerungsschemas bereitstellt. Die Konfigurationsanwendung kann es einem Konfigurationsdesigner auch ermöglichen, Bedienoberflächen zu erstellen oder zu ändern, die von einer Anzeigeanwendung verwendet werden, um einem Bediener Daten anzuzeigen und es dem Bediener zu ermöglichen, Einstellungen, wie Sollwerte, innerhalb der Prozesssteuerungsroutinen zu ändern. Jede dedizierte Steuerung und in einigen Fällen ein oder mehrere Feldgeräte speichern eine entsprechende Steuerungsanwendung und führen sie aus, die die ihr zugeordneten und auf sie heruntergeladenen Steuerungsmodule ausführt, um die Funktionalität der tatsächlichen Prozesssteuerung zu implementieren. Die Anzeigeanwendungen, die auf einer oder mehreren Bediener-Workstations (oder auf einer oder mehreren entfernte Rechenvorrichtungen in kommunikativer Verbindung mit den Bediener-Workstations und der Datenautobahn) ausgeführt werden können, empfangen über die Datenautobahn Daten von der Steuerungsanwendung und zeigen diese Daten den Prozessleitsystem-Designern, -Bedienern oder -Benutzern über die Benutzeroberflächen an und können eine Vielzahl von verschiedenen Ansichten, wie zum Beispiel eine Bedieneransicht, eine Ingenieursansicht, eine Technikeransicht usw. bereitstellen. Eine Data Historian-Anwendung wird in der Regel in einer Data Historian-Gerät gespeichert und ausgeführt, das einige oder alle Daten erfasst und speichert, die über die Datenautobahn bereitgestellt werden, während eine Konfigurationsdatenbank-Anwendung auf noch einem weiteren Computer ausgeführt wird, der an die Datenautobahn angeschlossen ist, um die aktuelle Konfiguration der Prozesssteuerungsroutine und die damit verbundenen Daten zu speichern. Alternativ kann sich die Konfigurationsdatenbank auf der gleichen Workstation wie die Konfigurationsanwendung befinden.
-
Die Architektur von derzeit bekannten Prozesssteuerungsanlagen und Prozessleitsystemen wird stark durch begrenzten Steuerungs- und Gerätespeicher, begrenzte Kommunikationsbandbreite sowie Leistungsfähigkeit von Steuerungs- und Geräteprozessoren beeinflusst. In derzeit bekannten Prozessleitsystemarchitekturen wird beispielsweise die Verwendung von dynamischem und statischem nichtflüchtigem Speicher in der Steuerung in der Regel minimiert oder zumindest sorgfältig verwaltet. Infolgedessen muss ein Benutzer oder Konfigurationstechniker bei der Systemkonfiguration typischerweise (z. B. a priori) wählen, welche Daten in der Steuerung archiviert oder gespeichert werden sollen, mit welcher Häufigkeit sie gespeichert werden sollen und ob eine Komprimierung verwendet wird oder nicht, und die Steuerung wird entsprechend mit diesem begrenzten Satz von Datenregeln konfiguriert. Folglich werden Daten, die bei der Fehlerbehebung und Prozessanalyse nützlich sein könnten, häufig nicht archiviert, und falls sie erfasst wurden, sind die nützlichen Informationen möglicherweise aufgrund der Datenkomprimierung verloren gegangen.
-
Um die Speichernutzung der Steuerung in den derzeit bekannten Prozessleitsystemen zu minimieren, werden darüber hinaus ausgewählte Daten, die (wie in der Konfiguration der Steuerung angegeben) archiviert oder gespeichert werden sollen, an die Workstation oder die Rechenvorrichtung zur Speicherung in einem geeigneten Daten-Historian oder Datensilo gemeldet. Die aktuellen Techniken zur Meldung der Daten nutzen die Kommunikationsressourcen schlecht aus und führen zu einer übermäßigen Belastung der Steuerung. Aufgrund der zeitlichen Verzögerungen bei der Kommunikation und Abtastung beim Historian oder Silo ist die Datenerfassung und Zeitstempelung zudem oft nicht mit dem tatsächlichen Prozess synchronisiert.
-
Ebenso bleiben in Chargen-Prozessleitsystemen, um den Speicherverbrauch der Steuerung zu minimieren, Chargenrezepte und Schnappschüsse der Steuerungskonfiguration in der Regel bei einer zentralen administrativen Rechenvorrichtung oder einem solchen Standort (z. B. an einem Datensilo oder Historian) gespeichert und werden nur bei Bedarf an eine Steuerung übertragen. Eine solche Strategie führt zu erheblichen Burst-Lasten bei der Steuerung und der Kommunikation zwischen der Workstation oder der zentralen administrativen Rechenvorrichtung und der Steuerung.
-
Auf jeden Fall ist die aktuelle Architektur industrieller Steuerungssysteme wie etwa Prozessleitsystemen weitgehend durch die Hardware bestimmt, da verschiedene Funktionen, wie etwa Steuerungsfunktionen, Ein-/Ausgabefunktionen (I/O), Benutzeroberflächenfunktionen usw., auf bestimmter Hardware (z. B. Benutzer-Workstations oder Schnittstellengeräten, Prozesssteuerungen, Sicherheitssytemsteuerungen, dedizierten I/O-Geräten, I/O-Rangiergeräten, Feldgeräten, Sicherheits-Logik-Solvern usw.) ausgeführt werden und an diese gebunden sind und immer in der spezifischen Hardware gespeichert verbleiben. Beispielsweise werden in aktuellen Prozessleitsystemen Verbindungen zwischen Steuerungen und I/O-Geräten (z. B. entweder einzelnen I/O-Geräten oder Bänken von I/O-Rangiergeräten) basierend auf bestimmter Hardware konfiguriert und folglich sind physische I/O-Beziehungen eng eingegrenzt, meistens eins zu eins, z. B. I/O-Gerät mit der Steuerung, ein anderes I/O Gerät mit eine anderen Steuerung usw. Dieses Architekturdesign schränkt die Ausfallsicherheit, Zuverlässigkeit, Verfügbarkeit, Reaktionsfähigkeit und Elastizität des Steuerungssystems ein, da diese Systeme schwer in kurzer Zeit zu ändern oder neu zu konfigurieren sind, eng an proprietäre Hardware gebunden sind, die zur Implementierung proprietärer Steuerungssoftware verwendet wird, Hardware-Redundanz auf Geräteebene erfordern, deren Implementierung kostspielig sein kann, und nicht leicht skalierbar oder aufrüstbar sind, ohne um zusätzliche Hardware erweitert zu werden, die, z. B. aufgrund von Größenbeschränkungen einzelner Geräte, wie z. B. physischer Prozesssteuerungen, besonderen Eigenschaften und Fähigkeiten von I/O-Geräten usw., auf bestimmte Weise konfiguriert werden muss.
-
Einige Versuche, diese Probleme zu beheben, beinhalten die Virtualisierung physischer Steuerungen; die Steuerungs-Virtualisierung ist jedoch bisher auf Offline-Entwicklungs- und Testsysteme beschränkt und wird, wenn überhaupt, bisher nicht in großem Umfang zur Laufzeitprozesssteuerung in physischen Anlagen- und/oder Produktionsumgebungen eingesetzt. Darüber hinaus unterliegen sowohl virtualisierte als auch physische Steuerungen weiterhin den Einschränkungen physischer I/O-Geräte wie Leistung, Bandbreite, Durchsatz usw.
-
ZUSAMMENFASSUNG
-
Eine neuartige Mehrzweck-Hardware-/Software-Architektur oder -Plattform für die dynamische Simulation und/oder Laufzeit-Produktionsprozesssteuerung, die es einem industriellen oder Prozessleitsystem einer industriellen Prozessanlage ermöglicht, im Vergleich zu bekannten industriellen oder Prozessleitsystemen widerstandsfähiger, reaktionsfähiger und elastischer zu sein. Insbesondere entkoppelt diese neuartige Architektur oder Plattform die im Steuerungssystem verwendete Hardware weitgehend von der Software, die das Verhalten der Hardware steuert, wodurch das System einfacher skaliert, neu konfiguriert und geändert sowie insgesamt hinsichtlich Systemzuverlässigkeit, -verfügbarkeit und -leistung verbessert werden kann. Zur Erleichterung der Diskussion wird die neuartige Mehrzweck-Plattform oder - Architektur für dynamische Simulation und Laufzeitsteuerung hier gleichbedeutend mit „MPDSC“, „MPDSC-Plattform“, „MPDSC-System“ oder „MPDSC-Architektur“ bezeichnet.
-
Im Allgemeinen umfasst das MPDSC eine virtuelle Prozessumgebung, die an eine physische Prozessumgebung gekoppelt ist, in der Komponenten der virtuellen und physischen Umgebung zusammenarbeiten, um eine dynamische Simulation und/oder Laufzeit- (z. B. tatsächliche oder betriebliche) Produktionsprozesssteuerung der industriellen Prozessanlage durchzuführen. Für die Laufzeit-Prozesssteuerung unterstützt die MPDSC-Plattform Prozessleitsysteme (PCS), die virtuelle Komponenten, physische Komponenten und/oder sowohl virtuelle als auch physische Komponenten beinhalten können, die zusammenarbeiten, um Chargen- und/oder kontinuierliche industrielle Prozesse während der Laufzeit der Anlage zu überwachen und zu steuern. In einigen Fällen unterstützt die MPDSC-Plattform auch Safety Instrumented Systems (sicherheitstechnische Systeme - SIS), die sowohl virtuelle als auch physische Komponenten enthalten können, die zusammenarbeiten, um während der Laufzeit einen sicheren Betrieb aufrechtzuerhalten und einen ausfallsicheren Betrieb der Anlage zu gewährleisten. Virtuelle Knoten, die Laufzeit-, Betriebsprozesssteuerungs- und/oder verwandte Laufzeitfunktionen durchführen (z. B. in Verbindung mit einem oder mehreren physischen Geräten oder Komponenten, die in der physischen Umgebung der Prozessanlage angeordnet sind), werden hier als „virtuelle Laufzeitknoten“ bezeichnet.
-
Die MPDSC-Plattform kann zusätzlich oder alternativ eine Simulationsumgebung oder einen Simulationsraum unterstützen, die/der für Steuerungs- und/oder Sicherheitssystem- und/oder Komponententests, -validierung, -verifizierung und/oder -durchprüfung, Bedienerschulungen, Fallstudien und laufende Prozessverbesserungen usw. verwendet werden können. Für Simulationszwecke sieht die MPDSC-Plattform virtuelle Knoten vor, die eine oder mehrere physische Geräte, Module oder Komponenten simulieren, die in der physischen Prozessumgebung eingesetzt werden können. Virtuelle Knoten, die verschiedene Geräte, Module und/oder Komponenten simulieren, die in der physischen Umgebung der Prozessanlage eingesetzt werden können, werden hier als „simulierte Knoten“ bezeichnet.
-
Die von der MPDSC-Plattform bereitgestellte Simulation ist „dynamisch“, da Simulationen der Prozessanlage oder von Teilen davon in Echtzeit ausgeführt werden können, wodurch die Zeitsteuerung und andere Verhaltensweisen, die zur Laufzeit auftreten (würden), widergespiegelt werden, und/oder Simulationen manipuliert werden können, um schneller oder langsamer als in Echtzeit ausgeführt zu werden, um unterschiedliche Werte, Ausgangsbedingungen, Zwischenbedingungen usw. zu verwenden. Der Simulationsraum bietet verschiedene Funktionen, wie zum Beispiel Speicher-/Wiederherstellungsfunktionen für verschiedene simulierte Szenarien, bearbeitbare Ausgangs- und/oder Zwischenbedingungen für verschiedene Szenarien, Koordination mit Simulatoren von Drittanbietern über verschiedene Protokolle, Testen und Durchprüfen von Bedieneranzeigenansichten, Echtzeitsimulation eines oder mehrerer Teile des PCS, Beschleunigen und/oder Verlangsamen der Simulation des einen oder der mehreren Teile des PCS; Simulationen, die simulierte Komponenten enthalten, die in Verbindung mit tatsächlichen (z. B. nicht simulierten) virtuellen und/oder physischen Komponenten arbeiten, Änderungsverwaltung und Synchronisation mit der Anlagenkonfiguration usw. Die MPDSC-Plattform kann gleichzeitig sowohl einen Simulationsals auch Laufzeitbetrieb, verschiedene Interaktionen und Schnittpunkte zwischen Simulations- und Laufzeitbetrieb unterstützen (z. B. Testen von Upgrades, Patches, „Was-wäre-wenn“-Szenarien, Konfigurationsänderungen, Benutzereingabeänderungen und dergleichen. Darüber hinaus können mit der MPDSC-Plattform Systemredundanz, Störfalltoleranz, Umschaltungen, geplante Wartung usw. nahtlos und einfach durchgeführt werden.
-
Eine der Schlüsselkomponenten der MPDSC-Architektur wird hier als „I/O-Switch“ oder „I/O-Server“ bezeichnet, durch den im Allgemeinen I/O der Prozessanlage so abstrahiert wird, dass sie nicht länger konkret und direkt mit einer bestimmter Hardware verbunden ist, und andere Funktionen im Zusammenhang mit I/O für die Simulation und/oder Laufzeitprozesssteuerung durchgeführt werden. Der I/O-Switch oder I/O-Server ist ein Knoten, der während der Laufzeit I/O-Daten zwischen virtuellen und/oder physischen Knoten der Prozessanlage übermittelt. Jeder Knoten (ob virtuell oder physisch) ist in der Regel eine Komponente der Prozessanlage, die innerhalb des MPDSC-Systems durch einen eindeutigen Namen, ein eindeutiges Tag oder eine eindeutige Kennung identifiziert wird. Beispielsweise kann ein Knoten eine physische oder virtuelle Steuerung, ein Feldgerät, eine Sicherheitsinformationssteuerung, ein Sicherheits-Logik-Solver, eine I/O-Karte oder ein I/O-Gerät (z. B. ein drahtloses I/O-Gerät, ein Ethernet-I/O-Gerät, ein I/O-Rangierschrank oder Komponenten davon usw.), eine Bediener-Workstation, eine andere Art von Benutzeroberflächengerät, ein Werkzeug (z. B. Diagnosewerkzeug, Simulationswerkzeug usw.), ein Gateway, ein Datenspeichergerät oder eine andere Art von Komponente sein. Im Allgemeinen arbeitet der I/O-Switch als Datenbroker zwischen virtuellen und/oder physischen Knoten, wobei der I/O-Switch I/O-Daten (hier auch gleichbedeutend als „Prozess-I/O-Daten“ oder „PIO-Daten“ bezeichnet) zwischen Quellknoten (ob virtuell oder physisch) und Zielknoten (ob virtuell oder physisch) übermittelt oder umschaltet. In gewisser Weise virtualisiert der I/O-Switch die physischen Übermittlungsmechanismen von Prozess-I/O-Daten zwischen Knoten des MPDSC-Systems, statt physische I/O-Karten eng und/oder konkret an verschiedene Quell- und Zielknoten zu binden, um Prozess-I/O-Daten zu übergeben, und löst die Bindungen zwischen Hardwarekomponenten, die zum Übermitteln von I/O-Daten verwendet werden. Darüber hinaus ist der I/O-Switch so konfiguriert, dass er I/O-Daten so schnell (z. B. mit ausreichend geringer Verzögerung) übermitteln kann, dass die Laufzeit-, die tatsächliche Produktionsprozesssteuerung und/oder die Echtzeitsimulation der Produktionsprozesssteuerung unterstützt wird.
-
Im Allgemeinen enthalten virtuelle und physische Knoten/Komponenten, die vom I/O-Switch oder I/O-Server bedient werden, Module, die jeweils das Verhalten von virtuellen und physischen Knoten oder Komponenten steuern. Solche Module werden hier als „Komponentenverhaltensmodule“ oder „CBM“ bezeichnet, von denen Beispiele Steuermodule in Steuerungen, Sicherheitslogik in Sicherheits-Logik-Solvern und andere Arten von Modulen beinhalten, die zumindest teilweise durch das Ausführen von Operationen auf I/O-Daten das Verhalten und den Betrieb der Komponenten steuern, in denen die Module gespeichert sind und ausgeführt werden. Innerhalb des MPDSC-Systems sind CBM, die auf der prozessbezogenen Nutzlast der I/O-Daten Operationen durchführen, agnostisch oder in Unkenntnis über den I/O-Switch und seine Rolle bei der Übermittlung von I/O-Daten zu/von den Komponentenverhaltensmodulen. Das heißt, die CBM wissen nicht, ob es sich bei ihrem jeweiligen I/O-Übermittlungsmechanismus zu/von ihrem Hostknoten um eine physische I/O-Karte oder den I/O-Switch handelt.
-
Daher kann der I/O-Switch als Switching Fabric, Router und/oder Übermittlungsmechanismus für I/O-Daten angesehen werden, der für Komponentenverhaltensmodule des MPDSC-Systems transparent ist. Hierzu übermittelt der I/O-Switch I/O-Daten zwischen virtuellen und/oder physischen Knoten über entsprechende Publish-/Subscribe-(Veröffentlichungs-/Abonnement)-Schichten der Knoten (hier auch gleichbedeutend als „Pub-/Sub-Schicht“ bezeichnet) und ein virtuelles Kommunikationsnetzwerk, über das die I/O-Nutzlastdaten oder Daten zwischen Knoten übertragen werden. Beispielsweise kann ein sendender oder veröffentlichender Knoten eine jeweilige Pub-/Sub-Schicht enthalten, die vom Komponentenverhaltensmodul des sendenden Knotens generierte Daten im virtuellen Kommunikationsnetzwerk veröffentlicht. Der I/O-Switch kann die veröffentlichten Daten an Knoten zustellen oder vermitteln, die Empfänger oder Abonnenten der Daten sind, und jeder Abonnentenknoten kann die Daten über seine jeweilige Pub-/Sub-Schicht für den Gebrauch durch sein jeweiliges Komponentenverhaltensmodul wiederherstellen. Als solches vermittelt der I/O-Switch Daten zwischen Veröffentlicherknoten und Abonnentenknoten auf Bedarfsbasis gemäß den definierten Beziehungen der Knoten zueinander innerhalb des MPDSC-Systems.
-
Dabei bezieht sich hier die „physische Umgebung“ der MPDSC-Plattform oder des MPDSC-Systems auf die Produktionsanlage oder -umgebung, in der physische, materielle Komponenten (z. B. Feldgeräte, Tanks, Ventile, Stellantriebe, Heizungen, Verdampfer, Sensoren usw.) verwendet werden, um physische Materialien über laufzeitgesteuerte Prozesse in physische Produkte umzuwandeln. Dementsprechend wird die „physische Umgebung“ hier gleichbedeutend als „Anlagenumgebung“ der industriellen Prozessanlage bezeichnet. Wie vorstehend erörtert, beinhaltet die physische oder Anlagenumgebung einen Front-End-Teil, in dem physische oder Hardwarekomponenten des MPDSC-Systems wie Feldgeräte, Sensoren, Geber, Switch, Stellungsregler, Tanks, Heizungen usw. angeordnet sind und physische Materialien zur Herstellung physischer Produkte bearbeiten. Als solches wird der „Front-End“-Teil der physischen Umgebung hier gleichbedeutend als „Feld“- oder „Standort“-Teil der physischen Umgebung der Prozessanlage bezeichnet.
-
Die physische oder Anlagenumgebung des MPDSC-Systems beinhaltet auch einen Back-End-Teil, in dem physische oder Hardwarekomponenten wie Bediener-Workstations, Personalcomputer oder Rechenvorrichtungen, Daten-Historians, Berichtsgeneratoren, zentralisierte Datenbanken und/oder sonstige zentralisierte (oder zumindest teilweise zentralisierte) administrative Rechenvorrichtungen Anwendungen ausführen, um beispielsweise die Prozessanlage und/oder ihre Komponenten zu konfigurieren, den Laufzeitbetrieb der Anlage anzuzeigen und zu überwachen, auf Warnungen oder Alarme während des Laufzeitbetriebs der Anlage zu reagieren, Parameter während des Laufzeitbetriebs der Anlage einzustellen, Berichte zu generieren, Daten zu speichern und zu analysieren und dergleichen. Der Back-End-Teil der physischen Umgebung des MPDSC-Systems kann sich in Bereichen, die vor der raueren Feldumgebung geschützt sind, z. B. in einem geschlossenen Raum am Standort und/oder an Orten außerhalb des Standorts oder entfernt von der Feldumgebung, befinden.
-
Die virtuelle Umgebung des MPDSC-Systems wird unter Verwendung von physischen oder Hardware-Rechenvorrichtungen implementiert, die speziell konfiguriert und miteinander verbunden sind, um eine Plattform bereitzustellen, die die Virtualisierung verschiedener physischer Prozessanlagenkomponenten unterstützt, wie in späteren Abschnitten dieser Offenbarung ausführlicher beschrieben wird. Im Allgemeinen können sich die physischen Rechenvorrichtungen, die die Virtualisierungsplattform bereitstellen und unterstützen, physisch am Standort in der Anlage befinden (z. B. in geschützten, geschlossenen Bereichen der Feldumgebung), können sich physisch außerhalb des Standorts befinden oder können sich physisch und verteilt an verschiedenen Orten am Standort und außerhalb des Standorts befinden. Die physischen Rechenvorrichtungen, die die Virtualisierungsplattform bereitstellen und unterstützen, können über eine beliebige Anzahl von physischen Datenverbindungen und/oder Kommunikations-/Datennetze miteinander verbunden sein. Im Allgemeinen bilden die physischen Rechenvorrichtungen, Datenverbindungen und Kommunikations-/Datennetze eine Datenverarbeitungsplattform, auf der sich verschiedene logische oder virtuelle Komponenten des MPDSC-Systems befinden, auf der die verschiedenen logischen oder virtuellen Komponenten zur Laufzeitprozesssteuerung in Verbindung mit Komponenten der physischen Prozessumgebung und/oder zu Prozesssimulationszwecken verwendet werden können.
-
Die logischen oder virtuellen Komponenten, die sich in der virtuellen Umgebung des MPDSC-Systems befinden, können eine Simulation eines oder mehrerer tatsächlicher oder geplanter physischer Teile des MPDSC-Systems bereitstellen (z. B. gegebenenfalls in Echtzeit, bei höheren Geschwindigkeiten und/oder bei niedrigeren Geschwindigkeiten). Bei einigen Implementierungen können die logischen oder virtuellen Komponenten, die sich in der virtuellen Umgebung des MPDSC-Systems befinden, und die physischen Komponenten, die sich in der physischen Umgebung des MPDSC-Systems befinden, zusammenarbeiten, um eine Simulations- und/oder tatsächliche Produktionsprozesssteuerung zur Laufzeit bereitzustellen. Als solches sind in einigen Ausführungsformen die physischen und virtuellen Umgebungen der MPDSC-Plattform über eine oder mehrere Kommunikationsverbindungen und/oder Netzwerke kommunikativ untereinander verbunden, wobei die Kommunikationsverbindungen und/oder Netzwerke eine beliebige Anzahl von leitungsgebundenen Verbindungen und/oder Netzwerken, drahtlosen Verbindungen und/oder Netzwerken, privaten Verbindungen und/oder Netzwerken, öffentlichen Verbindungen und/oder Netzwerken enthalten können. Ausführungsformen einer eigenständigen virtuellen Echtzeitsimulation und Ausführungsformen der Zusammenarbeit zwischen den logischen/virtuellen und physischen Komponenten des industriellen Steuerungssystems und kommunikative Verbindungen zwischen diesen werden in späteren Abschnitten dieser Offenbarung ausführlicher beschrieben.
-
Ferner verwenden oder nutzen die virtuellen und physischen Umgebungen der MPDSC-Plattform eine gemeinsame (z. B. dieselbe) Systemkonfigurationsdatenbank, die hier als „MPDSC-Systemkonfigurationsdatenbank“ bezeichnet wird. Daher können über die MPDSC-Systemkonfigurationsdatenbank verschiedene virtuelle und physische Komponenten innerhalb der MPDSC-Plattform sowohl in virtuellen als auch in physischen Umgebungen eindeutig identifiziert werden und Schnittstellen zwischen Simulations- und Laufzeitbetrieb (z. B. Testen, Umschalten usw.) können nahtlos und einfach ausgeführt werden.
-
Bei einer Ausführungsform beinhaltet ein Verfahren zum Steuern eines industriellen Prozesses einer industriellen Prozessanlage während des Laufzeitbetriebs der industriellen Prozessanlage das Ausführen eines Prozessregelkreises eines Prozessleitsystems, um mindestens einen Teil des industriellen Prozesses zu steuern. Der Prozessregelkreis weist ein Feldgerät, das sich in einer physischen Umgebung der industriellen Prozessanlage befindet, eine Prozesssteuerung und einen I/O-Knoten auf, der mit dem Feldgerät und der Prozesssteuerung kommunikative verbunden ist. Das Ausführen des Prozessregelkreises beinhaltet, dass in einem Echtzeit-Steuerungsprotokoll am I/O-Knoten eine erste Veröffentlichung abgerufen wird, wobei die erste Veröffentlichung den vom Feldgerät während des Ausführens des Prozessregelkreises erzeugten Dateninhalt angibt, wobei das Abrufen der ersten Veröffentlichung auf einem Abonnement des I/O-Knotens basiert, das dem vom Feldgerät erzeugten Dateninhalt entspricht. Zusätzlich beinhaltet das Ausführen des Prozessregelkreises das Bestimmen eines Abonnenten von Veröffentlichungen, die den vom Feldgerät erzeugten Dateninhalt angeben, durch den I/O-Knoten, wobei der Abonnent der Prozesssteuerung entspricht; und das Erzeugen und Veröffentlichen einer zweiten Veröffentlichung durch den I/O-Knoten im Echtzeit-Steuerungsprotokoll, wobei die zweite Veröffentlichung den vom Feldgerät erzeugten Dateninhalt angibt. Damit bewirkt das Verfahren, dass der vom Feldgerät erzeugte Dateninhalt der Prozesssteuerung innerhalb eines Zeitintervalls zur Verfügung gestellt wird, das kleiner oder gleich einer maximalen Übertragungsverzögerung ist, die der Lieferung von Daten, z. B. Prozessdaten, vom Feldgerät an die Prozesssteuerung während der Ausführung des Prozessregelkreises während des Laufzeitbetriebs der industriellen Prozessanlage entspricht.
-
Bei einer Ausführungsform beinhaltet ein Prozessleitsystem zum Steuern eines industriellen Prozesses einer industriellen Prozessanlage einen Prozessregelkreis mit einem Feldgerät, das sich in einer physikalischen Umgebung der industriellen Prozessanlage befindet, und eine Prozesssteuerung. Das Feldgerät und die Prozesssteuerung sind in einem Prozessregelkreis des Prozessleitsystems über ein Echtzeit-Steuerungsnetzwerk kommunikativ miteinander verbunden und der Prozessregelkreis wird zum Steuern mindestens einen Teil des industriellen Prozesses während des Laufzeitbetriebs der industriellen Prozessanlage ausgeführt. Das Prozessleitsystem enthält ferner das Echtzeit-Steuerungsnetzwerk, das einen I/O-Knoten enthält, der mehrere andere Knoten kommunikativ verbindet. Der I/O-Knoten und die mehreren anderer Knoten kommunizieren über das Echtzeit-Steuerungsnetzwerk, indem sie Daten unter Verwendung eines Echtzeit-Steuerungsprotokolls in dem Echtzeit-Steuerungsnetzwerk veröffentlichen und indem sie Daten abonnieren, die unter Verwendung eines Echtzeit-Steuerungsprotokolls im Echtzeit-Steuerungsnetzwerk veröffentlicht wurden. Ein erster Knoten der mehreren anderen Knoten entspricht dem Feldgerät und ein zweiter Knoten der mehreren anderer Knoten entspricht der Prozesssteuerung. Während der Laufzeitausführung des Prozessregelkreises werden Prozessdaten, z. B. über den ersten Knoten, den I/O-Knoten und den zweiten Knoten des Echtzeit-Steuerungsnetzwerks zwischen dem Feldgerät und der Prozesssteuerung innerhalb eines Zeitintervalls geliefert, das kleiner oder gleich einer maximalen Übertragungsverzögerungstoleranz ist und z. B. der Zustellung von Echtzeit-Prozessdaten zwischen dem Feldgerät und Prozesssteuerung während der Ausführung des Prozessregelkreises während des Laufzeitbetriebs der industriellen Prozessanlage entspricht.
-
Figurenliste
-
- 1 ist ein Blockdiagramm eines beispielhaften dynamischen Mehrzweck-Simulations- und Laufzeit-Industrie- oder Prozessleitsystems (MPDSC), das eine dynamische Simulation und/oder Laufzeitprozesssteuerung einer industriellen Prozessanlage bereitstellt.
- 2 ist ein Blockdiagramm, das Ausführungsformen beispielhafter virtueller Knotenarchitekturen darstellt, die Bestandteil des MPDSC-Systems aus 1 sein können.
- 3 ist eine beispielhafte Anordnung einer physischen Anlagenumgebung, die das MPDSC-System aus 1 unterstützen kann.
- 4 veranschaulicht eine beispielhafte Anordnung mehrerer I/O-Switches, die zumindest teilweise in dem MPDSC-System aus 1 implementiert sein können.
- 5 ist ein Blockdiagramm, das ein beispielhaftes Virtualisierungsverwaltungssystem darstellt, über das mindestens Teile des MPDSC-Systems aus 1 konfiguriert und administriert werden können.
- 6 ist ein Flussdiagramm eines beispielhaften Verfahrens zum Steuern eines industriellen Prozesses einer industriellen Prozessanlage.
-
DETAILLIERTE BESCHREIBUNG
-
1 ist ein Blockdiagramm eines beispielhaften dynamischen Mehrzweck-Simulations- und Laufzeit-Industrie- oder Prozessleitsystems (MPDSC) oder einer Plattform 10, das/die eine dynamische Simulation und/oder Laufzeit-Prozesssteuerung einer industriellen oder Prozessanlage bereitstellt. Die beispielhafte MPDSC-Plattform 10 unterstützt die dynamische Simulation der Prozesssteuerung der industriellen Prozessanlage und/oder die Echtzeit-Prozesssteuerung unter Verwendung virtualisierter Geräte. Beispielsweise können die virtualisierten Geräte von der MPDSC-Plattform 10 während der Laufzeit der Prozessanlage für Zwecke der physischen Produktion verwendet werden. Wie in 1 gezeigt, umfasst die MPDSC-Plattform 10 einen virtuellen Anlagenumgebungsteil 12 und einen physischen Anlagenumgebungsteil 15; in Ausführungsformen, in denen die MPDSC-Plattform 10 ausschließlich für Echtzeitsimulationszwecke verwendet wird, kann jedoch der Teil 15 der physischen Anlagenumgebung weggelassen werden. Im Allgemeinen bilden der virtuelle Anlagenumgebungsteil 12 und der physische Anlagenumgebungsteil 15 zusammen eine oder mehrere Operations Technology-(OT)-Schicht(en) 18 der industriellen Prozessanlage, die generierte Daten für eine oder mehrere Information Technology-(IT)-Schicht(en) 20 bereitstellen können, die mit der industriellen Prozessanlage und/oder den Netzwerken außerhalb der IT-Schichten verbunden sind, z. B. zur unternehmensinternen und/oder externen Verwendung durch eine oder mehrere Anwendungen 21a-21n, 22a-22m. Beispielsweise können die Anwendungen 21a-21m von dem Unternehmen bereitgestellt werden, das die MPDSC-Plattform 10 besitzt/betreibt, und in einer mit dem Unternehmen verbundenen IT-Schicht ausgeführt werden, und die Anwendungen 22a-22m können Anwendungen des Internet of Things (IoT, Internet der Dinge) und/oder des Industrial Internet of Things (IIoT, industrielles Internet der Dinge) sein, die von jeweiligen Drittanbietern bereitgestellt werden, die dies in Remote-Netzwerken ausführen, auf die über das Internet oder ein anderes öffentliches Netzwerk zugegriffen wird.
-
Die IT-Schichten 20 des Unternehmens können in einer beliebigen Anzahl von lokal und/oder entfernt angeordneten Rechenvorrichtungen implementiert sein, wie beispielsweise einer oder mehreren lokalen und/oder entfernten Serverbanken, einer oder mehreren Datenverarbeitungs-Clouds usw., und können eine beliebige Anzahl von Anwendungen oder Verbrauchern 21a-21n von Daten, die durch die OT-Schichten 18 des Unternehmens generiert wurden, enthalten. Typischerweise (aber nicht notwendigerweise) und wie in 1 dargestellt, sind die OT-Schichten 18 über ein oder mehrere öffentliche und/oder private Kommunikationsnetze 24 und ein oder mehrere Edge-Gateway-Systeme 28 kommunikativ mit den IT-Schichten 20 gekoppelt, wobei das (die) Edge-Gateway-System(e) 28 Sicherheit und Effizienz der Datenübermittlung zwischen den OT-Schichten 18/der MPDSC-Plattform 10 und den IT-Schichten 20 bereitstellen. Ferner können das eine oder die mehreren Edge-Gateway-Systeme 28 Sicherheit und Effizienz der Datenübermittlung zwischen der MPDSC-Plattform 10 und externen Netzwerken und/oder externen Anwendungen 22 bereitstellen.
-
In 1 enthält die virtuelle Anlagenumgebung 12 der MPDSC-Plattform 10 einen oder mehrere virtuelle Knoten (VN) 30a, 30b, 30c ... 30p, die kommunikativ mit einem I/O-Switch 25 verbunden sind (der hier gleichbedeutend als „I/O-Server“ bezeichnet wird). Im Allgemeinen ist jeder virtuelle Knoten 30x eine virtuelle Maschine, die das Verhalten einer jeweiligen physischen Komponente simuliert oder virtualisiert, die in der physischen Anlagenumgebung 15 betriebsfähig sein kann. Anders ausgedrückt, verarbeitet jeder virtuelle Knoten 30x in der virtuellen Anlagenumgebung 12 Daten und verhält sich auf dieselbe Weise, wie sein physisches Gegenstück in der physischen Anlagenumgebung 15 Daten verarbeiten und sich verhalten würde.
-
Insbesondere beinhaltet jeder virtuelle Knoten 30x einen Framework und ein oder mehrere Subsysteme 32, die es dem VN 30x ermöglichen, mit anderen virtuellen Knoten 30x innerhalb der virtuellen Anlagenumgebung 12 und/oder mit einem oder mehreren physischen Knoten (PN) innerhalb der physischen Anlagenumgebung 15 zu kommunizieren, wie beispielsweise den physischen Knoten 40a, 40b, 40c und dem Edge-Gateway-System 28 (wobei das Edge-Gateway 28 als ein bestimmter Typ von PN angesehen werden kann), von denen jedes entsprechende Frameworks und jeweils ein oder mehrere Subsysteme 42x enthält, die die Kommunikation mit virtuellen Knoten ermöglichen 30x. Zusätzlich kann die MPDSC-Plattform 10 eine beliebige Anzahl anderer physischer Knoten oder Komponenten (z. B. PNa-PNk) enthalten.
-
Virtuelle Knoten können verschiedene Typen von physischen Knoten virtualisieren. Allgemein gesprochen wird der Ausdruck „physischer Knoten“ hier für ein physisches Gerät oder eine physische Komponente der MPDSC-Plattform 10 verwendet, die Hardware enthält und Daten an andere Geräte oder Komponenten (ob virtuell oder physisch) sendet und/oder von diesen empfängt. Beispiele für Typen physischer Knoten, die durch jeweilige virtuelle Knoten dargestellt sein können, sind, ohne darauf beschränkt zu sein: verschiedene Typen von Prozessleitsteuerungen; verschiedene Typen lokaler und/oder entfernter I/O-Geräte oder -Karten (z. B. drahtlose 1/0-Karten (WIOC), Ethernet-I/O-Karten (EIOC) usw.) und verschiedene Komponenten von elektronischen Rangier-I/O-Systemen (wie Charakterisierungsmodulen (CHARM), Klemmenblöcken, CHARM-I/O-Karten (CIOC) usw.); verschiedene Typen von SIS-(Safety Instrumented System)-Knoten wie Sicherheitssteuerungen, Sicherheits-Logik-Solver, SIS-Repeater, Sicherheitsnetzwerkbrücken, Sicherheitsnetzwerk-Gateways usw.; Benutzeroberflächengeräte, einschließlich lokaler und/oder entfernter physischer Bediener-Workstations, mobile Geräte und/oder andere Rechenvorrichtungen, die Benutzeroberflächen für den Laufzeitbetrieb und/oder für andere Zwecke im Zusammenhang mit der MPDSC-Plattform 10 bereitstellen; lokale und/oder entfernte physische Rechenvorrichtungen, die Tools für die MPDSC-Plattform 10 bereitstellen, z. B. Steuerungskonfigurationstools, Datenkonsolidierungs- und Anzeigetools, Datenanalyse- und Analysekonfigurationstools, Anzeigeansichtskonfigurationstools, Diagnosetools, Bestandsverwaltungstools, Anwendungsstationen usw.; verschiedene Typen von Gateways, die innerhalb und/oder von der MPDSC-Plattform 10 verwendet werden, wie drahtlose Gateways, Sicherheitsgateways, Firewalls, Edge-Gateways, Feldgateways, systemübergreifende Gateways usw.; und andere Typen von physischen Knoten, die innerhalb einer physischen Anlagenumgebung 15 verwendet werden können.
-
In einigen Ausführungsformen kann ein einzelner VN 30x einen gesamten physischen Knoten darstellen oder virtualisieren. In einigen Ausführungsformen kann ein einzelner VN 30x einen oder mehrere Teile eines bestimmten physischen Knotens darstellen oder virtualisieren. Beispielsweise kann ein einzelner VN 30x ein bestimmtes Modul oder eine bestimmte Gruppe von Modulen darstellen oder virtualisieren, die in dem bestimmten PN ausgeführt werden oder sich dort befinden, wobei solche Module Softwaremodule oder -komponenten, Firmwaremodule oder -komponenten und/oder Hardwaremodule oder -komponenten einschließen können. Beispielsweise kann ein erster VN eine gesamte Anwendung darstellen oder virtualisieren, die auf dem bestimmten PN ausgeführt wird (wie die Gesamtheit eines Steuermoduls, das auf einer physischen Prozesssteuerung ausführbar ist), ein zweiter VN kann eine Teilmenge der gesamten Anwendung darstellen oder virtualisieren, die auf dem bestimmten PN (wie einem bestimmten Steuermodell, einer bestimmten Funktion oder einer bestimmten Routine, die vom Steuermodul verwendet wird) ausgeführt wird, ein dritter VN kann das Verhalten einer protokollspezifischen I/O-Karte oder eines protokollspezifischen Geräts darstellen oder virtualisieren, das/die dem bestimmten PN zugeordnet ist, und/oder ein vierter VN kann eine PN-Unterkomponente darstellen oder virtualisieren, und zwar so granular wie eine Hardware-Unterkomponente des bestimmten PN (z. B. ein Anschluss oder eine andere Schnittstelle, ein Bus, ein Transceiver, ein Chip, eine Leiterplatte usw.) oder eine Firmware- oder Software-Unterkomponente des bestimmten PN (z. B. ein Modul, eine Routine, eine Funktion oder ein Verhalten, eine Netzwerkadresse des bestimmten PN, wie z. B. eine MAC-(Media Access Control)-Adresse oder eine andere Art von Adressen usw.).
-
Beispiele für Typen von physischen I/O-Karten, die in der physischen Anlagenumgebung 15 verwendet werden können und die durch virtuelle Knoten 30x des MPDSC 10 dargestellt und/oder virtualisiert werden können, sind, aber nicht beschränkt auf, u. a.:
- diskrete Ausgangskarten, einschließlich eigensicherer und redundanter diskreter Ausgangskarten mit hoher Dichte;
- diskrete Eingangskarten, einschließlich eigensicherer und redundanter diskreter Eingangskarten mit hoher Dichte;
- analoge Eingangskarten, einschließlich analoger Eingangskarten, die das HART®-(Highway Addressable Remote Transducer)-Kommunikationsprotokoll unterstützen, redundante analoge Eingangskarten, die HART unterstützen, redundante analoge Eingangskarten mit hoher Dichte, die HART unterstützen, und schnelle analoge Eingangskarten;
- analoge Ausgangskarten, einschließlich analoger Ausgangskarten, die HART unterstützen, redundante analoge Ausgangskarten, die HART unterstützen, redundante analoge Ausgangskarten mit hoher Dichte, die HART unterstützen, und schnelle analoge Ausgangskarten;
- serielle Karten, einschließlich redundanter, programmierbarer und redundanter programmierbarer serieller Karten;
- Schnittstellenkarten für diskrete Stellantriebe und/oder Sensoren, RTD-(Resistance Temperature Detector)-Karten, Thermoelementkarten, Millivoltkarten, isolierte Temperaturkarten, Multifunktionskarten, Ereignisabfolgekarten, die das Fieldbus-Kommunikationsprotokoll unterstützen, redundante, Fieldbus-unterstützende Karten; Karten, die das Profibus-Kommunikationsprotokoll unterstützen; redundante, Profibus unterstützende Karten und andere Typen von physischen Karten.
-
Wie in 1 veranschaulicht kommunizieren die VN 30a, 30b, 30c, ..., 30p miteinander und mit dem I/O-Switch 25 über die jeweiligen Veröffentlichungs-/Abonnementschichten 32a, 32b, 32c, ..., 32p und 35, die hier gleichbedeutend als „Pub-/Sub-Schichten“ bezeichnet werden und die in 1 durch die jeweiligen mit Raute markierten Teile 32x, 35 eines jedem VN 30x und des I/O-Switches 25 bezeichnet sind. In Ausführungsformen der MPDSC-Plattform 10, in denen physische Knoten enthalten sind, wie in 1 dargestellt, können mindestens einige der PN 28, 40a, 40b, 40c, die in der physischen Anlagenumgebung 15 angeordnet sind, entsprechende Pub-/Sub-Schichten 38, 42a, 42b, 42c enthalten. In gewisser Weise dienen die Pub-/Sub-Schichten 32x, 35 (und in einigen Anordnungen die Pub-/Sub-Schichten 38, 42x) als virtuelles Kommunikationsnetzwerk 45, über das verschiedene virtuelle Knoten 30x und der I/O-Switch 25 (und in einigen Anordnungen die physischen Knoten 40x) abstrahierte I/O-Daten kommunizieren können. In einem Implementierungsbeispiel ist jede Pub-/Sub-Schicht 32x, 35, 38, 42x eine entsprechende Schnittstelle zum virtuellen Kommunikationsnetzwerk 45.
-
Das virtuelle Kommunikationsnetzwerk 45 kann durch eine oder mehrere physische Kommunikations- und/oder Datenverbindungen und/oder -Netzwerke implementiert sein, die leitungsgebundene und/oder drahtlose Netzwerke einschließen können und die unter Verwendung einer beliebigen geeigneten Technologie wie Ethernet, optisch, IP, ein anderes Paketnetzwerk von einem anderen Typ usw. implementiert werden können. Die Daten werden zwischen Knoten des virtuellen Kommunikationsnetzwerks 45 über Veröffentlichungen und Abonnements übermittelt und jedes oder mehrere geeignete Kommunikationsprotokolle, die Veröffentlichungen und Abonnements unterstützen, können innerhalb des virtuellen Kommunikationsnetzwerks 45 für die Übermittlung von Daten verwendet werden. Beispielsweise können private Paketprotokolle und/oder öffentliche oder standardisierte Paketprotokolle (wie IPv6-, IoT- und/oder IIoT-Protokolle) zum Veröffentlichen und Abonnieren von I/O-Daten verwendet werden, die zwischen verschiedenen Knoten 30x, 28, 40x des virtuellen Kommunikationsnetzwerks 45 und optional an andere Anwendungen 21x, 22x, z. B. über Edge-Gateway-Systeme 28, übermittelt werden.
-
Beispielsweise kann jeder Knoten des virtuellen Kommunikationsnetzwerks 45 (z. B. die virtuellen Knoten 30x, der I/O-Switch 25, die physischen Knoten 28, 40x usw.) I/O-Daten über seine jeweilige Pub-/Sub-Schicht (z. B. über die Pub-/Sub-Schichten 32x, 35, 38, 42x usw.) im virtuellen Kommunikationsnetzwerk 45 veröffentlichen, und jeder Knoten des virtuellen Kommunikationsnetzwerks 45 (z. B. die virtuellen Knoten 30x, der I/O-Switch 25, die physischen Knoten 28, 40x usw.) kann I/O-Daten abonnieren und erhalten, die über ihre jeweilige Pub-/Sub-Schicht (z. B. über die Pub-/Sub-Schichten 32x, 35, 38, 42x usw.) im virtuellen Kommunikationsnetzwerk 45 veröffentlicht werden. Typischerweise besteht bei Abonnements für verschiedene veröffentlichte Daten eine Eins-zu-Eins-Entsprechung zwischen dem I/O-Switch 25 und jedem der anderen Knoten 30x, 28, 40x. In einer bevorzugten Ausführungsform akzeptiert jeder Knoten 30x, 28, 40x des virtuellen Kommunikationsnetzwerks 45 Abonnements nur vom I/O-Switch 25 und nicht von anderen Knoten, und jeder Knoten 30x, 28, 40x abonniert nur I/O-Daten, die vom I/O-Switch 25 veröffentlicht werden (wobei die vom I/O-Switch 25 veröffentlichten I/O-Daten weitergeleitete Daten sein können, die von anderen Knoten generiert wurden und die der I/O-Switch 25 abonniert hat) und nicht I/O-Daten, die von anderen Knoten veröffentlicht wurden. Als solches sind in dieser bevorzugten Eins-zu-Eins-Ausführungsform ungerichtete Graphen von Veröffentlichungs-/Abonnementbeziehungen eingeschränkt im Vergleich zu Ausführungsformen, die es Knoten ermöglichen, mehrere Abonnements mit mehreren anderen Knoten zu haben, wodurch die Netzwerkkomplexität verringert, die Netzwerkdiagnose und - Verwaltung vereinfacht und die Netzwerklast/-auslastung verringert werden. Um die Netzwerkkomplexität weiter zu verringern, die Netzwerkdiagnose und -verwaltung zu vereinfachen und die Netzwerklast/-auslastung zu verringern, kann zusätzlich oder alternativ jeder Knoten 30x, 28, 40x des virtuellen Kommunikationsnetzwerks 45 per Veröffentlichung an den I/O-Switch 25 nur Daten senden, die vom I/O-Switch 25 an andere Knoten der MPDSC-Plattform 10 weitergeleitet werden sollen. Natürlich können in einigen Ausführungsformen zumindest Teile von ungerichteten Graphen auf Wunsch in Eins-zu-Viele-, Viele-zu-Eins- und/oder Viele-zu-Viele-Beziehungen implementiert werden.
-
Im Allgemeinen werden innerhalb der MPDSC-Plattform 10 prozessbezogene Nutzlastdaten (z. B. wie sie von CBM und/oder physischen Komponenten der Prozessanlage generiert werden) abstrahiert und als I/O-Daten veröffentlicht und können an Abonnentenknoten des virtuellen Kommunikationsnetzwerks 45 auf Bedarfsbasis übermittelt werden. Das heißt, I/O-Daten können bereitgestellt werden (z. B. über Veröffentlichung), wenn der Veröffentlichungsknoten bestimmt, dass die prozessbezogene Datennutzlast ein neues Veröffentlichungsereignis erfordert. Beispielsweise kann ein Veröffentlichungsknoten automatisch einen bestimmten Typ von sensorgenerierten Daten als I/O-Daten in dem virtuellen Kommunikationsnetzwerk veröffentlichen, wenn sich der Wert der sensorgenerierten Daten ändert. Optional kann der Veröffentlichungsknoten den vom Sensor generierten Datenwert periodisch (z. B. alle fünf Sekunden, zehn Sekunden, jede Minute usw.) als I/O-Daten veröffentlichen, selbst wenn sich der vom Sensor generierte Datenwert nicht geändert hat, z. B. um dadurch verlorene Nachrichten und andere möglicherweise auftretende Wiedergabetreueprobleme zu mindern. Daher ist in einigen Ausführungsformen keine explizite Abonnementrate erforderlich und/oder wird eine solche nicht von Abonnentenknoten verwendet. Folglich wird die Ausführung der Verarbeitungslogik (z. B. des Komponentenverhaltensmoduls) an jedem Abonnentenknoten von eingehenden Daten gesteuert, die über das virtuelle Kommunikationsnetzwerk 45 abonniert und empfangen werden, und dementsprechend können Ressourcen, die von jedem Knoten und vom virtuellen Kommunikationsnetzwerk 45 verwendet werden, effizienter genutzt werden.
-
In einem veranschaulichenden Beispielszenario kann VN 30a zur Laufzeit einen bestimmten Satz prozessbezogener Nutzlastdaten, z. B. „Daten1“, als I/O-Daten generieren und in seiner Pub-/Sub-Schicht 32a veröffentlichen. Der I/O-Switch oder Server 25 kann ein Abonnement für I/O-Daten haben, das die Daten1 einschließt, und kann die prozessbezogenen Nutzlast-Daten 1 über das virtuelle Kommunikationsnetzwerk 45, seine jeweilige Pub-/Sub-Schicht 35 und sein jeweiliges Abonnement erhalten. Der I/O-Switch oder Server 25 kann wiederum die erhaltenen prozessbezogenen Nutzlast-Daten1 als I/O-Daten über seine Pub-/Sub-Schicht 35 im virtuellen Kommunikationsnetzwerk 45 veröffentlichen, damit sie von den Knoten empfangen werden, die Abonnements für I/O-Daten, das die Daten1 einschließt, haben. Beispielsweise kann VN 30b ein Abonnement für I/O-Daten haben, das die Daten1 einschließt, und bei Veröffentlichung von Daten1 als I/O-Daten über die Pub-/Sub-Schicht 35 des I/O-Switches 25 kann VN 30b die prozessbezogenen Nutzlast-Daten1 über das virtuelle Kommunikationsnetzwerk 45, seine jeweilige Pub-/Sub-Schicht 32b und deren Abonnement dafür erhalten. Anschließend kann VN 30b auf den erhaltenen prozessbezogenen Nutzlast-Daten1-Werten Operationen ausführen.
-
Somit abstrahiert die MPDSC-Plattform 10 mehrere verschiedene Typen von I/O, die für verschiedene physischen Komponenten industrieller Prozessanlagen nativ sind und dort verwendet werden (z. B. diskreter Ausgang, diskreter Eingang, analoger Ausgang, analoger Eingang, serieller I/O, Railbus, HART, Wireless HART, Fieldbus, Profibus, Ethernet, Advanced Physical Layer und/oder andere Typen von I/O) zur Übermittlung zwischen virtuellen und physischen Knoten über den I/O-Switch 25 und im virtuelle Kommunikationsnetzwerk 45 über Veröffentlichung und Abonnement. Jeder Knoten des virtuellen Kommunikationsnetzwerks 45 kann eine entsprechende Abstraktion und De-Abstraktion (z. B. Wiederherstellung) von I/O-Daten durchführen, die er über seine jeweilige Pub-/Sub-Schicht und optional andere Subsysteme sendet und empfängt.
-
Virtuelle Knoten
-
Um I/O-Abstraktion und -De-Abstraktion zu veranschaulichen, zeigt 2 zwei beispielhafte architektonische Ausführungsformen 52a, 52b eines virtuellen Knotens 30x. Im Allgemeinen simuliert und/oder virtualisiert ein virtueller Knoten 30x einen physischen Knoten oder eine physische Komponente, die in der physischen Anlagenumgebung 15 verwendet und betrieben werden können. Jeder VN 52a, 52b enthält eine jeweilige Pub-/Sub-Schicht 55a, 55b, über die der VN 52a, 52b mit dem I/O-Switch 25 kommuniziert. Zusätzlich enthält jeder VN 52a, 52b ein entsprechendes Komponentenverhaltensmodul 58a, 58b, das hier gleichbedeutend als „Komponenten-Geschäftslogikmodul“ 58a, 58b oder „CBM“ 58a, 58b bezeichnet wird. Allgemein gesprochen ist ein CBM 58x ein Modul, dessen Ausführung das Betriebsverhalten seines jeweiligen virtuellen Knotens 30x, z. B. auf Anwendungsebene, regelt. Beispielsweise kann das CBM 58x eines virtuellen Steuerungsknotens eine bestimmte Instanz eines Steuermoduls sein, wobei andere Instanzen des Steuermoduls zur Ausführung während der Laufzeit der physischen Anlage 15 in physische Steuerungen heruntergeladen werden können, die in der physischen Anlagenumgebung 15 angeordnet sind. In einem anderen Beispiel kann das CBM 58x eines virtuellen CIOC-Knotens eine bestimmte Instanz eines entfernten I/O-Moduls sein, wobei andere Instanzen des entfernten I/O-Moduls während der Laufzeit der physischen Anlagenumgebung 15 bei darin angeordneten physischen CIOC ausgeführt werden können.
-
Da VBM 58x innerhalb physischer Komponenten ausgeführt werden kann, sind CBM in der Regel mit einem oder mehreren entsprechenden nativen I/O-Typen vertraut, wie beispielsweise analogem Eingang/Ausgang, Fieldbus, Railbus usw. Ferner haben CBM 58x typischerweise keine Kenntnis darüber, ob sie auf einem virtuellen Knoten 30x der virtuellen Anlagenumgebung 12, auf einem physischen Knoten 40x, der in der physischen Anlagenumgebung 15 angeordnet ist, oder auf einer anderen physischen Komponente, die in der physischen Anlagenumgebung 15 angeordnet ist, ausgeführt werden, z. B. Knoten PNa-PNk. Daher sendet und empfängt ein CBM 58x Daten auf dieselbe Weise und unter Verwendung derselben Verarbeitungslogik und desselben I/O-Typs, unabhängig davon, ob das CBM 58x in der virtuellen Anlagenumgebung 12 oder in der physischen Anlagenumgebung 15 ausgeführt wird.
-
In der Ausführungsform des virtuellen Knotens 52a werden prozessbezogene Nutzlastdaten, die vom CBM 58a gesendet und empfangen wurden, zur Übermittlung an/von dem VN 52a über ein virtuelles Prozess-I/O (PIO)-Subsystem 60 abstrahiert. Allgemein ausgedrückt simuliert das virtuelle PIO-Subsystem 60 die native physische PIO-Übermittlung für den virtuellen Knoten 52a. Das heißt, während der Laufzeit des virtuellen Knotens 52a kommuniziert das virtuelle PIO-Subsystem 60 I/O-Prozesswerte und -Ereignisse an das/vom CBM 58a unter Verwendung seiner nativen I/O, z. B. als ob die I/O-Prozesswerte und Ereignisse von physischer Hardware stammen/an diese übermittelt würden. Als solches kann das virtuelle PIO-Subsystem 60 auf den spezifischen Typ des virtuellen Knotens 52a zugeschnitten sein, wobei der Typ des virtuellen Knotens von seinem CBM 58a bestimmt wird. Wenn beispielsweise der VN 52a eine physische Steuerung repräsentiert, die mit anderen Geräten unter Verwendung von Railbus-I/O kommuniziert, stellt das virtuelle PIO-Subsystem 60 I/O-Daten an das/von dem Steuerroutine-CBM 58a in der von Railbus I/O-Karten verwendeten Form bereit. Wenn der VN 52a einen CIOC repräsentiert, dann stellt das virtuelle PIO-Subsystem 60 I/O-Daten an das/von dem entfernten I/O-CBM 58a in der Form, die von CHARM verwendet wird, bereit.
-
Ferner kann das virtuelle PIO-Subsystem 60 die Veröffentlichung und das Abonnieren von Daten für den virtuellen Knoten 52a übernehmen. Das heißt, das virtuelle PIO-Subsystem 60 kann Daten, die vom CBM 58a generiert wurden, in der Pub-/Sub-Schicht 55a veröffentlichen und das virtuelle PIO-Subsystem 60 kann Daten abonnieren, die von anderen Knoten generiert (und vom I/O-Switch 25) über die Pub/Sub-Schicht 55a weitergeleitet wurden. In einer Ausführungsform können Abonnements und Veröffentlichungen von Daten auf einem Tag oder einer anderen Kennung basieren, die innerhalb der MPDSC-Plattform 10 eindeutig ist. Das Tag oder die andere Kennung kann beispielsweise Daten, einen Knoten, ein Gerät oder eine Komponente der MPDSC-Plattform 10 eindeutig identifizieren. In einer Ausführungsform können die Tags und/oder Kennungen während der Konfiguration und/oder Inbetriebnahme zugewiesen werden.
-
Damit erhält das virtuelle PIO-Subsystem 60 an jedem virtuellen Knoten 52a innerhalb der virtuellen Umgebung 12 eine logische Trennung zwischen dem CBM 58a und der entsprechenden physischen I/O aufrecht (z. B. über die Pub-/Sub-Schicht 55a, das virtuelle Kommunikationsnetzwerk 45 und andere Pub-/Sub-Schichten 32, 35, 38, 42), ähnlich der logischen Trennung, die in der physischen Umgebung 15 an jedem physischen Knoten mit einem integrierten CBM 58a und seiner entsprechenden physischen I/O (z. B. über eine physische I/O-Karte oder I/O-Rangieranordnung) aufrechterhalten wird. Allgemein ausgedrückt erhält das virtuelle PIO-Subsystem 60 eines beliebigen virtuellen Knotens 30 eine logische Trennung zwischen einem beliebigen I/O-Abonnenten (dem CBM 58a, einem anderen Modul, einem anderen Typ von I/O-Verbraucher usw.), der in dem virtuellen Knoten 30 vorhanden ist, und seiner entsprechenden physischen I/O aufrecht.
-
In der Ausführungsform des virtuellen Knotens 52b, der in 2 dargestellt ist, ist das virtuelle PIO-Subsystem 60 weggelassen oder wird nicht verwendet. In der Regel sind die Typen von virtuellen Knoten, die die VN-Architektur 52b verwenden, diejenigen Knoten, deren CBM 58b nativ mit den physischen Komponenten und Technologien kommunizieren können, über die das virtuelle Kommunikationsnetzwerk 45 implementiert ist. Wenn beispielsweise das virtuelle Kommunikationsnetzwerk 45 über ein IP-Protokoll über Ethernet implementiert ist, dann enthält ein virtueller Knoten 52b, der ein EIOC simuliert, ein CBM 58b, das nativ dazu konfiguriert ist, unter Verwendung des IP-Protokolls über Ethernet zu kommunizieren. Folglich kann der virtuelle EIOC-Knoten 52b das virtuelle PIO-Subsystem 60 ausschließen (oder dessen Betrieb ausschalten oder ignorieren) und der virtuelle EIOC-Knoten 52b kann die Übermittlung von Daten zum/vom virtuellen Knoten 52b unter Verwendung ausschließlich des CBM 58b und der Pub-/Sub-Schicht 55b handhaben.
-
Physische Knoten
-
3 ist ein Blockdiagramm einer beispielhaften physischen Anlagenumgebung 100, die in Verbindung mit der MPDSC-Plattform 10 von 1 betrieben werden kann. Beispielsweise kann der in 1 dargestellte Teil 15 der physischen Umgebung der MPDSC-Plattform 10 mindestens Teile der physischen Anlagenumgebung 100 enthalten.
-
Die physische Anlage 100 steuert einen industriellen Prozess (oder arbeitet in einigen Ausführungsformen in Verbindung mit einer virtuellen Anlagenumgebung, wie der virtuellen Anlagenumgebung 12, um den industriellen Prozess zu steuern), wobei der industrielle Prozess einen oder mehrere „Prozessausgänge“ aufweisen kann, die den Zustand des Prozesses charakterisieren (z. B. Tankfüllstände, Durchflussraten, Materialtemperaturen usw.) und einen oder mehrere „Prozesseingänge“ (z. B. den Zustand verschiedener Umgebungsbedingungen und Stellantriebe, deren Manipulation dazu führen kann, dass sich die Prozessausgänge ändern). Die physische Prozessanlage 100 von 3 beinhaltet eine Feldumgebung 102 und eine Back-End-Umgebung 105, von denen jede über ein Prozesssteuerungs-Backbone oder eine Datenautobahn 108, die eine oder mehrere leitungsgebundene und/oder drahtlose Kommunikationsverbindungen und/oder -netzwerke enthalten können, kommunikativ mit der anderen verbunden ist, und unter Verwendung eines beliebigen gewünschten oder geeigneten Kommunikationsprotokolls, wie beispielsweise eines Ethernet-Protokolls, eines IP-Protokolls oder eines anderen Paketprotokolls, implementiert werden kann.
-
Stark verallgemeinert (und wie in 3 dargestellt) beinhaltet die Feldumgebung 102 physische Komponenten (z. B. Prozesssteuerungsgeräte, Netzwerke, Netzwerkelemente usw.), die zur Steuerung des industriellen Prozesses während der Laufzeit installiert und miteinander verbunden sind. Im Großen und Ganzen befinden sich diese physischen Komponenten in der Feldumgebung 102 der physischen Prozessanlage 100, sind darin angeordnet oder anderweitig in ihr enthalten, in der Rohmaterial unter Verwendung der darin angeordneten physischen Komponenten aufgenommen und verarbeitet werden, um dadurch ein oder mehrere physische Produkte zu generieren (z. B. Papier, raffiniertes Öl, Arzneimittel usw.). Dagegen enthält die Back-End-Umgebung 105 der physischen Prozessanlage 100 verschiedene physische Komponenten, wie z. B. Rechenvorrichtungen, Bediener-Workstations, Datenbanken oder Datensammlungen usw., die von den rauen Bedingungen und Materialien der Feldumgebung 102 abgeschirmt und/oder vor diesen geschützt werden. In einigen Konfigurationen können sich verschiedene in der Back-End-Umgebung 105 der physischen Prozessanlage 100 enthaltene Rechenvorrichtungen, Datenbanken und andere Komponenten und Ausrüstungen physisch an verschiedenen Standorten befinden, von denen sich einige vor Ort in der physischen Anlage 100 und andere entfernt befinden können.
-
Wie in
3 dargestellt, umfasst die Feldumgebung
102 eine oder mehrere Prozesssteuerungen
110, die kommunikativ mit der Datenautobahn
108 verbunden sind. Jede der Prozesssteuerungen
110 kann mit einem oder mehreren Zwischenknoten
112,
115 (z. B. I/O-Karten, I/O-Geräten, I/O-Systemen usw.) verbunden sein, um die Kommunikation zwischen den Steuerungen
110 und den Feldgeräten zu ermöglichen. Im Allgemeinen wird in der Prozesssteuerungsindustrie der Begriff „I/O“ manchmal in einer Reihe verwandter, aber unterschiedlicher Kontexte verwendet. Der Begriff bezieht sich im Allgemeinen auf eine logische Verbindung oder einen Kommunikationskanal, der ein Feldgerät kommunikativ mit einer I/O-Karte oder einer Steuerung (z. B. „I/O-Kanal“) koppelt, kann jedoch verwendet werden, wenn auf eine Reihe anderer Konzepte Bezug genommen wird, wie z. B. die physischen Geräte, die zum Senden oder Empfangen von Signalen an/von Feldgeräte/n über I/O-Kanäle (z. B. „I/O-Geräte“ oder „I/O-Karten“) und Steckverbinder/n oder Anschlüsse/n verwendet werden, die den I/O-Geräten zugeordnet sind (z. B. „I/O-Steckverbinder“). I/O-Geräte und I/O-Karten
112,
115 können eigenständige einzelne physische Geräte sein, von denen jedes mit einer jeweiligen Steuerung und mit einem oder mehreren jeweiligen Feldgeräten verbunden ist, wie in
3 dargestellt. In einigen Anordnungen (nicht in
3 dargestellt) sind I/O-Geräte, Karten, Steckverbinder und andere I/O-bezogene Komponenten, wie Klemmenblöcke, Module, Prozessoren usw., in einem elektronischen I/O-Rangiersystem enthalten, das eine flexible I/O-Übermittlung zwischen mehreren Steuerungen und mehreren Feldgeräten verschiedenen Typs ermöglicht, wie in den
US-Patenten Nr. 7,684,875 ;
8,332,567 ;
8,762,618 ;
8,977,851 ;
9,083,548 ;
9,411,769 ;
9,495,313 ; und
9,946,240 beschrieben, deren gesamter Inhalt hiermit zu einem Bestandteil dieser Schrift werden. Aus Gründen der Klarheit der Erörterung und bezieht sich der Begriff „I/O-Geräte“ hier im Allgemeinen auf physische I/O-Geräte, I/O-Karten, elektronische I/O-Rangiersysteme und Komponenten davon, über die I/O-Kanäle implementiert sind, um dadurch Feldgeräte und Steuerungen kommunikativ zu koppeln.
-
In der Prozesssteuerungsindustrie kann der Begriff „I/O“ außerdem im Allgemeinen dazu verwendet werden, sich auf die auf dem I/O-Kanal übertragenen Signale (z. B. „I/O-Signale“), Variablen oder Befehle zu beziehen, die durch die Signale dargestellt werden (z. B. „I/O-Parameter“) oder auf die Werte der Variablen oder Befehle, die von den Signalen übertragen werden (z. B. „I/O-Parameterwerte“ oder „I/O-Datennutzlast“). Dementsprechend werden zur Klarheit der Erörterung hier I/O-Signale, I/O-Parameter und I/O-Parameterwerte zusammenfassend und allgemein als „I/O-Daten“ oder „Prozess-I/O-Daten“ bezeichnet.
-
Soweit der Begriff „I/O“ hier ohne Attribut verwendet wird, sollte aus dem Kontext des Satzes deutlich hervorgehen, welches dieser Konzepte erörtert wird. Ferner sollte davon ausgegangen werden, dass ein „I/O-Kanal“ einen bestimmten Typ von „Kommunikationskanal“ oder „Kanal“ darstellt. Das heißt, sofern der Kontext des Satzes nichts anderes nahelegt, können Verweise in dieser Beschreibung auf den Begriff „Kanal“ oder den Begriff „Kommunikationskanal“ ohne das Attribut „I/O“ auf eine Kommunikationsverbindung verweisen, die in einigen Implementierungen ein I/O-Kanal sein könnte, können sich aber in einigen Implementierungen auch auf eine andere Kommunikationsverbindung als einen I/O-Kanal beziehen.
-
In jedem Fall und wieder auf 3 verweisend, implementiert jede Prozesssteuerung 110 der physischen Prozessanlage 100 eine Steuerstrategie, die durch eine oder mehrere Steuerroutinen (z. B. ein oder mehrere Komponentenverhaltensmodule) definiert ist, die in einem Speicher der Steuerung 110 gespeichert sein können. Wenn ein Prozessor der Steuerung eine oder mehrere der Steuerroutinen ausführt, sendet die Steuerung ein Steuersignal (d. h. einen „Steuerausgang“) über leitungsgebundene oder drahtlose Prozesssteuerungs-Kommunikationsverbindungen oder - netzwerke an andere Feldgeräte zur Steuerung des Betriebs eines Prozesses in der Anlage 100. Die Steuerung kann ein Steuersignal generieren, das basiert auf: (i) einem oder mehreren empfangenen Signalen, die als „Steuereingänge“ bezeichnet werden können (z. B. ein oder mehrere empfangene Signale, die Messungen darstellen, die von Feldgeräten erhalten wurden), und (ii) der Logik der einen oder mehreren Steuerungsroutinen, die durch ein oder mehrere Softwareelemente (z. B. Funktionsblöcke) definiert werden können. Typischerweise manipuliert eine Steuerung einen Prozesseingang (der als „Stellgröße“ bezeichnet werden kann), um einen bestimmten Prozessausgang (der als „Regelgröße“ bezeichnet werden kann) basierend auf einer Rückmeldung (d. h. einer Messung der Regelgröße) und einem gewünschten Wert für den Prozessausgang (d. h. einen Sollwert) zu ändern.
-
Im Allgemeinen führt mindestens ein Feldgerät eine physische Funktion aus (z. B. Öffnen oder Schließen eines Ventils, Erhöhen oder Verringern einer Temperatur, Durchführung einer Messung, Erfassen einer Bedingung usw.), um den Betrieb eines in der physischen Prozessanlage 100 implementierten Prozesses zu steuern. Einige Arten von Feldgeräten kommunizieren mit Steuerungen über I/O-Geräte. Prozesssteuerungen, Feldgeräte und I/O-Geräte können leitungsgebunden oder drahtlos sein, und jede beliebige Anzahl und Kombination von leitungsgebundenen und drahtlosen Prozesssteuerungen, Feldgeräten und/oder I/O-Geräten kann in der Prozessanlagenumgebung oder der Plattform 100 enthalten sein.
-
Die Front-End-Umgebung 102 der Anlage 100
-
Zum Beispiel veranschaulicht 3 eine Prozesssteuerung 110, die kommunikativ mit den leitungsgebundenen Feldgeräten 125-132 über Eingangs-/Ausgangs-(I/O)-Geräte 112 und 115 verbunden ist, und die mit den drahtlosen Feldgeräten 140-146 über ein drahtloses Gateway 168 und die Datenautobahn 108 verbunden ist. In einigen (nicht dargestellten) Konfigurationen kann die Steuerung 110 kommunikativ mit dem drahtlosen Gateway 168 unter Verwendung von einem oder mehreren Kommunikationsnetzwerken außer dem Backbone 108 verbunden sein, wie z. B. durch Verwenden einer beliebigen Anzahl anderer leitungsgebundener oder drahtloser Kommunikationsverbindungen, die ein oder mehrere Kommunikationsprotokolle unterstützen, z. B. Wi-Fi oder ein anderes IEEE 802.11-konformes WLAN-Protokoll, Mobilkommunikationsprotokoll (z. B. WiMAX, LTE oder ein anderes ITU-R-kompatibles Protokoll), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus usw.
-
Die Steuerung 110, die beispielsweise die von Emerson Process Management vertriebene DeltaV™-Steuerung sein kann, kann dazu betrieben werden, einen industriellen Batch-Prozess oder einen kontinuierlichen industriellen Prozess unter Verwendung von mindestens einigen der Feldgeräte 125-132 und 140-146 umzusetzen. In einer Ausführungsform ist die Steuerung 110 nicht nur kommunikativ mit der Prozesssteuerungs-Datenautobahn 108 verbunden, sondern auch mit mindestens einigen der Feldgeräte 125-132 und 140-146, wobei jede gewünschte Hard- und Software verwendet wird, die z. B. mit 4-20-mA-Standardgeräten, den I/O-Geräten 112, 115 und/oder jedem geeigneten intelligenten Kommunikationsprotokoll, wie z. B. dem FOUNDATION® Fieldbus-Protokoll, dem HART®-Protokoll, dem WirelessHART®-Protokoll usw. verbunden ist. In 3 sind die Steuerung 110, die Feldgeräte 125-132 und die I/O-Geräte 112, 115 leitungsgebundene Geräte, während die Feldgeräte 140-146 drahtlose Feldgeräte sind. Natürlich könnten die leitungsgebundenen Feldgeräte 125-132 und die drahtlosen Feldgeräte 140-146 mit jedem (allen) anderen gewünschten Standard(s) oder Protokollen, wie z. B. allen leitungsgebundenen oder drahtlosen Protokollen, einschließlich allen künftig entwickelten Standards oder Protokollen, konform sind.
-
Der Prozesssteuerung 110 von 3 enthält einen Prozessor 120, der eine oder mehrere Prozesssteuerungsroutinen 118 implementiert oder überwacht (z. B. die in einem Speicher 122 der Steuerung 110 gespeichert sind). Der Prozessor 120 ist dazu konfiguriert, mit den Feldgeräten 125-132 und 140-146 und mit anderen mit der Steuerung 110 kommunikativ verbundenen Knoten zu kommunizieren. Zu beachten ist, dass beliebige der hier beschriebenen Steuerungsroutinen oder Module von verschiedenen Steuerungen oder anderen Geräten umgesetzt oder ausgeführt werden können, sofern dies gewünscht ist. Ebenso können die hier beschriebenen Steuerroutinen oder -module 118, die innerhalb der Prozesssteuerungsanlage 100 zu implementieren sind, jede Form annehmen, einschließlich Software, Firmware, Hardware usw. Steuerroutinen können in jedem beliebigen Softwareformat implementiert werden, wie z. B. durch Verwendung von objektorientierter Programmierung, Kontaktplänen, sequenziellen Funktionsplänen, Funktionsblockschaltbildern oder durch Verwendung anderer Softwareprogrammiersprachen oder Design-Paradigmas. Die Steuerroutinen 118 können in jedem gewünschten Speichertyp 122, wie z. B. Arbeitsspeicher (RAM) oder Festwertspeicher (ROM) gespeichert sein. Ebenso können die Steuerroutinen 118 zum Beispiel in einem oder mehreren EPROMs, EEPROMs, anwendungsspezifischen integrierten Schaltungen (ASIC) oder anderen Hardware- oder Firmware-Elementen hartkodiert sein. Somit kann die Steuerung 110 dazu konfiguriert sein, eine Steuerstrategie oder Steuerroutine in jeder gewünschten Weise zu implementieren.
-
Die Steuerung 110 implementiert eine Steuerungsstrategie unter Verwendung von so genannten Funktionsblöcken, wobei jeder Funktionsblock ein Objekt oder ein anderer Teil (z. B. eine Subroutine) einer Gesamtsteuerroutine ist und in Verbindung mit anderen Funktionsblöcken (über als Links bezeichneten Kommunikationen) arbeitet, um Prozessregelkreise innerhalb der MPDSC-Plattform 10 zu implementieren. Steuerungsbasierte Funktionsblöcke führen typischerweise eines von (i) einer Eingangsfunktion, wie z. B. der mit einem Geber, einem Sensor oder einem anderen Prozessparameter-Messgerät verknüpften (manchmal als „Eingangsblöcke“ bezeichnet); (ii) einer Steuerungsfunktion, wie z. B. der mit einer Steuerroutine verknüpften, die eine PID-, Fuzzy-Logik- usw. -Steuerung (manchmal als „Steuerblöcke“ bezeichnet) ausführt, oder (iii) einer Ausgabefunktion durch, die den Betrieb einiger Geräte, wie z. B. eines Ventils, steuert, um eine physische Funktion innerhalb der Prozesssteuerungsanlage 100 auszuführen. Natürlich gibt es auch hybride und andere Arten von Funktionsblöcken.
-
Funktionsblöcke können von der Steuerung 110 gespeichert und ausgeführt werden, was typischerweise der Fall ist, wenn diese Funktionsblöcke für Standard-Geräte von 4-20 mA und einige Typen von intelligenten Feldgeräten, wie z. B. HART®-Geräten, verwendet werden oder damit verknüpft werden, oder sie können in den Feldgeräten selbst gespeichert und implementiert sein, was bei FOUNDATION® Fieldbus-Geräten der Fall sein kann. Eine oder mehrere der Steuerroutinen 118 können einen oder mehrere Regelkreise implementieren, die durch Ausführen eines oder mehrerer Funktionsblöcke durchgeführt werden. In gewissem Sinne können die Steuerroutinen 118 als die Komponentenverhaltensmodule der Steuerung 110 angesehen werden.
-
Die leitungsgebundenen Feldgeräte 125-132 können beliebige Typen von Geräten sein, wie z. B. Sensoren, Ventile, Messumformer, Stellungsregler usw., während die I/O-Geräte 112 und 115 beliebige Typen von Prozesssteuerungs-I/O-Geräten sein können, die mit einem beliebigen gewünschten Kommunikations- oder Steuerungsprotokoll konform sind. Beispielsweise können die I/O-Geräte 112, 115 in einem elektronischen I/O-Rangiersystem enthalten sein. In 3 sind die Feldgeräte 125-128 Standard-Geräte von 4-20 mA oder HART®-Geräte, die über analoge Leitungen oder kombinierte analoge und digitale Leitungen mit dem I/O-Gerät 112 kommunizieren, während die Feldgeräte 129-132 intelligente Geräte wie FOUNDATION® Fieldbus-Feldgeräte sind, die über einen digitalen Bus mit dem I/O-Gerät 115 mittels eines FOUNDATION® Feldbus-Kommunikationsprotokolls kommunizieren. In einigen Ausführungsformen können jedoch zumindest einige der leitungsgebundenen Feldgeräte 125, 126, 128-131 und/oder zumindest einige der I/O-Geräte 112, 115 zusätzlich oder alternativ mit der Steuerung 110 über die Prozesssteuerungs-Datenautobahn 108 und/oder über andere geeignete Steuerungssystemprotokolle (z. B. Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART usw.) kommunizieren. In einigen Anordnungen (in 3 nicht dargestellt) können zumindest einige der Feldgeräte 125-132 mit der Steuerung 110 über ein elektronisches I/O-Rangiersystem statt über ein einzelnes I/O-Gerät 112, 115 kommunizieren.
-
In 3 kommunizieren die drahtlosen Feldgeräte 140-146 über ein drahtloses Prozesssteuerungs-Kommunikationsnetz 165 mit einem drahtlosen Protokoll, wie dem WirelessHART®-Protokoll. Solche drahtlosen Feldgeräte 140-146 können direkt mit einem oder mehreren anderen Geräte oder Knoten des drahtlosen Netzwerks 165 kommunizieren, die ebenfalls für drahtlose Kommunikation (zum Beispiel unter Verwendung des drahtlosen Protokolls oder eines anderen drahtlosen Protokolls) konfiguriert sind. Zur Kommunikation mit einem oder mehreren anderen Knoten, die nicht für die drahtlose Kommunikation konfiguriert sind, können sich die drahtlosen Feldgeräte 140-146 eines drahtlosen Gateways 168 bedienen, das mit der Prozesssteuerungs-Datenautobahn 108 oder einem anderen Prozesssteuerungs-Kommunikationsnetzwerk verbunden ist. Das drahtlose Gateway 168 ermöglicht den Zugriff auf verschiedene drahtlose Geräte 140-158 des drahtlosen Kommunikationsnetzwerks 165. Insbesondere stellt das drahtlose Gateway 168 eine kommunikative Kopplung zwischen den drahtlosen Geräten 140-158, den leitungsgebundenen Geräten 125-132 und/oder anderen Knoten oder Geräten der physischen Prozesssteuerungsanlage 100 bereit. Das drahtlose Gateway 168 kann z. B. eine kommunikative Kopplung über die Prozesssteuerungs-Datenautobahn 108 und/oder über ein oder mehrere andere Kommunikationsnetzwerke der physischen Prozessanlage 100 bereitstellen.
-
Analog zu den leitungsgebundenen Feldgeräten 125-132 übernehmen die drahtlosen Feldgeräte 140-146 des drahtlosen Netzwerks 165 physische Steuerungsfunktionen innerhalb der physischen Prozessanlage 100, z. B. Öffnen oder Schließen von Ventilen oder die Vornahme von Messungen von Prozessparametern. Die drahtlosen Feldgeräte 140-146 sind jedoch für die Kommunikation unter Verwendung des drahtlosen Protokolls des Netzwerks 165 konfiguriert. Damit sind die drahtlosen Feldgeräte 140-146, das drahtlose Gateway 168 und die anderen drahtlosen Knoten 152-158 des drahtlosen Netzwerks 165 Erzeuger und Verbraucher drahtloser Kommunikationspakete.
-
In einigen Konfigurationen der physischen Prozessanlage 100 beinhaltet das drahtlose Netzwerk 165 auch nichtdrahtlose Geräte. Zum Beispiel ist in 3 ein Feldgerät 148 von 3 ein älteres Gerät von 4-20 mA und ein Feldgerät 150 ist ein leitungsgebundenes HART®-Gerät. Zur Kommunikation innerhalb des Netzwerks 165 sind die Feldgeräte 148 und 150 über einen drahtlosen Adapter 152a, 152b mit dem drahtlosen Kommunikationsnetzwerk 165 verbunden. Die drahtlosen Adapter 152a, 152b unterstützen ein drahtloses Protokoll, wie z. B. WirelessHART, und können auch ein oder mehrere andere Kommunikationsprotokolle wie Foundation® Fieldbus, PROFIBUS, DeviceNet, usw. unterstützen. Darüber hinaus enthält das drahtlose Netzwerk 165 in einigen Konfigurationen einen oder mehrere Netzwerkzugangspunkte 155a, 155b, die separate physische Geräten in leitungsgebundener Kommunikation mit dem drahtlosen Gateway 168 sein können oder die in das drahtlose Gateway 168 integriert sein können. Das drahtlose Netzwerk 165 kann auch einen oder mehrere Router 58 enthalten, um Pakete von einem drahtlosen Gerät zu einem anderen drahtlosen Gerät innerhalb des drahtlosen Kommunikationsnetzwerks 165 weiterzuleiten. In 3 kommunizieren die drahtlosen Geräte 140-146 und 152-158 miteinander und mit dem drahtlosen Gateway 168 über drahtlose Verbindungen 160 des drahtlosen Kommunikationsnetzwerks 165 und/oder über die Prozesssteuerungs-Datenautobahn 108.
-
Die Back-End-Umgebung 105 der Anlage 100
-
Die Back-End-Umgebung 105 beinhaltet, wie angemerkt, verschiedene Komponenten, wie z. B. Rechenvorrichtungen, Bediener-Workstations, Datenbanken oder Datensammlungen usw., die in der Regel von den rauen Bedingungen und Materialien der Feldumgebung 102 abgeschirmt und/oder vor diesen geschützt werden. Beispielsweise kann die Back-End-Umgebung 105 eines oder mehrere der folgenden Elemente enthalten, von denen jedes kommunikativ mit der Datenautobahn 108 verbunden sein kann: (i) eine oder mehrere Bediener-Workstations 170a und andere lokale oder entfernte Benutzeroberflächengeräte 170b; (ii) eine oder mehrere Konfigurationsanwendungen 172a und Konfigurationsdatenbanken 172b; (iii) eine oder mehrere andere Typen von Anwendungen 175a und/oder Datenbanken 175b, wie beispielsweise Werkzeuge, Diagnose-, Bestandsverwaltungssysteme, Simulatoren und/oder andere Typen von Anwendungen einschließen können; (iv) einen oder mehrere andere drahtlose
Zugangspunkte 178, die mit anderen mit der Anlage 100 verbundenen Geräten (z. B. Benutzeroberflächengeräten 170b oder anderen Geräten) unter Verwendung verschiedener drahtloser Protokolle kommunizieren; (v) ein oder mehrere Anlagen-Gateway-Systeme 180 zu anderen Anlagen; (vi) ein oder mehrere Edge-Gateway-Systeme 182 zu Systemen 185, die außerhalb der unmittelbaren OT-Schichten der physischen Prozesssteuerungsplattform 100 liegen (z. B. IT-Netzwerke/-Systeme des Unternehmens und/oder externe Datennetze/-systeme, die auf Cloud Computing und/oder anderen geeigneten Plattformen implementiert werden können); und/oder (vii) andere physische Komponenten, die speziell über Hardware und Software dazu konfiguriert sind, die Prozessanlage 100 zu unterstützen.
-
Bediener-Workstations und Benutzeroberflächengeräte 170a, 170b
-
Die Bediener-Workstations 170a und anderen Benutzeroberflächengeräte 172b können von Bedienern verwendet werden, um den Laufzeitbetrieb der physischen Prozessanlage 100 anzuzeigen und zu überwachen sowie um eventuell erforderliche Diagnose-, Korrektur-, Wartungs- und/oder andere Maßnahmen zu ergreifen. Zumindest einige der Bediener-Workstations 172a können sich in verschiedenen, geschützten Bereichen in oder nahe der Anlage 100 befinden und in manchen Situationen können zumindest einige der Bediener-Workstations 172b entfernt angeordnet sein, jedoch dennoch in kommunikativer Verbindung mit der Anlage 10 stehen. Die Bediener-Workstations 172a, 172b können leitungsgebundene oder drahtlose Rechenvorrichtungen sein.
-
Konfigurationsanwendungen 172a und Konfigurationsdatenbanken 172b
-
Die Konfigurationsanwendungen 172a und die Konfigurationsdatenbanken 172b können verwendet werden, um bestimmte Aspekte der Anlage 100 zu konfigurieren, wie beispielsweise Steuermodule/-routinen, Benutzeroberflächen, Datenüberwachung/-analyse usw. Beispielsweise können verschiedene Instanzen der Konfigurationsanwendung 172a auf einer oder mehreren Rechenvorrichtungen (nicht dargestellt) ausgeführt werden, um Benutzern das Erstellen oder Ändern von Prozesssteuermodulen und das Herunterladen dieser Module über die Datenautobahn 108 zu den Steuerungen 110 zu ermöglichen, um Benutzeroberflächen zu erstellen oder zu ändern, über die der Bediener Daten anzeigen und Dateneinstellungen innerhalb von Prozesssteuerungsroutinen ändern kann, um Datenüberwachungs-/-analyseroutinen und - funktionen zu erstellen oder zu ändern, die in verschiedene physische Komponenten innerhalb der Feldumgebung 102 usw. heruntergeladen werden können. Die Konfigurationsdatenbanken 172b speichern die erstellten (z. B. konfigurierten) Module, Benutzeroberflächen, Datenüberwachung/-analyse usw. Im Allgemeinen sind die Konfigurationsanwendungen 172a und Konfigurationsdatenbanken 172b zentralisiert und haben gegenüber der physischen Prozesssteuerungsplattform 100 ein als Einheit dargestelltes, logisches Erscheinungsbild, obwohl mehrere Instanzen der Konfigurationsanwendungen 172a gleichzeitig innerhalb der physischen Prozesssteuerungsplattform 100 ausgeführt werden können und die Konfigurationsdatenbanken 172b über mehrere physische Datenspeichergeräte implementiert werden können. Dementsprechend umfassen die Konfigurationsanwendungen 172a, die Konfigurationsdatenbanken 172b und die Benutzeroberflächen dazu (nicht dargestellt) ein Konfigurations- oder Entwicklungssystem 172 für verschiedene Typen von Modulen, z. B. Steuermodule, Anzeige- oder Benutzeroberflächenmodule und/oder Analysemodule. Typischerweise, aber nicht notwendigerweise, unterscheiden sich die Benutzeroberflächen für das Konfigurationssystem 172 von den Bediener-Workstations/Benutzeroberflächengeräten 170, wobei die Benutzeroberflächen für das Konfigurationssystem 172 von Konfigurations- und Entwicklungsingenieuren verwendet werden, unabhängig davon, ob die Anlage 100 im Produktionsmodus arbeitet oder nicht, während die Bediener-Workstations/Benutzeroberflächengeräte 170 von den Bedienern während des Laufzeitbetriebs der physischen Prozessanlage 100 verwendet werden.
-
In Bezug auf die Inbetriebnahme der physischen Komponenten der MPDSC-Plattform 100 kann die Konfigurationsdatenbank 172b Daten und andere Informationen speichern, durch die spezifisch die verschiedenen physischen Geräte oder Komponenten und deren Verbindungen untereinander identifiziert und/oder adressiert werden, die für den Prozessanlagenbereich oder die Feldumgebung 102 geplant sind oder deren Implementierung dort erwünscht ist. Einige dieser Inbetriebnahmedaten können Komponenten in der Feldumgebung 102 zur Verwendung bei der Inbetriebnahme von darin befindlichen Geräten und Schleifen bereitgestellt werden, und einige dieser Daten können in der Back-End-Umgebung 105 z. B. für das Design, die Entwicklung und Vorbereitung von Steuermodulen, Benutzeroberflächenmodulen und/oder Datenanalysemodulen verwendet werden, die in Verbindung mit der Feldumgebung 102 während des Live-Betriebs der physischen Prozessanlage 100 in Betrieb sind. In einem Beispiel wird ein genehmigtes Steuermodul von der Konfigurationsdatenbank 172b in eine Prozesssteuerung 110 heruntergeladen, so dass die Prozesssteuerung 110, wenn sie während des Live-Betriebs ausgeführt wird, gemäß ihrem residenten Steuermodul arbeitet und verschiedene Signale zu/von anderen Komponenten in ihrer Schleife (und in einigen Fällen zu/von anderen Prozesssteuerungen) sendet und empfängt und mittels dieser mindestens einen Teil des Prozesses in der physischen Prozessanlage 100 steuert.
-
Die Konfigurationsdatenbank 172b kann eine Anzahl von logischen Kennungen von Komponenten in der Feldumgebung 102 speichern, wodurch die Steuerung 110 und andere Geräten die den Komponenten zugeordneten Komponenten und Signale über die logischen Kennungen referenzieren können. Beispielsweise kann die Konfigurationsdatenbank 172b für ein gegebenes Feldgerät eine Informationszuordnung speichern oder eine logische Kennung an eine bestimmte Hardwareadresse oder einen bestimmten I/O-Kanal binden. Die Hardwareadresse kann eine bestimmte Steuerung, ein bestimmtes I/O-Gerät, das mit der bestimmten Steuerung verbunden ist, oder eine bestimmte Adresse für den I/O-Kanal identifizieren, der das bestimmte I/O-Gerät mit dem Feldgerät verbindet. In einigen Fällen kann diese Zuordnung oder Bindung in der Steuerung 110, dem Benutzeroberflächengerät 170b, der Bediener-Workstation 170a oder einem anderen gewünschten Gerät (z. B. einem Gerät, das die logische Kennung auflösen muss) gespeichert werden. Nachdem eine logische Kennung an eine Hardwareadresse oder einen I/O-Kanal gebunden wurde, wird die Kennung als „zugewiesen“ betrachtet. In einigen Fällen enthält die Anlage 100 „nicht zugewiesene“ logische Kennungen, wobei es sich um Kennungen handelt, auf die ein Softwareelement (z. B. eine Steuerroutine und/oder ein Funktionsblock) referenziert, die jedoch keine Bindung aufweisen. Das heißt, eine logische Kennung wird als „nicht zugewiesen“ betrachtet, wenn die Anlage 100 und die Konfigurationsdatenbank 172b keine Hardwareadresse oder keinen I/O-Kanal aufweisen, der an das Tag gebunden ist. Wenn also eine nicht zugewiesene logische Kennung von einer Steuerroutine referenziert wird, wird kein Wert gelesen, der von einem Signal in der Anlage 100 übertragen wird, und es wird kein Befehl über ein Signal an ein Feldgerät in der Anlage 100 übertragen.
-
Beispiele für solche logischen Kennungen schließen Geräte-Tags (DT) ein, von denen jedes ein bestimmtes Instrument, eine bestimmte Steuerung, ein bestimmtes Ventil oder ein anderes physisches Feldgerät repräsentiert, und Geräte-Signal-Tags (DST), von denen jedes ein bestimmtes Signal repräsentiert, das von einem bestimmten Gerät empfangen oder generiert wird und das typischerweise einem bestimmten Parameter entspricht, der von dem Feldgerät verwendet wird. Bei einigen Geräten umfasst ein Geräte-Signal-Tag eine Kombination aus dem Geräte-Tag eines Geräts und einer Kennung eines bestimmten Signals, das von diesem Gerät empfangen oder generiert wird, z. B. einer Kennung eines bestimmten Parameters, auf den ein Steuermodul referenziert ist. Bei einigen Geräten, normalerweise älteren oder „nicht intelligenten“ Geräten, repräsentiert ein Geräte-Tag sowohl das physische Gerät als auch ein vom Gerät generiertes Signal. Allgemein ausgedrückt wird die logische Kennung eines Geräts von der physischen Prozessanlage 100 sowohl in der Feldumgebung 102 als auch in der Back-End-Umgebung 105 dazu verwendet, das Gerät eindeutig zu identifizieren. Die DT und DST können als „System-Tags“ oder „System-IDs“ bezeichnet werden.
-
In einigen Fällen können die intelligenten Feldgeräte 129-132 auch logische Kennungen speichern, die für die intelligenten Feldgeräte 129-132 eindeutig sind. Diese logischen Kennungen können sich von den System-Tags unterscheiden, die von der Anlage 100 zur Identifizierung der Feldgeräte 129-132 verwendet werden, und können als „Quell-IDs“ oder „Quell-Tags“ bezeichnet werden. Quell-Tags können in Abhängigkeit von der Implementierung in der Konfigurationsdatenbank 172b gespeichert werden oder nicht.
-
Die Konfigurationsdatenbank 172b kann Daten und andere Informationen speichern, durch die spezifisch verschiedene virtuelle Geräten oder Komponenten (z. B. verschiedene virtuelle Knoten 30) identifiziert und/oder adressiert werden, die für die virtuelle Anlagenumgebung 12 geplant sind oder in sie implementiert werden sollen. Ähnlich wie bei physischen Geräten und Komponenten kann die Konfigurationsdatenbank 172 entsprechende logische Kennungen von Komponenten der virtuellen Umgebung 12 speichern und es anderen Geräten und/oder Komponenten (ob physisch oder virtuell) so ermöglichen, auf die virtuellen Komponenten zu verweisen. Beispielsweise können ähnlich wie bei den physischen Knoten 40x verschiedene virtuelle Knoten 30x innerhalb der MPDSC-Plattform 10 (z. B. sowohl in der virtuellen 12 als auch in der physischen 15 Umgebung) über ihre jeweiligen Geräte-Tags (DT), Geräte-Signal-Tags (DST), Quell-Tags und/oder andere Typen von eindeutigen Kennungen eindeutig identifiziert werden. In weiteren Abschnitten dieser Offenbarung wird die Konfiguration und Identifizierung von virtuellen Geräten und Komponenten ausführlicher erörtert.
-
Andere Anwendungen 175a und Datenbanken 175b
-
Die anderen Anwendungen 175a und Datenbanken 175b können Instanzen von Anwendungen enthalten, die für die Prozessanlage 100 spezifisch sind, wie Diagnoseanwendungen/- Datenbanken, Data-Historian-Anwendungen/-Datenbanken, Anwendungen/Datenbanken zur Überwachung des Zustands auf Systemebene, lokale und/oder entfernte Benutzeroberflächen; usw. Allgemein ausgedrückt können die anderen Anwendungen 175a und Datenbanken 175b eine oder mehrere Anwendungen enthalten, die auf den OT-Schichten 18 der Prozessanlage 100 und ihren zugehörigen Datenbanken ausgeführt werden. Zusätzlich oder alternativ können die anderen Anwendungen 175a und Datenbanken 175b eine oder mehrere Anwendungen enthalten, die auf den IT-Schichten 20 ausgeführt werden, die der Prozessanlage 100 zugeordnet sind, wie z. B. Bestandsverwaltungsanwendungen, Personalverwaltungsanwendungen, Lieferkettenverwaltungsanwendungen, andere Typen von unternehmensbezogenen Anwendungen, Wetter-/Umweltanwendungen usw. und die zugehörigen Datenbanken. Beispielsweise können die anderen Anwendungen 175a und Datenbanken 175b die Anwendungen 21a bis 21n und ihre zugehörigen Datenbanken enthalten. Darüber hinaus können die anderen Anwendungen 175a und Datenbanken 175b zusätzlich oder alternativ eine oder mehrere Anwendungen enthalten, die sich außerhalb der Prozessanlage 100 und/oder ihres Unternehmens befinden und/oder entfernt von dieser ausgeführt werden, wie Simulationsanwendungen, Analyseanwendungen, IoT-Anwendungen, IIoT-Anwendungen usw. und die zugehörigen Datenbanken. Beispielsweise können die anderen Anwendungen 175a und Datenbanken 175b die Anwendungen 22a-21m und ihre zugehörigen Datenbanken enthalten. Die anderen Anwendungen 175a und Datenbanken 175b können Anwendungen von Drittanbietern und/oder Anwendungen enthalten, die von dem mit der Prozessanlage 100 verbundenen Unternehmen bereitgestellt werden. Auf mindestens einige der anderen Anwendungen 175a und Datenbanken 175b kann über ein Edge-Gateway-System 28 und/oder eine andere Art von Sicherheits- und/oder Firewall-System zugegriffen werden.
-
Drahtlose Zugangspunkte 178
-
Der eine oder die mehreren drahtlosen Zugangspunkte 178 ermöglichen es Geräten in der Back-End-Umgebung 105 (und manchmal in der Feldumgebung 102), mit anderen Geräten unter Verwendung von anderen drahtlosen Protokollen zu kommunizieren, wie z. B. Wi-Fi oder anderen IEEE 802.11-konformen drahtlosen lokalen Netzwerkprotokollen, mobilen Kommunikationsprotokollen, wie z. B. WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) oder anderen ITU-R (International Telecommunication Union Radiocommunication Sector)-kompatiblen Protokollen, kurzwelligen Funkkommunikationen, wie z. B. NFC und Bluetooth, oder anderen drahtlosen Kommunikationsprotokollen. Typischerweise ermöglichen solche drahtlosen Zugangspunkte 178 mobilen oder anderen tragbaren Rechenvorrichtungen (z. B. Benutzeroberflächengeräten 170b) über ein entsprechendes drahtloses Prozesssteuerungs-Kommunikationsnetzwerk, das sich vom drahtlosen Netzwerk 165 unterscheidet und das ein anderes drahtloses Protokoll als das drahtlose Netzwerk 165 unterstützt, zu kommunizieren. Zum Beispiel kann ein drahtloses oder tragbares Benutzeroberflächengerät 170b eine mobile Workstation oder ein Diagnosetestgerät sein, das von einem Bediener innerhalb der physischen Prozessanlage 100 verwendet wird (z. B. eine Instanz einer der Bediener-Workstations 170a). In einigen Szenarien kommunizieren neben tragbaren Rechenvorrichtungen auch ein oder mehrere Prozesssteuerungsgeräte (z. B. Steuerung 110, Feldgeräte 125-132 oder die drahtlosen Geräte 168, 140-158) unter Verwendung des von den Zugangspunkten 174 unterstützten drahtlosen Protokolls.
-
Gateway-Systeme 180, 182
-
Die Gateway-Knoten oder -Systeme 180 und 182 können an Systeme angeschaltet sein, die sich außerhalb der unmittelbaren physischen Prozesssteuerungsanlage 100 befinden. Typischerweise sind solche Systeme Kunden und/oder Lieferanten von Informationen, die von der physischen Prozessanlage 100 generiert werden oder auf denen sie Operationen ausführt. Zum Beispiel kann die Prozesssteuerungsanlage 100 einen Anlagen-Gateway-Knoten 180 enthalten, um die unmittelbare physische Prozessanlage 100 kommunikativ mit einer anderen Prozessanlage zu verbinden. Zusätzlich oder alternativ kann die Prozesssteuerungsanlage 100 einen Edge-Gateway-Knoten oder ein solches System 182 enthalten, um die unmittelbare physische Prozessanlage 100 mit einem externen öffentlichen oder privaten System kommunikativ zu verbinden, wie z. B. einem Laborsystem (z. B. Laborinformations-Verwaltungssystem oder LIMS), einer Operator-Rounds-Datenbank, einem Datenkonsolidierungs- und -Anzeigesystem, einem Datenanalysesystem, einem Materialflusssystem, einem Bestandsverwaltungssystem, einem Wartungsverwaltungssystem, einem Produktbestandssteuerungssystem, einem Produktionsplanungssystem, einem Wetterdatensystem, einem Versand- und Handhabungssystem, einem Verpackungssystem, dem Internet, einer IoT-Anwendung, einer IIoT-Anwendung oder anderen externen Systemen.
-
Im Allgemeinen ermöglicht das Edge-Gateway-System 182 die sichere Übermittlung von Kommunikationen zwischen der Prozessanlage 100 und anderen Netzwerken 185. In einer beispielhaften Architektur beinhaltet ein Edge-Gateway-System 182 eine nach innen oder zur Anlage gerichtete Engine (die als „Feld-Gateway“ bezeichnet werden kann) und eine extern oder nach außen gerichtete Engine (die als „Edge-Gateway“ bezeichnet werden kann), wobei die zur Anlage gerichtete Engine und die nach außen gerichtete Engine zusammenarbeiten, um Prozessanlagendaten (z. B. von den OT-Schichten generierte Daten) sicher an externe Netzwerke und/oder Anwendungen (z. B. IT-Schichten und/oder externe Netzwerke und/oder Systeme), die Verbraucher der Anlagendaten sind, zu übermitteln. In einer von vielen Ausführungsformen erfasst die zur Anlage gerichtete Engine Daten, die von verschiedenen Komponenten der Prozessanlage 100 generiert werden, und überträgt die erfassten Daten sicher über eine oder mehrere gesicherte Kommunikationsverbindungen zur nach außen gerichteten Engine, z. B. über einen ersten Satz von Veröffentlichungen. Die nach außen gerichtete Engine hat die verschiedenen Veröffentlichungen abonniert, die von der zur Anlage gerichteten Engine generiert wurden, und erhält die erfassten Anlagendaten von dieser. Die nach außen gerichtete Engine überträgt wiederum die erhaltenen Anlagendaten sicher an eine oder mehrere externe Client-Anwendungen (z. B. Anwendungen 21a-21n, 22a-22m) innerhalb der Netzwerke 185, z. B. über einen zweiten Satz von Veröffentlichungen. Veröffentlichungen und Abonnements der zur Anlage gerichteten Engine und/oder der nach außen gerichteten Engine können jeweils nach Wunsch konfiguriert werden. Typischerweise unterscheiden sich jedoch die Veröffentlichungs-/Abonnement-, Verschlüsselungs- und/oder anderen sicheren Datenübermittlungsmechanismen, die zwischen der zu Anlage gerichteten Engine und der nach außen gerichteten Engine verwendet werden, von dem Veröffentlichungs-/Abonnement-, Verschlüsselungs- und/oder anderen sicheren Datenübermittlungsmechanismus, der zwischen der nach außen gerichteten Engine und externen Anwendungen verwendet wird. In einigen Ausführungsformen beinhaltet das Edge-Gateway-System 182 zur zusätzlichen Sicherheit eine Einwegdatendiode, die zwischen der zur Anlage gerichteten Engine und der nach außen gerichteten Engine angeordnet ist, um zu verhindern, dass Daten aus externen Netzwerken 185 in die Prozessanlage 100 fließen. Beispiele für Edge-Gateway-Systeme finden sich in den US-Patentveröffentlichungen Nr. 20180115516; 20180115528; 20180115517; und 20180113442, deren gesamte Offenbarungen hiermit zu einem Bestandteil der vorliegenden Schrift wird. Natürlich können andere Edge-Gateway-Systeme zusätzlich oder alternativ von der Prozessanlage 100 verwendet werden.
Es wird darauf hingewiesen, dass, obwohl 3 nur eine Steuerung 110 mit einer endlichen Anzahl von Feldgeräten 125-132 und 140-146, drahtlosen Gateways 168, drahtlosen
Adaptern 152, Zugangspunkten 155, Routern 158, drahtlosen Prozesssteuerungs-Kommunikationsnetzwerken 165, die in der physischen Beispiel-Prozessanlage 100 enthalten sind, veranschaulicht, dies jedoch nur eine veranschaulichende und nicht-einschränkende Ausführungsform ist. Jede beliebige Anzahl von Steuerungen 110 kann in die Prozesssteuerungsanlage oder -Plattform 100 einbezogen werden und jede der Steuerungen 110 kann mit einer beliebigen Anzahl von leitungsgebundenen oder drahtlosen Geräten und Netzwerken 125-132, 140-146, 168, 152, 155, 158 und 165 kommunizieren, um einen Prozess in der Anlage 100 zu steuern.
Was die physischen Knoten in 1 und 3 betrifft kann jeder in 1 gezeigte physische Knoten 40a-40c und PNa-PNk eine(s) der jeweiligen physischen Komponenten oder Geräte sein, die in Bezug auf die Prozesssteuerungsanlage 100 von 3 erörtert wurden. Zum Beispiel kann PN 40b eine Prozesssteuerung sein, die eine jeweilige Pub-/Sub-Schicht 42b aufweist und die kommunikativ mit einem Feldgerät PNh über eine I/O-Karte PNg verbunden ist. In einem anderen Beispiel kann PN 40c ein CIOC (mit einer jeweiligen Pub-/Sub-Schicht 42c) sein, mit dem sechs verschiedene Feldgeräte PNa-PNf kommunikativ verbunden sind, oder PN 40c kann ein drahtloser Zugangspunkt 178 oder ein EIOC sein (mit einer jeweiligen Pub-/Sub-Schicht 40c), mit dem(der) verschiedene andere physische Komponenten PNa-PNf ohne Pub-/Sub-Schichten kommunikativ verbunden sind. In einem weiteren Beispiel kann PN 40a ein I/O-Rangiergerät oder ein I/O-Hub-Gerät sein, das über seine Pub-/Sub-Schicht 42a Prozess-I/O-Daten für mehrere andere PN übermittelt, die keine Pub-/Sub-Schichten haben, z. B. PNi-PNk. Das I/O-Rangier- oder Hub-Gerät 40a kann ein eigenständiges Gerät sein oder in einer anderen physischen Komponente enthalten sein, die in der physischen Anlagenumgebung 15 angeordnet ist, wie beispielsweise in einer Steuerung 110, einem I/O-Gerät 112, 115 (z. B. einem CIOC, einem ECOC, einem WIOC usw.), in einem Zugangspunkt 178, in einem Gateway 180, 182 usw. Ferner können in einigen Implementierungen das Edge-Gateway-System 28 und seine Pub-/Sub-Schicht 38 ein physischer Knoten sein, der mit verschiedenen physischen Komponenten der physischen Anlagenumgebung 15 (z. B. PN 40a-40c und PNa-PNk) kommunikativ verbunden ist (nicht in 1 dargestellt), beispielsweise in einer Art und Weise, wie in Bezug auf 3 erörtert.
-
I/O-Switch
-
Wie vorstehend erwähnt, dient der in 1 gezeigte I/O-Switch 25 als Datenbroker, Switching Fabric oder Router für Prozess-I/O-Daten zwischen Knoten des virtuellen Kommunikationsnetzwerks 45. Das heißt, der I/O-Switch 25 leitet für einen Veröffentlichungsknoten vom Veröffentlichungsknoten generierte I/O-Daten an Knoten weiter, die diese Daten abonniert haben. Im Allgemeinen kann der I/O-Switch 25 Datensätze darüber pflegen (und aktualisieren), welche I/O-Daten von welchem Knoten veröffentlicht werden und welche Knoten welche veröffentlichten I/O-Daten abonniert haben. In einer Ausführungsform können die I/O-Daten innerhalb der Datensätze durch die eindeutige Kennung, den Namen oder das Tag identifiziert werden, die über die MPDSC-Plattform 10 hinweg eindeutig sind, oder durch eine entsprechende Angabe dazu. Die eindeutige Kennung kann beispielsweise die prozessbezogenen Nutzlastdaten identifizieren, die in den I/O-Daten und/oder ihrem Veröffentlichungsknoten enthalten sind. In einer Ausführungsform werden die eindeutigen Kennungen, Namen oder Tags während der Konfiguration und/oder Inbetriebnahme zugewiesen. Der I/O-Switch 25 verwendet die gespeicherten Datensätze, um eingehende veröffentlichte Daten an Abonnenten der veröffentlichten Daten weiterzuleiten. Beispielsweise kann der I/O-Switch 25 I/O-Daten abonnieren, die von verschiedenen Knoten 28, 30x, 40x veröffentlicht werden, und beim Empfang der veröffentlichten I/O-Daten über seine Abonnements kann der I/O-Switch 25 die empfangenen I/O-Daten gemäß den gespeicherten Datensätzen an ausgewählte Abonnentenknoten 28, 30x, 40x selbst veröffentlichen. Typischerweise, aber nicht notwendigerweise, führt der I/O-Switch 25 keine Pflege, Aufzeichnung oder Speicherung von I/O-Daten und/oder prozessbezogenen Nutzlastdaten, die von anderen Knoten des virtuellen Kommunikationsnetzwerks 45 veröffentlicht werden, aus.
-
Wichtig ist, dass der I/O-Switch 25 so konfiguriert ist, dass er empfangene Prozess-I/O-Daten mit minimaler Verzögerung vermittelt oder weiterleitet. In einem Prototyp war der I/O-Switch 25 in der Lage, empfangene Prozess-I/O-Daten über den I/O-Switch 25 in Zeitintervallen weiterzuleiten, die in Hunderten von Mikrosekunden gemessen wurden, beispielsweise unter 500 Mikrosekunden, unter 200 Mikrosekunden und unter 100 Mikrosekunden, in Abhängigkeit von der Belastung.
-
Im Allgemeinen kann der I/O-Switch 25 über Hardware, Firmware und/oder Software implementiert werden. In einem Beispiel wird der I/O-Switch 25 unter Verwendung eines oder mehrerer physischer Hardwaregeräte implementiert, auf denen spezielle Software installiert ist, um mindestens einen Teil der hier beschriebenen I/O-Switch 25-Funktionalität bereitzustellen; das heißt, der I/O-Switch 25 kann als Vorrichtung implementiert sein. In einem anderen Beispiel ist der I/O-Switch 25 als Software (z. B. Programme, Routinen, Anwendungen usw.) implementiert, die auf einem Server oder einer Bank von Rechenvorrichtungen installiert und ausgeführt werden kann, um zumindest einen Teil der hier beschriebenen I/O Switch 25-Funktionalität bereitzustellen. In einem weiteren Beispiel wird der I/O-Switch 25 über eine Virtualisierung implementiert, z. B. als virtuelle Maschine, Container (wie beispielsweise Docker, LXD usw.) oder einen anderen Typ der virtualisierten Implementierung.
-
Die Pub-/Sub-Schicht 35 des I/O-Switches 25 ist im Allgemeinen in Konfiguration und Funktionalität den Pub-/Sub-Schichten 32x, 38, 42x, 55x, die an anderer Stelle in dieser Offenbarung beschrieben sind, ähnlich. Die Pub-/Sub-Schicht 35 des I/O-Switches 25 ist jedoch ferner dazu konfiguriert, Abonnementanforderungen für verschiedene identifizierte Prozess-I/O-Daten zu akzeptieren und zu pflegen. Wie vorstehend erörtert, werden Abonnements am I/O-Switch 25 aufgezeichnet und von diesem gepflegt, z. B. in einem oder mehreren materiellen, nichtflüchtigen Speichern. Ferner ist die Pub-/Sub-Schicht 35 des I/O-Switches 25 so konfiguriert, dass veröffentlichte Prozess-I/O-Daten an Abonnementsknoten, die andere I/O-Switches enthalten können, weitergeleitet werden.
-
Zur Veranschaulichung zeigt 4 eine beispielhafte Anordnung 200 mehrerer I/O-Switches 202, 205, 208, 210, die in der MPDSC-Plattform 10 von 1 enthalten sein können. In einem Beispiel hat jeder I/O-Switch 202, 205, 208, 210 eine entsprechende Architektur ähnlich der des I/O-Switches 25, einschließlich einer jeweiligen Pub-/Sub-Schicht (wie durch die jeweiligen mit Raute markierten Teile angegeben). Ebenfalls ähnlich dem I/O-Switch 25 ist jeder I/O-Switch 202, 205, 208, 210 über das virtuelle Kommunikationsnetzwerk 225 einem entsprechenden Satz von VN und/oder PN 212a-212n, 215a-215m, 218a-218p und 220a-220q zugeordnet und mit diesem verbunden, unter denen der jeweilige I/O-Switch 202, 205, 208, 210 I/O-Daten über das Veröffentlichen und Abonnieren in der Weise wie vorstehend beschrieben weiterleitet. Obwohl die Anordnung 200 vier I/O-Switches 202, 205, 208, 210 enthält, können die hier in Bezug auf die Anordnung 200 erörterten Konzepte leicht auf eine größere oder kleinere Anzahl von I/O-Switches angewendet werden, die in einer Mesh-Topologie miteinander verbunden sind.
-
In 4 kann jeder I/O-Switch 202, 205, 208, 210 ferner über das virtuelle Kommunikationsnetzwerk 225 I/O-Daten an jeden der anderen I/O-Switches 202, 205, 208, 210 weiterleiten. Durch die Verbindung mehrerer I/O-Switches 202, 205, 208, 210 kann die Anzahl der bedienten virtuellen Knoten und/oder physischen Knoten erweitert werden, um größere Systeme 10 zu unterstützen und zusätzliche Übermittlungsbandbreite bereitzustellen. In der Anordnung 200 kann jeder I/O-Switch 202, 205, 208, 210 Daten für seinen jeweiligen Satz von VN/PN für andere I/O-Switches 202, 205, 208, 210 veröffentlichen. In ähnlicher Weise kann jeder I/O-Switch 202, 205, 208, 210 Daten abonnieren, die von anderen I/O-Switches 202, 205, 208, 210 für ihre jeweiligen Sätze von VN/PN 212a-212n, 215a-215m, 218a-218p, 220a-220q weitergeleitet werden.
-
Die Anordnung 200 veranschaulicht, dass jeder der I/O-Switches 202, 205, 208, 210 mit jedem der anderen I/O-Switches 202, 205, 208, 210 direkt verbunden ist. Das heißt, das virtuelle Kommunikationsnetzwerk 225 weist eine vollständig vernetzte oder Mesh-Topologie auf. Dementsprechend ist in einer Implementierung dieser Anordnung 200 die maximale Übertragungsverzögerung von einem Veröffentlicherknoten zu einem Abonnentenknoten begrenzt, da die maximale Anzahl von Sprüngen, die eine bestimmte Prozess-I/O-Datennutzlast durchlaufen kann, drei beträgt. In anderen Implementierungen der Anordnung 200 kann die maximale Anzahl von Sprüngen davon verschieden sein. Beispielsweise kann die maximale Anzahl von Sprüngen erhöht werden, z. B. zum Überwachen von Verkehr, wenn Zeitsequenzierungsfunktionen (wie Zeitsequenzierungsnetzwerke oder andere geeignete Zeitsequenzierungsfunktionen) und dergleichen verwendet werden. Falls gewünscht, kann eine maximale Anzahl von Sprüngen innerhalb der Anordnung 200 konfiguriert und modifiziert werden.
-
Natürlich können zusätzlich oder alternativ zur Mesh-Topologie für das virtuelle Kommunikationsnetzwerk 225 auch andere vernetzte Topologien (z. B. Hub-and-Spoke, Stern, Ring, Baum, Hybrid usw.) möglich sein. Im Allgemeinen erfolgen Abonnements zum Verarbeiten von I/O-Daten, die von einem bestimmten Veröffentlichungsknoten, z. B. dem Knoten 215a, veröffentlicht werden, für den entsprechenden I/O-Switch, z. B. den I/O-Switch 205, und werden von diesem verwaltet. Wenn der I/O-Switch 205 jedoch keinen Datensatz für die bestimmten Daten hat, für die ein Abonnement angefordert wird, kann der I/O-Switch 205 die Abonnementanforderung an die anderen I/O-Switches 202, 208, 210 weiterleiten. Der bestimmte I/O-Switch, der dem Knoten entspricht, der die angeforderten Daten veröffentlicht, z. B. der I/O-Switch 210, der dem Veröffentlichungsknoten 220q entspricht, hat einen Datensatz, der den angeforderten Daten und deren Veröffentlichungsknoten 220q entspricht, und antwortet dem I/O-Switch 205, der dem anfordernden Knoten 215a entspricht, woraufhin der I/O-Switch 105 einen entsprechenden Datensatz für die angeforderten Daten erstellen und speichern kann. Auf diese Weise kann eine Durchlaufroute für die angeforderten Daten vom Veröffentlichungsknoten 220q zum Abonnementknoten 215a über die I/O-Switches 210, 205 eingerichtet werden.
-
In einer Ausführungsform kann die Anordnung 200 über mehrere MPDSC-Systeme 10 hinweg implementiert sein. Beispielsweise kann der I/O-Switch 202 in einem ersten MPDSC-System enthalten sein und der I/O-Switch 205 kann in einem anderen MPDSC-System enthalten sein. Damit können verschiedene MPDSC-Systeme die Prozess-I/O-Daten des jeweils anderen über eine oder mehrere Verbindungen des virtuellen Kommunikationsnetzwerks 225 veröffentlichen und/oder abonnieren.
-
Virtuelle Echtzeitsteuerung und zugehörige Operationen
-
Wie vorstehend erwähnt, können die virtuellen Knoten 30x das Verhalten der verschiedenen physischen Komponenten, die innerhalb des physischen Anlagenumgebung 15 betreibbar sind, virtualisieren. Ferner können aufgrund der Merkmale der MPDSC-Plattform 10 virtualisierte Komponenten 30x der virtuellen Anlagenumgebung 12 in Verbindung mit physischen Komponenten der physischen Anlagenumgebung 15 arbeiten, um Echtzeitsteuerung der industriellen Prozessanlage während der Laufzeit durchzuführen, um dadurch physische Produkte aus Rohstoffen zu generieren. Unter gleichzeitiger Bezugnahme auf die 1, 2 und 3 zur Veranschaulichung wird nun erläutert, wie die Prozesssteuerung 110 als der virtuelle Knoten 30a virtualisiert werden kann, der eine Architektur 52a aufweist. Dazu enthält der virtuelle Knoten 110/30a statt der physischen Prozesssteuerung 110, die ihre entsprechenden Steuermodule oder -routinen 118 zur Laufzeit ausführt, die Steuermodule oder -routinen 118 wie sein CBM 58a und führt die entsprechenden Steuermodule oder -routinen 118 während der Laufzeit aus, was das Senden und Empfangen von Signalen zu/von verschiedenen Feldgeräten beinhalten kann, die in der physischen Umgebung 15 über den I/O-Switch 25 angeordnet sind.
-
Beispielsweise kann während der Laufzeit der industriellen Prozessanlage 100 die virtuelle Steuerung 110/30a Daten empfangen, die von dem Feldgerät 129 über ein physisches I/O-Gerät 115 generiert werden. In diesem Beispiel ist das physische I/O-Gerät 115 in 1 durch den physischen Knoten PNg, dargestellt; das Feldgerät 129 ist in 1 durch den physischen Knoten PNh dargestellt und der physische Knoten 40b ist ein I/O-Hub-Gerät. Datennutzlast, die durch das Feldgerät PNh generiert wird, wird über das I/O-Gerät PNg an das I/O-Hub-Gerät 40b übermittelt, das ein Knoten des virtuellen Kommunikationsnetzwerks 45 ist. Das I/O-Hub-Gerät 40b kann dem I/O-Switch 25 die Datennutzlast veröffentlichen, die durch das Feldgerät PNh generiert und vom I/O-Hub-Gerät 40b veröffentlicht wurde, für das der I/O-Switch 25 über ein Abonnement verfügt. Im Gegenzug kann der I/O-Switch 25 die Nutzlastdaten, die durch das Feldgerät PNh generiert wurden, der virtuellen Steuerung 110/30a veröffentlichen, woraufhin das CBM 58a (z. B. die Steuermodule/-routinen 118) der virtuellen Steuereinheit 110/30a auf den vom Feldgerät PNh generierten Nutzlastdaten Operationen ausführen kann. Das CBM 58a kann Ausgangsnutzlastdaten generieren, die über das virtuelle Kommunikationsnetzwerk 45 an einen anderen virtuellen oder physischen Knoten übermittelt werden sollen.
-
In einem anderen Beispiel kann die virtuelle Steuerung 110/30a während der Laufzeit der industriellen Prozessanlage 100 Daten empfangen, die von dem drahtlosen Feldgerät 142a generiert werden. In diesem Beispiel wird das physische drahtlose Feldgerät 142a in 1 durch den physischen Knoten PNa repräsentiert und das physische drahtlose Gateway 168 wird durch PN 40c repräsentiert. Das drahtlose Gateway PN 40c empfängt Nutzlastdaten, die durch das drahtlose Feldgerät PNa generiert wurden. Da PN 40c ein Knoten des virtuellen Kommunikationsnetzwerks 45 ist, veröffentlicht PN 40c an den I/O-Switch 25 die Nutzlastdaten, die von dem drahtlosen Feldgerät PNa generiert wurden, für die der I/O-Switch 25 über ein Abonnement verfügt. Im Gegenzug kann der I/O-Switch 25 die Nutzlastdaten, die von dem Feldgerät PNa generiert wurden, an einen virtuellen Knoten 30b veröffentlichen, wobei der virtuelle Knoten 30b als Repräsentation eines I/O-Geräts, wie beispielsweise des I/O-Geräts 115, konfiguriert ist. Das virtuelle I/O-Gerät 30b verfügt über ein Abonnement für die Nutzlastdaten, die von dem Feldgerät PNa generiert und durch den I/O-Switch 25 weitergeleitet wurden. Damit erhält das virtuelle I/O-Gerät 30b die durch das drahtlose Feldgerät PNa generierten Nutzlastdaten über sein Abonnement und veröffentlicht von neuem die erhaltenen, von dem Feldgerät PNa generierten Nutzlastdaten für den I/O-Switch 25 zur Weiterleitung an geeignete Abonnenten. Der I/O-Switch 25 kann wiederum die erhaltenen Nutzlastdaten des Feldgeräts PNa veröffentlichen, die durch das virtuelle I/O-Gerät 30b für seine jeweiligen Abonnenten, die (in diesem Beispiel) die virtuellen Steuerung 30a beinhalten, veröffentlicht wurde. Bei Empfang der Nutzlastdaten an der virtuellen Steuerung 30a über sein Abonnement für diese kann das CBM 58a (z. B. die Steuermodule/-routinen 118) der virtuellen Steuerung 30a, auf den Nutzlastdaten, die durch das drahtlose Feldgerät PNa generiert wurden, Operationen durchführen. Das CBM 58a kann Ausgangsnutzlastdaten generieren, die über das virtuelle Kommunikationsnetzwerk 45 an einen anderen virtuellen oder physischen Knoten übermittelt werden sollen.
-
Die Virtualisierung physischer Komponenten von industriellen Prozessanlagen bietet zahlreiche Vorteile gegenüber industriellen Prozessanlagen, die vollständig mit physischen Komponenten implementiert sind. Durch virtualisierte Komponenten kann eine industrielle Prozessanlage in Bezug auf Größe und Anzahl der Komponenten flexibel vergrößert und/oder verkleinert werden, wobei nur minimale Änderungen des Hardware-Platzbedarfs und geringere Installationskosten erforderlich sind. Da ein virtueller Knoten ein physisches Gerät in seiner Gesamtheit oder nur einen Teil davon repräsentieren kann, kann die Steuerung leicht skaliert werden, z. B. über so viele virtuelle Knoten wie erforderlich. Darüber hinaus bietet die MPDSC-Plattform 10 I/O-Flexibilität beispielsweise über die Abstraktion von I/O, sodass Steuerungen weniger von tatsächlichen konfigurierten und heruntergeladenen I/O-Modulzuweisungen abhängig sind. Das heißt, dass I/O-Bindungsentscheidungen zwischen physischen I/O-Geräten und Steuerungen und Feldgeräten zumindest aufgrund des I/O-Switches 25 eliminiert werden können. Durch die Verwendung virtueller physischer Komponenten können Software-Upgrades bei den virtualisierten physischen Komponenten problemlos durchgeführt werden. Darüber hinaus können Simulationen und Online-Tests des Verhaltens physischer Komponenten durch die Verwendung der MPDSC-Plattform 10 gegenüber derzeit bekannten Techniken ebenfalls leicht erreicht und verbessert werden.
-
Virtuali si erungsverwaltungsknoten 5 ist ein Blockdiagramm, das eine beispielhafte Architektur veranschaulicht, die Konfiguration, Inbetriebnahme, Verwaltung und Administration des MPDSC-Systems 10 von 1 unterstützt. Der Übersichtlichkeit halber und nicht zu Zwecken der Einschränkung wird 5 hier unter gleichzeitiger Bezugnahme auf 1-4 erörtert. Wie in 5 dargestellt, erstellt, konfiguriert und verwaltet ein Virtualisierungsverwaltungsknoten 300 (der hier gleichbedeutend als „VMN 300“ oder „virtueller Knoten 300“ bezeichnet wird) virtualisierte Komponenten des MPDSC-Systems 10, wie beispielsweise den I/O-Switch 25, verschiedene virtuelle Knoten 30x, das virtuelle PIO-Subsystem 60, die Veröffentlichungs-/Abonnementschichten 32x, 35, 38, 42x usw. Der VMN 300 führt automatisch mindestens einen Teil der Erstellung, Konfiguration und Verwaltung virtueller Komponenten durch. Zusätzlich oder alternativ führt der VMN 300 zumindest einen Teil der Erstellung, Konfiguration und Verwaltung der virtuellen Komponenten basierend auf manuellen Anweisungen, z. B. manuellen Anweisungen, die über eine Benutzeroberfläche 302 des VMN 300 empfangen werden, die lokal oder eine entfernte Benutzeroberfläche sein kann, durch. Ferner steuert und/oder koordiniert der Virtualisierungsverwaltungsknoten 300 Simulationsaktivitäten der virtuellen Prozessumgebung 12, die mit und/oder ohne Inline-Benutzereingabe während der Simulationen durchgeführt werden können, wie nachstehend ausführlicher beschrieben wird.
-
Konfiguration, Administration und Verwaltung virtueller Komponenten
-
In einer Ausführungsform greift der VMN 300 während der Konfiguration und/oder Inbetriebnahme der virtuellen Umgebung 12 und ihrer Komponenten auf die Systemkonfigurationsdatenbank der Anlage zu (z. B. greift der VMN 300 auf die Konfigurationsdatenbank(en) 172b der Anlage 100 über die Datenautobahn 108 zu) und basierend auf der erhaltenen Konfiguration bestimmt der VMN 300 die Typen und Anzahlen von virtuellen Knoten, virtuellen Vorlagen und/oder Subsystemen, I/O-Switches und/oder anderen virtuellen Komponenten, die die Anlagenkonfiguration am besten unterstützen würden (oder die zu deren Unterstützung gewünscht werden). Der VMN 300 erstellt die verschiedenen Typen und Anzahlen von virtuellen Knoten 30x und konfiguriert den I/O-Switch 25 und die virtuellen Knoten 30x zum Kommunizieren über das virtuelle Kommunikationsnetzwerk 45, beispielsweise über entsprechende Veröffentlichungs-/Abonnements-Schichten 32x und, für einige VN 30x, über das virtuelle PIO-Subsystem 60. Bei manchen Anlagenkonfigurationen kann der VMN 300 Instanzen von Veröffentlichungs-/Abonnements-Schichten 42x (und optional Instanzen des virtuellen PIO-Subsystems 60) erstellen und an verschiedene physische Komponenten 40x der physischen Anlagenumgebung 15 verteilen. Damit kann der VMN 300 eine beliebige Anzahl von Knoten 25, 28, 30x, 40x des virtuellen Kommunikationsnetzwerks 45 erstellen, konfigurieren und administrieren, die virtuelle Komponenten enthalten können, die in Verbindung mit physischen Komponenten der physischen Anlage arbeiten, um Echtzeitsteuerung und/oder dynamische Simulation durchführen.
-
Die Konfiguration des virtuellen Kommunikationsnetzwerks 45 und seiner Knoten 25, 28, 30x, 40x kann in der Systemkonfigurationsdatenbank 172b und/oder lokal in einer Konfigurationsdatenbank 305 für die virtuelle Umgebung gespeichert sein. In einigen Implementierungen wird eine Master-Version der Konfiguration der virtuellen Anlagenumgebung 12 in der Systemkonfigurationsdatenbank 172b (zusammen mit der Konfiguration der physischen Anlagenumgebung 15) gespeichert und eine Kopie der Master-Konfiguration der virtuellen Anlagenumgebung 12 wird lokal in der Konfigurationsdatenbank 305 der virtuellen Umgebung gespeichert. In einigen Implementierungen wird eine Master-Version der Konfiguration der virtuellen Anlagenumgebung 12 in der Konfigurationsdatenbank 305 der virtuellen Umgebung gespeichert und eine Kopie der Master-Konfiguration der virtuellen Anlagenumgebung 12 wird in der Systemkonfigurationsdatenbank 172b (zusammen mit der Konfiguration der physischen Anlagenumgebung 15) gespeichert. Der VMN 300 koordiniert die Änderungsverwaltung und Synchronisation von Daten, die in der Konfigurationsdatenbank 305 der virtuellen Umgebung gespeichert sind, und von verwandten Daten, die in der Systemkonfigurationsdatenbank 172b gespeichert sind.
-
Während die Anlage 100 operative Prozesssteuerung während der Laufzeit der Prozessanlage 100 durchführt, kann der VMN 300 den I/O-Switch 25, virtuelle Knoten 30x, das virtuelle Kommunikationsnetzwerk 45 sowie damit verbundene Knoten überwachen (wie beispielsweise physische Knoten 40x, 28) in Bezug auf beispielsweise das Laden von Ressourcen, die Verfügbarkeit von Ressourcen, die Bandbreite von Ressourcen, das Auftreten von Störfällen und andere Leistungsprobleme von Hardware- und/oder Softwareressourcen, die von der physischen Datenverarbeitungs-Plattform bereitgestellt werden, die die virtuelle Umgebung 12 unterstützt, z. B. ein Plattform von Hardware-Rechenvorrichtungen, die die virtuelle Umgebung 12 unterstützen. Basierend auf erkannten und/oder vorhergesagten Bedingungen kann der VMN 300 während des Laufzeitbetrieb automatisch Abhilfemaßnahmen durchführen, z. B. Anpassen der Ressourcenzuweisungen, Aktivieren von virtuellen Standby-Knoten, Erstellen und/oder Löschen von virtuellen Knoten usw., z. B. für Lastausgleich, Fehlerbehebung und andere Leistungszwecke. Beispielsweise kann der VMN 300 Leistungsengpässe analysieren und automatische Regulierungsoperationen durchführen, um erkannte Engpässe abzustellen. Beispielsweise kann der VMN 300 als Reaktion auf die Menge des virtuellen Netzwerkverkehrs im virtuellen Kommunikationsnetzwerk 45 eine automatische Regulierung auf Prozessdatenebene durchführen und/oder der VMN 300 kann so eine automatische Regulierung auf der Ebene einer physischen Rechenvorrichtung durchführen, dass diese CPU- und/oder physische Netzwerkauslastung über die physischen Rechenvorrichtungen, physischen Datenverbindungen und/oder physischen Netzwerke, in denen die virtuelle Umgebung 12 implementiert ist, ausgeglichen wird.
-
In administrativer Hinsicht kann der VMN 300 Speichern, Snapshots, Erstellen von Sicherungskopien, Migrieren, Wiederherstellen usw. verschiedener virtueller Knoten, virtueller Vorlagen und Subsysteme sowie der zugehörigen Prozessdaten durchführen und der VMN 300 kann Speichern, Snapshots, Erstellen von Sicherungskopien, Migrieren, Wiederherstellen usw. der gesamten virtuellen Umgebung 12 selbst durchführen. In einer Ausführungsform kann jede vom VMN 300 ausgeführte administrative Aktion auf eine Gesamtheit der Logik angewendet werden, die von betreffenden virtuellen Knoten simuliert wird (z. B. die Gesamtheit der Logik, die von einem kollektiven Satz von CBM 58 der betreffenden virtuellen Knoten ausgeführt wird). Wenn beispielsweise ein Snapshot von einer virtuellen Steuerung erstellt und gespeichert wird, speichert der VMN 300 möglicherweise nicht nur Daten, die von der virtuellen Steuerung empfangen, bearbeitet und generiert werden und Angaben zu deren Vernetzungen und Betriebszustände machen, sondern der VMN 300 speichert unter Umständen im Rahmen des Snapshots auch die zugehörigen Daten von Modulen, die in Verbindung mit der virtuellen Steuerung ausgeführt werden, selbst wenn diese Module auf anderen Knoten gehostet werden und/oder andere physische Komponenten simulieren. In einem anderen Beispiel kann der VMN 300 beim Erstellen und Speichern eines Snapshots eines virtuellen CIOC Daten speichern, die der Ebene der virtuellen Maschine des virtuellen CIOC entsprechen, und/oder der VMN 300 kann Prozesssimulationswerte speichern, die vom virtuellen CIOC beobachtet werden.
-
Dynamische Simulation
-
Wie vorstehend erwähnt, unterstützt das MPDSC-System 10 die dynamische Simulation der gesamten Prozessanlage 100 und/oder von Teilen davon. Beispielsweise stellt das MPDSC-System 10 eine Echtzeitsimulation bereit, bei der die Echtzeitsimulation die Laufzeit-Zeitsteuerung, die Werte und/oder andere Verhaltensweisen mindestens eines Teils einer entsprechenden physischen Komponente und/oder eines physischen Betriebsprozesses widerspiegelt. Dabei werden die Begriffe „Simulation“ und „Simulationslauf“ hier gleichbedeutend verwendet und eine Simulation oder ein Simulationslauf ist begrenzt. Das heißt, jede Simulation oder jeder Simulationslauf hat einen jeweiligen Start und ein jeweiliges Ende, die wie gewünscht definiert werden können, z. B. basierend auf einer Zeit, einem Parameterwert, einem Zustand, einem Benutzerbefehl und/oder anderen Kriterien.
-
Zusätzlich sieht das MPDSC-System 10 die Manipulation von Simulationen vor, wie zum Beispiel das Beschleunigen oder Verlangsamen des Tempos der Simulationsausführung, das Anhalten der Simulation, das Einfügen und/oder Modifizieren verschiedener Werte, das Ändern von Ausgangsbedingungen usw. Simulationen können vollständig innerhalb der virtuellen Umgebung 12 des MPDSC-Systems 10 ausgeführt werden und/oder Simulationen können unter Verwendung einer oder mehrerer virtueller oder simulierter Komponenten in Verbindung mit einer oder mehreren physischen Komponenten ausgeführt werden (z. B. kann eine Konfiguration einer Steuerung, die von einem virtuellen Knoten in der virtuellen Umgebung 12 simuliert wird, mit einem physischen Feldgerät kommunizieren, das in der physischen Umgebung 15 angeordnet ist, um das simulierte Steuerungsverhalten zu testen). Im Allgemeinen bietet das MPDSC-System 10 eine Plattform, über die Ingenieure und Benutzer Entwürfe von Steuerungsstrategien und Entwürfe von Bedieneranzeigen testen und überprüfen, Prozessverbesserungen untersuchen, Bedienerschulungen durchführen, Fallstudien durchführen können, usw. Der VMN 300 verwaltet, koordiniert und steuert Simulationsaktivitäten an, die vom MPDSC-System 10 unterstützt werden.
-
Insbesondere erstellt, konfiguriert und administriert der VMN 300 virtuelle Knoten 25, 30x und andere virtuelle Komponenten 28, 32, 35, 38, 42x, 60, die mindestens Teile der physischen Anlage 100 simulieren. Virtuelle Knoten 25, 30x, die ausschließlich zu Simulationszwecken (und nicht zu Laufzeitsteuerungszwecken) verwendet werden, werden hier gleichbedeutend als „simulierte Knoten“ bezeichnet. Beispielsweise kann der VMN 300 ein Spiegelsimulationssystem des gesamten Laufzeitsteuersystems generieren, wie es durch die Anlagenkonfigurationsdatenbank 172b beschrieben ist, z. B. indem simulierte Knoten verwendet werden, die integrale physische Hardwarekomponenten wie Steuerungen 110, Workstations 170a und/oder andere physische Geräte und ihre entsprechenden Netzwerkverschaltungen (in einigen Implementierungen bis auf die MAC-Adressenebene) simulieren. In einem anderen Beispiel kann der VMS 300 entsprechende Simulationen einer oder mehrerer einzelner physischer Komponenten generieren, von denen jede in einem eigenständigen Modus oder in Verbindung mit einer oder mehreren anderen simulierten, virtuellen und/oder physischen Komponenten ausgeführt werden kann. Beispielsweise kann der VMS 300 innerhalb der virtuellen Umgebung 12 einen virtuellen Zwilling einer physischen Komponente generieren, die derzeit in der physischen Umgebung 15 arbeitet, z. B. um eine neue Steuerungskonfiguration, ein Upgrade, einen Patch usw. zu testen, die/das auf die physische Komponente anzuwenden ist. In einem anderen Beispiel kann VMS 300 eine Simulation eines Verhaltens einer bestimmten physischen Komponente auf MAC-Adressenebene generieren. In noch einem weiteren Beispiel kann der VMS 300 einen als Einheit dargestellten (z. B. einzelnen), simulierten Knoten generieren, der das Echtzeit-Betriebsverhalten einer Gruppe von physischen Geräten, Komponenten oder Knoten simuliert, wie z. B. einen Regelkreis oder eine Bedieneranzeigeansicht.
-
In Bezug auf das Konfigurieren der Typen von Datenwerten, die in der virtuellen 12 und physischen 15 Umgebung des Prozessleitsystems 100 verwendet werden, definiert in einer Ausführungsform eine Systemprozessdatendefinition (die über eine Systemkonfigurationsanwendung 172a und/oder über den VMS 300 konfiguriert werden kann), welche Datenwerte (und/oder Typen davon), die in der Prozessanlage 100 verwendet werden, simuliert werden sollen, und der VMS 300 weist den Datenwerten (und/oder Typen davon), die zu simulieren sind, entsprechende Daten-Tags (z. B. Kennungen) zu. Beispielsweise kann der VMS 300 mindestens einigen Datenwerten und/oder Datentypen, die simuliert werden sollen, automatisch Daten-Tags zuweisen, und/oder der VMS 300 kann manuell generierte Daten-Tags von mindestens einigen Datenwerten und/oder Datentypen, die simuliert werden sollen, empfangen, z. B. über die Benutzeroberfläche 302. Zugewiesene Daten-Tags von simulierten Datenwerten und/oder Datentypen können in der Konfigurationsdatenbank 305 der virtuellen Umgebung und/oder in der Systemkonfigurationsdatenbank 172b gespeichert werden.
-
Zusätzlich steuert und/oder koordiniert der VMN 300 die Simulationen der gesamten physischen Anlage 100 und/oder von Teile davon. Zu diesem Zweck stellt die virtuelle Umgebung 12 eine Simulator-API (Application Programming Interface - Anwendungsprogrammierschnittstelle) 310 oder einen anderen geeigneten Zugriffsmechanismus bereit, über den Anwendungen, wie die Benutzeroberfläche 302, IT-Schicht-Anwendungen 21x und/oder Anwendungen von Drittanbietern oder externen Anbietern 22x zu Simulationszwecken mit der virtuellen Umgebung 12 verbunden sein können. In einer Ausführungsform hostet der VMN 300 oder eine andere Rechenvorrichtung in der virtuellen Umgebung 12 die Simulator-API 310 und/oder stellt sie anderen Anwendungen bereit.
-
Wie in 5 dargestellt, kommuniziert die Simulator-API 310 simulierte Datenwerte (hier auch gleichbedeutend als „Simulationsdatenwerte“, „simulierte Werte“ und/oder „Simulationswerte“ bezeichnet) an die und von der virtuellen Umgebung 12 und darin enthaltene simulierte Komponenten über den I/O-Switch 25. Allgemein ausgedrückt werden simulierte Laufzeitprozessdaten zwischen 28, 30x und der Simulator-API 310 über die jeweiligen Pub-/Sub-Schichten der Knoten übermittelt. Beispielsweise können die simulierten Knoten 28, 30x, 310 Laufzeitprozessdaten über den I/O-Switch 25 auf einem oder mehreren anderen simulierten Knoten 28, 30x, 310 veröffentlichen und die simulierten Knoten 28, 30x, 310 können Laufzeitprozessdaten abonnieren, die von einem oder mehreren anderen simulierten Knoten 28, 30x, 310 generiert und über den I/O-Switch 25 empfangen werden. Andererseits können in einer Ausführungsform simulierte Datenwerte, die keine Laufzeitprozessdaten sind (z. B. Datenwerte, die konfigurierbar sind und die typischerweise während der Downloadzeit in der physischen Umgebung 15 zugewiesen werden), zwischen simulierten Knoten 28, 30x, 310 bei aufgetretenen Änderungen übermittelt werden, z. B. nur, wenn sich die jeweiligen Werte der Daten ändern.
-
Die Simulator-API 310 ist mit Namen, Daten-Tags, Kennungen, Datendefinitionen, Kanaldaten usw. von simulierten Komponenten in der virtuellen Umgebung 12 (z. B. basierend auf Daten, die in der virtuellen Konfigurationsdatenbank 305 gespeichert sind) konfiguriert und die Simulator-API 310 ist auch dazu konfiguriert, unter Verwendung eines oder mehrerer industrieller und/oder universeller Kommunikations-/Datenprotokolle zu kommunizieren, wobei es sich um ein standardisiertes Protokoll handeln kann, z. B. OPC, Ethernet, IPv6 usw. Damit dient die Simulator-API 310 als Datenübermittlungs- und Transportmechanismus zwischen simulierten Komponenten innerhalb der virtuellen Umgebung 12 und anderen Anwendungen 302, 21x, 22x, die Verbraucher und/oder Anbieter von Simulationsdaten sind und die das eine oder mehrere industrielle und/oder universelle Kommunikations-/Datenprotokolle verwenden. Beispielsweise kann eine Simulationsanwendung eines Drittanbieters die Simulator-API 310 verwenden, um Testwerte zur Verwendung durch eine simulierte Komponente zuzuführen, die Ausgangsbedingungen eines Simulationslaufs zu ändern usw.
-
Zusätzlich oder alternativ verarbeitet die Simulator-API 310 Simulationsbefehle, die über die Benutzeroberfläche 302 und/oder durch andere Anwendungen 21x, 22x bereitgestellt werden. Beispielsweise kann die Simulator-API 310 Simulationsbefehle empfangen, um das Tempo der Modulausführung (von der zumindest ein Teil in der virtuellen Umgebung 12 simuliert wird) zu beschleunigen und/oder zu verlangsamen und/oder um das Tempo der I/O-Verarbeitung zu beschleunigen und/oder zu verlangsamen, und kann die Zeitsteuerung und die Aktionen von zugeordneten simulierten Knoten 30x, 28 und/oder des virtuellen Kommunikationsnetzwerks 45 entsprechend steuern. In einem anderen Beispiel kann die Simulator-API 310 Simulationsbefehle empfangen, um verschiedene Datenwerte während der Simulation zuzuführen und/oder zu ändern. Ferner kann die Simulator-API 310 administrative Simulationsbefehle empfangen, um beispielsweise einen Snapshot zu speichern, einen gespeicherten Snapshot abzurufen, aus gespeicherten Daten wiederherzustellen usw. und als Antwort die entsprechende Aktion auszuführen. Beispielsweise kann die Simulator-API 310 Simulationsbefehle empfangen und darauf reagieren, um eine Simulation der gesamten Prozessanlage 100 zu speichern, abzurufen, wiederherzustellen usw. (z. B. zu/von der Konfigurationsdatenbank 305 für die virtuelle Umgebung und/oder zu/von der Systemkonfigurationsdatenbank 172b) sowie zum Speichern, Abrufen, Wiederherstellen usw. einer Simulation eines oder mehrerer Knoten oder Komponenten der Prozessanlage 100.
-
Im Allgemeinen ist die Simulations-API 310 statusbehaftet. Das heißt, die Simulations-API 310 kennt verschiedene Zustände der Simulation und der Komponenten (z. B. von virtuellen, physischen und/oder simulierten Geräten; virtuellen, physischen und/oder simulierten Modulen; anderen Typen von virtuellen, physischen und/oder simulierten Komponenten; einen Prozess, der durch die Simulation zumindest teilweise simuliert wird, einen Zustand der Gesamtsimulation usw.), die damit verbunden sind, während die Simulation ausgeführt wird und auf die empfangenen Befehle basierend auf den verschiedenen Zuständen reagiert. Wenn die Simulations-API 310 beispielsweise auf einen Befehl zum Speichern reagiert, kann sie Prozessdaten in Verbindung mit Daten speichern, die Angaben zum Status der zugeordneten Komponenten machen. In einem anderen Beispiel kann es die Simulations-API 310 beim Simulieren eines modifizierten Steuermoduls, das zu Testzwecken in einer Steuerung ausgeführt wird, einem Benutzer ermöglichen, den Status eines zugeordneten Moduls zu ändern, um zu festzulegen, wie das modifizierte Steuermodul auf verschiedene Zustände des zugeordneten Moduls reagieren würde.
-
6 ist ein Flussdiagramm eines beispielhaften Verfahrens 400 zum Steuern eines industriellen Prozesses einer industriellen Prozessanlage. Mindestens ein Teil der Ausführungsformen des Verfahrens 400 kann von einem oder mehreren Teilen des dynamischen Mehrzweck-Simulations- und industriellen Laufzeit- oder Prozessleit-(MPDSC)-Systems oder der Plattform 10 aus 1 und/oder einer oder mehrerer Komponenten davon ausgeführt werden. Zum Beispiel kann mindestens ein Teil des Verfahrens durch den I/O-Switch aus 1 ausgeführt werden. Zusätzlich oder alternativ kann mindestens ein Teil des Verfahrens 400 in Verbindung mit einem oder mehreren Teilen der Ausführungsformen der virtuellen Knoten 52a, 52b aus 2; einem oder mehreren Teilen der Ausführungsformen der physischen Anlagenumgebung 100 aus 3 und/oder einer oder mehreren Komponenten davon; einem oder mehreren Teilen der Ausführungsformen der Anordnung 200 aus I/O-Switches aus 4; und/oder einem oder mehreren Teilen der Ausführungsformen des Virtualisierungsverwaltungsknotens 300 aus 5 ausgeführt werden. Zum Beispiel kann mindestens ein Teil des Verfahrens durch die Anordnung 200 aus I/O-Switches aus 4 ausgeführt werden. Das Verfahren 400 wird hier zur leichteren Veranschaulichung, und nicht um eine Beschränkung zu bewirken, beschrieben, wobei gleichzeitig auf Teile der 1-5 bezuggenommen wird. Ferner kann das Verfahren 400 in Ausführungsformen mehr, weniger und/oder andere alternative Schritte als die hier beschriebenen enthalten.
-
Wie in 6 dargestellt, enthält das Verfahren 400 das Ausführen eines Prozessregelkreises zur Regelung mindestens eines Teils eines industriellen Prozesses (Block 402), z. B. während des Laufzeitbetriebs der industriellen Prozessanlage. Der Prozessregelkreis weist ein Feldgerät, das sich in einer physischen Umgebung der industriellen Prozessanlage befindet, und eine Prozesssteuerung auf. Das Feldgerät und die Prozesssteuerung sind in einem Prozessregelkreis über einen I/O-Knoten kommunikativ miteinander verbunden. In einem Beispiel kann der I/O-Knoten eine Ausführungsform des I/O-Switches aus 1 sein.
-
Das Ausführen des Prozessregelkreises (Block 402) kann in einem Echtzeit-Steuerungsprotokoll (Block 405) das Beziehen einer ersten Veröffentlichung am I/O-Knoten enthalten. Bei dem Echtzeit-Steuerungsprotokoll kann es sich beispielsweise um ein öffentliches oder privates Paketprotokoll handeln und der I/O-Knoten kann die erste Veröffentlichung basierend auf einem Abonnement des I/O-Knotens erhalten, der der ersten Veröffentlichung entspricht. Beispielsweise kann das Abonnement für die Art des Inhalts, den bestimmten Inhalt, den Absender usw. erfolgen. In einigen Szenarien kann der Absender oder Veröffentlicher der ersten Veröffentlichung das Feldgerät sein (z. B. wenn das Feldgerät selbst ein Knoten des Echtzeit-Steuerungsnetzwerks ist, zum Beispiel auf ähnliche Weise wie der Knoten 40b aus 1). In einigen Szenarien kann der Absender oder Veröffentlicher der ersten Veröffentlichung ein dazwischenliegender Knoten oder ein Gerät sein, das zwischen dem Feldgerät und dem I/O-Knoten angeordnet ist. Zum Beispiel kann das Feldgerät, wie in 1 gezeigt, dem physikalischen Knoten PNa ähneln und sein jeweiliger dazwischenliegender Knoten kann dem Knoten 40c ähneln.
-
Bei einigen Ausführungsformen wird das Echtzeit-Steuerungsprotokoll innerhalb eines Echtzeit-Steuerungsnetzwerks verwendet, wobei das Echtzeit-Steuerungsnetzwerk den I/O-Knoten und mehrere andere Knoten enthält. Beispielsweise kann das Echtzeit-Steuerungsnetzwerk dem Netzwerk 45 aus 1 ähneln. Damit können bei Ausführungsformen das Feldgerät und die Prozesssteuerung über das den I/O-Knoten enthaltenden Echtzeit-Steuerungsnetzwerk kommunikativ miteinander verbunden sein. Beispielsweise kann ein erster Knoten aus den mehreren anderen Knoten dem Feldgerät entsprechen und ein zweiter Knoten aus den mehreren anderer Knoten der Prozesssteuerung entsprechen. Im Echtzeit-Steuerungsnetzwerk kommunizieren der I/O-Knoten und die mehreren anderer Knoten, indem sie Daten unter Verwendung des Echtzeit-Steuerungsprotokolls in dem Echtzeit-Steuerungsnetzwerk veröffentlichen und indem sie Daten abonnieren, die unter Verwendung des Echtzeit-Steuerungsprotokolls im Echtzeit-Steuerungsnetzwerk veröffentlicht wurden. Beispielsweise können der I/O-Knoten und jeder aus den mehreren anderen Knoten eine jeweilige Veröffentlichungs-/Abonnement-Schicht enthalten, die ein jeder der Knoten zur Kommunikation über das Echtzeit-Steuerungsnetzwerk verwendet. Dementsprechend kann bei diesen Ausführungsformen der erste Knoten, der dem Feldgerät entspricht, erste Daten, die von dem Feldgerät erzeugte Daten angeben, während der Laufzeitausführung des Prozessregelkreises im Echtzeit-Steuerungsnetzwerk veröffentlichen und kann der I/O-Knoten über ein entsprechendes Abonnement die veröffentlichten ersten Daten über das Echtzeit-Steuerungsnetzwerk beziehen.
-
Wie darüber hinaus in 6 dargestellt, beinhaltet das Ausführen des Prozessregelkreises (Block 402) das Bestimmen eines Abonnenten von Veröffentlichungen, die den vom Feldgerät erzeugten Dateninhalt angeben (Block 408), durch den I/O-Knoten. Der Abonnent kann der Prozesssteuerung entsprechen; beispielsweise kann der Abonnent der zweite Knoten aus den mehreren anderer Knoten sein, die sich in dem Echtzeit-Steuerungsnetzwerk befinden, das von dem Feldgerät erzeugte Dateninhalte und/oder eine Art von Übertragung, die von dem Feldgerät oder dem ersten, dem Feldgerät entsprechenden Knoten erzeugt wurden, abonniert hat. Das Bestimmen des Abonnenten (Block 408) kann auf einem Satz eindeutiger Kennungen basieren, die vom I/O-Knoten verwaltet werden und/oder ihm zugänglich sind, wobei jede der eindeutigen Kennungen jeweils einen jeweiligen Dateninhalt, einen jeweiligen Absender oder Veröffentlicher einer oder mehrerer Arten von Dateninhalt (z. B. ein sendender Knoten des Echtzeit-Steuerungsnetzwerks) oder einen Empfänger oder Abonnent einer oder mehrerer Arten von Dateninhalten (z. B. ein empfangender Knoten des Echtzeit-Steuerungsnetzwerks) identifiziert. Damit kann das Bestimmen des Abonnenten (Block 408) auf der eindeutigen Kennung des von dem Feldgerät erzeugten (und von dem I/O-Knoten abonnierten) Dateninhalts und/oder auf der eindeutigen Kennung des Knotens, der den vom Feldgerät (bei dem es sich um das Feldgerät selbst oder einen dazwischenliegenden Knoten handeln kann, der Teil des Echtzeit-Steuerungsnetzwerks ist und sich zwischen dem Feldgerät und dem I/O-Knoten befindet) erzeugten Dateninhalt veröffentlicht hat, basieren. Der Satz eindeutiger Kennungen kann jegliche geeignete Form aufweisen, beispielsweise die eines Tags oder einer alphanumerischen Kombination von Symbolen, und kann basierend auf einer oder mehreren Systemkonfigurationsdatenbanken des Prozessleitsystems festgelegt oder definiert werden, z. B. während der Inbetriebnahme und/oder Konfiguration eines damit verbundenen Datentyps, Geräts, Knotens oder einer anderen identifizierten Komponente oder Gruppe von Komponenten, die in einer oder mehreren Systemkonfigurationsdatenbanken definiert sind. Beispielsweise kann der VMN 300 den Satz eindeutiger Kennungen während der Konfiguration des I/O-Knotens definieren. Bei dem Satz eindeutiger Kennungen kann es sich um die genauen Kennungen, Tags, Namen usw., wie sie in den Systemkonfigurationsdatenbanken verwendet oder referenziert werden, handeln oder nicht; der Satz eindeutiger Kennungen muss nur innerhalb des I/O-Knotens eindeutig sein. Bei einigen Ausführungsformen ist der Satz eindeutiger Kennungen beispielsweise innerhalb des Echtzeit-Steuerungsnetzwerks und/oder innerhalb des MPDSC 10 eindeutig.
-
Bei einigen Ausführungsformen kann der I/O-Knoten einen Satz von Datensätzen verwalten oder Zugriff auf diesen haben, den die I/O zum Bestimmen des abonnierenden Knotens (Block 408) verwendet. Beispielsweise kann jeder Datensatz eine Zuordnung zwischen einem jeweiligen Dateninhalt und mindestens einem aus einem jeweiligen Veröffentlicher des Dateninhalts (oder optional einer Angabe des Dateninhalts) oder einem jeweiligen Abonnenten des Dateninhalts (oder optional einer Angabe des Dateninhalts) angeben. Der Datensatz kann bei der Anforderung, Genehmigung, Löschung, Änderung usw. von Abonnements aktualisiert und/oder verwaltet werden. In der Regel, aber nicht notwendigerweise, können der jeweilige Dateninhalt, die jeweiligen Veröffentlicher und die jeweiligen Abonnenten, die in dem Satz von Datensätzen angegeben sind, durch ihre jeweiligen eindeutigen Kennungen oder Tags identifiziert werden.
-
Wie weiterhin in 6 dargestellt, beinhaltet das Ausführen des Prozessregelkreises (Block 402) das Veröffentlichen einer zweiten Veröffentlichung im Echtzeit-Steuerungsprotokoll (Block 410) durch den I/O-Knoten, wobei die zweite Veröffentlichung den vom Feldgerät erzeugten Dateninhalt angibt. Beispielsweise kann der I/O-Knoten basierend auf der Bestimmung des Abonnenten von dem Feldgerät zugeordneten Veröffentlichungen zweite Daten erzeugen, die den bezogenen Dateninhalt anzeigen, der von dem Feldgerät erzeugt wurde, und kann die zweiten Daten veröffentlichen (Block 410), wodurch bewirkt wird, dass Abonnenten der veröffentlichten zweiten Daten die zweite Veröffentlichung beziehen. Beispielsweise kann der der Prozesssteuerung entsprechende, zweite Knoten ein den vom Feldgerät erzeugten Dateninhalt betreffendes Abonnement haben und kann die zweite Veröffentlichung, die vom I/O-Knoten basierend auf dem Abonnement des zweiten Knotens veröffentlicht wird, beziehen. Bei dem zweiten Knoten kann es sich um die Prozesssteuerung selbst handeln; beispielsweise kann die Prozesssteuerung dem virtuellen Knoten 30a oder dem physischen Knoten 40a aus 1 ähneln. In einigen Situationen kann es sich bei dem der Prozesssteuerung entsprechenden, zweiten Knoten um einen dazwischenliegender Knoten handeln, der sich zwischen dem I/O-Knoten und der Prozesssteuerung befindet, wobei der dazwischenliegende Knoten den vom Feldgerät erzeugten Dateninhalt unter Verwendung eines der Prozesssteuerung nativen Protokolls an die Prozesssteuerung übermittelt. Zum Beispiel und erneut auf 1 bezugnehmend kann die Prozesssteuerung dem physischen Knoten PNg ähneln und ihre jeweiligen dazwischenliegenden Knoten können dem Knoten 42b ähneln. Natürlich können auch andere Knoten des Echtzeit-Steuerungsnetzwerks, die Abonnements, die den vom Feldgerät erzeugten Daten entsprechen, haben, die zweite Veröffentlichung beziehen, selbst wenn solche anderen Knoten nicht Teil des Prozessregelkreises sind. Beispielsweise können Knoten, die Benutzeroberflächen, Analysen, Simulationen, Diagnosen usw. entsprechen, Abonnenten der zweiten Veröffentlichung sein.
-
Insbesondere bewirkt das Ausführen des Prozessregelkreises (Block 402) unter Verwendung des I/O-Knotens und entsprechender Veröffentlichungs-/Abonnementmechanismen, wie in Bezug auf die Blöcke 405, 408, 410 erörtert, dass der Dateninhalt, der von dem Feldgerät während der Ausführung des Prozessregelkreises während des Laufzeitbetriebs der industriellen Prozessanlage erzeugt wird, über den I/O-Knoten und unter Verwendung des Echtzeit-Steuerungsprotokolls innerhalb einer maximalen Übertragungsverzögerungstoleranz bereitgestellt wird, die der Bereitstellung von Echtzeit-Prozessdaten zwischen dem Feldgerät und der Prozesssteuerung (Block412) entspricht. Anschließend führt ein Komponentenverhaltensmodul (CBM) der Prozesssteuerung als (nicht in 6 gezeigter) Teil der Laufzeitausführung des Prozessregelkreises auf den vom Feldgerät erzeugten empfangenen Daten Operationen aus, erzeugt basierend auf der Operation ein entsprechendes Steuersignal und bewirkt, dass das Steuersignal an eine andere Prozesssteuervorrichtung (z. B. eine andere Steuerung, ein anderes Feldgerät usw.) gesendet wird, um damit den zumindest einen Teil des industriellen Prozesses zu steuern.
-
In einigen Szenarien handelt es sich bei der Prozesssteuerung des Verfahrens 400 um eine virtuelle Prozesssteuerung, die sich in einer virtuellen Umgebung der industriellen Prozessanlage befindet. Das CBM der virtuellen Prozesssteuerung kann die von dem Feldgerät erzeugten Daten über die residente Veröffentlichungs-/Abonnement-Schicht der virtuellen Prozesssteuerung, z. B. auf ähnliche Weise wie der virtuelle Knoten 52b aus 2, von dem Echtzeit-Steuerungsnetzwerk beziehen. Alternativ kann das CBM der virtuellen Prozesssteuerung die von dem Feldgerät erzeugten Daten über die residente Veröffentlichungs-/Abonnement-Schicht und eine residente virtuelle PIO-Schicht der virtuellen Prozesssteuerung, z. B. auf ähnliche Weise wie der virtuelle Knoten 52a aus 2, von dem Echtzeit-Steuerungsnetzwerk beziehen.
-
In einigen Szenarien handelt es sich bei der Prozesssteuerung des Verfahrens 400 um eine physische Prozesssteuerung, die sich in der physischen Umgebung der industriellen Prozessanlage befindet. Bei einigen Ausführungsformen handelt es sich bei der physischen Prozesssteuerung um einen Knoten des Echtzeit-Steuerungsnetzwerks. Das heißt, die Prozesssteuerung kann eine jeweilige Veröffentlichungs-/Abonnement-Schicht enthalten, über die Abonnements bei der Prozesssteuerung empfangen und Veröffentlichungen von der Prozesssteuerung gesendet werden. Beispielsweise kann die Prozesssteuerung dem physischen Knoten 40a aus 1 ähneln. Bei diesen Ausführungsformen kann das CBM der physischen Prozesssteuerung die von dem Feldgerät erzeugten Daten von dem Echtzeit-Steuerungsnetzwerk über die residente Veröffentlichungs-/Abonnement-Schicht der physischen Prozesssteuerung (und optional auch über das residente virtuelle PIO-Subsystem der physischen Prozesssteuerung) beziehen.
-
Bei anderen Ausführungsformen ist die physische Prozesssteuerung kommunikativ mit einem dazwischenliegenden Knoten verbunden, bei dem es sich um einen Knoten des Echtzeit-Steuerungsnetzwerks handelt. Zum Beispiel und erneut auf 1 bezugnehmend kann die Prozesssteuerung dem physischen Knoten PNg ähneln und ihre jeweiligen dazwischenliegenden Knoten können dem Knoten 42b ähneln. Der dazwischenliegende Knoten kann die vom Feldgerät erzeugten Daten über die residente Veröffentlichungs-/Abonnement-Schicht des dazwischenliegenden Knotens (und optional das residente virtuelle PIO-Subsystem des dazwischenliegenden Knotens) vom Echtzeit-Steuerungsnetzwerk beziehen und der dazwischenliegende Knoten kann die vom Feldgerät erzeugten Daten unter Verwendung einer Kommunikationsschnittstelle zu einer oder mehreren Verbindungen und/oder Netzwerken der physischen Umgebung der industriellen Prozessanlage der Prozesssteuerung bereitstellen, wobei sich eine oder mehrere physische Verbindungen/Netzwerke von dem Echtzeit-Steuerungsnetzwerk unterscheiden und wobei die physischen Verbindungen/Netzwerke in der Regel eine andere Art von Prozesssteuerungsnetzwerk enthalten, das ein standardisiertes industrielles Steuerungsprotokoll und/oder eine solche Plattform verwendet (z. B. HART, WirelessHART, Fieldbus, Profibus usw.) und/oder eine andere Art von Kommunikationsnetzwerk, das ein standardisiertes Kommunikationsprotokoll und/oder eine solche Plattform verwendet (z. B. Ethernet, Advanced Physical Layer, Wi-Fi usw.). Von der physischen Prozesssteuerung ausgehende und an ein Empfängergerät oder einen Empfängerknoten gesendete Kommunikation (z. B. ein Steuersignal, das aus dem CBM der physischen Prozesssteuerung resultiert, das auf den vom Feldgerät erzeugten, empfangenen Daten Operationen ausführt) kann dem Empfängergerät oder Empfängerknoten von der Prozesssteuerung über eine oder mehrere geeignete Verbindungen/Netzwerke bereitgestellt werden, z. B. über den dazwischenliegenden Knoten und das Echtzeit-Steuerungsnetzwerk, über die physische Verbindung/das physische Netzwerk, die/das den dazwischenliegenden Knoten und die physische Prozesssteuerung miteinander verbindet, über eine andere geeignete Kommunikationsverbindung oder ein solches Netzwerk innerhalb der physischen Umgebung der industriellen Prozessanlage usw.
-
Unabhängig davon, ob es sich bei der Prozesssteuerung um eine virtuelle oder eine physische Prozesssteuerung handelt, kann der I/O-Knoten einen I/O-Switch, wie den I/O-Switch 25, enthalten. Bei einigen Ausführungsformen kann der I/O-Knoten nur (z. B. ausschließlich) virtuelle Knoten (ob virtuelle Laufzeitknoten und/oder simulierte Knoten) kommunikativ miteinander verbinden. Bei einigen Ausführungsformen kann der I/O-Knoten nur (z. B. ausschließlich) physische Knoten (ob z. B. die physischen Knoten selbst und/oder die in dem Echtzeit-Steuerungsnetzwerk enthaltenen, jeweiligen dazwischenliegenden Knoten) kommunikativ miteinander verbinden. Bei einigen Ausführungsformen kann der I/O-Knoten sowohl virtuelle als auch physische Knoten kommunikativ miteinander verbinden.
-
Allgemein ausgedrückt kann der I/O-Knoten einen Satz von computerausführbaren Anweisungen umfassen, die in den Speichern einer oder mehrerer Rechenvorrichtungen gespeichert sind. Bei einigen Ausführungsformen kann mindestens ein Teil des I/O-Knotens unter Verwendung einer Virtualisierung implementiert werden, beispielsweise einer virtuellen Maschine, eines Containers oder einer anderen geeigneten Art der Virtualisierung. Bei einigen Ausführungsformen umfasst der I/O Knoten auch die eine oder die mehreren Rechenvorrichtungen oder die Hardware, auf denen die computerausführbaren Anweisungen (die eine oder mehrere Virtualisierungen enthalten können oder nicht) gespeichert und ausgeführt werden. Daher kann der I/O Knoten problemlos konfiguriert und neu konfiguriert werden, um aktuelle und/oder vorhergesagte Netzwerkbedingungen (z. B. im Echtzeit-Steuerungsnetzwerk), wie Kapazität, Bandbreite und/oder Ressourcennutzung (die z. B. Software- und/oder Hardwareressourcennutzung einschließen kann), zu unterstützen. Somit kann das Echtzeit-Steuerungsprotokoll problemlos so angepasst werden, dass die aktuelle und/oder vorhergesagte Netzwerkkapazität, -bandbreite und/oder -ressourcennutzung berücksichtigt wird, beispielsweise durch Modifizieren der Zeitsteuerung der Paketzustellung, Anpassen der Ressourcen, die zum Zustellen von Paketen verwendet werden, usw.
-
Der I/O-Knoten kann mindestens einige physische I/O-Ports verschiedener Typen enthalten, die von den mehreren anderen Knoten des Echtzeit-Steuerungsnetzwerks gemeinsam genutzt werden können, um mit anderen Geräten als den Knoten des Echtzeit-Zeitsteuerungsnetzwerks über andere Verbindungen und/oder Netzwerke als das Echtzeit-Steuerungsnetzwerk zu kommunizieren. Beispielsweise kann der I/O-Knoten ein oder mehr physische I/O-Geräte, - Komponenten und/oder -Systeme (z. B. I/O-Karten, -Klemmenblöcke usw.) enthalten, von denen jedes eine entsprechende Anzahl von physischen I/O-Ports zur Unterstützung physischer Schnittstellen zu anderen Verbindungen, Netzwerken und/oder Geräten und zur Unterstützung von Protokollen, die von anderen Verbindungen, Netzwerken und/oder Geräten verwendet werden, aufweist. Die Gesamtzahl der physischen I/O-Ports des I/O-Knotens ist jedoch gegenüber Prozessleitsystemen, die keinen solchen I/O-Knoten enthalten, stark reduziert. In der Regel ist die Gesamtzahl der vom I/O-Knoten bereitgestellten physischen I/O-Ports geringer als die Gesamtzahl der Knoten, die (mit dem I/O-Knoten) im Echtzeit-Steuerungsnetzwerk enthalten sind.
-
In Anbetracht des vorstehend Ausgeführten bieten die neuartige Mehrzweckplattform für dynamische Simulation und die Laufzeitsteuerungsplattform 10 zahlreiche Vorteile gegenüber bekannten Prozessleitsystemen. Da beispielsweise die MPDSC-Plattform 10 sowohl die Simulation als auch die Laufzeitsteuerung über virtuelle Komponenten unterstützt, kann das Testen von Änderungen (z. B. Upgrades, Patches usw.) in der virtuellen Umgebung 12 über eine simulierte Komponente durchgeführt werden und nach zufriedenstellendem Durchprüfen kann die simulierte Komponente leicht als virtuelle Komponente der Prozessanlage 100 aktiviert werden (z. B. „Load, Evaluate, Go“ (Laden, Auswerten, Loslegen), stoßfreie oder warme Umschaltungen usw.). Dadurch kann die Umschaltung von simulierten Komponenten auf Laufzeitkomponenten einfacher durchgeführt werden und Ausfallzeiten aufgrund von Upgrades, Patches und geplanter Wartung können reduziert werden. Darüber hinaus wird die Menge an Ressourcen, die verwendet werden, um virtualisierte Ersatzteile verschiedener Komponenten bereitzustellen und die virtualisierten Ersatzteile während Ausfall- oder Fehlerszenarien online zu schalten, erheblich reduziert.
-
Ferner ermöglicht die Bereitstellung von virtuellen Laufzeitkomponenten durch die MPDS-Plattform 10 die Unabhängigkeit zwischen Hardware und Software innerhalb der Anlage 100. Beispielsweise kann eine Steuerungssoftware, die zur Laufzeit des Prozessleitsystems 100 verwendet wird, in virtuellen Laufzeitsteuerungen aktualisiert werden, ohne dass eine physische Steuerungshardware aktualisiert oder geändert werden muss. Auf ähnliche Weise ermöglicht die MPDS-Plattform 10 aufgrund der Hardware-/Softwareunabhängigkeit, dass die Hardware der Prozessanlage 100 unabhängig von Software-Upgrades aktualisiert wird.
-
Die Bereitstellung von virtuellen Laufzeitkomponenten und deren Administration und/oder Verwaltung (z. B. über den VMS 300 der MPDSC-Plattform 10) ermöglicht jedoch auch eine einfache und kostengünstigere Skalierbarkeit des Systems, da zusätzliche virtuelle Komponenten problemlos innerhalb der virtuellen Umgebung 12 implementiert werden können, ohne dass verschiedene physische Hardwarekomponenten und erforderliche Schränke, Verdrahtungen usw. bezahlt, installiert, getestet, in Betrieb genommen und geprüft werden müssen. In der Tat können, wenn zusätzliche virtuelle Komponenten zur Unterstützung des Systems 100 benötigt werden, virtuelle Komponenten nach Bedarf bis zu den Verarbeitungs- und/oder Speichergrenzen der physischen Rechenvorrichtungen und/oder Hardware, auf denen die virtuelle Umgebung 12 implementiert ist, erstellt werden, wonach zusätzliche physische Rechenvorrichtungen und/oder Hardware einfach hinzugefügt werden können.
-
Die von der MPDS-Plattform 10 bereitgestellte virtuelle Umgebung 12 ermöglicht die Erstellung digitaler Zwillinge verschiedener Komponenten und/oder die virtuelle Simulation der gesamten Prozessanlage 100, z. B. für Tests, Ersatzteile, Upgrades, Patches, geplante Wartungsarbeiten und/oder andere Zwecke. Digitale Zwillinge (z. B. bestimmter Komponenten und der gesamten Prozessanlage 100) können im Gleichschritt mit Aktualisierungen ihrer jeweiligen bestimmten physischen Komponente(n) aktualisiert werden. Das heißt, Statusinformationen können über die MPDSC-Plattform 10 vom/von den physischen Knoten zum/zu den virtuellen Knoten übertragen werden. In der Tat bietet die MPDSC-Plattform 10 ein verbessertes Online-Testen von Änderungen und/oder verschiedenen Szenarien (z. B. „Was-wäre-wenn“-Szenarien) und in einigen Situationen in Verbindung mit virtuellen und/oder physischen Laufzeitkomponenten des Prozessanlage 100. Aufgrund der Architektur und Verwendung der gemeinsamen MPDS-Plattform 10 (und insbesondere der virtuellen Umgebung 12 der MPDS-Plattform 10) für Simulations- und Laufzeitsteuerungszwecke kann die Off-Simulation ohne Konfigurationsänderungen problemlos durchgeführt werden.
-
Da die MPDS-Plattform 10 darüber hinaus die I/O der Prozessanlage 100 so abstrahiert, dass sie nicht mehr direkt mit einer bestimmten Hardware konkret verknüpft ist, ist die I/O-Konfiguration innerhalb der Anlage 100 flexibler und kann nicht nur während der Laufzeit, sondern auch während Upgrades, Wartungen, Ausfällen und dergleichen leicht geändert und adaptiert werden. Bezeichnenderweise sind Kommunikationsverbindungen zwischen I/O-Geräten und anderen Komponenten (z. B. CIOC und Steuerungen) nicht mehr durch physische Ports beschränkt, die auf physischen I/O-Geräten verfügbar sind. Da I/O innerhalb der MPDS-Plattform 10 abstrahiert werden, ist eine beliebige Anzahl von Kommunikationsverbindungen zwischen einem virtuellen I/O-Gerät und anderen Komponenten bis zu den Verarbeitungs- und/oder Speichergrenzen der physischen Rechenvorrichtungen und/oder Hardware, auf denen die virtuelle Umgebung 12 implementiert ist, logisch möglich, wonach zusätzliche physische Rechenvorrichtungen und/oder Hardware einfach dazugefügt werden können. In ähnlicher Weise können aufgrund der Abstraktion von I/O innerhalb der MPDS-Plattform 10 Steuermodule und/oder andere CBM 58 jedem virtuellen Hostgerät oder jeder virtuellen Hostkomponente zugewiesen werden, ohne dass der I/O-Standort und/oder das Laden des Hostgeräts oder der Host-Komponente berücksichtigt werden müssen, wie dies bei Verwendung von physischen Hostgeräten oder Host-Komponenten erforderlich ist. Das heißt, wie zuvor erläutert, können virtuelle Komponenten (ob zur Simulation oder zur Laufzeitsteuerung verwendet) unter Verwendung von I/O von physischen Komponenten oder von anderen virtuellen Komponenten betrieben werden. Als solches ist die MPDS-Plattform 10 in der Lage, Redundanz, Wiederholungsversuche und andere Mechanismen, die gegenwärtig an bestimmte Implementierungen innerhalb derzeit bekannter Techniken gebunden sind, zu abstrahieren (z. B. unter Verwendung des I/O-Switches 25), so dass die Abstraktionen übergreifend für mehrere unterschiedliche Typen von Anwendungen, Szenarien und Implementierungen verwendet werden können , z. B. mit ausgewählter Anpassung und Spezialisierung verschiedener Abstraktionen für bestimmte Implementierungen und/oder Anwendungen. Folglich kann die MPDS-Plattform 10 viel mehr Anzahlen und Typen von I/O-Systemen (im Vergleich zu derzeit bekannten Techniken) auf konsistente und leicht skalierbare Weise unterstützen.
-
Bei der Implementierung in Software können alle hier beschriebenen Anwendungen, Dienste, virtuellen Vorrichtungen, vertikalen Maschinen, virtuellen Einheiten usw. in jedem materiellen, nicht vorübergehenden, computerlesbaren Speicher gespeichert werden, wie beispielsweise auf einer Magnetplatte, einer Laserplatte, einer Halbleiterspeichervorrichtung, einer molekularen Speichervorrichtung oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. Obwohl die hier offenbarten Beispielsysteme als neben anderen Komponenten auch Software und/oder Firmware, die auf Hardware ausgeführt wird, enthaltend offenbart werden, ist zu beachten, dass diese Systeme lediglich illustrativ sind und nicht als einschränkend betrachtet werden sollten. Zum Beispiel wird in Betracht gezogen, dass beliebige oder alle dieser Hardware-, Software- und Firmware-Komponenten ausschließlich in Hardware, ausschließlich in Software oder in beliebiger Kombination von Hardware und Software ausgeführt werden können. Dementsprechend werden die hier beschriebenen Systembeispiele zwar als in Software implementiert beschrieben, die auf einem Prozessor eines oder mehrerer Rechenvorrichtungen ausgeführt wird, aber der Fachmann wird leicht verstehen, dass die angegebenen Beispiele nicht die einzige Möglichkeit sind, solche Systeme zu implementieren.
-
Während also die vorliegende Erfindung anhand konkreter Beispiele beschrieben wurde, die nur zur Veranschaulichung und nicht zur Beschränkung der Erfindung gedacht sind, ist es dem Fachmann offensichtlich sein, dass Änderungen, Ergänzungen oder Löschungen an den offengelegten Ausführungsformen vorgenommen werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 62859508 [0001]
- US 7684875 [0047]
- US 8332567 [0047]
- US 8762618 [0047]
- US 8977851 [0047]
- US 9083548 [0047]
- US 9411769 [0047]
- US 9495313 [0047]
- US 9946240 [0047]