Liberare il Potenziale dei Big Data nell'Oil and Gas

Il problema del diluvio di dati che nessuno aveva previsto

Una moderna piattaforma offshore genera letture di sensori, log di allarmi, segnali sullo stato delle apparecchiature e voci dello storico di processo a una velocità che sarebbe stata inimmaginabile quando l'impianto è stato progettato. Il sistema di controllo distribuito (DCS) e il sistema strumentato di sicurezza (SIS) sono stati progettati per agire su tali dati in tempo reale, ma nessuno ha specificato compiutamente cosa fare con l'archivio accumulato. Il risultato è familiare alla maggior parte dei team operativi: terabyte di dati dello storico fermi sui server, interrogati occasionalmente dopo un incidente, altrimenti ignorati. Nel frattempo, .

Questo articolo affronta il modo in cui i team di operazioni, manutenzione e ingegneria possono costruire una capacità pratica di big data senza fare promesse eccessive al management o fornire risultati insufficienti sul campo.

Cosa significano effettivamente i "Big Data" in questo contesto

Il termine è abusato, ma la definizione ingegneristica è sufficientemente precisa per essere utile: i big data nell'oil and gas si riferiscono a set di dati troppo grandi, che arrivano troppo velocemente o troppo vari strutturalmente per essere gestiti dai database relazionali convenzionali e dai flussi di lavoro di analisi manuale.

In pratica, ciò significa:

• Volume: anni di dati ad alta frequenza dello storico di processo attraverso centinaia di tag per asset
• Velocity: streaming in tempo reale da sistemi di monitoraggio delle condizioni, misuratori di portata multifase e moduli di controllo sottomarini
• Variety: strutturati (tag SCADA), semi-strutturati (ordini di lavoro di manutenzione nel CMMS) e non strutturati (rapporti di ispezione, log di pozzo, log degli operatori in testo libero)

Il valore operativo non risiede nei dati stessi. Risiede nelle decisioni che i dati abilitano: rilevamento precoce del degrado, migliore pianificazione della manutenzione programmata e riduzione dei tassi di falsi allarmi che causano l'affaticamento da allarme e desensibilizzano gli operatori in sala controllo.

Standard e contesto normativo

Prima di implementare qualsiasi livello di analisi che riguardi decisioni critiche per la sicurezza, il team deve comprendere dove risiede il confine tra i sistemi consultivi e le funzioni di sicurezza.

