DE102020124789A1

DE102020124789A1 - Hyperkonvergente architektur für industrieleitsystem

Info

Publication number: DE102020124789A1
Application number: DE102020124789.3A
Authority: DE
Inventors: Gary K. Law; Nina Golder; Aaron Crews; Robert G. III Halgren; Claudio Fayad
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2019-09-23
Filing date: 2020-09-23
Publication date: 2021-03-25
Also published as: JP2021057033A; GB202014107D0; US20210089015A1; GB2589710B; US11846934B2; GB2589710A; CN112540578A

Abstract

Eine hyperkonvergente industrielle Prozesssteuerungsarchitektur zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung unter Verwendung einer softwaredefinierten verteilten Steuersystem(DCS)-Umgebung wird offenbart. Die softwaredefinierte DCS-Umgebung kann implementiert werden, indem die Hardwarekomponenten einer DCS-Architektur auf einer Servergruppe virtualisiert werden, um sowohl softwaredefinierte Prozesssteuerungen als auch Back-End-DCS-Anwendungen innerhalb der Servergruppe ausführen zu können. Diese softwaredefinierte DCS-Netzwerkarchitektur verringert die Hardwareanforderungen des Prozessleitsystems und verringert die Komplexität der Konfiguration, indem Steuerungskomponenten und übergeordnete Komponenten in einer gemeinsamen Umgebung innerhalb der Servergruppe implementiert werden.

Description

