DE112018002293T5 - Industrielles steuerungssystem mit offener architektur - Google Patents

Industrielles steuerungssystem mit offener architektur Download PDF

Info

Publication number
DE112018002293T5
DE112018002293T5 DE112018002293.5T DE112018002293T DE112018002293T5 DE 112018002293 T5 DE112018002293 T5 DE 112018002293T5 DE 112018002293 T DE112018002293 T DE 112018002293T DE 112018002293 T5 DE112018002293 T5 DE 112018002293T5
Authority
DE
Germany
Prior art keywords
virtual
control
communication
input
control system
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
DE112018002293.5T
Other languages
English (en)
Inventor
Mark J. Nixon
Juan Carlos Bravo
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=62186554&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE112018002293(T5) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Fisher Rosemount Systems Inc filed Critical Fisher Rosemount Systems Inc
Publication of DE112018002293T5 publication Critical patent/DE112018002293T5/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/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0421—Multiprocessor 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/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/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
    • 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/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines
    • 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/4063—Device-to-bus coupling
    • G06F13/4068—Electrical coupling
    • G06F13/4072—Drivers or receivers
    • 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/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4204—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
    • G06F13/4221—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus
    • G06F13/4226—Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being an input/output bus, e.g. ISA bus, EISA bus, PCI bus, SCSI bus with asynchronous protocol
    • 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 Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Programmable Controllers (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Ein industrielles Steuerungssystem, z. B. eine Prozesssteuerung für den Einsatz in einer Prozessanlage, verwendet eine Hardware-/Softwarearchitektur, die das System reaktiver macht, indem es das System widerstandsfähiger, reaktionsschneller und elastischer macht. Das industrielle Steuerungssystem umfasst eine oder mehrere verteilte Ein-/Ausgabe(I/O)-Steuerungen (BFN I/O-Steuerung), die mit den Feldgeräten innerhalb einer Anlage gekoppelt sind und einen direkten oder indirekten Zugriff auf die Feldgeräte zu Steuerungs- und Nachrichtenzwecken bereitstellen, einen oder mehrere erweiterte Funktions- und Rechenknoten sowie einen oder mehrere Benutzerknoten, die über eine Netzwerkverbindung mit den BFN-I/O-Steuerungen gekoppelt sind. Die erweiterten Funktionsknoten speichern virtuelle Maschinen, Geräte oder Entitäten, die die im Steuerungssystem verwendete Hardware von der Software entkoppeln, die auf dieser Hardware funktioniert, und führen diese aus, wodurch das System einfacher skaliert, neu konfiguriert und geändert werden kann. Darüber hinaus verwendet das industrielle Steuerungssystem ein selbstbeschreibendes Datennachrichtenschema, das sowohl die Daten als auch eine Beschreibung der Daten von einem Absender an einen Empfänger bereitstellt, wodurch verschiedene Nachrichtenprotokolle und Datenformate im Steuerungssystem verwendet werden können, was das System auch offener macht.

Description

  • VERWANDTE ANMELDUNGEN
  • Es handelt sich um eine regulär eingereichte Anmeldung, die den Vorrang und den Vorteil des Anmeldetags der vorläufigen U.S. Patentanmeldung mit Seriennr. 62/492,895 mit dem Titel „Open Architecture Industrial Control System“, die am 1. Mai 2017 eingereicht wurde, und der vorläufigen U.S. Patentanmeldung mit der Seriennr. 62/500,198 mit dem Titel „Open Architecture Industrial Control System“, die am 2. Mai 2017 eingereicht wurde, beansprucht, deren gesamte Offenbarung hiermit ausdrücklich durch Bezugnahme hierin aufgenommen wird.
  • TECHNISCHER BEREICH
  • Diese Patentanmeldung bezieht sich im Allgemeinen auf Industrie- und Prozesssteuerungssysteme und insbesondere auf ein industrielles Steuerungssystem mit offener Architektur, das Zuverlässigkeit, Ausfallsicherheit, Reaktionsfähigkeit und Elastizität gewährleistet.
  • HINTERGRUND
  • Prozess- oder industrielle Steuerungssysteme, wie sie in Chemie-, Erdöl- oder anderen Prozessanlagen verwendet werden, beinhalten typischerweise eine oder mehrere Prozesssteuerungen, die über analoge, digitale oder kombinierte analoge/digitale Busse oder über eine drahtlose Kommunikationsverbindung oder ein drahtloses Netzwerk kommunikativ mit einem oder mehreren Feldgeräten gekoppelt sind. Die Feldgeräte, die beispielsweise Ventile, Ventilstellungsregler, Schalter und Messumformer (z. B. Temperatur-, Druck-, Füllstands- und Durchflusssensoren) sein können, befinden sich innerhalb der Prozessumgebung und übernehmen im Allgemeinen physikalische oder prozesssteuernde Funktionen wie das Öffnen oder Schließen von Ventilen, das Messen von Prozessparametern usw. zur Steuerung eines oder mehrerer Prozesse, die innerhalb der Prozessanlage oder des Systems ausgeführt werden. Intelligente Feldgeräte, wie beispielsweise die Feldgeräte, die dem bekannten FOUNDATION® Fieldbus-Protokoll entsprechen, können auch Steuerberechnungen, Alarmierungsfunktionen und andere Steuerfunktionen ausführen, die üblicherweise in der Steuerung implementiert sind. Die Prozesssteuerungen, die zentral angeordnet sein können, aber auch dezentral in der Anlagenumgebung angeordnet sein können, empfangen Signale, die Prozessmessungen der Feldgeräte und/oder andere Informationen zu den Feldgeräten anzeigen, und führen eine Steuerungsanwendung aus, die beispielsweise verschiedene Steuermodule ausführt, die Prozesssteuerungsentscheidungen treffen, auf Grundlage der empfangenen Informationen Steuersignale erzeugen und sich mit den in den Feldgeräten ausgeführten Steuermodulen oder Blöcken koordinieren, wie beispielsweise HART®, WirelessHART® und FOUNDATION® Feldbusfeldgeräte. Die Steuermodule in der Steuerung senden die Steuersignale über die Kommunikationsleitungen oder Verbindungen zu den Feldgeräten, um dadurch den Betrieb mindestens eines Teils der Prozessanlage oder des Systems zu steuern.
  • Informationen von den Feldgeräten und der Steuerung werden in der Regel von den Steuerungen über eine Datenautobahn zu einem oder mehreren anderen Hardwaregeräten, wie z. B. Bedienerarbeitsplätzen, PCs oder Computergeräten, Datenhistorikern, Berichtgeneratoren, zentralisierten Datenbanken oder anderen zentralisierten administrativen Computergeräten bereitgestellt, die in der Regel in Steuerungsräumen oder an anderen Orten entfernt von der raueren Anlagenumgebung platziert werden. Jedes dieser Hardware-Geräte ist typischerweise über die gesamte Prozessanlage oder einen Abschnitt der Prozessanlage hinweg zentralisiert. Diese Hardwaregeräte führen Anwendungen aus, die es beispielsweise einem Ingenieur ermöglichen, den Prozess zu konfigurieren, oder einem Bediener, Funktionen in Bezug auf die Steuerung eines Prozesses und/oder den Betrieb der Prozessanlage auszuführen, wie z. B. das Ändern der Einstellungen der Prozesssteuerungsroutine, das Ändern des Betriebs der Steuermodule innerhalb der Steuerungen oder der Feldgeräte, das Anzeigen des aktuellen Prozesszustands, das Anzeigen von Alarmen, die von Feldgeräten und Steuerungen erzeugt werden, das Simulieren des Betriebs des Prozesses zum Zwecke der Schulung von Personal oder das Testen der Prozesssteuerungssoftware, das Halten und Aktualisieren einer Konfigurationsdatenbank usw. Die von den Hardwaregeräten, Steuerungen und Feldgeräten verwendete Datenautobahn kann einen verkabelten Kommunikationsweg, einen drahtlosen Kommunikationsweg oder eine Kombination aus verkabelten und drahtlosen Kommunikationswegen beinhalten.
  • Als Beispiel enthält das DeltaV™-Steuerungssystem, das von Emerson Process Management vertrieben wird, mehrere Anwendungen, die in verschiedenen Geräten an verschiedenen Orten innerhalb einer Prozessanlage gespeichert und ausgeführt werden. Eine Konfigurationsanwendung, die in einer oder mehreren Arbeitsstationen oder Computervorrichtungen untergebracht ist, ermöglicht Benutzern das Erstellen oder Ändern von Prozessregelmodulen und das Herunterladen dieser Prozessregelmodule über eine Datenautobahn auf dedizierte dezentrale Steuerungen. Typischerweise bestehen diese Steuerungsmodule aus kommunikativ miteinander verbundenen Funktionsblöcken, die Objekte in einem objektorientierten Programmierprotokoll sind, das Funktionen innerhalb des Steuerungsschemas auf der Basis von Eingängen ausführt und die Ausgänge an andere Funktionsblöcke innerhalb des Steuerungsschemas bereitstellt. Die Konfigurationsanwendung kann es einem Konfigurationsdesigner auch ermöglichen, Bedienoberflächen zu erstellen oder zu ändern, die von einer Anzeigeanwendung verwendet werden, um Daten an einen Bediener anzuzeigen, und dem Bediener zu ermöglichen, Einstellungen, wie beispielsweise Sollwerte, innerhalb der Prozesssteuerungsroutinen zu ändern. Jede dedizierte Steuerung und in einigen Fällen ein oder mehrere Feldgeräte speichern und führen eine entsprechende Steuerungsanwendung aus, die die ihr zugeordneten und heruntergeladenen Steuermodule ausführt, um die eigentliche Prozesssteuerungsfunktionalität zu implementieren. Die Betrachtungsanwendungen, die auf einer oder mehreren Bedienerarbeitsplätzen (oder auf einer oder mehreren entfernten Rechengerä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 Konstrukteuren, Betreibern oder Benutzern von Prozessleitsystemen über die Benutzeroberflächen an und können eine von mehreren verschiedenen Ansichten bereitstellen, wie beispielsweise eine Bedienersicht, eine Ingenieursicht, eine Technikersicht usw. Eine Datenhistoriker-Anwendung wird typischerweise in einer Datenhistorikervorrichtung gespeichert und ausgeführt, die einige oder alle Daten sammelt und speichert, die über die Datenautobahn bereitgestellt werden, während eine Konfigurationsdatenbankanwendung in einem noch weiteren an die Datenautobahn angeschlossenen Computer ausgeführt werden kann, um die aktuelle Konfiguration der Prozesssteuerungsroutine und die damit verbundenen Daten zu speichern. Alternativ kann die Konfigurationsdatenbank in derselben Arbeitsstation wie die Konfigurationsanwendung platziert sein.
  • Die Architektur der derzeit bekannten Prozesssteuerungsanlagen und Prozessleitsysteme wird stark durch begrenzten Steuerungs- und Gerätespeicher, Kommunikationsbandbreite sowie Steuerungs- und Geräteprozessorfähigkeit beeinflusst. In derzeit bekannten Prozesssteuerungssystemarchitekturen 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 ist entsprechend mit diesem begrenzten Satz von Datenregeln konfiguriert. Folglich werden Daten, die bei der Fehlerbehebung und Prozessanalyse nützlich sein könnten, oft nicht archiviert, und wenn sie gesammelt werden, sind die nützlichen Informationen möglicherweise aufgrund der Datenkomprimierung verloren gegangen.
  • Um die Speichernutzung der Steuerung in den derzeit bekannten Prozessleitsystemen zu minimieren, werden ausgewählte Daten, die archiviert oder gespeichert werden sollen (wie in der Konfiguration des Steuerung angegeben), an die Arbeitsstation oder das Rechengerät zur Speicherung bei einem geeigneten Datenhistoriker 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 Historiker oder Silo ist die Datenerfassung und Zeitstempelung zudem oft nicht mit dem eigentlichen Prozess synchronisiert.
  • Ebenso bleiben in Chargen-Prozesssteuerungssystemen, um den Speicherverbrauch der Steuerung zu minimieren, Chargenrezepte und Schnappschüsse der Steuerungskonfiguration typischerweise an einem zentralen administrativen Computergerät oder -standort (z. B. an einem Datensilo oder Historiker) gespeichert und werden nur bei Bedarf an eine Steuerung übertragen. Eine solche Strategie führt zu erheblichen Burst-Lasten in der Steuerung und in der Kommunikation zwischen der Arbeitsstation oder der zentralen Verwaltungscomputeranordnung und der Steuerung.
  • Darüber hinaus spielen die Leistungsfähigkeit und Leistungseinschränkungen relationaler Datenbanken von derzeit bekannten Prozessleitsystemen in Verbindung mit den bisher hohen Kosten für die Plattenspeicherung eine große Rolle bei der Strukturierung von Daten in unabhängige Einheiten oder Silos, um die Ziele spezifischer Anwendungen zu erreichen. So werden beispielsweise innerhalb des DeltaV™-Systems die Archivierung von Prozessmodellen, kontinuierlichen Vergangenheitsdaten sowie Chargen- und Ereignisdaten in drei verschiedenen Anwendungsdatenbanken oder Datensilos gespeichert. Jedes Silo hat eine andere Schnittstelle, um auf die darin gespeicherten Daten zuzugreifen.
  • Auf jeden Fall ist die aktuelle Architektur industrieller Steuerungssysteme, wie z. B. Prozesssteuerungssysteme, weitgehend hardwaregesteuert, da verschiedene Funktionen, wie z. B. Steuerungsfunktionen, Ein-/Ausgabefunktionen (I/O), Benutzeroberflächenfunktionen usw. in bestimmter Hardware (z. B. Benutzerarbeitsplätze, Prozesssteuerungen, dedizierte I/O-Geräte, Feldgeräte usw.) ausgeführt werden und an diese gebunden sind und jederzeit in der spezifischen Hardware verbleiben. Dieses architektonische Design begrenzt die Belastbarkeit, Reaktionsfähigkeit und Elastizität des Steuerungssystems, da diese Systeme schwer zu ändern oder schnell zu rekonfigurieren sind, eng an proprietäre Hardware gebunden sind, die zur Implementierung proprietärer Steuerungssoftware verwendet wird, Hardware-Redundanz auf Gerätebasis erfordern, die teuer zu implementieren sein kann, und nicht leicht skalierbar sind, ohne zusätzliche Hardware hinzuzufügen, die insbesondere auf bestimmte Weise konfiguriert werden muss.
  • KURZDARSTELLUNG
  • Ein industrielles Steuerungssystem, z. B. eine Prozesssteuerung für den Einsatz in einer Prozessanlage, verwendet eine Hardware-/Softwarearchitektur, die das System reaktiver macht, indem es das System widerstandsfähiger, reaktionsschneller und elastischer macht. Insbesondere entkoppelt die industrielle Steuerung weitgehend die in der Steuerung verwendete Hardware von der Software, die auf dieser Hardware funktioniert, wodurch das System einfacher skaliert, neu konfiguriert und geändert werden kann. Im Allgemeinen beinhaltet das neue Industrie- oder Prozesssteuerungssystem eine oder mehrere Ein-/Ausgabevorrichtungen (I/O) mit Grundfunktionsknoten (BFN), die mit Feldgeräten innerhalb einer Anlage gekoppelt sind und einen direkten oder indirekten Zugriff auf die Feldgeräte für Steuerungs- und Nachrichtenzwecke ermöglichen. Das System beinhaltet auch einen oder mehrere erweiterte Funktionsknoten (AFNs) und einen oder mehrere Benutzer- oder andere Rechenknoten, die über eine Netzwerkverbindung mit den BFN-I/O-Geräten und den AFNs gekoppelt sind, wie beispielsweise ein offenes Protokollnetzwerk wie ein Ethernet-Bus oder Switch.
  • Jede der BFN-I/O-Vorrichtungen (auch als BFN-Steuerung bezeichnet) kann einen Frontend-Prozessor (der ein Multicore-Prozessor sein kann) beinhalten, der mit dedizierter I/O-Hardware verbunden ist, die wiederum Kommunikationskanäle oder Busverbindungen zu verschiedenen Feldgeräten innerhalb der Anlage bereitstellt oder implementiert, wobei eines der verschiedenen Feldgeräteprotokolle verwendet wird, die derzeit für Feldgeräte existieren. Die erweiterten Funktionsknoten können eine oder mehrere Verarbeitungsvorrichtungen, wie beispielsweise einen oder mehrere Server, beinhalten, die miteinander gekoppelt sind oder die an einem bestimmten Knoten miteinander verbunden sind, um übergeordnete Verarbeitungsaktivitäten durchzuführen, wie z. B. Kontrollverarbeitung, Datenanalyseverarbeitung, Alarm- und Warnungsverarbeitung, Datenspeicherung usw. Die erweiterten Funktionsknoten können verschiedene virtuelle Geräte wie virtuelle Steuerungen, virtuelle Ethernet-Geräte, virtuelle Protokoll- und Steuerungsübersetzungsgeräte, virtuelle Datenanalysegeräte usw. beinhalten, die darin angeordnet und ausgeführt werden. Jede oder mehrere Gruppen der virtuellen Geräte (z. B. die in Software implementiert werden können, die auf generischer Verarbeitungshardware innerhalb der erweiterten Funktionsknoten ausgeführt wird) arbeiten jedoch als eigenständige Geräte, die unabhängig von den anderen virtuellen Geräten innerhalb des erweiterten Funktionsknotens und der BFN-I/O-Geräte laufen. Darüber hinaus kann das System einen oder mehrere andere Computerknoten beinhalten, die Benutzerarbeitsplätze, Datenhistoriker, Konfigurationsdatenbanken usw. implementieren können.
  • Die Vorrichtungen, einschließlich der virtuellen Vorrichtungen oder Elemente innerhalb jedes der Knoten (z. B. die Grundfunktionsknoten, die erweiterten Funktionsknoten und die anderen Rechenknoten) kommunizieren miteinander über Datennachrichten, bei denen die sendenden Vorrichtungen oder Elemente (auch als Aktoren bezeichnet) Datennachrichten an andere virtuelle Vorrichtungen oder Aktoren unter Verwendung eines Nachrichtenformatierungs- und Adressierungsschemas senden, das unabhängig vom Standort der Hardwarevorrichtung ist, d. h., wobei das Kommunikationsadressierungsschema die Hardwarevorrichtung oder den Standort der Hardwarevorrichtung (z. B. Server, Prozessor usw.), die den beabsichtigten Empfänger der Nachricht bereitstellt, nicht spezifiziert oder nicht davon abhängig ist. So können beispielsweise die Datennachrichten an Adressen gesendet werden, die anderen virtuellen Vorrichtungen oder Elementen zugeordnet sind, ohne den Hardware- oder Netzwerkstandort dieser virtuellen Vorrichtungen anzugeben, wodurch die virtuellen Vorrichtungen von einem Hardwarestandort zu einem anderen Hardwarestandort (z. B. zwischen verschiedenen Verarbeitungsvorrichtungen an einem bestimmten fortgeschrittenen Funktionsknoten oder zwischen verschiedenen Hardwarevorrichtungen verschiedener fortgeschrittener Funktionsknoten) ohne Unterbrechung der Kommunikation verschoben werden können, ohne dass das Steuersystem neu konfiguriert werden muss, um solche Standortänderungen durchzuführen.
  • Darüber hinaus kann das Datennachrichtenschema unidirektional und protokollunabhängig sein, was bedeutet, dass jedes virtuelle Gerät oder Element (sowohl innerhalb der BFNI/O-Steuerung als auch der erweiterten Funktionsknoten) jedes gewünschte Kommunikationsprotokoll oder jede beliebige Paketstruktur und jedes gewünschte Datenformat innerhalb der Nachrichten verwenden kann, um Nachrichten zwischen Elementen und Hardwaregeräten über die Netzwerkverbindung zu senden. Im Allgemeinen kann die Datennachrichtenstruktur selbstbeschreibend sein, da dieses Datennachrichtenschema Datennachrichten vorsieht, die die zu übertragenden Daten und Datenformat-(oder Metadaten-)Nachrichten beinhalten, die die Struktur der Daten in der Datennachricht definieren oder identifizieren und/oder das Nachrichtenprotokoll, das zur Dekodierung der Datennachricht verwendet werden soll. Die Datennachrichten und Datenformatnachrichten können getrennt und zu verschiedenen Zeiten gesendet werden, damit der Empfänger einer Nachricht das Format und das Kommunikationsprotokoll der Datennachricht verstehen kann, um die Daten innerhalb der Datennachricht zu dekodieren, zu interpretieren und zu verwenden. In einigen Fällen kann jeder erweiterte Funktionsknoten eine Steuerung oder einen anderen Übersetzungsdienst (der eine virtuelle Maschine oder Vorrichtung sein kann) beinhalten, der die Dateninterpretation und -dekodierung von Nachrichten durchführt, die an die virtuellen Steuerungen oder an andere virtuelle Elemente innerhalb des erweiterten Funktionsknotens gesendet werden.
  • Diese Aspekte des Datennachrichtenprotokolls ermöglichen es, dass virtuelle Elemente hardwareortunabhängig sind, d. h. die Elemente des Steuerungssystems können entweder an einem einzigen Knoten (der mehrere Server oder Blades beinhalten kann) oder an verschiedenen Knoten verschoben oder in verschiedene Hardwarevorrichtungen (z. B. verschiedene Verarbeitungsvorrichtungen) platziert werden, ohne dass die Elemente des Steuerungssystems neu konfiguriert werden müssen. Diese Funktion ermöglicht eine robustere und kostengünstigere Bereitstellung von Redundanzen, da mit dieser Funktion virtuelle Geräte auf jedes verfügbare Hardwaregerät verschoben werden können, wenn das Hardwaregerät, auf dem das virtuelle Gerät läuft, ausfällt, überlastet wird oder aus anderen Gründen benötigt wird. Darüber hinaus ermöglichen diese Aspekte des Datennachrichtenprotokolls der neuen Steuerungsarchitektur virtuellen Geräten oder Elementen das Senden und Empfangen von Datennachrichten eines beliebigen Formats oder Nachrichtenprotokolls, ohne dass alle virtuellen Geräte oder Elemente im Steuersystem das gleiche Protokoll oder Nachrichten- oder Datenformat verwenden müssen. So können beispielsweise verschiedene virtuelle Steuerungen oder virtuelle Steuerelemente jedes gewünschte Kommunikationsprotokoll und/oder Datenformat verwenden, um mit anderen virtuellen Geräten oder virtuellen Elementen innerhalb desselben Knotens oder innerhalb verschiedener Knoten über ein gemeinsames Kommunikationsnetz zu kommunizieren. Diese Funktionen ermöglichen die Interoperabilität von virtuellen Geräten oder Elementen, die von verschiedenen Herstellern im selben Steuerungssystem oder Netzwerk bereitgestellt werden.
  • Darüber hinaus kann die Steuerungssystemarchitektur ein Aktormodell verwenden, um die Kommunikation innerhalb des Systems durchzuführen. Unter Verwendung des Aktormodells kann jeder Steuereintrag oder jede andere virtuelle Einheit im System ein separater Aktor sein, der unabhängig von allen Aktoren im System arbeitet. Jeder Aktor ist konfiguriert, unidirektionalen Nachrichtenaustausch (z. B. unter Verwendung des hierin erwähnten selbstbeschreibenden Nachrichtenprotokolls) zu verwenden, um Nachrichten an nachgelagerte Aktoren über Adressen zu senden, die die empfangenden Aktoren angeben, nicht die Hardware-Standorte, an denen die empfangenden Aktoren ausführen. Infolgedessen ist jeder Aktor eine in sich geschlossene Entität, die asynchron mit anderen Aktoren in der Ausführung und Kommunikation arbeitet. Diese Funktion bedeutet, dass einzelne Aktoren in der Hardware bewegt werden können (für Lastausgleich, Fehlertoleranz und Redundanzzwecke), ohne den Rest des Steuerungssystems oder die anderen Aktoren im Steuerungssystem neu zu konfigurieren, z. B. ohne die anderen Aktoren zu benachrichtigen. Darüber hinaus ermöglicht die Verwendung eines Aktormodells auf diese Weise die Durchführung von Rekonfigurationsaktivitäten für einige Aktoren in einem Nachrichtenstrom oder Thread, ohne die anderen Aktoren neu zu konfigurieren oder zu ändern, was die Aktualisierung des Systems einfacher und belastbarer macht.
  • In einer Ausführungsform beinhaltet ein industrielles Steuerungssystem mit einer Vielzahl von Feldgeräten, die physikalische Funktionen in einer industriellen Umgebung ausführen, einen Ein-/Ausgabeknoten mit einem Ein-/Ausgabeprozessor, der mit der Vielzahl von Feldgeräten innerhalb der industriellen Umgebung gekoppelt ist; einen oder mehrere virtuelle Steuerungsknoten, wobei jeder der einen oder mehreren virtuellen Steuerungsknoten einen oder mehrere Prozessoren, einen Speicher, einen oder mehrere virtuelle Steuerungen, die im Speicher gespeichert und auf dem einen oder den mehreren Prozessoren ausführbar sind, um die Steuerung der Feldgeräte innerhalb der industriellen Umgebung durchzuführen, und ein im Speicher gespeicherten und auf dem einen oder den mehreren Prozessoren ausführbares Hauptsteuerprogramm zum Verwalten des Betriebs des einen oder der mehreren virtuellen Steuerungen am Knoten; und ein Kommunikationsnetz, das den Ein-/Ausgabeknoten mit jedem der einen oder mehreren virtuellen Steuerungsknoten verbindet. Der Ein-/Ausgabeprozessor empfängt Gerätesignale von einem oder mehreren der Feldgeräte innerhalb der industriellen Umgebung, verarbeitet die Gerätesignale und legt die verarbeiteten Gerätesignale zur Abgabe an die einen oder mehreren virtuellen Steuerungen auf das Kommunikationsnetz und empfängt Steuersignale von einem oder mehreren der virtuellen Steuerungen über das Kommunikationsnetz, verarbeitet die empfangenen Steuersignale und sendet die verarbeiteten Steuersignale an eine oder mehrere der Feldgeräte in der industriellen Umgebung.
  • Falls gewünscht, beinhaltet der eine oder die mehreren virtuellen Steuerungsknoten eine Vielzahl von virtuellen Steuerungsknoten und der eine oder die mehreren virtuellen Steuerungen eines der Vielzahl von virtuellen Steuerungsknoten ist von dem einen der Vielzahl von virtuellen Steuerungsknoten zu einem anderen der Vielzahl von virtuellen Steuerungsknoten bewegbar, ohne die Kommunikation der virtuellen Steuerung neu zu konfigurieren. In einem anderen Fall sind der eine oder die mehreren virtuellen Steuerungen von einer Position des Speichers eines virtuellen Steuerungsknotens zu einer anderen Position im Speicher des virtuellen Steuerungsknotens bewegbar, ohne die Kommunikation der virtuellen Steuerung neu zu konfigurieren. Zusätzlich kann mindestens einer der virtuellen Steuerungsknoten eine Vielzahl von verschiedenen Speichervorrichtungen beinhalten und die eine oder die mehreren virtuellen Steuerungen können von einer der Vielzahl von Speichervorrichtungen des mindestens einen der virtuellen Steuerungsknoten zu einer anderen der Vielzahl von Speichervorrichtungen des mindestens einen der virtuellen Steuerungsknoten bewegbar sein, ohne die Kommunikation der virtuellen Steuerung neu zu konfigurieren.
  • Ebenso kann der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine beinhalten, die mit einer physikalischen Ein-/Ausgabevorrichtung in der industriellen Umgebung gekoppelt ist, um Gerätesignale von Feldgeräten über die physikalische Ein-/Ausgabevorrichtung in der industriellen Umgebung zu empfangen. Der Ein-/Ausgabeknoten kann auch oder stattdessen eine virtuelle Ein-/Ausgaberoutine beinhalten, die gekoppelt ist, um Gerätesignale direkt von Feldgeräten in der industriellen Umgebung zu empfangen, wobei die virtuelle Ein-/Ausgaberoutine auf einem Universalprozessor innerhalb des Ein-/Ausgabeknotens ausgeführt wird, um eine Ein-/Ausgabesignalverarbeitung an Gerätesignalen von den Feldgeräten und an die Feldgeräte gelieferten Steuersignalen durchzuführen. Außerdem kann der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine beinhalten, die Gerätesignale an die virtuellen Steuerungen in den virtuellen Steuerungsknoten unter Verwendung eines selbstbeschreibenden Kommunikationsschemas und/oder unter Verwendung einer Vielzahl von verschiedenen Kommunikationsprotokollen und/oder unter Verwendung eines hardwareortunabhängigen Kommunikationsadressierungsschemas übermittelt.
  • Darüber hinaus kann der Ein-/Ausgabeknoten eine im Speicher des Ein-/Ausgabeknotens gespeicherte Steuerungsroutine enthalten, die auf dem Prozessor des Ein-/Ausgabeknotens ausgeführt wird, um eines oder mehrere der Gerätesignale zu verwenden, um ein oder mehrere Steuersignale für Steuerung eines der Feldgeräte in der industriellen Umgebung zu steuern. In diesem Fall können die virtuellen Steuerungen in einem oder mehreren virtuellen Steuerungsknoten Steuerroutineausführungen mit höchstens einer ersten Geschwindigkeit ausführen, und die Steuerungsroutine im Ein-/Ausgabeknoten kann Steuerungsroutineausführungen mit einer zweiten Geschwindigkeit ausführen, die höher als die erste Geschwindigkeit ist. In einer Ausführungsform kann die zweite Geschwindigkeit gleich oder größer als das Fünffache der ersten Geschwindigkeit sein.
  • Ebenso beinhaltet der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgabekommunikationsroutine, die Gerätesignale in das Kommunikationsnetz bündelt, die Gerätesignale von einer Vielzahl von Feldgeräten über eine Vielzahl von verschiedenen Kommunikationsprotokollen empfängt und die die Gerätesignale auf dem Kommunikationsnetz unter Verwendung eines selbstbeschreibenden Kommunikationsschemas bündelt und/oder die Gerätesignale von einer Vielzahl von Feldgeräten über eine Vielzahl von verschiedenen Kommunikationsprotokollen empfängt und die Gerätesignale auf das Kommunikationsnetz unter Verwendung der Vielzahl von verschiedenen Kommunikationsprotokollen und eines selbstbeschreibenden Kommunikationsschemas bündelt. Das selbstbeschreibende Kommunikationsschema kann Gerätesignaldaten beinhalten, die die Gerätesignale in einem ersten Kommunikationsprotokoll und Protokollbeschreibungssignale, die das erste Kommunikationsprotokoll beschreiben.
  • Außerdem kann das Hauptsteuerprogramm der virtuellen Steuerungsknoten auf Wunsch einen Lastausgleich der Prozessoren im virtuellen Steuerungsknoten durchführen und das Hauptsteuerprogramm mindestens eines der virtuellen Steuerungsknoten kann konfiguriert werden, um eine virtuelle Steuerung von einem Prozessor zu einem anderen Prozessor am virtuellen Steuerungsknoten zu bewegen, ohne die Kommunikation der virtuellen Steuerung für die virtuelle Steuerung neu zu konfigurieren.
  • In einer weiteren Ausführungsform beinhaltet ein industrielles Steuerungssystem mit einer Vielzahl von Feldgeräten, die physikalische Funktionen innerhalb einer industriellen Umgebung ausführen, einen Ein-/Ausgabeknoten mit einem Ein-/Ausgabeprozessor, der über einen oder mehrere Kommunikationskanäle mit der Vielzahl von Feldgeräten innerhalb der industriellen Umgebung gekoppelt ist; eine Vielzahl von Steuerungsknoten, wobei jeder der Steuerungsknoten einen oder mehrere Prozessoren, einen Speicher, eine oder mehrere im Speicher gespeicherte und auf einem oder mehreren Prozessoren ausführbare Steuerungen zur Steuerung der Feldgeräte innerhalb der industriellen Umgebung und ein im Speicher gespeichertes und auf einem oder mehreren Prozessoren ausführbares Hauptsteuerprogramm zur Verwaltung des Betriebs der einen oder mehreren Steuerungen am Steuerungsknoten beinhaltet; und ein offenes ProtokollKommunikationsnetz, das den Ein-/Ausgabeknoten mit jedem der einen oder mehreren Steuerungsknoten unter Verwendung eines offenen Kommunikationsprotokolls verbindet. Dabei empfängt der Ein-/Ausgabeprozessor Gerätesignale von einem oder mehreren der Feldgeräte in der industriellen Umgebung, platziert die Gerätesignale über ein offenes Kommunikationsprotokoll in das Kommunikationsnetz zur Abgabe an die eine oder mehreren Steuerungen und empfängt Steuersignale von einer oder mehreren der Steuerungen über das Kommunikationsnetz und sendet die Steuersignale an eine oder mehrere der Feldgeräte in der industriellen Umgebung.
  • Das Kommunikationsnetz mit offenem Protokoll kann ein Ethernet-Kommunikationsnetz sein und/oder ein TCP/IP-Paket-basiertes Netzwerkkommunikationsschema verwenden. Außerdem kann der Ein-/Ausgabeknoten Gerätesignale an die Steuerungen an den Steuerknoten übermitteln, indem er Daten in einer Vielzahl von verschiedenen Kommunikationsprotokollen über Pakete sendet, die gemäß dem offenen Kommunikationsprotokoll konfiguriert sind, und/oder ein hardwareortunabhängiges Kommunikationsadressierungsschema verwendet.
  • In einer weiteren Ausführungsform beinhaltet ein industrielles Steuerungssystem mit einer Vielzahl von Feldgeräten, die physikalische Funktionen innerhalb einer industriellen Umgebung ausführen, einen Ein-/Ausgabeknoten mit einem Ein-/Ausgabeprozessor, der über einen oder mehrere Kommunikationskanäle, eine Vielzahl von Steuerungsknoten mit der Vielzahl von Feldgeräten innerhalb der industriellen Umgebung gekoppelt ist, wobei jeder der Steuerungsknoten einen oder mehrere Prozessoren, einen oder mehrere Speicher, eine oder mehrere Steuerungen, die in dem einen oder den mehreren Speichern gespeichert und auf dem einen oder den mehreren Prozessoren ausführbar sind, um die Steuerung der Feldgeräte in der industriellen Umgebung durchzuführen, und ein Kommunikationsnetz umfasst, das den Ein-/Ausgabeknoten mit jedem der einen oder mehreren Steuerungsknoten verbindet. In diesem Beispiel empfängt der Ein-/Ausgabeprozessor Gerätesignale von einem oder mehreren der Feldgeräte in der industriellen Umgebung und platziert die Gerätesignale über ein hardwareortunabhängiges Kommunikationsadressierungsschema in das Kommunikationsnetz.
  • Figurenliste
    • 1 ist ein Blockdiagramm einer exemplarischen Industrie- oder Prozessleitsystemarchitektur mit mehreren BFN-I/O-Steuerungen oder -Geräten, mehreren erweiterten Funktionsknoten und anderen Rechenknoten, wie beispielsweise Benutzerarbeitsplatzknoten, die über ein gemeinsames Kommunikationsnetz kommunikativ verbunden sind.
    • 2 ist ein Blockdiagramm, das eine detailliertere exemplarische Anordnung von virtuellen Geräten und Elementen innerhalb einer BFN-I/O-Steuerung und eines einzelnen erweiterten Funktionsknotens von 1 veranschaulicht.
    • 3 ist ein Datenflussdiagramm, das den Datenfluss zwischen verschiedenen virtuellen Elementen innerhalb des Systems der 1 und 2 veranschaulicht.
    • 4 ist ein Flussdiagramm, das ein selbstbeschreibendes Datennachrichtenschema veranschaulicht, das von den verschiedenen virtuellen Elementen in den Steuerungssystemen der 1 und 2 implementiert werden kann, um standort- und protokollunabhängiges Nachrichtenaustausch durchzuführen.
    • 5 ist ein exemplarisches Aktormodelldiagramm, das neben einem herkömmlichen Regelkreisdiagramm angeordnet ist und ein Verfahren zum Implementieren eines aktorbasierten Regelkreises veranschaulicht, der die Kommunikation von Prozessvariablenmessungen mit einem PID-Steuerelement durchführt, das ein Steuersignal erzeugt, das an einen Ausgang gesendet wird, unter Verwendung des aktorbasierten Modells und des hierin beschriebenen selbstbeschreibenden Datennachrichtensystems.
    • 6 ist ein Diagramm eines lokalen schnellen Steuerungsnetzwerks, das in den Steuerungssystemen der 1 und 2 implementiert werden kann, einschließlich mehrerer schneller BFN-I/O-Steuerungen, die mit einem einzelnen Steuerungsübersetzer innerhalb eines einzelnen erweiterten Funktionsknotens gekoppelt sind.
    • 7 ist ein Blockdiagramm einer exemplarischen Architektur zur Verteilung von Aufgaben innerhalb eines Multicore-Prozessors einer BFN-I/O-Steuerung auf das lokale schnelle Steuerungsnetzwerk von 6.
    • 8 ist eine exemplarische Konfigurationshierarchie des lokalen schnellen Steuerungsnetzwerks von 6.
    • 9 ist ein Diagramm einer logischen Struktur von Elementen innerhalb eines Prozessleitsystems, mit dem Steuerungsfunktionen ausgeführt werden.
    • 10 ist ein allgemeines Hardware-Protokolldiagramm eines Steuerungsnetzwerks gemäß dem S88-Standard.
    • 11 ist ein Datendiagramm, das ein Datenumwandlungsverfahren oder -schema zur Verwendung mit den logischen und Hardwarediagrammen der 9 und 10 veranschaulicht, um Daten an das OPC-UA-Protokoll anzupassen, das mit dem selbstbeschreibenden Nachrichtenprotokoll verwendet werden kann, das vom Steuersystem der 1 und 2 verwendet wird.
    • 12 ist ein Benutzeroberflächendiagramm einer exemplarischen Konfigurationshierarchie des Satzes von Steuerknoten, die eine herkömmliche Steuerung und eine virtuelle Steuerung beinhaltet, die einem erweiterten Funktionsknoten des Steuersystems der 1 und 2 zugeordnet sind.
    • 13 veranschaulicht ein Beispiel eines Modbus-Subnetzes, das mit einer virtuellen Ethernet-BFN-Modbus-Steuerung in einem erweiterten Funktionsknoten von 2 gekoppelt werden kann.
  • DETAILLIERTE BESCHREIBUNG
  • 1 ist ein Blockdiagramm einer exemplarischen Architektur eines industriellen Steuerungssystems 10, wie beispielsweise eines in einer Prozessanlage verwendeten Prozessleitsystems. Das exemplarische industrielle Steuerungssystem 10 (im Folgenden auch als Prozessleitsystem 10 bezeichnet) beinhaltet eine oder mehrere Ein-/Ausgabe-(I/O)-Steuerungen oder Vorrichtungen 12, die über ein Netzwerk 16 mit einem oder mehreren erweiterten Funktionsknoten 14 gekoppelt sind. In diesem Fall wird das Netzwerk 16 als Ethernet-Netzwerk mit einem Switch 18 dargestellt, aber das Netzwerk 16 könnte auch andere Arten von Netzwerken sein, einschließlich aller offenen Protokollnetzwerke, wie beispielsweise jedes paketbasierte Netzwerk, wie jedes IP-Netzwerk (z. B. jedes Netzwerk, das ein TCP/IP-Protokoll verwendet). Wie in 1 dargestellt, beinhaltet das Prozessleittechnik-Netzwerk 10 verschiedene andere Rechenknoten 20, die kommunikativ mit dem Netzwerk 16-Bus verbunden sind. Die Rechenknoten 20 können beispielsweise Betreiber- oder Benutzerarbeitsplatzknoten (22, 24), einen Konfigurationsknoten 26, einen oder mehrere Datenhistoriker oder Datenbankknoten 28 und alle anderen Knoten beinhalten, die typische Hardwarevorrichtungen implementieren, die in Prozessregelungsanlagen oder - systemen verwendet werden.
  • Im Allgemeinen ist jede der BFN-I/O-Steuerungen 12 eine Rechenplattform, die das Prozessleitsystem 10 und insbesondere die erweiterten Funktionsknoten 14 mit verschiedenen Feldgeräten in der zu steuernden Anlage verbindet, wie beispielsweise Sensoren, Ventile und andere Mess- und Regelgeräte. Jeder der BFN-I/O-Steuerungen 12 beinhaltet einen Frontend-Prozessor oder eine schnelle Steuerung, die mit einem oder mehreren I/O-Subnetzen oder -Geräten gekoppelt ist, die herkömmliche I/O-Subnetze einschließlich I/O-Geräten wie HART, Foundation Fieldbus, CAN, Profibus, WirelessHART I/O-Geräte usw. sein können. Die I/O-Geräte sind natürlich mit I/O-Kanälen oder -Bussen gekoppelt, die mit verschiedenen Feldgeräten in der Anlage zum Zwecke der Datenerfassung und -steuerung verbunden sind, d. h. um Gerätesignale von den Feldgeräten zu empfangen und diese Gerätesignale zu verarbeiten, um die Signale zu interpretieren, Datenprotokollkonvertierungen oder Protokolltunnelungen an den Signalen durchzuführen usw. Darüber hinaus können die BFN-I/O-Steuerungen 12 direkt mit Feldgeräten über eine beliebige Kommunikationsprotokollstruktur gekoppelt werden, wie beispielsweise HART, WirelessHART, Foundation Fieldbus, 4-20 Milliampere, CAN, Profibus oder andere bekannte Protokolle. Die BFN-I/O-Steuerungen 12 enthalten eine physikalische Komponente, die Kommunikationsverbindungen (die logisch konfigurierbare Verbindungen sein können) zu verschiedener Hardware, z. B. Feldgeräten, innerhalb einer zu steuernden Anlage oder eines Systems bereitstellt, und eine logische Komponente, die Kommunikationsaktivitäten zwischen dem Netzwerk 16 und den Teilnetzen durchführen kann und die in einigen Fällen Steueraktivitäten, wie beispielsweise schnelle Steueraktivitäten, durchführen kann. Die physikalischen und logischen Komponenten einer bestimmten BFN-I/O-Steuerung 12 sind jedoch im Allgemeinen eng miteinander gekoppelt, um aus Sicht des Netzwerks 16 einen einzigen Knoten zu bilden. Im Allgemeinen kann jede BFN-I/O-Steuerung 12 proprietär sein und von einem anderen Hersteller bereitgestellt werden, aber diese Vorrichtungen 12 führen die Kommunikation in der unten beschriebenen Weise durch, um eine vernetzte Kommunikation mit verschiedenen Arten von I/O-Vorrichtungen (auch mit proprietären Vorrichtungen) zu ermöglichen und gleichzeitig das Zusammenwirken der BFN-I/O-Steuerungen 12 im gleichen Prozesssteuerungsnetz zu ermöglichen. Ebenso können die Ein-/Ausgabevorrichtungen in den Knoten 12, wie verstanden, Steuersignale von einer oder mehreren Steuerungen, z. B. den nachfolgend beschriebenen virtuellen Steuerungen, empfangen und diese Steuersignale verarbeiten (z. B. um diese Steuersignale in Signalformate umzuwandeln oder zu verpacken, die an die Feldgeräte gesendet werden können) und die verarbeiteten Steuersignale über die Ein-/Ausgabeleitungen an die Feldgeräte zur Steuerung der Feldgeräte und damit der Anlage weiterleiten.
  • Die erweiterten Funktionsknoten 14 können verallgemeinerte Computer-Verarbeitungshardware oder Banken von Verarbeitungshardware beinhalten, wie beispielsweise einen oder mehrere Server in einer Serverfarm an jedem Knoten 14. Im Allgemeinen haben die erweiterten Funktionsknoten 14 eine Kommunikationsschnittstelle zum Netzwerk 16, ein Hauptsteuerprogramm und verschiedene virtuelle Geräte oder Dienste, die in der Hardware des Knotens ausgeführt werden, um Steuerungs- und andere Funktionen wie Datenanalyse, Konfigurationsfunktionen, Wartungsfunktionen, Datenspeicherfunktionen usw. auszuführen. Das Hauptsteuerprogramm (im Folgenden auch Hypervisor genannt) kann den Betrieb der verschiedenen anderen virtuellen oder logischen Vorrichtungen koordinieren, einschließlich verschiedener virtueller Steuerungen, virtueller Ethernet-BFNs, Datenübersetzungsdienste, Kommunikationsdienste usw., die innerhalb eines erweiterten Funktionsknotens 14 betrieben werden. Das Hauptsteuerprogramm kann auch die anderen logischen oder virtuellen Geräte innerhalb der Hardware des erweiterten Funktionsknotens 12 verschieben oder aktiv planen, um Lastausgleichs- und Redundanzdienste innerhalb eines bestimmten erweiterten Funktionsknotens 12 bereitzustellen.
  • Darüber hinaus können die verschiedenen anderen Rechenknoten 20 mit dem Netzwerk 16 und insbesondere mit den BFN-I/O-Steuerungen 12 und den erweiterten Funktionsknoten 14 verbunden werden, um andere Kontrollaktivitäten wie Benutzeroberflächenaktivitäten, Netzwerk- und Prozessleitsystemkonfigurationsaktivitäten, Datenerfassungs- und Speicheraktivitäten, Datenanalyse usw. durchzuführen. In vielen Fällen können die anderen Rechenknoten 20 jedoch Thin Client-Geräte beinhalten oder ausführen, die mit virtuellen Geräten oder Entitäten innerhalb der anderen Knoten, insbesondere innerhalb der erweiterten Funktionsknoten 14, verbunden sind, um Benutzern Informationen zur Verfügung zu stellen und es Benutzern zu ermöglichen, mit Steuerungs-, Wartungs-, Datenanalyse-, Alarm- und anderen Funktionen, die innerhalb virtueller Geräte in den erweiterten Funktionsknoten 14 ausgeführt werden, zu kommunizieren.
  • 2 veranschaulicht genauer eine der BFN-I/O-Steuerungen 12 und einen der erweiterten Funktionsknoten 14, die über den Switch 18 des Netzwerks 16 verbunden sind. Wie in 2 dargestellt, beinhaltet die BFN-I/O-Steuerung 12 eine logische Komponente 30 (die Softwareroutinen und Module beinhaltet, die auf einem Prozessor innerhalb der BFN-I/O-Steuerung 12 ausgeführt werden) und eine physikalische Komponente 32, die einen oder mehrere Prozessoren 34 (die Universalprozessoren, ACICs, programmierbare Logik-Arrays, reprogrammierbare Gate-Arrays, programmierbare Logik-Steuerungen (PLCs) usw. sein können) und verschiedene physikalische I/O-Stecker 36 zum Anschluss der BFN-I/O-Steuerungen 12 an Feldgeräte oder andere Vorrichtungen innerhalb der zu steuernden Anlage oder Anlage beinhaltet. Die physischen I/O-Steckverbinder 36 können beliebige Arten von I/O-Steckverbindern sein, einschließlich Standard 4-20-mA-Steckverbinder, busbasierte Steckverbinder wie Feldbus-, CAN-, Profibus- usw. Steckverbinder, Kanalverbinder wie HART-Steckverbinder, Wireless-Steckverbinder wie WirelessHART-Steckverbinder, IEEE Wireless-Protokollstecker usw. In einem Fall kann die I/O-Steckverbinder-Hardware 36 umprogrammierbare oder digital konfigurierbare Steckverbinder beinhalten, die es ermöglichen, Adress- oder Tag-Verbindungen der Feldgeräte und anderer Hardware innerhalb der Anlage nach dem Herstellen der Verbindungen zu konfigurieren oder festzulegen. Beispiele für eine solche konfigurierbare Verbindungs-I/O-Struktur sind in den U.S.-Patenten mit den Nummern 7,684,875; 8,332,567; 8,762,618; 8,977,851; 9,083,548; 9,411,769; und 9,495,313 sowie in der U.S.-Patentantragsveröffentlichung Nr. 2016/0226162 beschrieben, die hierin ausdrücklich durch Bezugnahme aufgenommen werden und hierin als CHARMs I/O bezeichnet werden.
  • Ebenso kann die logische Komponente 30 der I/O-Steuerung 12, wie in 2 dargestellt, verschiedene Dienstanwendungen beinhalten, wie beispielsweise eine Kommunikationsanwendung (Comms), die die Kommunikation über das Netzwerk 16 durchführt, eine Steueranwendung, die in der I/O-Steuerung 12 gespeicherte Steuermodule implementieren oder ausführen kann, um beispielsweise eine schnelle Steuerung innerhalb der BFN-I/O-Steuerung 12 durchzuführen, und eine I/O-Anwendung, die die Kommunikation mit den Teilnetzen (z. B. Feldgeräten) über die physikalischen I/O-Komponenten 32 oder 36 durchführt. Wie auch in 2 dargestellt, kann die logische Komponente 30 ein oder mehrere Steuermodule 38 beinhalten oder speichern, die beispielsweise Eingangssteuermodule (z. B. Funktionsblöcke), Ausgangssteuermodule (z. B. Funktionsblöcke), Steuerberechnungsmodule oder Blöcke, wie Proportional-Integral-Derivat (PID) oder Modellprädiktive Regelung (MPC) Blöcke, Alarmblöcke usw. sein können. Im Allgemeinen bedient oder führt die BFN I/O-Steuerung 12 Steuermodule oder Blöcke darin aus, um eine schnelle Steuerung durchzuführen (z. B. bei 10 Millisekunden Zykluszeit).
  • Wie in dargestellt, kann der erweiterte Funktionsknoten 14 eine Vielzahl verschiedener Hardwaregeräte enthalten, z. B. Server in einer Serverfarm, Prozessoren und Speicher auf separaten Motherboards usw., wobei jeder Server oder jede Prozessorkomponente als z. B. ein anderes Blade oder Hardwaregerät in einem Serverschrank konfiguriert ist. Der erweiterte Funktionsknoten 14 beinhaltet ein Hauptsteuerprogramm oder Hypervisor 50, das/der den Betrieb der verschiedenen anderen virtuellen Vorrichtungen oder Einheiten innerhalb des Knotens 14 steuert und überwacht, wie er auf den verschiedenen Hardwarevorrichtungen konfiguriert oder ausgeführt wird, und die Hardwareaufsicht am Knoten übernimmt. Der erweiterte Funktionsknoten 14 kann beispielsweise ein oder mehrere Betriebssysteme beinhalten, wie beispielsweise das Windows®-Betriebssystem (OS), das als Basis-Betriebssystem auf einem oder mehreren Prozessoren des Knotens 14 läuft. Ebenso kann der erweiterte Funktionsknoten 14 eine beliebige Anzahl virtueller Maschinen, Geräte oder Entitäten enthalten. Wie beispielsweise in 2 dargestellt, beinhaltet der erweiterte Funktionsknoten 14 einen oder mehrere virtuelle Steuerungen 52, die als herkömmliche Steuerungen in Prozessanlagen nachahmen oder als solche arbeiten können, um Kontrollaktivitäten durchzuführen. Jede der virtuellen Steuerungen 52 kann verschiedene Steuermodule, Funktionsblöcke, Alarmmodule, Kommunikationsmodule, Benutzerschnittstellenmodule usw. beinhalten, wie es bei standardmäßig verteilten Steuerungen üblich ist, und diese Steuermodule oder andere Strukturen innerhalb der virtuellen Steuerungen 52 können Steuersignale (jeglicher Art) erzeugen, die über das Kommunikationsnetz 16 an den Knoten 12 zur Verarbeitung und Lieferung an die Feldgeräte gesendet werden. In diesem Fall laufen die virtuellen Steuerungen 52 jedoch unabhängig voneinander und von den anderen virtuellen Vorrichtungen oder Entitäten innerhalb des erweiterten Funktionsknotens 14 und können auf verschiedenen Prozessor- oder Serverhardwarevorrichtungen im Knoten 14 laufen oder ausgeführt werden und unabhängig von einer oder mehreren der BFN-I/O-Steuerungen 12 über das Netzwerk 16 ausgeführt werden und mit diesen kommunizieren, um Steuerungen durchzuführen, z. B. um Sensormessungen zu erhalten, Steuersignale zu erzeugen und an Feldgeräte zu senden, um Alarme, Warnungen und andere Nachrichten von den Feldgeräten oder von den Bedienoberflächen 22, 24 zu erzeugen und zu senden oder zu verarbeiten, um eine Überwachungssteuerung durchzuführen usw.
  • Ebenso kann der erweiterte Funktionsknoten 14, wie in 2 dargestellt, eine oder mehrere virtuelle Ethernet-BFN-Steuerungen oder -Vorrichtungen 54 beinhalten, die eine Steuerung durchführen können oder die Steuerungsaktivitäten für andere verteilte Steuerungs-Subnetze verfolgen können, die über die Ethernet-Netzwerkverbindung 16 mit dem Knoten 14 gekoppelt sind. Solche Teilnetze können beispielsweise Modbus-Netze umfassen. Wie in 2 dargestellt, können die virtuellen Steuerungen 52 und die Ethernet-BFN-Steuerung 54 auf demselben oder auf getrennten oder unterschiedlichen Betriebssystemen laufen oder ausgeführt werden.
  • Wie in 2 dargestellt, kann der erweiterte Funktionsknoten 14 noch eine weitere virtuelle Datenspeichermaschine 62 beinhalten, die Prozess- und/oder andere Daten von den virtuellen Steuerungen 52, 50 und den BFN-I/O-Steuerungen 12 und Subnetzen, an die sie angeschlossen sind, sammeln, organisieren und speichern kann. Falls gewünscht, kann die virtuelle Datenspeichermaschine 62 eine virtuelle Großdatenanwendung oder eine andere Art von Datenspeichermaschine sein. Darüber hinaus kann der erweiterte Funktionsknoten 14 eine oder mehrere virtuelle Datenanalysevorrichtungen 64 beinhalten, die Datenanalysen durchführen können, z. B. unter Verwendung der von der virtuellen Datenspeichervorrichtung 62, den virtuellen Steuerungen 52, 50, den BFN -I/O-Steuerungen 12 usw. gesammelten Daten oder anderer Daten. Auch hier kann jede der virtuellen Maschinen auf der gleichen oder anderen allgemeinen Verarbeitungshardware innerhalb des Knotens 16 implementiert werden, z. B. auf jedem allgemeinen Prozessor und Speicher, der mit einer der verschiedenen Hardwarevorrichtungen (z. B. Servern oder Motherboards) verbunden ist.
  • Darüber hinaus kann der erweiterte Funktionsknoten 14 eine virtuelle OPC-UA-Vorrichtung 68 beinhalten, die die OPC-Verarbeitung und -Konvertierung von Daten innerhalb des Netzwerks 16 durchführt, um die Zusammenarbeit oder Interpretation von Daten aus verschiedenen Quellen oder von Geräten verschiedener Hersteller zu ermöglichen. Der erweiterte Funktionsknoten 14 kann auch eine oder mehrere virtuelle Konfigurationen, virtuelle Bedienoberflächen, virtuelle Steuerungsschnittstellen, Anwendungen für virtuelle Wartungsschnittstellen usw. beinhalten. 70. Die virtuellen Vorrichtungen 70 können Standard-Bedienerführungstätigkeiten (einschließlich Benutzeranmeldung), Konfigurationsaktivitäten (einschließlich Benutzeranmeldung), Wartungsaktivitäten (einschließlich Benutzeranmeldung), Alarmverarbeitungs- und Anzeigeaktivitäten usw. durchführen, und diese virtuellen Vorrichtungen 70 können mit den Benutzerarbeitsplätzen oder Thin Clients 22, 24, 26 usw. über das Netzwerk 16 und die Schnittstelle mit Benutzern in der Anlage oder im System 10 verbunden werden.
  • Darüber hinaus kann der erweiterte Funktionsknoten 14 einen BFN-Steuerungsübersetzungsdienst oder eine Maschine 74 beinhalten. Im Allgemeinen führt der Steuerungsübersetzungsdienst oder die Maschine 74 Datenübersetzungsdienste für Daten durch, die zwischen beispielsweise den BFN-I/O-Steuerungen 12 und den virtuellen Steuerungen 52 im erweiterten Funktionsknoten 14 fließen. Wie im Folgenden näher erläutert wird, ermöglichen diese Datenübersetzungsdienste 70 die protokollunabhängige Kommunikation über das Netzwerk 16, d. h. die Übersetzungsdienste 70 ermöglichen verschiedenen Geräte, virtuellen Geräten, logischen Entitäten und virtuelle Entitäten innerhalb des Steuerungssystems 10, jedes Kommunikationsprotokoll und jedes gewünschte Datenformat zu verwenden und dennoch Kommunikation über das Netzwerk 16 durchzuführen. Diese Eigenschaft ermöglicht es auch, dass das Steuerungssystem 10 eine offene Architektur im Sinne der Wahl der Kommunikationsprotokolle und Datenformate ist, die bei der Kommunikation zwischen den BFN-I/O-Steuerungen 12 und den erweiterten Funktionsknoten 14 verwendet werden.
  • Wie man versteht, kann jede der virtuellen Maschinen oder Geräte innerhalb des Knotens 14 ein eigenes (und ein anderes) Betriebssystem haben und somit unabhängig von den anderen virtuellen Geräten laufen. Darüber hinaus müssen das Design und die Konfiguration der verschiedenen virtuellen Maschinen innerhalb des erweiterten Funktionsknotens 14 nicht aufeinander abgestimmt werden und können daher von verschiedenen Herstellern bereitgestellt werden, was das Design des Knotens 14 zu einer offenen Architektur macht. Darüber hinaus kann jede(s) der virtuellen Geräte oder Entitäten innerhalb eines einzelnen erweiterten Funktionsknotens 14 auf demselben oder einem anderen physikalischen Server oder Verarbeitungsgerät innerhalb des Knotens 14 ausgeführt werden und (z. B. durch den Hypervisor 50) zwischen physikalische Hardware oder Verarbeitungsgeräte innerhalb des Knotens 14, ohne dass die anderen virtuellen Geräte oder der Knoten 14 selbst neu konfiguriert werden müssen, und mit nur begrenzten oder minimalen Ausfallzeiten für das virtuelle Gerät, das verschoben wird. Diese Funktion ermöglicht es dem Hypervisor 50, virtuelle Geräte zwischen physikalischer Hardware oder Servern am Knoten 14 zu verschieben, um Lasten am Knoten 14 auszugleichen, Redundanz-Neukonfigurationen oder -umschaltungen durchzuführen, falls eines der Hardwaregeräte ausfällt, um temporäre hohe Lastverarbeitung durch ein bestimmtes virtuelles Gerät, ohne den Betrieb anderer virtueller Geräte am Knoten 14 usw. erheblich zu belasten.
  • So beinhaltet das neue industrielle Steuerungssystem mit offener Architektur der 1 und 2 eine verteilte Architektur, in der eine oder mehrere Ein-/Ausgabe-(I/O)-Steuerungen oder -Vorrichtungen 12 mit Grundfunktionsknoten (BFN) und eine oder mehrere Steuerungsüberwachungen oder erweiterte Funktionsknoten 14 über ein Netzwerk 16 gekoppelt sind und jede eine Reihe von Funktionen unterstützen kann, einschließlich I/O-Dienste, Gerätedienste, Steuerdienste und allgemeine Dienste. Das System 10 enthält eine Kombination aus Hard- und Software, wobei die Hardware für den BFN I/O Steuerung 12 einen konfigurierbaren Intelligent Logic Solver (CSLS), einen konfigurierbaren I/O-Träger, verschiedene konfigurierbare I/O-Module sowie unterstützende Kabel und Stromversorgungen beinhaltet. Das System 10 beinhaltet auch die Überwachungssteuerung 14, die verwendet wird, um eine offene Systemschnittstelle (z. B. OPC-UA) 68, eine Steuerungs-Übersetzungsschicht 70 und andere Funktionen bereitzustellen. Der Überwachungssteuerungsknoten 14 und andere Teile des Systems 10 können als Teil des konfigurierbaren virtuellen Systems virtualisiert und gebündelt oder als eigenständige Hardware installiert und ausgeführt werden.
  • Es versteht sich, dass die Grundfunktionsknoten 12 in der einfachsten Form, mit einem einzigen Gerät oder sogar mit einer einzigen Messung verwendet werden können, so dass die Grundfunktionsknoten 12 nicht in allen Fällen I/O bündeln müssen. Darüber hinaus können die Grundfunktions-Knoten 12 auch Übersetzungsdienste für andere Geräte bereitstellen, z. B. für Ethernet-IP-Geräte, wenn diese Geräte keine offenen Protokolle unterstützen. Als weitere Beispiele könnten die Grundfunktionsknoten 12 Übersetzungsdienste für andere Geräte wie Waagen, NIR-Geräte, Messsysteme usw. bereitstellen.
  • Darüber hinaus könnte die hierin beschriebene Steuerungssystemarchitektur erweitert werden, so dass I/O-Geräte oder die eigentliche Prozesssteuerung oder andere Geräte, wie beispielsweise Feldgeräte, direkt mit dem Netzwerk 16 verbunden werden können, anstatt sich über einen Grundfunktionsknoten 12 zu verbinden. In diesem Fall würden die Vorrichtungen (z. B. Feldgeräte) die Kommunikation mit dem Netzwerkprotokoll unterstützen und eine oder mehrere, aber vielleicht nur eine kleine Anzahl von Routinen (die wie unten beschrieben Aktoren sein könnten) beinhalten, die für die Kommunikation, Datenmanipulationen und spezifische Funktionen wie eine Ventildiagnose verwendet werden können.
  • Die Steuerungsarchitektur von 1 und 2 ist so konzipiert, dass Anwendungen auf jedem Rechen- oder Prozessorknoten des Netzwerks 16 innerhalb des Anlagensteuerungssystems 10 installiert werden können. Diese Anwendungen können zwischen den Knoten verteilt oder in einigen Fällen zwischen den Rechenknoten verschoben werden, als Reaktion auf Anforderungen und Störungen beim Laden des Systems. Die Fähigkeit, Anwendungen unabhängig voneinander zu migrieren und zu aktualisieren, ermöglicht es dem Gesamtsystem 10, sehr signifikante Skalierungs- und Betriebszeitstatistiken zu erhalten. Diese Funktion kann als reaktiv bezeichnet werden und kann auf verschiedenen reaktiven Architekturen wie Erlang und zuletzt Akka und Akka.Net basieren.
  • Die neue offene Architektur kann auch die Verwendung selbstbeschreibender datengesteuerter Systeme oder Datennachrichten umfassen. Mit einem selbstbeschreibenden Nachrichtenansatz können sowohl die Daten als auch die Datenbeschreibungen als Teil jeder Komponente (physikalische und/oder logische oder virtuelle Komponente) im System 10 gespeichert werden, und sowohl die Daten als auch die Datenbeschreibungen können als Teil des Verbindungsaufbaus zwischen den Endpunkten jeder Datenkommunikation übermittelt werden.
  • Die neue offene Architektur beinhaltet auch Redundanz auf Hardware-, Anwendungs- und Funktionsebene. Auf Hardwareebene können Daten zwischen Systemen repliziert werden, und wenn ein Hardwareausfall erkannt wird, können ganze Anwendungen oder virtuelle Maschinen automatisch auf andere Hardwareplattformen (z. B. durch den Hypervisor 50 initiiert) umsteigen, ohne oder mit geringem Zeit- oder Datenverlust. Auf Anwendungsebene können Anwendungen auf verschiedenen Rechenknoten oder auf verschiedenen Servern oder physikalischen Verarbeitungsmaschinen innerhalb eines Knotens repliziert werden (wiederum auf Initiative des Hypervisors 50) und zwischen Geräten oder Knoten ohne Verlust von Verbindungen migriert werden. Auf der Feature-Ebene können Features wie Messungen mit anderen Messungen oder im allgemeineren Fall mit weichen Sensoren gesichert werden. Das System 10 kann auch eine Messabstimmung als Teil der grundlegenden Architektur des Steuerungssystems durchführen.
  • Noch weiter kann die neue offene Architektur datengesteuerte Schnittstellen enthalten. Mit datengesteuerten Schnittstellen sind die Endpunkte in der Lage, die Komponenten nach den für sie interessanten Daten abzufragen, ohne die Details der Implementierung kennen zu müssen. Um dies noch weiter zu vertiefen, können abfragegesteuerte und funktionale Schnittstellen verwendet werden, um auf Daten über physikalisch getrennte Subsysteme zuzugreifen. Ebenso können, wie bereits erwähnt, in dieser Steuerungssystemarchitektur Hardware-Computing-Ressourcen gebündelt und virtualisiert werden, um sehr skalierbare Hardwareplattformen bereitzustellen, und diese Virtualisierungssysteme können Technologien wie Docker verwenden, um Applets zu installieren und auszuführen.
  • Darüber hinaus ist die offene Systemarchitektur so konzipiert, dass Anwendungen auf jedem Rechenknoten im System 10 installiert werden können. Diese Anwendungen können somit auf die Knoten 12 und 14 verteilt oder in einigen Fällen zwischen den Knoten 12 und 14 verschoben werden, z. B. als Reaktion auf Systemlast und Störungen. Die Fähigkeit, Anwendungen einfach zu migrieren und unabhängig voneinander zu aktualisieren, ermöglicht es dem Gesamtsystem 10, sehr signifikante Skalierungs- und Verfügbarkeitsstatistiken zu erhalten.
  • Im Hintergrund wurde die Industrie der verteilten Steuerungssysteme (DCS) durch den Aufstieg des Mikrocontrollers weitgehend ermöglicht. Im Rahmen der frühen DCS-Architekturen wurden Bediener-, Steuerungs- und I/O-Funktionen in spezialisierte Rechenplattformen aufgeteilt und über eine proprietäre und redundante Netzwerktechnologie verteilt. Systeme der nächsten Generation, wie das DeltaV™-System von Emerson Automation Solutions, haben diese Konzepte erweitert, indem sie sowohl Steuerungsfunktionen auf fast jedem Knoten ausführen als auch die Rechenleistung an jedem Punkt des Systems nutzen können, zuletzt am I/O selbst im Sinne der CHARMS™-Technologie. DeltaV umfasste auch IT-basierte Technologie wie Ethernet, Switches, TCP/UDP/IP und gängige Betriebssysteme wie Windows und Linux. Obwohl Systeme wie DeltaV es ermöglichen, die Steuerung überall auszuführen, setzen die Architekturen dennoch Funktionen durch, die auf bestimmten Rechenboxen oder Maschinen ausgeführt werden.
  • Um sehr hohe Betriebszeiten und Support-Ausfallszenarien zu erreichen und Online-Upgrade-Szenarien bereitzustellen, bieten Steuerarchitekturen typischerweise Netzwerkredundanz, Steuerungsredundanz, I/O-Redundanz und Applikationsstationsredundanz auf hardware-spezifischer Basis. Obwohl diese Redundanz ihre Ziele weitgehend erreicht hat, erschwert sie die Skalierung von Steuerungsanwendungen. Insbesondere müssen Steuerungsanwendungen manuell neu zugeordnet und installiert oder in das System „heruntergeladen“ werden. Darüber hinaus hat der Anstieg von Fernüberwachung, Fehlererkennung und anderen Anwendungen die Belastung dieser DCS-Architekturen weiter erhöht. Viele dieser Anforderungen werden durch die sogenannten IoT- oder IIoT-Anforderungen bestimmt.
  • Die Antwort auf einige dieser Probleme, wie sie in dem hierin beschriebenen System verwendet werden, ist zum Teil der Einsatz von Multi-Core-Prozessoren, die Verwendung der neuen Netzwerk-Nachrichten-Passaging-Technologie, wie Time-Sensitive Networks (TSNs), programmierbare Plattformen wie FPGAs, datengesteuerte Techniken und nachrichtengesteuerte Systeme. Eine Möglichkeit, Multi-Core-Plattformen zu nutzen, war die Virtualisierung und zuletzt die containerbasierte Virtualisierung wie Docker. Virtualisierung und containerbasierte Virtualisierung wurde in vielen Branchen übernommen. Ein wichtiger Ansatz, der im Steuerungssystem der offenen Architektur der und verwendet werden kann, ist jedoch eine aktorbasierte Methode (dies ist ein gängiger Begriff in der Informatikindustrie). Dieser aktorbasierte Ansatz macht das System 10 reaktiver, und die Entwicklung reaktiver Anwendungen stellt einen signifikanten Paradigmenwechsel dar.
  • Im Allgemeinen sind die Prinzipien eines reaktiven Systems darauf ausgelegt, ein System zu erreichen, das reaktionsschneller, widerstandsfähiger und elastischer ist, insbesondere durch den Einsatz von Nachrichtenverarbeitung. Insbesondere ist ein reaktionsschnelles System in der Lage, so schnell wie möglich auf Änderungen bei Rechenanforderungen, Ausfällen und Benutzeranfragen zu reagieren, was sicherstellt, dass die Anwendungen und Benutzer nicht viel Zeit damit verbringen, untätig auf die Ausführung von Operationen zu warten. Damit eine Anwendung beispielsweise reagieren kann, muss sie auf einen erhöhten Nutzungsanstieg reagieren können. Diese Spitzen können durch eine Benutzeranfrage zur Durchführung einer Form der Anomalieerkennung oder durch etwas so Einfaches oder Gewöhnliches wie das Aufrufen einer Reihe von Dashboards (Benutzeroberflächen) ausgelöst werden, die Daten aus dem gesamten System anzeigen. Für den Fall, dass sich die Verwendung der Anwendung verdoppelt, sollte sich auch die Antwortzeit der Anwendung nicht verdoppeln. Der einfachste Weg, die Reaktionsfähigkeit zu verwalten, ist die Schaffung eines Systems, das eine einfache Skalierbarkeit ermöglicht, um auf diesen erhöhten Verarbeitungsdruck zu reagieren. Die Bereitstellung einer Anwendungsverarbeitung, bei der die Anzahl der Instanzen eines Dienstes auf- und abgebaut werden kann, ohne die Prozessorressourcen im Falle einer erhöhten Anwendungslast zu überlasten, ermöglicht es Anwendungen, leicht auf diese und den erhöhten Verarbeitungsbedarf zu reagieren. Das hierin beschriebene System ermöglicht diese einfache Skalierung basierend auf der Virtualisierung und den im System 10 verwendeten Nachrichtenübermittlungsschemata.
  • Damit eine Anwendung nutzbar ist, muss sie außerdem einem breiten Spektrum von Bedingungen standhalten, denen sie ausgesetzt sein kann, und als solche sollte sie widerstandsfähig sein. Anwendungen sollten widerstandsfähig gegen Probleme sein, die von Benutzern aufgrund einer erhöhten Last verursacht werden, sowie gegen Probleme, die aus der Anwendung heraus entstehen. So sind beispielsweise Fehler ein häufiger Aspekt fast aller Anwendungen, insbesondere aufgrund der Vielzahl von Datenquellen, die zu leistungsfähigeren Anwendungen kombiniert werden. Es besteht immer die Möglichkeit, dass einer dieser externen Dienste ausfällt, und deshalb ist es wichtig zu überlegen, was passiert, wenn eine Anwendung auf einen Fehler stößt. Um widerstandsfähige Anwendungen zu gewährleisten, müssen die Anwendungen in der Lage sein, auf Fehlerquellen zu reagieren oder resistent zu sein.
  • Ebenso wichtig ist es, darüber nachzudenken, wie Systeme bei potenziellen Sicherheitsproblemen, wie z. B. mangelnder Berechtigung, funktionieren. Wenn Benutzer ihre Aufträge mit immer mehr Diensten integrieren möchten, muss die Systemarchitektur in der Lage sein, Fehler in diesen Drittsystemen zu behandeln. Generell ist es wichtig, dass im Falle eines Ausfalls nicht das gesamte System um seine Bewältigung kämpft, oder noch schlimmer, dass das gesamte System aufgrund eines einzelnen Komponentenausfalls ausfällt. Im Idealfall ist es wünschenswert, Ausfälle bis auf die kleinstmögliche Einheit zu isolieren und Fehler innerhalb dieser Einheit allein einzukapseln. Dieses Designziel trägt dazu bei, dass eine Anwendung auch bei widrigen Umständen bestehen kann. Im Falle eines Fehlers ist es nicht wünschenswert, die internen Details eines Fehlers einem Benutzer aufzudrängen, sondern es ist wünschenswert, dem Benutzer einige Details zur Verfügung zu stellen, die für den Benutzer von Bedeutung sind. Im Idealfall sollte das System 10 in der Lage sein, Probleme automatisch zu lösen und Anwendungen die Selbstheilung zu ermöglichen. Skalierbarkeit und Ausfallsicherheit teilen also beide eine starke Verbindung, und für den Fall, dass eine Anwendung mit Blick auf die Skalierbarkeit erstellt wird, ist die Anwendung besser in der Lage, Fehler zu bewältigen. Das Gegenteil dieser Aussage ist auch der Fall, denn wenn eine Anwendung mit Blick auf die Belastbarkeit erstellt wird, dann kann die Anwendung mit einer erhöhten Last umgehen.
  • Um ein reaktives System und insbesondere reaktive Anwendungen innerhalb des Steuerungssystems der 1 und 2 vorzusehen, kann das System 10 ein bestimmtes Nachrichtenübermittlungsprotokoll oder eine bestimmte Architektur verwenden, die sich auf unidirektionalen Nachrichtenaustausch zwischen Anwendungen oder Einheiten im System und die Verwendung von selbstbeschreibenden Datenprotokollen für den Nachrichtenaustausch stützt. Die Architektur des Nachrichtendurchlaufs kann in Form von asynchroner Kommunikation erfolgen, bei der Daten in die Warteschlange gestellt werden, die ein Mitarbeiter zu einem späteren Zeitpunkt verarbeiten kann, etwa wie nach dem Prinzip „Abfeuern und Vergessen“. Die Verwendung einer solchen unidirektionalen Nachrichtenübergabearchitektur bietet eine Reihe wertvoller Bausteine, auf denen Anwendungen erstellt werden können, die belastbar, skalierbar und reaktionsschnell sind. Insbesondere die Verwendung einer unidirektionalen Nachrichtenübermittlungsarchitektur bietet eine Isolierung zwischen Komponenten (Anwendungen, Vorrichtungen usw.) Sobald die Isolierung erreicht ist, ist es möglich, die verschiedenen Aufgaben, die an dem idealsten (Hardware-)Ort ausgeführt werden müssen, abhängig von Faktoren wie verfügbarer CPU-Leistung, verfügbarem Speicher, dem Ausfallrisiko usw. einzusetzen. Die Isolation ist eine Schlüsselkomponente für die Ausfallsicherheit, denn im Falle eines Ausfalls einer einzelnen Komponente ist es möglich, dass der Rest des Systems ohne Ausfall arbeitet. Die Isolation ermöglicht es der fehlerhaften Komponente auch, sich im Laufe der Zeit selbst zu heilen, indem sie sich entweder von einem abhängigen Dienst zurückzieht, der Probleme verursacht, oder indem sie neu startet, um ihren Zustand zurückzusetzen.
  • Darüber hinaus bietet die Verwendung eines unidirektionalen Nachrichtenübermittlungsschemas eine Standorttragfähigkeit. Insbesondere erfordert die unidirektionale Nachrichtenübermittlung nur, dass der Absender eine Adresse des Empfängers angibt, um die Nachricht zu senden. Der Sender muss nicht den tatsächlichen Standort (in der Hardware) des Empfängers kennen, so dass sich der Empfänger an beliebiger Stelle im Steuerungssystem befinden und ohne Wissen des Senders bewegt werden kann. Insbesondere wenn der Sender eine Nachricht mit einer Adresse des Empfängers sendet, befasst sich das Framework mit den Feinheiten der Weiterleitung der Nachricht an den physischen Standort des Dienstes oder Empfängers innerhalb eines Clusters oder einer Gruppe von Knoten, unabhängig davon, ob sich dieser Dienst auf derselben Maschine, auf einem Server im selben Knoten oder auf einem Server in einer völlig anderen Rechenplattform befindet. Diese Funktion ermöglicht es dem Framework, den Speicherort einer laufenden Aufgabe dynamisch neu zu konfigurieren, ohne die Anwendung auf diese Änderung aufmerksam machen zu müssen, was eine einfachere Skalierung ermöglicht. Bei einem Systemausfall ist es durchaus möglich, dass das Framework einen Dienst an einen neuen Standort verlagert, was wiederum zu einer Forderung nach Standorttransparenz führt.
  • Die Nachrichtenübermittlung kann auch vorteilhaft durch die Verwendung von aktorbasierter Parallelität erfolgen. Beispiele für diese Methode umfassen Erlang und Akka. Beide Techniken implementieren das Aktormodell, das das System in unabhängige Aktoren aufteilt. Ein Aktor innerhalb des Aktormodells umfasst drei Schlüsselkonzepte: Speicherung, Verarbeitung und Kommunikation. Aktoren sind nicht blockierend und asynchron.
  • Ein DCS ist eine datenintensive Architektur. Infolgedessen werden sehr große Mengen an Echtzeitdaten aus Messgeräten extrahiert, und diese Daten werden verwendet, um Entscheidungen auf Steuer-, Benutzer- und Unternehmensebene voranzutreiben. Eine reaktive Anwendung reagiert auf die sich verändernde Welt um sie herum. Komponenten oder Arbeitseinheiten reagieren damit auf Nachrichten, die von anderen Komponenten früher in der Verarbeitungskette verbreitet wurden. Als Ergebnis dieses unidirektionalen, aktorbasierten Nachrichtenaustauschs fließen Daten durch die Phasen der Anwendung, wie in 3 dargestellt. Insbesondere stellt 3 ein Beispiel für ein einfaches Datenflussdiagramm 100 dar, bei dem mehrere Datensammler 102 Daten an einen Datenaggregator 104 liefern (oder auffächern), der dann Daten an einen anderen Datenaggregator 106 senden kann, der dann Daten an mehrere Ausgangsblöcke 108 senden kann. Die Datensammler 102 in können beispielsweise Sensormessungen oder bezogen auf AI-Blöcke in einem herkömmlichen Steuerungssystem sein. Der Datenaggregator 104 kann ein Steuerblock oder ein Steuermodul in einem herkömmlichen Steuerungssystem sein, der Datenaggregator 106 kann ein Alarmbehandlungsblock in einem herkömmlichen Steuerungssystem sein und der Ausgangsblock 108 kann Benutzeroberflächen, Alarmstationen, Alarmverriegelungen usw. eines herkömmlichen Steuerungssystems sein. Selbstverständlich kann das Datenflussdiagramm 100 aus 3 viele andere Arten des Datenflusses in einem Industrie- oder Prozessleitsystem darstellen. Die Pfeile in 3 veranschaulichen, wie die Daten durch das System fließen, und es wird schnell deutlich, dass das Fehlen von zirkulären Abhängigkeiten (d. h. unidirektionaler Fluss in Bezug auf Datennachrichten) den Aufwand reduziert, der erforderlich ist, um zu verstehen, wie ein solches System funktioniert.
  • Im Beispiel von 3 nimmt das System 10 Daten in das Steuerungssystem auf (z. B. über ein Steuerungsprotokoll, wie ein Publish/Subscribe-Kommunikationsprotokoll, eine HTTP-API-Anforderung oder eine andere Form des Telemetrie-Aufnahmeprotokolls, wie z. B. MQTT). Wenn es sich bei den Daten um Sensordaten handelt, ist die Sensoridentifikatorkomponente (z. B. einer der Datenaggregatoren 104 oder 106) für die Durchführung der Aggregation und anderer Verarbeitungen der Sensormesswerte verantwortlich und leitet diese Messwerte dann an die nächste Komponente weiter. Diese nächste Komponente kann ein View-Client sein, der dann die Daten an eine Anzeige zur Anzeige der Daten, an einen historischen Client, der die Daten aufzeichnet, und an eine Steueranwendung, die Maßnahmen gegen die Daten ergreift, und/oder an einige andere Anwendungen weitergibt. Das Hauptziel bei der Betrachtung des Datenflusses ist, dass Vorgänge vermeiden sollten, sich auf Rückwärtsaufrufe in der Kette zu verlassen. Stattdessen sollte jeder Dienst in der Lage sein, korrekt zu handeln, abhängig von den Daten, die er vom vorherigen Element oder den Elementen der Kette erhalten hat. Dieser unidirektionale Datenfluss stellt sicher, dass die Komponenten einfach zu testen sind, dass die Kombination für Entwickler, die neu in der Codebasis sind, leicht verständlich ist und dass die Anwendung in der Lage ist, in einem Push-basierten Modell und nicht in einem Pull-basierten Modell zu arbeiten. Sobald eine Anwendung in einem Pull-basierten Modell vorhanden ist, führt dies zu Konfliktproblemen, da mehrere unabhängige Dienste mit Konfliktproblemen konfrontiert sind, da sie alle darum kämpfen, Daten vom Ziel des Pull-Vorgangs abzurufen.
  • Darüber hinaus sind im Beispiel von 3 jede der Boxen oder Objekte (z. B. die Sammler 102, die Aggregatoren 104 und 106 und die Ausgänge 108) Aktoren in einem Aktormodell. Das Aktormodell ist ein Berechnungsmodell, das als Mittel zur Modellierung gleichzeitiger Operationen konzipiert ist. Das Aktormodell beruht auf der Verwendung von Nachrichten, die zwischen unabhängigen Entitäten übertragen werden, um die Parallelitätsstammfunktionen auf niedriger Ebene zu abstrahieren. Erlang ist das bekannteste Beispiel für eine Implementierung des Aktormodells, das von Ericsson entwickelt wurde, um bei der Entwicklung hochkontinuierlicher Anwendungen für Telekommunikationszwecke zu helfen. Das Aktormodell bildet eine leistungsstarke Abstraktion, die es dem hier beschriebenen Steuerungssystem ermöglicht, Code so zu verwenden, dass das System auf Maschinen mit einer beliebigen Anzahl von Kernen ausgeführt werden kann, ohne sich um die Details des Multithreadings kümmern zu müssen, während gleichzeitig die Ressourcen, die auf einem bestimmten Hardwarecomputer verfügbar sind, bestmöglich genutzt werden.
  • Ein weiterer wichtiger Aspekt der hierin beschriebenen Leitsystemarchitektur ist, dass die Daten oder der Datenaustausch zwischen Komponenten (z. B. virtuelle Geräte, virtuelle Komponenten oder Entitäten, Hardwaregeräte und Aktoren) selbstbeschreibend sind. Um ein selbstbeschreibendes Datennachrichtenprotokoll zu unterstützen, müssen die Komponenten des Steuerungssystems 10 in der Lage sein, sowohl Daten als auch Datenbeschreibungen unabhängig oder gemeinsam zu empfangen. Auf diese Weise können die Aktoren aus den Datenbeschreibungen zunächst die empfangenen Daten interpretieren und dann auf die Daten reagieren.
  • Ein Verfahren zum Senden von Datenbeschreibungen und Daten in einem selbstbeschreibenden Datensystem ist in 4 näher dargestellt. Insbesondere empfängt ein Aktor 122, wie in dem Diagramm 120 von 4 dargestellt, Daten von der Anlage (oder einem anderen Aktor innerhalb der Anlage) 124 und gleichzeitig oder zu einem anderen Zeitpunkt vor oder kurz nach Erhalt der Daten 124 erhält der Aktor 120 Referenzdaten 126, die die Daten 124 so beschreiben, dass der Aktor 122 die Daten 124 entschlüsseln und verstehen kann. Die Daten 124 und die Referenzdaten (auch Metadaten genannt) 126 können beispielsweise in komprimierter Form übertragen oder in JSON-Form erweitert werden, wie im Beispiel von 4 dargestellt. Die Daten können jedoch in einem beliebigen Protokoll und/oder Datenformat ausgedrückt oder gesendet werden. In beiden Fällen werden der Verweis oder die Metadaten 126 vom Aktor 122 verwendet, um die empfangenen Daten 124 zu interpretieren.
  • Es wird darauf hingewiesen, dass im System der und , die Steuerung-Übersetzungsdienste Maschine 74 die Datendekodierung und Interpretation für verschiedene andere virtuelle Geräte in Knoten 14 mit dem Schema von durchführen kann, wenn die virtuellen Maschinen 52, 54 usw. als Aktoren modelliert sind. Ferner wird darauf hingewiesen, dass das hierin beschriebene aktorbasierte Modell auf virtuellen Geräten verwendet werden kann, die in den BFN-I/O-Steuerungen 12 und den virtuellen Geräten oder Entitäten in den erweiterten Funktionsknoten 14 dargestellt sind, wobei bei jeder virtuellen Vorrichtung oder logischen Komponente ein separater Aktor vorhanden ist. In diesem Fall kann der BFN-Steuerungsübersetzer 74 eine Datendekodierung basierend auf dem hierin beschriebenen selbstbeschreibenden Datennachrichtenschema durchführen und die interpretierten Daten an eine oder mehrere der anderen virtuellen Maschinen (z. B. die virtuellen Steuerungen 52, das virtuelle Ethernet BFN 54, die Datenanalysemaschine 64 usw.). Ebenso kann der BFN-Steuerungsübersetzer 74 Datennachrichten, die von einer der anderen virtuellen Maschinen 50, 52, 62, 64 an externe Geräte (z. B. an die DNC-I/O-Steuerungen 12) gesendet werden, bereitstellen oder anpassen, indem er eine Datenbeschreibung für diese Geräte oder Nachrichten in Kombination mit der von einer virtuellen Vorrichtung gesendeten Datennachricht bereitstellt.
  • Wichtig ist jedoch, dass verschiedene oder, wenn gewünscht, jede der tatsächlichen virtuellen Entitäten innerhalb der virtuellen Vorrichtungen, wie jeder der Steuerblöcke oder Module innerhalb der virtuellen Steuerungen 52, jeder datenanalytische Block innerhalb der datenanalytischen Maschine 64 usw. ein separater Aktor innerhalb des Aktormodells sein kann. Ebenso können in diesem Fall jede der logischen Entitäten innerhalb der BFN-I/O-Steuerungen 12 separate Aktoren innerhalb des Aktormodells sein. Daher können Datenübersetzungen oder Datennachrichten (z. B. unter Verwendung des hier beschriebenen selbstbeschreibenden Datenschemas) von jedem Aktor durchgeführt werden. In diesem Fall wird die Steuerungs-Übersetzungsdienste-Maschine 74 in den erweiterten Funktionsknoten 14 möglicherweise nicht benötigt, da diese Funktionalität von den separaten Aktoren bereitgestellt wird.
  • Ebenso würden, wie oben erwähnt, wenn die Systemarchitektur erweitert wird, um Prozesssteuerung oder andere Geräte, wie Feldgeräte, direkt mit dem Netzwerk 16 verbinden zu können, anstatt eine Verbindung über einen grundlegenden Funktionsknoten 12 herzustellen, die Geräte (z. B. Feldgeräte) die Kommunikation mit dem Netzwerkprotokoll unterstützen und könnten einen oder mehrere Aktoren umfassen, die für Kommunikation, Datenmanipulationen und spezifische Funktionen wie eine Ventildiagnose verwendet werden können, um eine solche Kommunikation zu ermöglichen. Dabei sind die Aktoren innerhalb des Steuerungssystems bis hinunter zur Feldgeräteebene verteilt.
  • In jedem Fall kann der aktorbasierte Ansatz sehr gut für verschiedene Steuerungsarten geeignet sein, einschließlich z. B. Chargensteuerung und zustandsbasierte Steuerung. Bei der Chargensteuerung sendet jeder der Beteiligten Nachrichten an andere interessierte Aktoren, während die Charge ihr Rezept durchläuft. Ebenso senden die Aktoren bei der zustandsbasierten Steuerung oder bei der einfachen Ablaufsteuerung Nachrichten an andere interessierte Aktoren, während die Sequenz abläuft. In diesen Fällen ist eine eng gekoppelte Koordination zwischen den Aktoren, mit Ausnahme des Sendens von Nachrichten zwischen den Aktoren, nicht erforderlich. Darüber hinaus versteht man, dass Nachrichten zwischen Aktoren jedes beliebige Format und Protokoll haben können und andere Protokollnachrichten wie z. B. HART- oder Feldbus-Protokollnachrichten enthalten können. Ebenso kann das aktorbasierte Modell auch dann verwendet werden, wenn das Kommunikationsnetz ein Mesh-Kommunikationssystem ist (z. B. basierend auf einem drahtgebundenen oder drahtlosen Netzwerk oder einer Kombination aus beidem), da die Aktoren über ein Mesh-Netzwerk mit den gleichen Grundprinzipien wie in einem busbasierten Netzwerk kommunizieren können.
  • Als ein Beispiel für die Verwendung des Aktormodells, das auf ein herkömmliches Prozessleitsystem angewendet wird, kann jeder Funktionsblock in einem herkömmlichen Prozessleitsystem als separater Aktor im Aktormodell bezeichnet werden, da jeder Aktor dann (asynchron in Bezug auf die anderen Aktoren) ausführt und die Ergebnisse an den nächsten Aktor in der Kette sendet, der die Funktionalität entlang der Kette treibt. Diese Zuordnung eignet sich z. B. gut für kaskadierte Prozessregelkreise.
  • Als weiteres Beispiel für die Anwendung des aktorbasierten Modells in einem Prozessregelkreis eines Prozessleitsystems veranschaulicht 5 eine Art und Weise der Implementierung eines einfachen PID-Regelkreises 130, der zwischen einem oder mehreren der BFN-I/O-Regler 12 und einem der erweiterten Funktionsknoten 14 getrennt ist. In diesem Beispiel beinhaltet der Prozessregelkreis einen AI-Block 132 (analoger Eingang), der in einer Feldvorrichtung oder in einem der BFN-I/O-Steuerungen 12 angeordnet ist und ein Messsignal an einen PID-Steuerblock 134 liefert, der in der virtuellen Steuervorrichtung 52 eines erweiterten Funktionsknotens 14 implementiert ist, der einen Steuerausgang an einen AO-Block 136 (analoger Ausgang) liefert, der in einem Ventil oder in einer der BFN-I/O-Steuerungen 12 angeordnet ist, und der eine Rückkopplungsmessung der aktuellen Ventilpositionierung des Ventils empfängt. In einem herkömmlichen Steuerungssystem wären die Blöcke 132, 134 und 136 proprietär und entsprechen dem gleichen Protokoll oder Nachrichtenschema, und diese Blöcke wären konfiguriert, Signale über dedizierte oder vorkonfigurierte Kommunikationspfade an vorkonfigurierte Hardware zu senden, um die Steuerkommunikation zu implementieren. Da die Blöcke 132, 134, 136 alle das gleiche Protokoll haben, wissen der Sende- und der Empfangsblock, wie man die Datennachrichten jederzeit liest, da diese Nachrichten dem gleichen Protokoll und Datenformat entsprechen.
  • Der untere Teil von 5 veranschaulicht jedoch eine Art und Weise, wie das aktorbasierte Modell auf den einfachen Regelkreis 130 angewendet werden würde oder könnte, um unidirektionales und selbstbeschreibenden Nachrichtenaustausch bereitzustellen, das die Unabhängigkeit von Nachrichtenprotokollen und Formaten über das Netzwerk 16 der 1 und 2 (und sogar zwischen Aktoren desselben Knotens oder einer physikalischen Maschine oder eines Prozessors eines einzelnen Knotens) ermöglicht. Insbesondere in einem aktorbasierten Modell 140 sind mehrere Datensammlerblöcke 142A und 142B vorgesehen, um die Sensormessung (die dem AI-Block 132 zugeordnet ist) und die Ventilstellungsmessung (die dem AO-Block 136 zugeordnet ist) zu erfassen. Diese Datensammlerblöcke 142A und 142B können sich in verschiedenen Feldgeräten und/oder in denselben oder verschiedenen BFN-I/O-Steuergeräten 12 befinden. Wie jedoch in 5 dargestellt, ist jeder der Blöcke 142A und 142B mit einem Datenübersetzerblock 144A und 144B verbunden, die jeweils Datennachrichten über das Netzwerk 12 unter Verwendung eines selbstbeschreibenden Datenprotokolls bereitstellen. Jeder der Blöcke 144A und 144B kann die Daten aus den Blöcken 142A und 142B in den gleichen oder in verschiedenen Nachrichtenprotokollpaketen einkapseln und andere Metadatennachrichten bereitstellen, die die Daten in der Basisnachricht beschreiben (auch Datennachricht genannt). Die Blöcke 144A und 144B können diese Nachrichtenpaare (die dem selbstbeschreibenden Nachrichtenschema zugeordnet sind) über das Netzwerk 16 senden, das an die nachfolgenden Blöcke 146A und 146B adressiert ist, die sich in diesem Fall in einem der virtuellen Steuerungen 52 befinden können, die in einem der erweiterten Funktionsknoten 14 angeordnet sind. Es wird darauf hingewiesen, dass die Blöcke 144A und 144B unterschiedliche Nachrichtenprotokolle und/oder unterschiedliche Nachrichten- oder Datenformate verwenden können, so dass die Datensammlerblöcke 142A und 142B nicht dem gleichen proprietären Protokoll oder Schema entsprechen müssen, sondern von völlig verschiedenen Herstellern mit unterschiedlicher proprietärer Programmierung bereitgestellt werden können. Darüber hinaus können die Übersetzungsblöcke 144A und 144B die Nachrichten mit völlig unterschiedlichen Datenformaten oder Metadatenbeschreibungen (z. B. voneinander) versenden, was diese Blöcke wieder unabhängiger und offener in der Verwendung macht.
  • Weiterhin empfängt ein zweites Paar von Übersetzungsblöcken oder Aktoren 146A und 146B die Datennachrichten und die Metadatennachrichten aus den Blöcken 144A und 144B und verwendet die darin enthaltenen Informationen zur Dekodierung der Daten (z. B. Sensormessdaten). Dieser Dekodierungsprozess kann das Bestimmen des Nachrichtenprotokolls der Nachricht (z. B. das Paketformat) sowie das Bestimmen des Datenformats beinhalten, das die Bedeutung der Daten innerhalb der Nachricht basierend auf der Metadatennachricht definiert. Die Übersetzungsblöcke 146A und 146B liefern dann die dekodierten Daten an einen PID-Steuerblock 148. Es wird darauf hingewiesen, dass die Übersetzerblöcke 146A und 146B unabhängig voneinander und vom PID-Block 148 arbeiten können. Der PID-Steuerblock 148, der eine proprietäre Steuerroutine einrichten kann, kann die Sensormesseingänge verwenden und ein Steuersignal am Ausgang erzeugen. Das Steuersignal vom PID-Steuerblock kann einem anderen Übersetzerblock 150 (einem separaten Aktor im Aktormodell) zugeführt werden, der die Daten in einer Nachricht (einem Nachrichtenpaket) kodieren kann, die für die Kommunikation über das Netzwerk 16 geeignet ist, und diese Datennachricht zusammen mit einer Metadatennachricht über das Netzwerk 16 senden kann, die an eine logische Einheit innerhalb einer der BFN-I/O-Steuerungen 12 gerichtet ist. Die Nachrichten werden dann von einem weiteren Übersetzungsblock 152 in der entsprechenden BFN-I/O-Steuerung 12 empfangen, der die Daten innerhalb der über das Netzwerk 16 empfangenen Nachrichten (basierend auf den Metadaten und den Daten innerhalb der Datennachricht) dekodiert. Auch hier kann die vom Übersetzungsblock 152 dekodierte Nachricht in jedem beliebigen Nachrichtenprotokoll (z. B. jedem paketbasierten Protokoll), das über das Netzwerk 16 gesendet wird, enthalten sein und kann jedes Nachrichten- oder Datenformat oder Schema verwenden, da der Übersetzungsblock 152 die Metadaten verwendet, um das Format der Datennachricht zu dekodieren oder zu verstehen. In jedem Fall liefert der Übersetzerblock 152 dann das Steuersignal an einen Steuerblock 154, der sich beispielsweise in einer logischen Komponente eines der BFN-I/O-Regler 12 oder in einem Feldgerät usw. befinden kann, um beispielsweise eine Positionsänderung eines Ventils zu bewirken.
  • Wie bereits erwähnt, ist jeder der Blöcke 142A, 142B, 144A, 144B, 146A, 146B, 148, 150, 152 und 154 ein separater Aktor, der in derselben oder unterschiedlicher physikalischer Hardware betrieben werden kann. Jeder dieser Aktoren verwendet asynchrone, zueinander unidirektionale Kommunikation und führt somit keine Pull-basierte Kommunikation durch. Darüber hinaus kann jeder der Aktoren oder Blöcke Daten unter Verwendung des hierin beschriebenen selbstbeschreibenden Datenprotokolls übertragen, wodurch das Kommunikationsprotokoll und das Format unabhängig werden. In einigen Fällen können die Metadatennachrichten des selbstbeschreibenden Datenprotokolls gleichzeitig (z. B. kurz vor oder nach) der Datennachricht gesendet werden oder periodisch oder zu anderen aperiodischen Zeiten an den nachgelagerten Aktor zur Verwendung durch den nachgelagerten Aktor gesendet werden. Das heißt, die Metadatennachricht muss möglicherweise nicht so oft gesendet werden wie die Datennachrichten des selbstbeschreibenden Nachrichtenprotokolls, da der empfangende Aktor die Metadaten für die Dekodierung von Datennachrichten speichern kann. Somit können die Metadatennachrichten typischerweise seltener als die Datennachrichten gesendet werden, und die Metadatennachrichten können nur gesendet werden, wenn die Metadaten geändert, ergänzt oder anderweitig geändert werden und/oder um neue dem System hinzugefügte Aktoren zu informieren, die Datennachrichten von einem bestimmten vorgeschalteten Aktor der Metadaten empfangen können.
  • Noch weiter, wie in 5 veranschaulicht, hat das aktorbasierte Modell die Aktoren 142A und 144A, die im Allgemeinen dem AI-Block 132 des herkömmlichen Regelkreises entsprechen, die Aktoren 146A, 146B, 148 und 150, die dem PID-Block 134 des herkömmlichen Regelkreises 130 entsprechen, und die Aktoren 142B, 144B, 152 und 154, die dem AO-Block 136 des herkömmlichen Regelkreises 130 entsprechen. Natürlich können weitere Aktoren in das Ketten- oder Aktormodell 140 aufgenommen werden, um andere Aktionen durchzuführen. So könnten beispielsweise Übersetzungsblöcke in zwei Aktoren unterteilt werden, von denen einer eine Datennachricht nach einem Metadatenschema formatiert und der andere die Datennachricht des ersten Aktors in ein Paket eines bestimmten paketbasierten Protokolls formatiert, um diese Nachricht über das Netzwerk 16 zu senden.
  • Wie man versteht, sieht die Verwendung des hierin diskutierten aktorbasierten Modells unidirektionalen Nachrichtenaustausch vor, ermöglicht die Verwendung von selbstbeschreibenden Nachrichtenprotokollen und ermöglicht den asynchronen Betrieb der verschiedenen logischen Elemente im Steuerungssystem, was die oben beschriebenen reaktiven Vorteile für Anwendungen bietet, die innerhalb des Steuerungssystems 10 ausgeführt werden. Die Verwendung dieses aktorbasierten Modells ermöglicht es beispielsweise einem Benutzer, Übersetzungsblöcke unabhängig von Steuerblöcken zu aktualisieren. Diese Funktion ermöglicht es einem Benutzer oder System, Übersetzungsblöcke zu ändern oder neu zu konfigurieren, wenn ein Datenprotokoll oder ein Datenübertragungsformat geändert wird (z. B. wenn ein neues Update für ein paketbasiertes Nachrichtenübertragungsprotokoll bereitgestellt wird), ohne die Steuerblöcke (z. B. die Steuerblockkommunikation) berühren oder neu konfigurieren zu müssen. Andererseits ermöglicht diese Funktion, Steuerblöcke zu aktualisieren oder zu ändern (z. B. den proprietären Betrieb dieser Blöcke zu ändern oder zu aktualisieren), ohne die Datennachrichten- oder Übersetzerblöcke ändern zu müssen. Diese Funktion ermöglicht es dann, die Rekonfigurationsaktivitäten auf die mit der Änderung verbundenen Aktoren zu konzentrieren, ohne andere Aktoren zu rekonfigurieren, deren Funktionalität nicht direkt mit der Änderung verbunden ist. Diese Operation erleichtert die Konfiguration des Systems 10 und isoliert die Fehlererkennung und -behebung und macht das System oder die Anwendungen innerhalb der Steuerung widerstandsfähiger gegen Fehler.
  • Wie bereits erwähnt, kann die hierin beschriebene Steuerungssystemarchitektur sowohl die Änderungen der Arbeitslast als auch Ausfälle von Komponenten problemlos bewältigen. Insbesondere gibt es viele verschiedene Arten von Fehlern und Problemen, die beim Umgang mit einem relativ komplexen Steuerungssystem auftreten können. Einige Beispiele sind Hardwareausfälle, Softwareausfälle, Ausfälle von Netzwerkverbindungen, Wartungsfehler und übermäßige Verarbeitungsfehler.
  • Im Allgemeinen treten Hardwareausfälle auf, wenn eine physikalische Komponente eines Rechenknotens, der eine Anwendung hostet, oder eine logische Einheit ausfällt. Dieser Fehler deckt den Fall ab, dass ein Knoten, der eine Reihe von (z. B. Sensor-)Aktoren hostet, ausfällt. Typischerweise beinhalten Hardwareausfälle solche wie Festplattenausfälle, Prozessorausfälle usw. Im Falle eines Hardwarefehlers kann das System (z. B. der Hypervisor 50 von 2) die auf diesem Knoten befindlichen Darstellungen des Aktors (z. B. Sensors) leicht auf ein Ersatzgerät oder -knoten übertragen (z. B. können die Sensoren auf einen Backup-Sensor, einen Soft-Sensor oder einen Fehlerbedingungshandler übertragen werden). Somit können die Aktoren oder andere logische Einheiten auf andere Hardware auf demselben Knoten oder auf jede beliebige Kombination von Hardware auf anderen Knoten im Steuerungssystem 10 abgelegt werden. Hier können die Front-End-Knoten die Nachrichten korrekt umleiten, ohne sich auch nicht um die Interna dieser Nachrichten zu kümmern, da die Nachrichten an andere Aktoren und nicht an hardwarespezifische Speicherorte gerichtet sind. So kann beispielsweise das Hauptsteuerprogramm oder der Hypervisor 50 von 2 Komponenten wie Steuerroutinen, virtuelle Steuerungen, Übersetzungsdienste usw. von einer Hardwarevorrichtung (oder in verschiedene Speicher oder Prozessoren innerhalb einer Hardwarevorrichtung) verschieben, ohne die Routine, die Steuerung, den Übersetzer und insbesondere ohne die Kommunikation der zu verschiebenden Komponente neu konfigurieren zu müssen (da die hierin beschriebenen Kommunikationen die Unabhängigkeit vom Hardware-Standort ermöglichen oder einrichten).
  • Softwarefehler treten auf, wenn ein unzulässiger Vorgang auftritt und die Software eine nicht behandelte Ausnahme auslöst. Diese Art von Fehler beinhaltet allgemeine Fälle, in denen die Anwendung schuld ist, z. B. wenn eine Anwendung nicht auf eine Datenbank zugreifen kann, ist sie für die Verbindung verantwortlich oder wenn die Anwendung versucht, durch Null zu dividieren. Um diese Art von Fehler zu behandeln, beinhaltet das System ein Hauptsteuerprogramm (z. B. den Hypervisor 50), das die einzelnen Sensoren oder Anwendungen überwacht und sicherstellt, dass der Aktor im Fehlerfall in einen bekannten Betriebszustand zurückgebracht wird, typischerweise durch Neustart des Aktors oder der Repräsentation.
  • Netzwerkverbindungsfehler treten auf, wenn Computer aufgrund von Router-, Switch- oder anderen Netzwerkhardwarefehlern nicht miteinander kommunizieren können. Ebenso können Fehler in der Umgebungswartungsroutine das Ausführen einer Reihe von potenziell lang laufenden Aufgaben beinhalten, wie z. B. das Sammeln einer sehr großen Datenmenge vom Datenhistoriker. In all diesen Fällen entzieht der Fehler der Anwendung Ressourcen, was zu einer Unterbrechung der Anwendung führen kann. Während diese spätere Situation normalerweise nicht als Fehler angesehen wird, kann sie bei anderen Maschinen als Fehler erscheinen, da die Anwendung möglicherweise nicht rechtzeitig auf Heartbeat-Anfragen reagiert. Um diese Art von Fehler zu beheben, kann das System ein Hauptsteuerprogramm (z. B. den Hypervisor 50 von 2) beinhalten, das sicherstellt, dass der Aktor oder die Repräsentation an einen Ort bewegt wird, an dem er über mehr Rechenleistung verfügt.
  • Darüber hinaus kann ein übermäßiger Verarbeitungsfehler auftreten, wenn ein Aktor (z. B. ein Sensor) mehr Verarbeitung benötigt als andere. Beispielsweise kann ein Sensoraktor häufiger als einmal pro Sekunde Messwerte generieren, was sich auf die Verarbeitungsdauer auswirkt. In diesem Fall will das System andere Sensoraktoren der Verarbeitungszeit nicht verkümmern lassen, da dies verhindern würde, dass diese anderen Sensoren ansprechbar bleiben. Um mit dieser Art von Fehler umgehen zu können, beinhaltet das System ein Hauptsteuerprogramm (z. B. den Hypervisor 50 von 2), das sicherstellt, dass der Sensor oder andere Aktor an einen Ort bewegt werden kann, an dem ihm mehr Rechenleistung zur Verfügung steht, sei es eine Maschine in einem eigenen Thread oder eine völlig andere Maschine zusammen.
  • In einigen Fällen kann die BFN-I/O-Steuerungs-Hardware einen Dual-Core-Prozessor verwenden, wobei einer der Kerne für schnelle Steuerungsaktivitäten (z. B. 10 ms und 20 ms Ausführung) und der andere Kern für alles andere (z. B. I/O, Nachrichtenbehandlung, 50 ms und 100 ms Steuerungsausführung usw.) verwendet wird. Der BFN-I/O-Steuerungsträger kann redundante Hardware-BFNs unterstützen und der Träger stellt Verbindungen zu den I/O-Grundplatten her. Ebenso können die schnellen Steuerungsaktivitäten mit einer Ausführungsgeschwindigkeit oder -rate betrieben werden, die beispielsweise mindestens fünf- oder zehnmal höher ist als die Ausführungsgeschwindigkeit der virtuellen Steuerungen in den erweiterten Funktionsknoten 14.
  • In einem weiteren Beispiel kann die hierin beschriebene Steuerungsarchitektur gleichzeitig schnelle und langsame Steuerungsaktivitäten durchführen und dennoch sicherstellen, dass beide oder dass alle Steuerungsgeschwindigkeiten mit der Nenngeschwindigkeit berücksichtigt und ausgeführt werden. 6 veranschaulicht ein Beispiel für ein schnelles Steuerungsnetzwerk mit drei BFN-I/O-Steuerungen 12, die über ein lokales Ethernet-Schnellsteuerungsnetzwerk 16A verbunden sind. Alle BFN-I/O-Steuerungen 12 sind in diesem Beispiel mit einem BFN-Steuerungsübersetzer 74 gekoppelt, der sich innerhalb eines erweiterten Funktionsknotens 14 befinden kann und das gleiche lokale schnelle Steuerungsnetzwerk teilt. Der BFN-Steuerungsübersetzer 74 und die BFN-I/O-Steuerungen 12 kommunizieren Konfiguration, Parameteränderungen und Steuerdaten über das lokale schnelle Steuerungsnetzwerk 16A. Die BFN-I/O-Steuerungen 12 kommunizieren auch schnelle Parameter und Eingabedaten an andere BFNs über das lokale schnelle Steuerungsnetzwerk 16A. Jede BFN-I/O-Steuerung 12 sendet ihre langsamen Parameter und Eingangsdaten im Abstand von 50 ms, und es wird darauf hingewiesen, dass die Ausführung der BFN-Steuerung nicht mit schnellen Parameterübertragungen zwischen den BFN-I/O-Steuereinheiten 12 synchronisiert ist. In diesem Fall kann, um sicherzustellen, dass die schnellen Steuerungsparameter auf dem schnellen Steuerungsnetz 16A mit der Nenngeschwindigkeit übertragen werden, das schnelle Steuerungsnetz ein zeitsensibles Netzwerk (TSN) mit einem TSN-Switch sein oder beinhalten, der die schnellen Steuerungsnachrichten auf dem Bus priorisiert, um sicherzustellen, dass diese Nachrichten mit der schnellen Geschwindigkeit (z. B. 10 ms oder 20 ms) über den Bus übertragen werden. Die Verwendung eines TSN-Switches in dem Netzwerk 16 zum Bilden einer schnellen Steuer-Netzwerkverbindung 16A ist wünschenswert, um sowohl eine schnelle als auch eine langsame Steuerung über dasselbe Netzwerk zwischen den BFN-I/O-Steuerungen 12 und den erweiterten Funktionsknoten 14 zu ermöglichen.
  • In einem Fall führen die BFN-Steuerungsmodule (die herkömmliche Module oder Aktoren im oben beschriebenen aktorbasierten Modell sein können) in den aktiven BFN-I/O-Steuerungen 12 aus. Die BFN-I/O-Steuerungen 12 verwenden die lokalen Eingänge sowie die vom lokalen Schnellsteuerungsnetz 16A empfangenen schnellen Parameter als Eingangsdaten für die BFN-Steuermodule oder -Aktoren. Am Ende der Steuerungsausführung schreiben die Steuersubsysteme Ausgabewerte an das lokale I/O-Subsystem (z. B. verbunden mit den Feldgeräten) und reihen I/O-Daten und schnelle Parameterdaten zur Übertragung über das lokale schnelle Steuerungsnetzwerk 16A entweder einmal alle 10s (für schnelle Parameterdaten) oder einmal alle 50 ms (für langsame Parameterdaten) auf. Diese Zeiten sind natürlich nur Beispiele und es könnten auch andere Zeiten verwendet werden.
  • Um eine schnelle Steuerung an den BFN-I/O-Steuerungen 12 durchzuführen, kann jede Steuerung 12 zwei Kerne oder Prozessoren beinhalten, die für die Steuerung mit hoher und mittlerer Geschwindigkeit (oder langsam) verwendet werden. veranschaulicht eine Art der Aufteilung von Aufgaben zwischen diesen beiden Kernen (Kern 0 und Kern 1), um eine schnelle und eine langsame Steuerung durchzuführen. In diesem Beispiel wird Kern 0 für die schnelle Steuerung und Kern 1 für die langsame Steuerung verwendet. Die synchronisierte Natur des I/O-Scannens und der Steuerungsausführung ermöglicht eine Steuerleistung von 10 ms und 20 ms Schraube-an-Schraube auf Kern 0 und 50 ms und 100 ms Schraube-an-Schraube auf Kern 1. Steuerungsausführungsgeschwindigkeiten, die langsamer als 100 ms sind, können auf der virtuellen Steuerung 52 in einem der erweiterten Funktionsknoten 14 ausgeführt werden, wenn gewünscht.
  • Wie in 7 dargestellt, beinhaltet Kern 0 ein Kommunikations-Subsystem 202, das die Kommunikation über das schnelle Steuerungsnetzwerk 16A durchführt, und einen Hochgeschwindigkeitssteuerblock 204, der schnelle Rechensteuerungsaktivitäten durchführt (z. B. bei den Zyklusraten zu 10 oder 20 ms). Der Hochgeschwindigkeitssteuerblock von Kern 0 ist mit einem P2P (Peer-to-Peer) Subsystem-Kommunikationsblock 206, einem Slow Speed Steuerblock 208 und einem I/O Subsystem-Kommunikationsblock 210 verbunden, die sich alle innerhalb von Kern 1 befinden. Darüber hinaus kann der Kommunikations-Subsystem-Block 202 mit dem I/O-Systemblock 210 verbunden werden, um die Bereitstellung schneller Steuerdaten aus dem I/O-Subsystem-Block 210 direkt auf das schnelle Steuerungsnetzwerk 16A oder umgekehrt zu ermöglichen. Der P2P-Block 206 führt Peer-to-Peer-Kommunikationen mit der langsamen Steuergeschwindigkeit oder -rate (z. B. 50 ms) durch, der langsame Geschwindigkeitssteuerblock 208 führt Aktivitäten der langsamen Geschwindigkeitssteuerung durch (z. B. Berechnungen der mittleren Geschwindigkeitssteuerung, Alarmbehandlung, Kommunikationsverarbeitung zwischen Geräten usw.), und der I/O-Subsystem-Block 210 führt Kommunikationen mit den Geräten (z. B. Feldgeräten) im I/O-Subsystem durch. Darüber hinaus wird in Kern 1 ein Diagnosesubsystem-Block 212 ausgeführt, um die Diagnose des Subsystems durchzuführen. Diese Aufgabenteilung zwischen den Kernen eines Multicore-Prozessors in den BFN-I/O-Steuerungen 12 ermöglicht sowohl eine schnelle als auch eine langsame Steuerung mit den gewünschten Geschwindigkeiten. Darüber hinaus ermöglicht die Verwendung eines TSN als schnelles Steuerungsnetzwerk 16A sowohl eine schnelle als auch eine langsame Steuerkommunikation mit anderen Geräten, wie beispielsweise den erweiterten Funktionsknoten 14, die es ermöglicht, auf Wunsch eine schnelle Steuerung in den erweiterten Funktionsknoten 14 durchzuführen.
  • Auf Wunsch können die BFN-I/O-Steuerungen 12 Warninformationen unterstützen, z. B. Hardware-Alarme wie ADVISE_ALM, COMM_ALM, FAILED_ALM und MAINT_ALM. Diese Ereignisse werden an einen Aktor übertragen, der für die Verarbeitung von Ereignis- und Alarminformationen verantwortlich ist. Jeder dieser Alarme hat die gleichen Alarmeigenschaften wie Prozessalarme (z. B. Alarmunterdrückung). Hardware-Alarme geben einen allgemeinen Hinweis auf ein Problem und dass die Diagnose verwendet wird, um das genaue Problem weiter zu diagnostizieren. Beispielhafte Hardwarealarme sind unten Tabelle 1 zusammengefasst. Tabelle 1 - Hardware-Alarme
    Alarmtyp Bedingung Kommentare
    ADVISE I/O-Integritätsproblem (z. B. Open Loop, ein schlechter Slice-Bus-Kanal) Die spezifischen Bedingungen werden sich mit dem I/O-Design weiterentwickeln. Es wird versucht, anzuzeigen, ob es sich um einen internen Zustand oder einen Zustand auf Sensorebene handelt.
    COMM Keine Kommunikation mit aktivierten I/O
    Keine Kommunikation mit zugewiesenem BFN
    FAILED HW-oder SW-Fehler erkannt
    MAINT BFN-Integritätsproblem nicht verursacht durch schlechte I/O (z. B. fehlgeschlagenes sekundäres lokales Schnellsteuerungsnetzwerk oder I/O-Busabschlussfehler) Die spezifischen Bedingungen werden sich mit dem BFN-Design weiterentwickeln.
  • In einem Fall kann bei der Konfiguration des Steuerungssystems jede einzelne BFN-I/O-Steuerung 12 einer virtuellen Steuerung 52 im lokalen schnellen Steuerungsnetzwerk 16A zugeordnet und dann die Steuerung 12 in Betrieb genommen und konfiguriert werden. Die Inbetriebnahme kann über das BFN-Kontextmenü erfolgen, das in einer Konfigurationsanwendung bereitgestellt wird, die in einem virtuellen Konfigurationssystem 70 auf dem erweiterten Funktionsknoten 14 oder in einem Client oder einem anderen Rechenknoten, wie beispielsweise einer der Arbeitsstationen 26 von 1, ausgeführt wird. Das EEPROM auf der BFN-I/O-Steuerkarte kann verwendet werden, um die Adresse, den Namen, die Download-CRCs und die letzte Downloadzeit der BFN-I/O-Steuerung 12 zu speichern. Wenn die BFN I/O-Steuerung 12 eingeschaltet wird, liest sie diese Informationen aus, um festzustellen, ob sie sich in der gleichen Position befindet, in der sie sich vor dem Ausschalten befand. Wenn die BFN-I/O-Steuerung 12 feststellt, dass sie noch an der gleichen Position in Betrieb genommen wird und eine gültige Konfiguration im Flash hat, die mit der Konfiguration der virtuellen Steuerung übereinstimmt, wechselt die BFN-I/O-Steuerung 12 in den konfigurierten Zustand.
  • Wie vorstehend erwähnt, kann eine BFN-I/O-Steuerungskonfiguration über das lokale schnelle Steuerungsnetzwerk-Subsystem unter einer virtuellen Steuerung 52 bereitgestellt werden. 8 veranschaulicht eine Bildschirmdarstellung einer Konfigurationsanwendung, die eine erweiterte Ansicht eines BFN-I/O-Steuerungsnetzwerks unter oder als Teil einer bestimmten virtuellen Steuerung 52 darstellt. In diesem Beispiel werden drei BFN-I/O-Steuerungen 12 (BFN-1, BFN-2, BFN-3) unter dem lokalen schnellen Steuerungsnetzwerk für eine virtuelle Steuerung 52 dargestellt. Es wird darauf hingewiesen, dass das I/O-Modul-Subsystem unter dem BFN-1 alle konfigurierten I/O-Module in diesem BFN beinhaltet. Bei der Erweiterung des I/O-Modul-Subsystems unter einem BFN kann einem Benutzer alle möglichen I/O-Module präsentiert werden, die unter dem BFN aktiviert werden können. Jedes I/O-Modul kann nummeriert werden, d. h. CHM1-01 bis CHM1-12 bis CHM8-01 bis CHM8-12 (8 Träger * 12 = 96 IO-Module pro BFN) und das Konfigurationssystem kann es dem Benutzer ermöglichen, die Kanal- oder Modulzuordnung in diesem Bildschirm vorzunehmen. Die folgende Tabelle 2 zeigt eine exemplarische Zuordnung von Kanälen (CHARMs-Kanäle) zu Geräte-Tags.
    Figure DE112018002293T5_0001
    Darüber hinaus können die Hardware-Alarme für das BFN und seine I/O-Module über den Hardware-Eintrag oder die Registerkarte Hardware definiert werden.
  • Darüber hinaus kann das Kontextmenü „Local Fast Control Network“ die Erstellung neuer Platzhalter für BFN-I/O-Steuerungen ermöglichen. Nicht zugewiesene BFNs, die physisch mit der virtuellen Steuerung verbunden sind, werden möglicherweise in der Inhaltsansicht Nicht zugewiesene BFNs angezeigt. Das Format der nicht zugewiesenen BFNs kann den Typ, das Modell und die Revision der nicht zugewiesenen BFNs anzeigen. Darüber hinaus können die BFNs in den nicht zugeordneten BFNs den erstellten Platzhaltern entweder durch Drag-and-Drop oder Kontextmenüauswahl aus dem BFN-Menü zugewiesen werden. Die BFNs sollten physisch vorhanden sein, um eine Aufgabe auszuführen. Wenn die Zuordnung erfolgt ist, erhält die virtuelle Steuerung grundlegende Identifikationsinformationen, um ihr entsprechendes Gerätemodul einschließlich Name und Adresse zu erstellen. Die Identifikationsinformationen werden in I/O-Daten und bei der schnellen Veröffentlichung von Parametern verwendet, um die Quelle der Daten eindeutig zu identifizieren.
  • In einem Beispiel werden bei der Wiederherstellung einer nicht funktionierenden BFN-I/O-Steuerung, wenn die BFN-I/O-Steuerung feststellt, dass sie noch in Betrieb genommen wird, an der gleichen Position und mit der gleichen Konfiguration wie die virtuelle Steuerung, die Konfiguration aus dem lokalen Kaltstartspeicher in den Laufzeitkonfigurationsspeicher kopiert, die I/O-Module heruntergeladen und die Steuerausführung beginnt. Darüber hinaus kann die BFN-I/O-Steuerung Gesamtdownloads unterstützen, und es besteht die Möglichkeit, dass der Benutzer einzelne I/O-Module herunterladen kann oder auch nicht. Im Gesamtdownload-Fall kann die BFN-I/O-Steuerung den Download verarbeiten und bestimmen, welche Komponenten sich geändert haben, um die Störeffekte des Downloads zu minimieren (d. h. es handelt sich um einen „total matching“-Download). Wenn sich z. B. nur eine Steuerstrategie (Modul) oder ein I/O-Modul geändert hat, wird nur diese Position aktualisiert. Die BFN-I/O-Steuerung kann alle I/O-Module konfigurieren, die sich beim Download geändert haben. Wenn die BFN-I/O-Steuerung jemals feststellt, dass ein I/O-Modul eine verlorene Kommunikation mit ihm wiederhergestellt hat, kann die BFN-I/O-Steuerung die erforderliche Konfigurationssequenz an das Modul senden, um das Modul wieder in Betrieb zu nehmen. Dies ermöglicht die Fehlerbehebung.
  • Darüber hinaus kann die BFN-I/O-Steuerung eine beliebige Anzahl und Typen von I/O-Modulen unterstützen, einschließlich Eingangsmodulen und Ausgangsmodulen. In einem Beispiel können insgesamt 96 I/O-Module der unten beschriebenen Typen unterstützt werden. Insbesondere sind exemplarische BFN-I/O-Eingangsmodule, die unterstützt werden können, in Tabelle3 zusammengefasst. Tabelle 3 - BFN-Eingangs-IO-Modultypen
    Gruppe Hardwaretyp Funktionalität
    Analoger Eingang (AI) AI 4-20 mA HART I/O-Modul HART Analogeingang 4-20 mA Analoger Eingang 4-20 mA Analoger Eingang 0-20 mA
    AI 4-20 mA HART (eigensicher) I/O Modul
    AI-generisches I/O-Modul
    Diskreter Eingang (DI) DI NAMUR I/O-Modul Diskrete Eingabe Impulszählereingang
    DI 24 V Gleichstrom, Low-Side I/O-Modul
    DI 24 V Gleichstrom, Isoliertes I/O-Modul
    DI 120 V Wechselstrom, Isoliertes I/O-Modul
    DI 230 V Wechselstrom, Isoliertes I/O-Modul
    IS DI NAMUR I/O-Modul
    DI Generisches I/O-Modul
    Thermoelement_mv LS Thermoelement/mV I/O Modul Thermoelementeingang Typ B
    Thermoelementeingang Typ E
    Thermoelementeingang Typ J
    Thermoelementeingang Typ K
    Thermoelementeingang Typ N
    Thermoelementeingang Typ R
    Thermoelementeingang Typ S
    Thermoelement Eingang Typ T
    ±20-Millivolt -Eingang
    ±50-Millivolt -Eingang
    LS Thermoelement/mV (eigensicher) IO Modul ± 100-Millivolt-Eingang
    LS Thermoelement/mV Generisches I/O-Modul
    RTD-Eingang LS RTD / Widerstand-Eingangs-IO-Modul Pt 100 RTD Eingang
    Pt 200 RTD Eingang
    Pt 500 RTD Eingang
    Pt 1000 RTD Eingang
    Ni 120 RTD Eingang
    Ni 100 RTD Eingang
    Ni 200 RTD Eingang
    Ni 500 RTD Eingang
    Ni 1000 RTD Eingang
    LS RTD / Widerstandseingang (eigensicher) IO Modul
    Cu 10 RTD Eingang
    Widerstand RTD Eingang
    LS RTD Generisches I/O-Modul
    Spannung LS AI 0-10 V Gleichstrom, Isoliertes I/O-Modul 0 bis 5 Volt Eingang
    0 bis 10 Volt Eingang
    1 bis 5 Volt Eingang
    -1 bis + 1 Volt Eingang
    -5 bis +5 Volt Eingang
    LS AI 0-10 Generisches I/O-Modul -10 bis + 10 Volt Eingang
    Spannungsversorgung LS 24 V Gleichstrom, Spannungsversorgung I/O-Modul 24 V Gleichstrom, Spannungsversoreung
  • Beispielhafte BFN-I/O-Ausgabemodule, die unterstützt werden können, sind in Tabelle 4 zusammengefasst. Tabelle 4 - BFN-Ausgang IO Modultypen
    Gruppe Hardwaretyp Funktionalität
    Analoger Ausgang (AO) AO 4-20 mA HART I/O Modul HART Analogausgang 4-20 mA
    AO 4-20 mA HART (eigensicher) I/O-Modul Analogausgang 4-20 mA
    AO Generisches I/O-Modul Analogausgang 0-20 mA
    Diskrete Ausgabe (DO) DO Generisches I/O-Modul
    DO 100 mA energiebegrenztes I/O-Modul Diskrete Ausgabe Momentaner Ausgang Kontinuierlicher Impulsausgang
    DO 24 V Gleichstrom High-Side I/O Modul
    DO 24 V Gleichstrom Isoliertes I/O-Modul
    DO V Wechselstrom Isoliertes I/O-Modul
    IS DO 45mA I/O-Modul
  • Darüber hinaus kann der BFN-Steuerungs-Übersetzungsdienst 74 (von 2) in Kombination mit dem OPC-UA-Dienst 68 (von 2) ein OPC-Mapping für die BFN-I/O-Steuerung bereitstellen. Ein Beispiel für diese Zuordnung ist mit Bezug auf 9-11 veranschaulicht. In 9 beinhalten die Organisationskomponenten alle genannten Elemente im Steuerungssystem 10. Beispiele, wie im Diagramm von 9 dargestellt, sind Bereiche und Steuerstrategien (Steuermodule). Stammfunktionen bestehen aus Funktionsblockdefinitionen und Parameterdefinitionen. Definitionen und Verwendungen definieren die Schnittstellen zu Funktionsbausteinen, Steuerungsstrategien, Parametern und Alarmen. Zu den Instanzen gehören bestimmte markierte Elemente, wie beispielsweise ein bestimmtes Gerät oder ein I/O-Kanal. Zu den Geräten gehören Steuerungen, I/O-Module und intelligente Geräte, wie z. B. HART-Geräte.
  • Darüber hinaus können die Steuerungsstrategien einem ANSI/ISA-88-Modell folgen, wie in 10 dargestellt. Hier sind Alarme und Ereignisse an diese Struktur gebunden. Daher stellt die Mapping-Schicht eine Schnittstelle von Steuerungsstrategien (Modulen) zu Objekten bereit, die über OPC-UA durchsucht und aufgerufen werden können. Ein Beispiel für ein grundlegendes Objektmodell für diese Zuordnung ist in 11 dargestellt. Es ist zu beachten, dass die Abbildungen der 9-11 verwendet werden können, um Metadatennachrichten für das oben beschriebene selbstbeschreibende Nachrichtenprotokoll bereitzustellen.
  • Darüber hinaus führt die virtuelle Steuerung 52 Steuerstrategien (z. B. Steuermodule) aus, stellt eine Schnittstelle vom DCS zu den BFN-I/O-Steuerungen 12 bereit und kann eine Modbus/TCP-Verbindung unterstützen. Zur Vereinfachung der Konfiguration und des Betriebs können Schattenmodule verwendet werden, um Hochgeschwindigkeitsmodule zu beschatten, die in BFN-I/O-Steuerungen 12 ausgeführt werden.
  • Während der Konfiguration kann die Konfigurationsanwendung (z. B. die virtuelle Konfigurationsanwendung 70 aus ) eine Kontextmenüauswahl im Steuerungsnetzwerk bereitstellen, die die Möglichkeit bietet, virtuelle Steuerungen hinzuzufügen. veranschaulicht einen exemplarischen Konfigurationsbildschirm, der einem Benutzer von einer Konfigurationsanwendung oder -vorrichtung präsentiert werden kann, die eine virtuelle Steuerung in einer Explorer-Ansicht unter einem Steuerungsnetzelement in der Hierarchie darstellt.
  • In diesem Fall werden auf der Registerkarte Zugewiesene Module die der Steuerung zugeordneten Steuermodule angezeigt. Die Hardwarealarmtypen können ADVISE, COMM, FAILED und MAINT sein. Im Subsystem „Lokales Schnellsteuerungsnetzwerk“ werden BFN-I/O-Steuerungen angezeigt. Darüber hinaus enthalten die zugewiesenen I/Os und die zugewiesenen drahtlosen I/Os die Remote-I/O-Zuweisungen von Remote-I/Os, WIOCs und anderen Geräten (nicht erforderlich für den Prototyp des offenen Steuerungssystems).
  • In einem Beispiel bietet das virtuelle Ethernet BFN 54 in eine Plattform für den Zugriff auf Daten von intelligenten Feldgeräten. Das virtuelle Ethernet BFN 54 ermöglicht den Zugriff auf intelligente Gerätedaten, um die Erfassung von Verlaufsdaten, Alarmierung und eingeschränkte Kontrolle zu unterstützen und kann alle gewünschten Protokolle wie Modbus TCP und EtherNet/IP unterstützen. Die unterstützende DCS-Konfiguration ermöglicht die Definition von Ports mit physikalischen und logischen Geräten unter dem Port. Die logischen Geräte können Signale enthalten, die die spezifischen Datenelemente in den Geräten definieren, auf die zugegriffen werden soll. Die Gerätedaten können dann über Gerätesignal-Tags (DSTs) den Parametern der Steuerungsstrategie (Modul) zugeordnet werden. Der Port, die Geräte und Signale können Konfigurationseigenschaften aufweisen, die je nach Protokoll unterschiedlich sind. In einem Beispiel ist die Funktionsblockfähigkeit von Modulen im virtuellen Ethernet BFN 54 so strukturiert, dass sie die Motorsteuerung und die Überwachungssteuerung unterstützen, kann aber auch so strukturiert sein, dass sie analoge und erweiterte Steuerung unterstützt. In einem Fall kann das virtuelle Ethernet BFN 54 möglicherweise keine anderen I/Os direkt referenzieren und somit können die I/Os möglicherweise nicht einem virtuellen Ethernet BFN 54 zugeordnet werden. Darüber hinaus können Gerätedaten möglicherweise nur innerhalb des an das Gerät angeschlossenen virtuellen Ethernet BFN 54 referenziert werden, d. h. die Gerätedaten können nicht direkt von einer anderen Steuerung extern referenziert werden.
  • Darüber hinaus ermöglicht eine Modbus TCP-Schnittstelle die Integration von Modbus-Datenquellen wie programmierbaren Logiksteuerungen (PLCs), Antrieben, Motorsteuerzentren (MCCs), Analysatoren und ähnlichen Geräten, die Modbus TCP kommunizieren, in das Steuerungssystem 10. Die Modbus-TCP-Schnittstelle kann ein Modbus-Client (Master) sein, der Daten von/zu Modbus-Servern (Slave-Geräten) liest und schreibt. Die Modbus-Servergeräte können direkte Modbus-TCP-Geräte oder serielle Modbus-Geräte unter einem Modbus-TCP-Gateway sein, wie in 13 dargestellt. Natürlich kann eines der vielen verfügbaren Modbus-TCP-Gateways verwendet werden.
  • Darüber hinaus kann eine EtherNet/IP (EIP)-Schnittstelle die Integration von EIP-Datenquellen wie PLCen, drehzahlvariablen Antrieben, MCCs, Analysatoren, Unterwassergeräten und ähnlichen Geräten, die EIP kommunizieren, in das Steuerungssystem ermöglichen. Die EIP-Schnittstelle kann ein EIP-I/O-Scanner sein, der Daten von/zu EIP-I/O-Adaptern und anderen Scannern liest und schreibt. Typische Ring-, Stern- und Linientopologien können mit dem EIP-Schnittstellen-Netzwerk verwendet werden.
  • Die virtuelle Steuerung 52 kann eine oder mehrere BFN-Steuerstrategien (Module) speichern und kann die Online-Ansicht und den Zugriff auf Parameterdaten durch Schattenmodule bereitstellen, die in der virtuellen Steuerung 52 laufen, der die BFN-I/O-Steuerungen 12 zugeordnet sind. Wenn ein BFN I/O-Steuerung 12 heruntergeladen wird, werden die Schattenmodule aus den BFN-Modulen erstellt, die in der BFN I/O-Steuerung 12 ausgeführt werden. Darüber hinaus können die Daten des BFN-I/O-Moduls von jedem BFN in einem lokalen schnellen Steuerungsnetzwerk und der virtuellen Steuerung 52 selbst zugänglich sein. Die Ausgänge können von einem Modul in der BFN-I/O-Steuerung 12 gesteuert werden, dem das Ausgangs-I/O-Modul gehört. Die zyklischen Eingangsdaten mit schneller Abtastung können über das lokale schnelle Steuerungsnetzwerk mit einer Geschwindigkeit von 50 Millisekunden oder auf Wunsch schneller übertragen werden, und alle BFN-I/O-Steuerungen 12 im Netzwerk 16 empfangen die Updates. Andere Daten, wie Eingangsdaten, I/O-Diagnose und Alarminformationen, sowie Feldgeräteprotokolldaten (wie HART-Daten) können mit geringerer Geschwindigkeit (z. B. 100 ms) an die virtuelle Steuerung 52 gesendet werden.
  • Darüber hinaus kann die Hardware, die die Ethernet-Kommunikationsswitches und die I/O-Ports (IOPs) enthält, die Unterstützung zur physikalischen Isolierung der Netzwerkverbindungen in der virtuellen Steuerung, dem lokalen schnellen Steuerungsnetzwerk und dem Steuerungsnetzwerk beinhalten. Redundante Netzwerkverbindungen können unterstützt werden. Ferner zudem, wenn ein BFN-I/O-Modul konfiguriert ist, Daten von einem anderen BFN-I/O-Modul zu verwenden, dann gilt die Quelle der Daten als der schnelle Parameter und die Verwendung der Daten als die schnelle Parameterreferenz. Zusätzlich können die nicht schnellen Parameter zum Datenaustausch zwischen den virtuellen Steuerungen 52 und den BFN-I/O-Steuerungen 12 verwendet werden. Wenn außerdem eine Referenz von einer virtuellen Steuerung 52 auf eine BFN-I/O-Steuerung 12 konfiguriert wird, kann der nicht schnelle Parametermechanismus verwendet werden. Ebenso kann das System 10 die automatische Erkennung von I/O-Modulen unterstützen. Wenn der I/O-Modultyp zur Konfigurationszeit nicht definiert wurde, werden die Informationen beim automatischen Erfassen ausgefüllt. Wenn jedoch der I/O-Modultyp eingegeben wurde und der automatisch erfasste Typ nicht übereinstimmt, kann ein Abstimmungsdialog angezeigt werden. Der Abstimmungsdialog kann auch dann auftreten, wenn das I/O-Modul nicht mit dem übereinstimmt, was konfiguriert wurde.
  • Darüber hinaus können die auf der Ebene der virtuellen Steuerungsknoten verfügbaren Informationen die Diagnose für den Knoten selbst, Kommunikation, zugewiesene I/Os, zugewiesene Module, Neustart, Redundanz, Modbus und das lokale schnelle Steuerungsnetzwerk der virtuellen Steuerung beinhalten. Historie und Trend können auf Wunsch über die OPC-UA-Schnittstelle 68 unterstützt werden. Die Alarmerkennung und Zeitstempelung kann in den BFN I/O-Steuerungen 12 durchgeführt werden, die für genaue Zeitstempel und Alarmdaten sorgen. Die Alarme einer BFN-I/O-Steuerung 12 können sich in der Prozesskategorie befinden. Die Geräteverwaltung kann verwendet werden, um beispielsweise HART- und andere Protokoll-I/O-Module unter den virtuellen Steuerungen 52 und BFN-I/O-Steuerungen 12 zu lokalisieren. Die Geräteverwaltung erfolgt durch den virtuellen AMS-Gerätemanager 70 von .
  • Bei der Implementierung in Software können alle hierin beschriebenen Anwendungen, Dienste, virtuellen Vorrichtungen, vertikalen Maschinen, virtuellen Einheiten usw. in jedem greifbaren, nicht vorübergehenden, computerlesbaren Speicher gespeichert werden, wie beispielsweise auf einer Magnetplatte, einer Laserplatte, einer Halbleiterspeichervorrichtung, einer molekularen Speichervorrichtung oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. Obwohl die hierin offenbarten Beispielsysteme neben anderen Komponenten auch Software und/oder Firmware, die auf Hardware ausgeführt wird, offenbart werden, ist zu beachten, dass diese Systeme lediglich illustrativ sind und nicht als einschränkend betrachtet werden sollten. Zum Beispiel wird in Betracht gezogen, dass beliebige oder alle dieser Hardware-, Software- und Firmware-Komponenten ausschließlich in Hardware, ausschließlich in Software oder in beliebiger Kombination von Hardware und Software ausgeführt werden können. Während die hierin beschriebenen beispielhaften Systeme als in Software implementiert beschrieben werden, die auf einem Prozessor einer oder mehrerer Computervorrichtungen ausgeführt wird, werden Durchschnittsfachleute leicht erkennen, dass die bereitgestellten Beispiele nicht die einzige Möglichkeit sind, solche Systeme zu implementieren.
  • Während die vorliegende Erfindung unter Bezugnahme auf spezifische Beispiele beschrieben wurde, die nur veranschaulichend sein sollen und die Erfindung nicht beschränken sollen, ist es für den Durchschnittsfachmann offensichtlich, dass Änderungen, Hinzufügungen oder Streichungen möglich zu den offenbarten Ausführungsformen gemacht werden können, ohne vom Geist und Umfang der Erfindung abzuweichen.

Claims (39)

  1. Industrielles Steuersystem mit einer Vielzahl von Feldgeräten, die physikalische Funktionen in einer industriellen Umgebung ausführen, das Folgendes umfasst: einen Ein-/Ausgabeknoten, der einen Ein-/Ausgabeprozessor einschließt, der an die Vielzahl von Feldgeräten innerhalb der industriellen Umgebung gekoppelt ist; einen oder mehrere virtuelle Steuerungsknoten, wobei jeder des einen oder der mehreren virtuellen Steuerungsknoten einen oder mehrere Prozessoren, einen Speicher, eine oder mehrere virtuelle Steuerungen, die im Speicher gespeichert sind, und auf dem einen oder den mehreren Prozessoren ausführbar sind, um die Steuerung der Feldgeräte innerhalb der industriellen Umgebung auszuführen, und ein Hauptsteuerprogramm, das im Speicher gespeichert ist und auf einem oder mehreren Prozessoren ausführbar ist, um den Betrieb der einen oder der mehreren virtuellen Steuerungen am Knoten zu verwalten, einschließt; und ein Kommunikationsnetz, das den Ein-/Ausgabeknoten mit jedem des einen oder der mehreren virtuellen Steuerungsknoten verbindet; wobei der Ein-/Ausgabeprozessor Gerätesignale von einem oder mehreren Feldgeräten innerhalb der industriellen Umgebung empfängt, die Gerätesignale verarbeitet und die verarbeiteten Gerätesignale im Kommunikationsnetz zur Übermittlung an der einen oder den mehreren virtuellen Steuerungen platziert und Steuersignale von einer oder mehreren der virtuellen Steuerungen über das Kommunikationsnetz empfängt, die empfangenen Steuersignale verarbeitet und die verarbeiteten Steuersignale an eines oder mehrere der Feldgeräte in der industriellen Umgebung sendet.
  2. Industrielles Steuerungssystem nach Anspruch 1, wobei der eine oder die mehreren virtuellen Steuerungsknoten eine Vielzahl virtueller Steuerungsknoten einschließen und wobei eine oder mehrere virtuelle Steuerungen eines der Vielzahl virtueller Steuerungsknoten von einem der Vielzahl virtueller Steuerungsknoten zu einem anderen Knoten der Vielzahl virtueller Steuerungen bewegbar ist, ohne die Kommunikation der virtuellen Steuerung neu konfigurieren zu müssen.
  3. Industrielles Steuerungssystem nach Anspruch 1, wobei eine oder mehrere virtuelle Steuerungen von einem Speicherort des Speichers eines virtuellen Steuerungsknotens an einen anderen Speicherort im Speicher des virtuellen Steuerungsknotens verwendet werden, ohne die Kommunikation der virtuellen Steuerung neu zu konfigurieren.
  4. Industrielles Steuerungssystem nach Anspruch 1, wobei mindestens einer der virtuellen Steuerungsknoten eine Vielzahl verschiedener Speichergeräte enthält und wobei die eine oder die mehreren virtuellen Steuerungen von einer der Vielzahl von Speichervorrichtungen des mindestens einen der virtuellen Steuerungsknoten zu einem anderen der Vielzahl von Speichergeräten des mindestens einen der virtuellen Steuerungsknoten bewegbar sind, ohne die Kommunikation der virtuellen Steuerung neu konfigurieren zu müssen.
  5. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine enthält, die an eine physikalisches Ein--/Ausgabevorrichtung in der industriellen Umgebung gekoppelt ist, um Gerätesignale von Feldgeräten über die physikalische Ein-/Ausgabevorrichtung in der industriellen Umgebung zu empfangen.
  6. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine enthält, die gekoppelt ist, um Gerätesignale direkt von Feldgeräten in der industriellen Umgebung zu empfangen, wobei die virtuelle Ein-/Ausgaberoutine auf einem Allzweckprozessor innerhalb des Ein-/Ausgabeknotens ausgeführt wird, um die Ein-/Ausgabesignalverarbeitung an Gerätesignalen der Feldgeräte und an Steuersignalen durchzuführen, die an die Feldgeräte übermittelt werden.
  7. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine enthält, die Gerätesignale über ein selbstbeschreibendes Kommunikationsschema an die virtuellen Steuerungen in den virtuellen Steuerungsknoten kommuniziert.
  8. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine enthält, die Gerätesignale über das Kommunikationsnetz unter Verwendung einer Vielzahl unterschiedlicher Kommunikationsprotokolle an die virtuellen Steuerungen weitergibt.
  9. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgaberoutine enthält, die Gerätesignale über ein standortunabhängiges Hardware-Kommunikationsadressierungsschema an die virtuellen Steuerungen weitergibt.
  10. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten ferner eine im Speicher des Ein-/Ausgabeknotens gespeicherte Steuerungsroutine einschließt, die auf dem Prozessor des Ein-/Ausgabeknotens ausgeführt wird, um ein oder mehrere Gerätesignale zu verwenden, um ein oder mehrere Steuersignale zur Steuerung eines der Feldgeräte in der industriellen Umgebung zu erzeugen.
  11. Industrielles Steuerungssystem nach Anspruch 10, wobei die virtuellen Steuerungen in einem oder mehreren virtuellen Steuerungsknoten Steuerungsroutineausführungen mit höchstens einer ersten Geschwindigkeit ausführen und wobei eine Steuerungsroutine im Ein-/Ausgabeknoten Steuerungsroutineausführungen mit einer zweiten Geschwindigkeit, die höher als die erste Geschwindigkeit ist, ausführt.
  12. Industrielles Steuerungssystem nach Anspruch 11, wobei die zweite Geschwindigkeit dem Fünffachen der ersten Geschwindigkeit entspricht oder darüber liegt.
  13. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale an das Kommunikationsnetz bündelt.
  14. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale von einer Vielzahl von Feldgeräten über eine Vielzahl verschiedener Kommunikationsprotokolle empfängt, und die Gerätesignale im Kommunikationsnetz über ein selbstbeschreibendes Kommunikationsschema bündelt.
  15. Industrielles Steuerungssystem nach Anspruch 1, wobei der Ein-/Ausgabeknoten eine virtuelle Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale von einer Vielzahl von Feldgeräten über eine Vielzahl verschiedener Kommunikationsprotokolle empfängt und die Gerätsignale an das Kommunikationsnetz innerhalb der Vielzahl verschiedener Kommunikationsprotokolle und unter Verwendung eines selbstbeschreibenden Kommunikationsschemas bündelt.
  16. Industrielles Steuerungssystem nach Anspruch 15, wobei das selbstbeschreibende Kommunikationsschema Gerätesignaldaten einschließt, die Gerätesignale in einem ersten Kommunikationsprotokoll und Protokollbeschreibungssignale, die das erste Kommunikationsprotokoll beschreiben, einschließt.
  17. Industrielles Steuerungssystem nach Anspruch 1, wobei das Hauptsteuerprogramm der virtuellen Steuerungsknoten einen Lastenausgleich der Prozessoren im virtuellen Steuerungsknoten ausführt.
  18. Industrielles Steuerungssystem nach Anspruch 1, wobei das Hauptsteuerprogramm von mindestens einem der virtuellen Steuerungsknoten konfiguriert ist, eine virtuelle Steuerung von einem Prozessor auf einen anderen Prozessor am virtuellen Steuerungsknoten zu verschieben, ohne die virtuelle Steuerungskommunikation für die virtuelle Steuerung neu zu konfigurieren.
  19. Industrielles Steuerungssystem mit einer Vielzahl von Feldgeräten, die physikalische Funktionen in einer industriellen Umgebung ausführen, Folgendes umfassend: einen Ein-/Ausgabeknoten, der einen Ein-/Ausgabeprozessor einschließt, der über einen oder mehrere Kommunikationskanäle an die Vielzahl von Feldgeräten innerhalb der industriellen Umgebung gekoppelt ist; eine Vielzahl von Steuerungsknoten, wobei jeder der Steuerungsknoten einen oder mehrere Prozessoren, einen Speicher, eine oder mehrere Steuerungen, die im Speicher gespeichert und auf dem einen oder den mehreren Prozessoren ausführbar sind, um die Steuerung der Feldgeräte innerhalb der industriellen Umgebung durchzuführen, und ein Hauptsteuerprogramm, das im Arbeitsspeicher gespeichert und auf dem einen oder den mehreren Prozessoren ausführbar ist, um den Betrieb einer oder mehrerer Steuerungen am Steuerungsknoten zu verwalten, einschließt; und ein offenes Protokollkommunikationsnetz, das den Ein-/Ausgabeknoten über ein offenes Kommunikationsprotokoll mit jedem der oder mehreren Steuerungsknoten verbindet; wobei der Ein-/Ausgabeprozessor Gerätesignale von einem oder mehreren Feldgeräten in der industriellen Umgebung empfängt, die Gerätesignale zum Bereitstellen an die eine oder mehrere Steuerungen unter Verwendung eines offenen Kommunikationsprotokolls in dem Kommunikationsnetz platziert, und Steuersignale von einer oder mehreren Steuerungen über das Kommunikationsnetz empfängt und die Steuersignale an ein oder mehrere Feldgeräte in der industriellen Umgebung sendet.
  20. Industrielles Steuerungssystem nach Anspruch 19, wobei das offene Protokollkommunikationsnetz ein Ethernet-Kommunikationsnetz ist.
  21. Industrielles Steuerungssystem nach Anspruch 19, wobei das offene Protokollkommunikationsnetz ein TCP/IP-paketbasiertes Netzwerkkommunikationsschema verwendet.
  22. Industrielles Steuerungssystem nach Anspruch 19, wobei einer der Steuerungsknoten ein virtueller Steuerungsknoten ist, der eine Vielzahl virtueller Steuerungen enthält, die von einem ersten der Prozessoren zu einem zweiten der Prozessoren an dem einen der Steuerungsknoten bewegbar sind.
  23. Industrielles Steuerungssystem nach Anspruch 19, wobei der Ein-/Ausgabeknoten Gerätesignale über ein selbstbeschreibendes Kommunikationsschema an die Steuerungen in den Steuerungsknoten kommuniziert.
  24. Industrielles Steuerungssystem nach Anspruch 19, wobei der Ein-/Ausgabeknoten Gerätesignale an die Steuerungen an den Steuerungsknoten kommuniziert, indem er Daten in einer Vielzahl verschiedener Kommunikationsprotokolle über Pakete sendet, die nach dem offenen Kommunikationsprotokoll konfiguriert sind.
  25. Industrielles Steuerungssystem nach Anspruch 19, wobei der Ein-/Ausgabeknoten Gerätesignale über ein standortunabhängiges Hardware-Kommunikationsadressierungsschema an die Steuerungen an den Steuerungsknoten übermittelt.
  26. Industrielles Steuerungssystem nach Anspruch 19, wobei der Ein-/Ausgabeknoten eine Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale, die in verschiedenen Kommunikationsprotokollschemata konfiguriert sind, in das offene Protokollkommunikationsnetz bündelt.
  27. Industrielles Steuerungssystem nach Anspruch 19, wobei der Ein-/Ausgabeknoten eine Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale von der Vielzahl von Feldgeräten über eine Vielzahl verschiedener Kommunikationsprotokolle empfängt, und die die Gerätesignale unter Verwendung eines selbstbeschreibenden Kommunikationsschemas im Kommunikationsnetz bündelt.
  28. Industrielles Steuerungssystem nach Anspruch 27, wobei das selbstbeschreibende Kommunikationsschema Gerätesignaldaten einschließt, die die Gerätesignale in einem ersten Kommunikationsprotokoll und Protokollbeschreibungssignale, die das erste Kommunikationsprotokoll beschreiben, einschließen.
  29. Industrielles Steuerungssystem mit einer Vielzahl von Feldgeräten, die physikalische Funktionen in einer industriellen Umgebung ausführen, Folgendes umfassend: einen Ein-/Ausgabeknoten, der einen Ein-/Ausgabeprozessor einschließt, der über einen oder mehrere Kommunikationskanäle an die Vielzahl von Feldgeräten innerhalb der industriellen Umgebung gekoppelt ist; eine Vielzahl von Steuerungsknoten, wobei jeder der Steuerungsknoten einen oder mehrere Prozessoren, einen oder mehrere Speicher, eine oder mehrere Steuerungen, die in dem einem oder den mehreren Speichern gespeichert und auf dem einen oder den mehreren Prozessoren ausführbar sind, um die Steuerung der Feldgeräte in der industriellen Umgebung auszuführen, einschließt; und ein Kommunikationsnetz, das den Ein-/Ausgabeknoten mit jedem des einen oder der mehreren Steuerungsknoten verbindet; wobei der Ein-/Ausgabeprozessor Gerätesignale von einem oder mehreren Feldgeräten in der industriellen Umgebung empfängt und die Gerätesignale im Kommunikationsnetz unter Verwendung eines standortunabhängigen Hardware-Kommunikationsadressierungsschemas platziert.
  30. Industrielles Steuerungssystem nach Anspruch 29, wobei das standortunabhängige Hardware-Kommunikationsadressierungsschema ein selbstbeschreibendes Kommunikationsschema umfasst.
  31. Industrielles Steuerungssystem nach Anspruch 30, wobei das selbstbeschreibende Kommunikationsschema Gerätesignaldaten einschließt, die die Gerätesignale in einem ersten Kommunikationsprotokoll und Protokollbeschreibungssignale, die das erste Kommunikationsprotokoll beschreiben, einschließen.
  32. Industrielles Steuerungssystem nach Anspruch 30, wobei das selbstbeschreibende Kommunikationsschema Gerätesignaldaten einschließt, die Gerätesignale in einem ersten Kommunikationsprotokoll und Protokollbeschreibungssignale, die das erste Kommunikationsprotokoll in Bezug auf eines der Feldgeräte beschreiben, einschließen, und Gerätesignaldaten einschließt, die Gerätesignale in einem zweiten Kommunikationsprotokoll und Protokollbeschreibungssignale, die das zweite Kommunikationsprotokoll in Bezug auf ein zweites Feldgerät beschreiben, einschließen.
  33. Industrielles Steuerungssystem nach Anspruch 30, wobei es sich bei dem Kommunikationsnetz um ein offenes Protokollkommunikationsnetz handelt.
  34. Industrielles Steuerungssystem nach Anspruch 33, wobei das offene Protokollkommunikationsnetz ein TCP/IP-paketbasiertes Netzwerkkommunikationsschema verwendet.
  35. Industrielles Steuerungssystem nach Anspruch 29, wobei einer der Steuerungsknoten ein virtueller Steuerungsknoten ist, der eine Vielzahl virtueller Steuerungen enthält, die von einem ersten der Prozessoren zu einem zweiten der Prozessoren an den Steuerungsknoten bewegbar ist.
  36. Industrielles Steuerungssystem nach Anspruch 35, wobei der Ein-/Ausgabeknoten Gerätesignale an die virtuellen Steuerungen kommuniziert, indem er Daten in einer Vielzahl verschiedener Kommunikationsprotokolle über Pakete sendet, die nach einem selbstbeschreibenden Kommunikationsschema konfiguriert sind.
  37. Industrielles Steuerungssystem nach Anspruch 29, wobei der Ein-/Ausgabeknoten eine Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale, die in verschiedenen Kommunikationsprotokollschemata konfiguriert sind, unter Verwendung des hardwarestandortunabhängigen Kommunikationsschemas in das Kommunikationsnetz bündelt.
  38. Industrielles Steuerungssystem nach Anspruch 29, wobei der Ein-/Ausgabeknoten eine Ein-/Ausgabekommunikationsroutine enthält, die Gerätesignale von einer Vielzahl von Feldgeräten über eine Vielzahl verschiedener Kommunikationsprotokolle empfängt, und die Gerätesignale im Kommunikationsnetz unter Verwendung eines selbstbeschreibenden Kommunikationsschemas bündelt.
  39. Industrielles Steuerungssystem nach Anspruch 29, bei dem Steuerungsknoten Steuerungssignale unter Verwendung eines hardwarestandortunabhängigen Kommunikationsadressierungsschemas über das Kommunikationsnetz senden.
DE112018002293.5T 2017-05-01 2018-04-30 Industrielles steuerungssystem mit offener architektur Pending DE112018002293T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762492895P 2017-05-01 2017-05-01
US62/492,895 2017-05-01
US201762500198P 2017-05-02 2017-05-02
US62/500,198 2017-05-02
PCT/US2018/030110 WO2018204225A1 (en) 2017-05-01 2018-04-30 Open architecture industrial control system

Publications (1)

Publication Number Publication Date
DE112018002293T5 true DE112018002293T5 (de) 2020-02-27

Family

ID=62186554

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018002293.5T Pending DE112018002293T5 (de) 2017-05-01 2018-04-30 Industrielles steuerungssystem mit offener architektur

Country Status (6)

Country Link
US (1) US11137745B2 (de)
JP (1) JP7257329B2 (de)
CN (1) CN110582732B (de)
DE (1) DE112018002293T5 (de)
GB (3) GB2575758B (de)
WO (1) WO2018204225A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019116120A1 (de) * 2019-06-13 2020-12-17 Endress+Hauser Process Solutions Ag Verfahren zum Bereitstellen eines digitalen Zwillings für ein nicht digitales Feldgerät der Automatisierungstechnik

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110612488A (zh) * 2017-05-03 2019-12-24 西门子股份公司 控制器内实现真实世界对象可见性和可及性的过程映像
EP3401742B1 (de) * 2017-05-09 2020-09-02 Siemens Aktiengesellschaft Automatisierungssystem und verfahren zum betrieb
DE102017110633B3 (de) * 2017-05-16 2018-11-15 Krohne Messtechnik Gmbh Anzeigegerät für die Prozessautomation
GB2568806B (en) * 2017-10-02 2022-04-06 Fisher Rosemount Systems Inc I/O virtualization for commissioning
WO2019193031A1 (de) * 2018-04-04 2019-10-10 Siemens Aktiengesellschaft Datenübertragung in zeitsensitiven datennetzen
WO2019209322A1 (en) * 2018-04-27 2019-10-31 Hewlett-Packard Development Company, L.P. Signals to i/o devices based on virtual computer messages
DE102018216111A1 (de) * 2018-09-21 2020-03-26 Robert Bosch Gmbh Übertragungsverfahren
CA3115709A1 (en) 2018-10-12 2020-04-16 Bray International, Inc. Smart valve with integrated electronics
US11451632B2 (en) * 2018-10-29 2022-09-20 Honeywell International Inc. System and method for supporting wired and wireless communications in industrial safety systems
CA3122267A1 (en) 2018-12-06 2020-06-11 Bray International, Inc. Smart valve adaptor with integrated electronics
CN109521746A (zh) * 2018-12-28 2019-03-26 西安西热锅炉环保工程有限公司 一种基于容错设计的dcs外挂智能控制系统及方法
EP3942373B1 (de) * 2019-03-22 2023-09-13 Northrop Grumman Systems Corporation Überwachungssystem für systemsteuerungsarchitektur
HUE065179T2 (hu) * 2019-04-02 2024-05-28 Gamma Digital Kft Eljárás hálózaton elosztott folyamatirányító rendszerben kommunikáció megvalósítására és hálózaton elosztott folyamatirányító rendszer
WO2020217441A1 (ja) * 2019-04-26 2020-10-29 三菱電機株式会社 データ処理装置、データ処理方法およびプログラム
US11422543B2 (en) 2019-06-10 2022-08-23 Fisher-Rosemount Systems, Inc. Virtualized real-time I/O in process control systems
GB2623651A (en) * 2019-06-10 2024-04-24 Fisher Rosemount Systems Inc Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems
GB2587842A (en) * 2019-06-10 2021-04-14 Fisher Rosemount Systems Inc Centralized virtualization management node in process control system
US11231701B2 (en) 2019-06-10 2022-01-25 Fisher-Rosemount Systems, Inc. Publish/subscribe protocol for real-time process control
GB2624788A (en) 2019-06-10 2024-05-29 Fisher Rosemount Systems Inc Virtualized real-time I/O in process control systems
GB2589941B (en) 2019-06-10 2024-03-27 Fisher Rosemount Systems Inc Ease of node switchovers in process control systems
US11249464B2 (en) * 2019-06-10 2022-02-15 Fisher-Rosemount Systems, Inc. Industrial control system architecture for real-time simulation and process control
CN110442097B (zh) * 2019-07-30 2024-03-29 南京国电南自维美德自动化有限公司 一种分散控制系统中模件地址自动识别装置和方法
US11635980B2 (en) * 2019-09-20 2023-04-25 Fisher-Rosemount Systems, Inc. Modular process control system
US11768878B2 (en) * 2019-09-20 2023-09-26 Fisher-Rosemount Systems, Inc. Search results display in a process control system
US11768877B2 (en) * 2019-09-20 2023-09-26 Fisher-Rosemount Systems, Inc. Smart search capabilities in a process control system
US11287808B2 (en) * 2019-10-31 2022-03-29 Honeywell International Inc. Industrial process control and automation system having decoupled controllers
MX2022008290A (es) 2020-01-03 2022-08-08 Bray Int Inc Valvula con celda de carga.
JP7287325B2 (ja) * 2020-03-26 2023-06-06 横河電機株式会社 制御システム、制御装置、及び、フィールド機器へのアクセス方法
JP7264098B2 (ja) * 2020-03-26 2023-04-25 横河電機株式会社 制御システム
US11762742B2 (en) 2020-03-31 2023-09-19 Honeywell International Inc. Process control system with different hardware architecture controller backup
CN111614719A (zh) * 2020-04-13 2020-09-01 广州市山水生态环保建设有限公司 远程自动控制系统及农村生活污水一体化控制系统
US11782410B2 (en) * 2020-06-06 2023-10-10 Honeywell International Inc. Building management system with control logic distributed between a virtual controller and a smart edge controller
KR102211876B1 (ko) * 2020-07-14 2021-02-03 강재종 기존 필드버스 기반 자동제어 시스템의 사물인터넷 연동 장치 및 방법
CN111830895B (zh) * 2020-07-14 2022-03-15 上海海得自动化控制软件有限公司 基于plc阵列的数据调度方法、介质、plc设备及调度系统
CN112180820A (zh) * 2020-08-31 2021-01-05 国电蚌埠发电有限公司 一种基于Modbus RTU通讯协议在EDPF-NT Plus系统中的应用方法
CN112087461B (zh) * 2020-09-11 2022-12-20 工业互联网创新中心（上海）有限公司 Modbus/tcp协议的数据在tsn网络中流转的系统、方法、装置及设备
US12066804B2 (en) 2020-09-22 2024-08-20 Rockwell Automation Technologies, Inc. Integrating container orchestration systems with operational technology devices
US11474873B2 (en) * 2020-09-22 2022-10-18 Rockwell Automation Technologies, Inc. Implementing serverless functions using container orchestration systems and operational technology devices
US11989084B2 (en) 2020-09-23 2024-05-21 Honeywell International Inc. Self-healing process control system
CN112217673A (zh) * 2020-09-30 2021-01-12 北京东土科技股份有限公司 控制器站间通信方法、装置、计算机设备及存储介质
US11874938B2 (en) 2020-11-03 2024-01-16 Honeywell International Inc. Admittance mechanism
CN112578755A (zh) * 2020-12-17 2021-03-30 上海通群科技有限公司 可编程智能控制器及基于可编程智能控制器的应用系统
CN112697293A (zh) * 2020-12-31 2021-04-23 上海自动化仪表有限公司 基于opcua的智能温度变送器
US11656609B2 (en) * 2021-01-14 2023-05-23 Fisher-Rosemount Systems, Inc. Detecting component degradation in industrial process plants based on loop component responsiveness
CN115225726B (zh) * 2021-03-31 2024-05-24 京东方科技集团股份有限公司 多协议终端的组网方法、通信方法、存储介质及电子设备
CN113433850B (zh) * 2021-06-04 2022-06-03 电子科技大学 一种fpga异态逻辑修复方法
US20220398122A1 (en) * 2021-06-14 2022-12-15 Monsanto Technology Llc Systems and methods for providing a virtual machine link to process controls
US11960588B2 (en) 2021-06-16 2024-04-16 Fisher-Rosemount Systems, Inc Security services in a software defined control system
US11726933B2 (en) * 2021-06-16 2023-08-15 Fisher-Rosemount Systems, Inc. I/O server services configured to facilitate control in a process control environment by containerized controller services
US12007747B2 (en) 2021-06-16 2024-06-11 Fisher-Rosemount Systems, Inc. Software defined process control system and methods for industrial process plants
US11789428B2 (en) 2021-06-16 2023-10-17 Fisher-Rosemount Systems, Inc. I/O server services for selecting and utilizing active controller outputs from containerized controller services in a process control environment
US12078977B2 (en) 2021-06-16 2024-09-03 Fisher-Rosemount Systems, Inc. Discovery service in a software defined control system
CN113923071B (zh) * 2021-07-28 2022-09-27 北京大学 基于tsn的hart总线交换机电路
US11601331B1 (en) * 2021-09-14 2023-03-07 Salesforce.Com, Inc. Dynamic hardware configuration
CN114200899B (zh) * 2021-11-16 2024-06-14 中国航空工业集团公司雷华电子技术研究所 一种多子系统控制方法及其系统电子设备、可读存储介质
JP2023090264A (ja) * 2021-12-17 2023-06-29 横河電機株式会社 制御システムおよび制御方法
CN114465845B (zh) * 2022-04-14 2022-08-12 深圳艾灵网络有限公司 基于现场总线的数据通信方法、装置、设备及存储介质

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06214601A (ja) * 1993-01-13 1994-08-05 Nissan Motor Co Ltd 設備制御装置のバックアップ装置
JPH0736516A (ja) * 1993-06-28 1995-02-07 Ricoh Co Ltd シミュレーション装置
JP3993243B2 (ja) * 1996-10-04 2007-10-17 フィッシャー コントロールズ インターナショナル リミテッド ライアビリティー カンパニー プロセス制御ネットワーク用のネットワークアクセス可能なインタフェース
US7392165B2 (en) * 2002-10-21 2008-06-24 Fisher-Rosemount Systems, Inc. Simulation system for multi-node process control systems
US7865251B2 (en) * 2003-01-28 2011-01-04 Fisher-Rosemount Systems, Inc. Method for intercontroller communications in a safety instrumented system or a process control system
US8006056B2 (en) * 2004-01-30 2011-08-23 Hewlett-Packard Development Company, L.P. Storage system including capability to move a virtual storage device group without moving data
US7305520B2 (en) * 2004-01-30 2007-12-04 Hewlett-Packard Development Company, L.P. Storage system with capability to allocate virtual storage segments among a plurality of controllers
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
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
US7684875B2 (en) 2007-02-02 2010-03-23 Fisher-Rosemount Systems, Inc. Methods and apparatus to configure process control system inputs and outputs
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
EP2224300B1 (de) * 2009-02-27 2018-07-11 Siemens Aktiengesellschaft Verfahren zur Bereitstellung von Datenzugriff in einem industriellen Automatisierungssystem, Computerprogrammprodukt und industrielles Automatisierungssystem
US20120297461A1 (en) * 2010-12-02 2012-11-22 Stephen Pineau System and method for reducing cyber crime in industrial control systems
CN102684720B (zh) * 2011-03-09 2016-09-14 费希尔控制国际公司 用于在过程控制或监测环境中进行无线通信的方法和装置
US9191203B2 (en) * 2013-08-06 2015-11-17 Bedrock Automation Platforms Inc. Secure industrial control system
US9727511B2 (en) * 2011-12-30 2017-08-08 Bedrock Automation Platforms Inc. Input/output module with multi-channel switching capability
US20140229945A1 (en) * 2013-02-12 2014-08-14 Contextream Ltd. Network control using software defined flow mapping and virtualized network functions
US9378162B2 (en) * 2013-05-21 2016-06-28 Arm Limited Handling and routing interrupts to virtual processors
JP5895906B2 (ja) 2013-07-24 2016-03-30 横河電機株式会社 プロセス制御装置及びシステム並びにその健全性判定方法
JP2015026279A (ja) 2013-07-26 2015-02-05 株式会社東芝 プラント監視制御装置及びプログラム
JP6020476B2 (ja) * 2014-01-20 2016-11-02 横河電機株式会社 プロセス制御装置及びその更新方法
WO2015169352A1 (en) * 2014-05-07 2015-11-12 Abb Technology Ltd Flexible controller utilization in a process control system
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
US20160274930A1 (en) * 2015-03-16 2016-09-22 Honeywell International Inc. Method and apparatus for an on-process migration in a virtual environment within an industrial process control and automation system
KR101811332B1 (ko) 2015-03-25 2018-01-30 주식회사 에프티넷 내식성이 향상된 열교환기 튜브 및 파이프용 알루미늄 합금, 그 합금을 이용한 알류미늄 튜브 또는 배관의 제조방법 및 이를 이용한 열교환기 시스템
EP3352423B1 (de) * 2015-09-17 2020-08-19 Kabushiki Kaisha Yaskawa Denki Industrievorrichtung und kommunikationsverfahren
AU2016337406A1 (en) 2015-10-13 2018-05-17 Schneider Electric Industries Sas Software defined automation system and architecture
JP7171713B2 (ja) * 2017-11-16 2022-11-15 インテル・コーポレーション 分散型のソフトウェア定義型産業システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019116120A1 (de) * 2019-06-13 2020-12-17 Endress+Hauser Process Solutions Ag Verfahren zum Bereitstellen eines digitalen Zwillings für ein nicht digitales Feldgerät der Automatisierungstechnik

Also Published As

Publication number Publication date
US11137745B2 (en) 2021-10-05
US20180321662A1 (en) 2018-11-08
JP7257329B2 (ja) 2023-04-13
GB2608035A (en) 2022-12-21
CN110582732B (zh) 2023-06-02
CN110582732A (zh) 2019-12-17
JP2020518921A (ja) 2020-06-25
WO2018204225A1 (en) 2018-11-08
GB2575758B (en) 2023-04-12
GB201915675D0 (en) 2019-12-11
GB2605871A (en) 2022-10-19
GB2575758A (en) 2020-01-22
GB202212319D0 (en) 2022-10-05
GB2605871B (en) 2023-02-08
GB202201357D0 (en) 2022-03-16
GB2608035B (en) 2023-03-22

Similar Documents

Publication Publication Date Title
DE112018002293T5 (de) Industrielles steuerungssystem mit offener architektur
DE102020115456A1 (de) Derzentralisierter virtualisierungsverwaltungsknoten in prozessleitsystemen
DE102020124484A1 (de) Modulares prozesssteuerungssystem
DE102020124789A1 (de) Hyperkonvergente architektur für industrieleitsystem
EP1738236B1 (de) Automatisierungsnetzwerk mit zustandsmeldenden netzwerkkomponenten
DE102020115439A1 (de) Industrielle steuerungssystemarchitektur für echtzeitsimulation und prozesssteuerung
DE102018120345A1 (de) Hochleistungssteuerungsserversystem
DE102007001576A1 (de) Verfahren zur Synchronisierung redundanter Steuerungen für stoßfreies Failover unter normalen Bedingungen und bei Fehlanpasssung
DE10159697A1 (de) Redundante Einrichtungen in einem Prozesssteuersystem
DE102020115483A1 (de) Veröffentlichungs-/Abonnements-Protokoll für die Echtzeit-Prozesssteuerung
DE102022114306A1 (de) E/a-serverdienste, die so konfiguriert sind, dass sie die steuerung in einer prozesssteuerungsumgebung durch containerisierte steuerungsdienste erleichtern
DE102022114267A1 (de) Systeme und verfahren zur dynamischen aufrechterhaltung der redundanz und des lastausgleichs in softwaredefinierten steuerungssystemen für industrielle prozessanlagen
DE102022114256A1 (de) Systeme und verfahren zur dynamisch aufrechterhaltenen redundanz und zum lastausgleich in softwaredefinierten steuerungssystemen für industrielle prozessanlagen
DE102022115155A1 (de) Visualisierung eines softwaredefinierten prozesssteuerungsystems für industrielle prozessanlagen
DE102022114391A1 (de) Suchdienst in einem softwaredefinierten Steuerungssystem
DE102020115471A1 (de) Virtualisierte echtzeit-i/o in prozessleitsystemen
DE102021127384A1 (de) Industrielles prozesssteuerungssystem als rechenzentrum einer industriellen prozessanlage
DE102022114301A1 (de) Software-definiertes prozesssteuerungssystem für industrielle prozessanlagen
DE102013111052A1 (de) System zum flexiblen Betreiben einer Automatisierungsanlage
DE102022114380A1 (de) Sicherheitsdienste in einem softwaredefinierten steuerungssystem
DE102022114305A1 (de) E/a serverdienste zur auswahl und verwendung aktiver steuerungsausgänge von containerisierten steuerungsdiensten in einer prozesssteuerungsumgebung
DE102022114541A1 (de) Suchdienst in einem softwaredefinierten steuerungssystem
DE102022114799A1 (de) Systeme und verfahren zur zuordnung von modulen in einem softwaredefinierten steuerungssystem für industrielle prozessanlagen
DE102022114542A1 (de) Suchdienst in einem softwaredefinierten steuerungssystem
DE102020115508A1 (de) Automatischer lastausgleich und leistungsausgleich von virtuellen knoten, die eine echtzeitsteuerung ausführen, in prozessleitsystemen

Legal Events

Date Code Title Description
R012 Request for examination validly filed