Öl und Gas
Raffinerien, Verarbeitungsanlagen, Pipelines und Offshore-Plattformen generieren kontinuierlich Betriebs- und Inspektionsdaten, die von Wartungs- und Zuverlässigkeitsteams schnell interpretiert werden müssen, ohne dass diese Interpretation jemals Autorität über die Prozesssteuerung erlangt. Auf dieser Seite wird dargelegt, wie ein solcher Arbeitsablauf auf inTheEU Assist geplant und ausgeführt werden würde, und es handelt sich nicht um eine Aufzeichnung einer abgeschlossenen Bereitstellung.
Wie der Arbeitsablauf strukturiert sein würde
Prozess- und Inspektionsdaten, Kompressortelemetrie, Pipeline-Überwachung und Wartungsaufzeichnungen würden vor Ort erfasst und indiziert und als Wissenspaket für den eigenen Mandanten des Betreibers bereitgestellt. Ein für den Workflow konfigurierter Agent vergleicht aktuelle Messwerte mit der genehmigten Betriebshistorie und schlägt mögliche Anomalien vor, die jeweils an eine bestimmte Anlage gebunden sind und mit dem Status „Vorgeschlagen“ eingegeben werden. Eine Empfehlung zur Eskalation, beispielsweise eine gezielte Inspektion oder ein Wartungsauftrag, würde demselben Weg vom Vorschlag bis zur Genehmigung folgen.
Vorhandene Betriebstechnik, Prozesssteuerung, sicherheitstechnische Systeme und Notabschaltlogik blieben gänzlich außerhalb dieses Arbeitsablaufs. Die Plattform würde niemals die Autorität über diese Systeme besitzen, anfordern oder ausführen.
Wo menschliche Zustimmung sitzt
Jede Anomalie-Meldung oder Eskalationsempfehlung bedarf der ausdrücklichen Genehmigung eines benannten Ingenieurs, bevor sie als festgestellt gilt oder umgesetzt wird. Dabei handelt es sich nicht um eine Richtlinie, die über dem Workflow liegt. Es ist der Mechanismus, durch den der Workflow überhaupt abläuft: Eine nicht genehmigte Phase führt den nächsten Schritt einfach nicht aus.
Worauf sich das heute stützt und worauf nicht
Der Workflow zur Kennzeichnung von Anomalien, der Lebenszyklus von der vorgeschlagenen bis zur genehmigten Überprüfung und die unterzeichnete Prüfkette hinter jeder Aktion sind funktionierende Teile der Plattform. Was noch nicht Teil davon ist: ein anlagenspezifisches Modell, das auf den eigenen Prozessdaten eines bestimmten Betreibers trainiert wird, was genau das ist, was ein erster Pilot erstellen würde. Bestehende sicherheitstechnische Systeme und Prozesssteuerung bleiben konstruktionsbedingt vollständig außerhalb des Anwendungsbereichs der Plattform. Die Domänenbeurteilung bei einem Öl- und Gaseinsatz würde durchgehend bei den Ingenieuren des Betreibers verbleiben, und alle anlagenspezifischen Analysefähigkeiten würden zusammen mit ihnen entwickelt und nicht als Standardmodell bereitgestellt.
Ein Teil der diesem Funktionsumfang zugrunde liegenden Architektur ist in noch laufenden Einreichungen dokumentiert. Auf dieser Seite wird beschrieben, wofür die Plattform konzipiert ist, und zwar auf einer Ebene, die für die Planung eines Pilotprojekts geeignet ist, und nicht als Implementierungsspezifikation.
Plattformfunktionen und Benutzeroberfläche unterliegen einer kontinuierlichen Verbesserung. Die Beschreibungen in diesem Handbuch spiegeln möglicherweise nicht das genaue Layout oder den Wortlaut der neuesten veröffentlichten Version wider.