DE102020100854A1

DE102020100854A1 - System zur sicheren Erfassung von Systemen nicht vertrauenswürdiger Datenquellen, die aus gemeinsamen Quellen stammen

Info

Publication number: DE102020100854A1
Application number: DE102020100854.6A
Authority: DE
Inventors: Mark J. Nixon; Anthony Amaro jun.; Gang Wang
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2019-01-15
Filing date: 2020-01-15
Publication date: 2020-07-16
Also published as: GB2582421B; US11115218B2; US20200228342A1; GB2582421A; GB202000573D0; CN111435242A; JP2020113283A

Abstract

Um eine vertrauenswürdige, sichere und unveränderliche Aufzeichnung von Transaktionen innerhalb einer Prozessanlage zu ermöglichen, werden hier Techniken zur Verwendung eines verteilten Ledgers in Prozesssteuerungssystemen beschrieben. Das verteilte Ledger kann von Knoten verwaltet werden, die Transaktionen empfangen, die von Feldgeräten, Steuerungen, Betreiberarbeitsstationen oder anderen Geräten, die in der Prozessanlage arbeiten, gesendet werden. Zu den Transaktionen können Prozessanlagendaten gehören, wie z. B. Prozessparameterdaten, Produktparameterdaten, Konfigurationsdaten, Benutzerinteraktionsdaten, Wartungsdaten, Inbetriebnahmedaten, Anlagennetzwerkdaten und Produktverfolgungsdaten. Die verteilten Ledger sind ebenfalls zur Ausführung von intelligenten Verträgen geeignet, damit Maschinen wie Feldgeräte ohne menschliches Zutun selbstständig arbeiten können. Auf diese Weise können aufgezeichnete Prozessparameterwerte und Produktparameterwerte abgerufen werden, um die Qualität der Produkte zu überprüfen. Darüber hinaus können Regulierungsdaten als Reaktion auf auslösende Ereignisse aufgezeichnet werden, sodass die Regulierungsbehörden die Daten überprüfen können.

Description

TECHNISCHER BEREICH
Die vorliegende Offenlegung bezieht sich im Allgemeinen auf Prozessanlagen und auf Prozessleitsysteme und im Besonderen auf die Verwendung von verteilten Ledgern in Prozessleitsystemen zur Aufzeichnung von Daten und Ereignissen.
HINTERGRUND
Verteilte Prozessleitsysteme, wie sie in Chemie-, Mineralöl- oder anderen Prozessanlagen eingesetzt werden, umfassen typischerweise einen oder mehrere Prozesssteuerungen, die über analoge, digitale oder kombinierte Analog-/Digitalbusse oder über eine drahtlose Kommunikationsverbindung oder ein Netzwerk mit einem oder mehreren Feldgeräten kommunikativ gekoppelt sind. Die Feldgeräte, die z. B. Armaturen, Stellungsregler, Schalter und Transmitter (z. B. Temperatur-, Druck-, Füllstands- und Durchflusssensoren) sein können, befinden sich innerhalb der Prozessumgebung und übernehmen in der Regel physische oder prozess steuernde Funktionen wie z. B. das Öffnen oder Schließen von Armaturen, die Messung von Prozessparametern wie Druck, Temperatur usw., um einen oder mehrere Prozesse innerhalb der Prozessanlage oder des Systems zu steuern. Intelligente Feldgeräte, wie z. B. die Feldgeräte, die dem bekannten Feldbusprotokoll entsprechen, können auch Steuerungsberechnungen, Alarmfunktionen und andere Steuerungsfunktionen durchführen, die üblicherweise in der Steuerung implementiert sind. Die Prozesssteuerungen, die sich ebenfalls typischerweise in der Anlagenumgebung befinden, empfangen Signale, die für die von den Feldgeräten durchgeführten Prozessmessungen und/oder andere zu den Feldgeräten gehörende Informationen kennzeichnend sind, und führen eine Steuerungsanwendung aus, in der z. B. verschiedene Steuermodule laufen, die Entscheidungen zur Prozesssteuerung treffen, anhand der empfangenen Informationen Steuersignale erzeugen und sich mit den in den Feldgeräten durchgeführten Steuermodulen oder -blöcken, wie z. B. HART®, WirelessHART® und FOUNDATION® Feldbus-Feldgeräten, koordinieren. 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. Die hier verwendeten Feldgeräte und Steuerungen werden allgemein als „Prozesssteuergeräte“ bezeichnet.
Informationen von den Feldgeräten und der Steuerung werden in der Regel über eine Datenautobahn einem oder mehreren anderen Hardwaregeräten zur Verfügung gestellt, wie z. B. Betreiberarbeitsstationen, PCs oder Computergeräten, Datenhistorikem, Berichtsgeneratoren, zentralisierten Datenbanken oder anderen zentralisierten administrativen Computergeräten, die typischerweise in Kontrollräumen oder an anderen Orten abseits der raueren Anlagenumgebung platziert sind. Jedes dieser Hardwaregeräte ist typischerweise in der gesamten Prozessanlage oder in einem Teil der Prozessanlage zentral eingebunden. Auf diesen Hardwaregeräten laufen Anwendungen, mit denen ein Benutzer z. B. Funktionen zur Steuerung eines Prozesses und/oder zum Betrieb der Prozessanlage ausführen kann, wie z. B. die Änderung von Einstellungen der Prozesssteuerungsroutine, die Änderung der Bedienung der Steuermodule in den Reglern oder den Feldgeräten, die Anzeige des aktuellen Prozesszustands, die Anzeige von Alarmen, die von Feldgeräten und Reglern erzeugt werden, die Simulation des Prozessbetriebs für Schulungen des Personals oder den Test der Prozesssteuerungssoftware, die Pflege und Aktualisierung einer Konfigurationsdatenbank usw. Die von den Hardwaregeräten, Reglern und Feldgeräten genutzte Datenautobahn kann einen drahtgebundenen Kommunikationspfad, einen drahtlosen Kommunikationspfad oder eine Kombination aus drahtgebundenen und drahtlosen Kommunikationspfaden umfassen.
Das von Emerson Process Management vertriebene Leitsystem DeltaV™ umfasst beispielsweise mehrere Anwendungen, die in verschiedenen Geräten an verschiedenen Stellen einer Prozessanlage gespeichert sind und von diesen ausgeführt werden. Eine Konfigurationsanwendung, die sich in einer oder mehreren Arbeitsstationen oder Computergeräten befindet, ermöglicht es dem Anwender, Prozesssteuerungsmodule zu erstellen oder zu ändern und diese Prozesssteuerungsmodule über eine Datenautobahn zu dezidierten verteilten Steuerungen herunterzuladen. Üblicherweise bestehen diese Steuermodule aus kommunikativ miteinander verbundenen Funktionsblöcken, die Objekte in einem objektorientierten Programmierprotokoll sind, die Funktionen innerhalb des Steuerschemas auf der Basis von Eingängen dazu ausführen und die Ausgänge zu anderen Funktionsblöcken innerhalb des Steuerschemas bereitstellen. Mit der Konfigurationsanwendung kann ein Konfigurationsdesigner auch Bedienoberflächen erstellen oder ändern, die von einer Anzeigeanwendung verwendet werden, um einem Betreiber Daten anzuzeigen und es dem Betreiber zu ermöglichen, Einstellungen, wie z. B. 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 einem oder mehreren Betreiberarbeitsstationen (oder auf einem oder mehreren Remote-Computergeräten in kommunikativer Verbindung mit den Betreiberarbeitsstationen und der Datenautobahn) ausgeführt werden können, empfangen Daten von der Steuerungsanwendung über die Datenautobahn und zeigen diese Daten den Konstrukteuren von Prozesssteuerungssystemen, den Betreibern oder den Benutzern, die die Benutzerschnittstellen verwenden, an. Sie können eine beliebige Anzahl verschiedener Ansichten, wie z. B. die Ansicht eines Betreibers, eines Ingenieurs, eines Technikers usw., bereitstellen. Eine Datenhistoriker-Anwendung wird normalerweise in einer Datenhistorikervorrichtung gespeichert und ausgeführt, die einige oder alle über die Datenautobahn bereitgestellten Daten sammelt und speichert, während eine Konfigurationsdatenbank-Anwendung auf einem 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 sich die Konfigurationsdatenbank auf der gleichen Arbeitsstation wie die Konfigurationsanwendung befinden.
Im Allgemeinen umfasst ein Prozessleitsystem einer Prozessanlage Feldgeräte, Steuerungen, Arbeitsstationen und andere Geräte, die durch eine Reihe von Schichtnetzwerken und Bussen miteinander verbunden sind. Das Prozessleitsystem kann wiederum mit verschiedenen geschäftlichen und externen Netzwerken verbunden werden, z. B. zur Senkung der Herstellungs- und Betriebskosten, zur Steigerung der Produktivität und Effizienz, zur zeitnahen Bereitstellung zur Prozesssteuerung und/oder zur Verarbeitung von Anlageninformationen, usw. Andererseits erhöht die Verbindung von Prozessanlagen und/oder Prozessleitsystemen mit Unternehmens- und/oder externen Netzwerken und Systemen das Risiko von Cyber-Einbrüchen und/oder böswilligen Cyber-Angriffen, die sich aus erwarteten Schwachstellen in kommerziellen Systemen und Anwendungen, wie sie z. B. in Unternehmens- und/oder externen Netzwerken verwendet werden, ergeben können. Cyber-Einbrüche und böswillige Cyber-Angriffe auf Prozessanlagen, Netzwerke und/oder Steuersysteme können die Vertraulichkeit, Integrität und/oder Verfügbarkeit von Informationswerten beeinträchtigen, die im Allgemeinen ähnliche Schwachstellen wie in Allzweck-Computemetzwerken darstellen. Im Gegensatz zu Allzweck-Computernetzwerken können Cyber-Einbrüche in Prozessanlagen, Netzwerke und/oder Steuerungssysteme jedoch auch zur Beschädigung, Zerstörung und/oder zum Verlust nicht nur von Anlagen, Produkten und anderen physischen Vermögenswerten, sondern auch zum Verlust von Menschenleben führen. Zum Beispiel kann ein Cyber-Einbruch dazu führen, dass ein Prozess unkontrolliert wird und dadurch Explosionen, Brände, Überschwemmungen, Exposition gegenüber gefährlichen Stoffen usw. verursacht. Daher ist die Sicherung der Kommunikation in Bezug auf Prozesssteuerungsanlagen und -systeme von größter Bedeutung.
ZUSAMMENFASSUNG
Es werden Techniken, Systeme, Apparate, Komponenten, Geräte und Verfahren zur Verwendung eines verteilten Ledgers oder einer Blockchain in Prozesssteuerungssystemen offengelegt. Die genannten Techniken, Systeme, Apparate, Komponenten, Geräte und Verfahren können auf industrielle Prozesssteuerungssysteme, Umgebungen und/oder Anlagen angewendet werden, die hier austauschbar als „industrielle Steuerung“, „Prozesssteuerung“ oder „Prozess“-Systeme, Umgebungen und/oder Anlagen bezeichnet werden. Üblicherweise bieten solche Systeme und Anlagen eine verteilte Steuerung eines oder mehrerer Prozesse, die zur Herstellung, Verbesserung, Umwandlung, Erzeugung oder Produktion von physischen Materialien oder Produkten eingesetzt werden.
Beispielsweise kann in einem Prozesssteuerungssystem ein verteiltes Ledger durch Knoten geführt werden, die hier als „Edge-Gateways“ bezeichnet werden. Die Knoten empfangen Transaktionen, die von Feldgeräten, Steuerungen, Bedienstationen oder anderen Geräten, die in der Prozessanlage arbeiten, in ein verteiltes Ledger-Netzwerk übertragen werden. In einigen Szenarien enthalten die Transaktionen Prozessparameterwerte für Prozessparameter, die einer Prozessanlageneinheit entsprechen. Zu einer Prozessanlageneinheit können Vorrichtungen innerhalb einer Prozessanlage zur Verwendung in einem Teil des Prozesses gehören, die physische Materialien enthalten, umwandeln, erzeugen oder übertragen, wie z. B. ein Ventil, ein Tank, ein Mischer, eine Pumpe, ein Wärmetauscher usw. Die Transaktionen können auch Werte von Produktparametern wie Eigenschaften eines physischen Materials oder eines von der Prozessanlage hergestellten Produkts umfassen, einschließlich der Temperatur des Produkts, des Produktvolumens, der Masse des Produkts, der Dichte des Produkts, des Drucks des Produkts usw.
Die aufgezeichneten Prozessparameterwerte und Produktparameterwerte können dann abgerufen werden, um die Qualität eines Produkts zu überprüfen. Beispielsweise kann eine erste Prozessanlage ein Produkt herstellen, verfeinern, umwandeln, erzeugen oder produzieren, das dann an eine zweite Prozessanlage geliefert wird. Die zweite Prozessanlage kann bestimmen, dass das Produkt bestimmte Qualitätsstandards erfüllt, indem sie die aufgezeichneten Prozessparameterwerte und Produktparameterwerte aus dem verteilten Ledger abruft. Zusätzlich können regulatorische Daten im verteilten Ledger erfasst werden. Beispielsweise können als Reaktion auf ein auslösendes Ereignis wie einen Alarm, einen Fehler, ein Leck, ein Reparaturereignis, einen Prozessmeilenstein, eine Korrekturmaßnahme usw. Prozesssteuerelemente wie Feldgeräte oder Steuerungen Transaktionen mit Daten aus dem auslösenden Ereignis generieren, wie z. B. den Zeitpunkt des Auftretens des Ereignisses, die Dauer des Ereignisses, Prozessparameterwerte für am Ereignis beteiligte Anlagenteile, Produktparameterwerte für am Ereignis beteiligte Produkte usw. Die Regulierungsdaten werden dann im verteilten Ledger erfasst, sodass die Regulierungsbehörden die Daten überprüfen können.
Darüber hinaus können verteilte Ledger für die Ausführung von intelligenten Verträgen genutzt werden, die nachstehend näher beschrieben werden. Prozesssteuerungssysteme können intelligente Verträge für das verteilte Ledger bereitstellen, um Werte auszutauschen, z. B. bei Erhalt eines Produkts in gutem Zustand. Intelligente Verträge können auch für das verteilte Ledger bereitgestellt werden, damit Maschinen wie Feldgeräte ohne menschliches Eingreifen selbstständig Transaktionen durchführen können. Beispielsweise kann nach den Bedingungen eines intelligenten Vertrags ein Rechengerät in einer ersten Prozessanlage einem Rechengerät in einer zweiten Prozessanlage automatisch einen vorgegebenen Token-Betrag bereitstellen, wenn es von einem oder mehreren Feldgeräten in der ersten Prozessanlage Meldungen erhält, dass ein Produkt von der zweiten Prozessanlage geliefert wurde und das Produkt bestimmte Qualitätsstandards erfüllt. Intelligente Verträge können auch in Prozessanlagen für eine Vielzahl weiterer Anwendungen eingesetzt werden, die nachfolgend näher beschrieben werden.
Durch die Verwendung von verteilten Ledgern und in einigen Szenarien, intelligenten Verträgen in Prozessanlagen, bietet jede Prozessanlage oder ein Netzwerk von Prozessanlagen eine vertrauenswürdige, sichere und unveränderliche Aufzeichnung von Transaktionen innerhalb der Prozessanlage. Die sichere, unveränderliche und vertrauenswürdige Natur von verteilten Ledgern ist besonders in Prozesssteuerungssystemen wichtig, in denen Cyber-Einbrüche nicht nur zur Beschädigung, Zerstörung und/oder zum Verlust von Anlagen, Produkten und anderen physischen Vermögenswerten, sondern auch von Menschenleben führen können. Zusätzlich sind Prozessanlagen mit Hilfe von verteilten Ledgern in der Lage, die Produktlinie von den Rohstoffen bis zu den fertigen Produkten zu verfolgen und die Produkte nach der Herstellung weiter zu verfolgen. Darüber hinaus können bei der Nutzung oder Übertragung einer gemeinsamen Ressource durch konkurrierende Unternehmen verteilte Konten verwendet werden, um die Menge der von einer der Entitäten genutzten Ressource und eine angemessene Vergütung an die konkurrierende Einheit für die Nutzung der Ressource zu bestimmen. Beispielsweise kann eine Ölraffinerie Öl produzieren, das über eine Ölpipeline an mehrere Einheiten oder Prozessanlagen geliefert wird. Jede Prozessanlage ist für die Vergütung der Ölraffinerie für die Ölmenge verantwortlich, die die Prozessanlage über die Ölpipeline erhalten hat. Verteilte Ledger sind dazu geeignet, die Menge des Öls, die jede Prozessanlage von Geräten erhält, zu erfassen und die Ölmenge zum Zeitpunkt der Bereitstellung des Öls zu messen. Aufgrund der Schwierigkeit, die erfassten Daten in den verteilten Ledgern zu ändern, müssen konkurrierende Einheiten nicht darauf vertrauen, dass die Daten zuverlässig sind.
Figurenliste

1 ist ein Blockschaltbild einer beispielhaften Prozessanlage oder eines Prozesssteuerungssystems, das u. a. die Zusammenhänge zwischen verschiedenen Beispielkomponenten des Prozessteuerungssystems, dem Prozessteuerungssystem selbst und anderen beispielhaften Systemen und/oder Netzwerken veranschaulicht;
2 ist ein Blockschaltbild einer beispielhaften Sicherheitsarchitektur für eine Prozessanlage oder ein Prozesssteuerungssystem;
3 ist ein beispielhaftes verteiltes Ledger-System zur Aufzeichnung von Transaktionen und zur Ausführung von intelligenten Verträgen in einem Prozesssteuerungssystem;
4 zeigt die beispielhafte Validierung von Netzknoten und einen beispielhaften Transaktionsfluss auf einem verteilten Ledger-Netzwerk in einem Prozesssteuerungssystem;
5 zeigt beispielhafte Komponenten eines Netzknotens auf einem verteilten Ledger-Netzwerk in einem Prozessleitsystem;
6A zeigt ein Beispiel für ein verteiltes Ledger mit einer Blockchain mit Blöcken von Transaktionen in einem Prozesssteuerungssystem;
6B zeigt ein weiteres Beispiel für ein verteiltes Ledger, das mehrere Side-Blockchains oder Sidechains enthält, die von verschiedenen Prozessanlagen verwaltet werden, sowie eine Haupt-Blockchain, die von mehreren Prozessanlagen verwaltet wird und die Transaktionsdaten aus den Sidechains enthält;
7A zeigt ein weiteres Beispiel für ein verteiltes Ledger mit mehreren lokalen Blockchains, die jeweils von einer anderen Prozessanlage verwaltet werden;
7B zeigt eine globale Blockchain für eine Prozessanlage, die von mehreren Prozessanlagen verwaltet wird und Blöcke aus der lokalen Blockchain umfasst;
7C zeigt eine Super-Blockchain, die von mehreren Prozessanlagen verwaltet wird und Blöcke aus jeder der globalen Blockchains für jede Prozessanlage umfasst;
8 zeigt einen beispielhaften Status eines intelligenten Vertrags in einem verteilten Ledger-Netzwerk zur Durchführung sicherer Schreiboperationen in einer Prozessanlage, um einen Prozessparameter in ein Gerät des Sicherheitssystems (SIS) zu schreiben;
9 zeigt eine beispielhafte Transaktion, die eine Beweis-Transaktion darstellt, die von einem Beweis-Orakel generiert wurde, das ein Feldgerät ist, das die Ölmenge, die von einer Ölpipeline erhalten wurde, meldet;
10 zeigt eine beispielhafte Transaktion, die eine Beweis-Transaktion darstellt, die von einem Beweis-Orakel generiert wurde, das ein Computergerät ist, das ein Software- oder Firmware-Update meldet;
11 illustriert eine beispielhafte Transaktion, die eine Beweis-Transaktion darstellt, die von einem Beweis-Orakel generiert wurde, das eine Prozessanlageneinheit ist, die Prozessparameter oder Produktparameterdaten meldet;
12 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren zur Datenerfassung in einem Prozesssteuerungssystem mit einem verteilten Ledger darstellt;
13 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren zur sicheren Erfassung von nicht vertrauenswürdigen Daten in Prozessleitsystemen mit Hilfe eines verteilten Ledgers darstellt;
14 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren zur Erfassung von Qualitätskontroll-, Produktions- oder Regulierungsdaten in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers darstellt;
15 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren zur Erfassung von Zuständen von Software oder Firmware in einem Prozesssteuerungssystem und angeschlossener Instrumentierung mit Hilfe eines verteilten Ledgers darstellt;
16 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren zur Erstellung von intelligenten Verträgen in einem Prozesssteuerungssystem unter Verwendung eines verteilten Ledgers darstellt; und
17 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren zur Interaktion mit einem intelligenten Vertrag in einem Prozesssteuerungssystem unter Verwendung eines verteilten Ledgers darstellt.

