DE102020115439A1 - Industrielle steuerungssystemarchitektur für echtzeitsimulation und prozesssteuerung - Google Patents

Industrielle steuerungssystemarchitektur für echtzeitsimulation und prozesssteuerung Download PDF

Info

Publication number
DE102020115439A1
DE102020115439A1 DE102020115439.9A DE102020115439A DE102020115439A1 DE 102020115439 A1 DE102020115439 A1 DE 102020115439A1 DE 102020115439 A DE102020115439 A DE 102020115439A DE 102020115439 A1 DE102020115439 A1 DE 102020115439A1
Authority
DE
Germany
Prior art keywords
virtual
node
physical
data
simulated
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020115439.9A
Other languages
English (en)
Inventor
Mark J. Nixon
Anthony Amaro jun.
Noel Howard Bell
John M. Caldwell
Gary K. Law
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fisher Rosemount Systems Inc
Original Assignee
Fisher Rosemount Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fisher Rosemount Systems Inc filed Critical Fisher Rosemount Systems Inc
Publication of DE102020115439A1 publication Critical patent/DE102020115439A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • G05B19/4186—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication by protocol, e.g. MAP, TOP
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41885—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by modeling, simulation of the manufacturing system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4183—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by data acquisition, e.g. workpiece identification
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41835—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by programme execution
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41845—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by system universality, reconfigurability, modularity
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41865—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by job scheduling, process planning, material flow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B17/00—Systems involving the use of models or simulators of said systems
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B17/00—Systems involving the use of models or simulators of said systems
    • G05B17/02—Systems involving the use of models or simulators of said systems electric
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13125—Use of virtual, logical connections
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13185—Software function module for simulation
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/22—Pc multi processor system
    • G05B2219/2214—Multicontrollers, multimicrocomputers, multiprocessing
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31231—Lan and stations and fieldbus, each station controls own I-O
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32301—Simulate production, process stages, determine optimum scheduling rules
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32343—Derive control behaviour, decisions from simulation, behaviour modelling
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32344—Modular verification of real time systems
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32355—Simulate control process using virtual bus
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32359—Modeling, simulating assembly operations
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/32—Operator till task planning
    • G05B2219/32407—Real time processing of data
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/33—Director till display
    • G05B2219/33139—Design of industrial communication system with expert system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/33—Director till display
    • G05B2219/33149—Publisher subscriber, publisher, master broadcasts data to slaves, subscriber
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40311—Real time simulation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/80—Management or planning

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Manufacturing & Machinery (AREA)
  • Automation & Control Theory (AREA)
  • Quality & Reliability (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Programmable Controllers (AREA)

Abstract

Eine Plattform für dynamische Mehrzweck-Simulation und Laufzeitsteuerung beinhaltet eine virtuelle Prozessumgebung, die an eine physische Prozessumgebung gekoppelt ist, in der Komponenten/Knoten der virtuellen und physischen Prozessumgebung zusammenarbeiten, um die Laufzeitprozesssteuerung einer industriellen Prozessanlage und/oder Simulationen davon dynamisch durchzuführen. Virtuelle Komponenten können virtuelle Laufzeitknoten und/oder simulierte Knoten beinhalten. Die MPDSC enthält einen I/O-Switch, der I/O-Daten zwischen virtuellen und/oder physischen Knoten bereitstellt, z. B. unter Verwendung von Veröffentlichungs-/Abonnementmechanismen, wodurch die Bereitstellung physischer I/O-Prozessdaten virtualisiert wird. Knoten, die vom I/O-Switch bedient werden, können entsprechende Komponentenverhaltensmodule enthalten, die nicht wissen, ob sie auf einem virtuellen oder physischen Knoten verwendet werden oder nicht. Simulationen können in Echtzeit und sogar in Verbindung mit Laufzeitoperationen der Anlage durchgeführt werden, und/oder Simulationen können nach Wunsch (Geschwindigkeit, Werte, Administration usw.) manipuliert werden. Die Plattform unterstützt gleichzeitig Simulations- und Laufzeitoperationen sowie Interaktionen/Schnittpunkte dazwischen.

Description

  • RÜCKVERWEISUNG AUF VERWANDTE ANMELDUNGEN
  • Diese Anmeldung beansprucht die Priorität und den Vorteil des Anmeldedatums der vorläufigen US-Patentanmeldung Nr. 62/859,508 , die am 10. Juni 2019 eingereicht wurde, die den Titel „Industrial Control System Architecture for Real-Time Simulation and Control“ („Industrielle Steuerungssystemarchitektur für Echtzeitsimulation und -Steuerung“) trägt und deren gesamte Offenbarung hiermit ausdrücklich durch Bezugnahme hierin aufgenommen ist.
  • TECHNISCHES GEBIET
  • Diese Patentanmeldung bezieht sich im Allgemeinen auf Industrie- und Prozessleitsysteme und insbesondere auf ein Industriesteuerungssystem, das eine Simulation der Prozesssteuerung und/oder der tatsächlichen Prozesssteuerung zur Laufzeit unter Verwendung virtualisierter Komponenten bereitstellt.
  • HINTERGRUND
  • Prozess- oder industrielle Steuerungssysteme, wie diejenigen, die in der Chemie-, Erdölindustrie oder anderen industriellen Prozessanlagen zur Herstellung von physischen Produkten aus Materialien verwendet werden, beinhalten üblicherweise eine oder mehrere Prozesssteuerungen, die über analoge, digitale oder kombinierte Analog-/Digital-Busse oder über eine drahtlose Kommunikationsverbindung oder ein Drahtlos-Netzwerk mit einem oder mehreren Feldgeräten gekoppelt sind. Die Feldgeräte, wobei es sich z. B. um Ventile, Ventil-Stellungsregler, Schalter und Geber (z. B. Temperatur-, Druck-, Füllstands- und Durchflusssensoren) handeln kann, sind innerhalb der Prozessumgebung platziert 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 z. B. die Feldgeräte, die dem bekannten FOUNDATION® Feldbus-Protokoll entsprechen, können auch Steuerungsberechnungen, Alarmfunktionen und andere in der Steuerung übliche Steuerungsfunktionen durchführen. Die Prozesssteuerungen, die zentral angeordnet sein können, aber auch dezentral in der Anlagenumgebung angeordnet sein können, empfangen Signale, die Angaben zu Prozessmessungen der Feldgeräte und/oder andere Informationen zu den Feldgeräten machen, und führen eine Steuerungsanwendung aus, die beispielsweise verschiedene Steuermodule ausführt, die Prozesssteuerungsentscheidungen treffen, auf Grundlage der empfangenen Informationen Steuersignale generieren und sich mit den in den Feldgeräten ausgeführten Steuermodulen oder Blöcken koordinieren, wie beispielsweise HART®, WirelessHART® und FOUNDATION® Feldbus-Feldgeräte. Die Steuermodule in der Steuerung senden die Steuersignale über die Kommunikationsleitungen oder -verbindungen zu den Feldgeräten, um dadurch den Betrieb mindestens eines Anteils der Prozessanlage oder des Systems zu steuern, z. B. um dadurch mindestens einen Anteil der Prozessanlage oder des Systems zu steuern.
  • Informationen von den Feldgeräten und der Steuerung werden normalerweise von den Steuerungen über eine Datenautobahn einem oder mehreren anderen Hardware-Geräten zur Verfügung gestellt, wie z. B. Bedienerarbeitsplätzen, Personalcomputern oder Computergeräten, Data Historian-Geräten, Berichtsgeneratoren, zentralisierten Datenbanken oder anderen zentralisierten administrativen Computergeräten, die typischerweise in Leitstellen oder an anderen Orten außerhalb der raueren Anlagenumgebung aufgestellt werden. Jedes dieser Hardwaregeräte ist typischerweise über die gesamte Prozessanlage oder einen Anteil der Prozessanlage hinweg zentralisiert. Diese Hardwaregeräte führen Anwendungen aus, die es z. B. einem Ingenieur ermöglichen, Anteile 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 Prozesszustandes, das Anzeigen von durch Feldgeräte und Steuerungen generierte Alarmen, das Simulieren des Prozessbetriebs zu Personalschulungszwecken oder das Testen der Prozesssteuerungssoftware, das Führen und Aktualisieren einer Konfigurationsdatenbank, usw. Die von den Hardwaregeräten, Steuerungen und Feldgeräten verwendete Datenautobahn kann einen leitungsgebundenen Kommunikationspfad, einen drahtlosen Kommunikationspfad oder eine Kombination aus leitungsgebundenen und drahtlosen Kommunikationspfaden beinhalten.
  • Das von Emerson Process Management verkaufte 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 an einem oder mehreren Arbeitsplätzen oder Computergeräten untergebracht ist, ermöglicht Benutzern das Erstellen oder Ändern von Prozesssteuermodulen und das Herunterladen dieser Prozesssteuermodule über eine Datenautobahn auf dedizierte dezentrale Steuerungen. Typischerweise bestehen diese Steuermodule aus kommunikativ miteinander verbundenen Funktionsblöcken, die Objekte in einem objektorientierten Programmierprotokoll sind, das Funktionen innerhalb des Steuerungsschemas auf der Basis von Eingängen durchfü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 Steuermodule ausführt, um die tatsächliche Prozesssteuerungsfunktionalität umzusetzen. Die Anzeigeanwendungen, die auf einer oder mehreren Bedienerarbeitsplätzen (oder auf einem oder mehreren externen 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 Prozessleitsystem-Designern, -Bedienern oder -Benutzern über die Benutzeroberflächen an und können eine Vielzahl von verschiedenen Ansichten, wie zum Beispiel eine Bedieneransicht, eine Ingenieursansicht, eine Technikeransicht usw. bereitstellen. Eine Data Historian-Anwendung wird typischerweise in einem Data Historian-Gerät gespeichert und ausgeführt, das einige oder alle Daten sammelt und speichert, die über die Datenautobahn bereitgestellt werden, während eine Konfigurationsdatenbank-Anwendung auf einem weiteren Computer ausgeführt wird, der an die Datenautobahn angeschlossen ist, um die aktuelle Konfiguration der Prozesssteuerroutine und die damit verbundenen Daten zu speichern. Alternativ kann sich die Konfigurationsdatenbank an demselben Arbeitsplatz 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 der Steuerung in der Regel minimiert oder zumindest 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 den Arbeitsplatz oder das Computergerät zur Speicherung bei einem geeigneten Data Historians 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 tatsächlichen Prozess synchronisiert.
  • Ebenso bleiben in Batch-Prozessleitsystemen, um den Speicherverbrauch der Steuerung zu minimieren, Batch-Rezepte und Snapshots der Steuerungskonfiguration typischerweise an einem zentralen administrativen Computergerät oder -Standort (z. B. an einem Datensilo oder bei einem 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 dem Arbeitsplatz oder dem zentralen administrativen Computergerät und der Steuerung.
  • Auf jeden Fall ist die aktuelle Architektur von industriellen Steuerungssystemen, wie z. B. Prozessleitsystemen, weitgehend hardwaregesteuert, da verschiedene Funktionen, wie z. B. Steuerungsfunktionen, Ein-/Ausgabefunktionen (I/O), Benutzeroberflächenfunktionen usw. auf bestimmter Hardware (z. B. Benutzerarbeitsplätzen oder Schnittstellengeräten, Prozesssteuerungen, Sicherheitssystemsteuerungen, dedizierten I/O-Geräten, arrangierten I/O-Gerä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 arrangierten I/O-Geräten) basierend auf bestimmter Hardware konfiguriert, und folglich sind physische I/O-Beziehungen eng gebunden, meistens eins zu eins, z. B. I/O-Gerät an Steuerung, ein anderes I/O-Gerät an eine andere 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ätebasis erfordern, deren Implementierung kostspielig sein kann, und nicht leicht skalierbar oder aktualisierbar 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, besonderer Eigenschaften und Fähigkeiten von I/O-Geräten usw., auf bestimmte Weise konfiguriert werden muss.
  • Einige Versuche, diese Probleme zu beheben, beinhalten die Virtualisierung physischer Steuerungen; die Steuerungs-Virtualisierung ist jedoch bisher auf Offline-Entwicklungs- und Testsysteme beschränkt und wird, wenn überhaupt, nicht in großem Umfang zur Laufzeitprozesssteuerung in physischen Anlagen- und/oder Produktionsumgebungen eingesetzt. Darüber hinaus unterliegen sowohl virtualisierte als auch physische Steuerungen weiterhin den Einschränkungen physischer I/O-Geräte wie Leistung, Bandbreite, Durchsatz usw.
  • KURZDARSTELLUNG
  • Eine neuartige Mehrzweck-Hardware-/Software-Architektur oder -Plattform für die dynamische Simulation und/oder Laufzeit-Produktionsprozesssteuerung, die es einem industriellen oder Prozessleitsystem einer industriellen Prozessanlage ermöglicht, im Vergleich zu bekannten industriellen oder Prozessleitsystemen widerstandsfähiger, reaktionsfähiger und elastischer zu sein. Insbesondere entkoppelt diese neuartige Architektur oder Plattform die im Steuerungssystem verwendete Hardware weitgehend von der Software, die das Verhalten der Hardware steuert, wodurch das System einfacher skaliert, neu konfiguriert und geändert sowie insgesamt hinsichtlich Systemzuverlässigkeit, Verfügbarkeit und Leistung verbessert werden kann. Zur Erleichterung der Diskussion wird die neuartige Plattform oder Architektur für dynamische Mehrzweck-Simulation und Laufzeitsteuerung hierin austauschbar mit „MPDSC“, „MPDSC-Plattform“, „MPDSC-System“ oder „MPDSC-Architektur“ bezeichnet.
  • Im Allgemeinen beinhaltet die MPDSC eine virtuelle Prozessumgebung, die an eine physische Prozessumgebung gekoppelt ist, wobei Komponenten der virtuellen und physischen Umgebung zusammenarbeiten, um eine dynamische Simulation und/oder Laufzeit- (z. B. tatsächliche oder betriebliche) -Produktionsprozesssteuerung der industriellen Prozessanlage durchzuführen. Für die Laufzeit-Prozesssteuerung unterstützt die MPDSC-Plattform Prozessleitsysteme (PCS), die virtuelle Komponenten, physische Komponenten und/oder sowohl virtuelle als auch physische Komponenten beinhalten können, die zusammenarbeiten, um Batch- und/oder kontinuierliche industrielle Prozesse während der Laufzeit der Anlage zu überwachen und zu steuern. In einigen Fällen unterstützt die MPDSC-Plattform auch Safety Instrumented Systems (sicherheitstechnische Systeme - SIS), die sowohl virtuelle als auch physische Komponenten enthalten können, die zusammenarbeiten, um während der Laufzeit einen sicheren Betrieb aufrechtzuerhalten und einen ausfallsicheren Betrieb der Anlage zu gewährleisten. Virtuelle Knoten, die Laufzeit-, Betriebsprozesssteuerung und/oder verwandte Laufzeitfunktionen durchführen (z. B. in Verbindung mit einem oder mehreren physischen Geräten oder Komponenten, die in der physischen Umgebung der Prozessanlage angeordnet sind), werden hier als „virtuelle Laufzeitknoten“ bezeichnet.
  • Die MPDSC-Plattform kann zusätzlich oder alternativ eine Simulationsumgebung oder einen Simulationsraum unterstützen, die/der für Steuerungs- und/oder Sicherheitssystem- und/oder Komponententests, -Validierung, -Verifizierung und/oder -Auschecken, Bedienerschulungen, Fallstudien und laufende Prozessverbesserungen usw. verwendet werden können. Für Simulationszwecke bietet die MPDSC-Plattform virtuelle Knoten, die eine oder mehrere physische Geräte, Module oder Komponenten simulieren, die in der physischen Prozessumgebung eingesetzt werden können. Virtuelle Knoten, die verschiedene Geräte, Module und/oder Komponenten simulieren, die in der physischen Umgebung der Prozessanlage eingesetzt werden können, werden hier als „simulierte Knoten“ bezeichnet.
  • Die von der MPDSC-Plattform bereitgestellte Simulation ist „dynamisch“, da Simulationen der Prozessanlage oder von Anteilen davon in Echtzeit ausgeführt werden können, wodurch die Zeitsteuerung und andere Verhaltensweisen, die zur Laufzeit auftreten (würden), widergespiegelt werden, und/oder Simulationen manipuliert werden können, um schneller oder langsamer als in Echtzeit ausgeführt zu werden, um unterschiedliche Werte, Ausgangsbedingungen, Zwischenbedingungen usw. zu verwenden. Der Simulationsraum bietet verschiedene Funktionen, wie zum Beispiel Speicher-/Wiederherstellungsfunktionen für verschiedene simulierte Szenarien, bearbeitbare Ausgangs- und/oder Zwischenbedingungen für verschiedene Szenarien, Koordination mit Simulatoren von Drittanbietern über verschiedene Protokolle, Testen und Auschecken von Bedieneranzeigenansichten, Echtzeitsimulation eines oder mehrerer Anteile des PCS, Beschleunigen und/oder Verlangsamen der Simulation des einen oder der mehreren Anteile des PCS; Simulationen, die simulierte Komponenten enthalten, die in Verbindung mit tatsächlichen (z. B. nicht simulierten) virtuellen und/oder physischen Komponenten arbeiten, Änderungsverwaltung und Synchronisation mit der Anlagenkonfiguration usw. Die MPDSC-Plattform kann gleichzeitig sowohl Simulations- als auch Laufzeitoperationen, verschiedene Interaktionen und Schnittpunkte zwischen Simulations- und Laufzeitoperationen unterstützen (z. B. Testen von Upgrades, Patches, „Was-wäre-wenn“-Szenarien, Konfigurationsänderungen, Benutzereingabeänderungen und dergleichen. Darüber hinaus können mit der MPDSC-Plattform Systemredundanz, Fehlertoleranz, Umschaltungen, geplante Wartung usw. nahtlos und einfach durchgeführt werden.
  • Eine der Schlüsselkomponenten der MPDSC-Architektur wird hier als „I/O-Switch“ oder „I/O-Server“ bezeichnet, der im Allgemeinen unberücksichtigt lässt, dass die I/O der Prozessanlage spezifisch und direkt einer bestimmter Hardware zugeordnet ist, und andere Funktionen im Zusammenhang mit I/O für die Simulation und/oder Laufzeitprozesssteuerung durchführt. Der I/O-Switch oder I/O-Server ist ein Knoten, der während der Laufzeit I/O-Daten zwischen virtuellen und/oder physischen Knoten der Prozessanlage übermittelt. Jeder Knoten (ob virtuell oder physisch) ist normalerweise eine Komponente der Prozessanlage, die innerhalb des MPDSC-Systems durch einen eindeutigen Namen, ein eindeutiges Tag oder eine eindeutige Kennung identifiziert wird. Beispielsweise kann ein Knoten eine physische oder virtuelle Steuerung, ein Feldgerät, eine Sicherheitsinformationssteuerung, ein Sicherheits-Logik-Solver, eine I/O-Karte oder ein -Gerät (z. B. ein drahtloses I/O-Gerät, ein Ethernet-I/O-Gerät, ein arrangierter I/O-Schrank oder Komponenten davon, usw.), ein Bedienerarbeitsplatz, eine andere Art von Benutzeroberflächengerät, ein Werkzeug (z. B. Diagnosewerkzeug, Simulationswerkzeug usw.), ein Gateway, ein Datenspeichergerät oder andere Art von Komponente sein. Im Allgemeinen arbeitet der I/O-Switch als Datenbroker zwischen virtuellen und/oder physischen Knoten, wobei der I/O-Switch I/O-Daten (hierin auch austauschbar als „Prozess-I/O-Daten“ oder „PIO-Daten“ bezeichnet) zwischen Quellknoten (ob virtuell oder physisch) und Zielknoten (ob virtuell oder physisch) übermittelt oder umschaltet. In gewisser Weise virtualisiert der I/O-Switch die physischen Übermittlungsmechanismen von Prozess-I/O-Daten zwischen Knoten des MPDSC-Systems, statt physische I/O-Karten eng und/oder spezifisch an verschiedene Quell- und Zielknoten zu binden, um Prozess-I/O-Daten zu übergeben, und löst die Bindungen zwischen Hardwarekomponenten, die zum Übermitteln von I/O-Daten verwendet werden. Darüber hinaus ist der I/O-Switch so konfiguriert, dass er I/O-Daten so schnell (z. B. mit ausreichend geringer Verzögerung) übermitteln kann, dass die Laufzeit, die tatsächliche Produktionsprozesssteuerung und/oder die Echtzeitsimulation der Produktionsprozesssteuerung unterstützt wird.
  • Im Allgemeinen enthalten virtuelle und physische Knoten/Komponenten, die vom I/O-Switch oder I/O-Server bedient werden, entsprechende Module, die das Verhalten von virtuellen und physischen Knoten oder Komponenten steuern. Solche Module werden hier als „Komponentenverhaltensmodule“ oder „CBMs“ bezeichnet, von denen Beispiele Steuermodule in Steuerungen, Sicherheitslogik in Sicherheits-Logic-Solvern und andere Typen von Modulen beinhalten, die das Verhalten und Operationen der Komponenten steuern, in denen die Module gespeichert und ausgeführt werden, zumindest teilweise durch Arbeiten mit I/O-Daten. Innerhalb des MPDSC-Systems sind CBMs, die mit der prozessbezogenen Nutzlast der I/O-Daten arbeiten, agnostisch oder in Unkenntnis über den I/O-Switch und seine Rolle bei der Übermittlung von I/O-Daten zu/von den Komponentenverhaltensmodulen. Das heißt, die CBMs wissen nicht, ob es sich bei ihrem jeweiligen I/O-Übermittlungsmechanismus zu/von ihrem Hostknoten um eine physische I/O-Karte oder den I/O-Switch handelt.
  • Daher kann der I/O-Switch als Switching Fabric, Router und/oder Übermittlungsmechanismus für I/O-Daten angesehen werden, der für Komponentenverhaltensmodule des MPDSC-Systems transparent ist. Hierzu übermittelt der I/O-Switch I/O-Daten zwischen virtuellen und/oder physischen Knoten über entsprechende Publish-/Subscribe-(Veröffentlichungs-/Abonnement)-Schichten der Knoten (hier auch austauschbar als „Pub-/Sub-Schicht“ bezeichnet) und einem virtuellen Kommunikationsnetzwerk, über das I/O-Nutzlastdaten oder Daten zwischen Knoten übertragen werden. Beispielsweise kann ein sendender oder veröffentlichender Knoten eine entsprechende Pub-/Sub-Schicht enthalten, die vom Komponentenverhaltensmodul des sendenden Knotens generierte Daten an das virtuelle Kommunikationsnetzwerk veröffentlicht. Der I/O-Switch kann die veröffentlichten Daten an Knoten übermitteln oder umschalten, die Empfänger oder Abonnenten der Daten sind, und jeder Abonnentenknoten kann die Daten über seine jeweilige Pub-/Sub-Schicht für den Verbrauch durch sein jeweiliges Komponentenverhaltensmodul wiederherstellen. Als solches vermittelt der I/O-Switch Daten zwischen Veröffentlicher-Knoten und Abonnentenknoten auf Bedarfsbasis gemäß den definierten Beziehungen der Knoten innerhalb des MPDSC-Systems.
  • Wie hierin verwendet, bezieht sich die „physische Umgebung“ der MPDSC-Plattform oder des - Systems auf die Produktionsanlage oder -Umgebung, in der physische, materielle Komponenten (z. B. Feldgeräte, Tanks, Ventile, Stellantriebe, Heizungen, Verdampfer, Sensoren usw.) verwendet werden, um physische Materialien über laufzeitgesteuerte Prozesse in physische Produkte umzuwandeln. Dementsprechend wird die „physische Umgebung“ hierin austauschbar als „Anlagenumgebung“ der industriellen Prozessanlage bezeichnet. Wie vorstehend erörtert, beinhaltet die physische oder Anlagenumgebung einen Front-End-Anteil, in dem physische oder Hardwarekomponenten des MPDSC-Systems wie Feldgeräte, Sensoren, Sender, Schalter, Stellungsregler, Tanks, Heizungen usw. angeordnet sind und physische Materialien zur Herstellung physischer Produkte bearbeiten. Als solches wird der „Front-End“-Anteil der physischen Umgebung hier austauschbar als „Feld“- oder „Standort“-Anteil der physischen Umgebung der Prozessanlage bezeichnet.
  • Die physische oder Anlagenumgebung des MPDSC-Systems beinhaltet auch einen Back-EndBereich, in dem physische oder Hardwarekomponenten wie Bedienerarbeitsplätze, Personalcomputer oder Computergeräte, Data Historians, Berichtsgeneratoren, zentralisierte Datenbanken und/oder andere zentralisierte (oder zumindest teilweise zentralisierte) administrative Computergeräte Anwendungen ausführen, um beispielsweise die Prozessanlage und/oder ihre Komponenten zu konfigurieren, Laufzeitoperationen der Anlage anzuzeigen und zu überwachen, auf Warnungen oder Alarme während Laufzeitoperationen der Anlage zu reagieren, Parameter während Laufzeitoperationen der Anlage einzustellen, Berichte zu generieren, Daten zu speichern und zu analysieren, und dergleichen. Der Back-End-Anteil der physischen Umgebung des MPDSC-Systems kann sich in Bereichen, die vor der raueren Feldumgebung geschützt sind, z. B. in einem geschlossenen Raum am Standort und/oder an Orten außerhalb des Standorts oder entfernt von der Feldumgebung, befinden.
  • Die virtuelle Umgebung des MPDSC-Systems wird unter Verwendung von physischen oder Hardware-Computergeräten implementiert, die speziell konfiguriert und miteinander verbunden sind, um eine Plattform bereitzustellen, die die Virtualisierung verschiedener physischer Prozessanlagenkomponenten unterstützt, wie in späteren Abschnitten dieser Offenbarung ausführlicher beschrieben wird. Im Allgemeinen können sich die physischen Computergeräte, die die Virtualisierungsplattform bereitstellen und unterstützen, physisch am Standort in der Anlage befinden (z. B. in geschützten, geschlossenen Bereichen der Feldumgebung), können sich physisch außerhalb des Standorts befinden oder können physisch und dezentral an verschiedenen Orten am Standort und außerhalb des Standorts angeordnet sein. Die physischen Computergeräte, die die Virtualisierungsplattform bereitstellen und unterstützen, können über eine beliebige Anzahl von physischen Datenverbindungen und/oder Kommunikations-/Datennetzwerken miteinander verbunden sein. Im Allgemeinen bilden die physischen Computergeräte, Datenverbindungen und Kommunikations-/Datennetze eine Computerplattform, auf der sich verschiedene logische oder virtuelle Komponenten des MPDSC-Systems befinden, auf der die verschiedenen logischen oder virtuellen Komponenten zur Laufzeitprozesssteuerung in Verbindung mit Komponenten der physischen Prozessumgebung und/oder zu Prozesssimulationszwecken verwendet werden können.
  • Die logischen oder virtuellen Komponenten, die sich in der virtuellen Umgebung des MPDSC-Systems befinden, können eine Simulation eines oder mehrerer tatsächlicher oder geplanter physischer Anteile des MPDSC-Systems bereitstellen (z. B. in Echtzeit, bei höheren Geschwindigkeiten und/oder bei Bedarf bei niedrigeren Geschwindigkeiten). In einigen Implementierungen können die logischen oder virtuellen Komponenten, die sich in der virtuellen Umgebung des MPDSC-Systems befinden, und die physischen Komponenten, die sich in der physischen Umgebung des MPDSC-Systems befinden, zusammenarbeiten, um eine Simulation und/oder eine Laufzeit zur tatsächlichen Produktionsprozesssteuerung bereitzustellen. Als solches sind in einigen Ausführungsformen die physischen und virtuellen Umgebungen der MPDSC-Plattform über eine oder mehrere Kommunikationsverbindungen und/oder Netzwerke kommunikativ verbunden, wobei die Kommunikationsverbindungen und/oder Netzwerke eine beliebige Anzahl von leitungsgebundenen Verbindungen und/oder Netzwerken; drahtlosen Verbindungen und/oder Netzwerken, privaten Verbindungen und/oder Netzwerken, öffentlichen Verbindungen und/oder Netzwerken enthalten können. Ausführungsformen einer eigenständigen virtuellen Echtzeitsimulation und Ausführungsformen der Zusammenarbeit zwischen den logischen / virtuellen und physischen Komponenten des industriellen Steuerungssystems und kommunikativen Verbindungen dazwischen werden in späteren Abschnitten dieser Offenbarung ausführlicher beschrieben.
  • Ferner verwenden oder nutzen die virtuellen und physischen Umgebungen der MPDSC-Plattform eine gemeinsame (z. B. dieselbe) Systemkonfigurationsdatenbank, die hier als „MPDSC-Systemkonfigurationsdatenbank“ bezeichnet wird. Daher können über die MPDSC-Systemkonfigurationsdatenbank verschiedene virtuelle und physische Komponenten innerhalb der MPDSC-Plattform sowohl in virtuellen als auch in physischen Umgebungen eindeutig identifiziert werden, und Schnittstellen zwischen Simulations- und Laufzeitoperationen (z. B. Testen, Umschalten usw.) können nahtlos und einfach ausgeführt werden.
  • In einer Ausführungsform umfasst ein System, wie beispielsweise ein dynamisches Mehrzweck-Simulations- und Laufzeit-Industrie- oder Prozessleitsystem (MPDSC), ein Prozessleitsystem, das ein Feldgerät einschließt, wobei das Feldgerät in einer physischen Umgebung einer industriellen Prozessanlage angeordnet ist und eine physische Funktion erfüllt. Zusätzlich enthält das Prozessleitsystem einen I/O-Switch, der kommunikativ zwischen dem Feldgerät und einem virtuellen Knoten angeordnet ist, wobei der virtuelle Knoten in einer virtuellen Umgebung der industriellen Prozessanlage angeordnet ist. Der I/O-Switch ist ein Abonnent (Subscriber) von ersten Daten, die vom Feldgerät generiert und veröffentlicht wurden, und der I/O-Switch ist ein Veröffentlicher (Publisher) von zweiten Daten, die Angaben zu den ersten vom Feldgerät generierten Daten machen. Das Prozessleitsystem beinhaltet ferner den virtuellen Knoten, wobei der virtuelle Knoten ein Abonnent der zweiten Daten ist, die dem Feldgerät entsprechen und vom der I/O-Switch veröffentlicht werden. Der virtuelle Knoten enthält ein Komponentenverhaltensmodul, das mit den zweiten Daten arbeitet, die dem Feldgerät entsprechen, um dadurch ein Steuersignal zu generieren, um ein Verhalten eines anderen Knotens des Prozessleitsystems zu modifizieren. Das Feldgerät, der virtuelle Knoten und der andere Knoten arbeiten während Laufzeitoperationen der industriellen Prozessanlage zusammen, um beispielsweise einen industriellen Prozess zu steuern.
  • In einer Ausführungsform beinhaltet ein Verfahren zum Steuern eines Knotens eines Prozessleitsystems einer industriellen Prozessanlage das kommunikative Verbinden eines Feldgeräts und eines virtuellen Knotens über einen I/O-Switch, der zwischen dem Feldgerät und dem virtuellen Knoten angeordnet ist, so dass das Feldgerät, der I/O-Switch und der virtuelle Knoten während der Laufzeitoperationen der industriellen Prozessanlage zusammenarbeiten, um einen industriellen Prozess zu steuern. Das Feldgerät ist in einer physischen Umgebung der industriellen Prozessanlage angeordnet und erfüllt eine physische Funktion. Der I/O-Switch ist ein Abonnent (Subscriber) von ersten Daten, die vom Feldgerät generiert und veröffentlicht wurden, und der I/O-Switch ist ein Veröffentlicher (Publisher) von zweiten Daten, die Angaben zu den ersten vom Feldgerät generierten Daten machen. Der virtuelle Knoten ist in einer virtuellen Umgebung der industriellen Prozessanlage angeordnet, und der virtuelle Knoten ist ein Abonnent der zweiten Daten, die dem Feldgerät entsprechen und vom I/O-Switch veröffentlicht werden. Während der Laufzeitoperationen der industriellen Prozessanlage beinhaltet das Verfahren Empfangen der zweiten Daten, die dem Feldgerät entsprechen und vom I/O-Switch veröffentlicht werden, durch den virtuellen Knoten; Bearbeiten der zweiten Daten unter Verwendung eines Komponentenverhaltensmoduls des virtuellen Knotens, wodurch ein Steuersignal basierend auf den zweiten Daten generiert wird; und Bewirken einer Angabe, dass das Steuersignal an einen anderen Knoten des Prozessleitsystems zu übertragen ist, wodurch ein Verhalten des anderen Knotens modifiziert wird.
  • Figurenliste
    • 1 ist ein Blockdiagramm eines beispielhaften dynamischen Mehrzweck-Simulations- und Laufzeit-Industrie- oder Prozessleitsystems (MPDSC), das eine dynamische Simulation und/oder industrielle Laufzeit- oder Prozesssteuerung einer Prozessanlage bereitstellt.
    • 2 ist ein Blockdiagramm, das Ausführungsformen beispielhafter virtueller Knotenarchitekturen darstellt, die in dem MPDSC-System von 1 enthalten sein können.
    • 3 ist eine beispielhafte Anordnung einer physischen Anlagenumgebung, die das MPDSC-System von 1 unterstützen kann.
    • 4 veranschaulicht eine beispielhafte Anordnung mehrerer I/O-Switches, die zumindest teilweise in dem MPDSC-System von 1 implementiert sein können.
    • 5 ist ein Blockdiagramm, das ein beispielhaftes Virtualisierungsverwaltungssystem darstellt, über das mindestens Anteile des MPDSC-Systems von 1 konfiguriert und administriert werden können.
    • 6 ist ein Flussdiagramm eines Verfahrensbeispiels zum Steuern eines Knotens eines Prozessleitsystems einer industriellen Prozessanlage.
  • DETAILLIERTE BESCHREIBUNG
  • 1 ist ein Blockdiagramm eines beispielhaften dynamischen Mehrzweck-Simulations- und Laufzeit-Industrie- oder Prozessleitsystems (MPDSC) oder einer Plattform 10, das/die eine dynamische Simulation und/oder Laufzeit-Prozesssteuerung einer industriellen oder Prozessanlage bereitstellt. Die beispielhafte MPDSC-Plattform 10 unterstützt die dynamische Simulation der Prozesssteuerung der industriellen Prozessanlage und/oder der Echtzeit-Prozesssteuerung unter Verwendung virtualisierter Geräte. Beispielsweise können die virtualisierten Geräte von der MPDSC-Plattform 10 für physische Produktionszwecke während der Laufzeit der Prozessanlage verwendet werden. Wie in 1 gezeigt, beinhaltet die MPDSC-Plattform 10 einen virtuellen Anlagenumgebungsanteil 12 und einen physischen Anlagenumgebungsanteil 15; jedoch kann in Ausführungsformen, in denen die MPDSC-Plattform 10 ausschließlich für Echtzeitsimulationszwecke verwendet wird, der Anteil 15 der physischen Anlagenumgebung weggelassen werden. Im Allgemeinen bilden der virtuelle Anlagenumgebungsanteil 12 und der physische Anlagenumgebungsanteil 15 zusammen eine oder mehrere Operations Technology-(OT)-Schicht(en) 18 der industriellen Prozessanlage, die generierte Daten für eine oder mehrere Information Technology-(IT)-Schicht(en) 20 bereitstellen können, die der industriellen Prozessanlage und/oder Netzwerken außerhalb der IT-Schichten zugeordnet sind, z.B. zur unternehmensinternen und/oder externen Verwendung durch eine oder mehrere Anwendungen 21a-21n, 22a-22m. Beispielsweise können die Anwendungen 21a-21m von dem Unternehmen bereitgestellt werden, das die MPDSC-Plattform 10 besitzt / betreibt, und in einer dem Unternehmen zugeordneten IT-Schicht ausgeführt werden, und die Anwendungen 22a-22m können Anwendungen des Internet of Things (IoT) und/oder des Industrial Internet of Things (IIoT) sein, die von jeweiligen Drittanbietern bereitgestellt werden und in Remote-Netzwerken ausgeführt werden, auf die über das Internet oder ein anderes öffentliches Netzwerk zugegriffen wird.
  • Die IT-Schichten 20 des Unternehmens können in einer beliebigen Anzahl von lokal und/oder entfernt angeordneten Computergeräten implementiert sein, wie beispielsweise einer oder mehreren lokalen und/oder entfernten Serverbanken, einer oder mehreren Computer-Clouds usw., und können eine beliebige Anzahl von Anwendungen oder Verbrauchern 21a-21n von Daten, die durch die OT-Schichten 18 des Unternehmens generiert wurden, enthalten. Typischerweise (aber nicht notwendigerweise) und wie in 1 dargestellt, sind die OT-Schichten 18 über ein oder mehrere öffentliche und/oder private Kommunikationsnetze 24 und ein oder mehrere Edge-Gateway-Systeme 28 kommunikativ mit den IT-Schichten 20 gekoppelt, wobei das (die) Edge-Gateway-System(e) 28 Sicherheit und Effizienz der Datenübermittlung zwischen den OT-Schichten 18 / MPDSC-Plattform 10 und den IT-Schichten 20 bereitstellen. Ferner können das eine oder die mehreren Edge-Gateway-Systeme 28 Sicherheit und Effizienz der Datenübermittlung zwischen der MPDSC-Plattform 10 und externen Netzwerken und/oder externen Anwendungen 22 bereitstellen.
  • In FIG. In 1 enthält die virtuelle Anlagenumgebung 12 der MPDSC-Plattform 10 einen oder mehrere virtuelle Knoten (VNs) 30a, 30b, 30c,..., 30p, die kommunikativ mit einem I/O-Switch 25 verbunden sind (der hierin austauschbar als „I/O-Server“ bezeichnet wird). Im Allgemeinen ist jeder virtuelle Knoten 30x eine virtuelle Maschine, die das Verhalten einer jeweiligen physischen Komponente simuliert oder virtualisiert, die eventuell in der physischen Anlagenumgebung 15 funktionsfähig ist. Anders ausgedrückt, verarbeitet jeder virtuelle Knoten 30x in der virtuellen Anlagenumgebung 12 Daten und verhält sich auf dieselbe Weise, wie sein physisches Gegenstück in der physischen Anlagenumgebung 15 Daten verarbeiten und sich verhalten würde.
  • Insbesondere beinhaltet jeder virtuelle Knoten 30x einen Rahmen und ein oder mehrere Subsysteme 32, die es dem VN 30x ermöglichen, mit anderen virtuellen Knoten 30x innerhalb der virtuellen Anlagenumgebung 12 und/oder mit einem oder mehreren physischen Knoten (PNs) innerhalb der physischen Anlagenumgebung 15 zu kommunizieren, wie beispielsweise den physischen Knoten 40a, 40b, 40c und dem Edge-Gateway-System 28 (wobei das Edge-Gateway 28 als ein bestimmter Typ von PN angesehen werden kann), von denen jedes entsprechende Frameworks und jeweils ein oder mehrere Subsysteme 42x enthält, die die Kommunikation mit virtuellen Knoten ermöglichen 30x. Zusätzlich kann die MPDSC-Plattform 10 eine beliebige Anzahl anderer physischer Knoten oder Komponenten (z. B. PNa-PNk) enthalten.
  • Virtuelle Knoten können verschiedene Typen von physischen Knoten virtualisieren. Allgemein gesprochen, ist ein „physischer Knoten“, wie hierin verwendet, ein physisches Gerät oder eine physische Komponente der MPDSC-Plattform 10, die Hardware enthält und Daten an andere Geräte oder Komponenten (ob virtuell oder physisch) sendet und/oder von diesen empfängt. Beispiele für Typen physischer Knoten, die durch jeweilige virtuelle Knoten dargestellt sein können, beinhalten, ohne darauf beschränkt zu sein: verschiedene Typen von Prozessleitsteuerungen; verschiedene Typen lokaler und/oder entfernter I/O-Geräte oder -Karten (z. B. drahtlose I/O-Karten (WIOCs), Ethernet-I/O-Karten (EIOCs) usw.) und verschiedene Komponenten von elektronischen Rangier-I/O-Systemen (wie CHARakterisierungsmodulen (CHARMs), Klemmenblöcken, CHARM-I/O-Karten (CIOCs) usw.); verschiedene Typen von SIS-(Safety Instrumented System)-Knoten wie Sicherheitssteuerungen, Sicherheits-Logik-Solver, SIS-Repeater, Sicherheitsnetzwerkbrücken, Sicherheitsnetzwerk-Gateways usw.; Benutzeroberflächengeräte, einschließlich lokaler und/oder entfernter physischer Bedienerarbeitsplätze, mobile Geräte und/oder andere Computergeräte, die Benutzeroberflächen für Laufzeitoperationen und/oder für andere Zwecke im Zusammenhang mit der MPDSC-Plattform 10 bereitstellen; lokale und/oder entfernte physische Computergeräte, die Tools für die MPDSC-Plattform 10 bereitstellen, z. B. Steuerungskonfigurationstools, Datenkonsolidierungs-und Anzeigetools, Datenanalyse- und Analysekonfigurationstools, Anzeigeansichtskonfigurationstools, Diagnosetools, Vermögensverwaltungs-Tools, Anwendungsstationen usw.; verschiedene Typen von Gateways, die innerhalb und/oder von der MPDSC-Plattform 10 verwendet werden, wie drahtlose Gateways, Sicherheitsgateways, Firewalls, Edge-Gateways, Feldgateways, systemübergreifende Gateways usw.; und andere Typen von physischen Knoten, die innerhalb einer physischen Anlagenumgebung 15 verwendet werden können.
  • In einigen Ausführungsformen kann ein einzelner VN 30x einen gesamten physischen Knoten darstellen oder virtualisieren. In einigen Ausführungsformen kann ein einzelner VN 30x einen oder mehrere Anteile eines bestimmten physischen Knotens darstellen oder virtualisieren. Beispielsweise kann ein einzelner VN 30x ein bestimmtes Modul oder eine bestimmte Gruppe von Modulen darstellen oder virtualisieren, die in dem bestimmten PN ausgeführt werden oder sich dort befinden, wobei solche Module Softwaremodule oder -Komponenten, Firmware-Modulkomponenten und/oder Hardwaremodule oder -komponenten einschließen können. Beispielsweise kann ein erster VN eine gesamte Anwendung darstellen oder virtualisieren, die auf dem bestimmten PN ausgeführt wird (wie die Gesamtheit eines Steuermoduls, das auf einer physischen Prozesssteuerung ausführbar ist), ein zweiter VN kann eine Teilmenge der gesamten Anwendung darstellen oder virtualisieren, die auf dem bestimmten PN (wie einem bestimmten Steuermodell, einer bestimmten Funktion oder einer bestimmten Routine, die vom Steuermodul verwendet wird) ausgeführt wird, ein dritter VN kann das Verhalten einer protokollspezifischen I/O-Karte oder eines protokollspezifischen Geräts darstellen oder virtualisieren, das/die dem bestimmten PN zugeordnet ist, und/oder ein vierter VN kann eine PN-Unterkomponente darstellen oder virtualisieren, die so granular ist wie eine Hardware-Unterkomponente des bestimmten PN (z. B. ein Anschluss oder eine andere Schnittstelle, ein Bus, ein Transceiver, ein Chip, ein Board usw.), oder eine Firmware- oder Software-Unterkomponente des bestimmten PN (z. B. ein Modul, eine Routine, eine Funktion oder ein Verhalten, eine Netzwerkadresse des bestimmten PN, wie z. B. eine MAC-(Media Access Control)-Adresse oder eine andere Art von Adressen usw.).
  • Beispiele für Typen von physischen I/O-Karten, die in der physischen Anlagenumgebung 15 verwendet werden können und die durch virtuelle Knoten 30x des MPDSC 10 dargestellt und/oder virtualisiert werden können, enthalten, sind aber nicht beschränkt auf:
    • diskrete Ausgangskarten, einschließlich eigensicherer und redundanter diskreter Ausgangskarten mit hoher Dichte;
    • diskrete Eingangskarten, einschließlich eigensicherer und redundanter diskreter Eingangskarten mit hoher Dichte;
    • analoge Eingangskarten, einschließlich analoger Eingangskarten, die das HART®-(Highway Addressable Remote Transducer)-Kommunikationsprotokoll unterstützen, redundante analoge Eingangskarten, die HART unterstützen, redundante analoge Eingangskarten mit hoher Dichte, die HART unterstützen, und schnelle analoge Eingangskarten;
    • analoge Ausgangskarten, einschließlich analoger Ausgangskarten, die HART unterstützen, redundante analoge Ausgangskarten, die HART unterstützen, redundante analoge Ausgangskarten mit hoher Dichte, die HART unterstützen, und schnelle analoge Ausgangskarten;
    • serielle Karten, einschließlich redundanter, programmierbarer und redundanter programmierbarer serieller Karten;
    • Schnittstellenkarten für diskrete Stellantriebe und/oder Sensoren, RTD-(Resistance Temperature Detector)-Karten, Thermoelementkarten, Millivoltkarten, isolierte Temperaturkarten, Multifunktionskarten, Ereignisabfolgekarten, die das Feldbus-Kommunikationsprotokoll unterstützen, redundante Feldbus-unterstützende Karten; Karten, die das Profibus-Kommunikationsprotokoll unterstützen; redundante, Profibus unterstützende Karten und andere Typen von physischen Karten.
  • Wie in 1 veranschaulicht kommunizieren die VNs 30a, 30b, 30c, ..., 30p miteinander und mit dem I/O-Switch 25 über die jeweiligen Veröffentlichungs- / Abonnementschichten 32a, 32b, 32c, ..., 32p und 35, die hierin austauschbar als „Pub-/Sub-Schichten“ bezeichnet werden und die in 1 durch die jeweiligen mit Raute markierten Anteile 32x, 35 von jedem VN 30x und des I/O-Switches 25 bezeichnet sind. In Ausführungsformen der MPDSC-Plattform 10, in denen physische Knoten enthalten sind, wie in 1 dargestellt, können mindestens einige der PNs 28, 40a, 40b, 40c, die in der physischen Anlagenumgebung 15 angeordnet sind, entsprechende Pub-/Sub-Schichten 38, 42a, 42b, 42c enthalten. In gewisser Weise dienen die Pub-/Sub-Schichten 32x, 35 (und in einigen Anordnungen die Pub-/Sub-Schichten 38, 42x) als virtuelles Kommunikationsnetzwerk 45, über das verschiedene virtuelle Knoten 30x und der I/O-Switch 25 (und in einigen Anordnungen die physischen Knoten 40x) abstrahierte I/O-Daten kommunizieren können. In einem Implementierungsbeispiel ist jede Pub-/Sub-Schicht 32x, 35, 38, 42x eine entsprechende Schnittstelle zum virtuellen Kommunikationsnetzwerk 45.
  • Das virtuelle Kommunikationsnetzwerk 45 kann durch eine oder mehrere physische Kommunikations- und/oder Datenverbindungen und/oder -Netzwerke implementiert sein, die leitungsgebundene und/oder drahtlose Netzwerke einschließen können und die unter Verwendung einer beliebigen geeigneten Technologie wie Ethernet, optisch, IP, ein anderes Paketnetzwerk von einem anderen Typ usw. implementiert werden können. Die Daten werden zwischen Knoten des über das virtuelle Kommunikationsnetzwerk 45 über Veröffentlichung und Abonnement übertragen, und jedes oder mehrere geeignete Kommunikationsprotokolle, die Veröffentlichung und Abonnement unterstützen, können innerhalb des virtuellen Kommunikationsnetzwerks 45 für die Übermittlung von Daten verwendet werden. Beispielsweise können private Paketprotokolle und/oder öffentliche oder standardisierte Paketprotokolle (wie IPv6-, IoT- und/oder IIoT-Protokolle) zum Veröffentlichen und Abonnieren von I/O-Daten verwendet werden, die zwischen verschiedenen Knoten 30x, 28, 40x des virtuellen Kommunikationsnetzwerks 45 und optional an andere Anwendungen 21x, 22x, z. B. über Edge-Gateway-Systeme 28, übermittelt werden.
  • Beispielsweise kann jeder Knoten des virtuellen Kommunikationsnetzwerks 45 (z. B. die virtuellen Knoten 30x, der I/O-Switch 25, die physischen Knoten 28, 40x usw.) I/O-Daten über seine jeweilige Pub-/Sub-Schicht (z. B. über die Pub-/Sub-Schichten 32x, 35, 38, 42x usw.) an das virtuelle Kommunikationsnetzwerk 45 veröffentlichen, und jeder Knoten des virtuellen Kommunikationsnetzwerks 45 (z. B. die virtuellen Knoten 30x, der I/O-Switch 25, die physischen Knoten 28, 40x usw.) können I/O-Daten abonnieren und erhalten, die über ihre jeweilige Pub-/Sub-Schicht (z. B. über die Pub-/Sub-Schichten 32x, 35, 38, 42x usw.) an das virtuelle Kommunikationsnetzwerk 45 veröffentlicht werden. Typischerweise haben Abonnements für verschiedene veröffentlichte Daten eine Eins-zu-Eins-Entsprechung zwischen dem I/O-Switch 25 und jedem der anderen Knoten 30x, 28, 40x. In einer bevorzugten Ausführungsform akzeptiert jeder Knoten 30x, 28, 40x des virtuellen Kommunikationsnetzwerks 45 Abonnements nur vom I/O-Switch 25 und nicht von anderen Knoten, und jeder Knoten 30x, 28, 40x abonniert nur I/O-Daten, die vom I/O-Switch 25 veröffentlicht werden (wobei die vom I/O-Switch 25 veröffentlichten I/O-Daten weitergeleitete Daten sein können, die von anderen Knoten generiert wurden und die der I/O-Switch 25 abonniert hat) und nicht I/O-Daten, die von anderen Knoten veröffentlicht wurden. Als solches sind in dieser bevorzugten Eins-zu-Eins-Ausführungsform ungerichtete Graphen von Veröffentlichungs-/Abonnementbeziehungen eingeschränkt im Vergleich zu Ausführungsformen, die es Knoten ermöglichen, mehrere Abonnements mit mehreren anderen Knoten zu haben, wodurch die Netzwerkkomplexität verringert, die Netzwerkdiagnose und -verwaltung vereinfacht und die Netzwerklast / - auslastung verringert werden. Um die Netzwerkkomplexität weiter zu verringern, die Netzwerkdiagnose und -verwaltung zu vereinfachen und die Netzwerklast / -auslastung zu verringern, kann zusätzlich oder alternativ jeder Knoten 30x, 28, 40x des virtuellen Kommunikationsnetzwerks 45 per Veröffentlichung an den I/O-Switch 25 nur Daten senden, die vom I/O-Switch 25 an andere Knoten der MPDSC-Plattform 10 weitergeleitet werden sollen. Natürlich können in einigen Ausführungsformen zumindest Anteile von ungerichteten Graphen auf Wunsch in Eins-zu-Viele-, Viele-zu-Eins- und/oder Viele-zu-Viele-Beziehungen implementiert werden.
  • Im Allgemeinen werden innerhalb der MPDSC-Plattform 10 prozessbezogene Nutzlastdaten (z. B. wie sie von CBMs und/oder physischen Komponenten der Prozessanlage generiert werden) abstrahiert und als I/O-Daten veröffentlicht und können an Abonnentenknoten des virtuellen Kommunikationsnetzwerks 45 auf Bedarfsbasis übermittelt werden. Das heißt, I/O-Daten können bereitgestellt werden (z. B. über Veröffentlichung), wenn der Veröffentlichungsknoten bestimmt, dass die prozessbezogene Datennutzlast ein neues Veröffentlichungsereignis erfordert. Beispielsweise kann ein Veröffentlichungsknoten automatisch einen bestimmten Typ von sensorgenerierten Daten als I/O-Daten in dem virtuellen Kommunikationsnetzwerk veröffentlichen, wenn sich der Wert der sensorgenerierten Daten ändert. Optional kann der Veröffentlichungsknoten den vom Sensor generierten Datenwert periodisch (z. B. alle fünf Sekunden, zehn Sekunden, eine Minute usw.) als I/O-Daten veröffentlichen, selbst wenn sich der vom Sensor generierte Datenwert nicht geändert hat, z. B. um dadurch verlorene Nachrichten und andere möglicherweise auftretende Wiedergabetreueprobleme zu mindern. Daher ist in einigen Ausführungsformen keine explizite Abonnementrate erforderlich und/oder wird keine solche von Abonnentenknoten verwendet. Folglich wird die Ausführung der Verarbeitungslogik (z. B. des Komponentenverhaltensmoduls) an jedem Abonnentenknoten von eingehenden Daten gesteuert, die über das virtuelle Kommunikationsnetzwerk 45 abonniert und empfangen werden, und dementsprechend können Ressourcen, die von jedem Knoten und vom virtuellen Kommunikationsnetzwerk 45 verwendet werden, effizienter genutzt werden.
  • In einem veranschaulichenden Beispielszenario kann VN 30a zur Laufzeit einen bestimmten Satz prozessbezogener Nutzlastdaten, z. B. „Daten1“, als I/O-Daten generieren und an seine Pub-/Sub-Schicht 32a veröffentlichen. Der I/O-Switch oder Server 25 kann ein Abonnement für I/O-Daten haben, die Daten1 enthalten, und kann die prozessbezogenen Nutzlast-Daten 1 über das virtuelle Kommunikationsnetzwerk 45, seine jeweilige Pub-/Sub-Schicht 35 und sein jeweiliges Abonnement erhalten. Der I/O-Switch oder Server 25 kann wiederum die erhaltenen prozessbezogenen Nutzlast-Daten1 als I/O-Daten über seine Pub-/Sub-Schicht 35 im I/O-Netzwerk 45 veröffentlichen, damit sie von den Knoten empfangen werden, die Abonnements für I/O-Daten, die Data1 enthalten, haben. Beispielsweise kann VN 30b ein Abonnement für I/O-Daten haben, die Daten1 enthalten, und bei Veröffentlichung von Daten1 als I/O-Daten über die Pub-/Sub-Schicht 35 des I/O-Switches 25 kann VN 30b die prozessbezogenen Nutzlast-Daten1 über das virtuelle Kommunikationsnetzwerk 45, seine jeweilige Pub-/Sub-Schicht 32b und deren Abonnement dafür erhalten. Anschließend kann VN 30b mit den erhaltenen prozessbezogenen Nutzlast-Daten1-Werten arbeiten.
  • Somit lässt die MPDSC-Plattform 10 mehrere verschiedene Typen von I/O unberücksichtigt, die in verschiedenen physischen Komponenten industrieller Prozessanlagen nativ sind und verwendet werden (z. B. diskreter Ausgang, diskreter Eingang, analoger Ausgang, analoger Eingang, serieller I/O, Railbus, HART, Wireless HART, Feldbus, Profibus, Ethernet, Advanced Physical Layer und/oder andere Typen von I/O) zur Übermittlung zwischen virtuellen und physischen Knoten über den I/O-Switch 25 und das virtuelle Kommunikationsnetzwerk 45 über Veröffentlichung und Abonnement. Jeder Knoten des virtuellen Kommunikationsnetzwerks 45 kann eine entsprechende Abstraktion und De-Abstraktion (z. B. Wiederherstellung) von I/O-Daten durchführen, die er über seine jeweilige Pub-/Sub-Schicht und optional andere Subsysteme sendet und empfängt.
  • Virtuelle Knoten
  • Um I/O-Abstraktion und -De-Abstraktion zu veranschaulichen, zeigt 2 zwei beispielhafte architektonische Ausführungsformen 52a, 52b eines virtuellen Knotens 30x. Im Allgemeinen simuliert und/oder virtualisiert ein virtueller Knoten 30x einen physischen Knoten oder eine physische Komponente, die in der physischen Anlagenumgebung 15 verwendet und betrieben werden können. Jeder VN 52a, 52b enthält eine jeweilige Pub-/Sub-Schicht 55a, 55b, über die der VN 52a, 52b mit dem I/O-Switch 25 kommuniziert. Zusätzlich enthält jeder VN 52a, 52b ein entsprechendes Komponentenverhaltensmodul 58a, 58b, das hier austauschbar als „Komponenten-Geschäftslogikmodul“ 58a, 58b oder „CBM“ 58a, 58b bezeichnet wird. Allgemein gesprochen ist ein CBM 58x ein Modul, dessen Ausführung das Betriebsverhalten seines jeweiligen virtuellen Knotens 30x, z. B. auf Anwendungsebene, regelt. Beispielsweise kann das CBM 58x eines virtuellen Steuerungsknotens eine bestimmte Instanz eines Steuermoduls sein, wobei andere Instanzen des Steuermoduls zur Ausführung während der Laufzeit der physischen Anlage 15 in physische Steuerungen heruntergeladen werden können, die in der physischen Anlagenumgebung 15 angeordnet sind. In einem anderen Beispiel kann das CBM 58x eines virtuellen CIOC-Knotens eine bestimmte Instanz eines entfernten I/O-Moduls sein, wobei andere Instanzen des entfernten I/O-Moduls während der Laufzeit der physischen Anlagenumgebung 15 bei darin angeordneten physischen CIOCs ausgeführt werden können.
  • Da VBM 58x innerhalb physischer Komponenten ausgeführt werden kann, sind CBMs in der Regel mit einem oder mehreren entsprechenden nativen I/O-Typen vertraut, wie beispielsweise analogem Eingang/Ausgang, Feldbus, Railbus usw. Ferner haben CBMs 58x typischerweise keine Kenntnis darüber, ob sie auf einem virtuellen Knoten 30x der virtuellen Anlagenumgebung 12, auf einem physischen Knoten 40x, der in der physischen Anlagenumgebung 15 angeordnet ist, oder auf einer anderen physischen Komponente, die in der physischen Anlagenumgebung 15 angeordnet ist, ausgeführt werden, z. B. Knoten PNa-PNk. Als solches sendet und empfängt ein CBM 58x Daten auf dieselbe Weise und unter Verwendung derselben Verarbeitungslogik und desselben I/O-Typs, unabhängig davon, ob das CBM 58x in der virtuellen Anlagenumgebung 12 oder in der physischen Anlagenumgebung 15 ausgeführt wird.
  • In der Ausführungsform des virtuellen Knotens 52a werden prozessbezogene Nutzlastdaten, die von der CBM 58a gesendet und empfangen werden, zur Übermittlung an/von dem VN 52a über ein virtuelles Prozess-I/O (PIO)-Subsystem 60 abstrahiert. Im Allgemeinen simuliert das virtuelle PIO-Subsystem 60 die native physische PIO-Übermittlung für den virtuellen Knoten 52a. Das heißt, während der Laufzeit des virtuellen Knotens 52a kommuniziert das virtuelle PIO-Subsystem 60 I/O-Prozesswerte und -Ereignisse an das CBM 58a unter Verwendung seiner nativen I/O, z. B. als ob die I/O-Prozesswerte und Ereignisse von physischer Hardware stammten / an diese übermittelt wurden. Als solches kann das virtuelle PIO-Subsystem 60 auf den spezifischen Typ des virtuellen Knotens 52a zugeschnitten sein, wobei der Typ des virtuellen Knotens von seinem CBM 58a gesteuert wird. Wenn beispielsweise der VN 52a eine physische Steuerung darstellt, die mit anderen Geräten unter Verwendung von Railbus-I/O kommuniziert, stellt das virtuelle PIO-Subsystem 60 I/O-Daten an die/von der Steuerroutine CBM 58a in der von Railbus I/O-Karten verwendeten Form bereit. Wenn der VN 52a einen CIOC darstellt, dann stellt das virtuelle PIO-Subsystem 60 I/O-Daten an das/von dem entfernten I/O-CBM 58a in der Form, die von CHARMs verwendet wird, bereit.
  • Ferner kann das virtuelle PIO-Subsystem 60 die Veröffentlichung und das Abonnieren von Daten für den virtuellen Knoten 52a übernehmen. Das heißt, das virtuelle PIO-Subsystem 60 kann Daten, die vom CBM 58a generiert wurden, an die Pub-/Sub-Schicht 55a veröffentlichen, und das virtuelle PIO-Subsystem 60 kann Daten abonnieren, die von anderen Knoten generiert (und vom I/O-Switch 25) über die Pub/Sub-Schicht 55a weitergeleitet wurden. In einer Ausführungsform können Abonnements und Veröffentlichungen von Daten auf einem Tag oder einer anderen Kennung basieren, die innerhalb der MPDSC-Plattform 10 eindeutig ist. Das Tag oder eine andere Kennung kann beispielsweise Daten, einen Knoten, ein Gerät oder eine Komponente der MPDSC-Plattform 10 eindeutig identifizieren. In einer Ausführungsform können die Tags und/oder Kennungen während der Konfiguration und/oder Inbetriebnahme zugewiesen werden.
  • Als solches behält das virtuelle PIO-Subsystem 60 an jedem virtuellen Knoten 52a innerhalb der virtuellen Umgebung 12 eine logische Trennung zwischen dem CBM 58a und der entsprechenden physischen I/O bei (z. B. über die Pub-/Sub-Schicht 55a, das virtuelle Kommunikationsnetzwerk 45 und andere Pub-/Sub-Schichten 32, 35, 38, 42), ähnlich der logischen Trennung, die in der physischen Umgebung 15 an jedem physischen Knoten mit einem integrierten CBM 58a und seiner entsprechenden physischen I/O (z. B. über eine physische I/O-Karte oder arrangierte I/O-Anordnung) aufrechterhalten wird. Im Allgemeinen erhält das virtuelle PIO-Subsystem 60 eines beliebigen virtuellen Knotens 30 eine logische Trennung zwischen einem beliebigen I/O-Abonnenten (dem CBM 58a, einem anderen Modul, einem anderen Typ von I/O-Verbraucher usw.) aufrecht, der in dem virtuellen Knoten 30 und seiner entsprechenden physischen I/O enthalten ist.
  • In der Ausführungsform des virtuellen Knotens 52b, der in 2 dargestellt ist, ist das virtuelle PIO-Subsystem 60 weggelassen oder wird nicht verwendet. In der Regel sind die Typen von virtuellen Knoten, die die VN-Architektur 52b verwenden, diejenigen Knoten, deren CBMs 58b nativ mit den physischen Komponenten und Technologien kommunizieren können, über die das virtuelle Kommunikationsnetzwerk 45 implementiert ist. Wenn beispielsweise das virtuelle Kommunikationsnetzwerk 45 über ein IP-Protokoll über Ethernet implementiert ist, dann enthält ein virtueller Knoten 52b, der ein EIOC simuliert, ein CBM 58b, das nativ dazu konfiguriert ist, unter Verwendung des IP-Protokolls über Ethernet zu kommunizieren. Folglich kann der virtuelle EIOC-Knoten 52b das virtuelle PIO-Subsystem 60 ausschließen (oder dessen Betrieb ausschalten oder ignorieren), und der virtuelle EIOC-Knoten 52b kann die Übermittlung von Daten zum/vom virtuellen Knoten 52b nur unter Verwendung des CBM 58b und der Pub-/Sub-Schicht 55b handhaben.
  • Physische Knoten
  • 3 ist ein Blockdiagramm einer beispielhaften physischen Anlagenumgebung 100 in Verbindung mit der MPDSC-Plattform 10 von 1 kann arbeiten. Beispielsweise kann der in 1 dargestellte Anteil 15 der physischen Umgebung der MPDSC-Plattform 10 mindestens Anteile der physischen Anlagenumgebung 100 enthalten.
  • Die physische Anlage 100 steuert einen industriellen Prozess (oder arbeitet in einigen Ausführungsformen in Verbindung mit einer virtuellen Anlagenumgebung, wie der virtuellen Anlagenumgebung 12, um den industriellen Prozess zu steuern), wobei der industrielle Prozess einen oder mehrere „Prozessausgänge“ aufweisen kann, die den Zustand des Prozesses charakterisieren (z. B. Tankfüllstände, Durchflussraten, Materialtemperaturen usw.) und einen oder mehrere „Prozesseingänge“ (z. B. den Zustand verschiedener Umgebungsbedingungen und Stellantriebe, deren Manipulation dazu führen kann, dass sich die Prozessausgänge ändern). Die physische Prozessanlage 100 von 3 beinhaltet eine Feldumgebung 102 und eine Back-End-Umgebung 105, von denen jede über ein Prozesssteuerungs-Backbone oder eine Datenautobahn 108, die eine oder mehrere leitungsgebundene und/oder drahtlose Kommunikationsverbindungen und/oder -Netzwerke enthalten können, kommunikativ mit der anderen verbunden ist, und unter Verwendung eines beliebigen gewünschten oder geeigneten Kommunikationsprotokolls, wie beispielsweise eines Ethernet-Protokolls, eines IP-Protokolls oder eines anderen Paketprotokolls implementiert werden kann.
  • Auf einer hohen Ebene (und wie in 3 dargestellt) beinhaltet die Feldumgebung 102 physische Komponenten (z. B. Prozesssteuerungsgeräte, Netzwerke, Netzwerkelemente usw.), die zur Steuerung des industriellen Prozesses während der Laufzeit installiert und miteinander verbunden sind. Im Großen und Ganzen befinden sich diese physischen Komponenten in der Feldumgebung 102 der physischen Prozessanlage 100 und sind darin angeordnet, 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 Anlage 100 und andere entfernt angeordnet sein können.
  • Wie in 3 dargestellt, umfasst die Feldumgebung 102 eine oder mehrere Prozesssteuerungen 110, die kommunikativ mit der Datenautobahn 108 verbunden sind. Jede der Prozesssteuerungen 110 kann mit einem oder mehreren Zwischenknoten 112, 115 (z. B. I/O-Karten, I/O-Geräten, I/O-Systemen usw.) verbunden sein, um die Kommunikation zwischen den Steuerungen 110 und den Feldgeräten zu 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 in 3 dargestellt. In einigen Anordnungen (nicht in 3 dargestellt) sind I/O-Geräte, Karten, Steckverbinder und andere I/O-bezogene Komponenten wie Klemmenblöcke, Module, Prozessoren usw. in einem elektronischen I/O-Rangiersystem enthalten, das eine flexible I/O-Übermittlung zwischen mehreren Steuerungen und mehreren Feldgeräten 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 Erörterung und wie hierin verwendet, bezieht sich der Begriff „I/O-Geräte“ im Allgemeinen auf physische I/O-Geräte, Karten, elektronische Rangiersysteme und Komponenten davon, über die I/O-Kanäle implementiert sind, um dadurch Feldgeräte und Steuerungen kommunikativ zu koppeln.
  • In der Prozesssteuerungsindustrie kann der Begriff „I/O“ im Allgemeinen dazu verwendet werden, sich auf die auf dem I/O-Kanal übertragenen Signale (z. B. „I/O-Signale“), Variablen oder Befehle zu beziehen, die durch die Signale dargestellt werden (z. B. „I/O-Parameter“) oder auf die Werte der Variablen oder Befehle, die von den Signalen übertragen werden (z. B. „I/O-Parameterwerte“ oder „I/O-Datennutzlast“). Dementsprechend werden zur Klarheit der Erörterung und wie hierin verwendet, I/O-Signale, I/O-Parameter und I/O-Parameterwerte hierin 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 , sich aber in einigen Implementierungen auch auf eine andere Kommunikationsverbindung als einen I/O-Kanal beziehen kann.
  • In jedem Fall und zurück zu 3 implementiert jede Prozesssteuerung 110 der physischen Prozessanlage 100 eine Steuerstrategie, die durch eine oder mehrere Steuerroutinen (z. B. ein oder mehrere Komponentenverhaltensmodule) definiert ist, die in einem Speicher der Steuerung 110 gespeichert sein können. Wenn ein Prozessor der Steuerung eine oder mehrere der Steuerroutinen ausführt, sendet die Steuerung ein Steuersignal (d. h. einen „Steuerausgang“) über leitungsgebundene oder drahtlose Prozesssteuerungs-Kommunikationsverbindungen oder - Netzwerke an andere Feldgeräte zur Steuerung des Betriebs eines Prozesses in der Anlage 100. Die Steuerung kann ein Steuersignal generieren, das basiert auf: (i) einem oder mehreren empfangenen Signalen, die als „Steuereingänge“ bezeichnet werden können (z. B. ein oder mehrere empfangene Signale, die Messungen darstellen, die von Feldgeräten erhalten wurden), und (ii) der Logik der einen oder mehreren Steuerungsroutinen, die durch ein oder mehrere Softwareelemente (z. B. Funktionsblöcke) definiert werden können. Typischerweise manipuliert eine Steuerung einen Prozesseingang (der als „Stellgröße“ bezeichnet werden kann), um einen bestimmten Prozessausgang (der als „Regelgröße“ bezeichnet werden kann) basierend auf einer Rückmeldung (d. h. einer Messung der Regelgröße) und einem gewünschten Wert für den Prozessausgang (d. h. einen Sollwert) zu ändern.
  • Im Allgemeinen führt mindestens ein Feldgerät eine physische Funktion aus (z. B. Öffnen oder Schließen eines Ventils, Erhöhen oder Verringern einer Temperatur, Durchführung einer Messung, Erfassen einer Bedingung usw.), um den Betrieb eines in der physischen Prozessanlage 100 implementierten Prozesses zu steuern. Einige Typen von Feldgeräten kommunizieren mit Steuerungen über I/O-Geräte. Prozesssteuerungen, Feldgeräte und I/O-Geräte können leitungsgebunden oder drahtlos sein, und jede beliebige Anzahl und Kombination von leitungsgebundenen und drahtlosen Prozesssteuerungen, Feldgeräten und I/O-Geräten kann in der Prozessanlagenumgebung oder der -Plattform 100 enthalten sein.
  • Die Front-End-Umgebung 102 der Anlage 100 Zum Beispiel veranschaulicht 3 eine Prozesssteuerung 110, die kommunikativ mit den leitungsgebundenen Feldgeräten 125-132 über Eingangs-/Ausgangs-(I/O)-Geräte 112 und 115 verbunden ist, und die mit den drahtlosen Feldgeräten 140-146 über ein drahtloses Gateway 168 und die Datenautobahn 108 verbunden ist. In einigen (nicht dargestellten) Konfigurationen kann der Steuerung 110 kommunikativ mit dem drahtlosen Gateway 168 unter Verwendung von einem oder mehreren Kommunikationsnetzwerken außer dem Backbone 108 verbunden sein, wie z. B. durch Verwenden einer beliebigen Anzahl anderer leitungsgebundener oder drahtloser Kommunikationsverbindungen, die ein oder mehrere Kommunikationsprotokolle unterstützen, z. B. Wi-Fi oder ein anderes IEEE 802.11-konformes WLAN-Protokoll, Mobilkommunikationsprotokoll (z. B. WiMAX, LTE oder ein anderes ITU-R-kompatibles Protokoll), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® 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. In 3 sind die Steuerung 110, die Feldgeräte 125-132 und die I/O-Geräte 112, 115 leitungsgebundene Geräte, während die Feldgeräte 140-146 drahtlose Feldgeräte sind. Natürlich könnten die leitungsgebundenen Feldgeräte 125-132 und die drahtlosen Feldgeräte 140-146 allen anderen gewünschten Standards oder Protokollen, wie z. B. allen leitungsgebundenen oder drahtlosen Protokollen, einschließlich allen künftig entwickelten Standards oder Protokollen, entsprechen.
  • Der Prozesssteuerung 110 von 3. enthält einen Prozessor 120, der eine oder mehrere Prozesssteuerroutinen 118 implementiert oder überwacht (z. B. die in einem Speicher 122 der Steuerung 110 gespeichert sind). Der Prozessor 120 ist dazu konfiguriert, mit den Feldgeräten 125-132 und 140-146 und mit anderen mit der Steuerung 110 kommunikativ verbundenen Knoten zu kommunizieren. Es sei darauf hingewiesen, dass Teile von beliebigen der hierin beschriebenen Steuerroutinen oder -Module von verschiedenen Steuerungen oder anderen Geräten implementiert oder ausgeführt werden können, falls gewünscht. Ebenso können die hierin beschriebenen Steuerroutinen oder -Module 118, die innerhalb der Prozesssteuerungsanlage 100 zu implementieren sind, jede Form annehmen, einschließlich Software, Firmware, Hardware usw. Steuerroutinen können in jedem beliebigen Softwareformat implementiert werden, wie z. B. durch Verwendung objektorientierter Programmierung, Kontaktpläne, sequenzieller Funktionspläne, Funktionsblockschaltbilder 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 Steuerungsstrategie oder unter Verwendung von so genannten Funktionsblöcken, wobei jeder Funktionsblock ein Objekt oder ein anderes Teil (z. B. eine Subroutine) einer Gesamtsteuerroutine ist und in Verbindung mit anderen Funktionsblöcken (über als Links bezeichnete Kommunikationen) arbeitet, um Prozessregelkreise innerhalb der MPDSC-Plattform 10 zu implementieren. Steuerungsbasierte Funktionsblöcke führen typischerweise eines von (i) einer Eingangsfunktion, wie z. B. der mit einem Geber, einem Sensor oder einem anderen Prozessparameter-Messgerät verknüpften (manchmal als „Eingangsblöcke“ bezeichnet); (ii) einer Steuerungsfunktion, wie z. B. der mit einer Steuerroutine verknüpften, die eine PID-, Fuzzy-Logik- usw. -Steuerung (manchmal als „Steuerblöcke“ bezeichnet) durchführt, oder (iii) einer Ausgangsfunktion aus, die den Betrieb einiger Geräte, wie z. B. eines Ventils, steuert, um eine physische Funktion innerhalb der Prozesssteuerungsanlage 100 (manchmal aus „Ausgangsblöcke“ bezeichnet) auszuführen. Natürlich gibt es auch hybride und andere Typen 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 eine 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. In 3 sind die Feldgeräte 125-128 Standard 4-20 mA-Geräte oder HART®-Geräte, die über analoge Leitungen oder kombinierte analoge und digitale Leitungen mit dem I/O-Gerät 112 kommunizieren, während die Feldgeräte 129-132 intelligente Geräte wie FOUNDATION®-Feldbus-Feldgeräte sind, die über einen digitalen Bus mit dem I/O-Gerät 115 mittels eines FOUNDATION®-Feldbus-Kommunikationsprotokolls kommunizieren. In einigen Ausführungsformen können jedoch zumindest einige der leitungsgebundenen Feldgeräte 125, 126, 128-131 und/oder zumindest einige der I/O-Geräte 112, 115 zusätzlich oder alternativ mit der Steuerung 110 über die Prozesssteuerungs-Datenautobahn 108 und/oder über andere geeignete Steuerungssystemprotokolle (z. B. Profibus, DeviceNet, Foundation Feldbus, ControlNet, Modbus, HART usw.) kommunizieren. In einigen Anordnungen (in 3 nicht dargestellt) können zumindest einige der Feldgeräte 125-132 mit der Steuerung 110 über ein elektronisches I/O-Rangiersystem anstelle über ein einzelnes I/O-Gerät 112, 115 kommunizieren.
  • In 3 kommunizieren die drahtlosen Feldgeräte 140-146 über ein drahtloses Prozesssteuerungs-Kommunikationsnetzwerk 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 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 Gateways168 bedienen, das mit der Prozesssteuerungs-Datenautobahn 108 oder einem anderen Prozesssteuerungs-Kommunikationsnetzwerk verbunden ist. Das drahtlose Gateway168 ermöglicht den Zugriff auf verschiedene drahtlose Geräte 140-158 des drahtlosen Kommunikationsnetzwerks 165. Insbesondere stellt das drahtlose Gateway168 eine kommunikative Kopplung zwischen den drahtlosen Geräten 140-158, den leitungsgebundenen Geräten 125-132 und/oder anderen Knoten oder Geräten der physischen Prozesssteuerungsanlage 100 bereit. Das drahtlose Gateway 168 kann z. B. eine kommunikative Kopplung über die Prozesssteuerungsdatenautobahn 108 und/oder über ein oder mehrere andere Kommunikationsnetzwerke der physischen 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 physischen Prozessanlage 100, z. B. Öffnen oder Schließen von Ventilen oder die Vornahme von Messungen von Prozessparametern. Die drahtlosen Feldgeräte 140-146 sind jedoch für die Kommunikation unter Verwendung des drahtlosen Protokolls des Netzwerks 165 konfiguriert. Als solche sind die drahtlosen Feldgeräte 140-146, das drahtlose Gateway 168 und die anderen drahtlosen Knoten 152-158 des drahtlosen Netzwerks 165 Erzeuger und Verbraucher drahtloser Kommunikationspakete.
  • In einigen Konfigurationen der physischen Prozessanlage 100 beinhaltet das drahtlose Netzwerk 165 auch nichtdrahtlose Geräte. Zum Beispiel ist in 3 ein Feldgerät 148 von 3 ein älteres 4-20 mA-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, usw. unterstützen. Darüber hinaus enthält das drahtlose Netzwerk 165 in einigen Konfigurationen einen oder mehrere Netzwerkzugangspunkte 155a, 155b, die separate physische Geräten in leitungsgebundener Kommunikation mit dem drahtlosen Gateway 168 sein können oder die in das drahtlose Gateway 168 integriert sein können. Das drahtlose Netzwerk 165 kann auch einen oder mehrere Router 58 enthalten, um Pakete von einem drahtlosen Gerät zu einem anderen drahtlosen Gerät innerhalb des drahtlosen Kommunikationsnetzwerks 165 weiterzuleiten. In 3 kommunizieren die drahtlosen Geräte 140-146 und 152-158 miteinander und mit dem drahtlosen Gateway 168 über drahtlose Verbindungen 160 des drahtlosen Kommunikationsnetzwerks 165 und/oder über die Prozesssteuerungs-Datenautobahn 108.
  • Die Back-End-Umgebung 105 der Anlage 100
  • Die Back-End-Umgebung 105 beinhaltet, wie angemerkt, verschiedene Komponenten, wie z. B. Computergeräte, Bedienerarbeitsplätzen, 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 andere lokale oder entfernte Benutzeroberflächengeräte 170b; (ii) eine oder mehrere Konfigurationsanwendungen 172a und Konfigurationsdatenbanken 172b; (iii) eine oder mehrere andere Typen von Anwendungen 175a und/oder Datenbanken 175b, 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 185, die außerhalb der unmittelbaren OT-Schichten der physischen Prozesssteuerungsplattform 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.
  • Bedienerarbeitsplätze und Benutzeroberflächengeräte 170a, 170b
  • Die Bedienerarbeitsplätze 170a und andere Benutzeroberflächengeräte 172b 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 einige der Bedienerarbeitsplätze 172a können sich in verschiedenen, geschützten Bereichen in oder nahe der Anlage 100 befinden; und in manchen Situationen können zumindest einige der Bedienerarbeitsplätze 172b entfernt angeordnet sein, jedoch dennoch in kommunikativer Verbindung mit der Anlage 10 stehen. Die Bedienerarbeitsplätze 172a, 172b können leitungsgebundene oder drahtlose Computergeräte sein.
  • Konfigurationsanwendungen 172a und Konfigurationsdatenbanken 172b Die Konfigurationsanwendungen 172a und die Konfigurationsdatenbanken 172b können verwendet werden, um bestimmte Aspekte der Anlage 100 zu konfigurieren, wie beispielsweise Steuermodule/-routinen, Benutzeroberflächen, Datenüberwachung/-analyse usw. Beispielsweise können verschiedene Instanzen der Konfigurationsanwendung 172a auf einem oder mehreren Computergeräten (nicht dargestellt) ausgeführt werden, um Benutzern das Erstellen oder Ändern von Prozesssteuermodulen und das Herunterladen dieser Module über die Datenautobahn 108 zu den Steuerungen 110 zu ermöglichen, um Benutzeroberflächen zu erstellen oder zu ändern, über die der Bediener Daten anzeigen und Dateneinstellungen innerhalb von Prozesssteuerungsroutinen ändern kann, um Datenüberwachungs-/-analyseroutinen und - funktionen zu erstellen oder zu ändern, die in verschiedene physische Komponenten innerhalb der Feldumgebung 102 usw. heruntergeladen werden können. Die Konfigurationsdatenbanken 172b speichern die erstellten (z. B. konfigurierten) Module, Benutzeroberflächen, Datenüberwachung/-analyse usw. Im Allgemeinen sind die Konfigurationsanwendungen 172a und Konfigurationsdatenbanken 172b zentralisiert und haben ein einheitliches logisches Erscheinungsbild für die physische Prozesssteuerungsplattform 100, obwohl mehrere Instanzen der Konfigurationsanwendungen 172a gleichzeitig innerhalb der physischen Prozesssteuerungsplattform 100 ausgeführt werden können und die Konfigurationsdatenbanken 172b über mehrere physische Datenspeichergeräte implementiert werden können.
  • Dementsprechend beinhalten die Konfigurationsanwendungen 172a, die Konfigurationsdatenbanken 172b und die Benutzeroberflächen dazu (nicht dargestellt) ein Konfigurations- oder Entwicklungssystem 172 für verschiedene Typen von Modulen, z. B. Steuermodule, Anzeige- oder Benutzeroberflächenmodule und/oder Analysemodule. Typischerweise, aber nicht notwendigerweise, unterscheiden sich die Benutzeroberflächen für das Konfigurationssystem 172 von den 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 Anlage 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 MPDSC-Plattform 100 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 Anlage 100 „nicht zugewiesene“ logische Kennungen, wobei es sich um Kennungen handelt, auf die ein Softwareelement (z. B. eine Steuerroutine und/oder ein Funktionsblock) referenziert, die jedoch keine Bindung aufweisen. Das heißt, eine logische Kennung wird als „nicht zugewiesen“ betrachtet, wenn die Anlage 100 und die Konfigurationsdatenbank 172b keine Hardwareadresse oder keinen I/O-Kanal aufweisen, der an das Tag gebunden ist. Wenn also eine nicht zugewiesene logische Kennung von einer Steuerroutine referenziert wird, wird kein Wert gelesen, der von einem Signal in der Anlage 100 übertragen wird, und es wird kein Befehl über ein Signal an ein Feldgerät in der Anlage 100 übertragen.
  • Beispiele für solche logischen Kennungen schließen Geräte-Tags (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 Geräte-Signal-Tag eine Kombination aus dem Geräte-Tag eines Geräts und einer Kennung eines bestimmten Signals, das von diesem Gerät empfangen oder generiert wird, z. B. einer Kennung eines bestimmten Parameters, auf den ein Steuermodul referenziert ist. Bei einigen Geräten, normalerweise älteren oder „nicht intelligenten“ Geräten, stellt ein Geräte-Tag 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 „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äten oder Komponenten (z. B. verschiedene virtuelle Knoten 30) identifizieren und/oder adressieren, die für die virtuelle Anlagenumgebung 12 geplant sind oder in sie implementiert werden sollen. Ähnlich wie bei physischen Geräten und Komponenten kann die Konfigurationsdatenbank 172 entsprechende logische Kennungen von Komponenten der virtuellen Umgebung 12 speichern, wodurch andere Geräte und/oder Komponenten (ob physisch oder virtuell) auf die virtuellen Komponenten verweisen können. Beispielsweise können ähnlich wie bei den physischen Knoten 40x verschiedene virtuelle Knoten 30x innerhalb der MPDSC-Plattform 10 (z. B. sowohl in der virtuellen 12 als auch in der physischen 15 Umgebung) über ihre jeweiligen Geräte-Tags (DTs), Geräte-Signal-Tags (DSTs), Quell-Tags und/oder andere Typen von eindeutigen Kennungen eindeutig identifiziert werden. In weiteren Abschnitten dieser Offenbarung wird die Konfiguration und Identifizierung von virtuellen Geräten und Komponenten ausführlicher erörtert.
  • Andere Anwendungen 175a und Datenbanken 175b
  • Die anderen Anwendungen 175a und Datenbanken 175b können Instanzen von Anwendungen enthalten, die für die Prozessanlage 100 spezifisch sind, wie Diagnoseanwendungen/- Datenbanken, Data-Historian-Anwendungen/-Datenbanken, Anwendungen/Datenbanken zur Überwachung des Zustands auf Systemebene, lokale und/oder entfernte Benutzeroberflächen; usw. Im Allgemeinen können die anderen Anwendungen 175a und Datenbanken 175b eine oder mehrere Anwendungen enthalten, die auf den OT-Schichten 18 der Prozessanlage 100 und ihren zugehörigen Datenbanken ausgeführt werden. Zusätzlich oder alternativ können die anderen Anwendungen 175a und Datenbanken 175b eine oder mehrere Anwendungen enthalten, die auf den IT-Schichten 20 ausgeführt werden, die der Prozessanlage 100 zugeordnet sind, wie z. B. Bestandsverwaltungsanwendungen, Personalverwaltungsanwendungen, Lieferkettenverwaltungsanwendungen, andere Typen von unternehmensbezogenen Anwendungen, Wetter-/Umweltanwendungen usw. und die zugehörigen Datenbanken. Beispielsweise können die anderen Anwendungen 175a und Datenbanken 175b die Anwendungen 21a-21n und ihre zugehörigen Datenbanken enthalten. Darüber hinaus können die anderen Anwendungen 175a und Datenbanken 175b zusätzlich oder alternativ eine oder mehrere Anwendungen enthalten, die sich außerhalb der Prozessanlage 100 und/oder ihres Unternehmens befinden und/oder entfernt von dieser ausgeführt werden, wie Simulationsanwendungen, Analyseanwendungen, IoT-Anwendungen, IIoT-Anwendungen usw. und die zugehörigen Datenbanken. Beispielsweise können die anderen Anwendungen 175a und Datenbanken 175b die Anwendungen 22a-22m und ihre zugehörigen Datenbanken enthalten. Die anderen Anwendungen 175a und Datenbanken 175b können Anwendungen von Drittanbietern und/oder Anwendungen enthalten, die von dem mit der Prozessanlage 100 verbundenen Unternehmen bereitgestellt werden. Auf mindestens einige der anderen Anwendungen 175a und Datenbanken 175b kann über ein Edge-Gateway-System 28 und/oder eine andere Art von Sicherheits- und/oder Firewall-System zugegriffen werden.
  • Drahtlose Zugangspunkte 178
  • Die ein oder mehreren drahtlosen Zugangspunkte 178 ermöglichen es Geräten in der Back-End-Umgebung 105 (und manchmal in der Feldumgebung 102), mit anderen Geräten unter Verwendung von anderen drahtlosen Protokollen zu kommunizieren, wie z. B. 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 andere ITU-R (International Telecommunication Union Radio communication Sector)-kompatiblen Protokollen, kurzwelligen Funkkommunikationen, wie z. B. NFC und Bluetooth, oder anderen drahtlosen Kommunikationsprotokollen. Typischerweise ermöglichen solche drahtlosen Zugangspunkte 178 mobilen oder anderen tragbaren 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.
  • Gateway-Systeme 180, 182
  • Die Gateway-Knoten oder -Systeme 180 und 182 können an Systeme angeschaltet sein, die sich außerhalb der unmittelbaren physischen Prozesssteuerungsanlage 100 befinden. Typischerweise sind solche Systeme Kunden und/oder Lieferanten von Informationen, die von der physischen Prozessanlage 100 generiert oder darauf betrieben werden. Zum Beispiel kann die Prozesssteuerungsanlage 100 einen Anlagen-Gateway-Knoten 180 enthalten, um die unmittelbare physische Prozessanlage 100 kommunikativ mit einer anderen Prozessanlage zu verbinden. Zusätzlich oder alternativ kann die Prozesssteuerungsanlage 100 einen Edge-Gateway-Knoten oder ein -System 182 enthalten, um die unmittelbare physische Prozessanlage 100 mit einem externen öffentlichen oder privaten System kommunikativ zu verbinden, wie z. B. einem Laborsystem (z. B. Laborinformations-Verwaltungssystem oder LIMS), einer Operator-Rounds-Datenbank, einem Datenkonsolidierungs- und -Anzeigesystem, einem Datenanalysesystem, einem Materialflusssystem, einem 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 Prozessanlage 100 und anderen Netzwerken 185. In einer beispielhaften Architektur beinhaltet ein Edge-Gateway-System 182 eine nach innen oder zur Anlage gerichtete Engine (die als „Feld-Gateway“ bezeichnet werden kann) und eine extern oder nach außen gerichtete Engine (die als „Edge-Gateway“ bezeichnet werden kann), wobei die zur Anlage gerichtete Engine und die nach außen gerichtete Engine zusammenarbeiten, um Prozessanlagendaten (z. B. von den OT-Schichten generierte Daten) sicher an externe Netzwerke und/oder Anwendungen (z. B. IT-Schichten und/oder externe Netzwerke und/oder Systeme), die Verbraucher der Anlagendaten sind, zu übermitteln. In einer von vielen Ausführungsformen 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 die verschiedenen 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 (z. B. Anwendungen 21a-21n, 22a-22m) 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. 20180115516; 20180115528; 20180115517; und 20180113442, auf deren gesamte Offenbarungen hiermit Bezug genommen wird. Natürlich können andere Edge-Gateway-Systeme zusätzlich oder alternativ von der Prozessanlage 100 verwendet werden.
  • Es wird darauf hingewiesen, dass, obwohl 3 nur eine Steuerung 110 mit einer endlichen Anzahl von Feldgeräten 125-132 und 140-146, drahtlosen Gateways 168, drahtlosen Adaptern 152, Zugangspunkten 155, Routern 158, drahtlosen Prozesssteuerungs-Kommunikationsnetzwerken 165, die in der physischen Beispiel-Prozessanlage 100 enthalten sind, veranschaulicht, dies jedoch nur eine veranschaulichende und nicht-einschränkende Ausführungsform ist. Jede beliebige Anzahl von Steuerungen 110 kann in die Prozesssteuerungsanlage oder -Plattform 100 einbezogen werden, und jede der Steuerungen 110 kann mit einer beliebigen Anzahl von leitungsgebundenen oder drahtlosen Geräten und Netzwerken 125-132, 140-146, 168, 152, 155, 158, und 165 kommunizieren, um einen Prozess in der Anlage 100 zu steuern.
  • Nun gemeinsam Bezug nehmend auf die 1 und 3 in Bezug auf physische Knoten kann jeder in 1 gezeigte physische Knoten 40a-40c und PNa-PNk eine der jeweiligen physischen Komponenten oder Geräten sein, die in Bezug auf die Prozesssteuerungsanlage 100 von 3 erörtert wurden. Zum Beispiel kann PN 40b eine Prozesssteuerung sein, die eine jeweilige Pub-/Sub-Schicht 42b aufweist und die kommunikativ mit einem Feldgerät PNh über eine I/O-Karte PNg verbunden ist. In einem anderen Beispiel kann PN 40c ein CIOC (mit einer jeweiligen Pub-/Sub-Schicht 42c) sein, mit dem sechs verschiedene Feldgeräte PNa-PNf kommunikativ verbunden sind, oder PN 40c kann ein drahtloser Zugangspunkt 178 oder ein EIOC sein (mit einer jeweiligen Pub-/Sub-Schicht 40c), mit der verschiedene andere physische Komponenten PNa-PNf ohne Pub-/Sub-Schichten kommunikativ verbunden sind. In einem weiteren Beispiel kann PN 40a ein I/O-Rangiergerät oder ein I/O-Hub-Gerät sein, das über seine Pub-/Sub-Schicht 42a Prozess-I/O-Daten für mehrere andere PNs übermittelt, die keine Pub-/Sub-Schichten haben, z. B. PNi-PNk. Das I/O-Rangier- oder Hub-Gerät 40a kann ein eigenständiges Gerät sein oder in einer anderen physischen Komponente enthalten sein, die in der physischen Anlagenumgebung 15 angeordnet ist, wie beispielsweise in einer Steuerung 110, einem I/O-Gerät 112, 115 (z. B. einem CIOC, einem ECOC, einem WIOC usw.), ein Zugangspunkt 178, ein Gateway 180, 182 usw. Ferner können in einigen Implementierungen das Edge-Gateway-System 28 und seine Pub-/Sub-Schicht 38 ein physischer Knoten sein, der mit verschiedenen physischen Komponenten der physischen Anlagenumgebung 15 (z. B. PNs 40a-40c und PNa-PNk) kommunikativ verbunden ist (nicht in 1 dargestellt), beispielsweise in einer Art und Weise, wie in Bezug auf 3 erörtert.
  • I/O-Switch
  • Wie vorstehend erwähnt, dient der in 1 gezeigte I/O-Switch 25 als Datenbroker, Switching Fabric oder Router für Prozess-I/O-Daten zwischen Knoten des virtuellen Kommunikationsnetzwerks 45. Das heißt, der I/O-Switch 25 leitet für einen Veröffentlichungsknoten vom Veröffentlichungsknoten generierte I/O-Daten an Knoten weiter, die diese Daten abonniert haben. Im Allgemeinen kann der I/O-Switch 25 Datensätze darüber aufrecht erhalten (und pflegen), welche I/O-Daten von welchem Knoten veröffentlicht werden und welche Knoten welche veröffentlichten I/O-Daten abonniert haben. In einer Ausführungsform können die I/O-Daten innerhalb der Datensätze durch die eindeutige Kennung, den Namen oder das Tag identifiziert werden, die über die MPDSC-Plattform 10 eindeutig sind, oder durch eine entsprechende Angabe dazu. Die eindeutige Kennung kann beispielsweise die prozessbezogenen Nutzlastdaten identifizieren, die in den I/O-Daten und/oder ihrem Veröffentlichungsknoten enthalten sind. In einer Ausführungsform werden die eindeutigen Kennungen, Namen oder Tags während der Konfiguration und/oder Inbetriebnahme zugewiesen. Der I/O-Switch 25 verwendet die gespeicherten Datensätze, um eingehende veröffentlichte Daten an Abonnenten der veröffentlichten Daten weiterzuleiten. Beispielsweise kann der I/O-Switch 25 I/O-Daten abonnieren, die von verschiedenen Knoten 28, 30x, 40x veröffentlicht werden, und beim Empfang der veröffentlichten I/O-Daten über seine Abonnements kann der I/O-Switch 25 die empfangenen I/O-Daten gemäß den gespeicherten Datensätzen an ausgewählte Abonnentenknoten 28, 30x, 40x selbst veröffentlichen. Typischerweise, aber nicht notwendigerweise, führt der I/O-Switch 25 keine Pflege, Aufzeichnung oder Speicherung von I/O-Daten und/oder prozessbezogenen Nutzlastdaten, die von anderen Knoten des virtuellen Kommunikationsnetzwerks 45 veröffentlicht werden, aus.
  • Wichtig ist, dass der I/O-Switch 25 so konfiguriert ist, dass er empfangene Prozess-I/O-Daten mit minimaler Verzögerung umschaltet oder weiterleitet. In einem Prototyp war der I/O-Switch 25 tatsächlich in der Lage, empfangene Prozess-I/O-Daten über den I/O-Switch 25 in Zeitintervallen weiterzuleiten, die in Hunderten von Mikrosekunden gemessen wurden, beispielsweise unter 500 Mikrosekunden, unter 200 Mikrosekunden und unter 100 Mikrosekunden, in Abhängigkeit von der Belastung.
  • Im Allgemeinen kann der I/O-Switch 25 über Hardware, Firmware und/oder Software implementiert werden. In einem Beispiel wird der I/O-Switch 25 unter Verwendung eines oder mehrerer physischer Hardwaregeräte implementiert, auf denen spezielle Software installiert ist, um mindestens einen Teil der hier beschriebenen I/O-Switch 25-Funktionalität bereitzustellen; das heißt, der I/O-Switch 25 kann als Vorrichtung implementiert sein. In einem anderen Beispiel ist der I/O-Switch 25 als Software (z. B. Programme, Routinen, Anwendungen usw.) implementiert, die auf einem Server oder einer Bank von Computergeräten installiert und ausgeführt werden kann, um zumindest einen Teil der hier beschriebenen I/O Switch 25-Funktionalität bereitzustellen. In einem weiteren Beispiel wird der I/O-Switch 25 über eine Virtualisierung implementiert, z. B. als virtuelle Maschine, Container (wie beispielsweise Docker, LXD usw.) oder einen anderen Typ der virtualisierten Implementierung.
  • Die Pub-/Sub-Schicht 35 des I/O-Switches 25 ist im Allgemeinen in Konfiguration und Funktionalität den Pub-/Sub-Schichten 32x, 38, 42x, 55x, die an anderer Stelle in dieser Offenbarung beschrieben sind, ähnlich. Die Pub-/Sub-Schicht 35 des I/O-Switches 25 ist jedoch ferner dazu konfiguriert, Abonnementanforderungen für verschiedene identifizierte Prozess-I/O-Daten zu akzeptieren und zu pflegen. Wie vorstehend erörtert, werden Abonnements am I/O-Switch 25 aufgezeichnet und von diesem gepflegt, z. B. in einem oder mehreren greifbaren, nichtflüchtigen Speichern. Ferner ist die Pub-/Sub-Schicht 35 des I/O-Switches 25 so konfiguriert, dass veröffentlichte Prozess-I/O-Daten an Abonnementsknoten, die andere I/O-Switches enthalten können, weitergeleitet werden.
  • Zur Veranschaulichung zeigt 4 eine beispielhafte Anordnung 200 mehrerer I/O-Switches 202, 205, 208, 210, die in der MPDSC-Plattform 10 von 1 enthalten sein können. In einem Beispiel hat jeder I/O-Switch 202, 205, 208, 210 eine entsprechende Architektur ähnlich der des I/O-Switches 25, einschließlich einer jeweiligen Pub-/Sub-Schicht (wie durch die jeweiligen mit Raute markierten Anteile angegeben). Ebenfalls ähnlich dem I/O-Switch 25 ist jeder I/O-Switch 202, 205, 208, 210 über das virtuelle Kommunikationsnetzwerk 225 einem entsprechenden Satz von VNs und/oder PNs 212a-212n, 215a-215m, 218a-218p und 220a-220q zugeordnet und mit diesem verbunden, unter denen der jeweilige I/O-Switch 202, 205, 208, 210 I/O-Daten über das Veröffentlichen und Abonnieren in der Weise wie vorstehend beschrieben weiterleitet. Obwohl die Anordnung 200 vier I/O-Switches 202, 205, 208, 210 enthält, können die hier in Bezug auf die Anordnung 200 erörterten Konzepte leicht auf eine größere oder kleinere Anzahl von I/O-Switches angewendet werden, die in einer Mesh-Topologie miteinander verbunden sind.
  • In 4 kann jeder I/O-Switch 202, 205, 208, 210 ferner über das virtuelle Kommunikationsnetzwerk 225 I/O-Daten an jeden der anderen I/O-Switches 202, 205, 208, 210 weiterleiten. Durch die Verbindung mehrerer I/O-Switches 202, 205, 208, 210 kann die Anzahl der bedienten virtuellen Knoten und/oder physischen Knoten erweitert werden, um größere Systeme 10 zu unterstützen und zusätzliche Übermittlungsbandbreite bereitzustellen. In der Anordnung 200 kann jeder I/O-Switch 202, 205, 208, 210 Daten für seinen jeweiligen Satz von VNs / PNs an andere I/O-Switches 202, 205, 208, 210 veröffentlichen. In ähnlicher Weise kann jeder I/O-Switch 202, 205, 208, 210 Daten abonnieren, die von anderen I/O-Switches 202, 205, 208, 210 für ihre jeweiligen Sätze von VNs / PNs 212a-212n, 215a-215m, 218a-218p, 220a-220q weitergeleitet werden.
  • Die Anordnung 200 zeigt, dass jeder der I/O-Switches 202, 205, 208, 210 mit jedem der anderen I/O-Switches 202, 205, 208, 210 direkt verbunden ist. Das heißt, das virtuelle Kommunikationsnetzwerk 225 weist eine vollständig vernetzte oder Mesh-Topologie auf. Dementsprechend ist in einer Implementierung dieser Anordnung 200 die maximale Übertragungsverzögerung von einem Veröffentlicher-Knoten zu einem Abonnentenknoten begrenzt, da die maximale Anzahl von Sprüngen, die eine bestimmte Prozess-I/O-Datennutzlast durchlaufen kann, drei beträgt. In anderen Implementierungen der Anordnung 200 kann die maximale Anzahl von Sprüngen unterschiedlich sein. Beispielsweise kann die maximale Anzahl von Sprüngen erhöht werden, z. B. zum Überwachen von Verkehr, wenn Zeitsequenzierungsfunktionen (wie Zeitsequenzierungsnetzwerke oder andere geeignete Zeitsequenzierungsfunktionen) und dergleichen verwendet werden. Falls gewünscht, kann eine maximale Anzahl von Sprüngen innerhalb der Anordnung 200 konfiguriert und modifiziert werden.
  • Natürlich können zusätzlich oder alternativ zur Mesh-Topologie für das virtuelle Kommunikationsnetzwerk 225 auch andere vernetzte Topologien (z. B. Hub-and-Spoke, Stern, Ring, Baum, Hybrid usw.) möglich sein. Im Allgemeinen erfolgen Abonnements zum Verarbeiten von I/O-Daten, die von einem bestimmten Veröffentlichungsknoten, z. B. dem Knoten 215a, veröffentlicht werden, an den entsprechenden I/O-Switch, z. B. den I/O-Switch 205, und werden von diesem verwaltet. Wenn der I/O-Switch 205 jedoch keinen Datensatz für die bestimmten Daten hat, für die ein Abonnement angefordert wird, kann der I/O-Switch 205 die Abonnementanforderung an die anderen I/O-Switches 202, 208, 210 weiterleiten. Der bestimmte I/O-Switch, der dem Knoten entspricht, der die angeforderten Daten veröffentlicht, z. B. der I/O-Switch 210, der dem Veröffentlichungsknoten 220q entspricht, hat einen Datensatz, der den angeforderten Daten und deren Veröffentlichungsknoten 220q entspricht, und antwortet an den I/O-Switch 205 entsprechend dem anfordernden Knoten 215a, auf dem der I/O-Switch 105 einen entsprechenden Datensatz für die angeforderten Daten erstellen und speichern kann. Auf diese Weise kann eine Durchlaufroute für die angeforderten Daten vom Veröffentlichungsknoten 220q zum Abonnementknoten 215a über die I/O-Switches 210, 205 eingerichtet werden.
  • In einer Ausführungsform kann die Anordnung 200 über mehrere MPDSC-Systeme 10 implementiert sein. Beispielsweise kann der I/O-Switch 202 in einem ersten MPDSC-System enthalten sein, und der I/O-Switch 205 kann in einem anderen MPDSC-System enthalten sein. Als solche können verschiedene MPDSC-Systeme die Prozess-I/O-Daten des jeweils anderen über eine oder mehrere Verbindungen des virtuellen Kommunikationsnetzwerks 225 veröffentlichen und/oder abonnieren.
  • Virtuelle Echtzeitsteuerung und zugehörige Operationen
  • Wie vorstehend erwähnt, können die virtuellen Knoten 30x das Verhalten der verschiedenen physischen Komponenten, die innerhalb des physischen Anlagenumgebung 15 betreibbar sind, virtualisieren. Ferner können aufgrund der Merkmale der MPDSC-Plattform 10 virtualisierte Komponenten 30x der virtuellen Anlagenumgebung 12 in Verbindung mit physischen Komponenten der physischen Anlagenumgebung 15 arbeiten, um Echtzeitsteuerung der industriellen Prozessanlage während der Laufzeit durchzuführen um dadurch physische Produkte aus Rohstoffen zu generieren. Unter gleichzeitiger Bezugnahme auf die 1, 2 und 3 zur Veranschaulichung kann die Prozesssteuerung 110 als der virtuelle Knoten 30a virtualisiert werden, der eine Architektur 52a aufweist. Als solches enthält der virtuelle Knoten 110/30a anstelle der physischen Prozesssteuerung 110, die ihre entsprechenden Steuermodule oder - Routinen 118 zur Laufzeit ausführt, die Steuermodule oder -Routinen 118 wie sein CBM 58a und führt die entsprechenden Steuermodule oder -Routinen 118 während der Laufzeit aus, was das Senden und Empfangen von Signalen zu/von verschiedenen Feldgeräten beinhalten kann, die in der physischen Umgebung 15 über den I/O-Switch 25 angeordnet sind.
  • Beispielsweise kann während der Laufzeit der industriellen Prozessanlage 100 die virtuelle Steuerung 110/30a Daten empfangen, die von dem Feldgerät 129 über ein physisches I/O-Gerät 115 generiert werden. In diesem Beispiel ist das physische I/O-Gerät 115 in 1 durch den physischen Knoten PNg, dargestellt; das Feldgerät 129 ist in 1 durch den physischen Knoten PNh dargestellt und der physische Knoten 40b ist ein I/O-Hub-Gerät. Datennutzlast, die durch das Feldgerät PNh generiert wird, wird über das I/O-Gerät PNg an das I/O-Hub-Gerät 40b übermittelt, das ein Knoten des virtuellen Kommunikationsnetzwerks 45 ist. Das I/O-Hub-Gerät 40b kann an den I/O-Switch 25 die Datennutzlast veröffentlichen, die durch das Feldgerät PNh generiert und vom I/O-Hub-Gerät 40b veröffentlicht wurde, für das der I/O-Switch 25 über ein Abonnement verfügt. Im Gegenzug kann der I/O-Switch 25 die Nutzlastdaten, die durch das Feldgerät PNh generiert wurden, an die virtuelle Steuerung 110/30a veröffentlichen, woraufhin das CBM 58a (z. B. die Steuermodule/Routinen 118) der virtuellen Steuereinheit 110/30a mit den vom Feldgerät PNh generierten Nutzlastdaten arbeiten kann. Das CBM 58a kann Ausgangsnutzlastdaten generieren, die über das virtuelle Kommunikationsnetzwerk 45 an einen anderen virtuellen oder physischen Knoten übermittelt werden sollen.
  • In einem anderen Beispiel kann die virtuelle Steuerung 110/30a während der Laufzeit der industriellen Prozessanlage 100 Daten empfangen, die von dem drahtlosen Feldgerät 142a generiert werden. In diesem Beispiel ist das physische drahtlose Feldgerät 142a in 1 durch den physischen Knoten PNa dargestellt, und das physische drahtlose Gateway 168 ist durch PN 40c dargestellt. Das drahtlose Gateway PN 40c empfängt Nutzlastdaten, die durch das drahtlose Feldgerät PNa generiert wurden. Da PN 40c ein Knoten des virtuellen Kommunikationsnetzwerks 45 ist, veröffentlicht PN 40c an den I/O-Switch 25 die Nutzlastdaten, die von dem drahtlosen Feldgerät PNa generiert wurden, für die der I/O-Schalter 25 über ein Abonnement verfügt. Im Gegenzug kann der I/O-Switch 25 die Nutzlastdaten, die von dem Feldgerät PNa generiert wurden, an einen virtuellen Knoten 30b veröffentlichen, wobei der virtuelle Knoten 30b als Darstellung eines I/O-Geräts, wie beispielsweise des I/O-Geräts 115, konfiguriert ist. Das virtuelle I/O-Gerät 30b verfügt über ein Abonnement für die Nutzlastdaten, die von dem Feldgerät PNa generiert und durch den I/O-Switch 25 weitergeleitet wurden. Als solches erhält das virtuelle I/O-Gerät 30b die durch das drahtlose Feldgerät PNa generierten Nutzlastdaten über sein Abonnement und veröffentlicht von neuem die erhaltenen, von dem Feldgerät PNa generierten Nutzlastdaten an den I/O-Switch 25 zur Weiterleitung an geeignete Abonnenten. Der I/O-Switch 25 kann wiederum die erhaltenen Nutzlastdaten des Feldgeräts PNa veröffentlichen, die durch das virtuelle I/O-Gerät 30b an seine jeweiligen Abonnenten, die (in diesem Beispiel) die virtuellen Steuerung 30a beinhalten, veröffentlicht wurde. Bei Empfang der Nutzlastdaten an der virtuellen Steuerung 30a über sein entsprechendes Abonnement kann das CBM 58a (z. B. die Steuermodule/-Routinen 118) der virtuellen Steuerung 30a, mit den Nutzlastdaten, die durch das drahtlose Feldgerät PNa generiert wurden, arbeiten. Das CBM 58a kann Ausgangsnutzlastdaten generieren, die über das virtuelle Kommunikationsnetzwerk 45 an einen anderen virtuellen oder physischen Knoten übermittelt werden sollen.
  • Die Virtualisierung physischer Komponenten von industriellen Prozessanlagen bietet zahlreiche Vorteile gegenüber industriellen Prozessanlagen, die vollständig mit physischen Komponenten implementiert sind. Durch virtualisierte Komponenten kann eine industrielle Prozessanlage in Bezug auf Größe und Anzahl der Komponenten flexibel vergrößert und/oder verkleinert werden, wobei nur minimale Änderungen des Hardware-Platzbedarfs und geringere Installationskosten erforderlich sind. Da ein virtueller Knoten ein physisches Gerät in seiner Gesamtheit oder nur einen Anteil davon darstellen kann, kann die Steuerung leicht skaliert werden, z. B. über so viele virtuelle Knoten wie erforderlich. Darüber hinaus bietet die MPDSC-Plattform 10 I/O-Flexibilität beispielsweise über die Abstraktion von I/O, sodass Steuerungen weniger von tatsächlichen konfigurierten und heruntergeladenen I/O-Modulzuweisungen abhängig sind. Das heißt, dass I/O-Bindungsentscheidungen zwischen physischen I/O-Geräten und Steuerungen und Feldgeräten zumindest aufgrund des I/O-Switches 25 eliminiert werden können. Durch die Verwendung virtueller physischer Komponenten können Software-Upgrades auf die virtualisierten physischen Komponenten problemlos durchgeführt werden. Darüber hinaus können Simulationen und Online-Tests des Verhaltens physischer Komponenten gegenüber derzeit bekannten Techniken durch die Verwendung der MPDSC-Plattform 10 ebenfalls leicht erreicht und verbessert werden.
  • Virtualisierungsverwaltungsknoten
  • 5 ist ein Blockdiagramm, das eine beispielhafte Architektur veranschaulicht, die Konfiguration, Inbetriebnahme, Verwaltung und Administration des MPDSC-Systems 10 von 1 unterstützt. Der Übersichtlichkeit halber und nicht zu Zwecken der Einschränkung wird 5 hierin unter gleichzeitiger Bezugnahme auf 1-4 erörtert. Wie in 5 dargestellt, erstellt, konfiguriert und verwaltet ein Virtualisierungsverwaltungsknoten 300 (der hier austauschbar als „VMN 300“ oder „virtueller Knoten 300“ bezeichnet wird) virtualisierte Komponenten des MPDSC-Systems 10, wie beispielsweise den I/O-Switch 25, verschiedene virtuelle Knoten 30x, das virtuelle PIO-Subsystem 60, die Veröffentlichungs-/Abonnementschichten 32x, 35, 38, 42x usw. Der VMN 300 führt automatisch mindestens einen Teil der Erstellung, Konfiguration und Verwaltung virtueller Komponenten durch. Zusätzlich oder alternativ führt der VMN 300 zumindest einen Teil der Erstellung, Konfiguration und Verwaltung der virtuellen Komponenten basierend auf manuellen Anweisungen, z. B. manuellen Anweisungen, die über eine Benutzeroberfläche 302 des VMN 300 empfangen werden, die lokal oder eine entfernte Benutzeroberfläche sein kann, durch. Ferner steuert und/oder koordiniert der Virtualisierungsverwaltungsknoten 300 Simulationsaktivitäten der virtuellen Prozessumgebung 12, die mit und/oder ohne Inline-Benutzereingabe während der Simulationen durchgeführt werden können, wie nachstehend ausführlicher beschrieben wird.
  • Konfiguration, Administration und Verwaltung virtueller Komponenten
  • In einer Ausführungsform greift der VMN 300 während der Konfiguration und/oder Inbetriebnahme der virtuellen Umgebung 12 und ihrer Komponenten auf die Systemkonfigurationsdatenbank der Anlage zu (z. B. greift der VMN 300 auf die Konfigurationsdatenbank(en) 172b der Anlage 100 über die Datenautobahn 108 zu) und basierend auf der erhaltenen Konfiguration bestimmt der VMN 300 die Typen und Anzahlen von virtuellen Knoten, virtuellen Vorlagen und/oder Subsystemen, I/O-Switches und/oder anderen virtuellen Komponenten, die die Anlagenkonfiguration am besten unterstützen würden (oder die zu deren Unterstützung gewünscht werden). Der VMN 300 erstellt die verschiedenen Typen und Anzahlen von virtuellen Knoten 30x und konfiguriert den I/O-Switch 25 und die virtuellen Knoten 30x zum Kommunizieren über das virtuelle Kommunikationsnetzwerk 45, beispielsweise über entsprechende Veröffentlichungs-/Abonnements-Schichten 32x und, für einige VNs 30x, über das virtuelle PIO-Subsystem 60. Bei manchen Anlagenkonfigurationen kann der VMN 300 Instanzen von Veröffentlichungs-/Abonnements-Schichten 42x (und optional Instanzen des virtuellen PIO-Subsystems 60) erstellen und an verschiedene physische Komponenten 40x der physischen Anlagenumgebung 15 verteilen. Als solches kann der VMN 300 eine beliebige Anzahl von Knoten 25, 28, 30x, 40x des virtuellen Kommunikationsnetzwerks 45 erstellen, konfigurieren und administrieren, die virtuelle Komponenten enthalten können, die in Verbindung mit physischen Komponenten der physischen Anlage arbeiten, um Echtzeitsteuerung und/oder dynamische Simulation durchführen.
  • Die Konfiguration des virtuellen Kommunikationsnetzwerks 45 und seiner Knoten 25, 28, 30x, 40x kann in der Systemkonfigurationsdatenbank 172b und/oder lokal in einer Konfigurationsdatenbank 305 für die virtuelle Umgebung gespeichert sein. In einigen Implementierungen wird eine Master-Version der Konfiguration der virtuellen Anlagenumgebung 12 in der Systemkonfigurationsdatenbank 172b (zusammen mit der Konfiguration der physischen Anlagenumgebung 15) gespeichert und eine Kopie der Master-Konfiguration der virtuellen Anlagenumgebung 12 wird lokal in der Konfigurationsdatenbank 305 der virtuellen Umgebung gespeichert. In einigen Implementierungen wird eine Master-Version der Konfiguration der virtuellen Anlagenumgebung 12 in der Konfigurationsdatenbank 305 der virtuellen Umgebung gespeichert, und eine Kopie der Master-Konfiguration der virtuellen Anlagenumgebung 12 wird in der Systemkonfigurationsdatenbank 172b (zusammen mit der Konfiguration der physischen Anlagenumgebung 15) gespeichert. Der VMN 300 koordiniert die Änderungsverwaltung und Synchronisation von Daten, die in der Konfigurationsdatenbank 305 der virtuellen Umgebung gespeichert sind, und verwandte Daten, die in der Systemkonfigurationsdatenbank 172b gespeichert sind.
  • Während die Anlage 100 operative Prozesssteuerung während der Laufzeit der Prozessanlage 100 durchführt, kann der VMN 300 den I/O-Switch 25, virtuelle Knoten 30x, das virtuelle Kommunikationsnetzwerk 45 sowie damit verbundene Knoten überwachen (wie beispielsweise physische Knoten 40x, 28) in Bezug auf beispielsweise das Laden von Ressourcen, die Verfügbarkeit von Ressourcen, die Bandbreite von Ressourcen, das Auftreten von Fehlern und andere Leistungsprobleme von Hardware- und/oder Softwareressourcen, die von der physischen Computerplattform bereitgestellt werden, die die virtuelle Umgebung 12 unterstützt, z. B. Plattform von Hardware-Computergeräten, die die virtuelle Umgebung 12 unterstützen. Basierend auf erkannten und/oder vorhergesagten Bedingungen kann der VMN 300 während Laufzeitoperationen automatisch Abschwächungsaktionen durchführen, z. B. Anpassen der Ressourcenzuweisungen, Aktivieren von virtuellen Standby-Knoten, Erstellen und/oder Löschen von virtuellen Knoten usw., z. B. für Lastausgleich, Fehlerbehebung und andere Leistungszwecke. Beispielsweise kann der VMN 300 Leistungsengpässe analysieren und automatische Regulierungsoperationen durchführen, um erkannte Engpässe zu mindern. Beispielsweise kann der VMN 300 als Reaktion auf die Menge des virtuellen Netzwerkverkehrs im virtuellen Kommunikationsnetzwerk 45 eine automatische Regulierung auf Prozessdatenebene durchführen, und/oder der VMN 300 kann so eine automatische Regulierung auf der Ebene eines physischen Computergeräts durchführen, so dass diese CPU- und/oder physische Netzwerkauslastung über die physischen Computergeräte, physischen Datenverbindungen und/oder physischen Netzwerke, in denen die virtuelle Umgebung 12 implementiert ist, ausgeglichen wird.
  • In administrativer Hinsicht kann der VMN 300 Speichern, Snapshots, Sichern, Migrieren, Wiederherstellen usw. verschiedener virtueller Knoten, virtueller Vorlagen und Subsysteme sowie der zugehörigen Prozessdaten durchführen, und der VMN 300 kann Speichern, Snapshots, Sichern, Migrieren, Wiederherstellen usw. der gesamten virtuellen Umgebung 12 selbst durchführen. In einer Ausführungsform kann jede vom VMN 300 ausgeführte administrative Aktion auf eine Gesamtheit der Logik angewendet werden, die von betreffenden virtuellen Knoten simuliert wird (z. B. die Gesamtheit der Logik, die von einem kollektiven Satz von CBMs 58 der betreffenden virtuellen Knoten ausgeführt wird). Wenn beispielsweise ein Snapshot von einer virtuellen Steuerung erstellt und gespeichert wird, speichert der VMN 300 möglicherweise nicht nur Daten, die von der virtuellen Steuerung empfangen, bearbeitet und generiert werden und Angaben zu deren Vernetzungen und Betriebszustände machen, sondern der VMN 300 speichert unter Umständen im Rahmen des Snapshots auch die zugehörigen Daten von Modulen, die in Verbindung mit der virtuellen Steuerung ausgeführt werden, selbst wenn diese Module auf anderen Knoten gehostet werden und/oder andere physische Komponenten simulieren. In einem anderen Beispiel kann der VMN 300 beim Erstellen und Speichern eines Snapshots eines virtuellen CIOC Daten speichern, die der Ebene der virtuellen Maschine des virtuellen CIOC entsprechen, und/oder der VMN 300 kann Prozesssimulationswerte speichern, die vom virtuellen CIOC beobachtet werden.
  • Dynamische Simulation
  • Wie vorstehend erwähnt, unterstützt das MPDSC-System 10 die dynamische Simulation der gesamten Prozessanlage 100 und/oder von Anteilen davon. Beispielsweise stellt das MPDSC-System 10 eine Echtzeitsimulation bereit, bei der die Echtzeitsimulation die Laufzeit-Zeitsteuerung, die Werte und/oder andere Verhaltensweisen mindestens eines Teils einer entsprechenden physischen Komponente und/oder eines physischen Betriebsprozesses widerspiegelt. Wie hierin verwendet, werden die Begriffe „Simulation“ und „Simulationslauf“ austauschbar verwendet, und eine Simulation oder ein Simulationslauf ist begrenzt. Das heißt, jede Simulation oder jeder Simulationslauf hat einen jeweiligen Start und ein jeweiliges Ende, die wie gewünscht definiert werden können, z. B. basierend auf einer Zeit, einem Parameterwert, einem Zustand, einem Benutzerbefehl und/oder anderen Kriterien.
  • Zusätzlich sieht das MPDSC-System 10 die Manipulation von Simulationen vor, wie zum Beispiel das Beschleunigen oder Verlangsamen des Tempos der Simulationsausführung, das Anhalten der Simulation, das Einfügen und/oder Ändern verschiedener Werte, das Ändern von Ausgangsbedingungen usw. Simulationen können vollständig innerhalb der virtuellen Umgebung 12 des MPDSC-Systems 10 ausgeführt werden, und/oder Simulationen können unter Verwendung einer oder mehrerer virtueller oder simulierter Komponenten in Verbindung mit einer oder mehreren physischen Komponenten ausgeführt werden (z. B. kann eine Konfiguration einer Steuerung, die von einem virtuellen Knoten in der virtuellen Umgebung 12 simuliert wird, mit einem physischen Feldgerät kommunizieren, das in der physischen Umgebung 15 angeordnet ist, um das simulierte Steuerungsverhalten zu testen). Im Allgemeinen bietet das MPDSC-System 10 eine Plattform, über die Ingenieure und Benutzer Entwürfe von Steuerungsstrategien und Entwürfe von Bedieneranzeigen testen und überprüfen, Prozessverbesserungen untersuchen, Bedienerschulungen durchführen, Fallstudien durchführen können, usw. Der VMN 300 verwaltet, koordiniert und steuert Simulationsaktivitäten an, die vom MPDSC-System 10 unterstützt werden.
  • Insbesondere erstellt, konfiguriert und administriert der VMN 300 virtuelle Knoten 25, 30x und andere virtuelle Komponenten 28, 32, 35, 38, 42x, 60, die mindestens Anteile der physischen Anlage 100 simulieren. Virtuelle Knoten 25, 30x, die ausschließlich zu Simulationszwecken (und nicht zu Laufzeitsteuerungszwecken) verwendet werden, werden hierin austauschbar als „simulierte Knoten“ bezeichnet. Beispielsweise kann der VMN 300 ein Spiegelsimulationssystem des gesamten Laufzeitsteuersystems generieren, wie es durch die Anlagenkonfigurationsdatenbank 172b beschrieben ist, z. B. indem simulierte Knoten verwendet werden, die integrale physische Hardwarekomponenten wie Steuerungen 110, Arbeitsplätze 170a und/oder andere physische Geräte und ihre entsprechenden Netzwerkverschaltungen (in einigen Implementierungen bis auf die MAC-Adressenebene) simulieren. In einem anderen Beispiel kann der VMS 300 entsprechende Simulationen einer oder mehrerer einzelner physischer Komponenten generieren, von denen jede in einem eigenständigen Modus oder in Verbindung mit einer oder mehreren anderen simulierten, virtuellen und/oder physischen Komponenten ausgeführt werden kann. Beispielsweise kann der VMS 300 innerhalb der virtuellen Umgebung 12 einen virtuellen Zwilling einer physischen Komponente generieren, die derzeit in der physischen Umgebung 15 arbeitet, z. B. um eine neue Steuerungskonfiguration, ein Upgrade, einen Patch usw. zu testen, die/das auf die physische Komponente anzuwenden ist. In einem anderen Beispiel kann VMS 300 eine Simulation eines Verhaltens einer bestimmten physischen Komponente auf MAC-Adressenebene generieren. In noch einem weiteren Beispiel kann der VMS 300 einen einheitlichen (z. B. einzelnen) simulierten Knoten generieren, der das Echtzeit-Betriebsverhalten einer Gruppe von physischen Geräten, Komponenten oder Knoten simuliert, wie z. B. einen Regelkreis oder eine Bedieneranzeigeansicht.
  • In Bezug auf das Konfigurieren der Typen von Datenwerten, die in der virtuellen 12 und physischen 15 Umgebung des Prozessleitsystems 100 verwendet werden, definiert in einer Ausführungsform eine Systemprozessdatendefinition (die über eine Systemkonfigurationsanwendung 172a und/oder über den VMS 300 konfiguriert werden kann), welche Datenwerte (und/oder Typen davon), die in der Prozessanlage 100 verwendet werden, simuliert werden sollen, und der VMS 300 weist den Datenwerten (und/oder Typen davon) entsprechende Daten-Tags (z. B. Kennungen) zu, die zu simulieren sind. Beispielsweise kann der VMS 300 mindestens einigen Datenwerten und/oder Datentypen, die simuliert werden sollen, automatisch Daten-Tags zuweisen, und/oder der VMS 300 kann manuell generierte Daten-Tags mit mindestens einigen Datenwerten und/oder Datentypen, die simuliert werden sollen, empfangen, z. B. über die Benutzeroberfläche 302. Zugewiesene Daten-Tags von simulierten Datenwerten und/oder Datentypen können in der Konfigurationsdatenbank 305 der virtuellen Umgebung und/oder in der Systemkonfigurationsdatenbank 172b gespeichert werden.
  • Zusätzlich steuert und/oder koordiniert der VMN 300 die Simulationen der gesamten physischen Anlage 100 und/oder Anteile davon. Zu diesem Zweck stellt die virtuelle Umgebung 12 eine Simulator-API (Application Programming Interface - Anwendungsprogrammierschnittstelle) 310 oder einen anderen geeigneten Zugriffsmechanismus bereit, über den Anwendungen, wie die Benutzeroberfläche 302, IT-Layer-Anwendungen 21x und/oder Anwendungen von Drittanbietern oder externen Anbietern 22x zu Simulationszwecken mit der virtuellen Umgebung 12 verbunden sein können. In einer Ausführungsform hostet der VMN 300 oder ein anderes Computergerät in der virtuellen Umgebung 12 die Simulator-API 310 und/oder stellt sie anderen Anwendungen bereit.
  • Wie in 5 dargestellt, kommuniziert die Simulator-API 310 simulierte Datenwerte (hierin auch austauschbar als „Simulationsdatenwerte“, „simulierte Werte“ und/oder „Simulationswerte“ bezeichnet) an die und von der virtuellen Umgebung 12 und darin enthaltene simulierte Komponenten über den I/O-Switch 25. Allgemein gesprochen werden simulierte Laufzeitprozessdaten zwischen 28, 30x und der Simulator-API 310 über die jeweiligen Pub-/Sub-Schichten der Knoten übermittelt. Beispielsweise können die simulierten Knoten 28, 30x, 310 Laufzeitprozessdaten über den I/O-Switch 25 auf einem oder mehreren anderen simulierten Knoten 28, 30x, 310 veröffentlichen, und die simulierten Knoten 28, 30x, 310 können Laufzeitprozessdaten abonnieren, die von einem oder mehreren anderen simulierten Knoten 28, 30x, 310 generiert und über den I/O-Switch 25 empfangen werden. Andererseits können in einer Ausführungsform simulierte Datenwerte, die keine Laufzeitprozessdaten sind (z. B. Datenwerte, die konfigurierbar sind und die typischerweise während der Downloadzeit in der physischen Umgebung 15 zugewiesen werden), zwischen simulierten Knoten 28, 30x, 310 im geänderten Zustand übermittelt werden, z. B. nur, wenn sich die jeweiligen Werte der Daten ändern.
  • Die Simulator-API 310 ist mit Namen, Daten-Tags, Kennungen, Datendefinitionen, Kanaldaten usw. von simulierten Komponenten in der virtuellen Umgebung 12 (z. B. basierend auf Daten, die in der virtuellen Konfigurationsdatenbank 305 gespeichert sind) konfiguriert und die Simulator-API 310 ist auch dazu konfiguriert, unter Verwendung eines oder mehrerer industrieller und/oder universeller Kommunikations-/Datenprotokolle zu kommunizieren, wobei es sich um ein standardisiertes Protokoll handeln kann, z. B. OPC, Ethernet, IPv6 usw. Als solches dient die Simulator-API 310 als Datenübermittlungs- und Transportmechanismus zwischen simulierten Komponenten innerhalb der virtuellen Umgebung 12 und anderen Anwendungen 302, 21x, 22x, die Verbraucher und/oder Anbieter von Simulationsdaten sind und die das eine oder mehrere industrielle und/oder universelle Kommunikations-/Datenprotokolle verwenden. Beispielsweise kann eine Simulationsanwendung eines Drittanbieters die Simulator-API 310 verwenden, um Testwerte zur Verwendung durch eine simulierte Komponente zuzuführen, die Ausgangsbedingungen eines Simulationslaufs zu ändern usw.
  • Zusätzlich oder alternativ verarbeitet die Simulator-API 310 Simulationsbefehle, die über die Benutzeroberfläche 302 und/oder durch andere Anwendungen 21x, 22x bereitgestellt werden. Beispielsweise kann die Simulator-API 310 Simulationsbefehle empfangen, um das Tempo der Modulausführung zu beschleunigen und/oder zu verlangsamen (wovon zumindest ein Teil in der virtuellen Umgebung 12 simuliert wird) und/oder um das Tempo der I/O-Verarbeitung zu beschleunigen und/oder zu verlangsamen, und kann die Zeitsteuerung und die Aktionen von zugeordneten simulierten Knoten 30x, 28 und/oder des virtuellen Kommunikationsnetzwerks 45 entsprechend steuern. In einem anderen Beispiel kann die Simulator-API 310 Simulationsbefehle empfangen, um verschiedene Datenwerte während der Simulation zuzuführen und/oder zu ändern. Ferner kann die Simulator-API 310 administrative Simulationsbefehle empfangen, um beispielsweise einen Snapshot zu speichern, einen gespeicherten Snapshot abzurufen, aus gespeicherten Daten wiederherzustellen usw. und die entsprechende Aktion als Antwort auszuführen. Beispielsweise kann die Simulator-API 310 Simulationsbefehle empfangen und darauf reagieren, um eine Simulation der gesamten Prozessanlage 100 zu speichern, abzurufen, wiederherzustellen usw. (z. B. zu/von der Konfigurationsdatenbank 305 für die virtuelle Umgebung und/oder von zu/von der Systemkonfigurationsdatenbank 172b) sowie zum Speichern, Abrufen, Wiederherstellen usw. einer Simulation eines oder mehrerer Knoten oder Komponenten der Prozessanlage 100.
  • Im Allgemeinen ist die Simulations-API 310 statusbehaftet. Das heißt, die Simulations-API 310 kennt verschiedene Zustände der Simulation und der Komponenten (z. B. von virtuellen, physischen und/oder simulierten Geräten; virtuellen, physischen und/oder simulierten Modulen; anderen Typen von virtuellen, physischen und/oder simulierten Komponenten, einen Prozess, der durch die Simulation zumindest teilweise simuliert wird, einen Zustand der Gesamtsimulation usw.), die damit verbunden sind, während die Simulation ausgeführt wird und auf die empfangenen Befehle basierend auf den verschiedenen Zuständen reagiert. Wenn die Simulations-API 310 beispielsweise auf einen Befehl zum Speichern reagiert, kann sie Prozessdaten in Verbindung mit Daten speichern, die Angaben zum Status der zugeordneten Komponenten machen. In einem anderen Beispiel kann es die Simulations-API 310 beim Simulieren eines modifizierten Steuermoduls, das zu Testzwecken in einer Steuerung ausgeführt wird, einem Benutzer ermöglichen, den Status eines zugeordneten Moduls zu ändern, um zu bestimmen, wie das modifizierte Steuermodul auf verschiedene Zustände des zugeordneten Moduls reagieren würde.
  • 6 ist ein Flussdiagramm eines Verfahrensbeispiels 400 zum Steuern eines Knotens eines Prozessleitsystems einer industriellen Prozessanlage. Zumindest ein Anteil der Ausführungsformen des Verfahrens 400 kann durch einen oder mehrere Anteilen des dynamischen Mehrzweck-Simulations- und industriellen Laufzeit-oder Prozessleit-(MPDSC)-Systems oder der Plattform 10 von 1 und/oder einer oder mehrerer Komponenten davon; durch einen oder mehrere Anteile von Ausführungsformen der virtuellen Knoten 52a, 52b von 2; durch einen oder mehrere Anteile von Ausführungsformen der physischen Anlagenumgebung 100 von 3 und/oder eine oder mehrere Komponenten davon; durch einen oder mehrere Anteile von Ausführungsformen der Anordnung 200 von I/O-Switches von 4; und/oder durch einen oder mehrere Anteile von Ausführungsformen des Virtualisierungsverwaltungsknotens 300 von 5 ausgeführt werden. Zur leichteren Veranschaulichung und nicht zu Zwecken der Einschränkung wird das Verfahren 400 hierin unter gleichzeitiger Bezugnahme auf Anteile der 1-5 beschrieben. Ferner kann das Verfahren 400 in Ausführungsformen mehr, weniger und/oder andere alternative Schritte als die hierin beschriebenen einschließen.
  • Wie in 6 veranschaulicht, beinhaltet das Verfahren 400 das kommunikative Verbinden (Block 402) eines Feldgeräts und eines virtuellen Knotens über einen I/O-Switch, der zwischen dem Feldgerät und dem virtuellen Knoten angeordnet ist, so dass das Feldgerät, der I/O-Switch und der virtuelle Knoten während der Laufzeitoperationen der industriellen Prozessanlage zusammenarbeiten, z. B. um einen industriellen Prozess zu steuern. Beispielsweise kann das Feldgerät einem der in 3 gezeigten Feldgeräte 125-132 und 140-146, einem der physischen Knoten 40a, 40b, 40c oder PNa-PNk von 1 und/oder einem der in 4 gezeigten physischen Knoten 212a-212n, 215a-215n, 218a-218n oder 220a-220n ähnlich sein. Der I/O-Switch kann als Ausführungsform des I/O-Switches 25 von 1 und/oder zum Beispiel eines der I/O-Switches 202-210 von 4 implementiert sein. Der virtuelle Knoten kann einem der in 1 gezeigten virtuellen Knoten 30a, 30b, 30c, ..., 30p, der in 2 gezeigten virtuellen Knoten 52a, 52b und/oder zum Beispiel der in 4 gezeigten virtuellen Knoten 212a-212n, 215a-215n, 218a-218n oder 220a-220n ähnlich sein.
  • In jedem Fall ist in Bezug auf den Block 402 des Verfahrens 400 das Feldgerät, das über den I/O-Switch kommunikativ mit dem virtuellen Knoten verbunden ist, in einer physischen Umgebung der industriellen Prozessanlage angeordnet und führt während der Laufzeitoperationen der industriellen Prozessanlage eine physische Funktion zur Steuerung eines industriellen Prozesses zum Generieren physischer Produkte aus Roh- oder anderen Typen von Vormaterialien, wie Herstellung, Materialumwandlung usw., aus. Beispielsweise kann das Feldgerät selbst ein Ventil oder ein anderer Gerätetyp sein, kann ein anderes Gerät wie ein Ventil oder einen anderen Gerätetyp betätigen, kann eine Temperatur erhöhen oder verringern, kann eine Messung durchführen, kann einen Zustand erfassen usw.
  • In Bezug auf 6 ist der I/O-Switch ein Abonnent von ersten Daten, die vom Feldgerät generiert und veröffentlicht wurden, und der I/O-Switch ist ein Veröffentlicher von zweiten Daten, die Angaben zu den ersten vom Feldgerät generierten Daten machen. Beispielsweise kann der I/O-Switch über ein Abonnement erste Daten empfangen, die vom Feldgerät generiert werden, z. B. während das Feldgerät arbeitet, um den industriellen Prozess während der Laufzeitoperationen der Anlage zu steuern, und der I/O-Switch kann die empfangenen ersten Daten als zweite Daten veröffentlichen. Im Allgemeinen kann der I/O-Switch verschiedene Daten verschiedener Geräten veröffentlichen und abonnieren, mit denen er über eine oder mehrere Veröffentlichungs-/Abonnementschichten oder -Mechanismen kommunikativ verbunden ist, wie die Pub-/Sub-Schichten 32a-32p, 35, 38 und 42a-42c in den 1 und 5 und/oder die Pub-/Sub-Schichten 55a, 55b von 2.
  • Zusätzlich zu 6 ist der virtuelle Knoten in einer virtuellen Umgebung der industriellen Prozessanlage angeordnet, und ist ein Abonnent der zweiten Daten, die dem Feldgerät entsprechen und vom I/O-Switch veröffentlicht werden. Beispielsweise kann der virtuelle Knoten verschiedene Daten verschiedener Geräten abonnieren, mit denen er kommunikativ verbunden ist, und kann die verschiedenen Daten, die der virtuelle Knoten abonniert hat (oder Angaben dazu) über die Veröffentlichungs-/Abonnementschicht oder den -Mechanismus des virtuellen Knotens empfangen, wie eine der Pub-/Sub-Schichten 32a-32p von 1 oder eine der Pub-/Sub-Schichten 55a, 55b von 2. In ähnlicher Weise kann der virtuelle Knoten Daten für den Verbrauch anderer Knoten über seine jeweilige Pub-/Sub-Schicht veröffentlichen.
  • In einigen Anordnungen kann der virtuelle Knoten ein virtueller Laufzeitknoten sein, wie beispielsweise eine virtuelle Steuerung, eine virtuelle Sicherheitssteuerung oder ein Sicherheits-Logik-Solver, eine I/O-Karte oder ein Rangiersystem oder ein anderer Knotentyp, der eine virtualisierte Instanz eines physischen Knotens ist, der in der physischen Umgebung der Industrieanlage verwendet werden kann, wie z. B. vorstehend beschrieben. In einigen Implementierungen kann ein einzelner virtueller Laufzeitknoten eine Gruppe von Knoten virtualisieren. Beispielsweise kann sich ein einzelner virtueller Laufzeitknoten wie ein physischer I/O-Rangierschrank und der darin enthaltene Satz von physischen I/O-Karten verhalten.
  • In einigen Anordnungen kann der virtuelle Knoten ein simulierter Knoten sein, der eine oder mehrere integrale physische Hardwarekomponenten der physischen Umgebung der Prozessanlage und optional Verhaltensweisen und/oder Operationen davon simuliert, wobei es sich beispielsweise um Subsysteme, Geräte, Komponenten von Geräten, Netzwerkverbindungen und/oder Komponenten usw., bis auf die Granularität der MAC-Adressebenen, falls gewünscht, handeln kann.
  • In jedem Fall kann der virtuelle Knoten (unabhängig davon, ob der virtuelle Knoten ein virtueller Laufzeitknoten oder ein simulierter Knoten ist) ein entsprechendes Komponentenverhaltensmodul (CBM) enthalten, das einen Satz von Anweisungen einschließen kann, die in einem oder mehreren Speichern der virtualisierten Knoten gespeichert sind und von einem oder mehreren Prozessoren des virtualisierten Knotens ausgeführt werden. Das CBM, das sich auf dem virtualisierten Knoten befindet und auf diesem ausgeführt wird, kann zumindest einige Verhaltensweisen und/oder Operationen des virtualisierten Knotens steuern, z. B. auf eine Weise wie vorstehend beschrieben, zumindest durch Arbeiten mit I/O-Daten. Beispielsweise kann das CBM des virtualisierten Knotens als Steuermodul oder -Routine, Sicherheitslogikmodul oder -Routine, ausführbares Objekt usw. implementiert werden. Im Allgemeinen kann eine Instanz des CBM des virtualisierten Knotens von einem physischen Knoten der Prozessanlage verwendet werden. Das heißt, es können verschiedene Instanzen eines bestimmten CBM heruntergeladen oder auf andere Weise einem virtuellen Knoten und einem physischen Knoten bereitgestellt werden, und die heruntergeladenen Instanzen des bestimmten CBM können ohne Kenntnis oder agnostisch sein darüber, ob sie in einem virtuellen Knoten oder in einem physischen Knoten ausgeführt werden. Insbesondere in Bezug auf den virtuellen Knoten des Verfahrens 400 veröffentlicht der virtuelle Knoten Daten, die von seinem CBM über seine Pub-/Sub-Schicht generiert wurden, und der virtuelle Knoten empfängt veröffentlichte Daten, die er über seine Pub-/Sub-Schicht abonniert hat, und stellt die empfangenen Daten an sein CBM bereit, so dass das CBM mit den empfangenen Daten arbeiten kann.
  • Wie in 6 gezeigt, beinhaltet das Verfahren 400 während der Laufzeitoperationen der industriellen Prozessanlage das Empfangen der zweiten Daten, die dem Feldgerät entsprechen, das durch den I/O-Switch veröffentlicht wurde (Block 405), durch den virtuellen Knoten. Beispielsweise kann der virtuelle Knoten über seine Pub-/Sub-Schicht die zweiten vom I/O-Switch veröffentlichten Daten empfangen, wobei die veröffentlichten zweiten Daten auf den ersten Daten basieren, die vom Feldgerät generiert und abonniert und vom I/O-Switch empfangen werden.
  • In einem Block 408 beinhaltet das Verfahren 400 das Arbeiten mit den zweiten Daten während der Laufzeitoperationen der industriellen Prozessanlage und durch Verwenden eines Komponentenverhaltensmoduls des virtuellen Knotens, wodurch ein Steuersignal basierend auf den zweiten Daten generiert wird. Beispielsweise kann das CBM, das sich auf dem virtuellen Knoten befindet und auf diesem ausgeführt wird, mit den empfangenen zweiten Daten arbeiten (z. B. kann es die empfangenen zweiten Daten als Eingabe(n) verwenden) und kann ein entsprechendes Steuersignal basierend auf den Operationen oder der Ausführung des CBM generieren. Das CBM des virtuellen Knotens kann eine Steuerroutine oder ein Steuermodul sein; eine Sicherheitslogikroutine, ein Modul oder ein Solver; oder zum Beispiel ein anderer Typ von Objekt, Routine, Modul oder ausführbarer Datei.
  • In einem Block 410 beinhaltet das Verfahren 400 während der Laufzeitoperationen der industriellen Prozessanlage das Bewirken einer Angabe, dass das Steuersignal an einen anderen Knoten des Prozessleitsystems, z. B. einen Empfängerknoten, übertragen werden soll, wodurch ein Verhalten des anderen oder Empfängerknotens (Block 410) verändert wird. Der andere oder Empfängerknoten kann ein anderer virtueller Knoten (wie ein anderer virtueller Laufzeitknoten oder ein simulierter Knoten) sein, oder der Empfängerknoten kann ein physischer Knoten der industriellen Prozessanlage sein.
  • In einer Ausführungsform des Blocks 410 beinhaltet das Bewirken der Angabe, dass das Steuersignal an den Empfängerknoten zu übertragen ist, das direkte Übertragen der Angabe des Steuersignals an den Empfängerknoten durch den virtuellen Knoten.
  • In einer anderen Ausführungsform des Blocks 410 beinhaltet das Bewirken der Angabe, dass das Steuersignal an den Empfängerknoten zu übertragen ist, das Veröffentlichen von dritten Daten, die Angaben zum Steuersignal machen, durch den virtuellen Knoten, z. B. über die Pub-/Sub-Schicht des virtuellen Knotens. In dieser Ausführungsform kann der I/O-Switch ein Abonnent der dritten Daten sein, die vom virtuellen Knoten veröffentlicht werden, und der I/O-Switch kann mit den dritten Daten arbeiten, um vierte Daten zu generieren und zu veröffentlichen, die Angaben zu den empfangenen dritten Daten machen, z. B. über die Pub-/Sub-Schicht des I/O-Switches. In einer beispielhaften Implementierung dieser Ausführungsform kann der Empfängerknoten ein Abonnent der vierten Daten sein, die vom I/O-Switch veröffentlicht werden, und als solches kann der Empfängerknoten die veröffentlichten vierten Daten über seine Pub-/Sub-Schicht empfangen, wobei die vierten Daten Angaben zum Steuersignal machen.
  • In einer anderen beispielhaften Implementierung dieser Ausführungsform kann ein intervenierender Knoten kommunikativ zwischen dem I/O-Switch und dem Empfängerknoten angeordnet sein. In dieser beispielhaften Implementierung kann der intervenierende Knoten ein Abonnent der vierten Daten sein, die vom I/O-Switch veröffentlicht werden, und als solches kann der intervenierende Knoten die veröffentlichten vierten Daten über seine Pub-/Sub-Schicht empfangen. Der intervenierende Knoten kann die empfangenen vierten Daten in ein Kommunikationsformat konvertieren oder übersetzen, das dem Empfängerknoten nativ oder anderweitig bekannt ist, und kann die konvertierten oder übersetzten vierten Daten über eine oder mehrere geeignete Kommunikationsverbindungen und/oder Netzwerke an den Empfängerknoten übertragen und/oder veröffentlichen, so dass der Empfängerknoten eine Angabe des Steuersignals in seinem nativen oder bekannten Kommunikationsformat empfängt. Beispielsweise kann der intervenierende Knoten einem der in 1 gezeigten Knoten 40a-40c oder 28 ähnlich sein, oder kann ein anderer I/O-Switch sein, wie beispielsweise einer der I/O-Switches 202-210 von 4. In einem Anordnungsbeispiel kann der intervenierende Knoten ein I/O-Hub sein, der kommunikativ zwischen dem I/O-Switch und einer Mehrzahl von physischen Geräten angeordnet ist, die in der physischen Umgebung der Prozessanlage angeordnet sind. Die Mehrzahl von physischen Geräten kann das Feldgerät einschließen oder nicht, das die ersten Daten generiert hat, z. B. wie vorstehend in Bezug auf Block 402 beschrieben. In diesem Anordnungsbeispiel kann der I/O-Hub ein Veröffentlicher von Daten sein, die von einem der Mehrzahl von physischen Geräten generiert werden, mit denen er kommunikativ verbunden ist, und kann ein Abonnent von Daten sein, die von einem der Mehrzahl von physischen Geräten verwendet werden und die von einem anderen virtuellen Gerät, dem I/O-Switch oder einem anderen Veröffentlichungsknoten unter Verwendung des MPDSC 10 veröffentlicht werden.
  • Ferner kann in Bezug auf den Block 410, ob der Empfängerknoten die vierten Daten empfängt, die vom I/O-Switch direkt über ein Abonnement oder über einen intervenierenden Knoten veröffentlicht wurden, der Inhalt der vierten Daten (der, wie zuvor beschrieben, Angaben zu dem vom CBM des virtuellen Knotens generierte Steuersignal macht), der vom Empfängerknoten empfangen wird, dazu führen, dass der Empfängerknoten sein Verhalten ändert. Wie zuvor erläutert, kann der Empfängerknoten ein anderer virtueller Knoten (der ein virtueller Laufzeitknoten oder ein simulierter Knoten sein kann) der industriellen Prozessanlage sein, oder der Empfängerknoten kann ein physischer Knoten der industriellen Prozessanlage sein. Als solches kann der Inhalt der vierten Daten, die vom Empfängerknoten (über den I/O-Switch oder über den intervenierenden Knoten) empfangen werden, von dem CBM des Empfängerknotens bearbeitet werden, wodurch eine Änderung des Verhaltens und/oder der Operationen, z. B. des Laufzeitverhaltens und/oder der Laufzeitoperationen des Empfängerknotens, bewirkt wird. Beispielsweise kann der Inhalt der empfangenen vierten Daten Angaben zu einem vom virtuellen Knoten generierten Steuersignal machen, und das CBM des Empfängerknotens kann das Steuersignal bearbeiten und sein Verhalten und/oder seine Operationen entsprechend modifizieren, z. B. während die industrielle Prozessanlage zur Laufzeit arbeitet, um den industriellen Prozess zu steuern. In einigen Fällen kann abhängig von der Rolle des Empfängerknotens mindestens ein Anteil der Steuerung des industriellen Prozesses innerhalb der Prozessanlage basierend auf dem Inhalt der vom Empfängerknoten empfangenen Daten und entsprechend den vierten veröffentlichten Daten durch den I/O-Switch geändert werden.
  • In einer Ausführungsform des Verfahrens 400 (nicht in 6 dargestellt) ist der in Bezug auf den Block 402 beschriebene virtuelle Knoten ein virtueller Laufzeitknoten, und das Verfahren 400 beinhaltet das kommunikative Verbinden eines oder mehrerer simulierter Knoten mit dem I/O-Switch, bei dem der eine oder die mehreren simulierten Knoten virtuelle Knoten sind, die in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind. Der eine oder die mehreren Simulationsknoten und mindestens ein Anteil des I/O-Switches können beispielsweise in einem Simulationssystem enthalten sein, wobei das Simulationssystem das Laufzeitverhalten und/oder die Laufzeitoperationen einer oder mehrerer virtueller und/oder physischer Komponenten und/oder Knoten der industriellen Prozessanlage simuliert. In einigen Szenarien können der eine oder die mehreren simulierten Knoten das Laufzeitverhalten der jeweiligen virtuellen und/oder physischen Komponenten und/oder Knoten in Verbindung mit den Laufzeitoperationen einer oder mehrerer virtueller Laufzeit- und/oder physischer Knoten der industriellen Prozessanlage simulieren, z. B. während der eine oder die mehreren tatsächlichen virtuellen Laufzeit- und/oder physischen Knoten zur Laufzeit arbeiten, während die industrielle Prozessanlage den Prozess steuert.
  • Um die Simulation des Laufzeitverhaltens bereitzustellen, kann jeder der einen oder mehreren Simulationsknoten über einen oder mehrere Prozessoren eine entsprechende CBM ausführen, die in einem oder mehreren Speichern des jeweiligen Simulationsknotens gespeichert ist. Wie vorstehend erwähnt, sind die jeweiligen CBMs der simulierten Knoten agnostisch oder in Unkenntnis darüber, ob sie auf einem simulierten Knoten, auf einem virtuellen Laufzeitknoten oder auf einem physischen Knoten ausgeführt werden, und daher können Instanzen der jeweiligen CBMs in verschiedenen jeweiligen physischen und/oder virtuellen Laufzeitknoten, Komponenten und/oder Geräten innerhalb der physischen Umgebung der Prozessanlage bereitgestellt werden. Im Allgemeinen kann ein simulierter Knoten jedes physische Gerät oder jede Komponente davon simulieren, das/die in der industriellen Prozessanlage eingesetzt und/oder angeordnet werden kann, einschließlich, aber nicht beschränkt beispielsweise auf: eine Prozesssteuerung; eine Sicherheitssteuerung; einen Sicherheits-Logik-Solver; einen I/O-Knoten, eine Karte oder ein Gerät; ein drahtloses Gerät; ein Ethernet-Gerät; einen Bedienerarbeitsplatz; ein Benutzeroberflächengerät; ein Werkzeug; ein Gateway; einen elektronischen Rangierschrank; eine Netzwerkverbindung; eine MAC-Adresse; einen anderen Typ von physischem Gerät oder bestimmter physischer Komponente, das/die in der physischen Umgebung der industriellen Prozessanlage eingesetzt und/oder angeordnet werden kann; ein Modul, eine Routine, eine Funktion oder ein Verhalten; eine MAC-Adresse; eine Hardware-Unterkomponente eines bestimmten physischen Geräts oder einer bestimmten physischen Komponente; oder einen anderen Anteil eines bestimmten physischen Geräts oder einer bestimmten physischen Komponente, der in der physischen Umgebung der industriellen Prozessanlage eingesetzt und/oder angeordnet werden kann.
  • In einigen Ausführungsformen beinhaltet das Verfahren 400 das Ausführen eines Simulationslaufs, der einen bestimmten simulierten Knoten des einen oder der mehreren simulierten Knoten des Systems oder des MPDSC 10 enthält (nicht in 6 dargestellt). Insbesondere beinhaltet das Ausführen des Simulationslaufs das Ausführen des jeweiligen CBM des bestimmten simulierten Knotens. Das jeweilige Komponentenverhaltensmodul des bestimmten simulierten Knotens kann ausgeführt werden, um dadurch Daten zu generieren; und die von dem bestimmten simulierten Knoten generierten Daten können an einen anderen Knoten des MPDSC 10 übertragen werden, z. B. einen Empfangsknoten der von dem bestimmten simulierten Knoten generierten Daten. Beispielsweise können die von dem bestimmten simulierten Knoten generierten Daten direkt von dem bestimmten simulierten Knoten an den Empfangsknoten übertragen werden. In einem anderen Beispiel können die von dem bestimmten simulierten Knoten generierten Daten über die Pub-/Sub-Schicht des bestimmten simulierten Knotens veröffentlicht werden, und der Empfangsknoten, der I/O-Switch oder ein intervenierender Knoten, der kommunikativ zwischen dem I/O-Switch und dem Empfangsknoten angeordnet ist, kann ein Abonnent der vom simulierten Knoten veröffentlichten, generierten Daten sein. Der Empfangsknoten kann den Inhalt der generierten Daten über den Abonnenten der generierten Daten, die von dem simulierten Knoten veröffentlicht wurden, empfangen, wie auf eine vorstehend beschriebene Weise. Der Empfangsknoten kann ein anderer virtueller Knoten sein (z. B. ein anderer simulierter Knoten oder ein anderer virtueller Laufzeitknoten), oder der Empfangsknoten kann ein physischer Knoten sein. In einigen Implementierungen kann mindestens einer der simulierten Knoten oder der Empfangsknoten in Verbindung mit anderen virtuellen und/oder physischen Laufzeitknoten während der Laufzeitoperationen der industriellen Prozessanlage arbeiten.
  • In einigen Szenarien kann das Verfahren 400 nach dem Ausführen des Simulationslaufs, an dem der bestimmte Simulationsknoten beteiligt ist, das Herunterladen oder anderweitige Bereitstellen einer entsprechenden Instanz des CBM des bestimmten Simulationsknotens an einen virtuellen Laufzeitknoten oder an einen physischen Knoten der industriellen Prozessanlage einschließen. Beispielsweise kann der Simulationslauf ein Test sein oder auf andere Weise das gewünschte Verhalten des CBM in dem bestimmten simulierten Knoten beweisen, und nachdem sich das simulierte Verhalten als zufriedenstellend erwiesen hat und/oder genehmigt wurde, kann die Instanz des CBM (ob virtuell oder physisch) in einen Laufzeitknoten heruntergeladen werden. Daher kann das simulierte Verhalten über MPDSC 10 leicht getestet und bewiesen werden (in einigen Fällen unter Laufzeitbedingungen) und nach der Genehmigung einfach heruntergeladen oder zur Ausführung in jeweiligen virtuellen und/oder physischen Laufzeitknoten bereitgestellt werden.
  • Nicht alle Simulationsläufe müssen jedoch in Echtzeit oder unter Laufzeitbedingungen ausgeführt werden. Zu diesem Zweck kann das Simulationssystem einen Simulationsverwaltungsknoten und einen Simulatorzugriffsmechanismus bereitstellen, über den Simulationsläufe nach Wunsch unter verschiedenen Bedingungen administriert werden können. Beispielsweise kann der Simulationsverwaltungsknoten unter Verwendung einer Ausführungsform des VMN 300 von 5 implementiert werden, und der Simulatorzugriffsmechanismus kann unter Verwendung einer Anwendungsprogrammierschnittstelle (API), einer Funktion, eines Dienstes und/oder eines anderen Typs von Mechanismus implementiert werden, der für Benutzer und/oder andere Anwendungen, wie den Simulator API 310 von 5, zugänglich und bereitgestellt ist. Das Verfahren 400 kann das Verwenden des Simulatorzugriffsmechanismus einschließen, um beispielsweise einen oder mehrere simulierte Werte bereitzustellen und/oder zu empfangen, die während der Ausführung des Simulationslaufs einschließlich des bestimmten simulierten Knotens verwendet werden. Zusätzlich oder alternativ kann das Verfahren 400 das Verwenden des Simulatorzugriffsmechanismus einschließen, um einen oder mehrere Simulationsausführungs- und/oder administrative Befehle zu bearbeiten, z. B. wie sie von einem Benutzer und/oder von anderen Anwendungen (wie z. B. Anwendungen der OT-Schicht, die dem Unternehmen zugeordnet sind, das dem industriellen Prozessleitsystem und/oder der Anlage zugeordnet ist oder sie bereitstellt, und/oder Anwendungen von Drittanbietern) bereitgestellt werden. Beispielsweise kann das Verfahren 400 einschließen: Verwenden des Simulatorzugriffsmechanismus zum Ausführen des Simulationslaufs in einem Laufzeittempo; Beschleunigen des Simulationslaufs; um schneller als mit dem Laufzeittempo ausgeführt zu werden; Verlangsamen des Simulationslaufs; um langsamer als mit dem Laufzeittempo ausgeführt zu werden; Festlegen eines simulierten Wertes des Simulationslaufs; Festlegen einer Ausgangsbedingung des Simulationslaufs; Anhalten des Simulationslaufs; Festlegen einer Zwischenbedingung für den Simulationslauf; Ändern eines Tempos für die Ausführung der Simulation; Ändern eines simulierten Wertes; der dem Simulationslauf zugeordnet ist; Sichern oder Speichern von Daten; die mindestens einem Anteil des Simulationslaufs zugeordnet sind; Abrufen von mindestens einem Anteil eines gesicherten oder gespeicherten Simulationslaufs; Sichern oder Speichern einer Konfiguration des Simulationslaufs; Abrufen einer gesicherten oder gespeicherten Konfiguration des Simulationslaufs; und/oder dergleichen, wie auf eine vorstehend beschriebene Weise.
  • In einer Ausführungsform kann der Simulatorzugriffsmechanismus einen oder mehrere Zustände beibehalten, die einem Simulationslauf zugeordnet sind. Der eine oder die mehreren Zustände können jeweils verschiedenen einem oder mehreren Anteilen des Simulationslaufs und/oder damit verbundenen Komponenten und/oder Geräten zugeordnet sein. Beispielsweise können der eine oder die mehreren Zustände einem Zustand einer virtuellen Komponente, einem Zustand einer physischen Komponente, einem Zustand einer simulierten Komponente, einem Zustand eines virtuellen Geräts, einem Zustand eines physischen Geräts, einem Zustand eines simulierten Geräts, einem Zustand eines virtuellen Moduls, einem Zustand eines physischen Moduls, einem Zustand eines simulierten Moduls, einem Zustand eines Prozesses, der durch den Simulationslauf zumindest teilweise simuliert wird, einem Zustand des Simulationslaufs und/oder einer anderen Art von Zustand, die mit dem Simulationslauf verbunden ist, entsprechen, wie auf eine vorstehend beschriebene Weise.
  • In Anbetracht des vorstehend Aufgeführten bieten die neuartige Mehrzweckplattform für dynamische Simulation und die Laufzeitsteuerungsplattform 10 zahlreiche Vorteile gegenüber bekannten Prozessleitsystemen. Da beispielsweise die MPDSC-Plattform 10 sowohl die Simulation als auch die Laufzeitsteuerung über virtuelle Komponenten unterstützt, kann das Testen von Änderungen (z. B. Upgrades, Patches usw.) in der virtuellen Umgebung 12 über eine simulierte Komponente durchgeführt werden, und nach zufriedenstellendem Auschecken kann die simulierte Komponente leicht als virtuelle Komponente der Prozessanlage 100 aktiviert werden (z. B. „Load, Evaluate, Go“ (Laden, Auswerten, Loslegen), stoßfreie oder warme Umschaltungen usw.). Dadurch kann die Umschaltung von simulierten Komponenten auf Laufzeitkomponenten einfacher durchgeführt werden und Ausfallzeiten aufgrund von Upgrades, Patches und geplanter Wartung können reduziert werden. Darüber hinaus wird die Menge an Ressourcen, die verwendet werden, um virtualisierte Ersatzteile verschiedener Komponenten bereitzustellen und die virtualisierten Ersatzteile während Ausfall- oder Fehlerszenarien online zu schalten, erheblich reduziert.
  • Ferner ermöglicht die Bereitstellung von virtuellen Laufzeitkomponenten durch die MPDS-Plattform 10 die Unabhängigkeit zwischen Hardware und Software innerhalb der Anlage 100. Beispielsweise kann eine Steuerungssoftware, die zur Laufzeit des Prozessleitsystems 100 verwendet wird, in virtuellen Laufzeitsteuerungen aktualisiert werden, ohne dass eine physische Steuerungshardware aktualisiert oder geändert werden muss. Auf ähnliche Weise ermöglicht die MPDS-Plattform 10 aufgrund der Hardware-/Softwareunabhängigkeit, dass die Hardware der Prozessanlage 100 unabhängig von Software-Upgrades aktualisiert wird.
  • Die Bereitstellung von virtuellen Laufzeitkomponenten und deren Administration und/oder Verwaltung (z. B. über den VMS 300 der MPDSC-Plattform 10) ermöglicht jedoch auch eine einfache und kostengünstigere Skalierbarkeit des Systems, da zusätzliche virtuelle Komponenten problemlos innerhalb der virtuellen Umgebung 12 implementiert werden können, ohne dass verschiedene physische Hardwarekomponenten und erforderliche Schränke, Verdrahtungen usw. bezahlt, installiert, getestet, in Betrieb genommen und geprüft werden müssen. In der Tat können, wenn zusätzliche virtuelle Komponenten zur Unterstützung des Systems 100 benötigt werden, virtuelle Komponenten nach Bedarf erstellt werden bis zu den Verarbeitungs- und/oder Speichergrenzen der physischen Computergeräte und/oder Hardware, auf denen die virtuelle Umgebung 12 implementiert ist, wonach zusätzliche physische Computergeräte und/oder Hardware einfach hinzugefügt werden können.
  • Die von der MPDS-Plattform 10 bereitgestellte virtuelle Umgebung 12 ermöglicht die Erstellung digitaler Zwillinge verschiedener Komponenten und/oder die virtuelle Simulation der gesamten Prozessanlage 100, z. B. für Tests, Ersatzteile, Upgrades, Patches, geplante Wartungsarbeiten und/oder andere Zwecke. Digitale Zwillinge (z. B. bestimmter Komponenten und der gesamten Prozessanlage 100) können im Gleichschritt mit Aktualisierungen ihrer jeweiligen bestimmten physischen Komponente(n) aktualisiert werden. Das heißt, Statusinformationen können über die MPDSC-Plattform 10 von physischem(n) Knoten zu virtuellem(n) Knoten übertragen werden.
  • In der Tat bietet die MPDSC-Plattform 10 ein verbessertes Online-Testen von Änderungen und/oder verschiedenen Szenarien (z. B. „Was-wäre-wenn“-Szenarien) und in einigen Situationen in Verbindung mit virtuellen und/oder physischen Laufzeitkomponenten des Prozessanlage 100. Aufgrund der Architektur und Verwendung der gemeinsamen MPDS-Plattform 10 (und insbesondere der virtuellen Umgebung 12 der MPDS-Plattform 10) für Simulations- und Laufzeitsteuerungszwecke kann die Off-Simulation ohne Konfigurationsänderungen problemlos durchgeführt werden.
  • Da weiterhin die MPDS-Plattform 10 unberücksichtigt lässt, dass die I/O der Prozessanlage 100 spezifisch direkt mit einer bestimmten Hardware verknüpft sind, ist die I/O-Konfiguration innerhalb der Anlage 100 flexibler und kann nicht nur während der Laufzeit, sondern auch während Upgrades, Wartungen, Ausfällen und dergleichen leicht geändert und adaptiert werden. Bezeichnenderweise sind Kommunikationsverbindungen zwischen I/O-Geräten und anderen Komponenten (z. B. CIOCs und Steuerungen) nicht mehr durch physische Ports beschränkt, die auf physischen I/O-Geräten verfügbar sind. Da I/O innerhalb der MPDS-Plattform 10 unberücksichtigt gelassen werden, ist eine beliebige Anzahl von Kommunikationsverbindungen zwischen einem virtuellen I/O-Gerät und anderen Komponenten logisch möglich, bis zu den Verarbeitungs- und/oder Speichergrenzen der physischen Computergeräte und/oder Hardware, auf denen die virtuelle Umgebung 12 implementiert ist, wonach zusätzliche physische Computergeräte und/oder Hardware einfach dazugefügt werden können. In ähnlicher Weise können aufgrund der Abstraktion von I/O innerhalb der MPDS-Plattform 10 und Steuermodule und/oder andere CBMs 58 jedem virtuellen Hostgerät oder jeder virtuellen Hostkomponente zugewiesen werden, ohne dass der I/O-Standort und/oder das Laden des Hostgeräts oder der - Komponente berücksichtigt werden müssen, wie dies bei Verwendung von physischen Hostgeräten oder -Komponenten erforderlich ist. Das heißt, wie zuvor erläutert, können virtuelle Komponenten (ob zur Simulation oder zur Laufzeitsteuerung verwendet) unter Verwendung von I/O von physischen Komponenten oder von anderen virtuellen Komponenten betrieben werden. Als solches ist die MPDS-Plattform 10 in der Lage, Redundanz, Wiederholungsversuche und andere Mechanismen, die gegenwärtig an bestimmte Implementierungen innerhalb derzeit bekannter Techniken gebunden sind, unberücksichtigt zu lassen (z. B. unter Verwendung des I/O-Switches 25), so dass die Abstraktionen übergreifend für mehrere unterschiedliche Typen von Anwendungen, Szenarien und Implementierungen verwendet werden können , z. B. mit ausgewählter Anpassung und Spezialisierung verschiedener Abstraktionen für bestimmte Implementierungen und/oder Anwendungen. Folglich kann die MPDS-Plattform 10 viel mehr Anzahlen und Typen von I/O-Systemen (im Vergleich zu derzeit bekannten Techniken) auf konsistente und leicht skalierbare Weise unterstützen.
  • Wenn sie in Software implementiert sind, können alle der hierin beschriebenen Anwendungen, Dienste, virtuellen Geräte, vertikalen Maschinen, virtuellen Einheiten usw. in jedem materiellen, nichtflüchtigen computerlesbaren Speicher, wie z. B. auf einer Magnetplatte, einer Laserscheibe, einer Festkörper-Speichervorrichtung, einer molekularen Speichervorrichtung oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. gespeichert werden. Obwohl die hierin offenbarten Beispiel-Systeme so offenbart werden, dass sie neben anderen Komponenten auf Hardware ausgeführte Software und/oder Firmware enthalten, sei darauf hingewiesen, dass solche Systeme rein beispielhaft sind und nicht als einschränkend angesehen werden sollten. Zum Beispiel wird in Betracht gezogen, dass irgendeine oder alle dieser Hardware-, Software- und Firmware-Komponenten ausschließlich als Hardware, ausschließlich als Software oder in irgendeiner Kombination von Hardware und Software ausgeführt werden können. Dementsprechend werden die hier beschriebenen Systembeispiele zwar als in Software implementiert beschrieben, die auf einem Prozessor eines oder mehrerer Computergeräte ausgeführt wird, aber Personen mit durchschnittlichen Fachkenntnissen werden leicht verstehen, 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 einschränken sollen, ist es für Personen mit durchschnittlichen Fachkenntnissen offensichtlich, dass Änderungen, Hinzufügungen oder Streichungen zu/von den offenbarten Ausführungsformen möglich sind, ohne vom Geist und Umfang der Erfindung abzuweichen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62/859508 [0001]
    • US 7684875 [0047]
    • US 8332567 [0047]
    • US 8762618 [0047]
    • US 8977851 [0047]
    • US 9083548 [0047]
    • US 9411769 [0047]
    • US 9495313 [0047]
    • US 9946240 [0047]

Claims (33)

  1. System einer industriellen Prozessanlage, wobei das System umfasst: ein Prozessleitsystem, einschließlich: eines Feldgeräts, das in einer physischen Umgebung der industriellen Prozessanlage angeordnet ist, wobei das Feldgerät eine physische Funktion durchführt; eines I/O-Switches, der kommunikativ zwischen dem Feldgerät und einem virtuellen Knoten angeordnet ist, wobei der I/O-Switch ein Abonnent der ersten Daten ist, die vom Feldgerät generiert und veröffentlicht werden, und der I/O-Switch ein Veröffentlicher von zweiten Daten ist, die Angaben zu den ersten vom Feldgerät generierten Daten machen; und des virtuellen Knotens, wobei der virtuelle Knoten ein Abonnent der zweiten Daten ist, die dem Feldgerät entsprechen und von dem I/O-Switch veröffentlicht werden, wobei der virtuelle Knoten ein Komponentenverhaltensmodul enthält, das mit den zweiten Daten arbeitet, die dem Feldgerät entsprechen, um dadurch ein Steuersignal zum Ändern eines Verhaltens eines anderen Knotens des Prozessleitsystems und des virtuellen Knotens zu generieren, der in einer virtuellen Umgebung der industriellen Prozessanlage angeordnet ist, des Feldgeräts, des virtuellen Knotens und des anderen Knotens, die während der Laufzeitoperationen der industriellen Prozessanlage zusammenarbeiten, um einen industriellen Prozess zu steuern.
  2. System nach Anspruch 1, wobei der virtuelle Knoten ein Veröffentlicher von dritten Daten ist, die Angaben zum Steuersignal machen, und eine Angabe der dritten Daten durch den anderen Knoten empfangen wird, insbesondere wobei: der I/O-Switch ein Abonnent der dritten Daten ist, die Angaben zu dem vom virtuellen Knoten generierten Steuersignal machen; der I/O-Switch ein Veröffentlicher von vierten Daten ist, die Angaben zu den dritten Daten machen, die dem vom virtuellen Knoten generierten Steuersignal entsprechen, und der andere Knoten oder ein intervenierender Knoten, der kommunikativ zwischen dem I/O-Switch und dem anderen Knoten angeordnet ist, ein Abonnent der vierten Daten ist; mehr insbesondere wobei: der intervenierende Knoten der Abonnent der vierten Daten ist, der intervenierende Knoten ein I/O-Hub-Gerät ist, das kommunikativ zwischen dem I/O-Switch und einer Mehrzahl von physischen Geräten angeordnet ist, die in einer physischen Umgebung der industriellen Prozessanlage enthalten sind, wobei die Mehrzahl von physischen Geräten den anderen Knoten enthalten; und das I/O-Hub-Gerät ein Veröffentlicher von Daten ist, die jeweils von jedem physischen Gerät aus einer Mehrzahl von physischen Geräten generiert werden.
  3. System nach einem der vorhergehenden Ansprüche, wobei der virtuelle Knoten ein erster virtueller Knoten ist, und der andere Knoten ein zweiter virtueller Knoten ist, und/oder wobei der andere Knoten ein physischer Knoten ist, der in der industriellen Prozessanlage angeordnet ist; und/oder wobei der virtuelle Knoten eines von einer virtuellen Prozesssteuerung oder einer virtuellen Sicherheitssteuerung der industriellen Prozessanlage ist und das Komponentenverhaltensmodul ein jeweiliges Steuermodul ist.
  4. System nach einem der vorhergehenden Ansprüche, wobei der virtuelle Knoten in einer Mehrzahl von virtuellen Knoten enthalten ist, die innerhalb einer virtuellen Umgebung der industriellen Prozessanlage angeordnet sind, wobei die Mehrzahl von virtuellen Knoten mindestens eines der folgenden enthält: eine virtuelle Prozesssteuerung, eine virtuelle Sicherheitssteuerung; einen virtuellen Sicherheits-Logik-Solver; eine virtuelle I/O-Karte, ein Gerät oder einen Knoten; ein virtuelles drahtloses Gerät; einem virtuellen Ethernet-Gerät; einem virtuellen Bedienerarbeitsplatz; ein virtuelles Benutzeroberflächengerät; ein virtuelles Werkzeug; einen virtuellen Gateway; ein/en virtuellen/s elektronischen/s Rangierschrank oder -System; oder eine Virtualisierung eines anderen Typs eines physischen Geräts oder einer physischen Komponente, die in einer physischen Umgebung der industriellen Prozessanlage angeordnet ist; und/oder wobei das in dem virtuellen Knoten enthaltene Komponentenverhaltensmodul in ein physisches Gerät herunterladbar ist, das durch den virtuellen Knoten dargestellt wird, und das in einer physischen Umgebung der industriellen Prozessanlage angeordnet ist.
  5. System nach einem der vorhergehenden Ansprüche, wobei: der virtuelle Knoten und das Feldgerät in einem ersten Regelkreis des Prozessleitsystems enthalten sind, das Prozessleitsystem eine Mehrzahl von Regelkreisen beinhaltet, die zur Steuerung des industriellen Prozesses während der Laufzeitoperationen der industriellen Prozessanlage arbeiten; jeder Regelkreis der Mehrzahl von Regelkreisen ein jeweiliges Feldgerät beinhaltet, das in der physischen Umgebung der industriellen Prozessanlage angeordnet ist, und mindestens ein anderes Prozesssteuerungsgerät, das in der virtuellen Umgebung der industriellen Prozessanlage angeordnet ist; und jeder Regelkreis der Mehrzahl von Regelkreise den I/O-Switch anstelle eines beliebigen physischen I/O-Geräts verwendet.
  6. System nach einem der vorhergehenden Ansprüche, ferner umfassend ein Edge-Gateway-System, das mit einer oder mehreren Anwendungen kommunikativ verbunden ist, wobei jede der einen oder mehreren Anwendungen jeweils ein Verbraucher jeweils mindestens eines Anteils von einem oder mehreren Typen von Daten ist, die von dem I/O-Switch veröffentlicht wurden, wobei das Edge-Gateway-System ein Abonnent des einen oder der mehreren Typen von Daten ist, die von dem I/O-Switch veröffentlicht wurden, und das Edge-Gateway-System einen oder mehrere Sicherheitsmechanismen enthält, die bei der Bereitstellung des einen oder der mehreren Typen von Daten zwischen dem I/O-Switch und der einen oder mehreren Anwendungen verwendet werden; und/oder ferner umfassend ein I/O-Hub-Gerät, das kommunikativ zwischen dem I/O-Switch und dem Feldgerät angeordnet ist; und wobei das I/O-Hub-Gerät ein Veröffentlicher der ersten vom Feldgerät generierten Daten ist.
  7. System nach einem der vorhergehenden Ansprüche, wobei: der virtuelle Knoten, der während der Laufzeitoperationen der industriellen Prozessanlage arbeitet, um den industriellen Prozess zu steuern, ein virtueller Laufzeitknoten ist, der in einer Mehrzahl von virtuellen Knoten enthalten ist, die in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind; die Mehrzahl von virtuellen Knoten einen oder mehrere simulierte Knoten beinhaltet, wobei der eine oder die mehreren simulierten Knoten den virtuellen Laufzeitknoten ausschließen; und das System ferner ein Simulationssystem beinhaltet, wobei das Simulationssystem den I/O-Switch und den einen oder die mehreren simulierten Knoten einschließt; insbesondere wobei jeder simulierte Knoten des einen oder der mehreren simulierten Knoten mindestens einen Anteil von jeweils einem oder mehreren physischen Geräten oder Komponenten simuliert, die in der physischen Umgebung der industriellen Prozessanlage einsetzbar sind, wobei der jeweils eine oder die mehreren physischen Geräte oder Komponenten mindestens eines einschließen von: einer Prozesssteuerung; einer Sicherheitssteuerung; einem Sicherheits-Logik-Solver; einem I/O-Knoten, einer Karte oder einem Gerät; einem drahtlosen Gerät; einem Ethernet-Gerät; einem Bedienerarbeitsplatz; einem Benutzeroberflächengerät; einem Werkzeug; einem Gateway; einem elektronischen Rangierschrank; einer Netzwerkverbindung; oder einer anderen Art von physischem Gerät oder physischer Komponente, die in der physischen Umgebung der industriellen Prozessanlage angeordnet sind; mehr insbesondere wobei mindestens der Anteil der jeweils ein oder mehreren physischen Geräte oder Komponenten, die durch den jeweiligen simulierten Knoten simuliert werden, einen Anteil eines bestimmten physischen Geräts oder einer bestimmten physischen Komponente enthält, und der Anteil des jeweiligen physischen Geräts oder der jeweiligen bestimmten physischen Komponente mindestens eines der folgenden enthält: ein Modul, eine Routine, eine Funktion oder ein Verhalten, eine MAC-Adresse oder eine Hardware-Unterkomponente des bestimmten physischen Geräts oder der bestimmten physischen Komponente.
  8. System nach einem der der vorherigen Ansprüche, insbesondere nach Anspruch 7, wobei ein einzelner einheitlicher simulierter Knoten eine Mehrzahl von physischen Geräten oder Komponenten simuliert, die für den gemeinsamen Betrieb während der Laufzeitoperationen der industriellen Prozessanlage eingesetzt werden können; und/oder wobei der eine oder die mehreren simulierten Knoten eine Mehrzahl von simulierten Knoten einschließen, die gemeinsam arbeiten, um eine Funktion oder ein Verhalten der Laufzeitoperationen der industriellen Prozessanlage zu simulieren.
  9. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 7 oder 8, wobei: ein Simulationslauf, der einen bestimmten simulierten Knoten des einen oder der mehreren simulierten Knoten enthält, die Kommunikation zwischen dem bestimmten simulierten Knoten und mindestens einem von einem anderen virtuellen Laufzeitknoten, der in der virtuellen Umgebung der industriellen Prozessanlage angeordnet ist, oder einem anderen physischen Knoten, der in der physischen Umgebung der industriellen Prozessanlage angeordnet ist, enthält; und der mindestens eine von dem anderen virtuellen Laufzeitknoten oder dem anderen physischen Knoten so konfiguriert ist, dass er während der Laufzeitoperationen der industriellen Prozessanlage arbeitet.
  10. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 7-9, wobei das Simulationssystem ferner einen Simulatorzugriffsmechanismus beinhaltet, über den eine Simulatoranwendung einen oder mehrere simulierte Werte bereitstellt und/oder empfängt, die in einem durch das Simulationssystem ausgeführten Simulationslauf verwendet werden; insbesondere wobei der Simulatorzugriffsmechanismus eine Anwenderprogrammierschnittstelle - Application Programming Interface (API) ist.
  11. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 10, wobei der Simulatorzugriffsmechanismus mit dem I/O-Switch verbunden ist, um den einen oder die mehreren simulierten Werte bereitzustellen und/oder zu empfangen; und/oder wobei der Simulatorzugriffsmechanismus dazu konfiguriert ist, über ein standardisiertes Daten- oder Kommunikationsprotokoll den einen oder die mehreren simulierten Werte unter Verwendung der jeweiligen Kennungen des einen oder der mehreren simulierten Knoten, die in einer Konfigurationsdatenbank der industriellen Prozessanlage gespeichert sind, zu kommunizieren.
  12. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 10 oder 11, wobei der Simulatorzugriffsmechanismus so konfiguriert ist, dass er mit einem oder mehreren Simulationsbefehlen arbeitet, um dadurch mindestens eines der folgenden zu bewirken: Ausführen des Simulationslaufs mit einem Laufzeittempo, Beschleunigen des Simulationslaufs, um ihn schneller als mit dem Laufzeittempo auszuführen, Verlangsamen des Simulationslaufs, um ihn langsamer als mit dem Laufzeittempo auszuführen, Festlegen eines simuliertes Werts des Simulationslaufs, Festlegen eines Ausgangszustands des Simulationslaufs, Anhalten des Simulationslaufs, Festlegen einer Zwischenbedingung für den Simulationslauf, Ändern des Tempos der Ausführung der Simulation, oder Ändern eines simulierten Werts, der dem Simulationslauf zugeordnet ist.
  13. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 10-12, wobei der Simulatorzugriffsmechanismus so konfiguriert ist, dass er mit einem oder mehreren Simulationsbefehlen arbeitet, um dadurch mindestens eines der folgenden zu bewirken: Sichern oder Speichern von Daten, die mindestens einem Anteil des Simulationslaufs zugeordnet sind, Abrufen mindestens eines gesicherten oder gespeicherten Anteils des Simulationslaufs, Sichern oder Speichern einer Konfiguration des Simulationslaufs oder Abrufen einer gesicherten oder gespeicherten Konfiguration des Simulationslaufs; und/oder wobei mindestens ein Simulationsbefehl, auf den der Simulatorzugriffsmechanismus reagiert, über eine Benutzeroberfläche bereitgestellt wird; und/oder wobei mindestens ein Simulationsbefehl, auf den der Simulatorzugriffsmechanismus reagiert, über eine Simulationsanwendung eines Drittanbieters bereitgestellt wird.
  14. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 10-13, wobei der Simulatorzugriffsmechanismus einen oder mehrere Zustände pflegt, die jeweils den jeweiligen Anteilen des Simulationslaufs zugeordnet sind; insbesondere wobei der eine oder die mehreren Zustände mindestens einem der folgenden entsprechen: einem Zustand einer virtuellen Komponente, einem Zustand einer physischen Komponente, einem Zustand einer simulierten Komponente, einem Zustand eines virtuellen Geräts, einem Zustand eines physischen Geräts, einem Zustand eines simulierten Geräts, einem Zustand eines virtuellen Moduls, einem Zustand eines physischen Moduls, einem Zustand eines simulierten Moduls, einem Zustand eines Prozesses, der durch den Simulationslauf zumindest teilweise simuliert wird, oder einem Zustand des Simulationslaufs.
  15. System nach einem der vorhergehenden Ansprüche, wobei: der virtuelle Knoten, der während der Laufzeitoperationen der industriellen Prozessanlage zur Steuerung des industriellen Prozesses arbeitet, ein virtueller Laufzeitknoten ist, und das System ferner einen Virtualisierungsverwaltungsknoten umfasst, der den virtuellen Laufzeitknoten und alle anderen virtuellen Knoten, die in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind, erstellt, konfiguriert und administriert; insbesondere wobei die ggf. anderen in der virtuellen Umgebung angeordneten virtuellen Knoten eine Mehrzahl von virtuellen Knoten enthalten, die eines oder mehrere der folgenden aufweisen: mindestens einem mindestens einem anderen virtuellen Laufzeitknoten oder mindestens einen simulierten Knoten; und/oder insbesondere wobei der Virtualisierungsverwaltungsknoten ferner den I/O-Switch erstellt und konfiguriert.
  16. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 15, wobei der Virtualisierungsverwaltungsknoten den virtuellen Laufzeitknoten basierend auf einer Konfiguration des Prozessleitsystems, die in einer Konfigurationsdatenbank des Prozessleitsystems gespeichert ist, automatisch konfiguriert und administriert; insbesondere wobei der Virtualisierungsverwaltungsknoten den virtuellen Laufzeitknoten basierend auf einer Änderung der Konfiguration des Prozessleitsystems automatisch aktualisiert; mehr insbesondere wobei die Änderung der Konfiguration des Prozessleitsystems eine Änderung an mindestens einem der folgenden beinhaltet: der Konfiguration des virtuellen Laufzeitknotens, einer Konfiguration eines anderen virtuellen Laufzeitknotens, einer Konfiguration eines simulierten Knotens oder einer Konfiguration eines physischen Knotens, der in der physischen Umgebung der industriellen Prozessanlage angeordnet ist.
  17. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 16, wobei der Virtualisierungsverwaltungsknoten ferner einen simulierten Knoten, der in der virtuellen Umgebung der industriellen Prozessanlage angeordnet ist, basierend auf einer Änderung der Konfiguration des Prozessleitsystems, das einem physischen Knoten entspricht, der in der physischen Umgebung der Prozessanlage angeordnet ist und vom simulierten Knoten simuliert wird, automatisch aktualisiert.
  18. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-17, wobei: die Konfigurationsdatenbank des Prozessleitsystems eine Systemkonfigurationsdatenbank ist; das System ferner eine Konfigurationsdatenbank für die virtuelle Umgebung, in der die jeweiligen Konfigurationen der jeweiligen virtuellen Knoten gespeichert sind, die in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind, einschließt, und der Virtualisierungsverwaltungsknoten die in der Konfigurationsdatenbank der virtuellen Umgebung gespeicherten Daten mit in der Systemkonfigurationsdatenbank gespeicherten Daten synchroni si ert.
  19. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-18, wobei: die ggf. anderen virtuellen Knoten, die in der virtuellen Umgebung angeordnet sind, eine Mehrzahl von virtuellen Knoten mit einem oder mehreren von: mindestens einem anderen virtuellen Laufzeitknoten oder mindestens einem simulierten Knoten einschließen; und der Virtualisierungsverwaltungsknoten die Mehrzahl von virtuellen Knoten administriert, die auf eine oder mehrere Bedingungen einer physischen Computerplattform reagieren, die die virtuelle Umgebung unterstützt, wobei die physische Computerplattform ein oder mehrere Computergeräte enthält; insbesondere wobei die eine oder mehreren Bedingungen, die der physischen Computerplattform entsprechen, die die virtuelle Umgebung unterstützt, mindestens eines der folgenden beinhalten: ein Auftreten eines Fehlers, jeweilige Verwendungen einer oder mehrerer Ressourcen der physischen Computerplattform, jeweiliges Laden der einen oder mehreren Ressourcen, jeweilige Verfügbarkeit der einen oder mehreren Ressourcen, jeweilige Bandbreiten der einen oder mehreren Ressourcen, jeweilige Leistungsmaßzahlen der einen oder mehreren Ressourcen, jeweilige Zustände der einen oder mehreren Ressourcen oder eine andere Art von Zustand von mindestens einem Anteil der physischen Computerplattform; mehr insbesondere wobei die eine oder mehreren Ressourcen der physischen Computerplattform mindestens einer von einer Hardwareressource oder einer Softwareressource einschließen.
  20. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 19, wobei die Administration der Mehrzahl von virtuellen Knoten durch den Virtualisierungsverwaltungsknoten mindestens eines beinhaltet von: einem Löschen eines bestimmten virtuellen Knotens, der in der Mehrzahl von virtuellen Knoten enthalten ist, einer Erstellung eines anderen virtuellen Knotens, einer Aktivierung eines virtuellen Standby-Knotens, einer Neuzuweisung von Ressourcen oder einer anderen administrativen Aktion; und/oder wobei die eine oder mehreren Bedingungen, die der physischen Computerplattform entsprechen, die die virtuelle Umgebung unterstützt, während der Laufzeitoperationen einer industriellen Prozessanlage auftreten.
  21. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-20, wobei die vom Virtualisierungsverwaltungsknoten durchgeführte Administration des virtuellen Laufzeitknotens mindestens eines der folgenden beinhaltet: Speichern einer jeweiligen Konfiguration von mindestens einem Anteil des virtuellen Laufzeitknotens; Speichern von Laufzeitdaten, die dem mindestens einen Anteil des virtuellen Laufzeitknotens entsprechen, Speichern von Simulationsdaten, die dem mindestens einen Anteil des virtuellen Laufzeitknotens entsprechen, Speichern eines Zustands des mindestens einen Anteils des virtuellen Laufzeitknotens, oder Speichern anderer Daten, die dem mindestens einen Anteil des virtuellen Laufzeitknotens entsprechen; insbesondere wobei die Administration des virtuellen Laufzeitknotens durch den Virtualisierungsverwaltungsknoten ferner das Wiederherstellen von mindestens dem Anteil des virtuellen Laufzeitknotens von jeweiligen gespeicherten Daten beinhaltet.
  22. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-21, wobei: die ggf. anderen virtuellen Knoten, die in der virtuellen Umgebung angeordnet sind, eine Mehrzahl von virtuellen Knoten mit einem oder mehreren von: mindestens einem anderen virtuellen Laufzeitknoten oder mindestens einem simulierten Knoten einschließen; und die Administration der Mehrzahl von virtuellen Knoten, die von dem Virtualisierungsverwaltungsknoten durchgeführt wird, das Speichern einer jeweiligen Konfiguration von mehr als einem virtuellen Knoten der Mehrzahl von virtuellen Knoten, das Speichern von Laufzeitdaten, die dem mehr als einem virtuellen Knoten entsprechen, und das Speichern von Simulationsdaten, die dem mehr als einem virtuellen Knoten entsprechen, das Speichern eines Zustands des mehr als einen virtuellen Knotens oder das Speichern anderer Daten, die dem mehr als einem virtuellen Knoten entsprechen, einschließt; insbesondere wobei die Administration der Mehrzahl von virtuellen Knoten, die durch den Virtualisierungsverwaltungsknoten ausgeführt wird, ferner das Wiederherstellen des mehr als einen virtuellen Knotens von den jeweiligen gespeicherten Daten einschließt.
  23. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-22, wobei: die ggf. anderen virtuellen Knoten, die in der virtuellen Umgebung angeordnet sind, eine Mehrzahl von virtuellen Knoten einschließen, wobei die Mehrzahl von virtuellen Knoten einen simulierten Knoten einschließt, der einen physischen Knoten simuliert, der in der physischen Umgebung der industriellen Prozessanlage angeordnet ist, wobei der simulierte Knoten ein Komponentenverhaltensmodul enthält, und der Virtualisierungsverwaltungsknoten bewirkt, dass das Komponentenverhaltensmodul des simulierten Knotens in den physischen Knoten heruntergeladen wird.
  24. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-23, wobei der Virtualisierungsverwaltungsknoten an eine oder mehrere andere Anwendungen für die virtuelle Umgebung geschaltet ist; insbesondere wobei die eine oder mehreren Anwendungen mindestens eines der folgenden beinhalten: eine Benutzeroberflächenanwendung, eine Anwendung, die in einer Informationstechnologie-(IT)-Schicht, die der industriellen Prozessanlage zugeordnet ist, ausgeführt wird, eine Anwendung, die in einer Operations Technologie-(OT)-Schicht der industriellen Prozessanlage ausgeführt wird, eine Internet of Things-(IoT)-Anwendung, eine Industrial Internet of Things-(IIoT)-Anwendung, eine Anwendung, die in einer Computing Cloud ausgeführt wird, eine Anwendung, die mit dem Virtualisierungsverwaltungsknoten kommunikativ verbunden ist über ein oder mehrere öffentliche Netzwerke, oder eine Drittanbieteranwendung.
  25. System nach einem der vorherigen Ansprüche, insbesondere nach einem der Ansprüche 15-24, wobei mindestens ein Anteil der Administration des virtuellen Laufzeitknotens und der ggf. anderen virtuellen Knoten, die in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind, automatisch durch den Virtualisierungsverwaltungsknoten ohne Inline-Benutzereingabe ausgeführt wird; insbesondere wobei eine Gesamtheit der Administration des virtuellen Laufzeitknotens und der ggf. anderen virtuellen Knoten, die in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind, automatisch durch den Virtualisierungsverwaltungsknoten ohne Inline-Benutzereingabe durchgeführt wird.
  26. System nach einem der vorherigen Ansprüche, insbesondere nach Anspruch 25, wobei mindestens ein Anteil der Erstellung, Konfiguration und Administration des virtuellen Laufzeitknotens und der ggf. anderen virtuellen Knoten automatisch vom Virtualisierungsverwaltungsknoten ohne Inline-Benutzereingabe durchgeführt wird; insbesondere wobei eine Gesamtheit der Erstellung, Konfiguration und Administration des virtuellen Laufzeitknotens und der ggf. anderen virtuellen Knoten automatisch durch den Virtualisierungsverwaltungsknoten ohne Inline-Benutzereingabe durchgeführt wird.
  27. Verfahren zum Steuern eines Knotens eines Prozessleitsystems einer industriellen Prozessanlage, wobei das Verfahren umfasst: kommunikatives Verbinden eines Feldgeräts und eines virtuellen Knotens über einen I/O-Switch, der zwischen dem Feldgerät und dem virtuellen Knoten angeordnet ist, so dass das Feldgerät, der I/O-Switch und der virtuelle Knoten während der Laufzeitoperationen der industriellen Prozessanlage zum Steuern eines industriellen Prozesses zusammenarbeiten, wobei das Feldgerät in einer physischen Umgebung der industriellen Prozessanlage angeordnet ist und eine physische Funktion erfüllt, wobei der I/O-Switch ein Abonnent von ersten Daten ist, die vom Feldgerät generiert und veröffentlicht wurden, und der I/O-Switch ein Veröffentlicher von zweiten Daten ist, die Angaben zu den ersten vom Feldgerät generierten Daten machen, und der virtuelle Knoten in einer virtuellen Umgebung der industriellen Prozessanlage angeordnet ist, und der virtuelle Knoten ein Abonnent der zweiten Daten ist, die dem Feldgerät entsprechen und vom I/O-Switch veröffentlicht werden; und während der Laufzeitoperationen der industriellen Prozessanlage: Empfangen der zweiten Daten, die dem Feldgerät entsprechen und vom I/O-Switch veröffentlicht werden, durch den virtuellen Knoten; Arbeiten an den zweiten Daten unter Verwendung eines Komponentenverhaltensmoduls des virtuellen Knotens, wodurch ein Steuersignal basierend auf den zweiten Daten generiert wird; und Bewirken einer Angabe, dass das Steuersignal an einen Empfängerknoten des Prozessleitsystems zu übertragen ist, wodurch ein Verhalten des Empfängerknotens modifiziert wird.
  28. Verfahren nach Anspruch 27, wobei: das Bewirken einer Angabe, dass das Steuersignal an den Empfängerknoten des Prozessleitsystems zu übertragen ist, das Veröffentlichen von dritten Daten beinhaltet, die Angaben zum Steuersignal machen, durch den virtuellen Knoten; der I/O-Switch ein Abonnent der dritten Daten ist, die das Steuersignal angeben, und ein Veröffentlicher von vierten Daten ist, die Angaben zu den dritten Daten machen; und der Empfängerknoten oder ein intervenierender Knoten, der kommunikativ zwischen dem I/O-Switch und dem anderen Knoten angeordnet ist, ein Abonnent der vierten Daten ist; insbesondere wobei der intervenierende Knoten der Abonnent der vierten Daten ist, und der intervenierende Knoten ein I/O-Hub-Gerät ist, das kommunikativ zwischen dem I/O-Switch und einer Mehrzahl von physischen Geräten angeordnet ist, die in einer physischen Umgebung der industriellen Prozessanlage enthalten sind, wobei die Mehrzahl von physischen Geräten den Empfängerknoten einschließt, und das I/O-Hub-Gerät Veröffentlicher von Daten ist, die jeweils von jedem physischen Gerät der Mehrzahl von physischen Geräten generiert werden.
  29. Verfahren nach einem der Ansprüche 27-28, wobei das Bewirken, dass eine Angabe des Steuersignals an einen Empfängerknoten des Prozessleitsystems übertragen wird, wodurch das Verhalten des Empfängerknotens modifiziert wird, beinhaltet: Bewirken einer Angabe, dass das Steuersignal an einen anderen virtuellen Knoten zu übertragen ist, wobei der andere virtuelle Knoten eines der folgenden ist: eine virtuelle Prozesssteuerung, eine virtuelle Sicherheitssteuerung; ein virtueller Sicherheits-Logik-Solver; eine virtuelle I/O-Karte, ein Gerät oder Knoten; ein virtuelles drahtloses Gerät; ein virtuelles Ethernet-Gerät; ein virtueller Bedienerarbeitsplatz; ein virtuelles Benutzeroberflächengerät; ein virtuelles Werkzeug; ein virtueller Gateway; ein virtueller/s elektronischer/s Rangierschrank oder -System; oder eine Virtualisierung eines anderen Typs von physischen Gerät oder physischer Komponente, die in einer physischen Umgebung der industriellen Prozessanlage angeordnet ist, wodurch ein Laufzeitverhalten des anderen virtuellen Knotens geändert wird, während die industrielle Prozessanlage zur Laufzeit betrieben wird, um den industriellen Prozess zu steuern; und/oder wobei das Bewirken einer Angabe, dass das Steuersignal an den Empfängerknoten des Prozessleitsystems zu übertragen ist, wodurch ein Verhalten des Empfängerknotens modifiziert wird, beinhaltet: Bewirken der Angabe, dass das Steuersignal an einen physischen Knoten zu übertragen ist, der in der industriellen Prozessanlage angeordnet ist, wodurch ein Laufzeitverhalten des physischen Knotens geändert wird, während die industrielle Prozessanlage zur Laufzeit arbeitet, um den industriellen Prozess zu steuern.
  30. Verfahren nach einem der Ansprüche 27-29, wobei: der virtuelle Knoten ein virtueller Laufzeitknoten ist; das Verfahren ferner das kommunikative Verbinden eines oder mehrerer simulierter Knoten mit dem I/O-Switch umfasst, wobei der eine oder die mehreren simulierten Knoten in der virtuellen Umgebung der industriellen Prozessanlage angeordnet sind, und der eine oder die mehreren simulierten Knoten und der I/O-Switch in einem Simulationssystem enthalten sind; und jeder simulierte Knoten des einen oder der mehreren simulierten Knoten ein entsprechendes Komponentenverhaltensmodul enthält, das verwendet wird, um mindestens einen Anteil eines oder mehrerer entsprechender physischer Geräte oder Komponenten zu simulieren, die in der physischen Umgebung der industriellen Prozessanlage einsetzbar sind, wobei das eine oder die mehreren physischen Geräte oder Komponenten mindestens eines der folgenden beinhalten: eine Prozesssteuerung; eine Sicherheitssteuerung; einen Sicherheits-Logik-Solver; einen I/O-Knoten, eine Karte oder ein Gerät; ein drahtloses Gerät; ein Ethernet-Gerät; einen Bedienerarbeitsplatz; ein Benutzeroberflächengerät; ein Werkzeug; ein Gateway; einen elektronischen Rangierschrank; eine Netzwerkverbindung; eine MAC-Adresse; eine andere Art von physischem Gerät oder physischer Komponente, die in der physischen Umgebung der industriellen Prozessanlage angeordnet ist; oder einen Anteil eines bestimmten physischen Geräts oder einer bestimmten physischen Komponente, die in der physischen Umgebung der industriellen Prozessanlage angeordnet sind, wobei der Anteil des bestimmten physischen Geräts oder der bestimmten physischen Komponente mindestens eines der folgenden enthält: ein Modul, eine Routine, eine Funktion oder ein Verhalten, eine MAC-Adresse, oder eine Hardware-Unterkomponente des bestimmten physischen Geräts oder der bestimmten physischen Komponente; insbesondere ferner umfassend das Ausführen eines Simulationslaufs einschließlich eines bestimmten simulierten Knotens, einschließlich: Ausführen des jeweiligen Komponentenverhaltensmoduls des bestimmten simulierten Knotens zum Generieren von Daten; und Kommunizieren, durch den bestimmten simulierten Knoten über den I/O-Switch, einer Angabe der Daten, die aus der Ausführung des jeweiligen Komponentenverhaltens des bestimmten simulierten Knotens generiert wurden, an mindestens einen von: dem virtuellen Laufzeitknoten, einem anderen virtuellen Laufzeitknoten, einem anderen simulierten Knoten oder einem physischen Knoten, der in der physischen Umgebung der industriellen Prozessanlage angeordnet ist, wobei der mindestens eine von dem virtuellen Laufzeitknoten, der andere virtuelle Laufzeitknoten, der andere simulierte Knoten oder der physische Knoten während der Laufzeitoperationen der industriellen Prozessanlage arbeitet; mehr insbesondere ferner umfassend im Anschluss an die Ausführung des Simulationslaufs einschließlich des speziellen simulierten Knotens, Herunterladen des jeweiligen Komponentenverhaltensmoduls des jeweiligen simulierten Knotens in das/die eine oder mehreren jeweiligen physischen Geräte oder Komponenten entsprechend den jeweiligen simulierten Knoten, wodurch bewirkt wird, dass das eine oder die mehreren jeweiligen physischen Geräte oder Komponenten, die dem bestimmten simulierten Knoten entsprechen, während der Laufzeitoperationen der industriellen Prozessanlage gemäß dem jeweiligen Komponentenverhaltensmodul des bestimmten simulierten Knotens arbeiten.
  31. Verfahren nach einem der Ansprüche 27-30, insbesondere nach Anspruch 30, wobei das Simulationssystem ferner einen Simulatorzugriffsmechanismus beinhaltet und das Verfahren ferner das Verwenden des Simulatorzugriffsmechanismus für mindestens eines der folgenden umfasst: Bereitstellen und/oder Empfangen eines oder mehrerer simulierter Werte, die während der Ausführung des Simulationslaufs einschließlich des bestimmten simulierten Knotens verwendet werden; oder Arbeiten mit einem oder mehreren Simulationsbefehlen, um dabei mindestens einen der folgenden Schritte auszuführen: Ausführen des Simulationslaufs in einem Laufzeittempo, Beschleunigen des Simulationslaufs, um schneller als mit dem Laufzeittempo ausgeführt zu werden, Verlangsamen des Simulationslaufs, um langsamer als mit dem Laufzeittempo ausgeführt zu werden, Festlegen eines simulierten Wertes des Simulationslaufs, Festlegen einer Ausgangsbedingung des Simulationslaufs, Anhalten des Simulationslaufs, Festlegen einer Zwischenbedingung für den Simulationslauf, Ändern eines Tempos für die Ausführung der Simulation, Ändern eines simulierten Wertes, der dem Simulationslauf zugeordnet ist, Sichern oder Speichern von Daten, die mindestens einem Anteil des Simulationslaufs zugeordnet sind, Abrufen von mindestens einem Anteil eines gesicherten oder gespeicherten Simulationslaufs, Sichern oder Speichern einer Konfiguration des Simulationslaufs oder Abrufen einer gesicherten oder gespeicherten Konfiguration des Simulationslaufs; insbesondere wobei das Verwenden des Simulatorzugriffsmechanismus ferner mindestens eines der folgenden umfasst: Verwenden des Simulatorzugriffsmechanismus als Reaktion auf mindestens einen Simulationsbefehl, der über eine Benutzeroberfläche bereitgestellt wird, oder Verwenden des Simulatorzugriffsmechanismus als Reaktion auf mindestens einen weiteren Simulationsbefehl, der über eine Simulationsanwendung eines Drittanbieters bereitgestellt wird.
  32. Verfahren nach einem der Ansprüche 27-31, insbesondere nach Anspruch 31, ferner umfassend das Pflegen eines oder mehrerer Zustände, die jeweils den jeweiligen Anteilen der Ausführung des Simulationslaufs zugeordnet sind, durch den Simulatorzugriffsmechanismus, wobei der eine oder die mehreren Zustände mindestens einem der folgenden entsprechen: einem Zustand einer virtuellen Komponente, einem Zustand einer physischen Komponente, einem Zustand einer simulierten Komponente, einem Zustand eines virtuellen Geräts, einem Zustand eines physischen Geräts, einem Zustand eines simulierten Geräts, einem Zustand eines virtuellen Moduls, einem Zustand eines physischen Moduls, einem Zustand eines simulierten Moduls, einem Zustand eines Prozesses, der durch den Simulationslauf zumindest teilweise simuliert wird, einem Zustand des Simulationslaufs oder einem anderen Zustandstyp.
  33. Ein computerlesbares Medium zum Speichern von Befehlen, die, wenn sie von mindestens einem Prozessor ausgeführt werden, den mindestens einen Prozessor veranlassen, ein Verfahren gemäß einem der Ansprüche 27 bis 32 zu implementieren.
DE102020115439.9A 2019-06-10 2020-06-10 Industrielle steuerungssystemarchitektur für echtzeitsimulation und prozesssteuerung Pending DE102020115439A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962859508P 2019-06-10 2019-06-10
US62/859,508 2019-06-10
US15/931,998 US11249464B2 (en) 2019-06-10 2020-05-14 Industrial control system architecture for real-time simulation and process control
US15/931,998 2020-05-14

Publications (1)

Publication Number Publication Date
DE102020115439A1 true DE102020115439A1 (de) 2020-12-10

Family

ID=71616019

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020115439.9A Pending DE102020115439A1 (de) 2019-06-10 2020-06-10 Industrielle steuerungssystemarchitektur für echtzeitsimulation und prozesssteuerung

Country Status (4)

Country Link
US (4) US11249464B2 (de)
JP (1) JP2024038492A (de)
DE (1) DE102020115439A1 (de)
GB (6) GB2623437A (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200394351A1 (en) * 2018-02-07 2020-12-17 Incucomm, Inc. Operations and maintenance systems and methods employing sensor-less digital twins
US20190243933A1 (en) * 2018-02-07 2019-08-08 Incucomm, Inc. System and method that characterizes an object employing virtual representations thereof
EP3650970B8 (de) * 2018-11-09 2022-02-09 Siemens Aktiengesellschaft Verfahren und vorrichtung zum computergestützten simulieren eines modularen technischen systems
US11768877B2 (en) * 2019-09-20 2023-09-26 Fisher-Rosemount Systems, Inc. Smart search capabilities in a process control system
US11768878B2 (en) * 2019-09-20 2023-09-26 Fisher-Rosemount Systems, Inc. Search results display in a process control system
US20220309753A1 (en) * 2021-03-25 2022-09-29 B/E Aerospace, Inc. Virtual reality to assign operation sequencing on an assembly line
CN117255974A (zh) * 2021-05-04 2023-12-19 Abb瑞士股份有限公司 间歇性使用的设备的安全网络
JP2024018539A (ja) * 2022-07-29 2024-02-08 横河電機株式会社 情報管理装置、演算装置、情報管理プログラム、演算プログラム、情報処理システムおよび情報処理方法
DE102022128061A1 (de) * 2022-10-24 2024-04-25 Endress+Hauser Process Solutions Ag Verfahren und Vorrichtung zum Testen eines Firmware-Updates für ein Edge Device

Family Cites Families (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7392165B2 (en) 2002-10-21 2008-06-24 Fisher-Rosemount Systems, Inc. Simulation system for multi-node process control systems
JP3940665B2 (ja) * 2002-11-27 2007-07-04 株式会社東芝 ハイブリッドシミュレーション装置およびプログラム
US7564805B1 (en) * 2005-08-08 2009-07-21 At&T Intellectual Property, Ii, L.P. Systems, methods, and device for simulating capacity in a network
US8509926B2 (en) 2005-12-05 2013-08-13 Fisher-Rosemount Systems, Inc. Self-diagnostic process control loop for a process plant
WO2008017001A2 (en) * 2006-08-02 2008-02-07 Moka5, Inc. Sharing live appliances
US9411769B2 (en) 2006-09-19 2016-08-09 Fisher-Rosemount Systems, Inc. Apparatus and methods to communicatively couple field devices to controllers in a process control system
US8332567B2 (en) 2006-09-19 2012-12-11 Fisher-Rosemount Systems, Inc. Apparatus and methods to communicatively couple field devices to controllers in a process control system
US7684875B2 (en) 2007-02-02 2010-03-23 Fisher-Rosemount Systems, Inc. Methods and apparatus to configure process control system inputs and outputs
US20090089359A1 (en) 2007-09-27 2009-04-02 Rockwell Automation Technologies, Inc. Subscription and notification in industrial systems
US9083548B2 (en) 2008-09-23 2015-07-14 Fisher-Rosemount Systems, Inc. Apparatus and methods to communicatively couple field devices to controllers in a process control system
US8977851B2 (en) 2009-01-21 2015-03-10 Fisher-Rosemount Systems, Inc. Removable security modules and related methods
US8340790B2 (en) 2009-08-31 2012-12-25 Fisher-Rosemount Systems, Inc. Methods and apparatus to adjust control loop timing in a process control system
WO2012047654A1 (en) 2010-09-27 2012-04-12 Fisher-Rosemount Systems, Inc. Methods and apparatus to virtualize a process control system
US10037443B2 (en) 2011-03-07 2018-07-31 Rockwell Automation Technologies, Inc. Industrial simulation using redirected I/O module configurations
US8756041B2 (en) 2011-03-07 2014-06-17 Rockwell Automation Technologies, Inc. Industrial simulation using redirected I/O module configurations
US9002686B2 (en) * 2011-03-08 2015-04-07 Honeywell International Inc. System and method for simulating operation of substructures of a chemical processing plant
US9014955B2 (en) * 2011-07-20 2015-04-21 Sumitomo Electric Industries, Ltd. Traffic evaluation device non-transitory recording medium and traffic evaluation method
EP2599995B1 (de) * 2011-11-30 2015-10-28 Siemens Aktiengesellschaft Windturbinen-Steuerungssystem
US20130205277A1 (en) * 2012-02-07 2013-08-08 Telerik, AD Environment and method for cross-platform development of software applications
US8892267B2 (en) * 2012-03-13 2014-11-18 International Business Machines Corporation Real-time monitoring, controlling, and optimizing electrical generation assets based on emission level measurements
US9256222B2 (en) 2012-07-18 2016-02-09 International Business Machines Corporation Sensor virtualization through cloud storage and retrieval mechanisms
US10756543B2 (en) * 2012-09-13 2020-08-25 Stem, Inc. Method and apparatus for stabalizing power on an electrical grid using networked distributed energy storage systems
US9709978B2 (en) 2013-05-09 2017-07-18 Rockwell Automation Technologies, Inc. Using cloud-based data for virtualization of an industrial automation environment with information overlays
US9989958B2 (en) 2013-05-09 2018-06-05 Rockwell Automation Technologies, Inc. Using cloud-based data for virtualization of an industrial automation environment
CN105765920B (zh) * 2013-08-08 2019-06-25 瑞典爱立信有限公司 用于在分布式云中媒体处理的方法和装置
KR101488193B1 (ko) * 2013-09-04 2015-01-30 에스케이 텔레콤주식회사 상황 인지 기반의 명령 수행 방법 및 장치
JP6020476B2 (ja) 2014-01-20 2016-11-02 横河電機株式会社 プロセス制御装置及びその更新方法
DE102014109060B3 (de) * 2014-06-27 2015-09-24 Beckhoff Automation Gmbh Netzwerk, Kopf-Teilnehmer und Datenübertragungsverfahren
US9912737B2 (en) 2014-08-27 2018-03-06 Exxonmobil Research And Engineering Company Method and system for modular interoperable distributed control
US9729542B2 (en) * 2014-09-24 2017-08-08 Oracle International Corporation Compartmentalizing application distribution for disparate electronic devices
WO2016089342A1 (en) * 2014-12-01 2016-06-09 General Electric Company Method and system for efficient dynamic alarm construction
US10623244B2 (en) 2014-12-19 2020-04-14 Emerson Process Management Lllp Data transfer on an industrial process network
US10320958B2 (en) 2014-12-19 2019-06-11 Emerson Process Management Lllp Fast data transfer communication protocol for an industrial process network
US10142199B2 (en) 2014-12-19 2018-11-27 Emerson Process Management Lllp Automatic process data transmission and monitoring for an industrial process network
US9946240B2 (en) 2015-01-30 2018-04-17 Fisher-Rosemount Systems, Inc. Apparatus to communicatively couple three-wire field devices to controllers in a process control system
SG10201505489QA (en) 2015-07-14 2016-07-28 Yokogawa Engineering Asia Pte Ltd Systems and methods for optimizing control systems for a process environment
US11222551B2 (en) 2015-07-23 2022-01-11 Rockwell Automation Technologies, Inc. Snapshot management architecture for process control operator training system lifecycle
CA2993824A1 (en) * 2015-07-29 2017-02-02 Illinois Tool Works Inc. System and method to facilitate welding software as a service
US10185311B2 (en) 2015-10-08 2019-01-22 King Fahd University Of Petroleum And Minerals Methods and apparatus to design collaborative automation systems based on data distribution service middleware
US10868754B2 (en) * 2016-01-27 2020-12-15 Nebbiolo Technologies Inc. High availability input/output management nodes
KR102045618B1 (ko) * 2016-05-25 2019-11-18 최창준 기수법에 맞춘 통신 id 입력 방식의 통신 장치
AU2017280352B2 (en) 2016-06-24 2022-06-09 Schneider Electric Systems Usa, Inc. Methods, systems and apparatus to dynamically facilitate boundaryless, high availability M..N working configuration management with supplemental resource
US10382395B2 (en) * 2016-07-25 2019-08-13 Honeywell International Inc. Industrial process control using IP communications with publisher subscriber pattern
US20180260251A1 (en) * 2016-08-28 2018-09-13 Vmware, Inc. Use of nested hypervisors by a resource-exchange system to enhance data and operational security and to facilitate component installation
US10270745B2 (en) 2016-10-24 2019-04-23 Fisher-Rosemount Systems, Inc. Securely transporting data across a data diode for secured process control communications
US10530748B2 (en) 2016-10-24 2020-01-07 Fisher-Rosemount Systems, Inc. Publishing data across a data diode for secured process control communications
US10619760B2 (en) * 2016-10-24 2020-04-14 Fisher Controls International Llc Time-series analytics for control valve health assessment
US10877465B2 (en) 2016-10-24 2020-12-29 Fisher-Rosemount Systems, Inc. Process device condition and performance monitoring
US10257163B2 (en) 2016-10-24 2019-04-09 Fisher-Rosemount Systems, Inc. Secured process control communications
WO2018093351A1 (en) 2016-11-15 2018-05-24 Intel Corporation Neworking internet of things (iot) devices
US10794613B2 (en) * 2017-03-13 2020-10-06 Kevin Michael Murphy, Llc Overflow protection and monitoring apparatus and methods of installing same
US20180314240A1 (en) 2017-04-28 2018-11-01 Honeywell International Inc. Flexible hierarchical model for monitoring distributed industrial control systems
GB2575758B (en) 2017-05-01 2023-04-12 Fisher Rosemount Systems Inc Open architecture industrial control system
ES2863324T3 (es) 2017-05-02 2021-10-11 Siemens Ag Procedimiento para operar una red de automatización, red de automatización y producto de programa informático
US10620613B2 (en) 2017-08-21 2020-04-14 Fisher-Rosemount Systems, Inc. High performance control server system
GB2568806B (en) 2017-10-02 2022-04-06 Fisher Rosemount Systems Inc I/O virtualization for commissioning
CN111164952A (zh) 2017-11-16 2020-05-15 英特尔公司 分布式软件定义的工业系统
US10728303B2 (en) * 2017-12-05 2020-07-28 At&T Intellectual Property I, L.P. Codec selection for end-to-end communication without intermediate transcoding
US11362827B2 (en) * 2018-11-06 2022-06-14 Schlumberger Technology Corporation IOT security mechanisms for industrial applications
US11423254B2 (en) 2019-03-28 2022-08-23 Intel Corporation Technologies for distributing iterative computations in heterogeneous computing environments

Also Published As

Publication number Publication date
US11249464B2 (en) 2022-02-15
GB202316287D0 (en) 2023-12-06
US20230350397A1 (en) 2023-11-02
GB202316285D0 (en) 2023-12-06
GB2623437A (en) 2024-04-17
GB202316286D0 (en) 2023-12-06
GB202316288D0 (en) 2023-12-06
US20220019206A1 (en) 2022-01-20
US11726463B2 (en) 2023-08-15
US20220019205A1 (en) 2022-01-20
GB2589660B (en) 2024-05-01
GB2623438A (en) 2024-04-17
GB202316289D0 (en) 2023-12-06
GB2623439A (en) 2024-04-17
US20200387147A1 (en) 2020-12-10
US11693396B2 (en) 2023-07-04
GB2589660A (en) 2021-06-09
JP2024038492A (ja) 2024-03-19
GB202008489D0 (en) 2020-07-22
GB2623436A (en) 2024-04-17

Similar Documents

Publication Publication Date Title
DE102020115456A1 (de) Derzentralisierter virtualisierungsverwaltungsknoten in prozessleitsystemen
DE102020115439A1 (de) Industrielle steuerungssystemarchitektur für echtzeitsimulation und prozesssteuerung
DE112018002293T5 (de) Industrielles steuerungssystem mit offener architektur
DE102020124789A1 (de) Hyperkonvergente architektur für industrieleitsystem
DE102020115471A1 (de) Virtualisierte echtzeit-i/o in prozessleitsystemen
DE102020115483A1 (de) Veröffentlichungs-/Abonnements-Protokoll für die Echtzeit-Prozesssteuerung
DE102018124411A1 (de) I/o-virtualisierung für die inbetriebnahme
DE112016004666T5 (de) Automatische verteilung von vorrichtungsparametern zur inbetriebnahme von teilen eines getrennten prozessregelkreises
DE102020115508A1 (de) Automatischer lastausgleich und leistungsausgleich von virtuellen knoten, die eine echtzeitsteuerung ausführen, in prozessleitsystemen
DE102020115497A1 (de) Einfache knotenumschaltung in prozessleitsystemen
GB2587842A (en) Centralized virtualization management node in process control system

Legal Events

Date Code Title Description
R012 Request for examination validly filed