La norma IEC 61511 (Sicurezza funzionale — Sistemi strumentati di sicurezza per il settore dell'industria di processo) è inequivocabile: una funzione strumentata di sicurezza (SIF) deve essere progettata, validata e mantenuta all'interno di un ciclo di vita della sicurezza definito. Un modello analitico che gira sui dati dello storico non è una SIF. Se l'output di un modello di machine learning viene utilizzato per attivare un'azione di processo, quel percorso d'azione deve essere valutato nell'ambito del ciclo di vita della sicurezza IEC 61511 — non può essere bypassato.

L'ISA-TR84.00.02 fornisce una guida supplementare sull'assegnazione e la gestione del SIL. Quando i team discutono se un avviso predittivo debba essere cablato nella logica del SIS o gestito come un livello consultivo separato, la decisione deve basarsi sulla valutazione del ciclo di vita della sicurezza funzionale IEC 61511, non solo sull'ISA-TR84.00.02. La risposta generale è: tenerli separati a meno che non sia stata completata una valutazione formale del ciclo di vita della sicurezza.

Per le macchine rotanti, l'API 670 (Machinery Protection Systems) fornisce le pratiche raccomandate per il monitoraggio di vibrazioni, posizione e temperatura su macchine critiche. Qualsiasi iniziativa di big data che acquisisce dati di vibrazione da sistemi conformi a API 670 deve rispettare il primato del sistema di protezione cablato — l'analisi è un complemento, non un sostituto. Qualsiasi iniziativa di big data che acquisisce dati di vibrazione da sistemi conformi a API 670 deve rispettare il primato del sistema di protezione cablato — l'analisi è un complemento, non un sostituto.

Laddove il monitoraggio dell'integrità delle condotte sia in ambito, l'ASME B31.8S (Managing System Integrity of Gas Pipelines) fornisce un quadro per la valutazione basata sul rischio e la gestione dell'integrità che può informare la progettazione delle strategie di raccolta e analisi dei dati per i programmi di big data delle condotte.

Architettura pratica per l'implementazione sul campo

Livello di acquisizione dati

La base è una raccolta affidabile dei tag. Prima di investire in infrastrutture cloud o piattaforme di analisi avanzata, è necessario verificare lo storico esistente — OSIsoft PI e sistemi simili sono comuni — per completezza dei tag, coerenza della frequenza di scansione e impostazioni di compressione. Una compressione aggressiva del reporting delle eccezioni può distruggere la qualità del segnale necessaria per il trending delle vibrazioni o il rilevamento precoce del fouling. Verificare che i tag critici vengano memorizzati a una frequenza di scansione appropriata al processo fisico monitorato.

Per gli asset privi di strumentazione esistente, le reti di sensori wireless (che utilizzano i protocolli ISA-100.11a o WirelessHART) possono estendere la copertura a posizioni in cui il cablaggio non è pratico. Confermare la certificazione di sicurezza intrinseca e la classificazione dell'area classificata prima dell'installazione, in linea con i requisiti IEC 60079.

Contestualizzazione dei dati

I valori grezzi dei tag senza contesto producono modelli fuorvianti. Una lettura della pressione di scarico di una pompa significa cose diverse durante l'avvio, il funzionamento a regime e una variazione di portata pianificata. Come minimo, ogni set di dati dovrebbe essere taggato con:

• Modalità operativa (dallo stato del DCS o annotazione manuale)
• Eventi di manutenzione (dal CMMS, inclusi tipo di ordine di lavoro e data)
• Tasso di produzione e composizione del fluido, ove disponibili

Senza questo contesto, un modello di machine learning addestrato su modalità operative miste genererà falsi positivi durante ogni variazione di portata — esattamente il tipo di affaticamento da allarme che porta gli operatori a diffidare del sistema.

Livelli di analisi

Un programma pratico lavora per livelli, dal semplice al complesso:

La maggior parte degli impianti dovrebbe iniziare dal Livello 1 e dal Livello 2. Il motivo non è il conservatorismo tecnico, ma la qualità dei dati. L'implementazione del rilevamento delle anomalie di Livello 4 su dati scarsamente contestualizzati produce rumore, non intuizioni.

Apparecchiature rotanti: un esempio pratico (illustrativo)

Lo scenario seguente è illustrativo e non rappresenta un impianto specifico o un incidente documentato.

Si consideri un treno di compressione gas su una piattaforma offshore. Il sistema di protezione conforme a API 670 gestisce i trip cablati su alta vibrazione e alta temperatura dei cuscinetti. Il team operativo desidera un avviso più tempestivo rispetto a quanto fornito dai setpoint di trip, per consentire un intervento pianificato durante una finestra di manutenzione programmata piuttosto che una fermata di emergenza.

Il team estrae due anni di dati dallo storico: vibrazioni (globali e spettrali ove disponibili), temperature dei cuscinetti, pressioni di aspirazione e scarico, portata e pressione differenziale dell'olio lubrificante. Annotano il set di dati con i record del CMMS che identificano le sostituzioni dei cuscinetti e i cambi delle tenute.

Viene costruito innanzitutto un modello di prestazioni basato sulla fisica: utilizzando la curva prevalenza-portata fornita dall'OEM, i punti operativi effettivi vengono confrontati con la curva di progetto in ogni fase temporale. La deviazione sostenuta dalla curva prevista — dopo la correzione per la composizione del gas e le condizioni di ingresso — viene utilizzata come indicatore precoce di usura interna o fouling.

Parallelamente, viene stabilito un semplice trend della pressione differenziale dell'olio lubrificante rispetto a una baseline di messa in servizio. Il team di ingegneria concorda sul fatto che qualsiasi deriva verso l'alto sostenuta rispetto alla baseline di messa in servizio, che persista attraverso più turni operativi e non sia spiegata da un cambio di filtro, giustifichi una revisione dell'ordine di lavoro. Nessun valore di soglia specifico è inserito nella logica di allerta; l'allerta è consultiva e viene esaminata dall'ingegnere delle macchine rotanti prima che venga intrapresa qualsiasi azione.

Questo approccio a due livelli — monitoraggio delle prestazioni basato sulla fisica più monitoraggio semplice dei trend — è realizzabile con gli strumenti standard dello storico, non richiede un data scientist e mantiene intatto il confine di sicurezza con il sistema di protezione cablato.

Checklist di Implementazione

Utilizzare questa checklist prima di impegnare il budget in un programma big data:

Prontezza dei Dati

• [ ] Elenco tag dell'historian verificato per completezza rispetto ai P&IDs
• [ ] Impostazioni di compressione e frequenza di scansione verificate per i tag critici
• [ ] Dati CMMS accessibili e collegabili ai timestamp dell'historian
• [ ] Stati delle modalità operative acquisiti nell'historian o derivabili dalla logica dei tag

Governance e Confini di Sicurezza

• [ ] Output analitici classificati come consultivi (non SIF) a meno che non sia stato completato il ciclo di vita della sicurezza formale secondo IEC 61511
• [ ] Percorso di escalation chiaro definito: chi agisce su un allerta, entro quali tempi, con quale autorità
• [ ] Revisione della gestione degli allarmi completata per evitare di aumentare il carico di allarmi esistente (la EEMUA Publication 191 è la guida industriale riconosciuta per la razionalizzazione degli allarmi)

Validazione dei Modelli

• [ ] Modelli basati sulla fisica validati rispetto ai dati di commissioning o alle curve di prestazione OEM
• [ ] Modelli di machine learning (se utilizzati) testati su un set di dati riservato prima dell'implementazione live
• [ ] Tasso di falsi positivi valutato durante un periodo di prova definito prima del roll-out operativo

Integrazione con Campo e Manutenzione

• [ ] Responsabili della manutenzione formati su come interpretare e agire sugli allerta
• [ ] Ciclo di feedback stabilito: i risultati sul campo derivanti dagli ordini di lavoro vengono riportati per migliorare i modelli
• [ ] Ciclo di revisione programmato (almeno annualmente) per riaddestrare o ricalibrare i modelli con l'invecchiamento delle apparecchiature

Conclusione e Prossimi Passi

La barriera per estrarre valore dai big data nel settore oil & gas raramente è la tecnologia. È la qualità dei dati, il contesto e la disciplina di iniziare in modo semplice.

La sequenza raccomandata per la maggior parte dei team operativi è:

1. Controllare e rimediare alla qualità dei dati dell'historian prima di qualsiasi investimento in analisi
2. Implementare analisi di Livello 1 e Livello 2 sulle due o tre classi di apparecchiature responsabili della maggior parte dei fermi non pianificati nell'impianto
3. Stabilire un ciclo di feedback formale tra gli allerta analitici e gli esiti degli ordini di lavoro CMMS
4. Progredire verso metodi di machine learning solo quando esistono sufficienti dati di guasto etichettati e i livelli più semplici hanno dimostrato valore

Mantenere chiaro il confine di sicurezza: l'analitica è consultiva. Qualsiasi percorso da un output analitico a un'azione di processo deve passare attraverso una decisione umana o un ciclo di vita della sicurezza formalmente valutato. Tale disciplina protegge sia l'impianto che la credibilità del programma.