DETAILLIERTE BESCHREIBUNG
Ein verteiltes Ledger ist ein Speichermechanismus für Daten, Ereignisse, Transaktionen usw., der von mehreren Teilnehmern verwaltet wird. Genauer gesagt, stellt ein verteiltes Ledger eine Möglichkeit dar, einen verteilten Konsens über die Gültigkeit oder Ungültigkeit der im verteilten Ledger erfassten Informationen zu erreichen. Mit anderen Worten, das verteilte Ledger bietet den Teilnehmern und Beobachtern ein dezentrales Vertrauen. Im Gegensatz zu einer zentralen Instanz ist ein verteiltes Ledger eine dezentralisierte Datenbank, in der ein transaktionaler Satz von Änderungen des Ledgers von jedem Knoten eines Peer-to-Peer-Netzwerks gepflegt und validiert wird. Ein Typ des verteilten Ledgers, eine Blockchain, besteht aus Gruppierungen von Transaktionen, die in einem „Block“ organisiert und sequentiell geordnet sind (daher der Begriff „Blockchain“). Während die hier besprochenen verteilten Ledger im Rahmen einer Blockchain erwähnt werden, ist dies nur ein Beispiel für ein verteiltes Ledger. Verteilte Ledger können auch ein Gewirr, ein Blockgitter oder einen anderen gerichteten azyklischen Graphen (DAG) enthalten. In jedem Fall können Knoten im Laufe der Zeit dem Blockchain-Netzwerk beitreten und es verlassen, und sie können Blöcke von Peer-Knoten erhalten, die sich während der Abwesenheit des Knotens verbreitet haben. Knoten können Adressen anderer Knoten verwalten und Adressen bekannter Knoten untereinander austauschen, um die Verbreitung neuer Informationen über das Netzwerk in einer dezentralisierten, peer-to-peer-Weise zu vereinfachen.
Die Knoten, die sich das Ledger teilen, bilden das so genannte verteilte Ledger-Netzwerk. Die Knoten im Netzwerk des verteilten Ledgers validieren Änderungen an der Blockchain (z. B. wenn eine neue Transaktion und/oder ein neuer Block angelegt wird) nach einem Konsens-Regelwerk. Die Konsens-Regeln hängen von den Informationen ab, die von der Blockchain verfolgt werden, und können Regeln für die Chain selbst enthalten. Beispielsweise kann eine Konsens-Regel beinhalten, dass der Urheber einer Änderung einen Identitätsnachweis liefert, sodass nur zugelassene Einheiten Änderungen an der Chain veranlassen dürfen. Eine Konsens-Regel kann verlangen, dass Blöcke und Transaktionen Formatvorgaben einhalten und bestimmte Metainformationen zur Änderung liefern (z. B. Blöcke müssen unterhalb einer Größengrenze liegen, Transaktionen müssen eine Anzahl von Feldern enthalten, usw.). Die Konsens-Regeln können einen Mechanismus zur Festlegung der Reihenfolge enthalten, in der neue Blöcke in die Chain eingefügt werden (z. B. durch ein Proof-of-Work-System, Proof-of-Sake usw.).
Zusätze zur Blockchain, die die Konsens-Regeln erfüllen, werden von Knoten, die den Zusatz validiert haben, an andere Knoten, die dem validierenden Knoten bekannt sind, weitergeleitet. Wenn alle Knoten, die eine Änderung an der Blockchain erhalten, den neuen Block validieren, spiegelt das verteilte Ledger die neue Änderung so wider, wie sie auf allen Knoten gespeichert ist, wobei man sagen kann, dass ein verteilter Konsensus in Bezug auf den neuen Block und die darin enthaltenen Informationen erreicht wurde. Jede Änderung, die die Konsens-Regel nicht erfüllt, wird durch die Validierung der Knoten, die die Änderung erhalten, ignoriert und die Änderung wird nicht an andere Knoten weitergegeben. Dementsprechend kann eine einzelne Partei im Gegensatz zu einem klassischen System, das eine zentrale Instanz nutzt, das verteilte Ledger nicht einseitig ändern, es sei denn, die einzelne Partei kann dies in einer Weise tun, die den Konsens-Regeln entspricht. Die Unfähigkeit, vergangene Transaktionen zu verändern, führt dazu, dass Blockchains allgemein als vertrauenswürdig, sicher und unveränderlich beschrieben werden.
Die Validierungsaktivitäten von Knoten, die Konsens-Regeln in einem Blockchain-Netzwerk anwenden, können verschiedene Formen annehmen. In einer Ausführung kann die Blockchain als eine gemeinsame Tabelle betrachtet werden, die Daten wie z. B. der Besitz von Assets verfolgt. In einer anderen Ausführung führen die validierenden Knoten den Code aus, der in „intelligenten Verträgen“ enthalten ist, und der verteilte Konsensus wird dadurch ausgedrückt, dass sich die Netzwerkknoten über die Ausgabe des ausgeführten Codes einigen.
Ein intelligenter Vertrag ist ein Computerprotokoll, das die automatische Ausführung und/oder Durchsetzung einer Vereinbarung zwischen verschiedenen Parteien ermöglicht. Insbesondere kann der intelligente Vertrag ein Computercode sein, der sich an einer bestimmten Adresse auf der Blockchain befindet. In einigen Fällen kann der intelligente Vertrag automatisch ablaufen, wenn ein Teilnehmer der Blockchain Gelder (z. B. eine Kryptowährung wie Bitcoin, Ether oder eine andere digitale/virtuelle Währung) an die Adresse sendet, an der der intelligente Vertrag gespeichert ist. Zusätzlich können intelligente Verträge einen Saldo der Geldmittel, die an ihrer Adresse gespeichert sind, aufrechterhalten. In einigen Szenarien, wenn dieser Saldo Null erreicht, ist der intelligente Vertrag möglicherweise nicht mehr funktionsfähig.
Der intelligente Vertrag kann eine oder mehrere Auslösebedingungen beinhalten, die, wenn sie erfüllt sind, einer oder mehreren Aktionen entsprechen. Bei einigen intelligenten Verträgen kann/können die durchgeführte(n) Aktion(en) auf der Grundlage einer oder mehrerer Entscheidungsbedingungen bestimmt werden. In einigen Fällen können Datenströme an den intelligenten Vertrag geleitet werden, sodass der intelligente Vertrag das Eintreten einer Auslösebedingung erkennen und/oder eine Entscheidungsbedingung analysieren kann.
Blockchains können öffentlich, dezentral und genehmigungsfrei eingesetzt werden, was bedeutet, dass jede Partei das verteilte Ledger einsehen, neue Informationen zum Ledger hinzufügen oder dem Netzwerk als Validierungsknoten beitreten kann. Andere Blockchains sind privat (z. B. Permissioned Ledgers), die Chain-Daten zwischen einer Gruppe von Einheiten geheim halten, die zur Teilnahme am Blockchain-Netzwerk berechtigt sind. Andere Blockchain-Implementierungen können sowohl zulässig als auch unzulässig sein, wobei die Teilnehmer möglicherweise validiert werden müssen, wobei jedoch nur die Informationen veröffentlicht werden, die die Teilnehmer des Netzwerks veröffentlichen möchten.
In einigen Ausführungen enthält ein verteiltes Ledger mehrere Blockchains, wie z. B. eine Haupt-Blockchain und mehrere unabhängig von der Haupt-Blockchain arbeitende Sidechains. Die Sidechains interagieren dann mit der Haupt-Blockchain, um einige der Transaktionsdaten von den Sidechains an die Haupt-Blockchain zu liefern. Auf diese Weise können die Sidechains privat sein, während die Haupt-Blockchain öffentlich ist oder einer größeren Anzahl von Einheiten als die Side-Chains zur Verfügung steht. Nicht sensible Informationen aus den Side-Chains können in der Haupt-Blockchain freigegeben werden. Ebenso enthält ein verteiltes Ledger in einigen Ausführungen mehrere Schichten oder separate, parallel ausgeführte Blockchains, die von denselben Validierungsknoten verwaltet werden. Ein Teil der Transaktionsdaten von der Blockchain für die erste Schicht kann der Blockchain für die zweite Schicht zur Verfügung gestellt werden oder umgekehrt.
In einem Beispiel kann ein verteiltes Ledger in einem Prozesssteuerungssystem durch die Validierung von Knoten, die hier als „Edge-Gateways“ bezeichnet werden, verwaltet werden, die Daten an entfernte Systeme wie andere Prozessanlagen über ein oder mehrere öffentliche und/oder private Netzwerke, wie z. B. ein privates Unternehmensnetzwerk, das Internet, einen zellularen Router, eine Backhaul-Internet- oder eine andere Art von Backhaul-Verbindung, übertragen. Die Edge-Gateways empfangen Transaktionen, die in das verteilte Ledger-Netzwerk gesendet werden, z. B. von Prozesssteuerungsgeräten wie Feldgeräten oder Steuerungen, die in der Prozessanlage betrieben werden. Andere Computergeräte, wie z. B. Betreiberarbeitsstationen, Servergeräte oder andere Benutzerschnittstellen-Geräte in der Prozessanlage können ebenfalls Transaktionen an das verteilte Ledger-Netzwerk senden. Die Edge-Gateways validieren dann die übertragenen Transaktionen.
In einem anderen Beispiel führen die Edge-Gateways Code aus, der in „intelligenten Verträgen“ enthalten ist, und Feldgeräte fungieren als „Beweis-Orakel“, die der Blockchain Beweise in Bezug auf die Qualitätskontrolle, die Einhaltung von Vorschriften, die Lieferung oder den Empfang eines Produkts und die gelieferte/empfangene Menge usw. liefern.
1 ist ein Blockdiagramm einer beispielhaften Prozessanlage 10, in der eine oder mehrere der hier beschriebenen neuartigen, verteilten Ledger-Techniken zum Einsatz kommen können. Die Prozessanlage 10 (die hier austauschbar auch als Prozesssteuerungssystem 10 oder Prozesssteuerungssystemumgebung 10 bezeichnet wird) umfasst eine oder mehrere Prozesssteuerungen, die Signale empfangen, die für die von Feldgeräten durchgeführten Prozessmessungen kennzeichnend sind, diese Informationen verarbeiten, um eine Steuerroutine umzusetzen, und Steuersignale erzeugen, die über drahtgebundene oder drahtlose Prozesssteuerungs-Kommunikationsverbindungen oder Netzwerke an andere Feldgeräte gesendet werden, um den Betrieb eines Prozesses in der Anlage 10 zu steuern. Typischerweise führt mindestens ein Feldgerät eine physische Funktion aus (z. B. Öffnen oder Schließen eines Ventils, Erhöhen oder Verringern einer Temperatur, Durchführung einer Messung, Erfassen eines Zustands usw.), um den Betrieb eines Prozesses zu steuern. Einige Arten von Feldgeräten kommunizieren mit Steuerungen über E-/A-Geräte. Prozesssteuerungen, Feldgeräte und E-/A-Geräte können verdrahtet oder drahtlos sein, und jede Anzahl und Kombination von verdrahteten und drahtlosen Prozesssteuerungen, Feldgeräten und E-/A-Geräten kann in die Umgebung der Prozessanlage oder des Systems 10 eingebunden werden.
So zum Beispiel zeigt 1 eine Prozesssteuerung 11, die über die Ein-/Ausgabekarten 26 und 28 mit den verdrahteten Feldgeräten 15-22 und über ein Wireless-Gateway 35 und einer Prozesssteuerungs-Datenautobahn oder Backbone 105 mit den drahtlosen Feldgeräten 40-46 kommunikativ verbunden ist. Die Prozesssteuerungs-Datenautobahn 105 kann eine oder mehrere drahtgebundene und/oder drahtlose Kommunikationsverbindungen beinhalten und kann mit jedem gewünschten oder geeigneten Kommunikationsprotokoll, wie z. B. einem Ethernet-Protokoll, umgesetzt werden. In einigen Konfigurationen (nicht abgebildet) kann die Steuerung 11 über ein oder mehrere andere Kommunikationsnetzwerke außer dem Backbone 105 kommunikativ mit dem Wireless-Gateway 35 verbunden werden, z. B. durch die Verwendung einer beliebigen Anzahl anderer drahtgebundener oder drahtloser Kommunikationsverbindungen, die ein oder mehrere Kommunikationsprotokolle unterstützen, z. B, Wi-Fi oder ein anderes IEEE 802.11-konformes drahtloses lokales Netzwerkprotokoll, Mobilkommunikationsprotokoll (z. B. WiMAX, LTE oder ein anderes ITU-R-kompatibles Protokoll), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Feldbus usw.
Die Steuerung 11, die z. B. die von Emerson Process Management verkaufte DeltaVTM-Steuerung sein kann, ermöglicht die Implementierung eines Batch-Prozesses oder eines kontinuierlichen Prozesses unter Verwendung mindestens einiger der Feldgeräte 15-22 und 40-46. In einer Ausführungsform ist die Steuerung 11 nicht nur kommunikativ mit der Prozesssteuerungs-Datenautobahn 105 verbunden, sondern auch mit mindestens einigen der Feldgeräte 15-22 und 40-46, wobei jede gewünschte Hard- und Software verwendet wird, die z. B. mit Standard 4-20 mA-Geräten, I/O-Karten 26, 28 und/oder jedem intelligenten Kommunikationsprotokoll wie dem FOUNDATION® Feldbus-Protokoll, dem HART®-Protokoll, dem WirelessHART®-Protokoll usw. verbunden ist. In 1 sind die Steuerung 11, die Feldgeräte 15-22 und die I/O-Karten 26, 28 verdrahtete Geräte und die Feldgeräte 40-46 drahtlose Feldgeräte. Natürlich könnten die kabelgebundenen Feldgeräte 15-22 und die drahtlosen Feldgeräte 40-46 jedem anderen gewünschten Standard oder Protokoll entsprechen, wie z. B. allen kabelgebundenen oder drahtlosen Protokollen, einschließlich aller in der Zukunft entwickelten Standards oder Protokolle.
Die Prozesssteuerung 11 von 1 beinhaltet einen Prozessor 30, der eine oder mehrere Prozesssteuerungsroutinen 38 (z. B. die in einem Speicher 32 abgelegt sind) implementiert oder überwacht. Der Prozessor 30 ist konfiguriert, um mit den Feldgeräten 15-22 und 40-46 und mit anderen mit der Steuerung 11 kommunikativ verbundenen Knoten zu kommunizieren. Zu beachten ist, dass beliebige der hier beschriebenen Steuerungsroutinen oder Module von verschiedenen Steuerungen oder anderen Geräten umgesetzt oder ausgeführt werden können, sofern dies gewünscht ist. Ebenso können die hier beschriebenen Steuerungsroutinen oder Module 38, die innerhalb des Prozesssteuerungssystems 10 zu implementieren sind, jede Form annehmen, einschließlich Software, Firmware, Hardware usw. Die Steuerungsroutinen können in jedem gewünschten Softwareformat implementiert werden, wie z. B. durch objektorientierte Programmierung, Kontaktplan, Ablaufsprache, Funktionsblockdiagramm oder durch jede andere Software-Programmiersprache oder jedes andere Design-Paradigma. Die Steuerungsroutinen 38 können in jedem beliebigen Speichertyp 32, wie z. B. RAM (Random Access Memory) oder ROM (Read Only Memory), gespeichert werden. Ebenso können die Steuerungsroutinen 38 z. B. in ein oder mehrere EPROMs, EEPROMs, anwendungsspezifische integrierte Schaltkreise (ASICs) oder andere Hardware- oder Firmware-Elemente fest einprogrammiert werden. Somit kann die Steuerung 11 so konfiguriert werden, dass eine Steuerungsstrategie oder Steuerungsroutine in jeder gewünschten Weise umgesetzt werden kann.
Die Steuerung 11 implementiert eine Steuerungsstrategie mit Hilfe von sogenannten Funktionsblöcken, wobei jeder Funktionsblock ein Objekt oder ein anderer Teil (z. B. ein Unterprogramm) einer übergreifenden Steuerungsroutine ist und in Verbindung mit anderen Funktionsblöcken (über Kommunikation, die als Links bezeichnet wird) arbeitet, um Prozesssteuerungskreise innerhalb des Prozesssteuerungssystems 10 umzusetzen. Steuerungsbasierte Funktionsblöcke führen typischerweise eine Eingangsfunktion aus, wie z. B. diejenige, die mit einem Transmitter, einem Sensor oder einem anderen Prozessparameter-Messgerät verbunden ist, eine Steuerungsfunktion, wie z. B. diejenige, die mit einer Steuerungsroutine verbunden ist, die eine PID-, Fuzzy-Logik-Steuerung usw. durchführt, oder eine Ausgangsfunktion, die den Betrieb eines Gerätes, wie z. B. eines Ventils, steuert, um eine physische Funktion innerhalb des Prozesssteuerungssystems 10 auszuführen. Natürlich gibt es auch hybride und andere Arten von Funktionsblöcken. Funktionsblöcke können in der Steuerung 11 gespeichert und von ihr ausgeführt werden, was in der Regel der Fall ist, wenn diese Funktionsblöcke für Standard 4-20 mA-Geräte und einige Arten von intelligenten Feldgeräten wie HART^® -Geräte verwendet werden, oder sie können in den Feldgeräten selbst gespeichert und von ihnen implementiert werden, was bei FOUNDATION^® Feldbus-Geräten der Fall sein kann. Die Steuerung 11 kann eine oder mehrere Steuerungsroutinen 38 beinhalten, die einen oder mehrere Steuerungskreise implementieren können, die durch die Ausführung eines oder mehrerer Funktionsblöcke ausgeführt werden.
Bei den verdrahteten Feldgeräten 15-22 kann es sich um beliebige Gerätetypen wie Sensoren, Ventile, Messumformer, Stellungsregler usw. handeln, während die E-/A-Karten 26 und 28 beliebige Typen von E-/A-Geräten sein können, die jedem gewünschten Kommunikations- oder Steuerungsprotokoll entsprechen. In 1 sind die Feldgeräte 15-18 Standardgeräte 4-20 mA oder HART^® -Geräte, die über analoge Leitungen oder kombinierte analoge und digitale Leitungen mit der I/O-Karte 26 kommunizieren, während die Feldgeräte 19-22 intelligente Geräte, wie z. B. FOUNDATION® Feldbus Feldgeräte, sind, die über einen digitalen Bus mit einem FOUNDATION® Feldbus Kommunikationsprotokoll mit der I/O-Karte 28 kommunizieren. In einigen Ausführungsformen kommunizieren jedoch zumindest einige der verdrahteten Feldgeräte 15, 16 und 18-21 und/oder zumindest einige der E-/A-Karten 26, 28 zusätzlich oder alternativ mit der Steuerung 11 über die Prozesssteuerungs-Datenautobahn 105 und/oder über andere geeignete Steuerungssystemprotokolle (z. B. Profibus, DeviceNet, Foundation Feldbus, ControlNet, Modbus, HART, usw.).
In 1 kommunizieren die drahtlosen Feldgeräte 40-46 über ein drahtloses Kommunikationsnetzwerk 70 der Prozesssteuerungstechnik mit einem drahtlosen Protokoll, wie z. B. dem WirelessHART^®-Protokoll. Solche drahtlosen Feldgeräte 40-46 können direkt mit einem oder mehreren anderen Geräten oder Knoten des drahtlosen Netzwerks 70 kommunizieren, die ebenfalls für die drahtlose Kommunikation (z. B. über das drahtlose Protokoll oder ein anderes drahtloses Protokoll) konfiguriert sind. Zur Kommunikation mit einem oder mehreren anderen Knoten, die nicht für die drahtlose Kommunikation konfiguriert sind, können die drahtlosen Feldgeräte 40-46 ein Wireless-Gateway 35 verwenden, das mit der Prozesssteuerungs-Datenautobahn 105 oder mit einem anderen Prozesssteuerungs-Kommunikationsnetzwerk verbunden ist. Das Wireless-Gateway 35 ermöglicht den Zugriff auf verschiedene drahtlose Geräte 40-58 des drahtlosen Kommunikationsnetzwerks 70. Insbesondere das Wireless-Gateway 35 sorgt für die kommunikative Kopplung zwischen den Funkgeräten 40-58, den drahtgebundenen Geräten 15-28 und/oder anderen Knoten bzw. Geräten der Prozesssteuerungstechnik 10. Das Wireless-Gateway 35 kann z. B. eine kommunikative Kopplung über die Prozesssteuerungs-Datenautobahn 105 und/oder über ein oder mehrere andere Kommunikationsnetzwerke der Prozessanlage 10 ermöglichen.
Ähnlich wie die drahtgebundenen Feldgeräte 15-22 übernehmen die drahtlosen Feldgeräte 40-16 des drahtlosen Netzwerkes 70 physische Steuerungsfunktionen innerhalb der Prozessanlage 10, z. B. das Öffnen oder Schließen von Ventilen oder die Messung von Prozessparametern. Die drahtlosen Feldgeräte 40-46 sind jedoch zur Kommunikation über das drahtlose Protokoll des Netzwerks 70 konfiguriert. So sind die drahtlosen Feldgeräte 40-46, das Wireless-Gateway 35 und andere drahtlose Knoten 52-58 des drahtlosen Netzwerks 70 Erzeuger und Verbraucher von drahtlosen Kommunikationspaketen.
In einigen Konfigurationen der Prozessanlage 10 umfasst das drahtlose Netzwerk 70 auch nicht-drahtlose Geräte. So ist z. B. in 1 ein Feldgerät 48 aus 1 ein Legacy-Gerät 4-20 mA und ein Feldgerät 50 ein verdrahtetes HART^® -Gerät. Zur Kommunikation innerhalb des Netzwerks 70 sind die Feldgeräte 48 und 50 über einen drahtlosen Adapter 52A, 52B mit dem drahtlosen Kommunikationsnetzwerk 70 verbunden. Die drahtlosen Adapter 52A, 52B unterstützen ein drahtloses Protokoll wie WirelessHART und können auch ein oder mehrere andere Kommunikationsprotokolle wie Foundation® Feldbus, PROFIBUS, DeviceNet, usw. unterstützen. Zusätzlich enthält das drahtlose Netzwerk 70 in einigen Konfigurationen einen oder mehrere Netzwerkzugangspunkte 55A, 55B, die separate physikalische Geräte in drahtgebundener Kommunikation mit dem Wireless Gateway 35 sein können oder mit dem Wireless-Gateway 35 als integrales Gerät ausgestattet sein können. Das drahtlose Netzwerk 70 kann auch einen oder mehrere Router 58 enthalten, um Pakete von einem drahtlosen Gerät zu einem anderen drahtlosen Gerät innerhalb des drahtlosen Kommunikationsnetzwerks 70 weiterzuleiten. In 1 kommunizieren die drahtlosen Geräte 40-46 und 52-58 untereinander und mit dem Wireless-Gateway 35 über drahtlose Verbindungen 60 des drahtlosen Kommunikationsnetzwerkes 70 bzw. über die Prozesssteuerungs-Datenautobahn 105.
In FIG. In 1 umfasst das Prozesssteuerungssystem 10 eine oder mehrere Betreiberarbeitsstationen oder Benutzerschnittstellen-Geräte 8, die kommunikativ mit der Datenautobahn 105 verbunden sind. Über die Betreiberarbeitsstationen 8 kann das Bedienpersonal den laufenden Betrieb der Prozessanlage 10 einsehen und überwachen sowie ggf. erforderliche Diagnose-, Korrektur-, Wartungs- und/oder sonstige Maßnahmen ergreifen. Zumindest ein Teil der Betreiberarbeitsstationen 8 kann sich an verschiedenen, geschützten Stellen in oder in der Nähe der Anlage 10 befinden, und in manchen Situationen kann zumindest ein Teil der Betreiberarbeitsstationen 8 weit entfernt, aber dennoch in kommunikativer Verbindung mit der Anlage 10 stehen. Betreiberarbeitsstationen 8 können kabelgebundene oder drahtlose Computergeräte sein.
Das beispielhafte Prozesssteuerungssystem 10 kann weiterhin eine Konfigurationsanwendung (nicht dargestellt) und eine Konfigurationsdatenbank (nicht dargestellt) enthalten, die jeweils auch kommunikativ mit der Datenautobahn 105 verbunden sind. Wie oben besprochen, können verschiedene Instanzen der Konfigurationsanwendung (nicht dargestellt) auf einem oder mehreren Benutzerschnittstellen-Geräten 8 ausgeführt werden, um dem Benutzer die Erstellung oder Änderung von Prozess-Steuerungsmodulen und den Download dieser Module über die Datenautobahn 105 zu den Steuerungen 11 zu ermöglichen, sowie dem Benutzer die Erstellung oder Änderung von Bediengeräten zu ermöglichen, über die ein Betreiber Daten einsehen und Dateneinstellungen innerhalb von Prozess-Steuerungsroutinen ändern kann. In der Konfigurationsdatenbank (nicht dargestellt) werden die erstellten (z. B. konfigurierten) Module bzw. Benutzerschnittstellen gespeichert.
In einigen Konfigurationen enthält das Prozesssteuerungssystem 10 einen oder mehrere andere drahtlose Zugangspunkte 7a, die mit anderen Geräten über andere drahtlose Protokolle wie Wi-Fi oder andere IEEE 802.11-konforme drahtlose lokale Netzwerkprotokolle, mobile Kommunikationsprotokolle wie WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) oder andere ITU-R (International Telecommunication Union Radiocommunication Sector) kompatible Protokolle, kurzwellige Funkkommunikation wie Nahfeldkommunikation (NFC) und Bluetooth oder andere drahtlose Kommunikationsprotokolle kommunizieren. In der Regel ermöglichen solche drahtlosen Zugangspunkte 7a die Kommunikation von Handheld- oder anderen tragbaren Computergeräten über ein entsprechendes drahtloses Prozesssteuerungs-Kommunikationsnetz, das sich vom drahtlosen Netzwerk 70 unterscheidet und ein anderes drahtloses Protokoll als das drahtlose Netzwerk 70 unterstützt. Zum Beispiel kann ein drahtloses oder tragbares Benutzerschnittstellen-Gerät 8 eine mobile Arbeitsstation oder ein Diagnose-Testgerät sein, das von einem Betreiber innerhalb der Prozessanlage 10 verwendet wird. In einigen Szenarien kommunizieren neben tragbaren Computergeräten auch ein oder mehrere Prozesssteuerungsgeräte (z. B. Steuerung 11, Feldgeräte 15-22 oder drahtlose Geräte 35, 40-58) über das von den Zugangspunkten 7a unterstützte drahtlose Protokoll.
In einigen Konfigurationen beinhaltet das Prozesssteuerungssystem 10 ein oder mehrere Gateways 7b, 7c zu Systemen, die außerhalb des unmittelbaren Prozesssteuerungssystems 10 liegen (hier auch als „Edge-Gateway“ bezeichnet und nachfolgend näher beschrieben). In der Regel handelt es sich bei solchen Systemen um Kunden oder Anbieter von Informationen, die durch das Prozessleitsystem 10 erzeugt oder gesteuert werden. So kann z. B. die Prozesssteuerungsanlage 10 einen Gateway-Knoten 7b enthalten, um die unmittelbare Prozessanlage 10 mit einer anderen Prozessanlage kommunikativ zu verbinden. Zusätzlich oder alternativ kann die Prozesssteuerungsanlage 10 einen Gateway-Knoten 7c zur kommunikativen Anbindung der unmittelbaren Prozesssteuerungsanlage 10 an ein externes öffentliches oder privates System, wie z. B. ein Laborsystem (z. B. Labor-Informations-Management-System oder LIMS), eine Operator-Round-Datenbank, ein Materialflusssystem, ein Wartungsmanagementsystem, ein Produkt-Bestandsführungssystem, ein Produktionsplanungssystem, ein Wetterdatensystem, ein Versand- und Handlingsystem, ein Verpackungssystem, das Internet, das Prozesssteuerungssystem eines anderen Anbieters oder andere externe Systeme beinhalten.
Es wird daraufhingewiesen, dass 1 zwar nur eine einzelne Steuerung 11 mit einer endlichen Anzahl von Feldgeräten 15-22 und 40-46, Wireless-Gateways 35, drahtlosen Adaptern 52, Zugangspunkten 55, Routern 58 und drahtlosen Prozesssteuerungs-Kommunikationsnetzwerken 70, die in der beispielhaften Prozessanlage 10 enthalten sind, darstellt, dies aber nur eine veranschaulichende und nicht einschränkende Ausführungsform ist. Eine beliebige Anzahl von Steuerungen 11 kann in die Prozesssteuerungsanlage oder das Prozessleitsystem 10 eingebunden werden, und jede der Steuerungen 11 kann mit einer beliebigen Anzahl von verdrahteten oder drahtlosen Geräten und Netzwerken 15-22, 40-46, 35, 52, 55, 58 und 70 kommunizieren, um einen Prozess in der Anlage 10 zu steuern.
Weiterhin ist zu beachten, dass die Prozessanlage bzw. das Steuerungssystem 10 von 1 eine Feldumgebung (z. B. „die Ebene der Prozessanlage“) und eine Backend-Umgebung (z. B. Server 12) umfasst, die über die Datenautobahn 105 kommunikativ verbunden sind. Wie in 1 gezeigt, enthält die Feldumgebung physische Komponenten (z. B. Prozesssteuerungsgeräte, Netzwerke, Netzwerkelemente usw.), die zur Steuerung des Prozesses während der Laufzeit angeordnet, installiert und darin miteinander verbunden sind. So befinden sich z. B. die Steuerung 11, die E-/A-Karten 26, 28, die Feldgeräte 15-22 und weitere Geräte und Netzwerkkomponenten 40-46, 35, 52, 55, 58 und 70 in der Feldumgebung der Prozessanlage 10, die platziert, angeordnet oder anderweitig in diese einbezogen werden. In der Regel werden in der Feldumgebung der Prozessanlage 10 Rohstoffe entgegengenommen und mit den darin befindlichen physischen Komponenten zu einem oder mehreren Produkten verarbeitet.
Die Backend-Umgebung der Prozessanlage 10 umfasst verschiedene Komponenten wie Server-Computer 12, Betreiberarbeitsstationen 8, Datenbanken oder Datenbestände usw., die gegen die rauen Bedingungen und Materialien der Feldumgebung abgeschirmt bzw. geschützt sind. Bezogen auf 1 umfasst die Backend-Umgebung z. B. die Betreiberarbeitsstationen 8, die Server-Rechengeräte 12 und/oder Funktionen, die den Laufzeitbetrieb der Prozessanlage 10 unterstützen. In einigen Konfigurationen können sich verschiedene Computergeräte, Datenbanken und andere Komponenten und Ausrüstungen, die in der Backend-Umgebung der Prozessanlage 10 enthalten sind, physisch an verschiedenen Orten befinden, von denen einige lokal in der Prozessanlage 10 und andere entfernt sein können.
2 enthält ein Blockdiagramm einer beispielhaften Sicherheitsarchitektur 200 für die Prozessanlage 10. Wie in 2 dargestellt, sind ein oder mehrere Geräte 202 kommunikativ mit einem oder mehreren Wireless-Gateways 205A, 205B verbunden, die z. B. Instanzen des Wireless-Gateways 35 aus 1 sein können. Die kommunikativen Verbindungen zwischen den Gateways 205A, 205B und den Geräten 202 sind mit den Bezugszeichen 204A, 204B bezeichnet.
Der Geräte-Satz 202 wird als eine endliche Anzahl von drahtlosen Feldgeräten dargestellt. Es versteht sich jedoch, dass die hierin in Bezug auf die Geräte 202 beschriebenen Konzepte und Merkmale problemlos auf eine beliebige Anzahl von Feldgeräten der Prozessanlage 10 sowie auf beliebige Feldgeräte-Typen angewendet werden können. Beispielsweise können die Feldgeräte 202 ein oder mehrere drahtgebundene Feldgeräte 15-22 enthalten, die über ein oder mehrere drahtgebundene Kommunikationsnetze der Prozessanlage 10 kommunikativ mit den Wireless-Gateways 205A, 205B verbunden sind, und/oder die Feldgeräte 202 können drahtgebundene Feldgeräte 48, 50 enthalten, die an drahtlose Adapter 52A, 52B gekoppelt sind.
Ferner versteht es sich, dass der Geräte-Satz 202 nicht nur auf Feldgeräte beschränkt ist, sondern zusätzlich oder alternativ jedes Gerät oder jede Komponente innerhalb der Prozessanlage 10 umfassen kann, die Daten als Ergebnis der Steuerung des Online-Prozesses durch die Prozessanlage 10 erzeugen. Beispielsweise kann der Geräte-Satz 202 ein Diagnosegerät oder eine Komponente enthalten, die Diagnosedaten erzeugt, ein Netzwerk-Routing-Gerät oder eine Komponente, die Informationen zwischen verschiedenen Komponenten der Prozessanlage 10 überträgt, und ähnliches. Tatsächlich kann jede der in 1 dargestellten Komponenten (z. B. die Komponenten 7a-7c, 8, 11, 12, 15-22, 26, 28, 35, 40-46, 52, 55, 58, 60 und 70) und andere nicht dargestellte Komponenten ein Gerät sein, das Daten zur Lieferung an das Remote-System 210 erzeugt. Als solche wird der Geräte-Satz 202 hier austauschbar als „Datenquellen 202“ oder „Datenquellen-Geräte 202“ bezeichnet.
2 zeigt weiter eine Reihe von Remote-Anwendungen oder -Dienste 208, die für die Prozessanlage 10 genutzt werden können und/oder die die Prozessanlage 10 nutzt. Der Satz von Remote-Anwendungen oder -Diensten 208 kann auf einem oder mehreren Remote-Systemen 210 ausgeführt oder gehostet werden. Zumindest einige der Anwendungen oder Dienste 208 arbeiten in Echtzeit mit Echtzeitdaten, da die Echtzeitdaten von der Prozessanlage 10 erzeugt und von den Anwendungen oder Diensten 208 empfangen werden. Andere Anwendungen oder Dienste 208 können auf den von Prozessanlagen generierten Daten mit weniger strikten Zeitanforderungen arbeiten oder diese ausführen. Beispiele für Anwendungen/Dienste 208, die auf dem Remote-System 210 ausgeführt oder gehostet werden können und die Verbraucher von Daten sind, die von der Prozessanlage 10 erzeugt werden, sind Anwendungen, die Bedingungen und/oder Ereignisse überwachen und/oder erfassen, die in der Prozessanlage 10 auftreten, sowie Anwendungen oder Dienste, die zumindest einen Teil des Online-Prozesses selbst überwachen, während er in der Prozessanlage 10 ausgeführt wird. Weitere Beispiele für Anwendungen/Dienste 208 sind die beschreibende und/oder präskriptive Analytik, die mit Daten arbeiten kann, die von der Prozessanlage 10 erzeugt werden, und in einigen Fällen mit Erkenntnissen arbeiten kann, die aus der Analyse der von der Prozessanlage erzeugten Daten gewonnen oder entdeckt wurden, sowie mit Daten, die von anderen Prozessanlagen erzeugt und von diesen empfangen wurden. Weitere Beispiele für Anwendungen/Dienste 208 sind eine oder mehrere Routinen, die präskriptive Funktionen und/oder Änderungen implementieren, die z. B. aufgrund eines anderen Dienstes oder anderen Anwendung wieder in die Prozessanlage 10 implementiert werden sollen. Andere Beispiele für Anwendungen und Dienste 208 basieren auf dem Wissen, das durch die Analyse historischer Daten aus der Prozessanlage und/oder anderen Prozessanlagen oder durch den Vergleich von Daten für eine Prozessanlagen-Einheit mit Daten von Prozessanlagen-Einheiten gleichen oder ähnlichen Typs gewonnen wird.
Das eine oder die mehreren Remote-Systeme 210 können auf beliebige Weise implementiert werden, z. B. durch eine Remote-Bank mit vernetzten Servern, ein oder mehrere Cloud-Computing-Systeme, ein oder mehrere Netzwerke usw. Der Einfachheit halber werden das eine oder die mehreren Remote-Systeme 210 hier im Singular bezeichnet, d. h. „Remote-System 210“, obwohl man versteht, dass sich dieser Begriff auf ein System, mehrere Systeme oder eine beliebige Anzahl von Systemen beziehen kann. In einigen Szenarien kann das Computergerät 250, das die Daten der Prozessanlage analysiert, im Remote-System 210 integriert sein.
Generell bietet die Sicherheitsarchitektur 200 eine durchgängige Sicherheit von der Feldumgebung der Prozessanlage 10, in der die Geräte 202 installiert und betrieben werden, bis hin zum dezentralen System 210, das Anwendungen und/oder Dienste 208 bereitstellt, die die von der Prozessanlage 10 erzeugten Daten verbrauchen und verarbeiten. So können Daten, die von den Geräten 202 und anderen Komponenten der Prozessanlage 10 erzeugt werden, sicher zum Remote-System 210 zur Nutzung durch die Remote-Applikationen/- Dienste 208 transportiert werden, während die Anlage 10 vor Cyber-Angriffen, Einbrüchen und/oder anderen schadhaften Ereignissen geschützt ist. Die Sicherheitsarchitektur 200 umfasst insbesondere ein Feld-Gateway 212 und ein Edge-Gateway 218, die zwischen der Prozessanlage 10 (z. B. zwischen den Wireless-Gateways 205A, 205B der Prozessanlage 10) und dem Remote-System 210 angeordnet sind.
Daten, die aus der Prozessanlage 10 herausgehen und vom Eingangsport 220 zum Ausgangsport 222 übertragen werden, können durch Verschlüsselung weiter gesichert werden. In einem Beispiel verschlüsselt das Feld-Gateway 212 Daten und liefert verschlüsselte Daten an den Eingangsport 220. Der verschlüsselte und übermittelte Datenverkehr kann in einem Beispiel ein UDP-Datenverkehr (User Datagram Protocol) und in einem anderen Beispiel ein JSON-Datenverkehr oder ein anderes allgemeines Kommunikationsformat sein.
Das Feld-Gateway 212 verbindet sich kommunikativ mit der Prozesssteuerungsanlage 10. Wie in 2 dargestellt, ist das Feld-Gateway 212 kommunikativ mit den Wireless-Gateways 205A, 205B verbunden, die in der Feldumgebung der Prozessanlage 10 angeordnet sind und die mit einem oder mehreren Geräten oder Datenquellen 202 kommunikativ verbunden sind. Wie bereits erwähnt, können die Geräte bzw. Datenquellen 202 und die Wireless-Gateways 205A, 205B über das Industrieprotokoll WirelessHART oder ein anderes geeignetes drahtloses Protokoll kommunizieren, das so strukturiert ist, dass es eine sichere Kommunikation über einen oder mehrere Sicherheitsmechanismen ermöglicht. Das WirelessHART-Industrieprotokoll bietet beispielsweise eine 128-Bit-AES-Verschlüsselung, wobei sich die Kommunikationspfade 204A, 204B entsprechend absichern lassen.
Zusätzlich wird die kommunikative Verbindung 225 zwischen den Wireless Gateways 205A, 205B und dem Feld-Gateway 212 jeweils mit dem gleichen oder einem anderen Sicherheitsmechanismus gesichert, wie es für die kommunikativen Verbindungen 204A, 204B der Fall ist. In einem Beispiel ist die Kommunikationsverbindung 225 durch einen TLS-Wrapper (Transport Layer Security) gesichert. Die Wireless-Gateways 205A, 205B generieren beispielsweise Pakete im HART-IP-Format, die durch einen TLS-Wrapper für die Übertragung zum Field Gateway 212 gesichert sind.
So können, wie oben beschrieben, in einer Ausführungsform Daten oder Pakete, die von den Geräten 202 generiert werden, für den Transit 204A, 204B zu den Wireless-Gateways 205A, 205B mit einem ersten Sicherheitsmechanismus gesichert werden, und anschließend für den Transit 225 von den Wireless-Gateways 205A, 205B zum Feld-Gateway 212 mit einem zweiten Sicherheitsmechanismus gesichert werden, und noch anschließend für den Transit zum Edge-Gateway 218 mit einem dritten Sicherheitsmechanismus gesichert werden. Zusätzlich oder alternativ kann, wie in 2 dargestellt, das Edge-Gateway 218 durch eine Firewall 228 geschützt werden.
Daten, die vom Edge-Gateway 218 zum entfernten System 210 übertragen werden, können über ein oder mehrere öffentliche und/oder private Netzwerke, wie z. B. ein privates Unternehmensnetzwerk, das Internet, ein Mobilfunk-Router, eine Backhaul-Internet- oder eine Backhaul-Verbindung eines anderen Typs, übertragen werden. Entscheidend ist, dass die Daten, die vom Edge-Gateway 218 zum Remote-System 210 übertragen werden, durch einen vierten Sicherheitsmechanismus oder durch einen der oben beschriebenen Sicherheitsmechanismen gesichert werden. 2 zeigt den vom Edge-Gateway 218 zum Remote-System 210 übermittelten Datenverkehr als über ein SAS (Shared Access Signature) Token gesichert, das über einen am Remote-System 210 bereitgestellten Token-Service 230 verwaltet werden kann. Das Edge-Gateway 218 authentifiziert sich gegenüber dem Token-Service 230 und fordert einen SAS-Token an, der nur für eine begrenzte Zeitspanne gültig sein darf, z. B. zwei Minuten, fünf Minuten, dreißig Minuten, nicht mehr als eine Stunde usw. Das Edge-Gateway 218 empfängt und verwendet den SAS-Token, um eine AMQP-Verbindung (Advanced Message Queuing Protocol) zum Remote-System 210 zu sichern und zu authentifizieren, über welche Inhaltsdaten vom Edge-Gateway 218 zum Remote-System 210 übertragen werden.
Beim Remote-System 210 wird die Sicherheit über einen Domain-Authentifizierungsdienst 232 gewährleistet. Somit können nur Benutzerschnittstellen-Geräte 235, die über den Domain-Authentifizierungsdienst 232 authentifiziert und autorisiert sind, auf zumindest einen Teil der am Remote-System 210 verfügbaren Daten zugreifen, zu denen unter anderem die von den Geräten 202 generierten Daten gehören.
Daher bietet die Sicherheitsarchitektur 200, wie oben beschrieben, eine End-to-End-Sicherheit für Daten, die von Geräten oder Datenquellen 202 während des Betriebs in der Prozessanlage 10 zur Steuerung eines Prozesses erzeugt werden, z. B. von der Entstehung der Daten durch die Datenquellen 202 bis zu ihrer Übertragung an das entfernte System 210, das von einer oder mehreren entfernten Anwendungen oder Diensten 208 bedient werden soll. Wichtig ist, dass die Sicherheitsarchitektur 200 diese End-to-End-Sicherheit bietet und gleichzeitig böswillige Angriffe auf die Prozessanlage 10 verhindert.
Zu beachten ist, dass in 2 zwar die Wireless-Gateways 205A, 205B als kommunikative Verbindung zwischen den Geräten bzw. Datenquellen 202 und dem Feld-Gateway 212 dargestellt sind, in manchen Anordnungen jedoch eines oder mehrere der Wireless-Gateways 205A, 205B weggelassen werden und die Quelldaten von den Datenquellen 202 direkt an das Feld-Gateway 212 übertragen werden. Beispielsweise können die Datenquellen 202 über ein großes Datennetz der Prozessanlage 10 Quelldaten direkt an das Feld-Gateway 212 übertragen. Im Allgemeinen ist ein großes Datennetz der Prozessanlage 10 weder das Backbone-Anlagennetzwerk 105, noch ist das große Datennetz ein industrielles Protokollnetzwerk zur Übertragung von Steuersignalen zwischen Geräten mit einem industriellen Kommunikationsprotokoll (z. B. Profibus, DeviceNet, Foundation Feldbus, ControlNet, Modbus, HART usw.). Vielmehr kann ein großes Datennetzwerk der Prozessanlage 10 ein für die Prozessanlage 10 implementiertes Overlay-Netzwerk sein, das z. B. für Datenverarbeitungs- und Analysezwecke Daten zwischen den Knoten überträgt. Zu den Knoten eines großen Datennetzes können z. B. die Datenquellen 202, die Wireless-Gateways 205A, 205B und das Feld-Gateway 212 sowie eine oder mehrere der in 1 dargestellten Komponenten 7a-7c, 8, 11, 12, 15-22, 26, 28, 35, 40-46, 52, 55, 58, 60 und 70 und weitere Komponenten gehören. Dementsprechend umfassen die Datennetzwerke vieler Knoten einer Prozessanlage jeweils eine bestimmte Schnittstelle für den Betrieb der Prozessanlage, die üblicherweise ein industrielles Kommunikationsprotokoll nutzt, und eine andere bestimmte Schnittstelle für Datenverarbeitungs-/Analyseoperationen, die beispielsweise ein Streaming-Protokoll verwenden.
In Bezug auf 2 wird zudem darauf hingewiesen, dass in einigen Ausführungsformen ein drahtgebundenes Gateway (nicht dargestellt) anstelle eines der Wireless-Gateways 205A, 205B verwendet werden kann. Darüber hinaus können das Feld-Gateway 212 und das Edge-Gateway 218 physisch gemeinsam angeordnet sein, wie durch das in 2 gezeigte Kästchen 235 angezeigt wird, oder die Komponenten 212 und 218 können sich physisch an mehreren Orten befinden. Beispielsweise können ein oder mehrere der Feld-Gateways 212 oder das Edge-Gateway 218 in der Prozessanlage 10 angeordnet werden. Zusätzlich oder wahlweise können ein oder mehrere der Feld-Gateways 212 oder das Edge-Gateway 218 entfernt von der Prozessanlage 10 angeordnet werden.
Die Prozessanlage 10 kann auf Wunsch von mehreren Feld-Gateways 212 und eine beliebige Anzahl von Feld-Gateways 210 von einem Single-Edge-Gateway 218 bedient werden. In einigen Ausführungsformen wird das Remote-System 210 auf Wunsch von mehr als einem Edge-Gateway 218 bedient.
Während sich das obige Beispiel auf das Computergerät 250 zur Analyse von Prozessanlagendaten als eine Komponente des Remote-Systems 210 bezieht, kann das Computergerät 250 Prozessanlagendaten empfangen, indem es mit jeder geeigneten Kommunikationskomponente auf sichere Weise kommuniziert. Beispielsweise kann das Computergerät 250 kommunikativ mit den Wireless-Gateways 205A, 205B, dem Feld-Gateway 212 oder dem Edge-Gateway 218 verbunden werden. Die Kommunikationspfade können von den Geräten 202 bis zum Computergerät 250 über Verschlüsselungstechniken, Firewalls, eine Datendiode oder mit jedem anderen geeigneten Sicherheitsmechanismus gesichert werden.
Sobald die Daten der Prozessanlage am Computergerät 250 empfangen werden, analysiert das Computergerät die Daten der Prozessanlage, um die Umstände an den entsprechenden Einheiten der Prozessanlage zu identifizieren. Angaben zu den Umständen werden dann z. B. über einen Domain-Authentifizierungsdienst an das Benutzerschnittstellen-Gerät 235 übertragen. Auf diese Weise kann ein Betreiber die Umstände einsehen, die an verschiedenen Prozessanlageneinheiten in der Prozessanlage auftreten. Der Betreiber kann dann die geeigneten Maßnahmen ergreifen, um die durch diese Umstände entstandenen Probleme zu lösen.
Verteilte Ledger-Architektur in einem Prozesssteuerungssystem
Während die Prozessanlage 10 in 2 als mit einem Single Edge-Gateway 218 dargestellt ist, kann die Prozessanlage 10 mehrere Edge-Gateways enthalten, die jeweils als Validierungsknoten in einem verteilten Ledger-Netzwerk fungieren. 3 zeigt ein Beispiel für ein verteiltes Ledgersystem 300 zum Aufzeichnen von Prozessanlagen-Daten. Zu den Prozessanlagendaten können Prozessparameterdaten, Produktparameterdaten, Konfigurationsdaten, Benutzerinteraktionsdaten, Wartungsdaten, Inbetriebnahmedaten, Anlagennetzwerkdaten, Produktverfolgungsdaten, Ereignisdaten in Bezug auf Ereignisse in der Prozessanlage 10 wie Alarme, Leckagen, Ausfälle, Fehler usw. oder andere geeignete Daten gehören, die in einer oder mehreren Prozessanlagen erzeugt wurden oder sich auf diese beziehen.
Das System 300 umfasst ein verteiltes Ledger 312 und mehrere Knoten 302, 304, 306, 308 und 310, die Edge-Gateways in der Prozessanlage 10, wie z. B. das Edge-Gateway 218, Feldgeräte oder beliebige geeignete Computergeräte sein können, die in der Prozessanlage 10 oder in anderen Prozessanlagen arbeiten. Jeder Knoten verwaltet eine Kopie des verteilten Ledgers 312. Bei Änderungen im verteilten Ledger 312 erhält jeder Knoten die Änderung über das Netzwerk 314 und aktualisiert seine jeweilige Kopie des verteilten Ledgers 312. Über einen Konsensus-Mechanismus können die Knoten 302-310 im verteilten Ledger-System 300 entscheiden, ob es sinnvoll ist, empfangene Änderungen im verteilten Ledger 312 vorzunehmen.
Jeder Knoten im System hat daher eine eigene Kopie des verteilten Ledgers 312, die identisch ist mit jeder anderen Kopie des verteilten Ledgers 312, die von den anderen Knoten gespeichert wird. Das verteilte Ledger-System 300 kann aufgrund der dezentralen Natur des verteilten Ledgers robuster sein als ein Datenbanksystem einer zentralen Stelle. Somit gibt es auf dem verteilten Ledger-System 300 keinen Single Point of Failure, wie dies in einem zentralisierten System der Fall wäre.
4 zeigt beispielhaft validierende Netzwerkknoten sowie ein Beispiel für den Transaktionsfluss 400 in einem verteilten Ledger-Netzwerk zur Abwicklung von Transaktionen. 4 enthält zwei Zeitrahmen 420 und 422, die durch die linke bzw. rechte Seite der gepunkteten Linie dargestellt sind, Knoten A 402 und Knoten B 404 (die zwei Edge-Gateways in einer Prozessanlage 10, zwei Edge-Gateways in zwei verschiedenen Prozessanlagen, zwei Feldgeräte in der gleichen oder in verschiedenen Prozessanlagen usw. sein können), einen Satz von Transaktionen 408A-408D, einen Satz von Blöcken von Transaktionen 409A-409D, ein verteiltes Ledger 410 sowie eine Blockchain 418.
Der Blockübertragungsfluss 400 kann mit dem Knoten A 402 beginnen, der die Transaktion 406 zurzeit 420 empfängt. Wenn der Knoten A 402 bestätigt, dass die Transaktion 406 gültig ist, kann der Knoten A 402 die Transaktion einem neu erzeugten Block 408 hinzufügen. Als Teil der Hinzufügung der Transaktion 406 zum Block 408 kann der Knoten A 402 ein kryptographisches Puzzle lösen und die Lösung in den neu generierten Block 408 aufnehmen, als Beweis für die zur Generierung des Blocks 408 geleistete Arbeit. Alternativ kann zur Erzeugung des Blocks 408 ein Proof-of-Stake-Algorithmus verwendet werden, wobei der Knoten A 402 eine Menge eines im Netzwerk verwendeten digitalen Token „absteckt“, das Netzwerk selbst jedoch den Knoten bestimmt, der den neuen Block prägen wird. In anderen Ausführungsformen kann die Transaktion 406 einem Pool von Transaktionen hinzugefügt werden, bis eine ausreichende Anzahl von Transaktionen im Pool vorhanden ist, um einen Block zu bilden. Der Knoten A 402 kann den neu erzeugten Block 408 zum Zeitpunkt 412 an das Netzwerk senden. Vor oder nach der Übertragung des Blocks 408 kann der Knoten A 402 den Block 408 zu seiner Kopie der Blockchain 418 hinzufügen.
Während „Proof of Work“ und „Proof of Stake“ hier als Konsensus-Algorithmen für die Auswahl eines Knotens zur Prägung eines neuen Blocks beschrieben werden, sind dies nur einige wenige Beispiele für Konsensus-Algorithmen und sollen nicht einschränkend sein. Es können zusätzliche Konsensus-Algorithmen verwendet werden, wie z. B. ein delegiertes „Proof of Stake“, bei dem die Knoten eine Untergruppe von Knoten, die als Delegaten bezeichnet werden, auswählen, um die Validierung durchzuführen, und die Delegaten abwechselnd neue Blöcke prägen. Konsensus-Algorithmen können auch den Autoritätsnachweis, Gewichtsnachweis, byzantinische Fehlertoleranz, Tangle-Konsensus-Algorithmen, Blockgitter-Konsensus-Algorithmen, usw. umfassen.
In jedem Fall können die Transaktionen 409A-409D Aktualisierungen in einer Status-Datenbank 416 enthalten. Die Status-Datenbank 416 kann aktuelle Werte von Variablen enthalten, die durch intelligente Verträge, die auf der Blockchain 418 eingesetzt werden, erzeugt wurden. Validierte Blöcke, wie z. B. Block 408, können Transaktionen enthalten, die sich auf die Status-Variablen in der Status-Datenbank 416 auswirken. Zum Zeitpunkt 422 kann der Knoten B 404 den neu erstellten Block 408 über das Netzwerk bei 412 empfangen. Der Knoten B 404 kann überprüfen, ob der Block von Transaktionen 408 gültig ist, indem er die Lösung des kryptographischen Puzzles im Block 408 überprüft. Wenn die Lösung richtig ist, kann der Knoten B 404 den Block 408 zu seiner Blockchain 418 hinzufügen und alle Aktualisierungen in der Status-Datenbank 416 vornehmen, die von den Transaktionen in Block 408 abgelehnt wurden. Der Knoten B 404 kann anschließend den Block 408 zum Zeitpunkt 314 an den Rest des Netzwerks senden.
5 zeigt beispielhafte Komponenten eines Validierungsnetzwerkknotens 500 auf einem verteilten Ledger-Netzwerk zur Erfassung von Prozessanlagen-Daten. Der Knoten 500 kann mindestens einen Prozessor 502, Speicher 504, ein Kommunikationsmodul 506, eine Reihe von Anwendungen 508, externe Ports 510, einen Blockchain-Manager 514, intelligente Verträge 516 und ein Betriebssystem 518 enthalten. In einigen Ausführungsformen kann der Knoten 500 einen neuen Block von Transaktionen erzeugen oder mit Hilfe des Blockchain-Managers 514 Transaktionen an andere Netzwerkknoten senden. In ähnlicher Weise kann der Knoten 500 den Blockchain-Manager 514 in Verbindung mit den im Speicher 504 gespeicherten intelligenten Verträgen 516 verwenden, um die hier beschriebene Funktionsweise auszuführen. Der Speicher 504 kann ferner Chain-Daten 524 enthalten, darunter z. B. eine Status-Datenbank der Blockchain zur Speicherung der Zustände der darauf bereitgestellten intelligenten Verträge.
In anderen Ausführungsformen arbeiten die intelligenten Verträge 516 unabhängig vom Blockchain-Manager 514 oder anderen Anwendungen. In einigen Ausführungsformen verfügt der Knoten 500 nicht über einen Blockchain-Manager 514 oder intelligente Verträge 516, die am Knoten gespeichert sind. In einigen Ausführungsformen kann der Knoten 500 zusätzliche oder weniger Komponenten als beschrieben aufweisen. Die Komponenten des Knotens 500 werden nachstehend noch ausführlicher beschrieben.
Der Knoten 500 als Teil eines dezentralisierten Ledger-Systems 300 oder eines anderen dezentralisierten oder zentralisierten Netzwerks kann als Teil von Systemen verwendet werden, die mit Daten oder Ereignissen in einer oder mehreren Prozessanlagen interagieren und/oder Transaktionen manipulieren, die mit diesen Daten oder Ereignissen verbunden sind.
6A zeigt beispielhaft ein verteiltes Ledger 600 mit einer Blockchain mit den Blöcken 602-608 von Transaktionen in einem Prozesssteuerungssystem. In einigen Ausführungsformen umfasst die Blockchain 600 mehrere Blöcke 602-608, die miteinander verbunden sind, um eine Chain von Blöcken 602-608 von Transaktionen zu bilden. Um Blöcke und Transaktionen kryptographisch miteinander zu verknüpfen, organisiert jeder Block in der Blockchain 600 seine Transaktionen in einem Merkle-Baum. In einem Merkle-Baum wird jede Transaktion nach einem kryptographischen Hash-Algorithmus (z. B., SHA-256) gehasht und der entstandene Ausgabe-Hash wird dann mit dem Hash einer anderen Transaktion kombiniert. Danach wird das kombinierte Ergebnis ebenfalls nach dem kryptographischen Hashing-Algorithmus gehasht. Diese Ausgabe wird dann mit dem Hash zweier anderer Transaktionen kombiniert und dieser Prozess wird so lange wiederholt, bis alle Transaktionen im Block zusammengefasst und gehasht sind, um eine Merkle-Wurzel zu erzeugen, die im Header für einen Block 602-608 verwendet wird. Wenn eine einzelne Transaktion im Block geändert wird, würde eine andere Merkle-Wurzel erzeugt werden, da die Merkle-Wurzel eine Kombination der Hashes aller Transaktionen im Block ist.
Mit anderen Worten, die Transaktionen können mit Hilfe eines kryptographischen Hash-Algorithmus, wie die oben beschriebenen Algorithmen, gehasht werden, und der Hash jeder Transaktion kann im Baum gespeichert werden. Während des Aufbaus des Baums kann der Hash jedes benachbarten Knotens auf derselben Ebene zusammen gehasht werden, um einen neuen Knoten zu erzeugen, der auf einer höheren Ebene im Baum existiert. Daher ist der Knoten an der Spitze des Baumes oder Merkle-Wurzel, abhängig vom Hash jeder Transaktion, der unten im Baum gespeichert ist. Jede Transaktion kann einen Datensatz enthalten. Der Datensatz kann Identifizierungsdaten für die Transaktion sowie Transaktionsdaten enthalten, die die Art der Transaktion und die mit der Transaktion verbundenen Auswirkungen identifizieren (z. B. Ein- und Ausgangsadressen, einen Transaktionswert, einen Dokument-Hash-Wert, einen Zeitstempel, einen Transaktionsgebührenwert usw.).
Um die Gültigkeit eines Blocks zu überprüfen, kann ein Knoten die Merkle-Wurzel des Blocks mit der Merkle-Wurzel desselben Blocks vergleichen, der in den Kopien anderer Knoten der Blockchain enthalten ist. Somit kann die Merkle-Wurzel als Beweis für die im Block enthaltenen Transaktionen und als Beweis dafür verwendet werden, dass der Inhalt des Blocks nicht geändert wurde, wenn die Merkle-Wurzel in der Kopie des Blocks jedes Knotens gleich ist.
In einer Ausführung sind Dokumente, die „auf“ einer Blockchain gespeichert sind, Dokumente, die nach einem kryptographischen Hashing-Algorithmus (z. B. SHA-256) gehasht wurden und der entstandene Ausgabe-Hash wurde in eine Transaktion in einem Block aufgenommen, der von den Netzwerkknoten als den Konsens-Regeln der Blockchain entsprechend akzeptiert wurde. Als solche können die Dokumente später verifiziert oder validiert werden, indem der Hash der Dokumente mit dem auf der Blockchain gespeicherten Hash verglichen wird. Wenn z. B. ein Satz von Dokumenten einen SHA-256 Hash ergibt, der an einem bestimmten Datum auf einer Blockchain aufgezeichnet wurde, dann liefert die Blockchain den kryptographischen Nachweis dafür, dass die Dokumente zu diesem Datum existierten.
Eine Möglichkeit zum Speichern eines Dokuments in einer Blockchain besteht darin, eine Transaktion mit einem Hash des Dokuments an das Netzwerk zu senden, das in einem Block enthalten ist, wenn die Transaktion alle Konsens-Regeln des Netzwerks erfüllt. In einigen Ausführungen ist die Blockchain ein permissioned Ledger, was bedeutet, dass nur autorisierte Netzwerkteilnehmer Transaktionen senden dürfen. In anderen Ausführungen dürfen nur einige autorisierte Netzwerkteilnehmer bestimmte Transaktionen durchführen. Beispielsweise können Produktparameterdaten, die die Eigenschaften eines in einer Prozessanlage 10 erzeugten Produkts anzeigen, von einem Feldgerät in die Blockchain 600 hochgeladen werden, da das Feldgerät die Eigenschaften des Produkts bestimmt (z. B. eine Temperatur des Produkts, ein Volumen des Produkts, eine Masse des Produkts, eine Dichte des Produkts, einen Druck des Produkts usw.). Nur ein kryptographischer Hash der Daten darf in die Blockchain 600 aufgenommen werden, sodass die Daten mit Hilfe der Blockchain verifiziert werden können, auch wenn sie von einer Partei außerhalb der Chain erhalten werden.
Durch die Validierung von Netzwerkknoten kann überprüft werden, ob die signierte Transaktion oder die signierte Nachricht mit dem privaten kryptographischen Schlüssel signiert wurde, der dem veröffentlichten kryptographischen Public Key entspricht, der dem Feldgerät gehört, das die Messungen erfasst. In mindestens einer Ausführung kann ein gültiger Identitätsnachweis als Konsens-Regel durch das Blockchain-Netzwerk angewendet werden. Daher wird jede Transaktion, die versucht, neue Produktparameterdaten hinzuzufügen, ohne dass ein kryptographischer Identitätsnachweis vorliegt, der mit einer Identität übereinstimmt, die zum Hinzufügen neuer Produktparameterdaten berechtigt ist, vom Netzwerk als nicht konform mit der Konsens-Regel abgelehnt. Jedem Feldgerät in einer Prozessanlage 10 kann ein Public Key-/Private Key-Paar zugeordnet werden, das im Blockchain-Netzwerk als dem Feldgerät entsprechend identifiziert wird. Zusätzlich kann jedes Feldgerät zur Erfassung bestimmter Arten von Messungen berechtigt sein. Beispielsweise kann ein erstes Feldgerät zur Erfassung von Temperaturmessungen für ein Produkt autorisiert werden, während ein zweites Feldgerät zur Erfassung von Volumenmesswerten, die das Volumen des hergestellten Produkts angeben, autorisiert werden kann. Wenn die validierenden Netzwerkknoten eine Transaktion in Bezug auf Produktparameterdaten erhalten, die nicht von einem autorisierten Feldgerät stammt oder eine Art von Messung beinhaltet, für deren Erfassung das Feldgerät nicht autorisiert ist, lehnen die validierenden Netzwerkknoten die Transaktion ab.
6B zeigt ein weiteres Beispiel für ein verteiltes Ledger 650, das eine andere Architektur als die in 6A beschriebene Architektur aufweist. Das verteilte Ledger 650 in 6B enthält eine Blockchain 660 mit den Blöcken 662-668 von Transaktionen in einem Prozesssteuerungssystem, ähnlich wie das verteilte Ledger 600 in 6A. Die Blockchain 660 kann im verteilten Ledger 650 als Haupt-Blockchain bezeichnet werden. Zusätzlich zur Haupt-Blockchain 660 enthält das verteilte Ledger 650 mehrere Side-Blockchains 670, 680 oder Side-Chains, die von verschiedenen Prozessanlagen mit den Blöcken 672-676, 682-686 von Transaktionen verwaltet werden. Beispielsweise kann die Side-Chain 670 von zwei verfahrenstechnischen Anlagen gewartet werden: Anlage A und Anlage B zur Aufzeichnung von Transaktionen im Zusammenhang mit Ereignissen, die innerhalb oder zwischen den beiden verfahrenstechnischen Anlagen auftreten. Bei diesen Transaktionen kann es vorkommen, dass Anlage B die Zahlung in Form eines Token-Wertes an Anlage A sendet, wenn Anlage A ein Produkt an Anlage B liefert. Die Side-Chain 680 kann auch von zwei verfahrenstechnischen Anlagen verwaltet werden: Anlage C und Anlage D zur Aufzeichnung von Transaktionen im Zusammenhang mit Ereignissen, die innerhalb oder zwischen Anlage C und Anlage D stattfinden. Diese Transaktionen können die Aufzeichnung der von Anlage C erhaltenen Ölmenge innerhalb eines bestimmten Zeitraums durch Anlage D beinhalten.
In einigen Ausführungsformen wird die Haupt-Blockchain 660 von mehreren Prozessanlagen, darunter die Anlagen A-D, zusammen mit mehreren anderen Prozessanlagen verwaltet. Auch in einigen Ausführungsformen interagieren die Side-Chains 670, 680 mit der Haupt-Blockchain 660, um zumindest einige der Transaktionen in ihren jeweiligen Blöcken 672-676, 682-686 für die Haupt-Blockchain 660 bereitzustellen. Auf diese Weise können die Side-Chains 670, 680 Daten aus Transaktionen enthalten, die sich auf die sie verwaltenden Prozessanlagen beziehen. Die Haupt-Blockchain 660 kann Daten von Transaktionen enthalten, die sich auf jede der Prozessanlagen beziehen. Darüber hinaus können die Side-Chains 670, 680 private oder sensible Daten enthalten, die nicht dazu bestimmt sind, außerhalb der Prozessanlagen, die eine bestimmte Sidechain verwalten, freigegeben zu werden. Daten von der Side-Chain 670, die nicht privat oder sensibel sind, können an die Haupt-Blockchain 660 übermittelt werden, während die privaten oder sensiblen Daten nicht an die Haupt-Blockchain 660 übermittelt werden. Beispielsweise kann die Side-Chain 670 einen intelligenten Vertrag zwischen Anlage A und Anlage B ausführen, der einen Token-Wert von Anlage A an Anlage B überträgt, wenn Anlage A von Anlage B ein Produkt erhält, das bestimmte Qualitätsstandards erfüllt. Die Anlagen A und B möchten möglicherweise nicht alle Bedingungen des intelligenten Vertrags der Öffentlichkeit oder einer großen Gruppe von Prozessanlagen offenlegen, indem sie den intelligenten Vertrag auf der Haupt-Blockchain 660 verwenden, oder sie möchten möglicherweise nicht, dass jede Messung der Produkteigenschaften der Öffentlichkeit oder einer großen Gruppe von Prozessanlagen zur Verfügung gestellt wird. Zusätzlich erhöht sich der Speicherbedarf für die Haupt-Blockchain 660, je mehr Transaktionen auf der Haupt-Blockchain 660 hinzugefügt werden. Dementsprechend kann es den Speicherbedarf für die Validierung von Knoten im Netzwerk des verteilten Ledgers verringern, um einige Transaktionen außerhalb der Haupt-Blockchain 660 zu speichern. Wenn der intelligente Vertrag feststellt, dass Anlage A von Anlage B ein Produkt erhalten hat, das die erforderlichen Qualitätsstandards erfüllt, kann die Transaktion, die den Token-Wert von Anlage A auf Anlage B überträgt, in jedem Fall der Haupt-Blockchain 660 zur Verfügung gestellt werden.
In einigen Ausführungsformen ist die Haupt-Blockchain 660 eine öffentliche Blockchain, was bedeutet, dass jede Partei das verteilte Ledger einsehen, neue Informationen übermitteln, die dem Ledger hinzugefügt werden sollen, oder dem Netzwerk als Validierungsknoten beitreten kann. Die Side-Chains 670, 680 sind private oder permissioned Blockchains, die Chain-Daten zwischen einer Gruppe von Einheiten geheim halten, die für die Teilnahme am Side-Blockchain-Netzwerk autorisiert sind (z. B. kann die Side-Chain 670 zwischen Anlage A und Anlage B privat sein). In anderen Ausführungsformen ist die Haupt-Blockchain 660 ebenfalls eine permissioned Blockchain, aber die Haupt-Blockchain hat eine größere Anzahl von Einheiten, die für die Teilnahme am Blockchain-Netzwerk autorisiert sind, als die Side-Chains 670, 680. Beispielsweise kann die Haupt-Blockchain 660 zwischen einer großen Anzahl von Prozessanlagen einschließlich der Anlagen A-D und mehreren anderen Prozessanlagen privat sein, während die Side-Chain 670 zwischen Anlage A und Anlage B privat ist.
Zusätzlich oder alternativ zu den Side-Chains kann das verteilte Ledger 650 andere Formen von Off-Chain-Transaktionen enthalten, die nicht Teil der Haupt-Blockchain 660 sind. Beispielsweise können zwei Parteien wie Anlage A und Anlage B einen Zahlungskanal eröffnen, wobei eine erste Transaktion, bei der ein Schwellenbetrag eines Token zwischen Anlage A und Anlage B ausgetauscht wird, der Haupt-Blockchain 660 zur Verfügung gestellt wird. Danach können Anlage A und Anlage B miteinander Transaktionen durchführen, ohne dass auf der Haupt-Blockchain 660 etwas aufgezeichnet wird, solange sie Anteile des Schwellenbetrags hin und her senden, und keine der Transaktionen dazu führt, dass eine der Prozessanlagen mehr als den Schwellenbetrag hat. Wenn die beiden Prozessanlagen ihre Transaktionen miteinander beendet haben, können sie den Zahlungskanal schließen und die endgültigen Token-Marken für jede Prozessanlage in der Haupt-Blockchain 660 bereitstellen. Beispielsweise können Anlage A und Anlage B einen Zahlungskanal öffnen, wenn Anlage A zwei Token an Anlage B sendet. Anlage B kann dann einen Token an Anlage A zurückschicken, sodass jede Prozessanlage einen Token hat, Anlage B kann 0,5 Token an Anlage A zurückschicken usw., solange keine der Prozessanlagen mehr als zwei Token hat. In anderen Ausführungsformen kann das verteilte Ledger 650 mehrere Blockchain-Schichten einschließlich getrennter, unabhängig voneinander arbeitender Blockchains enthalten. Beispielsweise kann eine erste Blockchain-Schicht Transaktionen in Bezug auf die Lieferkette aufzeichnen, während eine zweite Blockchain-Schicht Transaktionen im Zusammenhang mit dem Token-Austausch aufzeichnen kann. Die erste Blockchain-Schicht kann öffentlich sein, während die zweite Blockchain-Schicht privat ist oder umgekehrt.
Zusätzlich zum Schutz der Privatsphäre über Side-Chains oder Off-Chain-Transaktionen kann in einigen Ausführungsformen die Privatsphäre auf einer öffentlichen Blockchain, wie der Blockchain 600, wie in 6A dargestellt, gewahrt werden. Beispielsweise können die Transaktionen in der Blockchain 600 durch verschiedene Verschlüsselungstechniken die Identitäten der Transaktionspartner und die Transaktionsbeträge verschleiern.
7A-7C zeigen ein weiteres Beispiel für ein verteiltes Ledger 700, das eine andere Architektur als die in 6A beschriebene Architektur aufweist. Das verteilte Ledger 700 in 7A-7C enthält mehrere lokale Blockchains 710, 720, wobei jede lokale Blockchain 710, 720 von einer anderen Partei oder einer anderen Prozessanlage verwaltet wird. Jede lokale Blockchain 710, 720 beinhaltet einen Block von Transaktionen 712-716, 722-726 in einem Prozesssteuerungssystem. Beispielsweise können mehrere Prozessanlagen eine Ressource gemeinsam nutzen, wie Öl aus einer Ölpipeline, Strom aus einem Stromerzeugungssystem, ein Produkt über den Schienen-, Automobil-, Schiffs- oder Lufttransport, ein Produkt über eine Flüssigkeits-, Gas-, Dampf-, Kraftstoff- oder Material-Pipeline oder Wasser aus einem Wasserverteilungssystem. Feldgeräte in Anlage A können Messungen bezüglich der gemeinsam genutzten Ressource, wie z. B. eine aus der Pipeline gewonnene Ölmenge, erfassen und die Messdaten in Transaktionen an die lokale Blockchain für Anlage A senden. Ebenso können Feldgeräte in Anlage B Messungen bezüglich der gemeinsam genutzten Ressource erfassen und die Messdaten in Transaktionen an die lokale Blockchain für Anlage B senden.
Wie in 7B dargestellt, werden Transaktionen von jeder lokalen Blockchain 710, 720 einer globalen Blockchain 730 für den jeweiligen Partner oder die jeweilige Prozessanlage zur Verfügung gestellt, wobei die globale Blockchain 730 von mehreren Prozessanlagen und/oder über Cloud Services mit mehreren Cloud Computersystemen verwaltet wird. Beispielsweise werden Blöcke aus der lokalen Blockchain 710 für Anlage A der globalen Blockchain 730 für Anlage A zur Verfügung gestellt, Blöcke aus der lokalen Blockchain 720 für Anlage B der globalen Blockchain für Anlage B, usw. Die Blöcke von Transaktionen können von lokalen Blockchains an entsprechende globale Blockchains nach einem Schwellenwertzeitraum oder einer Schwellenwert-Epoche bereitgestellt werden. Auf diese Weise kann die Validierung von Knoten innerhalb einer bestimmten Prozessanlage, die jede lokale in Blockchain verwalten, Blöcke aus der lokalen Blockchain entfernen oder löschen, die der globalen Blockchain mit Ausnahme des aktuellsten Blocks zur Verfügung gestellt wurden, um die Speicheranforderungen zu reduzieren.
Wie in 7B dargestellt, werden der lokalen Blockchain 710 für Anlage A während der Zeit-Epoche E (Ref. Nr. 740) der Block N (Ref. Nr. 742), der Block N+1 (Ref. Nr. 746) und der Block N+2 (Ref. Nr. 748) hinzugefügt. Nach Ablauf der Schwellenzeit für die Zeitepoche E stellen die Validierungsknoten, die die lokale Blockchain 710 für Anlage A verwalten, die Blöcke N - N+2 (Ref. Nr. 742-746) der globalen Blockchain 730 für Anlage A zur Verfügung. Anschließend entfernen oder löschen die Validierungsknoten, welche die lokale Blockchain 710 für Anlage A verwalten, Block N (Ref. Nr. 742) und Block N+1 (Ref. Nr. 744) aus der lokalen Blockchain 710, um den Speicherbedarf zu reduzieren. Die lokale Blockchain 710 umfasst zurzeit nur den aktuellsten Block, den Block N+2 (Ref. Nr. 746). Dann werden in der Zeit-Epoche E+1 (Best.-Nr. 750) die Blöcke N+3 (Ref. Nr. 752) und N+4 (Ref. Nr. 754) zur lokalen Blockchain 710 hinzugefügt. Nach Ablauf des Schwellenwertzeitraums für die Zeit-Epoche E+1 stellen die Validierungsknoten, die die lokale Blockchain 710 für Anlage A verwalten, die Blöcke N+3 - N+4 (Ref. Nr. 752-754) der globalen Blockchain 730 für Anlage A zur Verfügung. Anschließend entfernen oder löschen die Validierungsknoten, die die lokale Blockchain 710 für Anlage A verwalten, die Blöcke N+2 - N+3 (Ref. Nr. 746, 752) aus der lokalen Blockchain 710. Die lokale Blockchain 710 umfasst zurzeit nur den aktuellsten Block, den Block N+4 (Ref. Nr. 754).
Wie in 7C dargestellt, kombinieren die Validierungsknoten, die die globalen Blockchains verwalten, wie z. B. die globale Blockchain für Werk A 730 und die globale Blockchain für Werk B 770, die globalen Blockchains 730, 770 zu einer Super-Blockchain 760 mit den Status-Blöcken 762, 764. Jeder Status-Block 762, 764 enthält jeden der Blöcke aus den globalen Blockchains 730, 770 für einen bestimmten Zeitraum. Beispielsweise enthält der Status-Block K (Ref. Nr. 762) den jeweiligen Block N, Block N+1 und Block N+2 aus jeder globalen Blockchain 730, 770. Der Status-Block K+1 (Ref. Nr. 764) enthält den jeweiligen Block N+3, Block N+4 und Block N+5 aus jeder globalen Blockchain 730, 770.
Zur kryptographischen Verknüpfung von Blöcken und Transaktionen untereinander organisiert jeder Status-Block 762, 764 in der Super-Blockchain 760 seine Transaktionen in einem Merkle-Baum. Sobald eine einzelne Transaktion im Status-Block geändert wird, wird eine andere Merkle-Wurzel erzeugt, da die Merkle-Wurzel eine Kombination aus den Hashes aller Transaktionen im Block ist. Die Merkle-Wurzel für jeden Status-Block 762, 764 ist im Header für den Status-Block 762, 764 enthalten.
Das verteilte Ledger 700, das in den 7A - 7C mit lokalen Blockchains, globalen Blockchains und einer Super-Blockchain ermöglichen es konkurrierenden Einheiten, die Genauigkeit von Messdaten zu überprüfen. Wenn beispielsweise Anlage A an Anlage B meldet, dass Anlage A 30.000 Gallonen Öl aus einer von beiden Einheiten gemeinsam genutzten Ölpipeline entnommen hat, kann Anlage B Messdaten von der Super-Blockchain abrufen, um die Genauigkeit dieser Messung zu überprüfen. Die Messdaten können auch innerhalb der Super Blockchain 760 kryptographisch verifiziert werden, indem eine erwartete Merkle-Wurzel für den Header des Status-Blocks, der die Messdaten enthält, berechnet wird und die tatsächliche Merkle-Wurzel im Header des Status-Blocks mit der erwarteten Merkle-Wurzel verglichen wird. Dadurch können konkurrierende Entitäten, die die Super-Blockchain 760 analysieren, validieren, dass die Status-Blöcke 762, 764 in der Super-Blockchain 760 nicht geändert wurden.
Intelligente Verträge in einem Prozesssteuerungssystem
Wie oben beschrieben, können Prozesssteuerungssysteme intelligente Verträge in das verteilte Ledger zum Austausch von Werten einsetzen, z. B. bei Erhalt eines Produktes in gutem Zustand. Intelligente Verträge können auch für das verteilte Ledger bereitgestellt werden, damit Maschinen wie Feldgeräte ohne menschliches Eingreifen selbstständig Transaktionen durchführen können.
8 zeigt ein Beispiel für einen Status 806 eines intelligenten Vertrags in einem verteilten Ledger-Netzwerk innerhalb eines Prozesssteuerungssystems. 8 enthält eine Blockchain 802, einen Block von Transaktionen 804 und einen Status 806 eines intelligenten Vertrags für sichere Schreibanforderungen. Ein intelligenter Vertrag kann von jedem Teilnehmer im verteilten Ledger-Netzwerk oder Blockchain-Netzwerk (z. B. Anlagenbetreiber, Konfigurationstechniker, Prozesssteuerungssystem-Designer, usw.) eingesetzt werden, um z. B. für eine sichere Schreibanforderung einen Status 806 eines intelligenten Vertrags herzustellen. Der eingesetzte intelligente Vertrag kann Verfahren und Daten für andere Teilnehmer des Blockchain-Netzwerks zugänglich machen. Einige der Daten im Status des intelligenten Vertrags können private Daten sein, die nur durch Aufruf eines Verfahrens des intelligenten Vertrags oder nur von autorisierten Blockchain-Teilnehmern geändert werden dürfen. Eine Möglichkeit, den Status des intelligenten Vertrags zu ändern, ist die Übertragung einer Transaktion in das verteilte Ledger-Netzwerk. Wenn die gesendete Transaktion den Konsens-Regeln entspricht, können Netzwerk-Validierer die Transaktion in einen Block aufnehmen. Die Aufnahme in die Blockchain einer Transaktion, welche Daten an den intelligenten Vertrag sendet, kann die Validierungsknoten veranlassen, eine Status-Datenbank für den intelligenten Vertrag zu aktualisieren, wodurch die Netzteilnehmer Zugang zu einem Rich-State-Mechanismus erhalten, um die sichere Schreibanforderung zu verwalten und schließlich Parameterdaten in ein Gerät des Sicherheitssystems (SIS) zu schreiben.
Der Status eines intelligenten Vertrags für eine sichere Schreibanforderung 806 kann Daten zur Identifizierung des Betreibers, der die sichere Schreibanforderung übermittelt, des Computergeräts, das der Betreiber zur Übermittlung der sicheren Schreibanforderung verwendet, und/oder des SIS-Geräts, das das Ziel der sicheren Schreibanforderung ist, enthalten. In einigen Ausführungsformen kann der Betreiber durch kryptographische öffentliche Schlüssel identifiziert werden, die der elektronischen Geldbörse des Betreibers zugeordnet sind. Das Computergerät des Betreibers kann mit denselben kryptographischen öffentlichen Schlüsseln wie der Betreiber identifiziert werden, wenn die elektronische Geldbörse des Betreibers auf dem Computergerät des Betreibers betrieben wird. In anderen Ausführungsformen kann das Computergerät des Betreibers durch andere kryptographische öffentliche Schlüssel identifiziert werden, von denen die anderen Netzteilnehmer wissen, dass sie zum Computergerät des Betreibers gehören.
In einigen Ausführungsformen kann ein Vertragsinhaber eine eindeutige ID für das SIS-Gerät wählen, sodass nachfolgende Transaktionen und Daten, die an den intelligenten Vertrag gesendet werden, das SIS-Gerät anhand der ID-Nummer identifizieren können. Beispielsweise kann jedes SIS-Gerät im intelligenten Vertrag eine andere eindeutige Kennung haben. Der Vertragsinhaber kann auch Kennungen von Betreibern und/oder Computergeräten angeben, die für die Durchführung sicherer Schreibvorgänge autorisiert sind. Nachträglich an den intelligenten Vertrag gesendete Daten können eine mit privaten Schlüsseln signierte Nachricht enthalten, die den öffentlichen Schlüsseln entsprechen, die den Betreiber und/oder das Computergerät im intelligenten Vertrag identifizieren und so den kryptographischen Nachweis erbringen, dass die Transaktion von einem autorisierten Betreiber und/oder einem autorisierten Computergerät stammt. Die privaten und öffentlichen Schlüssel dürfen ausschließlich von den Betreibern/Computergeräten verwaltet werden, um die Angriffsfläche für Angreifer zu minimieren, die versuchen könnten, eine Transaktion zu fälschen (z. B. erzeugen die Betreiber/Computergeräte offline öffentliche/private kryptographische Schlüsselpaare und stellen den öffentlichen Schlüssel nur anderen Netzwerkteilnehmern zur Verfügung). Die privaten Schlüssel eines Betreibers und/oder Computers können anhand eines sicher gespeicherten Startwertes (z. B. auf einem Stück Papier oder mehreren Kopien eines Papiers) so generiert werden, dass die privaten Schlüssel im Falle eines Datenverlustes wiederhergestellt werden können.
Um Parameterdaten in ein SIS-Gerät zu schreiben, kann der Status eines intelligenten Vertrags für die sichere Schreibanforderung 806 einen Nachweis über die sichere Schreibanforderung erhalten. Der Nachweis für die sichere Schreibanforderung kann den Namen des im SIS-Gerät zu ändernden Parameters und/oder die Pfadangaben für den Parameter enthalten. Die Beweise können auch einen neuen Parameterwert enthalten, und in einigen Ausführungsformen können die Beweise einen Wert für die zyklische Redundanzprüfung (CRC) oder einen anderen Fehlerprüfungswert zusammen mit dem neuen Parameterwert enthalten, um sicherzustellen, dass die Parameterinformation nicht beschädigt wurde. In einigen Ausführungsformen kann der intelligente Vertrag als Reaktion auf den Empfang der Parameterinformationen einen Bestätigungsdialog für das Computergerät des Betreibers bereitstellen, der den Namen des SIS-Geräts, den Namen und/oder Pfad für den zu ändernden Parameter im SIS-Gerät, den neuen Parameterwert und eine Bestätigungstaste für den Betreiber zur Bestätigung der sicheren Schreibanforderung enthält. In diesem Szenario können die Nachweise einen Hinweis darauf enthalten, ob der Betreiber die Bestätigungstaste ausgewählt hat.
Der Betreiber und/oder das Computergerät des Betreibers kann Transaktionen an die Blockchain 802 senden, die die Beweise enthält. Die Beweise können kryptographisch signiert werden, um einen kryptographischen Identitätsnachweis zu erbringen, dass die Beweise von einem Betreiber und/oder dem Computergerät des Betreibers stammen, der für die Durchführung einer sicheren Schreibanforderung autorisiert ist. Dementsprechend kann der intelligente Vertrag die bereitgestellte Identität mit einer Liste von Betreibern und/oder Computergeräten vergleichen, die für die Durchführung sicherer Schreibanfragen autorisiert sind. In einigen Ausführungsformen kann der intelligente Vertrag die bereitgestellte Identität mit einer Liste von Betreibern und/oder Computergeräten vergleichen, die für die Durchführung sicherer Schreibanfragen für das jeweilige SIS-Gerät, welches das Ziel der sicheren Schreibanfrage ist, autorisiert sind.
Ein weiterer Aspekt des Status eines intelligenten Vertrags für eine sichere Schreibanforderung 806 sind die Daten des intelligenten Vertrags. Die Daten des intelligenten Vertrags können wie die privaten und öffentlichen Daten in einem Objekt, das nach einem objektorientierten Programmierparadigma erstellt wurde, insofern angesehen werden, als die Daten des intelligenten Vertrags direkt von außerhalb des Objekts aktualisiert werden können oder die Daten des intelligenten Vertrags nur auf eingeschränkte Weise aktualisiert werden können, z. B. durch Aufruf eines Verfahrens des intelligenten Vertrags. Die Daten des intelligenten Vertrags können den Namen und/oder Pfad für den zu ändernden Parameter im SIS-Gerät und den neuen Parameterwert enthalten. In einigen Ausführungsformen können die Daten des intelligenten Vertrags einen Hinweis darauf enthalten, ob die Parameterinformation unversehrt empfangen wurde. Beispielsweise kann die Transaktion mit dem zu ändernden Parameter und der Parameterinformation auch einen CRC-Wert oder einen anderen Fehlerprüfwert enthalten. Der intelligente Vertrag kann anhand des zu ändernden Parameters und der Parameterinformation einen erwarteten CRC-Wert generieren und den erwarteten CRC-Wert mit dem empfangenen CRC-Wert vergleichen. Stimmt der erwartete CRC-Wert mit dem empfangenen CRC-Wert überein, kann der intelligente Vertrag feststellen, dass die Parameterinformation unversehrt empfangen wurde. Auch in einigen Ausführungsformen können die Daten des intelligenten Vertrags einen Hinweis darauf enthalten, ob die sichere Schreibanforderung bestätigt wurde. Wenn der intelligente Vertrag z. B. eine Transaktion des Betreibers und/oder seines Computergerätes erhält, die anzeigt, dass der Betreiber die Bestätigungstaste gewählt hat, kann der intelligente Vertrag feststellen, dass die sichere Schreibanforderung bestätigt wurde.
Wie in 8 dargestellt, können die Daten des intelligenten Vertrags beispielsweise einen Parameter für die Sperrung/Entsperrung des SIS-Geräts, einen Parameterwert von „1“ oder „lock“, der angibt, dass der Parameter zur Sperrung des SIS-Geräts eingestellt werden soll, einen bestätigten Wert von „1“, „yes“ oder „true“, der angibt, dass die sichere Schreibanforderung bestätigt wurde, und einen Wert der empfangenen Datenintegrität von „1“, „yes“ oder „true“, der angibt, dass die Parameterinformation nicht beschädigt wurde, enthalten. Dementsprechend kann im intelligenten Vertrag festgelegt werden, dass der neue Parameterwert dem SIS-Gerät bereitgestellt werden soll. Dann kann der intelligente Vertrag die Parameterinformation an das SIS-Gerät oder an eine mit dem SIS-Gerät kommunikativ gekoppelte Steuerung liefern, um das sichere Datenschreiben durchzuführen.
In einigen Ausführungsformen kann der intelligente Vertrag für die sichere Schreibanforderung Parameterinformationen an ein Ziel-SIS-Gerät oder an eine kommunikativ mit dem Ziel-SIS-Gerät gekoppelte Steuerung liefern, wenn der Betreiber und/oder das Computergerät, das die sichere Schreibanforderung sendet, zur Durchführung sicherer Datenschreibvorgängen für das Ziel-SIS-Gerät autorisiert ist, die Parameterinformation nicht verfälscht wurde und die sichere Schreibanforderung bestätigt wird. In anderen Ausführungsformen bestimmt der intelligente Vertrag für die sichere Schreibanforderung nicht, ob die Parameterinformation unversehrt empfangen wird. Stattdessen liefert der intelligente Vertrag für eine sichere Schreibanforderung eine erste Instanz der Parameterinformation einschließlich des Parameternamens und/oder des Parameterpfads, des neuen Parameterwerts und des CRC-Werts an das SIS-Zielgerät oder die Steuerung als Reaktion auf den Empfang der sicheren Schreibanforderung. Der intelligente Vertrag für die sichere Schreibanforderung stellt als Reaktion auf die Bestätigung der sicheren Schreibanforderung auch eine zweite Instanz der Parameterinformation für das SIS-Zielgerät oder die Steuerung bereit. Die Steuerung bzw. das Ziel-SIS-Gerät stellt dann fest, ob die Parameterinformation in beiden Fällen gleich ist und ob die Parameterinformation unversehrt empfangen wurde. Wenn die Parameterinformation in beiden Fällen gleich ist und die Parameterinformation unversehrt empfangen wurde, schreibt die Steuerung oder das Ziel-SIS-Gerät den neuen Parameterwert für den Parameter in das Ziel-SIS-Gerät.
Während 8 den Status des intelligenten Vertrags für eine sichere Schreibanforderung 806 zeigt, dient dieses Beispiel nur der Veranschaulichung. Die Teilnehmer am verteilten Ledger-Netzwerk (z. B. Anlagenbetreiber, Konfigurationstechniker, Prozesssteuerungssystemdesigner usw.) können alle geeigneten intelligenten Verträge mit Bezug zur Prozesssteuerung einsetzen.
In einem anderen Beispiel kann ein intelligenter Vertrag bereitgestellt werden, der Geräteinformationen für ein Gerät in der Prozessanlage 10 abruft, bei dem eine Störung aufgetreten ist, und die Geräteinformationen einem Gerätelieferanten als Antwort auf den Empfang einer Anforderung zur Freigabe der Geräteinformationen bereitstellt. Genauer gesagt, wenn ein Gerät innerhalb der Prozessanlage 10 ausfällt, z. B. eine Prozessanlageneinheit, kann das Gerät eine Transaktion an eine Adresse für den im verteilten Ledger gespeicherten intelligenten Vertrag senden. Die Transaktion kann verschlüsselt signiert werden, um einen kryptographischen Identitätsnachweis bereitzustellen, dass die Transaktion von dem Gerät stammt. In anderen Ausführungsformen kann die Einheit der Prozessanlage einen Hinweis auf die Störung an eine Steuerung, ein Feldgerät oder ein anderes Prozesssteuerungsgerät übermitteln, das als Beweis-Orakel fungiert und die Transaktion generiert. In jedem Fall kann die Transaktion Produktinformationen für das Gerät enthalten, wie z. B. Identifizierungsinformationen für das Gerät, die Marke, das Modell und das Jahr des Geräts, den Wartungsverlauf für das Gerät, die Art der Störung, beschädigte Geräteteile usw.
In einigen Ausführungsformen überträgt der intelligente Vertrag die Geräteinformationen an ein Computergerät des Wartungspersonals innerhalb der Prozessanlage 10, damit das Wartungspersonal die Geräteinformationen überprüfen kann. Nach Überprüfung der Geräteinformationen kann das Wartungspersonal feststellen, dass die Geräteinformationen vom Gerätelieferanten zur weiteren Untersuchung der Störung und/oder zur Bereitstellung eines Ersatzgerätes oder von Ersatzteilen überprüft werden müssen. Dementsprechend kann das Computergerät des Wartungspersonals eine Transaktion generieren, die den intelligenten Vertrag auffordert, die Geräteinformationen dem Gerätelieferanten zur Verfügung zu stellen. Die Transaktion kann kryptographisch signiert werden, um einen kryptographischen Identitätsnachweis zu erbringen, dass die Transaktion vom Wartungspersonal stammt. Als Reaktion auf die Feststellung, dass die Anforderung zur Bereitstellung der Geräteinformationen an den Gerätelieferanten von autorisiertem Wartungspersonal erfolgte, kann der intelligente Vertrag die Geräteinformationen an ein Computergerät des Gerätelieferanten weitergeben.
Ein weiteres Beispiel für einen intelligenten Vertrag ist ein intelligenter Vertrag, der einen Token-Wert von einer ersten Prozessanlage erhält, und bestimmt, dass ein Produkt, das bestimmte Qualitätsstandards erfüllt, von einer zweiten Prozessanlage zur ersten Prozessanlage transferiert wird, und den Token-Wert der zweiten Prozessanlage zur Verfügung stellt. In einigen Ausführungsformen kann der intelligente Vertrag von einem Beweis-Orakel, wie z. B. einem Feldgerät in der ersten Prozessanlage, einen Hinweis darauf erhalten, dass das Produkt in der ersten Prozessanlage empfangen wurde. Das Feldgerät kann auch produktbezogene Parameterdaten liefern, die der intelligente Vertrag mit einer Reihe von Qualitätsmetriken vergleicht, um festzustellen, ob die Produkte die Qualitätsstandards erfüllen. Wenn das Produkt die Qualitätsstandards erfüllt, liefert der intelligente Vertrag den Token-Wert an die zweite Prozessanlage. Andernfalls kann der intelligente Vertrag den Token-Wert an die erste Prozessanlage zurücksenden.
Arten von Transaktionen, die in verteilten Ledgern in einem Prozesssteuerungssystem erfasst werden
Die verteilten Ledger des Prozesssteuerungssystems können viele verschiedene Arten von Transaktionen beinhalten, die sich auf die Prozesssteuerung beziehen. Diese Transaktionen können Folgendes umfassen: 1) Transaktionen in Bezug auf die Lieferung oder den Empfang eines Produkts in einer Prozessanlage 10 und die gelieferte/erhaltene Menge; 2) Transaktionen in Bezug auf Software- oder Firmware-Upgrades an Geräten innerhalb der Prozessanlage 10, wie z. B. Betreiberarbeitsstationen, Servergeräte, Steuerungen, E-/A-Geräte, Netzwerkgeräte, Feldgeräte usw.; 3) Transaktionen in Bezug auf die Qualitätskontrolle, die Produktion oder die behördliche Meldevorgänge in der Prozessanlage 10; 4) Transaktionen zur Aufzeichnung von Prozessanlagen-Daten; und 5) Transaktionen zur Aufzeichnung der Kontrollkette mit Hilfe von Produktverfolgungsdaten.
In einigen Szenarien werden die Transaktionen den intelligenten Verträgen zur Verfügung gestellt, z. B. zur Änderung eines Status eines intelligenten Vertrags. In anderen Szenarien werden die Transaktionen nicht den intelligenten Verträgen zur Verfügung gestellt und lediglich im verteilten Ledger als sicherer, unveränderlicher und vertrauenswürdiger Nachweis von Informationen über eine oder mehrere Prozessanlagen erfasst.
Transaktionen im Zusammenhang mit der Lieferung oder dem Erhalt eines Produkts und der gelieferten/erhaltenen Menge
9 zeigt ein Beispiel für eine Transaktion 906, die eine Beweis-Transaktion darstellt, die Aufschluss über die Ölmenge gibt, die in einer Prozessanlage 10 von einer Ölpipeline empfangen wurde. Während das Beispiel der Transaktion 906 in 9 die Ölmenge einer Ölpipeline angibt, dient dies nur der Veranschaulichung. Andere Materialien oder Produkte aus anderen Quellen können ebenfalls gemeldet werden, wie z. B. Strom aus einem Stromerzeugungssystem, ein Produkt über den Schienen-, Automobil-, Schiffs- oder Lufttransport, ein Produkt über eine Flüssigkeits-, Gas-, Dampf-, Kraftstoff- oder Materialleitung oder Wasser aus einem Wasserverteilungssystem. In jedem Fall kann die Transaktion 906 durch ein Feldgerät generiert werden, das als Beweis-Orakel fungiert. Wenn das Feldgerät erkennt, dass Öl durch ein Ventil fließt, sendet das Feldgerät eine Transaktion 906 an die Blockchain 902, um in einen Block, wie z. B. Block 904, aufgenommen zu werden.
Die Transaktion 906 kann eine Transaktions-ID und einen Urheber wie z. B. das Feldgerät 456 in Anlage A (identifiziert durch einen kryptographischen Identitätsnachweis) enthalten. Die Transaktion 906 kann auch Angaben zur Identifizierung des Produkts, zum Anbieter des Produkts (z. B. ein Ölproduzent) und Informationen über die Menge des erhaltenen Produkts enthalten. Das Feldgerät kann z. B. ein Durchflusssensor sein, der die in Anlage A erhaltene Ölmenge über einen bestimmten Zeitraum (z. B. eine Stunde, einen Tag usw.) ermittelt und das Volumen in die Transaktion einbezieht. In anderen Ausführungsformen kann das Feldgerät mehrere Durchflussraten in verschiedenen Zeiträumen in einer Reihe von Transaktionen enthalten, und die Durchflussraten als Funktion der Zeit können zur Bestimmung der in Anlage A erhaltenen Ölmenge verwendet werden. Außerdem kann die Transaktion 906 einen kryptographischen Hash der Informationen über das Ereignis, die Produktkennung und die Kennung des Produktanbieters enthalten. In einer anderen Ausführung werden die Informationen über das Ereignis, die Produktkennung und die Kennung des Produktanbieters nicht als kryptographischer Hash gespeichert, sondern sind im Block 904 für einen Beobachter oder anderen Netzteilnehmer direkt zugänglich.
Während in diesem Beispiel das Feldgerät für die Prozessanlage 10, die das Produkt erhält, eine Transaktion generiert, kann ein Feldgerät für eine Prozessanlage 10 oder eine andere Einheit, die das Produkt bereitstellt, eine Transaktion generieren. Diese Transaktion kann zusätzlich oder alternativ zur Transaktion durch das Feldgerät für die Prozessanlage 10, die das Produkt erhält, generiert werden.
Transaktionen im Zusammenhang mit Software- oder Firmware-Upgrades an Geräten innerhalb der Prozessanlage
Um ein Einbringen von unautorisierter Software oder Firmware in eine Prozessanlage 10 zu verhindern, können Software- und Firmware-Upgrades von Geräten innerhalb der Prozessanlage 10 in einem verteilten Ledger, wie den oben beschriebenen verteilten Ledgern, digital aufgezeichnet werden. Das verteilte Ledger kann ein Protokoll über jedes Software- und Firmware-Upgrade eines Gerätes innerhalb der Prozessanlage 10 führen, einschließlich der Zeit und des Datums des Upgrades, der Identität des Benutzers, der das Upgrade durchführt (über einen kryptographischen Identitätsnachweis), der Änderungen der vorherigen Softwareversion und/oder der neuen Softwareversion. Ein Server-Gerät 12 oder ein anderes Computergerät innerhalb der Prozessanlage 10 kann kontinuierlich oder periodisch (z. B. einmal pro Sekunde, einmal pro Minute, einmal pro Stunde, einmal pro Tag usw.) aktuelle Software- und Firmware-Versionen, die in Geräten der Prozessanlage 10 laufen, erhalten. Das Server-Gerät 12 kann auch die Transaktionen aus dem verteilten Ledger abrufen und die aktuelle Software oder Firmware in einem Gerät mit der neuesten Software- oder Firmwareversion vergleichen, die im verteilten Ledger gespeichert ist. In einigen Ausführungsformen speichert das verteilte Ledger einen kryptographischen Hash der neuen Software- oder Firmware-Version und vergleicht die aktuelle Software oder Firmware, die im Gerät ausgeführt wird, mit dem kryptographischen Hash-Wert, um zu überprüfen, ob die Software oder Firmware nicht manipuliert wurde.
Wenn die aktuelle Software oder Firmware im Gerät nicht mit der neuesten Version der im verteilten Ledger gespeicherten Software oder Firmware übereinstimmt, kann das Server-Gerät 12 das Gerät an der Ausführung der aktuellen Software oder Firmware hindern. In einigen Ausführungsformen kann das Server-Gerät 12 veranlassen, dass die Software oder Firmware im Gerät auf eine frühere Version zurückgesetzt wird, z. B. durch Herunterladen der früheren Version auf das Gerät. Somit ist eine Manipulation der in der Prozessanlage eingesetzten Soft- oder Firmware durch Unbefugte ausgeschlossen 10.
10 zeigt ein Beispiel für eine Transaktion 1006, die eine Beweis-Transaktion darstellt, die ein Software- oder Firmware-Update in einem Gerät innerhalb einer Prozessanlage 10 meldet. Die Transaktion 1006 kann von dem Gerät generiert werden, das die Upgrades erhält, z. B. eine Betreiberarbeitsstation, ein anderes Benutzerschnittstellen-Gerät 8, ein Server-Gerät 12, eine Steuerung 11, ein E-/A-Gerät 26, 28, ein Netzwerkgerät, ein Feldgerät 15-22, 40-46, usw. Ein Netzwerkgerät in der Prozessanlage 10 kann z. B. ein Wireless-Gateway 35, einen Router 58, einen drahtlosen Zugangspunkt 7a, 55, ein Edge-Gateway, einen drahtlosen Adapter 52, usw. umfassen.
Die Transaktion 1006 kann eine Transaktions-ID und einen Urheber enthalten, der die Software oder Firmware ändert, wie z. B. John Doe (identifiziert durch einen kryptographischen Identitätsnachweis). Die Transaktion 1006 kann auch Identifizierungsinformationen (Betreiberarbeitsstation 1234) für das Gerät, das die Software oder Firmware ausführt (identifiziert durch einen kryptografischen Identitätsnachweis), eine Beschreibung einschließlich einer Versionsnummer sowie Zeit und Datum des Upgrades („Update auf Version 10.3.1.4 am 15. Januar 2019 um 6:02 Uhr“) enthalten. Darüber hinaus kann die Transaktion 1006 einen kryptographischen Hash der Software-Befehle für die neue Version der Software enthalten. In einer anderen Ausführung wird die neue Version der Software nicht als kryptographischer Hash gespeichert, sondern ist im Block 1004 von einem Beobachter oder anderen Netzwerkteilnehmern direkt zugänglich. In einigen Ausführungsformen geben die Konsens-Regeln an, dass nur autorisierte Benutzer Software- oder Firmware-Updates auf dem verteilten Ledger speichern dürfen. Wenn dementsprechend die Transaktion 1006 an das verteilte Ledger gesendet wird, validieren die Validierungsknoten die Transaktion 1006, wenn der Urheber ein autorisierter Benutzer ist. Wenn der Urheber kein autorisierter Benutzer ist, wird die Transaktion 1006 nicht in das verteilte Ledger aufgenommen, und die Aktualisierung der Software stimmt nicht mit der neuesten Version der im verteilten Ledger gespeicherten Software überein.
In einem Beispiel-Szenario erhält ein Server-Gerät 12 in der Prozessanlage 10 am 15. Januar 2019 um 6:03 Uhr morgens den Status der in der Betreiberarbeitsstation 1234 ausgeführten Software und vergleicht die Software mit dem kryptographischen Hash der Software-Befehle für die neue Version der Software im verteilten Ledger, indem es z. B. einen kryptographischen Hash der in der Betreiberarbeitsstation 1234 ausgeführten Software-Befehle durchführt. Wenn die kryptographischen Hashes gleich sind, stellt das Servergerät 12 fest, dass die Software nicht manipuliert wurde. Falls sich die kryptographischen Hashes hingegen unterscheiden, stellt das Servergerät fest, dass die Software manipuliert wurde und verhindert, dass die Betreiberarbeitsstation 1234 die Software in ihrem aktuellen Zustand ausführt. Das Servergerät 12 lädt dann den vorherigen Status der Software auf die Betreiberarbeitsstation 1234 herunter, und die Betreiberarbeitsstation 1234 setzt die Ausführung der Software in ihrem vorherigen Status fort.
Transaktionen im Zusammenhang mit der Qualitätskontrolle, der Produktion oder den behördlichen Meldevorgängen in der Prozessanlage
In Prozessanlagen gelten Melde- und Aufzeichnungspflichten, um die Anforderungen der Regulierungsbehörden, wie z. B. der Umweltschutzbehörde (EPA), zu erfüllen. Beispielsweise hat die EPA Lecksuch- und Reparaturvorschriften (LDAR) erlassen, um die Emission flüchtiger organischer Verbindungen und gefährlicher Luftschadstoffe z. B. aus undichten Geräten wie Ventilen, Pumpen und Anschlüssen in Prozessanlagen zu minimieren. Zur Einhaltung der Vorschriften und zur Bereitstellung einer sicheren, unveränderlichen und vertrauenswürdigen Aufzeichnung können die Regulierungsdaten in einem verteilten Ledger aufgezeichnet werden. Beispielsweise können als Reaktion auf ein auslösendes Ereignis wie einen Alarm, einen Fehler, ein Leck, ein Reparaturereignis, einen Prozessmeilenstein, eine Korrekturmaßnahme usw. Prozesssteuerungselemente wie Feldgeräte, Steuerungen oder Prozessanlagen-Einheiten Transaktionen generieren, die Daten aus dem auslösenden Ereignis enthalten, wie z. B. den Zeitpunkt, an dem das Ereignis aufgetreten ist, die Dauer des Ereignisses, Prozessparameterwerte für am Ereignis beteiligte Prozessanlagen-Einheiten, Produktparameterwerte für am Ereignis beteiligte Produkte usw. Die Regulierungsdaten werden dann im verteilten Ledger aufgezeichnet, sodass die Regulierungsbehörden die Daten überprüfen können.
In einigen Ausführungsformen wird beim Eintreten eines auslösenden Ereignisses das auslösende Ereignis von einem der Prozesssteuerungselemente erkannt. Das Prozesssteuerungselement benachrichtigt dann andere Prozesssteuerungselemente über das auslösende Ereignis und weist dem auslösenden Ereignis eine eindeutige Kennung zu. Auf diese Weise kann jedes der Prozesssteuerungselemente Messungen in Bezug auf das auslösende Ereignis sammeln und Transaktionen an das verteilte Ledger senden, wobei jede Transaktion die gleiche eindeutige Kennung für das auslösende Ereignis enthält.
In einigen Ausführungsformen werden die Regulierungsdaten in einer öffentlichen Blockchain erfasst, sodass jeder die Regulierungsdaten von einer Prozessanlage 10 einsehen kann. In anderen Ausführungsformen werden die Regulierungsdaten in einer privaten oder permissioned Blockchain aufgezeichnet, auf die die Prozessanlage 10 und die Regulierungsbehörde zugreifen können. In wieder anderen Ausführungsformen werden die Regulierungsdaten in einer privaten oder permissioned Blockchain erfasst, auf die mehrere Prozessanlagen in einem Prozessanlagen-Netzwerk zusammen mit der Regulierungsbehörde zugreifen können.
11 zeigt ein Beispiel für die Transaktion 1106, die einen Prozessparameter oder Produktparameterdaten einer Beweis-Transaktion darstellt. Die Transaktion 1106 kann von einer Prozessanlageneinheit generiert werden, die ein Gerät innerhalb einer Prozessanlage 10 zur Verwendung in einem Teil des Prozesses sein kann, der physische Materialien umfasst, umwandelt, erzeugt oder transferiert, wie z. B. ein Ventil, einen Tank, einen Mischer, eine Pumpe, ein Heizgerät usw.
Die Transaktion 1106 kann eine Transaktions-ID und einen Urheber (Heizgerät Y-001) enthalten, der die Messung des Produkts oder der Prozessparameter (identifiziert durch einen kryptographischen Identitätsnachweis) erfasst. Die Transaktion 1106 kann auch Identifizierungsinformationen in Bezug auf das Produkt, Produktparameterdaten (z. B. die Temperatur des Produkts wurde 2 Stunden lang auf 100°C gehalten) und Prozessparameterdaten (z. B. die Temperatur im Heizgerät Y-001 beträgt 120°C) enthalten. Wenn die Transaktion 1106 als Reaktion auf ein auslösendes Ereignis generiert wird, kann die Transaktion 1106 auch Identifizierungsinformationen für das auslösende Ereignis und Ereignisdaten aus dem auslösenden Ereignis enthalten, wie z. B. den Zeitpunkt des auslösenden Ereignisses, die Dauer des auslösenden Ereignisses und/oder eine Beschreibung des auslösenden Ereignisses. In einigen Szenarien generieren mehrere Einheiten der Prozessanlage Transaktionen als Reaktion auf dasselbe auslösende Ereignis und kommunizieren miteinander, um dem auslösenden Ereignis eine eindeutige Kennung zuzuweisen. Auf diese Weise kann eine Partei, wie z. B. eine Regulierungsbehörde, die das verteilte Ledger überprüft, jede der mit demselben auslösenden Ereignis verbundenen Transaktionen einsehen.
Darüber hinaus kann die Transaktion 1106 einen kryptographischen Hash der Produkt- und/oder Prozessparameterdaten zusammen mit Daten, die sich auf ein auslösendes Ereignis beziehen, enthalten. In einer anderen Ausführung werden die Produktparameterdaten, Prozessparameterdaten und andere Daten, die sich auf ein auslösendes Ereignis beziehen, nicht als kryptographischer Hash gespeichert, sondern sind im Block 1104 für einen Beobachter oder anderen Netzwerkteilnehmer direkt zugänglich.
Wie oben beschrieben, können auslösende Ereignisse Alarme, Fehler, Leckagen, Reparaturereignisse, Abhilfemaßnahmen usw. sein. In einem Beispielszenario kann das auslösende Ereignis ein Leck in der Prozessanlage 10 sein, das durch das Öffnen eines Entlastungsventils verursacht wird. Das Überdruckventil kann sich öffnen, wenn der Druck im Prozesssteuerungssystem einen Schwellenwert überschreitet, oder das Entlastungsventil kann sich proportional zur Höhe des am Ventil gemessenen Drucks öffnen. Beim Öffnen des Überdruckventils kann das Überdruckventil oder ein oder mehrere andere Feldgeräte den Zeitpunkt des Öffnens, die Dauer des Öffnens, die Größe der Öffnung, den Druck im Entlastungsventil beim Öffnen, die Durchflussmenge des aus dem Entlastungsventil austretenden Fluids und/oder Eigenschaften des Fluids wie die Temperatur des Fluids, die Art des Fluids usw. erfassen. In einigen Ausführungsformen kann die Menge des aus dem Überdruckventil austretenden Fluids auch anhand der Durchflussmenge, der Größe der Öffnung und der Dauer der Öffnung des Entlastungsventils bestimmt werden. Dann kann das Überdruckventil und/oder ein oder mehrere andere Feldgeräte Transaktionen generieren, ähnlich der Transaktion 1106, die die gleiche eindeutige Kennung für das auslösende Ereignis und/oder die gleiche Beschreibung für das auslösende Ereignis eines durch das Öffnen des Entlastungsventils verursachten Lecks enthalten. Jede der Transaktionen kann auch Prozessparameterdaten enthalten, wie z. B. den Zeitpunkt der Öffnung, die Größe der Öffnung, den Druck im Überdruckventil, die Durchflussmenge des aus dem Entlastungsventil austretenden Fluids usw. Die Transaktionen können auch Produktparameterdaten, wie z. B. die Eigenschaften des Fluids, enthalten. Die Geräte, die die Transaktionen generieren, senden dann die Transaktionen an das Netzwerk des verteilten Ledgers, um Knoten zu validieren, wie z. B. Edge-Gateways, die die Gültigkeit der Transaktionen bestätigen und die Transaktionen in das verteilte Ledger aufnehmen.
Eine Regulierungsbehörde, die den Vorfall überprüft, kann Ereignisdaten aus dem verteilten Ledger anfordern und erhalten, die in Transaktionen mit der Kennung des auslösenden Ereignisses enthalten sind. Das Computergerät der Regulierungsbehörde, wie z. B. das in 2 gezeigte Computergerät 235, kann dann die Ereignisdaten auf einer Benutzerschnittstelle darstellen. In anderen Ausführungsformen enthält das verteilte Ledger kryptographische Hashes der Ereignisdaten, die dem Computergerät 235 der Regulierungsbehörde als Reaktion auf eine Anforderung zur Authentifizierung der Ereignisdaten zur Verfügung gestellt werden. Die Ereignisdaten werden aus anderen Datenquellen wie z. B. einer Datenbank gewonnen, die kommunikativ mit einem Servergerät 12 in der Prozessanlage 10 gekoppelt ist. Das Computergerät 235 der Regulierungsbehörde berechnet dann einen kryptographischen Hash der erhaltenen Ereignisdaten und vergleicht den kryptographischen Hash der erhaltenen Ereignisdaten mit dem kryptographischen Hash der Ereignisdaten aus dem verteilten Ledger. Wenn die kryptographischen Hashes gleich sind, stellt das Computergerät 235 der Regulierungsbehörde fest, dass die Ereignisdaten aus der Datenbank nicht manipuliert wurden. Andernfalls stellt das Computergerät 235 der Regulierungsbehörde fest, dass die Ereignisdaten aus der Datenbank unzuverlässig sind.
Transaktionen, die Daten der Prozessanlage aufzeichnen
Neben der Aufzeichnung von Prozessparameter- und Produktparameterdaten in Transaktionen, die sich auf ein auslösendes Ereignis beziehen, können Prozess- und Produktparameterdaten auch in Transaktionen eingebunden werden, die sich nicht auf ein auslösendes Ereignis beziehen, z. B. zur genauen Aufzeichnung der Vorgänge einer Prozessanlage 10. Andere Arten von Prozessanlagen-Daten können ebenfalls in Transaktionen enthalten sein, wie z. B. Konfigurationsdaten, Benutzerinteraktionsdaten, Wartungsdaten, Inbetriebnahmedaten, Anlagen-Netzwerkdaten, Produktverfolgungsdaten oder andere geeignete Daten, die in einer oder mehreren Prozessanlagen erzeugt werden oder sich auf diese beziehen. Zu den Benutzer-Interaktionsdaten können Operationen gehören, die von einem Betreiber oder einem Konfigurationstechniker z. B. an einem Betreiberarbeitsstation durchgeführt werden. Der Betreiber kann Sollwerte einstellen, auf Alarme reagieren, usw., über Bedienelemente am Betreiberarbeitsstation, die als Benutzer-Interaktionsdaten in Transaktionen eingebunden werden können. Auf diese Weise kann die Prozessanlage 10, wenn eine konkurrierende Einheit die Qualität eines in der Prozessanlage 10 hergestellten Produkts in Frage stellt, die Daten der Prozessanlage aus dem verteilten Ledger abrufen, die sich auf das Produkt beziehen. Die Prozessanlage 10 kann dann Aufzeichnungen über jede der an der Herstellung des Produkts beteiligten Prozessanlagen-Einheiten, Parameterwerte für die Prozessanlagen-Einheiten bei der Herstellung des Produkts, Parameterwerte für das Produkt auf verschiedenen Stufen des Herstellungsprozesses, auslösende Ereignisse, die während der Herstellung des Produkts aufgetreten sind, usw. überprüfen. Dementsprechend kann die Prozessanlage 10 feststellen, ob das Produkt ordnungsgemäß hergestellt wurde, um bestimmte Qualitätsstandards zu erfüllen, oder ob während der Produktion eine Anomalie aufgetreten ist, die dazu führt, dass das Produkt die Qualitätsstandards nicht erfüllt.
Die Prozessanlagen-Daten können auch zur Durchführung einer Ursachenanalyse von Produkten verwendet werden. Zum Beispiel können Produkte eine vorhergesagte Haltbarkeit haben, wie z. B. Benzin, das eine Halbwertszeit von weniger als einem Monat hat. In einigen Ausführungsformen kann ein Computergerät die Haltbarkeit eines Produkts anhand der Produkteigenschaften einschließlich der Prozessparameterdaten und der Produktparameterdaten, die während der Herstellung des Produkts im verteilten Ledger aufgezeichnet wurden, vorhersagen. Das Computergerät kann auch die Produkthaltbarkeit anhand von historischen Daten für ähnliche Produkte mit ähnlichen Komponenten und/oder Prozessparameterdaten und Produktparameterdaten während der Herstellung vorhersagen. Genauer gesagt kann das Computergerät die Produkthaltbarkeit anhand der durchschnittlichen Haltbarkeit desselben Produkttyps (z. B. Benzin) vorhersagen.
Das Computergerät kann dann die vorhergesagte Haltbarkeitsdauer gegenüber der durchschnittlichen Haltbarkeit auf der Basis der Qualität der Komponenten im Produkt erhöhen oder verringern. Beispielsweise können die Komponenten als überdurchschnittlich, durchschnittlich oder unterdurchschnittlich eingestuft werden. Die Angaben zu den Komponenten können in einer Datenbank mit zugehörigen Rangfolgen oder Qualitätsbewertungen gespeichert werden. Komponenten mit einer Qualitätsbewertung unter einem ersten Schwellenwert oder einem Rang unter einem ersten Schwellenwert können als unterdurchschnittlich eingestuft werden. Komponenten mit einer Qualitätsbewertung über einem ersten Schwellenwert und unter einem zweiten Schwellenwert oder mit einem Rang über dem ersten Schwellenwert und unter einem zweiten Schwellenwert können als durchschnittlich eingestuft werden. Komponenten mit einer Qualitätsbewertung über dem zweiten Schwellenwert oder mit einem Rang über dem zweiten Schwellenwert können als überdurchschnittlich eingestuft werden.
Das Computergerät kann die vorhergesagte Haltbarkeit weiter erhöhen oder verringern, und zwar abhängig von den Eigenschaften des Produkts, wie z. B. der Temperatur des Produkts, dem Volumen des Produkts, der Masse des Produkts, der Dichte des Produkts, dem Druck des Produkts, der Viskosität des Produkts, der chemischen Zusammensetzung des Produkts usw. Das Computergerät kann zum Beispiel jeder Eigenschaft eine Qualitätsbewertung zuweisen und die vorhergesagte Haltbarkeit auf der Grundlage jeder der Qualitätsbewertungen anpassen.
In einigen Ausführungsformen kann das Computergerät ein maschinelles Lernmodell generieren, um die Haltbarkeit eines Produkts auf der Grundlage der tatsächlichen Haltbarkeit früherer Produkte, der Komponenten in den früheren Produkten und der Eigenschaften der früheren Produkte vorherzusagen.
Wenn die tatsächliche Haltbarkeit eines Produkts von der vorhergesagten Haltbarkeit abweicht, kann das Computergerät darüber hinaus aus dem verteilten Ledger produktbezogene Daten der Prozessanlage abrufen, um die Ursache zu identifizieren. Zum Beispiel kann die tatsächliche Haltbarkeit aufgrund von qualitativ schlechten Komponenten im Produkt geringer sein als die prognostizierte Haltbarkeit. In einem anderen Beispiel kann die tatsächliche Haltbarkeit niedriger sein als die vorhergesagte Haltbarkeit, da ein Heizgerät in der Prozessanlage 10 das Produkt auf eine unerwünschte Temperatur erhitzt.
Transaktionen, die die Kontrollkette anhand von Produktverfolgungsdaten aufzeichnen
Um genaue Aufzeichnungen über die Kontrollkette von Produkten in einer Lieferkette bereitzustellen, können Transaktionen generiert werden, die Identifizierungsinformationen für die Quelle oder den Lieferanten eines Produkts und die mit dem Produkt befassten Stellen enthalten, wie z. B. Hersteller, Vertreiber, Vertriebseinrichtungen, Einzelhändler und den Kunden, der das Produkt kauft. Im Einzelnen können die Transaktionen Produktverfolgungsdaten mit Identifizierungsinformationen zum Produkt, Identifizierungsinformationen zum Lieferanten/Hersteller des Produkts, Identifizierungsinformationen zu den Herstellern/Anbietern der einzelnen Produktkomponenten, Identifizierungsinformationen zu den Stellen in der Lieferkette, die das Produkt empfangen und handhaben, Identifizierungsinformationen zu den Einzelhändlern, die das Produkt verkaufen, und/oder Identifizierungsinformationen zu den Kunden, die das Produkt kaufen, umfassen. Wenn das Produkt von einer Einheit (z. B. einer Prozessanlage) an eine andere Einheit (z. B. ein Lager) geliefert wird, kann die liefernde Einheit eine Transaktion generieren, die Identifizierungsinformationen zur liefernden Einheit, Identifizierungsinformationen zur empfangenden Einheit und einen Hinweis darauf, dass das Produkt an die empfangende Einheit übertragen wird, enthält.
Dementsprechend kann ein Benutzer, wie z. B. ein Kunde, über eine Benutzerschnittstelle jede der Transaktionen, die ein bestimmtes Produkt betreffen, aus dem verteilten Ledger anhand der Produkt-Identifizierungsinformationen abrufen. Das Benutzerschnittstellen-Gerät kann dann über eine Benutzerschnittstelle Angaben zum Lieferanten oder zur Quelle des Produkts sowie zu den Stellen anzeigen, die das Produkt gehandhabt haben, wie z. B. Hersteller, Vertreiber, Vertriebseinrichtungen, Einzelhändler und den Kunden, der das Produkt kauft. Das Benutzerschnittstellen-Gerät kann auch über die Benutzerschnittstelle Angaben zu den Komponenten des Produkts anzeigen. Der Benutzer kann dann jede der Transaktionen, die eine bestimmte Komponente des Produkts betreffen, mit Hilfe von Identifizierungsinformationen für die Komponente aus dem verteilten Ledger abrufen. Anschließend kann das Benutzerschnittstellen-Gerät über die Benutzerschnittstelle Angaben zum Lieferanten oder zur Quelle des Bauteils sowie zu den mit der Komponente befassten Stellen wie Hersteller, Vertreiber, Vertriebseinrichtungen usw. anzeigen.
In einigen Ausführungsformen kann die Produktverpackung eine Produktkennung enthalten, wie z. B. einen Barcode oder einen RFID-Tag (Funkfrequenz-Identifikation), der, wenn er gescannt wird, Daten aus dem verteilten Ledger zum Produkt liefert. Beispielsweise kann ein Benutzer den Barcode oder RFID-Tag über ein mobiles Gerät scannen, das dann Angaben zum Lieferanten oder zur Quelle des Produkts sowie zu den Stellen, die mit dem Produkt umgegangen sind, auf dem Mobilgerät anzeigt.
12 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren 1200 zur Datenerfassung in einem Prozesssteuerungssystem mit einem verteilten Ledger darstellt. Das Verfahren 1200 kann von einem Feldgerät 15-22, 40-46 in der Prozessanlage 10, einer Steuerung 11 in der Prozessanlage 10 oder einem anderen Computergerät in der Prozessanlage 10, wie z. B. einer Betreiberarbeitsstation, einem Server-Gerät 12, einem Benutzerschnittstellen-Gerät 8, einem E-/A-Gerät 26, 28, einem Netzwerk-Gerät 35, usw. ausgeführt werden.
Im Block 1202 werden Daten bezüglich eines Prozesssteuerungselements von einem Feldgerät erhalten. Das Prozesssteuerungselement kann ein Feldgerät, ein Regler oder eine Einheit der Prozessanlage wie ein Ventil, ein Tank, ein Mischer, eine Pumpe, ein Wärmetauscher usw. sein. Die Daten können Prozessanlagen-Daten umfassen, wie z. B. Prozessparameterdaten für Parameter des Prozessleitelements (z. B. ein Tankfüllstand, eine Pumpendrehzahl, die Temperatur in einem Wärmetauscher) und Produktparameterdaten für ein Produkt, das in das Prozesssteuerungselement eintritt, aus ihm austritt, in ihm enthalten ist und/oder von ihm gesteuert wird (z. B. die Temperatur eines Fluids in einem Tank, die Durchflussmenge des aus einem Ventil austretenden Fluids). Im Block 1204 wird dann eine Transaktion erzeugt, die die Daten der Prozessanlage in Bezug auf das Prozesssteuerungselement enthält. Die die Transaktion generierende Einheit (z. B. ein Feldgerät) signiert die Transaktion mit einer für die Einheit eindeutigen kryptographischen Signatur (Block 1206) und ergänzt die Transaktion mit Identitätsdaten der Einheit, wie z. B. einem öffentlichen kryptographischen Schlüssel, der der Einheit gehört (Block 1208). Beispielsweise kann die Transaktion mit einem privaten kryptographischen Schlüssel signiert werden, der dem öffentlichen kryptographischen Schlüssel entspricht, der der Einheit gehört.
Bei Block 1210 wird die Transaktion an einen Teilnehmer in dem verteilten Ledger-Netzwerk übertragen. Beispielsweise kann ein Feldgerät die Transaktion an das verteilte Ledger-Netzwerk senden. Ein Validierungsknoten, wie z. B. ein Edge-Gateway, kann anschließend die Gültigkeit der Transaktion bestätigen, die Transaktion zu einem Block von Transaktionen hinzufügen, ein kryptographisches Puzzle lösen und die Lösung in den neu generierten Block als Beweis für die geleistete Arbeit zur Generierung des Blocks aufnehmen. Der Validierungsknoten kann dann den neu generierten Block jedem der anderen Validierungsknoten im Netzwerk des verteilten Ledgers zur Verfügung stellen, um den neu generierten Block in ihre jeweiligen Kopien des verteilten Ledgers aufzunehmen.
In einigen Ausführungsformen bestätigt der Validierungsknoten die Transaktion gegen einen Satz von Konsens-Regeln und fügt die Transaktion zu einem Block hinzu, wenn die Transaktion jede der Konsens-Regeln erfüllt. Beispielsweise kann eine Konsens-Regel beinhalten, dass der Urheber einer Transaktion einen Identitätsnachweis liefert, sodass nur genehmigte Einheiten Transaktionen in das verteilte Ledger einbringen dürfen. Aufgrund einer Konsens-Regel kann es erforderlich sein, dass Blöcke und Transaktionen Formatvorgaben einhalten und bestimmte Meta-Informationen bezüglich der Transaktion liefern (z. B. Blöcke müssen unterhalb einer Größengrenze liegen, Transaktionen müssen eine Anzahl von Feldern enthalten, usw.). Jede Transaktion, die die Konsens-Regel nicht erfüllt, wird durch die Validierung der Knoten, die die Transaktion erhalten, ignoriert und die Transaktion wird nicht an andere Knoten weitergegeben.
Der Validierungsknoten enthält einen Sende-Empfänger zur Kommunikation mit Feldgeräten, Steuerungen oder anderen Computergeräten in der Prozessanlage 10, die die Transaktionen mit verteilten Ledger-Daten, wie z. B. Prozessanlagen-Daten, übertragen. Zusätzlich kann der Validierungsknoten einen Speicher zur Speicherung einer Kopie des verteilten Ledgers enthalten, einschließlich einer Status-Datenbank zur Speicherung der Zustände von intelligenten Verträgen, die auf dem verteilten Ledger bereitgestellt werden. Darüber hinaus kann der Validierungsknoten Anwendungen umfassen, z. B. einen Prozessdaten-Validierer, der einen Satz von Konsens-Regeln auf die verteilten Ledger-Daten anwendet und die verteilten Ledger-Daten an die Kopie des verteilten Ledgers des Validierungsknotens anhängt, wenn die verteilten Ledger-Daten die Konsens-Regeln erfüllen.
13 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren 1300 zur sicheren Erfassung nicht vertrauenswürdiger Daten in einem Prozesssteuerungssystem unter Verwendung eines verteilten Ledgers darstellt. Das Verfahren 1300 kann von einem Feldgerät 15-22, 40-46 in der Prozessanlage 10, einer Steuerung 11 in der Prozessanlage 10 oder einem anderen Computergerät in der Prozessanlage 10 wie z. B. einer Betreiberarbeitsstation, einem Servergerät 12, einem Benutzerschnittstellen-Gerät 8, einem E-/A-Gerät 26, 28, einem Netzwerkgerät 35 usw. ausgeführt werden. Das Verfahren 1300 kann auch von einem Validierungsknoten wie z. B. Edge-Gateway oder einer Kombination aus Feldgerät und Validierungsknoten ausgeführt werden.
Bei Block 1302 werden Daten bezüglich eines Prozesssteuerungselements von einem Feldgerät erhalten. Das Prozesssteuerungselement kann ein Feldgerät, ein Regler oder eine Einheit der Prozessanlage wie ein Ventil, ein Tank, ein Mischer, eine Pumpe, ein Wärmetauscher usw. sein. Die Daten können Prozessanlagen-Daten umfassen, wie z. B. Prozessparameterdaten für Parameter des Prozessleitelements (z. B. ein Tankfüllstand, eine Pumpendrehzahl, die Temperatur in einem Wärmetauscher) und Produktparameterdaten für ein Produkt, das in das Prozesssteuerungselement eintritt, aus ihm austritt, in ihm enthalten ist und/oder von ihm gesteuert wird (z. B. die Temperatur eines Fluids in einem Tank, die Durchflussmenge des aus einem Ventil austretenden Fluids). Anschließend wird bei Block 1304 eine Transaktion generiert, die die Prozessanlagen-Daten bezüglich des Prozesssteuerungselements enthält. Die Einheit, die die Transaktion generiert (z. B. ein Feldgerät), signiert die Transaktion mit einer für die Einheit eindeutigen kryptographischen Signatur und ergänzt die Transaktion mit Identitätsdaten für die Einheit, wie z. B. einem öffentlichen kryptographischen Schlüssel, der der Einheit gehört. Beispielsweise kann die Transaktion mit einem privaten kryptographischen Schlüssel signiert werden, der dem öffentlichen kryptographischen Schlüssel entspricht, der der Einheit gehört.
Bei Block 1306 wird die Transaktion an einen Teilnehmer in einem lokalen verteilten Ledger-Netzwerk übertragen. Es können mehrere lokal verteilte Ledger vorhanden sein, wobei jedes lokale verteilte Ledger von einem anderen Partner oder einer anderen Prozessanlage verwaltet wird. Beispielsweise kann ein lokales verteiltes Ledger-Netzwerk für Anlage A aus Edge-Gateways innerhalb von Anlage A bestehen. Die Edge-Gateways können Transaktionen aufzeichnen, die Prozessanlagen-Daten in Bezug auf Ereignisse und Geräte innerhalb von Anlage A enthalten. Die Transaktionen werden dann für einen Schwellenwertzeitraum oder eine Schwellenwert-Epoche in das lokale verteilte Ledger-Netzwerk eingefügt. Nach Ablauf des Schwellenwertzeitraums (Block 1308) stellen die Validierungsknoten, die das lokale verteilte Ledger verwalten, die Transaktionen oder Blöcke von Transaktionen, die während des Schwellenwertzeitraums generiert wurden, einem globalen verteilten Ledger-Netzwerk zur Verfügung (Block 1310). Das globale verteilte Ledger-Netzwerk kann die Validierung von Knoten über mehrere Prozessanlagen hinweg beinhalten, wie z. B. ein Cloud-Service mit mehreren Cloud-Computing-Systemen. Die Validierungsknoten können für jede Prozessanlage ein globales verteiltes Ledger (z. B. eine globale Blockchain) führen. Dann können die Validierungsknoten im lokalen verteilten Ledger-Netzwerk Blöcke aus dem lokalen verteilten Ledger entfernen oder löschen, die dem globalen verteilten Ledger mit Ausnahme des letzten Blocks zur Verfügung gestellt wurden. Die Validierungsknoten für das lokale verteilte Ledger können weiterhin Blöcke generieren, die Blöcke nach jedem Ablauf der Epoche an das Netzwerk des globalen verteilten Ledgers senden und lokale Kopien der Blöcke entfernen, wenn die Blöcke zu der globalen Blockchain hinzugefügt wurden.
Ebenso werden in einigen Ausführungsformen die globalen Blockchains für die jeweiligen Stellen oder Prozessanlagen zu einer Super-Blockchain mit Status-Blöcken zusammengefasst. Jeder Status-Block umfasst jeden der Blöcke aus den globalen Blockchains, die einem bestimmten Zeitraum oder einer bestimmten Epoche entsprechen.
14 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren 1400 zur Erfassung von Qualitäts-, Produktions- oder Regulierungsdaten in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers darstellt. Das Verfahren 1400 kann von einem Feldgerät 15-22, 40-46 in der Prozessanlage 10, einer Steuerung 11 in der Prozessanlage 10 oder einem anderen Computergerät in der Prozessanlage 10 wie z. B. einer Betreiberarbeitsstation, einem Servergerät 12, einem Benutzerschnittstellen-Gerät 8, einem E-/A-Gerät 26, 28, einem Netzwerkgerät 35 usw. ausgeführt werden.
Bei Block 1402 wird ein auslösendes Ereignis in Bezug auf die Qualitätskontrolle durch ein Prozesssteuerungselement erkannt. Das auslösende Ereignis kann ein Alarm, ein Fehler, ein Leck, ein Reparaturvorgang, ein Prozessmeilenstein, eine Korrekturmaßnahme usw. sein. In einigen Ausführungsformen wird das auslösende Ereignis einem Feldgerät, einer Steuerung oder einem anderen Computergerät innerhalb der Prozessanlage angezeigt 10. In anderen Ausführungsformen erkennt das Feldgerät, die Steuerung oder ein anderes Computergerät das auslösende Ereignis.
In jedem Fall werden bei Block 1404 Ereignisdaten für das auslösende Ereignis erhalten. Die Ereignisdaten können eine eindeutige Kennung für das auslösende Ereignis, einen Zeitpunkt des auslösenden Ereignisses, eine Dauer des auslösenden Ereignisses, eine Beschreibung des auslösenden Ereignisses, Identifizierungsinformationen für die am auslösenden Ereignis beteiligten Prozesssteuerungselemente, Identifizierungsinformationen für ein Produkt, das von den Prozesssteuerungselementen während des auslösenden Ereignisses hergestellt wird, usw. umfassen. Anschließend wird im Block 1406 eine Transaktion generiert, die die Ereignisdaten und/oder einen kryptographischen Hash der Ereignisdaten für das auslösende Ereignis enthält. Die Transaktion kann auch Identifizierungsinformationen für den Urheber der Transaktion, Produktparameterdaten für das Produkt bei Eintritt des auslösenden Ereignisses, Prozessparameterdaten für Prozesssteuerungselemente während des auslösenden Ereignisses oder jede andere geeignete Information enthalten. In einigen Ausführungsformen können mehrere Feldgeräte, Steuerungen oder andere Computergeräte innerhalb der Prozessanlage 10 Transaktionen generieren, die sich auf das auslösende Ereignis beziehen. Beispielsweise kann ein erstes Feldgerät eine Transaktion generieren, die die Temperatur in einem Heizgerät zum Zeitpunkt des auslösenden Ereignisses berücksichtigt, während ein zweites Feldgerät eine Transaktion generieren kann, die die Geschwindigkeit einer Pumpe zum Zeitpunkt des auslösenden Ereignisses berücksichtigt.
Bei Block 1408 wird die Transaktion an einen Teilnehmer in dem verteilten Ledger-Netzwerk übertragen. Beispielsweise kann ein Feldgerät die Transaktion an das verteilte Ledger-Netzwerk senden. Ein Validierungsknoten, wie z. B. ein Edge-Gateway, kann anschließend die Gültigkeit der Transaktion bestätigen, die Transaktion zu einem Block von Transaktionen hinzufügen, ein kryptographisches Puzzle lösen und die Lösung in den neu generierten Block als Beweis für die geleistete Arbeit zur Generierung des Blocks aufnehmen. Der Validierungsknoten kann dann den neu generierten Block jedem der anderen Validierungsknoten im Netzwerk des verteilten Ledgers zur Verfügung stellen, um den neu generierten Block in ihre jeweiligen Kopien des verteilten Ledgers aufzunehmen.
Wie oben beschrieben, kann die Transaktion einen kryptographischen Hash der Ereignisdaten für das auslösende Ereignis und/oder eine Kombination aus den Ereignisdaten für das auslösende Ereignis und anderen Prozessanlagen-Daten, die sich auf das auslösende Ereignis beziehen, enthalten. Zusätzlich zur Generierung der Transaktion kann das Feldgerät die Ereignisdaten oder andere Daten der Prozessanlage, die sich auf das auslösende Ereignis beziehen, einem Server-Gerät 12 zur Verfügung stellen, um sie z. B. in einer Datenbank zu speichern (Block 1410).
Anschließend werden zur Authentifizierung der Ereignisdaten die in der Datenbank gespeicherten Ereignisdaten mit dem kryptographischen Hash verglichen, der im verteilten Ledger (Block 1412) enthalten ist. Wenn eine Übereinstimmung vorliegt, wurden die Ereignisdaten nicht manipuliert. Beispielsweise kann eine Regulierungsbehörde, die einen Vorfall überprüft, kryptografische Hashes von Ereignisdaten aus dem verteilten Ledger anfordern und erhalten, die in Transaktionen mit der Kennung des auslösenden Ereignisses enthalten sind. Die Ereignisdaten werden aus anderen Datenquellen wie z. B. einer Datenbank gewonnen, die kommunikativ mit einem Servergerät 12 in der Prozessanlage 10 gekoppelt ist. Das Computergerät der Regulierungsbehörde berechnet dann einen kryptographischen Hash der erhaltenen Ereignisdaten und vergleicht den kryptographischen Hash der erhaltenen Ereignisdaten mit dem kryptographischen Hash der Ereignisdaten aus dem verteilten Ledger. Wenn die kryptographischen Hashes gleich sind, stellt das Computergerät der Regulierungsbehörde fest, dass die Ereignisdaten aus der Datenbank nicht manipuliert wurden. Andernfalls stellt das Computergerät der Regulierungsbehörde fest, dass die Ereignisdaten aus der Datenbank unzuverlässig sind. In anderen Ausführungsformen ruft ein Computergerät innerhalb der Prozessanlage 10 die in der Datenbank gespeicherten Ereignisdaten und den kryptografischen Hash der Ereignisdaten aus dem verteilten Ledger ab und vergleicht die Ereignisdaten mit dem kryptografischen Hash, um die Ereignisdaten zu authentifizieren.
15 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren 1500 zur Erfassung der Zustände von Software oder Firmware in einem Prozesssteuerungssystem und der angeschlossenen Instrumentierung mit Hilfe eines verteilten Ledgers darstellt. Das Verfahren 1500 kann von einem Feldgerät 15-22, 40-46 in der Prozessanlage 10, einer Steuerung 11 in der Prozessanlage 10 oder einem anderen Computergerät in der Prozessanlage 10, wie z. B. einer Betreiberarbeitsstation, einem Server-Gerät 12, einem Benutzerschnittstellen-Gerät 8, einem E-/A-Gerät 26, 28, einem Netzwerk-Gerät 35, usw. ausgeführt werden.
Bei Block 1502 wird ein aktueller Stand von Software oder Firmware, die auf einem Gerät in der Prozessanlage 10 ausgeführt wird, abgefragt. Beispielsweise kann ein Gerät innerhalb der Prozessanlage 10, bei dem ein Software- oder Firmware-Upgrade durchgeführt wird, die neue Software- oder Firmware-Version erhalten. Das Gerät kann eine Betreiberarbeitsstation, ein anderes Benutzerschnittstellen-Gerät 8, ein Servergerät 12, eine Steuerung 11, ein E-/A-Gerät 26, 28, ein Netzwerk-Gerät 35, ein Feldgerät 15-22, 40-46, usw. sein. Dann kann das Gerät im Block 1504 eine Transaktion generieren, die einen Hinweis auf den aktuellen Zustand der Software oder Firmware enthält. Die Angabe kann z. B. ein kryptographischer Hash der Software-Befehle für die neue Version der Software sein. Die Transaktion kann auch einen Urheber umfassen, der die durch einen kryptographischen Identitätsnachweis identifizierte Software oder Firmware ändert, sowie Identifizierungsinformationen für das Gerät, das die Software oder Firmware ausführt, eine Beschreibung des Upgrades, Uhrzeit und Datum des Upgrades usw.
Bei Block 1506 wird die Transaktion an einen Teilnehmer im verteilten Ledger-Netzwerk übertragen. Beispielsweise kann ein Computergerät die Transaktion an das verteilte Ledger-Netzwerk senden. Ein Validierungsknoten, wie z. B. ein Edge-Gateway, kann anschließend die Gültigkeit der Transaktion bestätigen, die Transaktion zu einem Block von Transaktionen hinzufügen, ein kryptographisches Puzzle lösen und die Lösung in den neu generierten Block als Beweis für die geleistete Arbeit zur Generierung des Blocks aufnehmen. Der Validierungsknoten kann dann den neu generierten Block jedem der anderen Validierungsknoten im Netzwerk des verteilten Ledgers zur Verfügung stellen, um den neu generierten Block in ihre jeweiligen Kopien des verteilten Ledgers aufzunehmen.
In einigen Ausführungsformen bestätigt der Validierungsknoten die Transaktion gegen einen Satz von Konsens-Regeln und fügt die Transaktion zu einem Block hinzu, wenn die Transaktion jede der Konsens-Regeln erfüllt. Auch in einigen Ausführungsformen deuten die Konsens-Regeln daraufhin, dass nur autorisierte Benutzer Software- oder Firmware-Updates auf dem verteilten Ledger aufzeichnen dürfen. Dementsprechend validieren die Validierungsknoten bei der Übertragung der Transaktion in das verteilte Ledger die Transaktion, wenn der Urheber ein autorisierter Benutzer ist. Wenn der Urheber kein autorisierter Benutzer ist, wird die Transaktion nicht in das verteilte Ledger aufgenommen und die Aktualisierung der Software stimmt nicht mit der neuesten Version der im verteilten Ledger gespeicherten Software überein.
In jedem Fall wird bei Block 1508 ein Status der auf dem Gerät in der Prozessanlage 10 laufenden Software oder Firmware erhalten. Beispielsweise kann ein Server-Gerät 12 oder ein anderes Computergerät innerhalb der Prozessanlage 10 kontinuierlich oder periodisch (z. B. einmal pro Sekunde, einmal pro Minute, einmal pro Stunde, einmal pro Tag usw.) aktuelle Versionen von Software und Firmware, die in Geräten in der Prozessanlage 10 laufen, abrufen. Der Status der am Servergerät 12 abgerufenen Software oder Firmware wird dann mit dem kryptographischen Hash-Wert für die im verteilten Ledger gespeicherte Software oder Firmware verglichen, um zu überprüfen, ob die Software oder Firmware nicht manipuliert wurde (Block 1510). Stimmt der Status der Software oder Firmware mit dem kryptographischen Hash-Wert für die im verteilten Ledger gespeicherte Software oder Firmware überein, wird die Software oder Firmware auf dem Gerät weiter ausgeführt (Block 1514). Andernfalls stellt das Servergerät 12 fest, dass die Software manipuliert wurde und verhindert, dass das Gerät die Software in ihrem aktuellen Status ausführt (Block 1512). In einigen Ausführungsformen lädt das Servergerät 12 dann den vorherigen Software-Status auf das Gerät herunter, und das Gerät setzt die Ausführung der Software in ihrem vorherigen Status fort.
16 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren 1600 zur Erstellung von intelligenten Verträgen in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers darstellt. Das Verfahren 1600 kann von einem Feldgerät 15-22, 40-46 in der Prozessanlage 10, einer Steuerung 11 in der Prozessanlage 10 oder einem anderen Computergerät in der Prozessanlage 10, wie z. B. einer Betreiberarbeitsstation, einem Servergerät 12, einem Benutzerschnittstellen-Gerät 8, einem E-/A-Gerät 26, 28, einem Netzwerkgerät 35, usw. ausgeführt werden.
Bei Block 1602 wird ein intelligenter Vertrag generiert, der sich auf eine oder mehrere Prozessanlagen bezieht. Beispielsweise kann der intelligente Vertrag einen Token-Wert von Anlage A auf Anlage B übertragen, wenn Anlage A von Anlage B ein Produkt erhält, das bestimmte Qualitätsstandards erfüllt. Ein weiteres Beispiel für einen intelligenten Vertrag in einem Prozesssteuerungssystem kann ein intelligenter Vertrag für eine sichere Schreibanforderung sein, wodurch es dem Anlagenpersonal erlaubt wird, Parameterdaten in ein SIS-Gerät in der Prozessanlage 10 zu schreiben. Ein weiteres Beispiel für einen intelligenten Vertrag in einem Prozesssteuerungssystem könnte ein intelligenter Vertrag für Geräteinformationen sein, der Geräteinformationen von einem fehlerhaften Gerät erhält und die Geräteinformationen einem Gerätelieferanten als Reaktion auf den Erhalt einer Anforderung zur Weitergabe der Geräteinformationen zur Verfügung stellt.
Bei Block 1604 wird der intelligente Vertrag an einer Adresse, die im verteilten Ledger gespeichert ist, bereitgestellt. Der bereitgestellte intelligente Vertrag kann Verfahren und Daten für andere Teilnehmer im verteilten Ledger-Netzwerk zur Verfügung stellen. Einige der Daten im Status des intelligenten Vertrags können private Daten sein, die nur durch den Aufruf eines Verfahrens des intelligenten Vertrags oder nur durch autorisierte Teilnehmer des verteilten Ledgers geändert werden dürfen. Eine Möglichkeit, den Status des intelligenten Vertrags zu ändern, ist die Übertragung einer Transaktion in das verteilte Ledger-Netzwerk. Wenn die übertragene Transaktion den Konsens-Regeln entspricht, können Netzwerk-Validierer die Transaktion in das verteilte Ledger aufnehmen.
In einigen Ausführungsformen führen Validierungsknoten wie Edge-Gateways den im intelligenten Vertrag enthaltenen Code aus, und Feldgeräte fungieren als Beweis-Orakel und liefern Beweis-Transaktionen, die den Status des intelligenten Vertrags ändern.
17 zeigt ein Flussdiagramm, das ein beispielhaftes Verfahren 1700 für die Interaktion mit einem intelligenten Vertrag in einem Prozessleitsystem mit Hilfe eines verteilten Ledgers darstellt. Das Verfahren 1700 kann von einem Feldgerät 15-22, 40-46 in der Prozessanlage 10, einer Steuerung 11 in der Prozessanlage 10 oder einem anderen Computergerät in der Prozessanlage 10 wie z. B. einer Betreiberarbeitsstation, einem Server-Gerät 12, einem Benutzerschnittstellen-Gerät 8, einem E-/A-Gerät 26, 28, einem Netzwerk-Gerät 35 usw. ausgeführt werden.
Bei Block 1702 werden Ereignisdaten von einem Ereignis erhalten, das in der Prozessanlage 10 auftritt. Ein Ereignis kann ein Produkt sein, das von einer Prozessanlage 10 geliefert oder in dieser empfangen wird, die Fertigstellung eines Produkts, das in der Prozessanlage 10 hergestellt wird, eine Änderung der Eigenschaften eines Produkts, eine Änderung eines Prozessparameterwerts, ein auslösendes Ereignis wie ein Alarm, ein Fehler, ein Leck, ein Reparaturereignis, eine Korrekturmaßnahme, eine Benutzerinteraktion wie eine Anforderung zum Schreiben in ein SIS-Gerät, eine Anforderung zur Bereitstellung von Geräteinformationen an einen Gerätelieferanten oder eine Anforderung zur Übertragung eines symbolischen Werts beim Empfang eines bestimmten Produkts oder jedes andere geeignete Ereignis, das in der Prozessanlage 10 auftritt. Die Ereignisdaten können Prozessparameterdaten, Produktparameterdaten, Konfigurationsdaten, Benutzerinteraktionsdaten, Wartungsdaten, Inbetriebnahmedaten, Anlagennetzwerkdaten, Produktverfolgungsdaten oder andere geeignete Daten im Zusammenhang mit dem Ereignis, wie z. B. Datum und Uhrzeit des Ereignisses, die Dauer des Ereignisses, eine Beschreibung des Ereignisses usw. umfassen.
Dann wird im Block 1704 eine Transaktion generiert, die die Ereignisdaten und Identifizierungsinformationen für die die Transaktion generierende Einheit enthält, wie z. B. einen kryptographischen öffentlichen Schlüssel, der der Einheit zugeordnet ist. Die Transaktion kann kryptographisch signiert werden, um einen kryptographischen Identitätsnachweis der die Transaktion generierenden Einheit zu erbringen. Bei Block 1706 wird der Vorgang an die Adresse des verteilten Ledgers übermittelt, an der der intelligente Vertrag eingesetzt wird. Auf diese Weise ändern Validierungsknoten wie z. B. Edge-Gateways den Status des intelligenten Vertrags entsprechend der in der Transaktion enthaltenen Ereignisdaten.
Beispielsweise kann ein intelligenter Vertrag einen Token-Wert von Anlage A auf Anlage B übertragen, wenn Anlage A von Anlage B ein Produkt erhält, das bestimmte Qualitätsstandards erfüllt. Ein Feldgerät in Anlage A kann eine Transaktion mit Ereignisdaten generieren, die sich auf die Qualität des Produkts beziehen, wie z. B. eine Identifizierungsinformation für Anlage A, eine Identifizierungsinformation für das Produkt, einen Hinweis, dass das Produkt von Anlage B empfangen wurde, und Produktparameterdaten, die Eigenschaften des Produkts beschreiben (z. B. die Temperatur des Produkts, das Volumen des Produkts, die Dichte des Produkts, die Viskosität des Produkts oder die chemische Zusammensetzung des Produkts). Das Feldgerät kann die Transaktion an die Adresse für den intelligenten Vertrag liefern, und die Validierungsknoten können den Status des intelligenten Vertrags so ändern, dass er die Produktparameterdaten enthält. In einigen Ausführungsformen vergleicht der intelligente Vertrag die in den Produktparameterdaten enthaltenen Eigenschaften des Produkts mit einer Reihe von Mindestschwellenanforderungen, damit das Produkt die entsprechenden Qualitätsstandards erfüllt. Wenn das Produkt die Qualitätsstandards erfüllt, kann der intelligente Vertrag den Token-Wert an Anlage B übertragen. In einigen Ausführungsformen kann ein Feldgerät in Anlage B eine Transaktion mit Ereignisdaten generieren, die sich auf die Qualität des Produkts beziehen, wie z. B. Prozessparameterdaten, die Parameterwerte für an der Herstellung des Produkts beteiligte Anlageneinheiten in Anlage B beschreiben, wobei die Parameterwerte während der Herstellung des Produkts erfasst werden.
Die Ausführungsformen der in der vorliegenden Offenbarung beschriebenen Techniken können eine beliebige Anzahl der folgenden Aspekte - entweder allein oder in Kombination - enthalten:

1. Ein validierender Netzwerkknoten in einer Prozessanlage in einem verteilten Ledger-Netzwerk, bestehend aus: einem Transceiver, der so konfiguriert ist, dass er mit einem oder mehreren Feldgeräten kommuniziert, die jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses in der Prozessanlage und zum Austausch von verteilten Ledger-Daten mit Peer-Netzwerkknoten ausführen, wobei die verteilten Ledger-Daten Transaktionen mit Prozessanlagendaten enthalten; einem Speichermedium, das so konfiguriert ist, dass es eine Kopie des verteilten Ledgers speichert; und einen Prozessdaten-Validierer, der so konfiguriert ist, dass er einen Satz von Konsens-Regeln auf die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers anwendet, wobei der Prozessdaten-Validierer ferner so konfiguriert ist, dass er die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers an die Kopie des verteilten Ledgers anhängt, wenn die Daten des verteilten Ledgers die Konsens-Regeln erfüllen.
2. Der validierende Netzwerkknoten gemäß Aspekt 1, wobei die von den Peer-Knoten empfangenen verteilten Ledger-Daten einen Identitätsnachweis einer Einheit enthalten, die eine Transaktion mit Prozessanlagen-Daten generiert.
3. Der validierende Netzwerkknoten gemäß einem der vorhergehenden Aspekte, wobei der Transaktions-Validierer zum Anhängen der von den Peer-Knoten empfangenen Daten des verteilten Ledgers so konfiguriert ist, dass er: ein kryptographisches Puzzle auf der Grundlage eines Blocks von Transaktionen löst; die Lösung des kryptographischen Puzzles dem Block von Transaktionen hinzufügt; den Block von Transaktionen an die Kopie des verteilten Ledgers anhängt; und den Block von Transaktionen an mindestens einen der Peer-Netzwerkknoten im Netzwerk des verteilten Ledgers überträgt.
4. Der validierende Netzwerkknoten gemäß einem der vorhergehenden Aspekte, wobei der Satz von Konsens-Regeln mindestens eines der Folgenden umfasst: Formatierungsanforderungen für Transaktionen oder für Blöcke von Transaktionen; einen Mechanismus zur Bestimmung, welcher der Peer-Netzwerkknoten eine nächste Transaktion oder einen nächsten Block von Transaktionen zum verteilten Ledger hinzufügt; oder einen kryptographischen Hash-Algorithmus zum Hashing der in jeder der Transaktionen enthaltenen Prozessanlagen-Daten.
5. Der validierende Netzwerkknoten gemäß einem der vorhergehenden Aspekte, wobei der Prozessdaten-Validierer weiter konfiguriert ist, um den Code in intelligenten Verträgen auszuführen und die Status-Datenbanken für die intelligenten Verträge zu aktualisieren.
6. Der validierende Netzwerkknoten gemäß einem der vorhergehenden Aspekte, wobei der Prozessdaten-Validierer ferner so konfiguriert ist, dass er die von den Peer-Netzwerkknoten empfangenen verteilten Ledger-Daten nicht berücksichtigt, wenn die verteilten Ledger-Daten nicht den Konsens-Regeln entsprechen.
7. Der validierende Netzwerkknoten nach einem der vorhergehenden Aspekte, wobei der validierende Netzwerkknoten und die Peer-Netzwerkknoten Geräte innerhalb derselben Prozessanlage sind.
8. Der validierende Netzwerkknoten nach einem der vorhergehenden Aspekte, wobei der validierende Netzwerkknoten und die Peer-Netzwerkknoten Geräte innerhalb mehrerer Prozessanlagen sind.
9. Verfahren zum Aufzeichnen von Daten in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Erhalten von Prozessanlagen-Daten, die sich auf ein Prozesssteuerungselement in einer Prozessanlage beziehen, durch ein Computergerät; Generieren einer Transaktion, die die Prozessanlagen-Daten enthält, wobei die Transaktion in dem verteilten Ledger gespeichert wird; und Übertragen der Transaktion an mindestens einen anderen Teilnehmer in einem verteilten Ledger-Netzwerk von Teilnehmern, die das verteilte Ledger verwalten.
10. Das Verfahren gemäß Aspekt 9, wobei die Generierung der Transaktion Folgendes umfasst: Generieren einer kryptographischen Signatur basierend auf der Transaktion; und Erweitern der Transaktion mit der kryptographischen Signatur.
11. Das Verfahren gemäß entweder Aspekt 9 oder Aspekt 10, wobei die Daten von einem Feldgerät innerhalb der Prozessanlage erhalten werden und die Generierung der Transaktion weiterhin Folgendes umfasst: Erhalten von Identitätsdaten für das Feldgerät; und Erweitern der Transaktion mit den Identitätsdaten.
12. Das Verfahren gemäß einem der Aspekte 9-11, weiterhin umfassend: Hinzufügen der Transaktion zu einem Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; und Übertragen des Blocks von Transaktionen an mindestens einen anderen Teilnehmer in dem verteilten Ledger-Netzwerk.
13. Das Verfahren gemäß einem der Aspekte 9-12, wobei die Daten Produktverfolgungsdaten sind und die Generierung einer Transaktion die Generierung einer Transaktion beinhaltet, die anzeigt, dass ein Produkt von einer Prozessanlage zu einer anderen Einheit transferiert wurde.
14. Das Verfahren gemäß einem der Aspekte 9-13, wobei die Daten Produktparameterdaten sind, die mindestens eines der folgenden enthalten: eine Temperatur eines Produkts, ein Volumen des Produkts oder eine chemische Zusammensetzung des Produkts, und wobei die Produktparameterdaten in dem verteilten Ledger gespeichert werden, um die Authentizität der Parameterdaten für das Produkt zu verifizieren, wenn das Produkt einer anderen Einheit zur Verfügung gestellt wird.
15. Das Verfahren gemäß einem der Aspekte 9-14, wobei das Netzwerk des verteilten Ledgers mehrere Schichten umfasst, und weiterhin Folgendes umfasst: in einem ersten Fall die Generierung einer Transaktion, die in einer ersten Schicht des verteilten Ledgers gespeichert werden soll; und in einem zweiten Fall die Generierung einer Transaktion, die in einer zweiten Schicht des verteilten Ledgers gespeichert werden soll.
16. Das Verfahren nach einem der Aspekte 9-15, wobei die erste Schicht des verteilten Ledgers öffentlich und die zweite Schicht der verteilten Schicht privat ist.
17. Das Verfahren gemäß einem der Aspekte 9-16, wobei das verteilte Ledger mindestens eines der Folgenden ist: eine Blockchain, ein Gewirr, ein Blockgitter oder ein anderer gerichteter azyklischer Graph.
18. Das Verfahren gemäß einem der Aspekte 9-17, wobei die Prozessanlagen-Daten mindestens einen der folgenden Aspekte umfassen: Produktparameterdaten, Konfigurationsdaten, Produktverfolgungsdaten oder Prozessparameterdaten.
19. Das Verfahren gemäß einem der Aspekte 9-18, wobei die Generierung einer Transaktion die Generierung einer Transaktion einschließt, die einen kryptographischen Hash-Wert enthält, der den Daten der Prozessanlage entspricht.
20. System zum Aufzeichnen von Daten in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, und Folgendes umfassend: eines oder mehrere Geräte, die in einer Prozessanlage angeordnet sind und jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses ausführen; und ein in der Prozessanlage ausführendes Computergerät, das Folgendes umfasst: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit verbunden ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Computergerät zu Folgendem veranlassen: Prozessanlagendaten zu erhalten, die sich auf das eine oder die mehreren Geräte innerhalb der Prozessanlage beziehen; eine Transaktion zu generieren, die die Prozessanlagendaten enthält; und die Transaktion an mindestens einen anderen Teilnehmer in einem verteilten Ledger-Netzwerk von Teilnehmern zu übertragen, die das verteilte Ledger zur Validierung und Aufzeichnung der Transaktion in dem verteilten Ledger verwalten.
21. Das System gemäß Aspekt 20, wobei zur Generierung der Transaktion die Befehle das Computergerät zu Folgendem veranlassen: Erzeugen einer kryptographischen Signatur basierend auf der Transaktion; und Erweitern der Transaktion mit der kryptographischen Signatur.
22. Das System entsprechend entweder Aspekt 20 oder Aspekt 21, wobei die Daten von einem Feldgerät innerhalb der Prozessanlage erhalten werden, und um die Transaktion zu generieren, veranlassen die Befehle das Computergerät zu Folgendem: Erhalten von Identitätsdaten für das Feldgerät; und Erweitern der Transaktion mit den Identitätsdaten.
23. Das System gemäß einem der Aspekte 20-22, wobei die Befehle weiterhin das Computergerät zum Folgenden veranlassen: Hinzufügen der Transaktion zu einem Block von Transaktionen; Lösen eines kryptographischen Puzzles auf der Grundlage des Blocks von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; und Übertragen des Blocks von Transaktionen an mindestens einen anderen Teilnehmer in dem verteilten Ledger-Netzwerk.
24. Das System gemäß einem der Aspekte 20-23, wobei das Netzwerk des verteilten Ledgers mehrere Schichten umfasst und die Befehle ferner bewirken, dass das Computergerät: in einem ersten Fall eine Transaktion generiert, die in einer ersten Schicht des verteilten Ledgers gespeichert werden soll; und in einem zweiten Fall eine Transaktion generiert, die in einer zweiten Schicht des verteilten Ledgers gespeichert werden soll.
25. Das System nach einem der Aspekte 20-24, wobei die erste Schicht des verteilten Ledgers eine öffentliche Blockchain und die zweite Schicht der verteilten Schicht eine private Blockchain ist.
26. Das System gemäß einem der Aspekte 20-25, wobei das verteilte Ledger mindestens eines der Folgenden ist: eine Blockchain, ein Gewirr, ein Blockgitter oder ein anderer gerichteter azyklischer Graph.
27. Das System gemäß einem der Aspekte 20-26, wobei die Daten der Prozessanlage mindestens einen der folgenden Aspekte umfassen: Produktparameterdaten, Konfigurationsdaten, Produktverfolgungsdaten oder Prozessparameterdaten.
28. Das System gemäß einem der Aspekte 20-27, wobei die Generierung einer Transaktion die Generierung einer Transaktion einschließlich eines kryptographischen Hash-Wertes beinhaltet, der den Daten der Prozessanlage entspricht.
29. Ein nichtflüchtiger, computerlesbarer Speicher, der mit einem oder mehreren Prozessoren gekoppelt ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Empfangen von Transaktionen, die Prozessanlagendaten enthalten, die von einem oder mehreren Feldgeräten generiert werden, die jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses in einer Prozessanlage ausführen; Speichern einer Kopie eines verteilten Ledgers; Anwenden eines Satzes von Konsens-Regeln auf die empfangenen Transaktionen; Anhängen einer der empfangenen Transaktionen an die Kopie des verteilten Ledgers, wenn die empfangene Transaktion die Konsens-Regeln erfüllt; und Übertragen der angehängten Transaktion an mindestens einen Peer-Netzwerkknoten, der eine Kopie des verteilten Ledgers speichert.
30. Der computerlesbare Speicher gemäß Aspekt 29, wobei die empfangene Transaktion einen Identitätsnachweis einer die Transaktion generierenden Einheit enthält.
31. Der computerlesbare Speicher gemäß entweder Aspekt 29 oder Aspekt 30, wobei zum Anhängen einer der empfangenen Transaktionen die Befehle den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Lösen eines kryptographischen Puzzles auf der Basis eines Blocks von Transaktionen, der die empfangene Transaktion enthält; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; Anhängen des Blocks von Transaktionen an die Kopie des verteilten Ledgers; und Übertragen des Blocks von Transaktionen an den Peer-Netzwerkknoten.
32. Der computerlesbare Speicher gemäß einem der Aspekte 29-31, wobei der Satz von Konsens-Regeln mindestens eines der Folgenden umfasst: Formatierungsanforderungen für Transaktionen oder Blöcke von Transaktionen; einen Mechanismus, um zu bestimmen, welcher der Peer-Netzwerkknoten eine nächste Transaktion oder einen nächsten Block von Transaktionen zu dem verteilten Ledger hinzufügt; oder einen kryptographischen Hash-Algorithmus zum Hashing der in jeder der Transaktionen enthaltenen Prozessanlagen-Daten.
33. Der computerlesbare Speicher gemäß einem der Aspekte 29-32, wobei die Befehle weiterhin den einen oder mehrere Prozessoren veranlassen, die von den Peer-Netzwerkknoten empfangenen verteilten Ledger-Daten zu ignorieren, wenn die verteilten Ledger-Daten nicht den Konsens-Regeln entsprechen.
34. Der computerlesbare Speicher nach einem der Aspekte 29-33, wobei die Peer-Netzknoten Geräte innerhalb einer gleichen Prozessanlage sind.
35. Der computerlesbare Speicher nach einem der Aspekte 29-34, wobei die Peer-Netzwerkknoten Geräte innerhalb mehrerer Prozessanlagen sind.
36. Verfahren zum sicheren Messen von nicht vertrauenswürdigen Daten in Prozesssteuerungssystemen mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Erfassen einer Messung eines Parameters innerhalb der Prozessanlage durch ein Feldgerät, das eine physische Funktion zur Steuerung eines industriellen Prozesses in einer Prozessanlage ausführt; Erhalten der Messung des Parameters durch ein Computergerät; Generieren einer Transaktion, die die Messung enthält; und Übertragen der Transaktion an mindestens einen anderen Teilnehmer in einem lokalen verteilten Ledger-Netzwerk von Teilnehmern, die ein lokales verteiltes Ledger verwalten; Übertragen mehrerer Transaktionen, die während des Schwellenwertzeitraums erzeugt wurden, nach einem Schwellenwertzeitraum an mindestens einen Teilnehmer in einem globalen verteilten Ledger-Netzwerk von Teilnehmern, die ein globales verteiltes Ledger verwalten.
37. Das Verfahren gemäß Aspekt 36, weiterhin Folgendes umfassend: Hinzufügen der Transaktion zu einem lokalen Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem lokalen Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem lokalen Block von Transaktionen; und Übertragen des lokalen Blocks von Transaktionen an mindestens einen anderen Teilnehmer in dem lokalen verteilten Ledger-Netzwerk.
38. Das Verfahren gemäß einem der Aspekte 36 oder 37, das ferner Folgendes umfasst: nach dem Schwellenwertzeitraum Übertragung eines oder mehrerer lokaler Blöcke von Transaktionen, die während des Schwellenwertzeitraums generiert wurden, an mindestens einen Teilnehmer im globalen verteilten Ledger-Netzwerk.
39. Das Verfahren gemäß einem der Aspekte 36-38, weiterhin Folgendes umfassend: nach dem Schwellenwertzeitraum, Löschen mindestens eines Teils der mehreren Transaktionen, die während des Schwellenwertzeitraums aus dem lokalen verteilten Ledger-Netzwerk generiert wurden.
40. Das Verfahren gemäß einem der Aspekte 36-39, wobei das globale verteilte Ledger eine permissioned Blockchain ist, die von mehreren Einheiten, die mehrere Prozessanlagen betreiben, eingesehen werden kann.
41. Das Verfahren nach einem der Aspekte 36-40, wobei der Parameter sich auf eine gemeinsame Ressource zwischen den mehreren Einheiten bezieht, die mehrere Prozessanlagen betreiben.
42. Das Verfahren gemäß einem der Aspekte 36-41, wobei das globale verteilte Ledger mehrere globale verteilte Ledger enthält, die den mehreren Einheiten entsprechen, wobei jedes globale verteilte Ledger Transaktionen enthält, die in dem lokalen verteilten Ledger für eine gleiche jeweilige Einheit wie das globale verteilte Ledger gespeichert sind.
43. Das Verfahren gemäß einem der Aspekte 36-42, weiterhin Folgendes umfassend: für Transaktionen, die während des Schwellenwertzeitraums erzeugt werden, Hinzufügen der Transaktion von jedem der mehreren global verteilten Ledgern zu einem Status-Block von Transaktionen; Lösen eines kryptographischen Puzzles auf der Basis des Status-Blocks von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Status-Block von Transaktionen; und Übertragen des Status-Blocks von Transaktionen an mindestens einen anderen Teilnehmer in einem Super-Blockchain-Netzwerk von Teilnehmern, die eine Super-Blockchain verwalten.
44. Das Verfahren nach einem der Aspekte 36-43, wobei das lokale verteilte Ledger eine private Blockchain ist, die von einer Einheit, die die Prozessanlage betreibt, eingesehen werden kann.
45. Das Verfahren gemäß einem der Aspekte 36-44, wobei die Generierung einer Transaktion einschließlich der Messung die Generierung der Transaktion einschließlich eines kryptographischen Hash-Wertes entsprechend der Messung beinhaltet.
46. Das Verfahren gemäß einem der Aspekte 36-45, wobei die gemeinsame Ressource zwischen den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, ein Fluid in einer Fluid-Pipeline ist, und die Parametermessung eine Fluidmenge ist, die von einer der mehreren Einheiten aus der Fluid-Pipeline erhalten wird.
47. System zur sicheren Messung von nicht vertrauenswürdigen Daten in Prozesssteuerungssystemen mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, Folgendes umfassend: ein oder mehrere Feldgeräte, die in einer Prozessanlage angeordnet sind und jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses ausführen, wobei das eine oder die mehreren Feldgeräte so konfiguriert sind, dass sie Messungen von Parametern innerhalb der Prozessanlage sammeln und die Parametermessungen an ein oder mehrere Edge-Gateway-Geräte liefern; und das eine oder die mehreren Edge-Gateway-Geräte, die in der Prozessanlage ausgeführt werden, jeweils Folgendes umfassen: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges, computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit gekoppelt ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, die Edge-Gateway-Vorrichtung dazu veranlassen, Folgendes auszuführen: Erhalten von mindestens einer der Parametermessungen; Generieren einer Transaktion einschließlich der Messung; und Übertragen der Transaktion zu mindestens einem anderen Edge-Gateway in einem lokalen verteilten Ledger-Netzwerk von Edge-Gateways, die ein lokales verteiltes Ledger verwalten; und nach einem Schwellenwertzeitraum, Übertragen mehrerer Transaktionen, die während des Schwellenwertzeitraums generiert wurden, zu mindestens einem Teilnehmer in einem globalen verteilten Ledger-Netzwerk von Teilnehmern, die ein globales verteiltes Ledger verwalten.
48. Das System gemäß Aspekt 47, wobei die Befehle ferner das Edge-Gateway zu Folgendem veranlassen: Hinzufügen der Transaktion zu einem lokalen Block von Transaktionen; Lösen eines kryptographischen Puzzles auf der Grundlage des lokalen Blocks von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem lokalen Block von Transaktionen; und Übertragen des lokalen Blocks von Transaktionen zu mindestens einem anderen Edge-Gateway in dem lokalen verteilten Ledger-Netzwerk.
49. Das System gemäß entweder Aspekt 47 oder Aspekt 48, wobei die Befehle ferner das Edge-Gateway zu Folgendem veranlassen: Nach dem Schwellenwertzeitraum, Übertragen eines oder mehrerer lokaler Blöcke von Transaktionen, die während des Schwellenwertzeitraums erzeugt wurden, an mindestens einen Teilnehmer im globalen verteilten Ledger-Netzwerk.
50. Das System nach einem der Aspekte 47-49, wobei die Befehle ferner das Edge-Gateway zu Folgendem veranlassen: nach dem Schwellenwertzeitraum Löschen mindestens einiger der mehreren Transaktionen, die während des Schwellenwertzeitraums aus dem lokalen verteilten Ledger-Netzwerk generiert wurden.
51. Das System gemäß einem der Aspekte 47-50, wobei das globale verteilte Ledger eine permissioned Blockchain ist, die von mehreren Einheiten, die mehrere Prozessanlagen betreiben, eingesehen werden kann.
52. Das System nach einem der Aspekte 47-51, wobei sich der Parameter auf eine gemeinsame Ressource zwischen den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, bezieht.
53. Das System gemäß einem der Aspekte 47-52, wobei das globale verteilte Ledger mehrere globale verteilte Ledger entsprechend der mehreren Einheiten enthält, wobei jedes globale verteilte Ledger Transaktionen enthält, die in dem lokalen verteilten Ledger für dieselbe jeweilige Einheit wie das globale verteilte Ledger gespeichert sind.
54. Das System gemäß einem der Aspekte 47-53, weiterhin Folgendes umfassend: ein Computergerät in einem globalen verteilten Ledger-Netzwerk, das ein globales verteiltes Ledger verwaltet, das Folgendes umfasst: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit gekoppelt ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Computergerät zu Folgendem veranlassen: für Transaktionen, die während des Schwellenwertzeitraums generiert werden, Hinzufügen der Transaktion von jedem der mehreren globalen verteilten Ledgern zu einem Status-Block von Transaktionen; Lösen eines kryptographischen Puzzles auf der Grundlage des Status-Blocks von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Status-Block von Transaktionen; und Übertragen des Status-Blocks von Transaktionen an mindestens einen anderen Teilnehmer in einem Super-Blockchain-Netzwerk von Teilnehmern, die eine Super-Blockchain verwalten.
55. Das System gemäß einem der Aspekte 47-54, wobei das lokale verteilte Ledger eine private Blockchain ist, die von einer Einheit, die die Prozessanlage betreibt, eingesehen werden kann.
56. Das System gemäß einem der Aspekte 47-55, wobei die Transaktion einen kryptographischen Hash-Wert entsprechend der Messung enthält.
57. Das System gemäß einem der Aspekte 47-56, wobei die gemeinsame Ressource zwischen den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, ein Fluid in einer Fluid-Pipeline ist, und die Parametermessung eine Fluidmenge ist, die von einer der mehreren Einheiten aus der Fluid-Pipeline erhalten wird.
58. Ein validierender Netzwerkknoten in einer Prozessanlage auf einem lokalen verteilten Ledger-Netzwerk, bestehend aus Folgendem: einen Sender-Empfänger, der so konfiguriert ist, dass er (i) mit einem oder mehreren Feldgeräten kommuniziert, von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses in der Prozessanlage ausführt und Messungen von Parametern innerhalb der Prozessanlage sammelt, und (ii) lokale verteilte Ledger-Daten mit Peer-Netzwerkknoten austauscht, wobei die lokalen verteilten Ledger-Daten Transaktionen mit Parametermessungen umfassen; ein Speichermedium, das so konfiguriert ist, dass es eine Kopie des lokalen verteilten Ledgers speichert; und einen Prozessdaten-Validierer, der so konfiguriert ist, dass er einen Satz von Konsens-Regeln auf die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers anwendet, wobei der Prozessdaten-Validierer ferner so konfiguriert ist, dass er die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers an die Kopie des verteilten Ledgers anhängt, wenn die Daten des verteilten Ledgers die Konsens-Regeln erfüllen, wobei der Sender-Empfänger nach einem Schwellenwertzeitraum so konfiguriert ist, dass er mehrere Transaktionen, die während des Schwellenwertzeitraums generiert werden, an mindestens einen Teilnehmer in einem globalen Netzwerk von Teilnehmern, die ein globales verteiltes Ledger führen, überträgt.
59. Der validierende Netzwerkknoten gemäß Aspekt 58, wobei der validierende Netzwerkknoten nach dem Schwellenwertzeitraum so konfiguriert ist, dass er zumindest einige der mehreren Transaktionen löscht, die während des Schwellenwertzeitraums aus der Kopie des lokalen verteilten Ledgers generiert wurden.
60. Der validierende Netzwerkknoten gemäß einem der Aspekte 58 oder 59, wobei das globale verteilte Ledger eine permissioned Blockchain ist, die von mehreren Einheiten, die mehrere Prozessanlagen betreiben, eingesehen werden kann.
61. Der validierende Netzwerkknoten gemäß einem der Aspekte 58-60, wobei mindestens einer der Parameter sich auf eine gemeinsame Ressource zwischen den mehreren Einheiten bezieht, die mehreren Prozessanlagen betreiben.
62. Der validierende Netzwerkknoten gemäß einem der Aspekte 58-61, wobei das globale verteilte Ledger mehrere globale verteilte Ledgern entsprechend den mehreren Einheiten enthält, wobei jedes globale verteilte Ledger Transaktionen enthält, die in dem lokalen verteilten Ledger für dieselbe jeweilige Einheit wie das globale verteilte Ledger gespeichert sind.
63. Der validierende Netzwerkknoten gemäß einem der Aspekte 58-62, wobei das lokale verteilte Ledger eine private Blockchain ist, die von einer Einheit, die die Prozessanlage betreibt, eingesehen werden kann.
64. Der validierende Netzwerkknoten nach einem der Aspekte 58-63, wobei eine Transaktion einen kryptographischen Hash-Wert enthält, der einer Parametermessung entspricht.
65. Verfahren zum Aufzeichnen von Qualitätskontroll-, Produktions- oder Regulierungsdaten in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Erfassen eines auslösenden Ereignisses, das sich auf die Qualitätskontrolle innerhalb einer Prozessanlage bezieht, über ein oder mehrere Feldgeräte, von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; Erhalten von Ereignisdaten aus dem auslösenden Ereignis, die mindestens eines davon umfassen: ein Zeitpunkt des auslösenden Ereignisses, eine Dauer des auslösenden Ereignisses, Produktparameterdaten, die sich auf das auslösende Ereignis beziehen, oder Prozessparameterdaten, die sich auf das auslösende Ereignis beziehen; Erzeugen einer Transaktion, die die Ereignisdaten enthält, wobei die Transaktion in dem verteilten Ledger gespeichert wird; und Übertragen der Transaktion an mindestens einen anderen Teilnehmer in einem verteilten Ledger-Netzwerk von Teilnehmern, die das verteilte Ledger verwalten.
66. Das Verfahren gemäß Aspekt 65, wobei das auslösende Ereignis mindestens eines der folgenden ist: ein Alarm, ein Fehler, ein Leck, ein Reparaturereignis, ein Prozessmeilenstein oder eine Korrekturmaßnahme.
67. Das Verfahren gemäß entweder Aspekt 65 oder Aspekt 66, weiterhin Folgendes umfassend: Empfangen einer Anforderung für Ereignisdaten von einem bestimmten auslösenden Ereignis; Erhalten der Ereignisdaten von dem verteilten Ledger; und Darstellen der Ereignisdaten von dem bestimmten auslösenden Ereignis auf einer Benutzerschni ttstelle.
68. Das Verfahren gemäß einem der Aspekte 65-67, wobei die Generierung einer Transaktion einschließlich der Ereignisdaten die Generierung der Transaktion einschließlich eines kryptographischen Hash-Wertes umfasst, der zumindest einigen der Ereignisdaten entspricht.
69. Das Verfahren gemäß einem der Aspekte 65-68, weiterhin Folgendes umfassend: Speichern der Ereignisdaten in einer Datenbank; und als Reaktion auf eine Anforderung zur Authentifizierung der Ereignisdaten, Bereitstellen des kryptografischen Hash-Wertes, der mindestens einigen der Ereignisdaten aus dem verteilten Ledger entspricht, zusammen mit den Ereignisdaten aus der Datenbank, um die Authentizität der Ereignisdaten zu verifizieren.
70. Das Verfahren gemäß einem der Aspekte 65-69, wobei das auslösende Ereignis eine Öffnung in einem Entlastungsventil ist und die Ereignisdaten von dem auslösenden Ereignis mindestens eines der folgenden Elemente umfassen: eine Zeit, zu der das Entlastungsventil geöffnet wurde, eine Dauer, in der das Entlastungsventil geöffnet wurde, einen Druckwert, wenn das Entlastungsventil geöffnet wurde, oder eine Fluidmenge, die während der Öffnung des Entlastungsventils entfernt wurde.
71. Das Verfahren nach einem der Aspekte 65-70, wobei das verteilte Ledger eine private Blockchain ist, zu der die Prozessanlage und eine Regulierungsbehörde Zugang haben.
72. Das Verfahren nach einem der Aspekte 65-71, wobei das verteilte Ledger eine öffentliche Blockchain ist.
73. Das Verfahren nach einem der Aspekte 65-72, wobei die Transaktion ferner eine eindeutige Kennung für das auslösende Ereignis enthält.
74. Das Verfahren gemäß einem der Aspekte 65-73, ferner umfassend: Übertragung eines Hinweises auf das erfasste auslösende Ereignis einschließlich der eindeutigen Kennung für das auslösende Ereignis an ein oder mehrere andere Prozesssteuerungselemente in der Prozessanlage für die anderen Prozesssteuerungselemente, um Transaktionen einschließlich zusätzlicher Ereignisdaten in Bezug auf das auslösende Ereignis zu generieren.
75. System zum Aufzeichnen von Qualitätskontroll-, Produktions- oder Regulierungsdaten in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, Folgendes umfassend: eine oder mehrere Vorrichtungen, die in einer Prozessanlage angeordnet sind und von denen jede eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; und ein Computergerät, das in der Prozessanlage ausgeführt wird und Folgendes umfasst: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit verbunden ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Computergerät zu Folgendem veranlassen: Erfassen eines auslösenden Ereignisses, das sich auf die Qualitätskontrolle innerhalb einer Prozessanlage bezieht, über die eine oder mehrere Vorrichtungen; Erhalten von Ereignisdaten von dem auslösenden Ereignis, die mindestens eines der folgenden Elemente enthalten: ein Zeitpunkt des auslösenden Ereignisses, eine Dauer des auslösenden Ereignisses, Produktparameterdaten, die sich auf das auslösende Ereignis beziehen, oder Prozessparameterdaten, die sich auf das auslösende Ereignis beziehen; Generieren einer Transaktion, die die Ereignisdaten enthält, wobei die Transaktion in dem verteilten Ledger gespeichert wird; und Übertragen der Transaktion an mindestens einen anderen Teilnehmer in einem verteilten Ledger-Netzwerk von Teilnehmern, die das verteilte Ledger zum Validieren und Aufzeichnen der Transaktion in dem verteilten Ledger verwalten.
76. Das System gemäß Aspekt 75, wobei das auslösende Ereignis mindestens eines der Folgenden ist: ein Alarm, ein Fehler, ein Leck, ein Reparaturereignis, ein Prozessmeilenstein oder eine Korrekturmaßnahme.
77. Das System gemäß entweder Aspekt 75 oder Aspekt 76, wobei die Befehle weiterhin das Computergerät zu Folgendem veranlassen: Empfangen einer Anforderung von Ereignisdaten von einem bestimmten auslösenden Ereignis; Erhalten der Ereignisdaten von dem verteilten Ledger; und Darstellen der Ereignisdaten von dem bestimmten auslösenden Ereignis auf einer Benutzerschnittstelle.
78. Das System nach einem der Aspekte 75-77, wobei die Transaktion einen kryptographischen Hash-Wert enthält, der zumindest einigen der Ereignisdaten entspricht.
79. Das System gemäß einem der Aspekte 75-78, wobei die Befehle ferner das Computergerät zu Folgendem veranlassen: Speichern der Ereignisdaten in einer Datenbank; und als Reaktion auf eine Anforderung zur Authentifizierung der Ereignisdaten, Bereitstellen des kryptographischen Hash-Wertes, der zumindest einigen der Ereignisdaten aus dem verteilten Ledger entspricht, zusammen mit den Ereignisdaten aus der Datenbank, um die Authentizität der Ereignisdaten zu verifizieren.
80. Das System gemäß einem der Aspekte 75-79, wobei das auslösende Ereignis eine Öffnung in einem Entlastungsventil ist und die Ereignisdaten von dem auslösenden Ereignis mindestens eines der Folgenden umfassen: ein Zeitpunkt, zu dem sich das Entlastungsventil geöffnet hat, eine Dauer, in der sich das Entlastungsventil geöffnet hat, ein Druckwert, wenn sich das Entlastungsventil geöffnet hat, oder eine Fluidmenge, die während der Öffnung des Entlastungsventils entfernt wurde.
81. Das System nach einem der Aspekte 75-80, wobei das verteilte Ledger eine private Blockchain ist, auf die die Prozessanlage und eine Regulierungsbehörde Zugriff haben.
82. Das System nach einem der Aspekte 75-81, wobei das verteilte Ledger eine öffentliche Blockchain ist.
83. Das System nach einem der Aspekte 75-82, wobei die Transaktion außerdem eine eindeutige Kennung für das auslösende Ereignis enthält.
84. Das System nach einem der Aspekte 75-83, wobei die Befehle ferner das Computergerät zu Folgendem veranlassen: Übertragung eines Hinweises auf das erfasste auslösende Ereignis einschließlich der eindeutigen Kennung für das auslösende Ereignis an das eine oder die mehreren Geräte in der Prozessanlage, damit das eine oder die mehreren Geräte Transaktionen einschließlich zusätzlicher Ereignisdaten in Bezug auf das auslösende Ereignis generieren.
85. Ein validierender Netzwerkknoten in einer Prozessanlage auf einem verteilten Ledger-Netzwerk, bestehend aus: einen Sender-Empfänger, der so konfiguriert ist, dass er mit einem oder mehreren Feldgeräten kommuniziert, die jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses in der Prozessanlage und zum Austausch von Daten des verteilten Ledgers mit Peer-Netzwerkknoten ausführen, wobei die Daten des verteilten Ledgers Transaktionen mit Ereignisdaten von einem auslösenden Ereignis enthalten; ein Speichermedium, das so konfiguriert ist, dass es eine Kopie des verteilten Ledgers speichert; und einen Prozessdaten-Validierer, der so konfiguriert ist, dass er einen Satz von Konsens-Regeln auf die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers anwendet, wobei der Prozessdaten-Validierer ferner so konfiguriert ist, dass er die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers an die Kopie des verteilten Ledgers anhängt, wenn die Daten des verteilten Ledgers die Konsens-Regeln erfüllen.
86. Der validierende Netzwerkknoten gemäß Aspekt 85, wobei die Ereignisdaten mindestens eines der folgenden Elemente enthalten: einen Zeitpunkt des auslösenden Ereignisses, eine Dauer des auslösenden Ereignisses, Produktparameterdaten, die sich auf das auslösende Ereignis beziehen, oder Prozessparameterdaten, die sich auf das auslösende Ereignis beziehen.
87. Der validierende Netzwerkknoten gemäß entweder Aspekt 85 oder Aspekt 86, wobei das auslösende Ereignis mindestens eines der Folgenden ist: ein Alarm, ein Fehler, ein Leck, ein Reparaturereignis oder eine Korrekturmaßnahme.
88. Der validierende Netzwerkknoten gemäß einem der Aspekte 85-87, wobei die von den Peer-Knoten empfangenen verteilten Ledger-Daten einen Identitätsnachweis eines der einen oder mehreren Feldgeräte enthalten, die eine Transaktion mit Ereignisdaten generieren.
89. Der validierende Netzwerkknoten gemäß einem der Aspekte 85-88, wobei der Transaktions-Validierer zum Anhängen der von den Peer-Knoten empfangenen Daten des verteilten Ledgers wie folgt konfiguriert ist: Lösen eines kryptographischen Puzzles auf der Basis eines Blocks von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; Anhängen des Blocks von Transaktionen an die Kopie des verteilten Ledgers; und Übertragen des Blocks von Transaktionen an mindestens einen der Peer-Netzwerkknoten in dem Netzwerk des verteilten Ledgers.
90. Der validierende Netzwerkknoten gemäß einem der Aspekte 85-89, wobei der Satz von Konsens-Regeln mindestens eines der folgenden umfasst:
- Formatierungsanforderungen für Transaktionen oder für Blöcke von Transaktionen; einen Mechanismus, um zu bestimmen, welcher der Peer-Netzwerkknoten eine nächste Transaktion oder einen nächsten Block von Transaktionen zum verteilten Ledger hinzufügt; oder einen kryptographischen Hash-Algorithmus zum Hashing der in jeder der Transaktionen enthaltenen Prozesssteuerungsdaten.
91. Der validierende Netzwerkknoten nach einem der Aspekte 85-90, wobei das verteilte Ledger eine private Blockchain ist, auf die die Prozessanlage und eine Regulierungsbehörde Zugriff haben.
92. Der validierende Netzwerkknoten nach einem der Aspekte 85-91, wobei das verteilte Ledger eine öffentliche Blockchain ist.
93. Der validierende Netzwerkknoten gemäß einem der Aspekte 85-92, wobei die Transaktion außerdem eine eindeutige Kennung für das auslösende Ereignis enthält.
94. Verfahren zum Aufzeichnen von Zuständen von Software oder Firmware in einem Prozesssteuerungssystem und einer angeschlossenen Instrumentierung mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Erhalten mittels eines Computergeräts einen aktuellen Status von Software oder Firmware, die innerhalb einer Prozessanlage mit einem oder mehreren Feldgeräten ausgeführt wird, die jeweils eine physikalische Funktion zur Steuerung eines industriellen Prozesses ausführen, wobei die Software oder Firmware innerhalb eines Netzwerks oder einer Prozesssteuerungsvorrichtung innerhalb der Prozessanlage ausgeführt wird; Generieren einer Transaktion einschließlich des aktuellen Status der Software oder Firmware, die innerhalb der Prozessanlage ausgeführt wird, wobei die Transaktion im verteilten Ledger gespeichert wird; und Übertragen der Transaktion an mindestens einen anderen Teilnehmer in einem verteilten Ledger-Netzwerk von Teilnehmern, die das verteilte Ledger verwalten.
95. Das Verfahren gemäß Aspekt 94, wobei der aktuelle Status der Software oder Firmware, die innerhalb der Prozessanlage ausgeführt wird, von einem Computergerät eines Benutzers erhalten wird, der den aktuellen Status aktualisiert hat, und wobei das Generieren der Transaktion ferner Folgendes umfasst: Erhalten von Identitätsdaten für den Benutzer; Erweitern der Transaktion mit den Identitätsdaten für den Benutzer an dem einen oder den mehreren Prozessoren; Erzeugen einer kryptographischen Signatur basierend auf der Transaktion an dem einen oder den mehreren Prozessoren; und Erweitern der Transaktion mit der kryptographischen Signatur an dem einen oder den mehreren Prozessoren.
96. Das Verfahren gemäß entweder Aspekt 94 oder Aspekt 95, wobei das Generieren einer Transaktion, die den aktuellen Status der in der Prozessanlage ausgeführten Software oder Firmware enthält, das Generieren der Transaktion einschließlich eines kryptographischen Hash-Wertes umfasst, der dem aktuellen Status der in der Prozessanlage ausgeführten Software oder Firmware entspricht.
97. Das Verfahren gemäß einem der Aspekte 94-96, weiterhin umfassend: Erhalten eines Status der Software oder Firmware, die in der Prozessanlage ausgeführt wird, von dem Netzwerk oder der Prozesssteuerungsvorrichtung, die die Software oder Firmware ausführt; und Vergleichen des Status der Software oder Firmware, die in der Prozessanlage ausgeführt wird, mit dem kryptographischen Hash-Wert aus dem verteilten Ledger, um zu verifizieren, dass die Software oder Firmware nicht manipuliert wurde.
98. Das Verfahren gemäß einem der Aspekte 94-97, weiterhin umfassend: als Reaktion auf die Feststellung einer Abweichung des Zustands der in der Prozessanlage ausgeführten Software oder Firmware von dem aktuellen Zustand der in dem verteilten Ledger gespeicherten Software oder Firmware gemäß dem kryptographischen Hash-Wert, Verhinderung der Ausführung der Software oder Firmware in der Prozessanlage.
99. Das Verfahren gemäß einem der Aspekte 94-98, das ferner Folgendes umfasst: Veranlassen, dass die Software oder Firmware in einen früheren Status zurückversetzt wird.
100. Das Verfahren gemäß einem der Aspekte 94-99, weiterhin umfassend: als Reaktion auf die Feststellung einer Übereinstimmung des Zustands der in der Prozessanlage ausgeführten Software oder Firmware mit dem aktuellen Zustand der in dem verteilten Ledger gespeicherten Software oder Firmware gemäß dem kryptographischen Hash-Wert, Veranlassen des Netzwerks oder der Prozesssteuerungsvorrichtung zur Ausführung der Software oder Firmware.
101. Das Verfahren gemäß einem der Aspekte 94-100, weiterhin umfassend: Hinzufügen der Transaktion zu einem Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; und Übertragen des Blocks von Transaktionen an mindestens einen anderen Teilnehmer in dem verteilten Ledger-Netzwerk.
102. Das Verfahren gemäß einem der Aspekte 94-101, weiterhin Folgendes umfassend: Vergleichen der Identitätsdaten in der Transaktion mit mehreren Identitätsdatensätzen, die Benutzern entsprechen, die zur Aktualisierung des Status der in der Prozessanlage ausgeführten Software oder Firmware autorisiert sind; und Hinzufügen der Transaktion zu dem Block von Transaktionen, wenn die Identitätsdaten in den mehreren Identitätsdatensätzen enthalten sind.
103. Das Verfahren nach einem der Aspekte 94-102, wobei das verteilte Ledger eine permissioned Blockchain ist.
104. System zum Aufzeichnen von Zuständen von Software oder Firmware in einem Prozesssteuerungssystem und einer angeschlossenen Instrumentierung unter Verwendung eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, umfassend: eine oder mehrere Vorrichtungen, die in einer Prozessanlage angeordnet sind und von denen jede eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; und ein Computergerät, das in der Prozessanlage ausgeführt wird und Folgendes umfasst:
- einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit verbunden ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Computergerät zu Folgendem veranlassen: Erhalten eines aktuellen Status von Software oder Firmware, die in der Prozessanlage ausgeführt wird, wobei die Software oder Firmware in mindestens einer der einen oder mehreren in der Prozessanlage angeordneten Vorrichtungen oder einer Netzwerkeinrichtung in der Prozessanlage ausgeführt wird; Generieren einer Transaktion, die den aktuellen Status der in der Prozessanlage ausgeführten Software oder Firmware enthält, wobei die Transaktion in dem verteilten Ledger gespeichert wird; und Übertragen der Transaktion an mindestens einen anderen Teilnehmer in einem verteilten Ledger-Netzwerk von Teilnehmern, die das verteilte Ledger zur Validierung und Aufzeichnung der Transaktion in dem verteilten Ledger führen.
105. Das System gemäß Aspekt 104, wobei der aktuelle Status der Software oder Firmware, die innerhalb der Prozessanlage ausgeführt wird, von einem Computergerät eines Benutzers erhalten wird, der den aktuellen Status aktualisiert hat, und zur Generierung der Transaktion veranlassen die Befehle das Computergerät zu Folgendem: Erhalten von Identitätsdaten für den Benutzer; Erweitern der Transaktion mit den Identitätsdaten für den Benutzer; Erzeugen einer kryptographischen Signatur basierend auf der Transaktion; und Erweitern der Transaktion mit der kryptographischen Signatur.
106. Das System gemäß entweder Aspekt 104 oder Aspekt 105, wobei die Transaktion mit einem kryptographischen Hash-Wert generiert wird, der dem aktuellen Status der in der Prozessanlage ausgeführten Software oder Firmware entspricht.
107. Das System gemäß einem der Aspekte 104-106, weiterhin Folgendes umfassend: ein Servergerät, das Folgendes umfasst: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit verbunden ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Servergerät dazu veranlassen: Erhalten eines Status der Software oder Firmware, die in der Prozessanlage ausgeführt wird, von der Netzwerk- oder Prozesssteuervorrichtung, die die Software oder Firmware ausführt; und Vergleichen des Status der Software oder Firmware, die in der Prozessanlage ausgeführt wird, mit dem kryptographischen Hash-Wert aus dem verteilten Ledger, um zu verifizieren, dass die Software oder Firmware nicht manipuliert wurde.
108. Das System gemäß einem der Aspekte 104-107, wobei die Befehle ferner das Servergerät zu Folgendem veranlassen: als Reaktion auf die Feststellung einer Abweichung des Status der in der Prozessanlage ausgeführten Software oder Firmware von dem aktuellen Status der in dem verteilten Ledger gespeicherten Software oder Firmware gemäß dem kryptographischen Hash-Wert, Verhindern der Ausführung der Software oder Firmware in der Prozessanlage.
109. Das System nach einem der Aspekte 104-108, wobei die Befehle ferner das Servergerät zu Folgendem veranlassen: Die Software oder Firmware in einen früheren Status zurückversetzen.
110. Das System gemäß einem der Aspekte 104-109, wobei die Befehle ferner das Servergerät zu Folgendem veranlassen: als Reaktion auf die Feststellung einer Übereinstimmung des Status der in der Prozessanlage ausgeführten Software oder Firmware mit dem aktuellen Status der in dem verteilten Ledger gespeicherten Software oder Firmware gemäß dem kryptographischen Hash-Wert, Veranlassen, dass die Netzwerk- oder Prozesssteuerungsvorrichtung die Software oder Firmware ausführt.
111. Das System gemäß einem der Aspekte 104-110, wobei die Befehle weiterhin das Computergerät zu Folgendem veranlassen: Hinzufügen der Transaktion zu einem Block von Transaktionen; Lösen eines kryptographischen Puzzles auf Basis des Blocks von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; und Übertragen des Blocks von Transaktionen an mindestens einen anderen Teilnehmer in dem verteilten Ledger-Netzwerk.
112. Das System gemäß einem der Aspekte 104-111, wobei die Befehle ferner das Computergerät zu Folgendem veranlassen: Vergleichen der Identitätsdaten in der Transaktion mehreren Identitätsdatensätzen, die Benutzern entsprechen, die zur Aktualisierung des Status der in der Prozessanlage ausgeführten Software oder Firmware autorisiert sind; und Hinzufügen der Transaktion zu dem Block von Transaktionen, wenn die Identitätsdaten in den mehreren Identitätsdatensätzen enthalten sind.
113. Das System nach einem der Aspekte 104-112, wobei das verteilte Ledger eine permissioned Blockchain ist.
114. Ein validierender Netzwerkknoten in einer Prozessanlage an einem verteilten Ledger-Netzwerk, bestehend aus: einen Sender-Empfänger, der so konfiguriert ist, dass er mit einem oder mehreren Feldgeräten kommuniziert, von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses in der Prozessanlage ausführt und verteilte Ledger-Daten mit Peer-Netzwerkknoten austauscht, wobei die verteilten Ledger-Daten Transaktionen mit Daten enthalten, die den aktuellen Status der in der Prozessanlage ausgeführten Software oder Firmware anzeigen; ein Speichermedium, das so konfiguriert ist, dass es eine Kopie des verteilten Ledgers speichert; und einen Prozessdaten-Validierer, der so konfiguriert ist, dass er einen Satz von Konsens-Regeln auf die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers anwendet, wobei der Prozessdaten-Validierer ferner so konfiguriert ist, dass er die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers an die Kopie des verteilten Ledgers anhängt, wenn die Daten des verteilten Ledgers die Konsens-Regeln erfüllen.
115. Der validierende Netzwerkknoten gemäß Aspekt 114, wobei der Transaktions-Validierer zum Anhängen von verteilten Ledger-Daten, die von Peer-Knoten empfangen werden, für Folgendes konfiguriert ist: Lösen eines kryptographischen Puzzles basierend auf einem Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; Anhängen des Blocks von Transaktionen an die Kopie des verteilten Ledgers; und Übertragen des Blocks von Transaktionen an mindestens einen der Peer-Netzwerkknoten in dem Netzwerk des verteilten Ledgers.
116. Der validierende Netzwerkknoten gemäß entweder Aspekt 114 oder Aspekt 115, wobei der Satz von Konsens-Regeln mindestens eines der folgenden Elemente enthält: Formatierungsanforderungen für Transaktionen oder für Blöcke von Transaktionen; einen Mechanismus, um zu bestimmen, welcher der Peer-Netzwerkknoten eine nächste Transaktion oder einen nächsten Block von Transaktionen zu dem verteilten Ledger hinzufügt; oder einen kryptographischen Hash-Algorithmus zum Hashing von Software- oder Firmware-Statusdaten, die in jeder der Transaktionen enthalten sind.
117. Der validierende Netzwerkknoten gemäß einem der Aspekte 114-116, wobei die von den Peer-Knoten empfangenen verteilten Ledger-Daten einen Identitätsnachweis eines Benutzers eines Geräts enthalten, das eine Transaktion mit Daten generiert, die den aktuellen Status der in der Prozessanlage ausgeführten Software oder Firmware anzeigen.
118. Verfahren zum Generieren von intelligenten Verträgen in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Generieren eines intelligenten Vertrags durch einen oder mehrere Prozessoren, der sich auf eine Prozessanlage mit einer oder mehreren Feldgeräten bezieht, von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; und Einsetzen des intelligenten Vertrags durch den einen oder die mehreren Prozessoren an einer Adresse, die in dem verteilten Ledger gespeichert ist, das von den mehreren Teilnehmern in einem verteilten Ledger-Netzwerk verwaltet wird.
119. Das Verfahren gemäß Aspekt 118, wobei der intelligente Vertrag einen Token-Wert in Abhängigkeit von einem in der Prozessanlage auftretenden Ereignis erhält oder bereitstellt.
120. Das Verfahren gemäß entweder Aspekt 118 oder Aspekt 119, wobei das Generieren eines intelligenten Vertrags, der sich auf eine Prozessanlage bezieht, das Generieren eines intelligenten Vertrags umfasst, der einen Token-Wert von einer ersten Prozessanlage erhält, bestimmt, dass ein Produkt von einer zweiten Prozessanlage in die erste Prozessanlage transferiert wird, und den Token-Wert der zweiten Prozessanlage bereitstellt.
121. Das Verfahren gemäß einem der Aspekte 118-120, wobei der intelligente Vertrag bestimmt, dass ein Produkt von der zweiten Prozessanlage in die erste Prozessanlage transferiert wird, indem eine Transaktion von einem Beweis-Orakel empfangen wird, das anzeigt, dass das Produkt in der ersten Prozessanlage empfangen wurde.
122. Das Verfahren gemäß einem der Aspekte 118-121, wobei die Erzeugung eines intelligenten Vertrags, der sich auf eine Prozessanlage bezieht, weiterhin die Erzeugung eines intelligenten Vertrags umfasst, der bestimmt, dass das Produkt eine oder mehrere Qualitätsmetriken erfüllt oder überschreitet, und den symbolischen Wert an die zweite Prozessanlage liefert, und zwar als Reaktion auf die Bestimmung, dass das Produkt die eine oder mehrere Qualitätsmetriken erfüllt oder übertrifft.
123. Das Verfahren gemäß einem der Aspekte 118-122, wobei der intelligente Vertrag bestimmt, dass das Produkt eine oder mehrere Qualitätsmetriken erfüllt oder übertrifft, indem er eine oder mehrere Transaktionen vom Beweis-Orakel erhält, die jeweils einen Produktparameterwert oder einen Prozessparameterwert enthalten, und den Produktparameterwert oder den Prozessparameterwert mit einem Produkt- oder Prozessparameterschwellenwert vergleicht, der in der einen oder den mehreren Qualitätsmetriken enthalten ist.
124. Das Verfahren gemäß einem der Aspekte 118-123, wobei das Generieren eines intelligenten Vertrags, der sich auf eine Prozessanlage bezieht, das Generieren eines intelligenten Vertrags umfasst, der Geräteinformationen für ein Gerät innerhalb der Prozessanlage, das eine Störung aufweist, erhält und die Geräteinformationen einem Gerätelieferanten bereitstellt, und zwar als Reaktion auf den Empfang einer Anforderung zur Weitergabe der Geräteinformationen.
125. Das Verfahren gemäß einem der Aspekte 118-124, wobei der intelligente Vertrag Geräteinformationen durch Empfangen einer Transaktion von einem Beweisorakel erhält, das die Geräteinformationen beinhaltet.
126. Verfahren gemäß einem der Aspekte 118-125, wobei der intelligente Vertrag eine Anforderung zur Weitergabe der Geräteinformationen durch Empfang einer Transaktion erhält, die die Anforderung zusammen mit Identitätsdaten für einen Benutzer, der die Anforderung ausgegeben hat, enthält, und wobei der intelligente Vertrag die Identitätsdaten in der Transaktion mit mehreren Identitätsdatensätzen vergleicht, die Benutzern entsprechen, die autorisiert sind, anzufordern, dass das verteilte Ledger-Netzwerk die Geräteinformationen weitergibt und die Geräteinformationen dem Gerätelieferanten zur Verfügung stellt, wenn die Identitätsdaten in den mehreren Identitätsdatensätzen enthalten sind.
127. Verfahren gemäß einem der Aspekte 118-126, wobei die Generierung eines intelligenten Vertrags für eine Prozessanlage die Generierung eines intelligenten Vertrags umfasst, der einen Parameter empfängt, der mit einem Gerät des Sicherheitssystems (SIS) verbunden ist, und den Parameter in das SIS-Gerät schreibt, wenn festgestellt wird, dass ein Betreiber, der den Parameter bereitgestellt hat, ein autorisierter Betreiber ist.
128. Das Verfahren gemäß einem der Aspekte 118-127, wobei der intelligente Vertrag einen Parameter empfängt, der einem SIS-Gerät zugeordnet ist, indem er eine Transaktion empfängt, die den Parameter zusammen mit Identitätsdaten für den Betreiber, der die Transaktion bereitgestellt hat, enthält, und wobei die Bestimmung, dass ein Betreiber, der den Parameter bereitgestellt hat, ein autorisierter Betreiber ist, den Vergleich der Identitätsdaten in der Transaktion mit mehreren Identitätsdatensätzen umfasst, die den Betreibern entsprechen, die zum Einstellen der dem SIS-Gerät zugeordneten Parameter autorisiert sind.
129. Das Verfahren gemäß einem der Aspekte 118-128, wobei der mit dem SIS-Gerät verknüpfte Parameter eine Anforderung zum Sperren des SIS-Gerätes ist.
130. Verfahren zur Interaktion mit einem intelligenten Vertrag in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Erhalten von Ereignisdaten von einem Ereignis, das in einer Prozessanlage mit einem oder mehreren Feldgeräten auftritt, von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; als Reaktion auf einen intelligenten Vertrag, der an einer in dem verteilten Ledger gespeicherten Adresse eingesetzt wird, Generieren einer Transaktion, die die Ereignisdaten enthält, durch ein Computergerät; und Übertragen der Transaktion an den intelligenten Vertrag, der in dem verteilten Ledger gespeichert ist, das von den mehreren Teilnehmern in einem Netzwerk von verteilten Ledgern verwaltet wird.
131. Das Verfahren gemäß Aspekt 130, weiterhin Folgendes umfassend: Erhalten von Identitätsdaten für das Computergerät; Erweitern der Transaktion mit den Identitätsdaten für das Computergerät bei dem einen oder den mehreren Prozessoren; Erzeugen einer kryptographischen Signatur basierend auf der Transaktion bei dem einen oder den mehreren Prozessoren; und Erweitern der Transaktion mit der kryptographischen Signatur bei dem einen oder den mehreren Prozessoren.
132. Das Verfahren gemäß entweder Aspekt 130 oder Aspekt 131, weiterhin Folgendes umfassend: Hinzufügen der Transaktion zu einem Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; und Übertragen des Blocks von Transaktionen an mindestens einen anderen Teilnehmer im verteilten Ledger-Netzwerk.
133. Das Verfahren gemäß einem der Aspekte 130-132, wobei der intelligente Vertrag einen Token-Wert von einer ersten Prozessanlage erhält, bestimmt, dass ein Produkt von einer zweiten Prozessanlage zu der ersten Prozessanlage transferiert wird, und den Token-Wert der zweiten Prozessanlage zur Verfügung stellt, und wobei das Erhalten von Ereignisdaten von einem Ereignis, das innerhalb einer Prozessanlage auftritt, Folgendes umfasst: Erhalten eines Hinweises, dass das Produkt in der ersten Prozessanlage empfangen wurde; und Generieren der Transaktion einschließlich der Identifizierungsinformation für die erste Prozessanlage, der Identifizierungsinformation für das Produkt und eines Hinweises, dass das Produkt in der ersten Prozessanlage von der zweiten Prozessanlage empfangen wurde.
134. Das Verfahren gemäß einem der Aspekte 130-133, wobei das Erhalten eines Hinweises darauf, dass das Produkt in der ersten Prozessanlage empfangen wurde, weiterhin Folgendes umfasst: Erhalten eines oder mehrerer Produktparameterwerte für das Produkt oder eines oder mehrerer Prozessparameterwerte für Prozessanlageneinheiten, die an der Herstellung des Produkts beteiligt sind; und Generieren der Transaktion, die den einen oder die mehreren Produktparameterwerte oder einen oder mehrere Prozessparameterwerte umfasst.
135. Verfahren gemäß einem der Aspekte 130-134, wobei der intelligente Vertrag Geräteinformationen für ein Gerät innerhalb der Prozessanlage, das eine Störung aufweist, erhält und die Geräteinformationen einem Gerätelieferanten als Reaktion auf den Empfang einer Anforderung zur Weitergabe der Geräteinformationen zur Verfügung stellt, und wobei das Erhalten von Ereignisdaten von einem Ereignis, das innerhalb einer Prozessanlage auftritt, Folgendes umfasst: Erhalten von Geräteinformationen für das Gerät; und Generieren der Transaktion einschließlich der Identifizierungsinformationen für das Gerät und der Geräteinformationen.
136. Das Verfahren gemäß einem der Aspekte 130-135, wobei der intelligente Vertrag einen Parameter empfängt, der mit einem Gerät des Sicherheitssystems (SIS) verknüpft ist, und den Parameter in das SIS-Gerät schreibt, und zwar als Reaktion auf die Bestimmung, dass ein Betreiber, der den Parameter bereitgestellt hat, ein autorisierter Betreiber ist, und wobei das Erhalten von Ereignisdaten von einem Ereignis, das innerhalb einer Prozessanlage auftritt, Folgendes umfasst: Erhalten einer Anforderung zur Änderung eines Parameters, der mit einem SIS-Gerät verknüpft ist; und Generieren der Transaktion, die Identifizierungsinformationen für das SIS-Gerät, den geänderten Parameter und einen neuen Parameterwert für den geänderten Parameter umfasst.
137. Computergerät zum Generieren von intelligenten Verträgen in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, umfassend: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit gekoppelt ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Computergerät zu Folgendem veranlassen: Generieren eines intelligenten Vertrags, der sich auf eine Prozessanlage mit einem oder mehreren Feldgeräten bezieht, von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; und Bereitstellen des intelligenten Vertrags an einer Adresse, die in dem verteilten Ledger gespeichert ist, das von den mehreren Teilnehmern in einem Netzwerk des verteilten Ledgers verwaltet wird.
138. Das Computergerät gemäß Aspekt 137, wobei der intelligente Vertrag einen Token-Wert in Abhängigkeit von einem in der Prozessanlage auftretenden Ereignis erhält oder bereitstellt.
139. Das Computergerät gemäß entweder Aspekt 137 oder Aspekt 138, wobei der intelligente Vertrag einen Token-Wert von einer ersten Prozessanlage erhält, bestimmt, dass ein Produkt von einer zweiten Prozessanlage in die erste Prozessanlage transferiert wird, und den Token-Wert der zweiten Prozessanlage zur Verfügung stellt.
140. Das Computergerät gemäß einem der Aspekte 137-139, wobei der intelligente Vertrag bestimmt, dass ein Produkt von der zweiten Prozessanlage in die erste Prozessanlage transferiert wird, indem eine Transaktion von einem Beweis-Orakel empfangen wird, das anzeigt, dass das Produkt in der ersten Prozessanlage empfangen wurde.
141. Das Computergerät gemäß einem der Aspekte 137-140, wobei der intelligente Vertrag bestimmt, dass das Produkt eine oder mehrere Qualitätsmetriken erfüllt oder übertrifft, und den Token-Wert an die zweite Prozessanlage übermittelt, und zwar als Reaktion auf die Bestimmung, dass das Produkt die eine oder mehrere Qualitätsmetriken erfüllt oder übertrifft.
142. Das Computergerät gemäß einem der Aspekte 137-141, wobei der intelligente Vertrag bestimmt, dass das Produkt eine oder mehrere Qualitätsmetriken erfüllt oder übertrifft, indem es eine oder mehrere Transaktionen vom Beweis-Orakel erhält, die jeweils einen Produktparameterwert oder einen Prozessparameterwert enthalten, und den Produktparameterwert oder den Prozessparameterwert mit einem Produkt- oder Prozessparameterschwellenwert vergleicht, der in der einen oder den mehreren Qualitätsmetriken enthalten ist.
143. Das Computergerät gemäß einem der Aspekte 137-142, wobei der intelligente Vertrag Geräteinformationen für ein Gerät innerhalb der Prozessanlage, das eine Störung aufweist, beschafft und die Geräteinformationen einem Gerätelieferanten als Reaktion auf den Erhalt einer Anforderung zur Weitergabe der Geräteinformationen zur Verfügung stellt.
144. Das Computergerät nach einem der Aspekte 137-143, wobei der intelligente Vertrag Geräteinformationen durch den Empfang einer Transaktion von einem Beweis-Orakel erhält, das die Geräteinformationen beinhaltet.
145. Das Computergerät gemäß einem der Aspekte 137-144, wobei der intelligente Vertrag eine Anforderung zur Weitergabe der Geräteinformationen durch Empfang einer Transaktion erhält, die die Anforderung zusammen mit Identitätsdaten für einen Benutzer, der die Anforderung ausgegeben hat, beinhaltet, und wobei der intelligente Vertrag die Identitätsdaten in der Transaktion mit mehreren Identitätsdatensätzen vergleicht, die Benutzern entsprechen, die autorisiert sind, die Weitergabe der Geräteinformationen an das verteilte Ledger-Netzwerk anzufordern, und die Geräteinformationen dem Gerätelieferanten zur Verfügung stellt, wenn die Identitätsdaten in den mehreren Identitätsdatensätzen enthalten sind.
146. Das Computergerät gemäß einem der Aspekte 137-145, wobei der intelligente Vertrag einen Parameter erhält, der mit einem Gerät des Sicherheitssystems (SIS) verbunden ist, und den Parameter in das SIS-Gerät schreibt, und zwar als Reaktion auf die Bestimmung, dass ein Betreiber, der den Parameter bereitgestellt hat, ein autorisierter Betreiber ist.
147. Das Computergerät gemäß einem der Aspekte 137-146, wobei der intelligente Vertrag einen Parameter empfängt, der einem SIS-Gerät zugeordnet ist, indem er eine Transaktion empfängt, die den Parameter zusammen mit Identitätsdaten für den Betreiber, der die Transaktion bereitgestellt hat, enthält, und wobei die Bestimmung, dass ein Betreiber, der den Parameter bereitgestellt hat, ein autorisierter Betreiber ist, den Vergleich der Identitätsdaten in der Transaktion mit mehreren Identitätsdatensätzen umfasst, die den Betreibern entsprechen, die autorisiert sind, die dem SIS-Gerät zugeordneten Parameter einzustellen.
148. Das Computergerät gemäß einem der Aspekte 137-147, wobei der dem SIS-Gerät zugeordnete Parameter eine Anforderung zum Sperren des SIS-Gerätes ist.
149. System zur Interaktion mit intelligenten Verträgen in einem Prozesssteuerungssystem mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, umfassend: ein oder mehrere Geräte, die in einer Prozessanlage angeordnet sind und von denen jedes eine physische Funktion zur Steuerung eines industriellen Prozesses ausführt; und ein Computergerät, das in der Prozessanlage ausgeführt wird, umfassend: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder den mehreren Prozessoren und der Kommunikationseinheit gekoppelt ist und darauf Befehle speichert, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das Computergerät zu Folgendem veranlassen: Erhalten, über das eine oder die mehreren Geräte, von Ereignisdaten von einem Ereignis, das innerhalb der Prozessanlage auftritt; als Reaktion auf einen intelligenten Vertrag, der an eine in dem verteilten Ledger gespeicherte Adresse eingesetzt wird, Generieren einer Transaktion, die die Ereignisdaten enthält; und Übertragen der Transaktion an den intelligenten Vertrag, der in dem verteilten Ledger gespeichert ist, das von den mehreren Teilnehmern in einem verteilten Ledger-Netzwerk verwaltet wird.
150. Das System gemäß Aspekt 149, wobei die Befehle ferner das Computergerät zu Folgendem veranlassen: Erhalten von Identitätsdaten für das Computergerät; Erweitern der Transaktion mit den Identitätsdaten für das Computergerät; Erzeugen einer kryptographischen Signatur basierend auf der Transaktion; und Erweitern der Transaktion mit der kryptographischen Signatur.
151. Das System gemäß entweder Aspekt 149 oder Aspekt 150, wobei die Befehle ferner das Computergerät zu Folgendem veranlassen: Hinzufügen der Transaktion zu einem Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zu dem Block von Transaktionen; und Übertragen des Blocks von Transaktionen an mindestens einen anderen Teilnehmer in dem verteilten Ledger-Netzwerk.
152. Das System gemäß einem der Aspekte 149-151, wobei der intelligente Vertrag einen Token-Wert von einer ersten Prozessanlage erhält und bestimmt, dass ein Produkt von einer zweiten Prozessanlage in die erste Prozessanlage transferiert wird, und den Token-Wert der zweiten Prozessanlage zur Verfügung stellt, und wobei die Befehle das Computergerät zu Folgendem veranlassen: Erhalten von Ereignisdaten von einem in der Prozessanlage auftretenden Ereignis: Erhalten eines Hinweises, dass das Produkt in der ersten Prozessanlage empfangen wurde; und Erzeugen der Transaktion einschließlich der Identifizierungsinformation für die erste Prozessanlage, sowie der Identifizierungsinformation für das Produkt und eines Hinweises, dass das Produkt in der ersten Prozessanlage von der zweiten Prozessanlage empfangen wurde.
153. Das System gemäß einem der Aspekte 149-152, wobei, um einen Hinweis darauf zu erhalten, dass das Produkt in der ersten Prozessanlage empfangen wurde, die Befehle das Computergerät zu Folgendem veranlassen: Erhalten eines oder mehrerer Produktparameterwerte für das Produkt oder eines oder mehrerer Prozessparameterwerte für Prozessanlageneinheiten, die an der Herstellung des Produkts beteiligt sind; und Erzeugen der Transaktion, die den einen oder die mehreren Produktparameterwerte oder einen oder mehrere Prozessparameterwerte enthält.
154. Das System gemäß einem der Aspekte 149-153, wobei der intelligente Vertrag Geräteinformationen für ein Gerät innerhalb der Prozessanlage, das eine Störung aufweist, erhält und die Geräteinformationen einem Gerätelieferanten als Reaktion auf den Erhalt einer Anforderung zur Weitergabe der Geräteinformationen zur Verfügung stellt, und wobei die Befehle zum Erhalten von Ereignisdaten von einem Ereignis, das innerhalb einer Prozessanlage auftritt, das Computergerät zu Folgendem veranlassen: Erhalten von Geräteinformationen für das Gerät; und Erzeugen der Transaktion einschließlich der Identifizierungsinformationen für das Gerät und die Geräteinformationen.
155. Das System gemäß einem der Aspekte 149-154, wobei der intelligente Vertrag einen Parameter empfängt, der mit einem Gerät des Sicherheitssystems (SIS) verknüpft ist, und den Parameter in das SIS-Gerät schreibt, und zwar als Reaktion auf die Bestimmung, dass ein Betreiber, der den Parameter bereitgestellt hat, ein autorisierter Betreiber ist, und wobei die Befehle zum Erhalten von Ereignisdaten von einem Ereignis, das innerhalb einer Prozessanlage auftritt, das Computergerät zu Folgendem veranlassen: Erhalten einer Anforderung zum Ändern eines Parameters, der mit einem SIS-Gerät verknüpft ist; und Generieren der Transaktion einschließlich der Identifizierungsinformationen für das SIS-Gerät, des geänderten Parameters und eines neuen Parameterwerts für den geänderten Parameter.