TECHNISCHES GEBIET
Diese Patentanmeldung bezieht sich allgemein auf Industrie- und Prozessleitsysteme und insbesondere auf ein industrielles Steuerungssystem, das eine Laufzeitsteuerung unter Verwendung von softwaredefinierter Architektur bereitstellt.
HINTERGRUND
Prozess- oder Industrieleitsysteme, wie sie in Chemie-, Erdöl- 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 drahtloses Netzwerk kommunikativ mit einem oder mehreren Feldgeräten gekoppelt sind. Die Feldgeräte, wobei es sich z. B. um Ventile, Ventil-Stellungsregler, Schalter und Sender (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 dem bekannten FOUNDATION® Fieldbus-Protokoll entsprechen, können auch Steuerberechnungen, Alarmierungsfunktionen und andere Steuerfunktionen ausführen, die üblicherweise in der Steuerung implementiert sind. Die Prozesssteuerungen, die dezentral 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® Feldbusfeldgeräte. Die Steuermodule in der Steuerung senden die Steuersignale über die Kommunikationsleitungen oder Verknüpfungen zu den Feldgeräten, um so den Betrieb mindestens eines Anteils 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 zu einem oder mehreren anderen Hardwaregeräten, wie z. B. Bedienerarbeitsplätzen, PCs oder Computergeräten, Data-Historians, Berichtgeneratoren, zentralisierten Datenbanken oder anderen zentralisierten administrativen Computergeräten bereitgestellt, die in der Regel in Steuerungsräumen oder an anderen Orten entfernt von der raueren Anlagenumgebung platziert werden. Jedes dieser Hardware-Geräte ist in der Regel über die gesamte Prozessanlage oder einen Anteil der Prozessanlage hinweg zentralisiert. Diese Hardwaregeräte führen Anwendungen aus, die es beispielsweise einem Ingenieur ermöglichen, Abschnitte 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 drahtgebunden Kommunikationsweg, einen drahtlosen Kommunikationsweg oder eine Kombination aus drahtgebundenen und drahtlosen Kommunikationswegen beinhalten.
Das von Emerson Process Management vertriebene DeltaV™-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 in einer oder mehreren Arbeitsstationen oder Computervorrichtungen untergebracht ist, ermöglicht Benutzern das Erstellen oder Ändern von Prozessregelmodulen und das Herunterladen dieser Prozessregelmodule über eine Datenautobahn auf dedizierte dezentrale Steuerungen. 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 Eingängen ausführt und die Ausgänge 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 Daten an einen Bediener anzuzeigen, und dem Bediener zu ermöglichen, Einstellungen, wie beispielsweise Sollwerte, innerhalb der Prozesssteuerungsroutinen zu ändern. Jede dedizierte Steuerung und in einigen Fällen ein oder mehrere Feldgeräte speichern und führen eine entsprechende Steuerungsanwendung aus, die die ihr zugeordneten und heruntergeladenen Steuerungsmodule ausführt, um die eigentliche Prozesssteuerungsfunktionalität umzusetzen. Die Betrachtungsanwendungen, die auf einem oder mehreren Bedienerarbeitsplätzen (oder auf einem oder mehreren Remote-Computergeräten in kommunikativer Verbindung mit den Bedienerarbeitsplätzen und der Datenautobahn) ausgeführt werden können, empfangen Daten von der Steuerungsanwendung über die Datenautobahn und zeigen diese Daten den Prozessleitsystementwicklern, den Bedienern oder den Benutzern, die die Benutzerschnittstellen verwenden, an. Sie bieten eine Reihe von verschiedenen Ansichten, wie z. B. die Ansicht eines Bedieners, eines Ingenieurs, eines Technikers usw. Eine Data-Historian-Anwendung wird normalerweise in einem Data-Historian-Gerät gespeichert und ausgeführt, das einige oder alle über die Datenautobahn bereitgestellten Daten sammelt und speichert, während eine Konfigurationsdatenbank-Anwendung in einem weiteren, an die Datenautobahn angeschlossenen Computer laufen kann, um die aktuelle Konfiguration der Prozesssteuerungsroutine und die damit verbundenen Daten zu speichern. Alternativ kann sich die Konfigurationsdatenbank auf der gleichen Arbeitsstation wie die Konfigurationsanwendung befinden.
Die Architektur von derzeit bekannten Prozesssteuerungsanlagen und Prozessleitsystemen wird stark durch begrenzten Steuerungs- und Gerätespeicher, begrenzte Kommunikationsbandbreite sowie Steuerungs- und Geräteprozessorfähigkeit beeinflusst. In derzeit bekannten Prozessleitsystemarchitekturen wird beispielsweise die Verwendung von dynamischem und statischem nichtflüchtigem Speicher in den Steuerungen in der Regel minimiert oder mindestens sorgfältig verwaltet. Infolgedessen muss ein Benutzer bei der Systemkonfiguration (z. B. a priori) typischerweise 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, oft nicht archiviert, und wenn sie gesammelt werden, 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 ausgewählte Daten, die archiviert oder gespeichert werden sollen (wie in der Konfiguration des Steuerung angegeben), an die Arbeitsstation oder das Rechengerät zur Speicherung bei einem geeigneten Data-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 Probenahme beim Historian oder Silo ist die Datenerfassung und Zeitstempelung zudem oft nicht mit dem eigentlichen Prozess synchronisiert.
Ebenso bleiben in Chargen-Prozessleitsystemen, um den Speicherverbrauch der Steuerung zu minimieren, Chargenrezepte und Schnappschüsse der Steuerungskonfiguration typischerweise an einem zentralen administrativen Computergerät oder -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 in der Steuerung und in der Kommunikation zwischen der Arbeitsstation oder der zentralen Verwaltungscomputeranordnung und der Steuerungen.
Ferner ist die aktuelle Architektur von Industrieleitsystemen wie etwa Prozessleitsystemen weitgehend hardwaregesteuert, da verschiedene Funktionen wie etwa Steuerungsfunktionen, Ein-/Ausgabefunktionen (I/O), Benutzeroberflächenfunktionen usw. auf bestimmter Hardware (z. B. Benutzerarbeitsplätzen oder Schnittstellengeräten, Prozesssteuerungen, 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 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) auf bestimmte Weise konfiguriert werden muss.
Darüber hinaus trennt die aktuelle Steuerungssystemarchitektur die Online-Prozesssteuerungsanwendungen und andere verwandte Anwendungen in mehrere funktionsspezifische Geräte, die über ein Kommunikationsnetz für Prozessanlagen kommunizieren. Prozessleitsysteme erfordern daher zusätzliche Hardwaregeräte, die separat konfiguriert werden müssen, um mit anderen Geräten zu kommunizieren, mit denen sie interagieren. Zum Beispiel kann das Ersetzen oder Neukonfigurieren eines Feldgeräts innerhalb der Prozessanlage die Neukonfiguration mehrerer Steuerungen, die mit dem Feldgerät interagieren, sowie mehrerer Arbeitsstationen und übergeordneter Anwendungen, die Daten überwachen, welche einem solchen Feldgerät zugeordnet sind, erfordern.
KU RZDARSTELLU NG
Hierin wird eine hyperkonvergente verteilte Steuersystem(Distributed Control System - DCS)-Architektur für industrielle Prozesssteuerung beschrieben, die softwaredefinierte Prozesssteuerungen und verwandte Anwendungen in einer kombinierten softwaredefinierten DCS-Umgebung implementiert. Die softwaredefinierte DCS-Umgebung kann die Hardwarekomponenten einer DCS-Architektur in einem softwaredefinierten virtuellen Netzwerk virtualisieren, das auf Standardhardwarekomponenten ausgeführt wird, sodass diese Komponenten als Softwarekomponenten verwaltet werden können. Eine solche softwaredefinierte DCS-Umgebung kann innerhalb einer Servergruppe implementiert werden, beispielsweise in einem privat gehosteten Cloud-Computing-System, wodurch sowohl die Hardwareanforderungen des Systems als auch die zum Einrichten des Systems erforderliche Konfiguration reduziert werden. Hierin werden Systeme, Verfahren und computerlesbare Medien mit darauf gespeicherten ausführbaren Anweisungen zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung beschrieben. Diese Systeme, Verfahren und Anweisungen können eine Servergruppe enthalten oder von dieser implementiert werden, die konfiguriert ist, eine softwaredefinierte DCS-Umgebung zu implementieren, umfassend eine oder mehrere softwaredefinierte Prozesssteuerungen, die konfiguriert sind, mindestens einen Teil des industriellen Prozesses durch Kommunikation mit mehreren Feldgeräten innerhalb der physischen Prozessumgebung in Echtzeit zu steuern; und eine oder mehrere DCS-Anwendungen, die für die Interaktion mit den softwaredefinierten Prozesssteuerungen konfiguriert sind.
Die Servergruppe enthält mehrere Servergeräte, die zusammen arbeiten, um die softwaredefinierte DCS-Umgebung zu implementieren. In manchen Ausführungsformen ist die Servergruppe über eine oder mehrere Eingabe/Ausgabe(input/output - I/O)-Verbindungen, die konfiguriert sind, Prozessdaten über ein Prozesssteuerungsnetzwerk unter Verwendung eines industriellen Prozesssteuerungskommunikationsprotokolls zu kommunizieren, mit den mehreren Feldgeräten verbunden. In weiteren Ausführungsformen umfasst die softwaredefinierte DCS-Umgebung ferner eine oder mehrere virtuelle Netzwerkkomponenten, die konfiguriert sind, eine oder mehrere der folgenden physischen Netzwerkkomponenten zu replizieren: Netzwerk-Switches, Router oder Firewalls.
In manchen Ausführungsformen ist mindestens eine der DCS-Anwendungen konfiguriert, den Betrieb der softwaredefinierten Prozesssteuerungen anzupassen. In weiteren Ausführungsformen können die DCS-Anwendungen verschiedene Funktionen innerhalb der softwaredefinierten DCS-Umgebung bereitstellen. Die DCS-Anwendungen können eine Konfigurationsanwendung für eine virtuelle Architektur mit einer Benutzerschnittstelle umfassen, die konfiguriert ist, es einem Benutzer zu ermöglichen, eine virtuelle DCS-Netzwerkarchitektur zu definieren, indem mehrere virtuelle Knoten innerhalb der virtuellen DCS-Netzwerkarchitektur und Verbindungen zwischen den virtuellen Knoten spezifiziert werden. Diese virtuellen Knoten können virtuelle Darstellungen der mehreren Feldgeräte enthalten. Zusätzlich oder alternativ dazu können DCS-Anwendungen ferner eine Data-Historian-Anwendung enthalten, die konfiguriert ist, Prozessdaten innerhalb der softwaredefinierten DCS-Umgebung während des Betriebs des industriellen Prozesses automatisch zu speichern. In noch weiteren Ausführungsformen können DCS-Anwendungen eine oder mehrere der folgenden Funktionen umfassen: eine Bedienerschnittstelle, eine Engineering-Workstation, ein Anlagenverwaltungssystem, ein Fertigungsausführungssystem oder ein modernes Prozessleitsystem. In noch weiteren Ausführungsformen können die DCS-Anwendungen ein Netzwerk-Gateway zum Kommunizieren mit externen Datennetzen enthalten.
In weiteren Ausführungsformen kann die Servergruppe konfiguriert sein, einen Lastenausgleich oder eine Redundanz unter Verwendung der mehreren Servergeräte bereitzustellen. In diesen Ausführungsformen enthalten die eine oder die mehreren softwaredefinierten Prozesssteuerungen mehrere Instanzen von virtuellen DCS-Steuerungen, die gleichzeitig auf verschiedenen Servergeräten der Servergruppe ausgeführt werden. Die Servergruppe kann demnach konfiguriert sein, einen automatischen Lastenausgleich zwischen den mehreren Instanzen der virtuellen DCS-Steuerungen basierend auf den Status der mehreren Servergeräte in der Servergruppe durchzuführen. In weiteren Ausführungsformen können die DCS-Anwendungen eine Anwendung umfassen, die konfiguriert ist, eine optimale Anzahl von Servergeräten der Servergruppe basierend auf der Ressourcennutzung der Servergruppe und der Ressourcenverfügbarkeit der mehreren Servergeräte vorherzusagen.
Nach einem Aspekt der Systeme, Verfahren und computerlesbaren Medien mit darauf gespeicherten ausführbaren Anweisungen zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung können Techniken zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung Folgendes umfassen: (i) Verbinden mehrerer Feldgeräte innerhalb der physischen Prozessumgebung mit einer Servergruppe, die mehrere Servergeräte umfasst, die konfiguriert sind, eine softwaredefinierte Prozessleitsystem(DCS)-Umgebung zu implementieren, über eine oder mehrere I/O-Verbindungen; (ii) Steuern mindestens eines Teils des industriellen Prozesses durch Kommunikation mit den mehreren Feldgeräten innerhalb der physischen Prozessumgebung in Echtzeit dadurch, dass eine oder mehrere softwaredefinierte Prozesssteuerungen, in der softwaredefinierten DCS-Umgebung auf der Servergruppe ausgeführt werden; und (iii) Anpassen des Betriebs der einen oder der mehreren softwaredefinierte Prozesssteuerungen durch eine oder mehrere DCS-Anwendungen, die in der softwaredefinierten DCS-Umgebung auf der Servergruppe ausgeführt werden und konfiguriert sind, mit den softwaredefinierten Prozesssteuerungen zu interagieren.
Die Servergruppe kann Prozessdaten von den mehreren Feldgeräten über die eine oder die mehreren I/O-Verbindungen empfangen und Prozesssteuersignale an die mehreren Feldgeräte senden, um den Teil des industriellen Prozesses über die eine oder die mehreren I/O-Verbindungen zu steuern. In manchen Ausführungsformen können die DCS-Anwendungen basierend auf dem Datenverkehr an der einen oder den mehreren I/O-Verbindungen einen Typ von Prozessdaten erfassen, die einem Feldgerät der mehreren Feldgeräten zugeordnet sind, und eine Anpassung an den Betrieb des einen oder der mehreren softwaredefinierte Prozesssteuerungen basierend auf dem Typ der Prozessdaten bestimmen. In weiteren Ausführungsformen können die DCS-Anwendungen einen Lastenausgleich bereitstellen, indem sie eine Änderung eines Status eines der mehreren Servergeräte der Servergruppe erfassen und eine Lastverteilung zwischen mehreren Servergeräten basierend auf der Änderung des Status anpassen. In einigen solchen Ausführungsformen kann die Redundanz der softwaredefinierten Prozesssteuerungen auch bereitgestellt werden, indem gleichzeitig mehrere Instanzen von virtuellen DCS-Steuerungen auf verschiedenen Servergeräten der Servergruppe implementiert werden, so dass die Steuerung im Falle eines Steuerausfalls durch eines der Servergeräte zwischen den Instanzen übertragen werden kann.
In einigen Ausführungsformen können die DCS-Anwendungen eine Konfigurationsanwendung für die virtuelle Architektur enthalten, die eine Benutzeroberfläche für einen Benutzer generiert, die mehrere Optionen zum Konfigurieren virtueller Komponenten in der softwaredefinierten DCS-Umgebung enthält und durch Spezifizieren mehrerer virtueller Knoten innerhalb der virtuellen DCS-Netzwerkarchitektur und Verbindungen zwischen den virtuellen Knoten Benutzereingaben vom Benutzer zum Definieren einer virtuellen DCS-Netzwerkarchitektur empfängt. Diese virtuellen Knoten können die eine oder die mehreren virtuelle Darstellungen der mehreren Feldgeräte enthalten. In weiteren Ausführungsformen können die DCS-Anwendungen einen Data-Historian enthalten, der Prozessdaten innerhalb der softwaredefinierten DCS-Umgebung während des Betriebs des industriellen Prozesses automatisch überwacht und die Prozessdaten automatisch in einem Datenspeicher speichert, der der Servergruppe zugeordnet ist.
Figurenliste

1 zeigt ein Blockdiagramm einer beispielhaften physischen Prozessanlagenumgebung, in der ein verteiltes Steuersystem (DCS) mindestens einen Teil eines Prozesses in einer Industrie- oder Prozessanlage steuert.
2A und 2B zeigen Blockdiagramme der beispielhaften Prozessanlage aus 1, in der eine softwaredefinierte DCS-Umgebung, die auf einer Servergruppe ausgeführt wird, mindestens einen Teil der Prozessanlage steuert.
3 zeigt ein Blockdiagramm einer beispielhaften redundanten Servergruppe, die eine softwaredefinierte DCS-Umgebung implementiert, wie beispielsweise die in 2A und 2B dargestellte Servergruppe.
4 zeigt ein Flussdiagramm eines beispielhaften softwaredefinierten Konfigurations- und Steuerverfahrens für die DCS-Architektur.

DETAILLIERTE BESCHREIBUNG
Die hier beschriebene hyperkonvergente Architektur industrieller Prozessleitsysteme stellt eine softwaredefinierte verteilte Steuersystem(DCS)-Architektur zur Steuerung industrieller Prozesse in physischen Prozessanlagen bereit. Eine solche softwaredefinierte DCS-Architektur stellt ein hardwareunabhängiges und erweiterbares Steuerungsnetzwerk bereit, indem Ressourcen innerhalb des Prozessleitsystems so zusammengefasst werden, dass Komponenten als Softwarekomponenten definiert, verwaltet und gesteuert werden können. Beispielsweise ermöglicht eine softwaredefinierte DCS-Architektur die Implementierung softwaredefinierter Prozesssteuerungen und Back-End-DCS-Anwendungen auf derselben Hardware, z. B. einer Servergruppe, die ein privates Cloud-Computing-Netzwerk ausbildet. Diese Kombination der Steuerungen und übergeordneten Anwendungen in einer softwaredefinierten DCS-Umgebung bietet zahlreiche Vorteile. Diese Architektur ermöglicht beispielsweise die Verwendung von Standard-Serverhardware anstelle von systemspezifischer Hardware für Prozesssteuerungen, wodurch die Skalierbarkeit im Prozessleitsystem durch Hinzufügen oder Entfernen von Servern innerhalb einer Servergruppe ermöglicht wird. Durch die Implementierung virtueller Darstellungen mehrerer DCS-Prozesssteuerungen in der Servergruppe (zusammen mit anderen DCS-Anwendungen) ist keine separate Hardware für jede Steuerung und jedes andere Back-End-System erforderlich. Darüber hinaus macht die softwaredefinierte Kombination der softwaredefinierten Prozesssteuerungen und DCS-Anwendungen innerhalb der Servergruppe die Weiterleitung von Prozessdaten an mehrere Steuerungen überflüssig, wodurch die Komplexität des Steuerungssystems und der Aufwand für die Konfiguration oder Aktualisierung der Systemarchitektur verringert werden. Die Lastenausgleichs- und Failover-Funktionen werden auch verbessert, indem die softwaredefinierten Prozesssteuerungen als virtuelle DCS-Steuerungen in einer Servergruppe implementiert werden, sodass redundante virtuelle DCS-Steuerungen auf ressourcenschonende Weise auf den verschiedenen Servern der Servergruppe implementiert werden können. Diese Vorzüge sind nur beispielhaft, und zusätzliche Vorzüge für die hierin beschriebene softwaredefinierte DCS-Architektur sind für Durchschnittsfachleute auf der Grundlage der folgenden Offenbarung offensichtlich.
Physische Prozessanlage und Prozessleitsysteme
1 ist ein Blockdiagramm einer beispielhaften physischen Prozessanlagenumgebung 100, in der ein verteiltes Steuersystem (DCS) mindestens einen Teil eines Prozesses in einer Industrie- oder Prozessanlage steuert. Das DCS-System der physischen Prozessanlage 100 steuert einen industriellen Prozess (oder arbeitet in einigen Ausführungsformen in Verbindung mit einer virtuellen Anlagenumgebung, 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 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.
Auf einer hohen Ebene beinhaltet die Feldumgebung 102 physische Komponenten (z. B. Prozesssteuerungsgeräte, Netzwerke, Netzwerkelemente usw.), die zur gemeinsamen Steuerung des industriellen Prozesses während der Laufzeit installiert und zusammengeschaltet sind. Im Großen und Ganzen befinden sich diese physischen Komponenten in der Feldumgebung 102 der physischen Prozessanlage 100 und sind darin angeordnet oder anderweitig darin enthalten, in der Rohstoffe 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. Computergeräte, Bedienerarbeitsplätze, 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 Computergeräte, Datenbanken und andere Komponenten und Ausrüstungen an verschiedenen physischen Standorten befinden, von denen einige lokal in der physischen Prozessanlage 100 und andere entfernt angeordnet sein können.
Die Feldumgebung 102 der physischen Prozessanlage 100
Wie in 1 dargestellt, beinhaltet die Feldumgebung 102 eine oder mehrere Prozesssteuerungen 110, die kommunikativ mit einer Datenautobahn 108 verbunden sind. Jede der Prozesssteuerungen 110 kann mit einem oder mehreren Zwischenknoten, wie etwa I/O-Geräten 112, 115 (z. B. I/O-Karten, I/O-Geräte, I/O-Systemen usw.) verbunden sein, um die Kommunikation zwischen den Steuerungen 110 und den Feldgeräten zu erleichtern. 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 dargestellt. In einigen Anordnungen (nicht in 1 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 verschiedener Typen 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, auf deren gesamten Inhalt hier ausdrücklich Bezug genommen wird. Aus Gründen der Klarheit der Diskussion und wie hier verwendet, schließt der Begriff „I/O-Geräte“ im Allgemeinen physische I/O-Geräte, Karten, elektronische Rangiersysteme und Komponenten davon ein, über die I/O-Kanäle implementiert sind, um dadurch Feldgeräte und Steuerungen kommunikativ zu koppeln. Darüber hinaus bezieht sich der Begriff „I/O-Verbindungen“ im Allgemeinen auf physische I/O-Geräte und andere physische Komponenten, die verschiedene Komponenten verbinden, um I/O-Daten zwischen diesen Komponenten zu kommunizieren.
In der Prozesssteuerungsindustrie kann der Begriff „I/O“ im Allgemeinen dazu verwendet werden, sich auf die auf einem 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 Diskussion und wie hier verwendet, I/O-Signale, I/O-Parameter und I/O-Parameterwerte hier zusammenfassend und allgemein als „I/O-Daten“ oder „Prozess-I/O-Daten“ bezeichnet.
In dem Maß, in dem hier ohne Qualifikationsmerkmal auf den Begriff „I/O“ Bezug genommen wird, sollte der Kontext des Satzes klarstellen, 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 Qualifikationsmerkmal „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.
Unter Einsatz von Prozess-I/O-Daten 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 ein oder mehrere Feldgeräte zur Steuerung des Betriebs eines Prozesses in der Anlage 100. Die Steuerung kann ein Steuersignal generieren, das auf folgendem basiert: (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, I/O-Geräten kann in der physischen Prozessanlage 100 enthalten sein.
Zum Beispiel veranschaulicht 1 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 der Datenautobahn 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® Feldbus 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 dem Backbone 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®-Feldbus-Protokoll, dem HART®-Protokoll, dem WirelessHART®-Protokoll usw. verbunden ist. Wie dargestellt, 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 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, entsprechen.
Die Prozesssteuerung 110 enthält einen Prozessor 120, der eine oder mehrere Prozesssteuerroutinen 118 implementiert oder überwacht (z. B. computerlesbare Anweisungen von Prozesssteuerroutinen 118 ausführt, die in 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, Prozessoren, 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 physischen Prozessanlage 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 irgendeiner anderen Softwareprogrammiersprache oder eines 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 (ASICs) oder anderen Hardware- oder Firmware-Elementen fest eingebaut 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 Steuerstrategie mit Hilfe von sogenannten Funktionsblöcken, wobei jeder Funktionsblock ein Objekt oder ein anderer Teil (z. B. ein Unterprogramm) einer übergreifenden Steuerroutine ist und in Verbindung mit anderen Funktionsblöcken (über Kommunikationswege, die als Links bezeichnet werden) arbeitet, um Prozesssteuerungskreise innerhalb eines Prozessleitsystems umzusetzen. 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 etwa eines Ventils, steuert, um eine physische Funktion innerhalb der physischen Prozessanlage 100 auszuführen (manchmal als „Ausgabeblöcke“ bezeichnet). 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 4-20-mA-Geräte 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^®-Feldbus-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 einem beliebigen gewünschten Kommunikations- oder Steuerungsprotokoll entsprechen. Beispielsweise können die I/O-Geräte 112, 115 in einem elektronischen I/O-Rangiersystem enthalten sein. Zum Beispiel können die Feldgeräte 125-128 4-20-mA-Standardgeräte oder HART^®-Geräte sein, die über analoge Leitungen oder kombinierte analoge und digitale Leitungen mit dem I/O-Gerät 112 kommunizieren, und die Feldgeräte 129-132 können intelligente Geräte, wie z. B. FOUNDATION^®-Fieldbus-Feldgeräte, sein, die über einen digitalen Bus mit dem I/O-Gerät 115 unter Verwendung eines FOUNDATION^®Fieldbus-Kommunikationsprotokolls kommunizieren. In einigen Ausführungsformen kommunizieren jedoch mindestens einige der leitungsgebundenen Feldgeräte 125, 126, 128-131 und/oder mindestens 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 industrielle Prozesssteuerungskommunikationsprotokolle (z. B. Profibus, DeviceNet, Foundation Feldbus, ControlNet, Modbus, HART usw.). In einigen Anordnungen (in 3 nicht dargestellt) können mindestens einige der Feldgeräte 125-132 mit der Steuerung 110 über ein elektronisches I/O-Rangiersystem anstelle über ein einzelnes I/O-Gerät 112, 115 kommunizieren.
Die drahtlosen Feldgeräte 140-146 kommunizieren über ein drahtloses ProzesssteuerungsKommunikationsnetzwerk 165 mit einem drahtlosen Protokoll, wie dem WirelessHART^®-Protokoll. Solche drahtlosen Feldgeräte 140-146 können direkt mit einem oder mehreren anderen Geräten oder Knoten des drahtlosen Netzwerks 165 kommunizieren, die ebenfalls für eine 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 ProzesssteuerungsKommunikationsnetzwerk verbunden ist. Das drahtlose Gateway 168 ermöglicht den Zugriff auf verschiedene drahtlose Geräte 140-158 des drahtlosen Kommunikationsnetzes 165. Insbesondere sorgt das drahtlose Gateway 168 für die kommunikative Kopplung zwischen den drahtlosen Geräten 140-158, den leitungsgebundenen Geräten 125-132 und/oder anderen Knoten oder Geräten der physischen Prozessanlage 100. Das drahtlose Gateway 168 kann z. B. eine kommunikative Kopplung über die Prozesssteuerungsdatenautobahn 108 und/oder über ein oder mehrere andere Kommunikationsnetzwerke der Prozessanlage 100 ermöglichen. Analog zu den leitungsgebundenen Feldgeräten 125-132 übernehmen die drahtlosen Feldgeräte 140-146 des drahtlosen Netzwerks 165 physische Steuerungsfunktionen innerhalb der Prozessanlage 100, z. B. Öffnen oder Schließen von Ventilen oder 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. Als solche sind die drahtlosen Feldgeräte 140-146, das drahtlose Gateway 168 und andere drahtlose Knoten 152-158 des drahtlosen Netzwerks 165 Erzeuger und Verbraucher drahtloser Kommunikationspakete.
In einigen Konfigurationen der Prozessanlage 100 beinhaltet das drahtlose Netzwerk 165 auch nichtdrahtlose Geräte. Zum Beispiel ist in 1 ein Feldgerät 148 ein 4-20-mA-Legacy-Gerät 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^®-Feldbus, PROFIBUS, DeviceNet, etc. unterstützen. Darüber hinaus enthält das drahtlose Netzwerk 165 in einigen Konfigurationen einen oder mehrere Netzwerkzugangspunkte 155a, 155b, die separate physische Geräte 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. Demnach 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.
Es wird darauf hingewiesen, dass, obwohl 1 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 physischen Prozessanlage 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 physischen Prozessanlage 100 zu steuern.
Die Back-End-Umgebung 105 der physischen Prozessanlage 100
Die Back-End-Umgebung 105 beinhaltet, wie zuvor angemerkt, verschiedene Komponenten, wie z. B. Computergeräte, Bedienerarbeitsplätze, 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) einen oder mehrere Bedienerarbeitsplätze 170a und/oder andere lokale oder entfernte Benutzeroberflächengeräte 170b; (ii) eine oder mehrere Konfigurationsanwendungen 172a und/oder Konfigurationsdatenbanken 172b; (iii) eine oder mehrere andere Typen von Anwendungen 175a und/oder Datenbanken 175b, die beispielsweise Werkzeuge, Diagnosen, Vermögensverwaltungssysteme, 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 oder anderen Netzwerken 185, die außerhalb der unmittelbaren Operations Technology-Schichten der physischen Prozessanlage 100 liegen (z. B. IT-Unternehmensnetzwerke/-Systeme 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.
Die Bedienerarbeitsplätze 170a und andere Benutzeroberflächengeräte 170b können von Bedienern verwendet werden, um Laufzeitoperationen der physischen Prozessanlage 100 anzuzeigen und zu überwachen sowie um eventuell erforderliche Diagnose-, Korrektur-, Wartungs- und/oder andere Maßnahmen zu ergreifen. Zumindest können sich einige der Bedienerarbeitsplätze 170a in verschiedenen, geschützten Bereichen in oder nähe der Anlage 100 befinden; und in manchen Situationen können mindestens einige der Benutzerschnittstellenvorrichtungen 170b entfernt angeordnet sein, jedoch dennoch in kommunikativer Verbindung mit der Anlage 100 stehen. Bedienerarbeitsplätze und Benutzerschnittstellenvorrichtungen 170a, 170b können leitungsgebundene oder drahtlose Computervorrichtungen sein, die konfiguriert sind, Bedienerschnittstellenprogramme oder - anwendungen zu implementieren, damit Bediener den Betrieb der physischen Prozessanlage 100 überwachen und steuern können.
Die Konfigurationsanwendungen 172a und die Konfigurationsdatenbanken 172b können verwendet werden, um bestimmte Aspekte in Bezug auf Steuerung und/oder Kommunikation für die physische Prozessanlage 100 zu konfigurieren, wie beispielsweise durch eine anfängliche Konfiguration und Rekonfiguration von 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 ein 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 ein als Einheit dargestelltes, logisches Erscheinungsbild für eine DCS-Umgebung (z. B. das DeltaVTM-Steuerungssystem, das von Emerson Process Management vertrieben wird) für die physische Prozessanlage 100, obwohl mehrere Instanzen der Konfigurationsanwendungen 172a gleichzeitig innerhalb der DCS-Umgebung ausgeführt werden können und die Konfigurationsdatenbanken 172b über mehrere physische Datenspeichergeräte implementiert werden können. Dementsprechend umfassen die Konfigurationsanwendungen 172a und die Konfigurationsdatenbanken 172b (einschließlich ihrer Benutzerschnittstellen) 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 Bedienerarbeitsplätzen/Benutzeroberflächengeräten 170, wobei die Benutzeroberflächen für das Konfigurationssystem 172 von Konfigurations- und Entwicklungsingenieuren verwendet werden, unabhängig davon, ob die physische Prozessanlage 100 im Produktionsmodus arbeitet, während die Bedienerarbeitsplätze/Benutzeroberflächengeräte 170 von den Bedienern während der Laufzeitoperationen der physischen Prozessanlage 100 verwendet werden.
In Bezug auf die Inbetriebnahme der physischen Komponenten der Feldumgebung 102 kann die Konfigurationsdatenbank 172b Daten und andere Informationen speichern, die spezifisch die verschiedenen physischen Geräte oder Komponenten und deren Verbindungen untereinander identifizieren und/oder adressieren, die für den Prozessanlagenbereich oder die Feldumgebung 102 geplant 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 arbeiten. 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, um verschiedene Signale zu/von anderen Komponenten in ihrer Schleife (und in einigen Fällen zu/von anderen Prozesssteuerungen) zu senden und zu empfangen, wodurch mindestens ein Anteil des Prozesses in der physischen Prozessanlage 100 gesteuert wird.
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, dem Bedienerarbeitsplatz 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 physische Prozessanlage 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 wurde. Wenn also eine nicht zugewiesene logische Kennung von einer Steuerroutine referenziert wird, wird kein Wert gelesen, der von einem Signal in der physischen Prozessanlage 100 übertragen wird, und es wird kein Befehl über ein Signal an ein Feldgerät in der physischen Prozessanlage 100 übertragen.
Beispiele für solche logischen Kennungen schließen Geräte-Tags (DTs) ein, von denen jedes ein bestimmtes Instrument, eine bestimmte Steuerung, ein bestimmtes Ventil oder ein anderes physisches Feldgerät darstellt, und Geräte-Signal-Tags (DSTs), von denen jedes ein bestimmtes Signal darstellt, 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 DST eine Kombination aus dem DT 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, wie etwa Legacy- oder „nicht intelligenten“ Geräten, stellt ein DT sowohl das physische Gerät als auch ein vom Gerät generiertes Signal dar. Im Allgemeinen 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 DTs und DSTs können als „Tags“, „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 sein oder nicht. Die Konfigurationsdatenbank 172b kann Daten und andere Informationen speichern, die spezifisch verschiedene virtuelle Geräte oder Komponenten (z. B. verschiedene virtuelle Knoten) identifizieren und/oder adressieren, die für eine virtuelle DCS-Umgebung wie nachfolgend beschrieben geplant sind, oder in sie implementiert werden sollen. Ähnlich wie bei physischen Geräten und Komponenten kann die Konfigurationsdatenbank 172b entsprechende logische Kennungen von Komponenten der virtuellen DCS-Umgebung speichern, wodurch andere Geräte und/oder Komponenten (ob physisch oder virtuell) auf die virtuellen Komponenten verweisen können. Beispielsweise können ähnlich wie bei physischen Knoten in der Feldumgebung 102 verschiedene virtuelle Knoten in der DCS-Umgebung, die in der Back-End-Umgebung 105 betrieben wird, über ihre jeweiligen Geräte-Tags (device tags - DT), Geräte-Signal-Tags (device signal tags - DST) Quell-Tags und/oder andere Arten 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.
Die anderen Anwendungen 175a und Datenbanken 175b können Instanzen von Anwendungen enthalten, die eingesetzt werden, um Aspekte des Betriebs der physischen Prozessanlage 100 zu überwachen oder zu analysieren, wie Diagnoseanwendungen/-Datenbanken, Data-Historian-Anwendungen/-Datenbanken, Anwendungen/Datenbanken zur Überwachung des Zustands auf Systemebene, lokale und/oder entfernte Benutzeroberflächen; usw. Im Allgemeinen können die anderen Anwendungen 175a und Datenbanken 175b eine oder mehrere Anwendungen enthalten, die auf den Operations Technology-Schichten der physischen 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 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 Anwendungen des Internet der Dinge (Internet of Things - loT) und/oder des industriellen Internet der Dinge (Industrial Internet of Things - IIoT) 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 physischen Prozessanlage 100 und/oder ihres Unternehmens befinden und/oder entfernt von dieser ausgeführt werden, wie Simulationsanwendungen, Analyseanwendungen usw. und die zugehörigen Datenbanken. Die anderen Anwendungen 175a und Datenbanken 175b können Anwendungen von Drittanbietern und/oder Anwendungen enthalten, die von dem mit der physischen Prozessanlage 100 verbundenen Unternehmen bereitgestellt werden. Auf mindestens einigen der anderen Anwendungen 175a und Datenbanken 175b kann über ein Edge-Gateway-System 182 und/oder eine andere Art von Sicherheits- und/oder Firewall-System zugegriffen werden.
Der eine oder die mehreren 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 leitungsgebundenen oder drahtlosen Kommunikationsprotokollen zu kommunizieren, wie z. B. WLAN 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 Zugangspunkte 178 mobilen oder anderen tragbaren Computergeräten (z. B. Benutzeroberflächengeräten 170b) über ein entsprechendes drahtloses Prozesssteuerungskommunikationsnetzwerk, 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 ein mobiler Arbeitsplatz oder ein Diagnosetestgerät sein, das von einem Bediener innerhalb der physischen Prozessanlage 100 verwendet wird (z. B. eine Instanz von einem der Bedienerarbeitsplätze 170a). In einigen Szenarien kommunizieren neben tragbaren Computergeräten 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.
Die Gateway-Knoten oder -Systeme 180 und 182 können mit Systemen verbunden sein, die außerhalb der unmittelbaren physischen Prozessanlage 100 liegen. Typischerweise sind solche Systeme Kunden und/oder Lieferanten von Informationen, die von der physischen Prozessanlage 100 generiert oder darauf betrieben werden. Beispielsweise kann die physische Prozessanlage 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 physische Prozessanlage 100 einen Edge-Gateway-Knoten oder ein -System 182 enthalten, um die 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 Vermögensverwaltungssystem, 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 physischen Prozessanlage 100 und anderen Netzwerken 185. In einer beispielhaften Architektur beinhaltet ein Edge-Gateway-System 182 eine nach innen gerichtete oder zur Anlage gerichtete Engine (die als „Feld-Gateway“ bezeichnet werden kann) und eine extern gerichtete 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 Operations Technology-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 sammelt die zur Anlage gerichtete Engine Daten, die von verschiedenen Komponenten der Prozessanlage 100 generiert werden, und überträgt die gesammelten 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 verschiedene Veröffentlichungen abonniert, die von der zur Anlage gerichteten Engine generiert wurden, und erhält die gesammelten Anlagendaten daraus. Die nach außen gerichtete Engine überträgt wiederum die erhaltenen Anlagendaten sicher an eine oder mehrere externe Client-Anwendungen innerhalb der Netzwerke 185, z. B. über einen zweiten Satz von Veröffentlichungen. Veröffentlichungen und Abonnements an der zur Anlage gerichteten Engine und/oder an 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. 2018/0115516; 2018/0115528; 2018/0115517; und 2018/0113442 , deren gesamte Offenbarungen hiermit durch Bezugnahme aufgenommen werden. Natürlich können andere Edge-Gateway-Systeme zusätzlich oder alternativ von der physischen Prozessanlage 100 verwendet werden.
Softwaredefinierte DCS-Umgebung für eine physische Prozessanlage 2A und 2B zeigen Blockdiagramme der beispielhaften physischen Prozessanlage 100 aus 1, in der eine softwaredefinierte DCS-Umgebung 200, die auf einer Servergruppe 210 ausgeführt wird, mindestens einen Teil der Prozessanlage steuert. In beiden dargestellten Ausführungsformen der softwaredefinierten DCS-Umgebung 200 sind die Steuerungen 110 der physischen Prozessanlage 100 als softwaredefinierte Prozesssteuerungen (virtuelle DCS-Steuerungen 212) innerhalb einer Servergruppe 210 in der Back-End-Umgebung 105 implementiert. Zusätzlich zu den virtuellen DCS-Steuerungen 212 implementiert die Servergruppe 210 auch verschiedene DCS-Anwendungen 221-225 und 229, um eine übergeordnete Funktionalität, Konfiguration, Überwachung und Analyse des Prozesses und der virtuellen DCS-Steuerungen 212 bereitzustellen. Die Servergruppe 210 enthält auch eine oder mehrere Datenbanken oder Datenspeicher für Prozessdaten, die für die virtuellen DCS-Steuerungen 212 und die DCS-Anwendungen 221-225 und 229 relevant sind. Obwohl die beispielhafte softwaredefinierte DCS-Umgebung 200 als Implementierung mehrerer virtueller DCS-Steuerungen 212 dargestellt ist, sollte dies als ein Beispiel für die Implementierung einer softwaredefinierten Infrastruktur verstanden werden, in der Hardware- und Softwareressourcen in einer softwaredefinierten Umgebung zusammengefasst werden, um das richtlinienbasierte Bereitstellen von Infrastruktur zu ermöglichen.
Die softwaredefinierte DCS-Steuerung des Prozesses in der Servergruppe 210 bietet mehrere Vorteile, einschließlich der Verbesserung der Systemstabilität durch Ermöglichen des Lastenausgleichs und des Schutzes vor Komponentenfehlern, Reduzieren der Geräteanforderungen durch Kombinieren der Steuerungen mit derselben Hardware und Reduzieren des Konfigurationsaufwands durch Reduzieren der Komplexität des Netzwerks. 2A zeigt eine Ausführungsform der softwaredefinierten DCS-Umgebung 200, in der die I/O-Verbindungen 240 von Komponenten in der Feldumgebung 102 behandelt werden, während 2B eine Ausführungsform der softwaredefinierten DCS-Umgebung 200 zeigt, in der die I/O-Verbindungen 240 von der Servergruppe 210 in der Back-End-Umgebung 105 verarbeitet werden. Weitere Ausführungsformen können Kombinationen von I/O-Verbindungen 240 sowohl in der Feldumgebung 102 als auch in der Back-End-Umgebung 105 enthalten (z. B. können intelligente Feldgeräte in der Lage sein, über ein Datenkommunikationsnetzwerk direkt mit der Servergruppe 210 zu kommunizieren, während Legacy-Feldgeräte möglicherweise ein I/O-Gerät erfordern, um zwischen einem von den Feldgeräten verwendeten Kommunikationsprotokoll zur industriellen Prozesssteuerung und einem von den Servern verwendeten allgemeinen IT-Kommunikationsprotokoll zu wechseln).
Wie zuvor in Bezug auf 1 beschrieben, steuern mehrere Feldgeräte 125-132, 140-150 innerhalb der Feldumgebung 102 mindestens einen Teil eines industriellen Prozesses basierend auf Steuersignalen von DCS-Steuerungen. In der softwaredefinierten DCS-Umgebung 200 werden diese Steuersignale von virtuellen DCS-Steuerungen 212 erzeugt, die von einem oder mehreren Servern innerhalb der Servergruppe 210 implementiert werden. Die virtuellen DCS-Steuerungen 212 wirken im Wesentlichen auf die gleiche Weise wie die (physischen) Steuerungen 110, um eine Prozesssteuerungslogik zu implementieren, die konfiguriert ist, den Prozess in Echtzeit zu überwachen und zu steuern. Die virtuellen DCS-Steuerungen 212 sind jedoch als computerausführbare Anweisungen innerhalb der Servergruppe 210 und nicht innerhalb spezieller Hardware-Steuerungen 110 in der Feldumgebung 102 implementiert. Beispielsweise können die virtuellen DCS-Steuerungen 212 virtuelle Instanzen von Steuerprogrammen sein, die in einer Echtzeitbetriebsumgebung ausgeführt werden, die von einem oder mehreren Hypervisoren implementiert wird, die auf der Servergruppe 210 ausgeführt werden, um eine native Betriebsumgebung jeder der virtuellen DCS-Steuerungen 212 zu simulieren. Jede virtuelle DCS-Steuerung 212 in der softwaredefinierten DCS-Umgebung 200 implementiert Prozessregelkreise unter Verwendung eines oder mehrerer Funktionsblöcke, um den Prozess über die Feldgeräte 125-132, 140-150 zu überwachen und zu steuern. Somit werden die virtuellen DCS-Steuerungen 212 innerhalb der Servergruppe 210 konsolidiert, um den Prozess (oder einen Teil davon) von einem Ort aus zu steuern, wodurch die Kommunikation zwischen den Steuermodulen verbessert wird. In einigen Ausführungsformen können mehrere virtuelle DCS-Steuerungen 212 implementiert sein, um verschiedene Teile des Prozesses zu steuern, ähnlich der Verwendung mehrerer physischer Steuerungen in physischen DCS-Netzwerken. Wie weiter unten erläutert, können Lastenausgleich und Redundanz erreicht werden, indem mehrere Instanzen jeder virtuellen DCS-Steuerung 212 auf verschiedenen Servern der Servergruppe 210 implementiert werden.
Zusätzlich zu den virtuellen DCS-Steuerungen 212 können in einigen Ausführungsformen andere Netzwerkkomponenten in der softwaredefinierten DCS-Umgebung 200 virtualisiert werden, um ein virtuelles Netzwerk zu erzeugen, das durch Software definiert ist, die auf der Servergruppe 210 ausgeführt wird. Ein solches virtuelles Netzwerk umfasst mehrere virtuelle Knoten, die physischen Knoten in der physischen Prozessanlage 100 zugeordnet sind. Diese virtuellen Knoten können virtuelle Komponenten enthalten, die die verschiedenen Hardwarekomponenten darstellen, die in dem Kommunikationsnetzwerk der Feldumgebung 102 vorhanden sind, wie beispielsweise Netzwerk-Switches, Router, Firewalls und andere Netzwerkgeräte. Diese virtuellen Knoten können Netzwerkkomponenten, wie etwa drahtlose Gateways 168, drahtlose Adapter 152, Zugangspunkte 155 oder Router 158 enthalten, wie oben beschrieben. In weiteren Ausführungsformen kann das virtuelle Netzwerk virtuelle Darstellungen von Feldgeräten zur Steuerung und Kommunikation mit den Feldgeräten 125-132, 140-150 enthalten. Virtuelle Darstellungen von Feldgeräten können innerhalb der virtuellen DCS-Steuerungen 212 unter Verwendung von Gerätefunktionsblöcken, Schattenfunktionsblöcken oder anderen solchen Techniken, die in DCS-Umgebungen verwendet werden, implementiert werden. Somit umfasst in diesen Ausführungsformen die softwaredefinierte DCS-Umgebung 200 eine virtuelle Darstellung der physischen Komponenten des Prozessleitsystems in der Feldumgebung (z. B. Feldgeräte und notwendige Netzwerkkomponenten) sowie der virtuellen DCS-Steuerungen 212, die die physischen Steuerungen ersetzt.
Um Kommunikationsverbindungen mit den Feldgeräten 125-132, 140-150 aufrechtzuerhalten, kann die softwaredefinierte DCS-Umgebung 200 I/O-Verbindungen 240 enthalten oder mit diesen verbunden sein, die konfiguriert sind, eine Kommunikationsverbindung zwischen der Servergruppe 210 und den physischen Komponenten des Kommunikationsnetzes der Feldumgebung 102 bereitzustellen. Die I/O-Verbindungen 240 enthalten physische Netzwerkkomponenten, die die Servergruppe 210 entweder direkt oder indirekt mit den Feldgeräten 125-132, 140-150 verbinden. Diese Komponenten können Ports, Switches oder Router enthalten. Die I/O-Verbindungen 240 leiten Prozessdaten zwischen den virtuellen DCS-Steuerungen 212 und den Feldgeräten 125-132, 140-150 weiter. Somit empfangen die I/O-Verbindungen 240 Prozessdaten von den Feldgeräten 125-132, 140-150 und senden diese Prozessdaten an die virtuellen DCS-Steuerungen 212, und die I/O-Verbindungen 240 empfangen ebenfalls Prozesssteuersignale von den virtuellen DCS Steuerungen 212 und senden diese Prozesssteuersignale an die Feldgeräte 125-132, 140-150.
In einigen Ausführungsformen können die I/O-Verbindungen 240 einen I/O-Server enthalten, der konfiguriert ist, physische Knoten innerhalb der Feldumgebung 102 virtuellen Knoten innerhalb der softwaredefinierten DCS-Umgebung 200 zuzuordnen, wodurch die virtuellen DCS-Steuerungen 212 in die Lage versetzt werden, mit virtuellen Knoten zu kommunizieren, die von dem I/O-Server ohne detaillierte Kenntnis des physischen Netzwerks in der Feldumgebung 102 verwaltet werden. Beispielsweise kann der I/O-Server physische Knoten, die den Feldgeräten 125-132, 140-150 zugeordnet sind, virtuellen Knoten zuordnen, die entsprechenden virtuellen Feldgeräten zugeordnet sind, und zwar durch eine Veröffentlichungs-/Abonnementzuordnung, um eine Echtzeitkommunikation von Daten zwischen der Servergruppe 210 und den Komponenten der Feldumgebung 102 (z. B. den Feldgeräten 125-132, 140-150) bereitzustellen. Durch Weiterleiten der gesamten Kommunikation an die Servergruppe 210 entkoppeln die I/O-Verbindungen 240 die Hardware- und Softwarekommunikationskonfiguration, wodurch allen virtuellen DCS-Steuerungen 212 in der Servergruppe 210 der Zugriff auf Prozessdaten ermöglicht wird, ohne dass jeweils separate Hardwareverbindungen für jede Steuerungen zu jeder Datenquelle konfiguriert werden müssen.
In weiteren Ausführungsformen können die I/O-Verbindungen 240 auch die Prozessdaten (einschließlich Prozesssteuersignalen) zwischen Serverkommunikationsprotokollen, die von den virtuellen DCS-Steuerungen 212 verwendet werden, und Kommunikationsprotokollen zur industriellen Prozesssteuerung, die von den Feldgeräten 125-132, 140-150 verwendet werden, konvertieren. Beispielsweise kann die Servergruppe 210 konfiguriert sein, Daten unter Verwendung eines allgemeinen IT-Kommunikationsprotokolls (z. B. eines Ethernet-Protokolls, eines IP-Protokolls oder eines anderen Paketprotokolls) zu kommunizieren, während die Feldgeräte 125-132, 140-150 konfiguriert sein können, Kommunikationsprotokolle zur industriellen Prozesssteuerung (z. B. Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART usw.) zu kommunizieren.
Wenngleich in 2A von der Servergruppe 210 getrennt ist, können die I/O-Verbindungen 240 alternativ in die Servergruppe 210 integriert werden, wie in 2B dargestellt. Ebenso können die I/O-Verbindungen 240 die Servergruppe 210 nur mit einer Teilmenge der Feldgeräte (z. B. Feldgeräte 125-132, wie in 2A gezeigt) verbinden, oder sie können die Servergruppe 210 mit allen Feldgeräten in der Feldumgebung 102 verbinden (z. B. Feldgeräte 125-132 und 140-150, wie in 2B gezeigt). Wie in 2A gezeigt, können andere Netzwerkkomponenten (wie das drahtlose Gateway 168) einige der Feldgeräte (wie etwa die Feldgeräte 140-150) direkt mit der Servergruppe 210 verbinden, beispielsweise über eine direkte physische Verbindung oder über ein lokales Netzwerk (nicht gezeigt) in der Backend-Umgebung 105. Beispielsweise kann innerhalb eines Serverraums in der Back-End-Umgebung 105 ein drahtloses Gateway 168 physisch über ein leitungsgebundenes Kommunikationskabel mit einem oder mehreren Server-Racks verbunden sein, die die Servergruppe 210 umfassen.
Zusätzlich zu den virtuellen DCS-Steuerungen 212 enthält die softwaredefinierte DCS-Umgebung 200 auch eine oder mehrere DCS-Anwendungen 221-225, 229, die auf den Servern der Servergruppe 210 ausgeführt werden. Diese DCS-Anwendungen 221-225, 229 sind konfiguriert, mit den virtuellen DCS-Steuerungen 212 zu interagieren, um den Betrieb des Prozesses innerhalb der physischen Prozessanlage 100 zu konfigurieren, zu überwachen, zu steuern und/oder zu analysieren. Die DCS-Anwendungen wirken auf ähnliche Weise wie die verschiedenen Anwendungen und Gateways der Back-End-Umgebung 105 in einer herkömmlichen DCS-Konfiguration (wie der in 1 dargestellten), um Daten von den virtuellen DCS-Steuerungen 212 zu erhalten und den Betrieb der virtuellen DCS-Steuerungen 212 bei der Steuerung des physischen Prozesses anzupassen. Das Implementieren der DCS-Anwendungen 221-225, 229 innerhalb der Servergruppe 210 zusammen mit den virtuellen DCS-Steuerungen 212 vereinfacht jedoch die Konfiguration und Kommunikation. In manchen Ausführungsformen kann die softwaredefinierte DCS-Umgebung 200 ein oder mehrere Betriebssysteme implementieren, in denen eine oder mehrere der DCS-Anwendungen 221-225, 229 nativ ausgeführt werden, zusätzlich zu der Echtzeitumgebung, in der die virtuellen DCS-Steuerungen 212 ausgeführt werden.
Die DCS-Anwendungen 221-225, 229 können mehrere Anwendungen zum Implementieren von Steuerungs-, Konfigurations-, Kommunikations- oder Analysefunktionen enthalten. Ein oder mehrere Benutzerschnittstellengeräte 170b (z. B. Arbeitsstationen, Desktop-Computer oder mobile Computergeräte) können von einem oder mehreren Bedienern verwendet werden, um mit den DCS-Anwendungen 221-225, 229 der softwaredefinierten DCS-Umgebung 200 zu interagieren. Beispielsweise kann ein Bediener einen Desktop-Computer oder ein Smartphone verwenden, um mit den DCS-Anwendungen 221-225, 229 zu interagieren, um Informationen bezüglich des Prozesses zu erhalten, um den Betrieb der virtuellen DCS-Steuerungen 212 anzupassen oder um den Prozess oder den Zustand der physischen Prozessanlage 100 zu analysieren.
Eine Edge-Gateway-Anwendung 221 kann konfiguriert sein, eine Kommunikation mit anderen Netzwerken 185 bereitzustellen, ähnlich dem Edge-Gateway-System 182 in 1. Zu diesen anderen Netzwerken können externe Netzwerke zählen, die von der Prozessanlage entfernt sind. Eine Bedienerschnittstellenanwendung 222 kann konfiguriert sein, einem Bediener eine Bedienerschnittstelle oder eine Arbeitsstationsschnittstelle bereitzustellen, damit der Bediener den Laufzeitbetrieb des Prozesses ähnlich wie bei den Bedienerarbeitsplätzen 170a überwachen und steuern kann. Beispielsweise kann ein Bediener eine Benutzerschnittstellenvorrichtung 170b verwenden, um auf die Bedienerschnittstellenanwendung 222 zuzugreifen, die auf der Servergruppe 210 ausgeführt wird, um Diagnose-, Korrektur-, Wartungs- und/oder andere Maßnahmen zu ergreifen, die zum Betreiben der physischen Prozessanlage 100 erforderlich sein können. Diese Maßnahmen können das Einstellen oder Anpassen von Betriebsparametern, Steuersollwerten oder Steuerschemata umfassen, die von den virtuellen DCS-Steuerungen 212 verwendet werden. Da die virtuellen DCS-Steuerungen 212 alle innerhalb der softwaredefinierten DCS-Umgebung 200 und der Servergruppe 210 ausgeführt werden, kann die Bedienerschnittstellenanwendung 222 konfiguriert sein, globale Änderungen auf alle virtuellen DCS-Steuerungen 212 oder andere Komponenten der softwaredefinierten DCS-Netzwerkarchitektur anzuwenden. Beispielsweise kann die Bedienerschnittstellenanwendung 222 konfiguriert sein, eine systemweite Sperre anzuwenden, um das Herunterladen von Steuermodulen auf die virtuellen DCS-Steuerungen 212 zu verhindern (z. B. um versehentliche oder nicht autorisierte Änderungen zu verhindern, während der Prozess ausgeführt wird). Eine Anlagenverwaltungsanwendung 223 kann konfiguriert sein, Informationen zu Anlagen in der physischen Prozessanlage 100 sowie Informationen zur Nutzung von Anlagen bereitzustellen.
Eine Data-Historian-Anwendung 224 kann konfiguriert sein, Prozessdaten innerhalb der softwaredefinierten DCS-Umgebung 200 während des Betriebs des Prozesses zur späteren Verwendung in der Prozessanalyse oder der Steuerung zu speichern. Durch Implementieren der Data-Historian-Anwendung 224 in der Servergruppe 210 mit den virtuellen DCS-Steuerungen 212 ist es möglich, detailliertere Prozessdaten zu speichern, als dies sonst möglich wäre. Da alle von den virtuellen DCS-Steuerungen 212 verwendeten und von diesen erzeugten Prozessdaten in der Servergruppe 210 verfügbar sind, ist keine weitere Kommunikation außerhalb der Servergruppe 210 erforderlich, um die Daten zu historisieren. Somit kann die Data-Historian-Anwendung 224 konfiguriert sein, High-Fidelity-Daten während des Prozessbetriebs automatisch zu speichern. Diese Prozessdaten können in den Datenbanken oder Datenspeichern 230 der Servergruppe 210 gespeichert sein, in denen auch Konfigurations- oder andere Daten gespeichert sein können, die von den virtuellen DCS-Steuerungen 212 oder den DCS-Anwendungen 221-225, 229 verwendet werden.
Eine Konfigurationsanwendung 225 für die virtuelle Architektur kann konfiguriert sein, eine softwaredefinierte DCS-Netzwerkarchitektur (z. B. eine virtuelle DCS-Netzwerkarchitektur) zu definieren, indem mehrere softwaredefinierte virtuelle Knoten innerhalb der softwaredefinierten DCS-Netzwerkarchitektur und Verbindungen zwischen diesen Knoten spezifiziert werden, ähnlich der Definition der Netzwerkarchitektur der physischen Prozessanlage 100 durch die Konfigurationsanwendung 172a. Beispielsweise können virtuelle Knoten in einer virtuellen DCS-Netzwerkarchitektur verwendet werden, um die physische Netzwerkarchitektur der Komponenten der Feldumgebung 102 darzustellen, damit die virtuellen DCS-Steuerungen 212 den Prozess steuern können. Somit können die virtuellen Knoten virtuelle Darstellungen der mehreren Feldgeräte enthalten. Um die softwaredefinierte DCS-Netzwerkarchitektur zu definieren, kann die Konfigurationsanwendung 225 für die virtuelle Architektur eine Benutzerschnittstelle bereitstellen, die so konfiguriert ist, dass ein Bediener virtuelle Knoten definieren kann. In einigen Ausführungsformen kann die Konfigurationsanwendung 225 für die virtuelle Architektur die I/O-Verbindungen 240 konfigurieren, um die Kommunikation zwischen der Servergruppe 210 und den Feldgeräten 125-132, 140-150 zu ermöglichen. In weiteren Ausführungsformen können Informationen bezüglich des Typs von Prozessdaten, die von den Komponenten der Feldumgebung 102 von den I/O-Verbindungen 240 empfangen werden, an die Konfigurationsanwendung 225 für die virtuelle Architektur bereitgestellt werden, um einen Teil oder die gesamte softwaredefinierte DCS-Netzwerkarchitektur basierend auf der Art der empfangenen Prozessdaten automatisch zu bestimmen. Wie auch immer definiert oder bestimmt, kann die softwaredefinierte DCS-Netzwerkarchitektur als Konfigurationsdaten in einer oder mehreren Datenbanken oder Datenspeichern 230 gespeichert werden, ähnlich den Konfigurationsdatenbanken 172b.
In einigen Ausführungsformen können andere DCS-Anwendungen 229 innerhalb der softwaredefinierten DCS-Umgebung 200 auf der Servergruppe 210 implementiert werden, um zusätzliche oder alternative Funktionen bereitzustellen. Diese anderen DCS-Anwendungen 229 können Mensch-Maschine-Schnittstellenanwendungen, Engineering-Workstation-Anwendungen, Fertigungsausführungssystemanwendungen, erweiterte Prozessleitsystemanwendungen, Netzwerkkommunikationsanwendungen, Sicherheitsanwendungen oder andere Anwendungen zum Durchführen von Prozesssteuerung, Überwachung, Testen, Wartung, Optimierung oder Analyse in Bezug auf den Prozess der physischen Prozessanlage 100 umfassen. Beispielsweise können die anderen DCS-Anwendungen 229 eine Emulatoranwendung enthalten, die konfiguriert ist, Softwareanwendungen von Drittanbietern innerhalb der Servergruppe 210 auszuführen, indem eine native Betriebsumgebung solcher Softwareanwendungen von Drittanbietern innerhalb der softwaredefinierten DCS-Umgebung 200 emuliert wird. Somit können Legacy- oder andere Softwareanwendungen in die softwaredefinierte DCS-Umgebung integriert werden, als ob sie in separaten Computergeräten in der physischen Prozessanlage 100 ausgeführt werden. Als ein anderes Beispiel können die anderen DCS-Anwendungen 229 eine Echtzeit-Prozessmodellanwendung enthalten, die konfiguriert ist, die Prozessregelkreise der virtuellen Steuerungen 212 während des Betriebs des Prozesses zu optimieren, abzustimmen oder auf andere Weise anzupassen (z. B. durch Durchführen einer adaptiven Prozesssteuerung, um Prozessmodelle basierend auf variablen Anlagenparametern auszuwählen oder anzupassen). Als zusätzliches Beispiel können die anderen DCS-Anwendungen 229 eine Sicherheitsrichtlinien-Manager-Anwendung enthalten, die konfiguriert ist, softwaredefinierte Sicherheitsberechtigungen oder Richtlinien für die verschiedenen Komponenten der softwaredefinierten DCS-Umgebung 200 festzulegen, wie etwa Betriebsumgebungen (z. B. Hypervisor-Umgebungen oder Software-Container), virtuelle Knoten (z. B. Feldgeräte, Router oder Switches), softwaredefinierte Prozesssteuerungen (z. B. virtuelle DCS-Steuerungen 212, Steuermodule, Funktionsblöcke) oder andere DCS-Anwendungen. Als weiteres Beispiel können die anderen DCS-Anwendungen 229 eine Netzwerkarchitektur-Konfigurationsanwendung enthalten, die konfiguriert ist, physische Netzwerkkomponenten in der Feldumgebung 102 (z. B. Switches oder Router) automatisch zu erkennen und diese physischen Netzwerkkomponenten für die Kommunikation innerhalb des Kommunikationsnetzwerks in der Feldumgebung 102 zu konfigurieren. In einigen solchen Ausführungsformen kann die Netzwerkarchitektur-Konfigurationsanwendung ferner die I/O-Verbindungen 240 für die Kommunikation zwischen der Feldumgebung 102 und der Servergruppe 210 konfigurieren.
In einigen Ausführungsformen kann die Servergruppe 210 kommunikativ mit einer oder mehreren zusätzlichen Servergruppen 210 gekoppelt sein, die der physischen Prozessanlage 100 oder anderen Prozessanlagen oder anderen Systemen zugeordnet sind. In einigen solchen Ausführungsformen können die anderen Servergruppen 210 konfiguriert sein, Teile der physischen Prozessanlage 100 zu betreiben. In ähnlicher Weise können in weiteren Ausführungsformen die virtuellen DCS-Steuerungen 212 der Servergruppe 210 nur einen Teil der physischen Prozessanlage 100 steuern, wobei eine oder mehrere physische Steuerungen 110 kommunikativ mit der Servergruppe 210 verbunden sind, um andere Teile des physischen Prozessanlage 100 in einer hybriden Steuerungsarchitektur zu steuern. In einigen solchen Hybridsteuerungsarchitekturen können die physischen Steuerungen 110 dennoch als Knoten innerhalb der softwaredefinierten DCS-Umgebung 200 dargestellt werden, um hardwareunabhängige Interaktionen zwischen diesen Steuerungen 110 und anderen Komponenten in der softwaredefinierten DCS-Architektur zu ermöglichen.
Servergruppe für softwaredefinierte DCS-Umgebung
3 zeigt ein Blockdiagramm einer beispielhaften redundanten Servergruppe 300, die eine softwaredefinierte DCS-Umgebung 200 implementiert, wie beispielsweise die in 2A und 2B dargestellte Servergruppe 210. Wie zuvor beschrieben, kann die von der Servergruppe 210 implementierte softwaredefinierte DCS-Umgebung 200 mehrere virtuelle DCS-Steuerungen 212 (oder andere softwaredefinierte Prozesssteuerungen) und mehrere DCS-Anwendungen 221-225, 229 enthalten. Um diese Softwarekomponenten zu implementieren, kann die Servergruppe 210 mehrere Server 350a-n enthalten, die von einem Steuerungsmanager 352 gesteuert werden, wie in der redundanten Servergruppe 300 in 3 dargestellt. Durch Implementieren der virtuellen DCS-Steuerungen 212 und der DCS-Anwendungen 221-225, 229 in den mehreren Servern 350a-n erleichtert die redundante Servergruppe 300 sowohl einen effizienten Lastenausgleich zwischen den Servern 350a-n als auch eine robuste Failover-Fähigkeit, falls Server 350a-n ausfallen. Somit können mehrere Instanzen jeder der virtuellen DCS-Steuerungen 212 gleichzeitig auf verschiedenen Servern 350a-n ausgeführt werden, wobei Instanzen der virtuellen DCS-Steuerungen 212 Steuermodule 314a-n und redundante Module 318a-n enthalten können, die von dem Steuerungsmanager 352 koordiniert werden. Basierend auf den Status (z. B. Verfügbarkeit) der Server 350a-n kann der Steuerungsmanager 352 einen automatischen Lastenausgleich zwischen den Servern 350a-n durchführen, indem er Module zwischen den Servern 350a-n zuweist.
In einigen Ausführungsformen können die Server 350a-n und der Steuerungsmanager 352 jeweils einen oder mehrere Blades enthalten, die in einem oder mehreren Server-Racks verbunden sind, um die redundante Servergruppe 300 auszubilden. Jedes der Blades 350a-n, 352 kann eine dünne elektronische Leiterplatte mit einem oder mehreren Prozessoren und einem Speicher sein. Die Prozessoren in jedem der Blades 350a-n, 352 können Mehrkernhardware enthalten, wie beispielsweise einen Mehrkernprozessor oder einen anderen Typ von Parallelprozessor. Zusätzlich kann der Speicher in jedem der Blades 350a-n, 352 eine Speichertechnologie mit hoher Dichte enthalten, beispielsweise einen Festkörperspeicher, einen Halbleiterspeicher, einen optischen Speicher, einen molekularen Speicher, einen biologischen Speicher oder eine andere geeignete Speichertechnologie mit hoher Dichte. In einigen Ausführungsformen kann der Speicher auch einen Flash-Speicher enthalten. Der Speicher (und in einigen Fällen der Flash-Speicher) kann konfiguriert sein, Daten vorübergehend zu speichern oder zwischenzuspeichern, die von dem jeweiligen Blade 350a-n, 352 erzeugt, empfangen oder auf andere Weise von diesem beobachtet werden.
In jedem Fall enthält jeder Server 350a-n Steuerroutinen oder -module, die einer Teilmenge der Feldgeräte 125-132, 140-150 entsprechen, um mindestens einen Teil des Prozesses innerhalb der physischen Prozessanlage 100 zu steuern. Während mehrere Server 350a-n innerhalb der redundanten Servergruppe 300 Steuersignale an dieselbe Teilmenge der Feldgeräte 125-132, 140-150 liefern können, liefern mehrere Server 350a-n möglicherweise keine Steuersignale an dasselbe Feldgerät und/oder für die gleichen Parameter innerhalb des gleichen Zeitintervalls. Beispielsweise liefern ein erster Server 350a und ein zweiter Server 350b möglicherweise keine Steuersignale an dasselbe Ventil, die das Ventil anweisen, innerhalb desselben Zeitintervalls zu öffnen oder zu schließen. In einigen Ausführungsformen weist der Steuerungsmanager 352 den Servern 350a-n Steuermodule zu, so dass mehrere Server 350a-n keine Steuersignale an dasselbe Feldgerät und/oder für dieselben Parameter innerhalb desselben Zeitintervalls liefern können. Zusätzlich oder alternativ kann ein Steuerüberwachungsmodul innerhalb der redundanten Servergruppe 300 die Steuerausgänge von den Servern 350a-n überwachen, um zu bestimmen, ob zwei Steuerausgänge zu demselben Feldgerät gehen und/oder für denselben Parameter innerhalb desselben Zeitintervalls bestimmt sind. In diesem Fall kann das Steuermonitormodul die Steuersignale überschreiben, um sicherzustellen, dass nur eines der Steuersignale an das Feldgerät geliefert wird. Das Steuerüberwachungsmodul kann auch eine Anforderung an einen der Server 350a-n oder an den Steuerungsmanager 352 bereitstellen, die Bereitstellung von Steuersignalen an das Feldgerät während des Zeitintervalls zu beenden. Es können jedoch mehrere Server 350a-n innerhalb desselben Zeitintervalls Ausgaben von desselben Feldgeräts empfangen, wie beispielsweise den Prozentsatz der Ventilöffnung von demselben Ventil.
In einigen Ausführungsformen kann für jede(s) der Steuerroutinen oder Module, die von den Servern 350a-n ausgeführt werden, einer der Server 350a-n ein Redundanzmodul enthalten. Das Redundanzmodul kann dazu führen, dass der Server 350b, der das Redundanzmodul ausführt, mit dem Server 350a synchron bleibt, der das Steuermodul ausführt, so dass der Server 350b, der das Redundanzmodul ausführt, verfügbar ist, um das Steuermodul zu übernehmen und auszuführen, wenn der Server 350a, der das Steuermodul gerade ausgeführt, ausfällt. Um mit dem Server 350a, der das Steuermodul ausführt, synchron zu bleiben, kann das Redundanzmodul bewirken, dass der Server 350b, der das Redundanzmodul ausführt, dieselben Eingaben, Ausgänge, Sollwerte usw. empfängt, die von dem Server 350a empfangen und bereitgestellt werden, der das Steuermodul ausführt. Der Server 350a, der das Steuermodul ausführt, kann ein anderer Server oder ein anderes Blade sein als der Server 350b, der das Redundanzmodul ausführt. Ähnlich wie bei den Steuermodulen können die Redundanzmodule Software, Firmware, Hardware usw. sein. Redundanzmodule können in jedem gewünschten Softwareformat implementiert werden, wie z. B. durch objektorientierte Programmierung, Kontaktplan, Ablaufsprachen, Funktionsblockdiagramm oder durch Einsatz jedweder anderer Software-Programmiersprache oder jedweder anderer Design-Paradigmen.
Ferner enthält in mehreren Ausführungsformen jeder Server 350a-n DCS-Anwendungsmodule 316a-n, um die zuvor erörterten DCS-Anwendungen 221-225, 229 zu implementieren. Ähnlich wie bei den Steuermodulen 314a-n können die DCS-Anwendungsmodule 316a-n Software, Firmware, Hardware usw. sein. Die DCS-Anwendungsmodule 316a-n können in jedem gewünschten Softwareformat implementiert werden, wie z. B. durch objektorientierte Programmierung, Kontaktplan, Ablaufsprachen, Funktionsblockdiagrammen oder durch Einsatz jedweder anderer Software-Programmiersprachen oder jedweder anderer Design-Paradigmen.
Zusätzlich zu den Servern 350a-n umfasst die redundante Servergruppe 300 einen Steuerungsmanager 352, der den Servern 350a-n Steuermodule, Redundanzmodule, DCS-Anwendungsmodule und andere geeignete Operationen zuweist. In einigen Ausführungsformen ist der Steuerungsmanager 352 in Hardware implementiert und ist einer der Blades innerhalb der Blade-Server. In anderen Ausführungsformen ist der Steuerungsmanager 352 eine Softwareanwendung, die in einem der Blades 350a-n, 352 in der redundanten Servergruppe 300 implementiert sein kann. Die redundante Servergruppe 300 kann einen einzelnen Steuerungsmanager 352 enthalten, der auf einem einzelnen Blade implementiert ist und die Steuerung für jede der Steuerungen innerhalb mehrerer Blade-Server verwaltet. In anderen Ausführungsformen kann der Steuerungsmanager 352 über mehrere Blades implementiert sein. In noch anderen Ausführungsformen kann die redundante Servergruppe 300 einen oder mehrere Rack-Server mit jeweils mehreren Montageschlitzen enthalten, so dass die Blades 350a-n, 352 den Schächten 350a-n, 352 in den Rack-Servern entsprechen.
In anderen Ausführungsformen umfasst die redundante Servergruppe 300 Cloud-Server in einer Cloud-Computing-Umgebung, Fog-Server in einer Fog-Computing-Umgebung, in der die Fog-Computing-Umgebung beispielsweise von der Organisation gehostet wird, die die physische Prozessanlage 100 betreibt, oder eine beliebige geeignete Kombination daraus. Während beispielsweise eine Cloud-Computing-Umgebung Server enthalten kann, die Prozesse in Prozessanlagen in den Vereinigten Staaten oder sogar der Welt steuern, kann die Fog-Computing-Umgebung Server enthalten, die Prozesse in den physischen Prozessanlagen 100 in einer bestimmten Stadt steuern.
Der Steuerungsmanager 352 kommuniziert mit den verschiedenen Servern 350a-n in der redundanten Servergruppe 300. Jeder der Server 350a-n und der Steuerungsmanager 352 können physische Maschinen (z. B. Hardware) oder virtuelle Maschinen (z. B. Software) sein. Auf diese Weise kann ein einzelnes Blade mehrere virtuelle Gastmaschinen oder Server hosten. In jedem Fall umfasst der Steuerungsmanager 352 eine Steuerungsleitung 354, einen Lastenausgleicher 302, eine Schattendatenbank 304, einen Redundanzmanager 306 und Steuerungsmodule 308. Jeder der Server 1-N (Ref. Nr. 350a-n) enthält einen Prozessor 310an, wie beispielsweise einen Mehrkernprozessor oder einen anderen Typ eines Parallelprozessors, und einen Speicher 312a-n, der ein Speicher hoher Dichte sein kann. Jeder der Speicher 312a-n kann verschiedene Routinen speichern, die dem jeweiligen Server 350a-n zugewiesen sind, einschließlich Steuermodulen 314a-n, DCS-Anwendungsmodulen 316a-n und Redundanzmodulen 318a-n.
Zusätzlich zum Speichern und Ausführen von Routinen zum Steuern und Überwachen von Vorgängen innerhalb der physischen Prozessanlage 100 können die Server 350a-n dem Steuerungsmanager 352 Hinweise auf Verfügbarkeit oder Status liefern. In einigen Ausführungsformen stellt jeder der Server 350a-n dem Steuerungsmanager 352 eine Verfügbarkeitsmetrik für ein bestimmtes Zeitintervall bereit, die auf der Last auf dem Server 350a-n, der verfügbaren Speichermenge auf dem Server 350a-n und der Bandbreite zum Übertragen von Daten vom Server 350a-n in dem bestimmten Zeitintervall basiert. In anderen Ausführungsformen stellt jeder der Server 350a-n Angaben zu der Last auf dem Server 350an, der verfügbaren Speichermenge auf dem Server 350a-n und der Bandbreite zum Übertragen von Daten vom Server 350a-n für ein bestimmtes Zeitintervall bereit. Der Steuerungsmanager 352 bestimmt dann eine Verfügbarkeitsmetrik für das bestimmte Zeitintervall für jeden Server 350a-n basierend auf diesen Informationen. Die Last auf dem Server 350a-n kann den Verarbeitungsaufwand, der von dem Server 350a-n ausgeführt wird, sowie die Verarbeitungsfähigkeiten des Servers 350a-n (z. B. Single Core, Dual Core, Quad Core usw.) anzeigen. Die Verfügbarkeitsmetrik kann, basierend auf einem Fehler des Servers, eine Anzeige bereitzustellen oder auf den Steuerungsmanager 352 zu antworten, auch ausgefallene oder anderweitig nicht verfügbare Server berücksichtigen.
Die Steuerungsleitung 354 am Steuerungsmanager 352 kann Operationen empfangen, die von den Servern 350a-n in der redundanten Servergruppe 300 ausgeführt werden sollen. In einigen Ausführungsformen erzeugt der Redundanzmanager 306 ein Redundanzmodul für jedes Steuermodul 308, das von dem Steuermanager 352 erhalten wird. Das Redundanzmodul kann bewirken, dass der Server 350a-n, der das Redundanzmodul ausführt, dieselben Ein-, Ausgänge, Sollwerte usw. empfängt, die von dem Server 350a-n empfangen und bereitgestellt werden, der das Steuermodul ausführt, ohne die in dem Steuerungsmodul enthaltenen Steuerungsschleifen oder -funktionen auszuführen. In manchen Ausführungsformen stellt die Steuerungsleitung 354 jedes der erhaltenen Steuermodule 308 dem Redundanzmanager 306 zur Verfügung, damit der Redundanzmanager ein entsprechendes Redundanzmodul erzeugt.
Ebenfalls in manchen Ausführungsformen weist die Steuerungsleitung 354 jedem der Steuermodule, Redundanzmodule und DCS-Anwendungsmodule eine Prioritätsstufe zu und ordnet die Module in der Reihenfolge ihrer Priorität. Prioritätsstufen können automatisch basierend auf einem vorbestimmten Satz von Prioritätsregeln zugewiesen werden (z. B. hat ein Redundanzmodul dieselbe Prioritätsstufe wie ein entsprechendes Steuermodul, Steuermodule haben höhere Prioritätsstufen als DCS-Anwendungsmodule usw.). Zusätzlich oder alternativ dazu kann ein Benutzer die Prioritätsstufe für jedes der Module zuweisen. Wenn ein Konfigurationsingenieur beispielsweise ein Steuermodul über eine Konfigurationsanwendung generiert, kann der Konfigurationsingenieur dem Steuermodul auch eine Prioritätsstufe zuweisen.
Die Steuerungsleitung 354 kann mit dem Lastenausgleicher 302 kommunizieren, um zu bestimmen, welcher Server 350a-n welche Steuermodule 308, Redundanzmodule und DCS-Anwendungsmodule während eines bestimmten Zeitintervalls ausführen soll. In einigen Ausführungsformen empfängt der Lastenausgleicher 302 eine Verfügbarkeitsmetrik für jeden der Server 350a-n und eine Liste von Steuermodulen, Redundanzmodulen und DCS-Anwendungsmodulen, die innerhalb eines bestimmten Zeitintervalls ausgeführt werden sollen, die entsprechende Prioritätsstufen für jedes der Module enthalten können. Der Lastenausgleicher 302 weist dann einen Server 350a-n in der redundanten Servergruppe 300 zu, um jedes der Module auszuführen. In einigen Szenarien kann ein einzelner Server 350a-n abhängig von den Parallelverarbeitungsfähigkeiten und der Speicherdichte des Servers 350a-n mehrere Module innerhalb desselben Zeitintervalls ausführen. In einem anderen Beispielszenario identifiziert der Lastenausgleicher 302 zwei verschiedene Server 350a-n, um ein Steuermodul und ein Redundanzmodul auszuführen, so dass der Server 350a-n, der das Redundanzmodul ausführt, im Falle eines Ausfalls an der Steuerung für den Server 350a-n, der das Steuermodul ausführt, übernehmen kann.
In einigen Ausführungsformen identifiziert der Lastenausgleicher 302 Merkmale jedes der Module, beispielsweise ob jedes Modul periodisch ausgeführt wird oder basierend auf dem Auftreten eines Ereignisses (ereignisgesteuert), der Ausführungszeit für jedes Modul oder anderen geeigneten Merkmalen. Dann identifiziert der Lastenausgleicher 302 die Server 350an, um die Module basierend auf den Verfügbarkeitsmetriken für die Server 350a-n und den Prioritätsstufen und Eigenschaften der Module auszuführen. Insbesondere verwendet der Lastenausgleicher 302 einen Lastenausgleichalgorithmus, um Server 350a-n zuzuweisen, um die Module auszuführen.
Beispielsweise kann der Lastenausgleicher 302 jeden der Server 350a-n gemäß ihren jeweiligen Verfügbarkeitsmetriken einstufen, wobei der Server 350a-n mit der höchsten Verfügbarkeitsmetrik die größte Verfügbarkeit aufweist und am höchsten eingestuft wird. Der Lastenausgleicher 302 kann auch jedes der Module basierend auf einer Kombination der Prioritätsstufe und der Eigenschaften für jedes Modul bewerten. In einigen Ausführungsformen werden periodische Module über ereignisgesteuerten Modulen eingestuft, dann wird jedes der periodischen Module basierend auf der Prioritätsstufe kategorisiert und jedes der ereignisgesteuerten Module wird basierend auf der Prioritätsstufe kategorisiert. Jedes der periodischen Module in der Kategorie mit hoher Priorität kann über jedem der periodischen Module in der Kategorie mit mittlerer Priorität usw. eingestuft werden. Periodische oder ereignisgesteuerte Module in derselben Prioritätskategorie können basierend auf der Ausführungszeit weiter eingestuft werden. Insbesondere wenn drei Prioritätskategorien (hoch, mittel und niedrig) sowie periodische und ereignisgesteuerte Module vorhanden sind, können die periodischen Module mit hoher Priorität an erster Stelle stehen, wobei jedes Modul in dieser Kategorie in der Reihenfolge der Ausführungszeit weiter eingestuft wird durch die periodischen Module mit mittlerer Priorität, gefolgt von den periodischen Modulen mit niedriger Priorität, gefolgt von den ereignisgesteuerten Modulen mit hoher Priorität usw.
Dementsprechend kann der Lastenausgleicher 302 die Server 350a-n und die Module bewerten. Während die Server 350a-n im obigen Beispiel in der Reihenfolge der Verfügbarkeitsmetriken und die Module in der Reihenfolge der Prioritätsstufen und Moduleigenschaften eingestuft werden, können die Server 350a-n und Module auf jede geeignete Weise eingestuft werden.
Dann kann der Lastenausgleicher 302 ein umgekehrtes Rundlaufverfahren verwenden, um zuerst das Modul mit dem höchsten Rang (z. B. ein periodisches Modul mit hoher Priorität mit der längsten Ausführungszeit) dem Server mit dem höchsten Rang 350a-n (z. B. der Steuerung mit der höchsten Verfügbarkeitsmetrik) zuzuweisen. Das zweithöchste Modul kann dem zweithöchsten Server 350a-n zugewiesen werden, und der Algorithmus kann auf diese Weise fortgesetzt werden, bis dem Server 350a-n mit dem niedrigsten Rang ein Modul zugewiesen wird. Wenn mehr Module zuzuweisen sind, weist der Lastenausgleicher 302 weiterhin Module in umgekehrter Reihenfolge zu. Beispielsweise weist der Lastenausgleicher 302 das nächste Modul auch dem Server 350a-n mit dem niedrigsten Rang zu und ordnet dann das Modul hinter dem nächsten eingestufte Modul dem Server 350a-n mit dem niedrigsten Rang zu und fährt in aufsteigender Reihenfolge fort, bis dem Server 350a-n mit dem höchsten Rang zwei Module zugeordnet sind. Dann kehrt der Lastenausgleicher 302 die Reihenfolge zum Zuweisen von Modulen in absteigender Reihenfolge erneut um und fährt im umgekehrten Rundlaufverfahren fort, bis jedes der Module den Servern 350a-n zugewiesen ist.
Während der Lastenausgleicher 302 die Server 350a-n und die Module einstufen und ein umgekehrtes Rundlaufverfahren verwenden kann, um den Servern 350a-n Module zuzuweisen, kann der Lastenausgleicher 302 den Servern 350a-n Module auf jede geeignete Weise zuweisen, um die Module unter den Servern 350a-n in der redundanten Servergruppe 300 zu verteilen. In anderen Ausführungsformen sind die Module unabhängig von der Prioritätsstufe oder den Merkmalen gleich oder zumindest ähnlich auf die Server 350a-n verteilt. In weiteren anderen Ausführungsformen weist der Lastenausgleicher 302 dem gleichen Server 350a Module zu, bis die Verarbeitung am Server 350a seine Kapazität erreicht. Dann weist der Lastenausgleicher 302 Module einem anderen Server 350b zu, bis die Verarbeitung auf dem anderen Server 350b seine Kapazität erreicht, und der Lastenausgleicher 302 kann weiterhin Module auf diese Weise zuweisen.
In jedem Fall stellt die Steuerungsleitung 354 dann die zugewiesenen Module den entsprechenden Servern 350a-n zur Verfügung, so dass jeder Server 350a-n die zugewiesenen Module ausführen kann. In einigen Ausführungsformen analysiert die Steuerungsleitung 354 die Zuweisungen und kann manche der Zuweisungen anpassen, um sicherzustellen, dass mehrere Server 350a-n keine Steuersignale an dasselbe Feldgerät und/oder für denselben Parameter innerhalb desselben Zeitintervalls liefern.
In einem beispielhaften Szenario kann einem Server 350a während eines ersten Zeitintervalls ein erster Satz von Modulen zugewiesen werden. Die Steuerungsleitung 354 kann die Steuermodule 314a, DCS-Anwendungsmodule 316a und Redundanzmodule 318a während des ersten Zeitintervalls auf den Server 350a herunterladen. Dann kann dem Server 350a während eines zweiten Zeitintervalls ein zweiter Satz von Modulen zugewiesen werden, der sich von dem ersten Satz von Modulen unterscheidet. Die Steuerungsleitung 354 kann die neuen Steuerungsmodule 314a, DCS-Anwendungsmodule 316a und Redundanzmodule 318a während des zweiten Zeitintervalls auf den Server 350a herunterladen.
In einem anderen beispielhaften Szenario weist der Steuermanager 352 während eines bestimmten Zeitintervalls einem ersten Server 350a ein erstes Steuermodul zu, wobei das erste Steuermodul einer ersten Teilmenge der Feldgeräte 125-132, 140-150 entspricht. Der Steuermanager 352 weist einem zweiten Server 350b ein zweites Steuermodul zu, wobei das zweite Steuermodul einer zweiten Teilmenge der Feldgeräte 125-132, 140-150 entspricht. Der erste Server 350a führt dann das erste Steuerungsmodul aus und der zweite Server 350b führt das zweite Steuerungsmodul innerhalb des gleichen Zeitintervalls aus. Während eines späteren Zeitintervalls wird dem ersten Server 350a nicht mehr das erste Steuerungsmodul zugewiesen, und werden dem zweiten Server 350b sowohl das erste als auch das zweite Steuermodul zugewiesen. Beispielsweise kann der erste Server 350a ausgefallen sein oder nicht über die Verarbeitungsressourcen verfügen, um das erste Steuerungsmodul während des späteren Zeitintervalls auszuführen. Der zweite Server 350b führt dann das erste und das zweite Steuerungsmodul für die erste und die zweite Teilmenge der Feldgeräte 125-132 bzw. 140-150 während des späteren Zeitintervalls aus.
In einigen Ausführungsformen bleiben periodische Module für mehrere Zeitintervalle demselben Server 350a-n zugewiesen, während ereignisgesteuerte Module für jedes Zeitintervall basierend auf den Verfügbarkeitsmetriken der Server 350a-n in dem bestimmten Zeitintervall den Servern 350a-n neu zugewiesen werden können. In anderen Ausführungsformen werden jedes der Steuerungsmodule, DCS-Anwendungsmodule und Redundanzmodule vor der Ausführung (z. B. wenn die Module erzeugt werden) auf jeden der Server 350a-n heruntergeladen und in ihren jeweiligen Speichern 212a-n gespeichert. Wenn die Steuerungsleitung 354 einen Server 350a auswählt, um ein bestimmtes Modul auszuführen, liefert der Steuerungsmanager 352 dem ausgewählten Server 350a eine Anzeige des bestimmten Moduls, und der ausgewählte Server 350a ruft das bestimmte Modul aus dem Speicher 312a ab und führt das bestimmte Modul durch den Prozessor 310a aus.
In einigen Ausführungsformen umfasst der Steuerungsmanager 352 eine Schattendatenbank 304, die Eingabedaten für die Steuerungsmodule, Redundanzmodule und DCS-Anwendungsmodule speichert. Eingabedaten für die Module können von Benutzerschnittstellenvorrichtungen 170b erhalten werden, wenn die Module beispielsweise konfiguriert oder erzeugt werden. Die Eingabedaten können auch von den Servern 350a-n erhalten werden, wenn die Server 350a-n die Steuerungsmodule 314a-n und die DCS-Anwendungsmodule 316a-n ausführen. Ausgaben von den Steuerungsmodulen 314a-n und den DCS-Anwendungsmodulen 316a-n können in der Schattendatenbank 304 von den Servern 350a-n empfangen und als Eingabedaten für Steuermodule, Redundanzmodule und DCS-Anwendungsmodule gespeichert werden, die während der nachfolgenden Zeitintervalle ausgeführt werden.
In einigen Ausführungsformen kann der Steuerungsmanager 352 ferner Verfügbarkeitsinformationen bezüglich des Status oder der Verfügbarkeit der Server 350a-n bereitstellen. Diese Informationen können Gesamtlast- oder Verfügbarkeitsmetriken für die redundante Servergruppe 300, Verfügbarkeitsmetriken für die einzelnen Server 350a-n, Betriebsstatus der einzelnen Server 350a-n (z. B. betriebsbereit oder nicht betriebsbereit) oder andere ähnliche Metriken umfassen. In einigen Ausführungsformen kann der Steuerungsmanager 352 ferner Verwendungsinformationen bezüglich der Ressourcennutzung innerhalb der redundanten Servergruppe 300 bereitstellen, wobei diese Informationen die Verarbeitungsressourcen angeben, die zum Ausführen der Steuerungsmodule, Redundanzmodule und DCS-Anwendungsmodule in den Servern 350a-n benötigt werden oder voraussichtlich benötigt werden. Aus den Verfügbarkeitsinformationen und Nutzungsinformationen kann der Steuerungsmanager 352 ferner eine optimale Ressourcenzuweisung für die redundante Servergruppe 300 berechnen oder vorhersagen, wie beispielsweise eine Anzahl oder einen Typ von Servern 350a-n, die innerhalb der redundanten Servergruppe 300 verbunden werden sollen. Eine solche Berechnung oder Vorhersage kann einem Bediener vorgelegt werden, um Anpassungen an der Hardwarekonfiguration der redundanten Servergruppe 300 zu ermöglichen (z. B. Hinzufügen oder Ersetzen von Servern). In einigen Ausführungsformen kann eine solche Berechnung oder Vorhersage von einer DCS-Anwendung durchgeführt werden, wie beispielsweise einer Anlagenverwaltungsanwendung 223 oder einer anderen DCS-Anwendung 229.
Konfiguration und Betrieb einer softwaredefinierten DCS-Umgebung
4 zeigt ein Flussdiagramm eines beispielhaften softwaredefinierten DCS-Konfigurations- und Steuerverfahrens 400 für eine physische Prozessanlage 100, die von softwaredefinierten Prozesssteuerungen einer softwaredefinierten DCS-Umgebung 200 gesteuert wird. Das virtuelle DCS-Konfigurations- und Steuerverfahren 400 kann durchgeführt werden, um ein Prozessleitsystem einzurichten, zu betreiben, zu überwachen und anzupassen, um einen Prozess innerhalb einer physischen Prozessanlage 100 unter Verwendung einer softwaredefinierten DCS-Umgebung 200, wie der oben beschriebenen, zu betreiben. Einige Aspekte des softwaredefinierten DCS-Konfigurations- und Steuerverfahrens 400 können manuell durchgeführt oder in einigen Ausführungsformen automatisiert werden. Alternative Ausführungsformen können zusätzliche, weniger oder alternative Aspekte umfassen.
Das softwaredefinierte DCS-Konfigurations- und Steuerverfahren 400 beginnt mit der Verbindung von mindestens einigen der Feldgeräte 125-132, 140-150 mit der Servergruppe 210 über die I/O-Verbindungen 240 (Block 402). Dies kann das physische Anschließen der Feldgeräte 125-132, 140-150 während der physischen Installation innerhalb der Anlage oder beim Hinzufügen eines Feldgeräts zu einem vorhandenen Prozesssteuerungsnetzwerk einschließen. In einigen Ausführungsformen können die Feldgeräte 125-132, 140-150 verbunden werden, indem softwaredefinierte Kommunikationsverbindungen über die I/O-Verbindungen 240 nach der Installation in der Anlage hergestellt werden, beispielsweise durch Herstellen von Veröffentlichungs-/Abonnementverbindungen in einem I/O-Server. In einigen Ausführungsformen müssen möglicherweise nicht alle Feldgeräte 125-132, 140-150 zur Steuerung eines Prozesses mit der Servergruppe 210 verbunden sein, und einige Feldgeräte 140-150 können stattdessen über ein drahtloses Gateway 168 in einigen Ausführungsformen direkt mit der Servergruppe 210 verbunden werden.
Sobald die relevanten Feldgeräte 125-132, 140-150 mit der Servergruppe 210 verbunden sind, wird die softwaredefinierte DCS-Netzwerkarchitektur konfiguriert, das Prozesssteuerungsnetzwerk der Feldumgebung 102 als ein softwaredefiniertes Netzwerk von Knoten und Verbindungen innerhalb der softwaredefinierten DCS-Umgebung 200 darzustellen (Block 404). Um die softwaredefinierte DCS-Netzwerkarchitektur zu konfigurieren, kann die Konfigurationsanwendung 225 für die virtuelle Architektur eine Benutzerschnittstelle erzeugen und einem Benutzer (z. B. einem Techniker, der das Prozessleitsystem konfiguriert) präsentieren, wobei diese Benutzerschnittstelle mehrere Optionen zum Konfigurieren von Komponenten und Verbindungen innerhalb des softwaredefinierten DCS-Netzwerks enthalten kann. Auf diese Weise können dem Benutzer Optionen zum Hinzufügen, Entfernen, Bearbeiten, Verbinden und Festlegen von Parametern der softwaredefinierten Komponenten über die Benutzeroberfläche angezeigt werden. Nach dem Empfang von Benutzereingaben vom Benutzer kann die Konfigurationsanwendung 225 für die virtuelle Architektur die softwaredefinierte DCS-Netzwerkarchitektur definieren, indem die Knoten und Verbindungen innerhalb des softwaredefinierten DCS-Netzwerks basierend auf den Benutzereingaben angegeben werden. Zusätzlich oder alternativ dazu kann ein Teil oder die gesamte softwaredefinierte DCS-Netzwerkarchitektur automatisch von der Konfigurationsanwendung 225 für die virtuelle Architektur basierend auf Informationen bezüglich des Typs von Prozessdaten bestimmt werden, die von den Komponenten der Feldumgebung 102, wie etwa den Feldgeräten, empfangen werden 123-132, 140-150. Die Informationen bezüglich der Arten von Prozessdaten werden basierend auf dem Datenverkehr von den Feldgeräten 123-132, 140-150 an den I/O-Verbindungen 240 bestimmt. In manchen solchen Ausführungsformen können Informationen bezüglich der Arten von Prozessdaten, die von solchen Komponenten der Feldumgebung 102 empfangen werden, von der Konfigurationsanwendung 225 für die virtuelle Architektur von den I/O-Verbindungen 240 (z. B. von einem I/O-Server) erhalten werden. In weiteren solchen Ausführungsformen können die bestimmten Arten von Prozessdaten dem Bediener über eine Benutzerschnittstelle der Konfigurationsanwendung 225 für die virtuelle Architektur zur Bestätigung oder Anpassung präsentiert werden. Die softwaredefinierte DCS-Netzwerkarchitektur wird dann in den Datenbanken oder Datenspeichern 230 der Servergruppe 210 zur Verwendung durch die softwaredefinierten Prozesssteuerungen und DCS-Anwendungen (z. B. die virtuellen DCS-Steuerungen 212 und die DCS-Anwendungen 221-225, 229) gespeichert.
In manchen Ausführungsformen stellt die softwaredefinierte DCS-Netzwerkarchitektur mehrere Dienstklassen für die verschiedenen Komponenten mit der softwaredefinierten DCS-Umgebung bereit, um eine angemessene Behandlung der Ressourcenanforderungen sicherzustellen. Beispielsweise wird Echtzeitprozessen (z. B. Prozesssteuerung durch die Steuerungsmodule) eine Klasse mit hoher Priorität zugewiesen, um sicherzustellen, dass zeitkritische Prozesssteuerungsroutinen Vorrang vor Analyseprozessen der DCS-Anwendungen haben. In weiteren Ausführungsformen können mehrere Klassen von Echtzeitprozessen verwendet werden, um prozesskritischen oder sicherheitsrelevanten Prozessen eine höhere Priorität einzuräumen. Auf ähnliche Weise können Klassen auf Bandbreitenanforderungen von Prozessen innerhalb der softwaredefinierten DCS-Umgebung 200 basieren oder verwendet werden, um diese zu differenzieren.
Die Servergruppe 210 ist dann bereit, die Prozesssteuerung durchzuführen. Während des Betriebs der physischen Prozessanlage 100 empfangen die softwaredefinierten Prozesssteuerungen (z. B. virtuelle DCS-Steuerungen 212) Prozessdaten von den Feldgeräten 125-132, 140-150 (Block 406) und implementieren eine Prozesssteuerungslogik, um den Prozess in Echtzeit zu steuern (Block 408). Die Prozessdaten können von einem oder mehreren der Feldgeräte 125-132, 140-150 über die I/O-Verbindungen 240 erzeugt und von diesen empfangen werden. Zumindest ein Teil dieser Prozessdaten wird dann von den softwaredefinierten Prozesssteuerungen verwendet, um Prozesssteuersignale zur Steuerung des Prozesses in der physischen Prozessanlage 100 zu erzeugen. Diese Prozesssteuersignale werden dann an ein oder mehrere der Feldgeräte 125-132, 140-150 gesendet, um Steueraktionen zur Steuerung des Prozesses durchzuführen (z. B. Einstellen einer Ventilposition oder Steuern eines Heizelements). Die Prozesssteuersignale können über die I/O-Verbindungen 240 an die relevanten Feldgeräte 125-132, 140-150 gesendet werden.
Auch während des Betriebs des Prozesses implementiert die Servergruppe 210 eine oder mehrere der DCS-Anwendungen 221-225, 229, um mit den softwaredefinierten Prozesssteuerungen zu interagieren (Block 410). Die DCS-Anwendungen 221-225, 229 können in der Servergruppe 210 ausgeführt werden. In manchen Ausführungsformen kann die Bedienerschnittstellenanwendung 222 ausgeführt werden, um den Betrieb einer oder mehrerer der softwaredefinierten Prozesssteuerungen anzupassen, beispielsweise durch Einstellen von Sollwerten oder Einstellen der Steuerungsmodule, die von den softwaredefinierten Prozesssteuerungen zur Verbesserung der Prozesssteuerung verwendet werden. Diese Anpassungen können automatisch von den DCS-Anwendungen 221-225, 229 oder als Reaktion auf Benutzereingaben vorgenommen werden. Natürlich kann jede Kombination der DCS-Anwendungen 221-225, 229 implementiert werden, während der Prozess in der physischen Prozessanlage 100 ausgeführt wird oder zu einem anderen Zeitpunkt vor, nach oder zwischen der Implementierung des Prozesses. Beispielsweise kann die Data-Historian-Anwendung 224 ausgeführt werden, während der Prozess abläuft, um Prozessdaten in der softwaredefinierten DCS-Umgebung 200 zu überwachen und diese Prozessdaten zur späteren Analyse in einer Datenbank oder einem Datenspeicher 230 zu speichern. Diese Überwachung kann das Auswählen einer Teilmenge der verfügbaren Prozessdaten umfassen (z. B. durch Abtasten der Prozessdaten oder durch Auswählen relevanter Daten, die von der Feldumgebung 102 empfangen oder von den virtuellen DCS-Steuerungen 212 erzeugt werden), oder die Data-Historian-Anwendung 224 kann konfiguriert sein, um alle verfügbare Prozessdaten während des Betriebs der physischen Prozessanlage 100 automatisch zu überwachen und zu speichern.
In einigen Ausführungsformen kann die Servergruppe 210 auch einen Lastenausgleich zwischen Servern oder anderen Servergeräten in der Servergruppe 210 während des Betriebs des Prozesses (Block 412) durchführen, wie zuvor erörtert. Um diesen Lastenausgleich durchzuführen, kann die Servergruppe 210 gleichzeitig mehrere Instanzen jeder der softwaredefinierten Prozesssteuerungen (oder Steuerungsmodule davon) auf verschiedenen Servern innerhalb der Servergruppe 210 implementieren. Beim Erkennen einer Änderung des Status eines der Server (z. B. Ausfall des Servers, Hinzufügen des Servers, Lastsprung am Server oder Lastabfall am Server) passt die Servergruppe 210 die Lastverteilung zwischen dem mehreren Servern innerhalb der Servergruppe 210 basierend auf der erfassten Änderung an, um eine effiziente Steuerung des Prozesses durch die softwaredefinierten Prozesssteuerungen aufrechtzuerhalten. Diese Anpassung an die Lastverteilung kann das Verschieben der Steuerung eines Teils des Prozesses von einer Instanz einer virtuellen DCS-Steuerung 212, die auf einem ersten Server ausgeführt wird, zu einer anderen Instanz der virtuellen DCS-Steuerung 212, die beispielsweise auf einem zweiten Server ausgeführt wird, umfassen. In einigen solchen Ausführungsformen kann eine neue Instanz der virtuellen DCS-Steuerung 212 auch auf einem dritten Server der Servergruppe 210 initiiert werden, um die Redundanz aufrechtzuerhalten und vor einem nachfolgenden Ausfall des zweiten Servers zu schützen.
In weiteren Ausführungsformen kann die Servergruppe 210 einen Hinweis auf eine Modifikation der Netzwerkarchitektur der Feldumgebung 102 (Block 414) erhalten und kann die softwaredefinierte DCS-Netzwerkarchitektur modifizieren, um diese Modifikation widerzuspiegeln (Block 416). Ähnlich wie bei der Erstkonfiguration der softwaredefinierten DCS-Netzwerkarchitektur kann die Anzeige der Änderung der Netzwerkarchitektur von einem Bediener über eine Konfigurationsanwendung 225 für die virtuelle Architektur empfangen werden, oder die Anzeige der Änderung kann automatisch basierend auf dem Erkennen einer Änderung des Typs der Prozessdaten erzeugt werden, die als Datenverkehr an den I/O-Verbindungen 240 empfangen werden. Beispielsweise kann ein Benutzer über eine Benutzereingabe einen Ersatz eines oder mehrerer der Feldgeräte 125-132, 140-150 durch neue Feldgeräte angeben, oder dieser Austausch kann basierend auf einer Änderung des von den neuen Feldgeräten empfangenen Datenverkehrs erkannt werden. Als Reaktion auf diesen Hinweis auf eine Änderung der physischen Netzwerkarchitektur in der Feldumgebung 102 passt die Konfigurationsanwendung 225 für die virtuelle Architektur die softwaredefinierte DCS-Netzwerkarchitektur an, um die modifizierte physische Netzwerkarchitektur darzustellen. Diese Anpassung kann das Hinzufügen, Entfernen oder Ändern von Knoten oder Verbindungen innerhalb der softwaredefinierten DCS-Netzwerkarchitektur einschließen. Diese Änderungen an der softwaredefinierten DCS-Netzwerkarchitektur werden dann zur Verwendung durch die softwaredefinierten Prozesssteuerungen und DCS-Anwendungen in den Datenbanken oder Datenspeichern 230 der Servergruppe 210 gespeichert. In einigen Ausführungsformen kann eine Anpassung an eine oder mehrere der softwaredefinierten Prozesssteuerungen auch basierend auf der Anpassung an die softwaredefinierte DCS-Netzwerkarchitektur bestimmt werden. Beispielsweise kann ein Regelkreis innerhalb einer softwaredefinierten Prozesssteuerung basierend auf dem Hinzufügen, Ersetzen oder Entfernen eines Feldgeräts innerhalb der Feldumgebung 102 angepasst werden, die die Prozessdaten ändert, die für die Prozesssteuerung verfügbar sind.
Das softwaredefinierte DCS-Konfigurations- und Steuerverfahren 400 kann die Prozesssteuerung wie oben beschrieben fortsetzen, bis festgestellt wird, dass der gesteuerte Prozess innerhalb der physischen Prozessanlage 100 nicht länger ausgeführt wird (Block 418). Wenn der Prozess beendet ist, kann auch das softwaredefinierte DCS-Konfigurations- und Steuerverfahren 400 enden.
Weitere Überlegungen
Die folgenden zusätzlichen Überlegungen gelten für die vorhergehende Diskussion. In dieser Spezifikation beziehen sich die von einem Gerät oder einer Routine beschriebenen Aktionen im Allgemeinen auf Aktionen oder Prozesse eines Prozessors, der Daten gemäß maschinenlesbarer Anweisungen manipuliert oder transformiert. Die maschinenlesbaren Anweisungen können auf einer Speichervorrichtung gespeichert und von dieser abgerufen werden, die kommunikativ mit dem Prozessor gekoppelt ist. Das heißt, dass die hierin beschriebenen Verfahren durch einen Satz von maschinenausführbaren Befehlen verkörpert sein können, die auf einem computerlesbaren Medium (d. h. auf einer Speichervorrichtung) gespeichert sind. Wenn die Anweisungen von einem oder mehreren Prozessoren eines entsprechenden Geräts (z. B. eines Servers, eines Bedienerarbeitsplatzes, einer Steuerung, eines Steuermanagers, einer Benutzerrechenvorrichtung usw.) ausgeführt werden, veranlassen die Prozessoren die Ausführung des Verfahrens. Wenn hierin erwähnte Befehle, Routinen, Module, Prozesse, Dienste, Programme und/oder Anwendungen als gespeichert oder in einem computerlesbaren Speicher oder auf einem computerlesbaren Medium abgelegt beschrieben sind, schließen die Wörter „gespeichert“ und „abgelegt“ vorübergehende Signale aus.
Darüber hinaus werden Begriffe wie „Bediener“, „Personal“, „Person“, „Benutzer“, „Techniker“, „Ingenieur“ und ähnliche andere Begriffe verwendet, um Personen in der Umgebung der Prozessanlage zu beschreiben, die den Prozess verwenden oder mit den hier beschriebenen Systemen, Geräte und Verfahren interagieren. Diese Begriffe sollen jedoch nicht einschränkend verstanden werden. Wenn ein bestimmter Begriff in der Beschreibung verwendet wird, wird der Begriff teilweise aufgrund der traditionellen Aktivitäten verwendet, mit denen das Betriebspersonal beschäftigt ist, soll jedoch nicht das Personal beschränken, das an dieser bestimmten Aktivität teilnehmen könnte.
Darüber hinaus können im Laufe diese Schrift Pluralangaben Komponenten, Operationen, oder Strukturen implementieren, die als einzelne Instanz beschrieben werden, sofern nicht ausdrücklich oder implizit durch den Kontext der Beschreibung eingeschränkt. Obwohl einzelne Operationen von einem oder mehreren Verfahren als separate Operationen dargestellt und beschrieben sind, können eine oder mehrere der einzelnen Operationen gleichzeitig ausgeführt werden, und nichts erfordert, dass die Operationen in der dargestellten Reihenfolge ausgeführt werden. Strukturen und Funktionen, die als separate Komponenten in Beispielkonfigurationen dargestellt werden, können als kombinierte Struktur oder Komponente implementiert werden. In ähnlicher Weise können Strukturen und Funktionalität, die als eine einzelne Komponente präsentiert werden, als separate Komponenten implementiert werden. Diese und andere Variationen, Änderungen, Hinzufügungen und Verbesserungen fallen in den Umfang des vorliegenden Gegenstandes.
Sofern nicht ausdrücklich anders spezifiziert, können Erörterungen, die Wörter wie „Verarbeiten“, „Erfassen“, „Berechnen“, „Bestimmen“, „Identifizieren“, „Anzeigen“, „Anzeigen bewirken“, „Darstellungen bewirken“, „Darstellen“ oder dergleichen auf Handlungen oder Prozesse einer Maschine (z. B. eines Computers) beziehen, die als physikalische (z. B. elektronische, biologische, magnetische oder optische) Größen dargestellte Daten innerhalb eines oder mehrerer Speicher (z. B. flüchtiger Speicher, nichtflüchtiger Speicher oder eine Kombination davon), Register oder anderer Maschinenkomponenten, die Informationen empfangen, speichern, übertragen oder anzeigen.
Wenn sie in Software implementiert sind, können beliebige der in dieser Schrift beschriebenen Anwendungen, Steuerungen, Dienste oder Antriebe in jedem materiellen, nicht-flüchtigen computerlesbaren Speicher, beispielsweise auf einer Magnetplatte, einer Laserplatte, einer Festkörper-Speichervorrichtung, einer molekularen Speichervorrichtung oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. gespeichert werden. 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. Daher werden Personen mit einer gewöhnlichen Kompetenz problemlos erkennen, dass die angegebenen Beispiele nicht die einzige Möglichkeit sind, solche Systeme zu implementieren. Während die vorliegende Erfindung unter Bezugnahme auf spezifische Beispiele beschrieben wurde, die nur veranschaulichend sein sollen und die Erfindung nicht beschränken sollen, ist es für den Durchschnittsfachmann offensichtlich, dass Änderungen, Hinzufügungen oder Streichungen möglich sind zu den offenbarten Ausführungsformen gemacht werden, ohne vom Geist und Umfang der Erfindung abzuweichen.
Ebenso versteht sich, dass, außer wenn ein Begriff in diesem Patent ausdrücklich durch den Satz „Bei seiner Verwendung in dieser Schrift wird der Begriff „____“ hiermit definiert, dass er bedeutet ...“ oder einen ähnlichen Satz definiert wird, keine Absicht besteht, die Bedeutung dieses Begriffs, ausdrücklich oder stillschweigend, über seine einfache oder gewöhnliche Bedeutung hinaus zu begrenzen; auch darf dieser Begriff nicht so ausgelegt werden, dass er aufgrund einer Aussage in einem Abschnitt dieses Patents (ausgenommen im Wortlaut der Ansprüche) in seinem Umfang eingeschränkt ist. In dem Maße, in dem jeder in den Ansprüchen am Ende dieses Patents zitierte Ausdruck in diesem Patent in einer mit einer einzigen Bedeutung übereinstimmenden Weise erwähnt wird, erfolgt dies aus Gründen der Klarheit nur, um den Leser nicht zu verwirren, und das ist es auch nicht beabsichtigt, dass ein solcher Anspruchsbegriff implizit oder anderweitig auf diese einzige Bedeutung beschränkt ist. Schließlich soll, sofern ein Anspruchselement nicht mit dem Wort „bedeutet“ definiert wird und eine Funktion ohne Erwähnung von irgendeiner Formel definiert wird, die Bedeutung eines Anspruchselements nicht auf der Grundlage des Antrags 35 USC § 112 (f) interpretiert werden. Obwohl der vorangehende Text eine detaillierte Beschreibung zahlreicher unterschiedlicher Ausführungsformen darstellt, sollte darüber hinaus verstanden werden, dass der Umfang des Patents durch die Worte der Ansprüche definiert ist, die am Ende dieses Patents dargelegt sind. Die detaillierte Beschreibung ist nur als Beispiel zu verstehen und beschreibt nicht jede mögliche Ausführungsform, da das Beschreiben jeder möglichen Ausführungsform unpraktisch wäre, wenn nicht unmöglich wäre. Zahlreiche alternative Ausführungsformen könnten unter Verwendung entweder gegenwärtiger Technologie oder nach dem Anmeldetag dieses Patents entwickelter Technologie umgesetzt werden und würden immer noch in den Geltungsbereich der Ansprüche und allen Entsprechungen davon fallen.
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 7684875 [0020]
US 8332567 [0020]
US 8762618 [0020]
US 8977851 [0020]
US 9083548 [0020]
US 9411769 [0020]
US 9495313 [0020]
US 9946240 [0020]
US 2018/0115516 [0044]
US 2018/0115528 [0044]
US 2018/0115517 [0044]
US 2018/0113442 [0044]

Claims

Prozessleitsystem zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung, Folgendes umfassend: eine Servergruppe, die mehrere Servergeräte umfasst, die konfiguriert sind, eine softwaredefinierte verteilte Steuersystem(DCS)-Umgebung zu implementieren, indem computerlesbare Anweisungen von einem oder mehreren Prozessoren jedes der Servergeräte ausgeführt werden, wobei die softwaredefinierte DCS-Umgebung Folgendes umfasst: eine oder mehrere softwaredefinierte Prozesssteuerungen, die konfiguriert sind, mindestens einen Teil des industriellen Prozesses durch Kommunikation mit mehreren Feldgeräten innerhalb der physischen Prozessumgebung in Echtzeit zu steuern; und eine oder mehrere DCS-Anwendungen, die für die Interaktion mit den softwaredefinierten Prozesssteuerungen konfiguriert sind, wobei mindestens eine der DCS-Anwendungen konfiguriert ist, den Betrieb der softwaredefinierten Prozesssteuerungen anzupassen.
Prozessleitsystem nach Anspruch 1, wobei die Servergruppe über eine oder mehrere Eingabe/Ausgabe(I/O)-Verbindungen, die konfiguriert sind, Prozessdaten über ein Prozesssteuerungsnetzwerk unter Verwendung eines industriellen Prozesssteuerungskommunikationsprotokolls zu kommunizieren, mit den mehreren Feldgeräten verbunden ist; und/oder wobei die softwaredefinierte DCS-Umgebung ferner eine oder mehrere virtuelle Netzwerkkomponenten umfasst, die konfiguriert sind, eine oder mehrere der folgenden physischen Netzwerkkomponenten zu replizieren: Netzwerk-Switches, Router oder Firewalls.
Prozessleitsystem nach Anspruch 1 oder 2, wobei die eine oder die mehreren DCS-Anwendungen eine Konfigurationsanwendung für eine virtuelle Architektur mit einer Benutzerschnittstelle umfassen, die konfiguriert ist, es einem Benutzer zu ermöglichen, eine virtuelle DCS-Netzwerkarchitektur zu definieren, indem mehrere virtuelle Knoten innerhalb der virtuellen DCS-Netzwerkarchitektur und Verbindungen zwischen den virtuellen Knoten spezifiziert werden, wobei diese virtuellen Knoten, virtuelle Darstellungen der mehreren Feldgeräte einschließen.
Prozessleitsystem nach einem der Ansprüche 1 bis 3, wobei die eine oder die mehreren DCS-Anwendungen eine Data-Historian-Anwendung enthalten, die konfiguriert ist, Prozessdaten innerhalb der softwaredefinierten DCS-Umgebung während des Betriebs des industriellen Prozesses automatisch zu speichern; und/oder wobei die eine oder die mehreren DCS-Anwendungen eine oder mehrere der folgenden Funktionen umfassen: eine Bedienerschnittstelle, eine Engineering-Workstation oder ein Anlagenverwaltungssystem; und/oder wobei die eine oder die mehreren DCS-Anwendungen eine oder mehrere der folgenden Funktionen umfassen: ein Fertigungsausführungssystem oder ein modernes Prozessleitsystem; und/oder wobei die eine oder die mehreren DCS-Anwendungen ein Netzwerk-Gateway zum Kommunizieren mit externen Datennetzen enthalten.
Prozessleitsystem nach einem der Ansprüche 1 bis 4, wobei die eine oder die mehreren softwaredefinierten Prozesssteuerungen mehrere Instanzen von virtuellen DCS-Steuerungen enthalten, die gleichzeitig auf verschiedenen Servergeräten der Servergruppe ausgeführt werden; insbesondere wobei die Servergruppe konfiguriert ist, einen automatischen Lastenausgleich zwischen den mehreren Instanzen der virtuellen DCS-Steuerungen basierend auf dem Status der mehreren Servergeräte in der Servergruppe durchzuführen.
Prozessleitsystem nach einem der Ansprüche 1 bis 5, wobei die eine oder die mehreren DCS-Anwendungen eine Anwendung umfassen, die konfiguriert ist, eine optimale Anzahl von Servergeräten der Servergruppe basierend auf der Ressourcennutzung der Servergruppe und der Ressourcenverfügbarkeit der mehreren Servergeräte vorherzusagen.
Nichtflüchtiges, computerlesbares Medium, auf dem ausführbare Anweisungen zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung gespeichert sind, die, wenn von Prozessoren mehrerer Servergeräte in einer Servergruppe ausgeführt, die Servergruppe veranlassen, ein softwaredefiniertes verteiltes Steuersystem (DCS) zu implementieren, wobei die softwaredefinierte DCS-Umgebung Folgendes umfasst: eine oder mehrere softwaredefinierte Prozesssteuerungen, die konfiguriert sind, mindestens einen Teil des industriellen Prozesses durch Kommunikation mit mehreren Feldgeräten innerhalb der physischen Prozessumgebung in Echtzeit zu steuern; und eine oder mehrere DCS-Anwendungen, die für die Interaktion mit den softwaredefinierten Prozesssteuerungen konfiguriert sind, wobei mindestens eine der DCS-Anwendungen konfiguriert ist, den Betrieb der softwaredefinierten Prozesssteuerungen anzupassen.
Nichtflüchtiges, computerlesbares Medium nach Anspruch 7, wobei die softwaredefinierte DCS-Umgebung ferner eine oder mehrere virtuelle Netzwerkkomponenten umfasst, die konfiguriert sind, eine oder mehrere der folgenden physischen Netzwerkkomponenten zu replizieren: Netzwerk-Switches, Router oder Firewalls; und/oder wobei die eine oder die mehreren DCS-Anwendungen eine Konfigurationsanwendung für eine virtuelle Architektur mit einer Benutzerschnittstelle umfassen, die konfiguriert ist, es einem Benutzer zu ermöglichen, eine virtuelle DCS-Netzwerkarchitektur zu definieren, indem mehrere virtuelle Knoten innerhalb der virtuellen DCS-Netzwerkarchitektur und Verbindungen zwischen den virtuellen Knoten spezifiziert werden, wobei diese virtuellen Knoten, virtuelle Darstellungen der mehreren Feldgeräte einschließen; und/oder wobei die eine oder die mehreren DCS-Anwendungen eine Data-Historian-Anwendung enthalten, die konfiguriert ist, Prozessdaten innerhalb der softwaredefinierten DCS-Umgebung während des Betriebs des industriellen Prozesses automatisch zu speichern.
Nichtflüchtiges, computerlesbares Medium nach Anspruch 7 oder 8, wobei die ausführbaren Anweisungen bewirken, dass mehrere Servergeräte der Servergruppe mehrere Instanzen von jedem von einem oder mehreren virtuellen DCS-Steuerungen als die eine oder die mehreren softwaredefinierten Prozesssteuerungen implementieren, wobei die mehrere Instanzen gleichzeitig auf verschiedenen Servergeräten der Servergruppe ausgeführt werden; insbesondere wobei die ausführbaren Anweisungen bewirken, dass die Servergruppe einen automatischen Lastenausgleich zwischen den mehreren Instanzen der virtuellen DCS-Steuerungen basierend auf dem Status der mehreren Servergeräte in der Servergruppe durchführt.
Verfahren zum Steuern eines industriellen Prozesses in einer physischen Prozessumgebung, Folgendes umfassend: Verbinden mehrerer Feldgeräte innerhalb der physischen Prozessumgebung über eine oder mehrere Eingabe/Ausgabe(I/O)-Verbindungen mit einer Servergruppe, die mehrere Servergeräte umfasst, die konfiguriert sind, eine softwaredefinierte verteilte Steuersystem(DCS)-Umgebung zu implementieren; Steuern, durch eine oder mehrere softwaredefinierte Prozesssteuerungen, die in der softwaredefinierten DCS-Umgebung auf der Servergruppe ausgeführt werden, mindestens eines Teils des industriellen Prozesses durch Kommunikation mit den mehreren Feldgeräten innerhalb der physischen Prozessumgebung in Echtzeit zu steuern; und Anpassen, durch eine oder mehrere DCS-Anwendungen, die in der softwaredefinierten DCS-Umgebung auf der Servergruppe ausgeführt werden und konfiguriert sind, mit den softwaredefinierten Prozesssteuerungen zu interagieren, des Betriebs der softwaredefinierten Prozesssteuerungen.
Verfahren nach Anspruch 10, ferner Folgendes umfassend: Empfangen von Prozessdaten aus den mehreren Feldgeräten an der Servergruppe über die eine oder die mehreren I/O-Verbindungen; und Senden von Prozesssteuersignalen von der Servergruppe über eine oder mehrere I/O-Verbindungen an mehrere Feldgeräte, um den Teil des industriellen Prozesses zu steuern.
Verfahren nach Anspruch 10 oder 11, wobei die eine oder die mehreren DCS-Anwendungen eine Konfigurationsanwendung für eine virtuelle Architektur umfassen und ferner Folgendes umfassend: Erzeugen einer Benutzerschnittstelle für einen Benutzer durch die Konfigurationsanwendung für die virtuelle Architektur, wobei die Benutzerschnittstelle mehrere Optionen zum Konfigurieren virtueller Komponenten innerhalb der softwaredefinierten DCS-Umgebung enthält; und Empfangen von Benutzereingaben des Benutzers in einer oder mehreren DCS-Anwendungen, um eine virtuelle DCS-Netzwerkarchitektur zu definieren, indem mehrere virtuelle Knoten innerhalb der virtuellen DCS-Netzwerkarchitektur und Verbindungen zwischen den virtuellen Knoten angegeben werden; insbesondere wobei die virtuellen Knoten eine oder mehrere virtuelle Darstellungen der mehreren Feldgeräte enthalten.
Verfahren nach einem der Ansprüche 10 bis 12, ferner Folgendes umfassend: Überwachen, durch eine Data-Historian-Anwendung, die in der softwaredefinierten DCS-Umgebung auf der Servergruppe ausgeführt wird, von Prozessdaten innerhalb der softwaredefinierten DCS-Umgebung während des Betriebs des industriellen Prozesses; und Automatisches Speichern der von der Data-Historian-Anwendung überwachten Prozessdaten in einem der Servergruppe zugeordneten Datenspeicher.
Verfahren nach einem der Ansprüche 10 bis 13, ferner Folgendes umfassend: Erfassen, durch die eine oder die mehreren DCS-Anwendungen, eines Typs von Prozessdaten, die einem Feldgerät der mehreren Feldgeräten zugeordnet sind, basierend auf dem Datenverkehr an der einen oder den mehreren I/O-Verbindungen; und Bestimmen, durch die eine oder die mehreren DCS-Anwendungen, einer Anpassung an den Betrieb der einen oder der mehreren softwaredefinierten Prozesssteuerungen basierend auf dem Typ der Prozessdaten.
Verfahren nach einem der Ansprüche 10 bis 14, wobei die eine oder die mehreren softwaredefinierten Prozesssteuerungen mehrere Instanzen jeder von einer oder mehreren virtuellen DCS-Steuerungen enthalten, die gleichzeitig auf verschiedenen Servergeräten der Servergruppe ausgeführt werden, und ferner Folgendes umfassend: Bestimmen, durch die eine oder die mehreren DCS-Anwendungen, einer Änderung des Status eines der mehreren Servergeräte der Servergruppe; und Einstellen, durch die eine oder die mehrere DCS-Anwendungen, einer Lastverteilung zwischen den mehreren Servergeräten basierend auf der Änderung des Status.