Wenn sie in Software implementiert sind, kann jede der hier beschriebenen Anwendungen, Dienste und Engines in jedem greifbaren, nichtflüchtigen, computerlesbaren Speicher, wie z. B. auf einer Magnetplatte, einer Laserplatte, einem Festkörperspeicher, einem molekularen Speichergerät oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. gespeichert werden. Obwohl die hierin offengelegten Systembeispiele neben anderen Komponenten auch Software und/oder Firmware enthalten, die auf Hardware ausgeführt werden, ist zu beachten, dass solche Systeme lediglich der Veranschaulichung dienen und nicht als einschränkend betrachtet werden sollten. Beispielsweise wird in Betracht gezogen, dass einige oder alle dieser Hardware-, Software- und Firmwarekomponenten ausschließlich in Hardware, ausschließlich in Software oder in einer beliebigen Kombination aus Hardware und Software enthalten sein können. Dementsprechend werden die hier beschriebenen Systembeispiele zwar als in Software implementiert beschrieben, die auf einem Prozessor eines oder mehrerer Computergeräte ausgeführt wird, aber Personen mit gewöhnlichen Fachkenntnissen werden leicht verstehen, dass die angegebenen Beispiele nicht die einzige Möglichkeit sind, solche Systeme zu implementieren.
Während also die vorliegende Erfindung anhand konkreter Beispiele beschrieben wurde, die nur zur Veranschaulichung und nicht zur Beschränkung der Erfindung gedacht sind, wird es für Personen mit gewöhnlichen Fachkenntnissen offensichtlich sein, dass Änderungen, Ergänzungen oder Löschungen an den offengelegten Ausführungsformen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen.

Claims

Verfahren zum sicheren Messen von nicht vertrauenswürdigen Daten in Prozesssteuerungssystemen mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, wobei das Verfahren Folgendes umfasst: Sammeln einer Messung eines Parameters innerhalb der Prozessanlage durch ein Feldgerät, das eine physische Funktion zur Steuerung eines industriellen Prozesses in einer Prozessanlage ausführt; Erhalten der Messung des Parameters mit Hilfe eines Computergeräts; Generieren einer Transaktion einschließlich der Messung; und Übertragen der Transaktion an mindestens einen weiteren Teilnehmer in einem lokalen verteilten Ledger-Netzwerk von Teilnehmern, die ein lokales verteiltes Ledger verwalten; nach einem Schwellenwertzeitraum, Übertragung mehrerer Transaktionen, die während des Schwellenwertzeitraums generiert wurden, an mindestens einen Teilnehmer in einem globalen verteilten Ledger-Netzwerk von Teilnehmern, die ein globales verteiltes Ledger verwalten.
Verfahren nach Anspruch 1, ferner Folgendes umfassend: Hinzufügen der Transaktion zu einem lokalen Block von Transaktionen; Lösen eines kryptografischen Puzzles basierend auf dem lokalen Block von Transaktionen; Hinzufügen der Lösung zum kryptografischen Puzzle zum lokalen Block von Transaktionen; und Übertragen des lokalen Blockes von Transaktionen an mindestens einen anderen Teilnehmer in dem lokalen verteilten Ledger, und/oder nach dem Schwellenwertzeitraum, Löschen zumindest eines Teils der mehreren Transaktionen, die während des Schwellenwertzeitraums aus dem lokalen verteilten Ledger-Netzwerk generiert wurden, und/oder wobei das globale verteilte Ledger eine permissioned Blockchain ist, die von mehreren Einheiten, die mehrere Prozessanlagen betreiben, eingesehen werden kann, und/oder wobei das lokale verteilte Ledger eine private Blockchain ist, die von einer Einheit, die die Prozessanlage betreibt, eingesehen werden kann, und/oder wobei die Generierung einer Transaktion einschließlich der Messung die Generierung der Transaktion einschließlich eines kryptographischen Hash-Wertes entsprechend der Messung umfasst.
Verfahren nach Anspruch 1 oder 2, ferner Folgendes umfassend: nach dem Schwellenwertzeitraum, Übertragen eines oder mehrerer lokaler Blöcke von Transaktionen, die während des Schwellenwertzeitraums generiert wurden, an mindestens einen Teilnehmer des globalen verteilten Ledger-Netzwerkes.
Verfahren nach einem der Ansprüche 1 bis 3, insbesondere nach Anspruch 2, wobei der Parameter auf eine freigegebene Ressource zwischen den mehreren Einheiten, die mehreren Prozessanlagen betreiben, bezogen ist.
Verfahren nach einem der Ansprüche 1 bis 4, insbesondere nach Anspruch 2, wobei das globale verteilte Ledger mehrere globale verteilte Ledger enthält, die den mehreren Einheiten entsprechen, wobei jedes globale verteilte Ledger Transaktionen enthält, die in dem lokalen verteilten Ledger für eine gleiche jeweilige Einheit wie das globale verteilte Ledger gespeichert sind.
Verfahren nach einem der Ansprüche 1 bis 5, insbesondere nach Anspruch 5, ferner Folgendes umfassend: für Transaktionen, die innerhalb des Schwellenwertzeitraums generiert wurden, Hinzufügen der Transaktion aus jedem der mehreren global verteilten Ledger zu einem Status-Block von Transaktionen; Lösen eines kryptografischen Puzzles basierend auf dem Status-Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zum Status-Block von Transaktionen; und Übertragen des Status-Blocks von Transaktionen an mindestens einen anderen Teilnehmer in einem Super-Blockchain-Netzwerk von Teilnehmern, die eine Super-Blockchain verwalten.
Verfahren nach einem der Ansprüche 1 bis 6, insbesondere nach Anspruch 4, wobei die von den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, gemeinsam genutzte Ressource ein Fluid in einer Fluid-Pipeline ist, und die Parametermessung eine Fluidmenge ist, die von einer der mehreren Einheiten aus der Fluid-Pipeline erhalten wird.
Ein System zur sicheren Messung von nicht vertrauenswürdigen Daten in Prozesssteuerungssystemen mit Hilfe eines verteilten Ledgers, das von mehreren Teilnehmern verwaltet wird, Folgendes umfassend: ein oder mehrere Feldgeräte, die in einer Prozessanlage angeordnet sind und jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses ausführen, wobei das eine oder die mehreren Feldgeräte so konfiguriert sind, dass sie Messungen von Parametern innerhalb der Prozessanlage sammeln und die Parametermessungen an ein oder mehrere Edge-Gateway-Geräte übermitteln; und wobei das eine oder die mehreren Edge-Gateway-Geräte in der Prozessanlage ausgeführt werden, von denen jedes jeweils Folgendes umfasst: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges, computerlesbares Medium, das an einen oder mehrere Prozessoren und die Kommunikationseinheit gekoppelt ist und darauf Befehle speichert, die bei Ausführung durch den einen oder die mehreren Prozessoren das Edge-Gateway-Gerät zu Folgendem veranlassen: Erhalten mindestens einer der Parametermessungen; Generieren einer Transaktion einschließlich der Messung; und Übertragen der Transaktion an mindestens ein anderes Edge-Gateway in einem lokalen verteilten Ledger-Netzwerk von Edge-Gateways, die ein lokales verteiltes Ledger verwalten; und nach einem Schwellenwertzeitraum, Übertragen mehrerer Transaktionen, die während des Schwellenwertzeitraums generiert wurden, an mindestens einen Teilnehmer in einem globalen verteilten Ledger-Netzwerk von Teilnehmern, die ein globales verteiltes Ledger verwalten.
System nach Anspruch 8, wobei die Befehle ferner das Edge-Gateway zu Folgendem veranlassen: Hinzufügen der Transaktion zu einem lokalen Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem lokalen Block von Transaktionen. Hinzufügen der Lösung des kryptographischen Puzzles zum lokalen Block von Transaktionen; und Übertragen des lokalen Blocks von Transaktionen an mindestens ein anderes Edge-Gateway im lokalen verteilten Ledger-Netzwerk, und/oder nach dem Schwellenwertzeitraum, Löschen von zumindest einigen der mehreren Transaktionen, die während des Schwellenwertzeitraums aus dem lokalen verteilten Ledger-Netzwerk generiert wurden, und/oder wobei das globale verteilte Ledger eine „permissioned“ Blockchain ist, die von mehreren Einheiten, die mehrere Prozessanlagen betreiben, eingesehen werden kann und/oder wobei das lokale verteilte Ledger eine private Blockchain ist, die von einer Einheit, die die Prozessanlage betreibt, eingesehen werden kann, und/oder wobei die Transaktion einen der Messung entsprechenden kryptographischen Hash-Wert enthält.
System nach Anspruch 8 oder 9, wobei die Befehle weiterhin das Edge-Gateway zu Folgendem veranlassen: nach dem Schwellenwertzeitraum, Übertragen eines oder mehrerer lokaler Blöcke von Transaktionen, die während des Schwellenwertzeitraums generiert wurden, an mindestens einen Teilnehmer des globalen verteilten Ledger-Netzwerkes.
System nach einem der Ansprüche 8 bis 10, insbesondere nach Anspruch 9, wobei sich der Parameter auf eine von den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, gemeinsam genutzte Ressource bezieht.
System nach einem der Ansprüche 8 bis 11, insbesondere nach Anspruch 9, wobei das globale verteilte Ledger mehrere globale verteilte Ledger enthält, die den mehreren Einheiten entsprechen, wobei jedes globale verteilte Ledger Transaktionen enthält, die in dem lokalen verteilten Ledger für dieselbe jeweilige Einheit wie das globale verteilte Ledger gespeichert sind.
System nach einem der Ansprüche 8 bis 12, insbesondere nach Anspruch 12, ferner Folgendes umfassend: ein Computergerät in einem globalen verteilten Ledger-Netzwerk, das ein global verteiltes Ledger verwaltet, einschließlich: einen oder mehrere Prozessoren; eine Kommunikationseinheit; und ein nichtflüchtiges computerlesbares Medium, das mit dem einen oder mehreren Prozessoren und der Kommunikationseinheit gekoppelt ist und darauf Befehle speichert, die bei Ausführung durch den einen oder die mehreren Prozessoren das Computergerät zu Folgendem veranlassen: für Transaktionen, die während des Schwellenwertzeitraums generiert wurden, Hinzufügen der Transaktion aus jedem der mehreren global verteilten Ledger zu einem Status-Block von Transaktionen; Lösen eines kryptographischen Puzzles basierend auf dem Status-Block von Transaktionen; Hinzufügen der Lösung des kryptographischen Puzzles zum Status-Block von Transaktionen; und Übertragen des Status-Blocks von Transaktionen an mindestens einen anderen Teilnehmer in einem Super-Blockchain-Netzwerk von Teilnehmern, die eine Super-Blockchain verwalten.
System nach einem der Ansprüche 8 bis 13, insbesondere nach Anspruch 11, wobei die von den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, gemeinsam genutzte Ressource ein Fluid in einer Fluid-Pipeline ist, und die Parametermessung eine Fluidmenge ist, die von einer der mehreren Einheiten aus der Fluid-Pipeline erhalten wird.
Ein validierender Netzwerkknoten in einer Prozessanlage in einem lokalen verteilten Ledger-Netzwerk, Folgendes umfassend: einen Sender-Empfänger, der so konfiguriert ist, dass er (i) mit einem oder mehreren Feldgeräten kommuniziert, die jeweils eine physische Funktion zur Steuerung eines industriellen Prozesses in der Prozessanlage ausführen und Messungen von Parametern innerhalb der Prozessanlage sammeln, und (ii) lokale verteilte Ledger-Daten mit Peer-Netzwerkknoten austauscht, wobei die lokalen verteilten Ledger-Daten Transaktionen mit Parametermessungen umfassen; ein Speichermedium, das zum Speichern einer Kopie des lokalen verteilten Ledgers konfiguriert ist; und einen Prozessdaten-Validierer, der so konfiguriert ist, dass er einen Satz von Konsens-Regeln auf die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers anwendet, wobei der Prozessdaten-Validierer ferner so konfiguriert ist, dass er die von den Peer-Netzwerkknoten empfangenen Daten des verteilten Ledgers an die Kopie des verteilten Ledgers anhängt, wenn die Daten des verteilten Ledgers die Konsens-Regeln erfüllen, wobei der Sender-Empfänger nach einem Schwellenwertzeitraum so konfiguriert ist, dass er mehrere Transaktionen, die während des Schwellenwertzeitraums generiert wurden, an mindestens einen Teilnehmer in einem globalen verteilten Ledger-Netzwerk von Teilnehmern, die ein globales verteiltes Ledger verwalten, überträgt.
Der validierende Netzwerkknoten nach Anspruch 15, wobei der validierende Netzwerkknoten nach dem Schwellenwertzeitraum so konfiguriert ist, dass er zumindest einige der mehreren Transaktionen, die während des Schwellenwertzeitraums erzeugt wurden, aus der Kopie des lokalen verteilten Ledgers löscht, und/oder wobei das globale verteilte Ledger eine permissioned Blockchain ist, die von mehreren Einheiten, die mehrere Prozessanlagen betreiben, eingesehen werden kann, und/oder wobei das lokale verteilte Ledger eine private Blockchain ist, die von einer Einheit, die die Prozessanlage betreibt, eingesehen werden kann, und/oder wobei eine Transaktion einen kryptographischen Hash-Wert enthält, der einer Parametermessung entspricht.
Der validierende Netzwerkknoten nach Anspruch 15 oder 16, wobei mindestens einer der Parameter sich auf eine von den mehreren Einheiten, die die mehreren Prozessanlagen betreiben, gemeinsam genutzte Ressource bezieht, und/oder wobei das globale verteilte Ledger mehrere globale verteilte Ledger enthält, die den mehreren Einheiten entsprechen, wobei jedes globale verteilte Ledger Transaktionen umfasst, die in dem lokalen verteilten Ledger für dieselbe jeweilige Einheit wie das globale verteilte Ledger gespeichert sind.
Computerlesbares Speichermedium, welches Instruktionen enthält, um mindestens einen Prozessor zu veranlassen ein Verfahren nach einem der Ansprüche 1 bis 7 zu implementieren.