Uno skid può superare la dimostrazione in fabbrica e risultare comunque inadatto al sito produttivo. Il controllore esegue la sequenza, ma un'interruzione di rete lascia incompleto il record di lotto; un operatore modifica un parametro senza una motivazione tracciabile; un server sostitutivo non ripristina la ricetta approvata. Sono carenze dei requisiti prima di diventare rilievi di validazione. La specifica dei requisiti utente, o URS, deve descrivere il risultato produttivo, le condizioni nelle quali deve restare affidabile e le evidenze necessarie per accettarlo.
Questo articolo riguarda la URS ingegneristica di PLC, DCS, SCADA, historian, MES e relative interfacce. Aiuta processo, produzione, automazione, qualità e IT/OT a concordare ciò che il sistema deve realizzare prima che il fornitore definisca il progetto. Architettura e strategia di validazione devono essere adeguate allo specifico impiego.
Partire dall'uso previsto e dal perimetro dell'automazione
Descrivere famiglie di prodotti, fasi di processo, modalità operative e decisioni supportate. Un controllore che regola la temperatura di un recipiente ha un uso previsto diverso da un historian utilizzato per indagare le escursioni, anche se entrambi trattano la stessa misura. Stabilire se una funzione controlla il processo, informa l'operatore, genera un record richiesto, autorizza un'attività o trasferisce informazioni. Queste finalità determinano controlli ed evidenze di accettazione.
Separare il perimetro fisico da quello logico. Il primo comprende strumenti, I/O remoti, controllori, postazioni, server, rete e infrastruttura. Il secondo comprende ricette, calcoli, autorizzazioni, interfacce, trasformazioni dei dati e responsabilità. Un servizio esterno di gestione delle identità può essere escluso dalla fornitura e restare comunque una dipendenza del sistema qualificato. Indicare chi lo fornisce, configura, verifica e mantiene.
Assegnare un responsabile anche alle esclusioni. «Integrazione MES esclusa» è insufficiente se lo skid non può completare l'operazione senza una risposta MES. Definire il comportamento autorizzato prima dell'interfaccia e le condizioni per introdurla successivamente.
Distinguere risultati richiesti e scelte progettuali
Un requisito deve esprimere il bisogno senza trasformare una preferenza non valutata in un obbligo. «Utilizzare server ridondanti» indica una soluzione. «Mantenere le funzioni di supervisione definite durante il guasto individuato di un server, preservando i record di lotto confermati» descrive un risultato analizzabile. La ridondanza può essere appropriata, ma richiede una giustificazione del perimetro, del failover e dei guasti residui.
Alcuni vincoli tecnici sono legittimi: piattaforma supportata dal sito, architettura di rete approvata, protocollo esistente o competenze manutentive disponibili. Identificarli come vincoli e motivarne l'origine. Separare requisiti obbligatori, preferenze e opzioni future, evitando che funzioni desiderabili oscurino dipendenze critiche.
Attribuire a ogni requisito un identificativo stabile, un responsabile e un percorso di accettazione. Evitare obblighi eterogenei nella stessa frase. Accessi, backup, firme elettroniche e allarmi non possono essere accettati con un'unica risposta «conforme» priva di evidenze.
Definire controllo e funzionamento anomalo
Specificare variabili controllate, uscite, intervalli operativi, stati e transizioni. La URS non deve contenere ogni istruzione PLC, ma deve chiarire avvio, pausa, hold, arresto, interruzione, ripresa e conclusione delle sequenze. Definire disponibilità delle apparecchiature e riconciliazione delle operazioni interrotte. Indicare chi può richiedere ogni transizione e quali condizioni il controllore deve confermare.
Distinguere permissivo, interblocco e allarme: il primo consente un'azione, il secondo la impedisce o modifica, il terzo richiede una risposta dell'operatore. Un allarme non costituisce automaticamente una funzione protettiva. Analogamente, una conferma HMI non dimostra che una valvola si sia mossa. Per i comandi critici definire feedback, gestione delle discrepanze ed evidenza dell'esito reale.
Progettare esplicitamente modalità manuali e degradate, protezioni mantenute, funzioni limitate e controlli operativi aggiuntivi. Passare sempre in manuale dopo una perdita di comunicazione è un'ipotesi inadeguata: la risposta dipende da stato, apparecchiatura e pericoli. Valutare separatamente perdita di alimentazione, qualità del segnale, comunicazioni e servizi di supporto.
Assegnare ricette, parametri e approvazioni
Separare la ricetta master approvata dalla ricetta di controllo istanziata per il lotto. Una formula o un insieme di parametri fornisce valori, ma non rappresenta necessariamente l'intera ricetta, che comprende anche requisiti procedurali e di apparecchiatura. Stabilire dove ciascun elemento viene redatto, approvato, trasferito ed eseguito. MES può coordinare il flusso mentre il controllore esegue le fasi, purché l'assegnazione sia esplicita.
Definire intervalli ammessi, autorità di modifica, versione applicabile e trattamento dei lotti in corso. Prevedere ricette incomplete, incompatibili con la configurazione o precedenti alla versione approvata. Chiarire quando occorrono nuova approvazione, nuova istanza di lotto o gestione documentata dell'eccezione. I valori devono derivare dal processo e dalla strategia approvata, non dai valori predefiniti della libreria del fornitore.
Nelle applicazioni CIP e SIP, distinguere l'esecuzione del ciclo dall'evidenza del soddisfacimento dei criteri di accettazione. Una sequenza completata non dimostra, da sola, l'efficacia della pulizia o della sterilizzazione.
Identificare i record prima di scegliere l'archiviazione
Creare un inventario che colleghi ogni classe di dati al suo impiego e responsabile: misure originali, indicatori di qualità, timestamp, unità, identificativi di lotto, versioni delle ricette, azioni, eccezioni, calcoli e decisioni di revisione. Un valore visualizzato può essere transitorio; un record GMP richiede il contesto necessario a ricostruire l'attività. Stabilire quale sistema conserva il record autorevole e come identificare le copie.
Specificare acquisizione e compressione dell'historian secondo gli eventi da ricostruire. Una rapida esecuzione del controllore non garantisce analoga risoluzione storica. Valutare se acquisizione, aggregazione o deadband possano nascondere un'escursione breve o un cambio di stato. Definire dati mancanti, ritardati, invalidi e recuperati successivamente. Frequenza di campionamento e durata di conservazione richiedono una giustificazione specifica.
Distinguere audit trail, registro eventi e registro allarmi. Identificare modifiche e cancellazioni rilevanti, identità associata, cronologia, motivazione quando richiesta, accesso alla revisione ed esportazione. «Audit trail abilitato» non dimostra una copertura adeguata di approvazioni, configurazioni e attività privilegiate.
Rendere le interfacce responsabili della transazione
Per ogni interfaccia documentare responsabili di invio e ricezione, identificativi, significato dei campi, unità, regole di versione, timestamp e stati della transazione. Una conferma di rete può indicare la consegna a un servizio senza dimostrare che l'applicazione abbia accettato un consumo di materiale, un'istruzione di lotto o un risultato. Definire la conferma applicativa e la risposta a esiti assenti o negativi.
Progettare insieme tentativi successivi e gestione dei duplicati. Dopo un guasto il mittente potrebbe ignorare se il primo messaggio sia stato applicato. Ripeterlo senza un'identità stabile può duplicare un consumo o avviare un'operazione indesiderata. Definire riconciliazione di omissioni, duplicati e stati conflittuali, con autorizzazioni alla risoluzione. Verificare il recupero lungo l'intero percorso apparecchiatura–supervisione–esecuzione.
OPC UA, API e middleware sono opzioni implementative. Il supporto di un protocollo standard non dimostra la correttezza del significato dei dati. Specificare contratto informativo e configurazione di sicurezza.
Costruire la matrice requisito–evidenza
Gli esempi originali seguenti illustrano la struttura. Condizioni operative e criteri devono essere sostituiti con quelli del processo approvato e della relativa valutazione del rischio.
| Requisito | Motivazione | Impatto GMP | Rischio | Criterio di accettazione | Verifica | Evidenza |
|---|---|---|---|---|---|---|
| Usare la versione approvata della ricetta | Prevenire parametri indesiderati | Coerenza del processo | Esecuzione di una versione obsoleta | Avvio consentito soltanto a una versione approvata idonea; versione eseguita collegata al lotto | Provare versioni approvate, obsolete e incompatibili | Configurazione, record di esecuzione ed esiti delle eccezioni |
| Preservare l'identità della transazione durante il retry | Evitare applicazioni duplicate | Genealogia di materiali e lotti | Messaggio ripetuto modifica due volte la quantità | La consegna ripetuta produce un solo effetto previsto; conflitti visibili per la riconciliazione | Interrompere la risposta dopo la conferma interna del ricevente | Record dei due sistemi ed esito della riconciliazione |
| Recuperare il record di lotto definito | Mantenere la ricostruibilità | Revisione e conservazione | Applicazione ripristinata senza metadati | Il recupero approvato restituisce record leggibili, completi e correttamente associati | Ripristinare nell'ambiente autorizzato | Registro di recupero, confronto e accettazione del revisore |
La matrice è utile quando rimanda a evidenze reali. Distinguere revisione, ispezione, analisi e test. Se una prova supporta più requisiti, spiegarne la copertura evitando script duplicati. Mantenere visibili i requisiti non verificati durante la decisione di rilascio.
Specificare insieme accessi, cronologia e sicurezza OT
Definire ruoli dalle attività: conduzione, redazione e approvazione delle ricette, manutenzione, amministrazione e revisione. Individuare privilegi incompatibili e accessi di emergenza controllati. L'accesso remoto del fornitore richiede richiesta, autorizzazione, connessione, supervisione quando appropriata, registrazione e chiusura. Un integratore con privilegi di configurazione non può essere trattato come un normale operatore.
Descrivere sorgente temporale, dipendenze di sincronizzazione, rappresentazione dei fusi e comportamento alla perdita di sincronismo. Distinguere momento dell'evento e momento di ricezione, preservando tale distinzione durante buffering e recupero.
Usare inventario OT e valutazione del rischio per definire segmentazione, comunicazioni consentite, configurazione sicura, valutazione delle patch e recupero. I controlli IT devono rispettare disponibilità del processo e limiti dell'apparecchiatura. Lo stato di validazione non giustifica una vulnerabilità lasciata senza gestione.
Definire disponibilità, recupero e passaggio alla gestione
La disponibilità riguarda la continuità del servizio; il recupero riguarda il ripristino dopo un'interruzione. L'hardware ridondante non dimostra automaticamente nessuno dei due. Individuare dipendenze comuni: alimentazione, storage, autenticazione e rete. Valutare se la perdita di ogni servizio consenta di continuare, mantenere un hold controllato o richieda l'arresto.
Separare backup, archivio e disaster recovery. Il backup supporta il ripristino; l'archivio preserva record consultabili; il disaster recovery coordina applicazioni, infrastrutture, dati, persone e riavvio. Derivare tempi di recupero e perdita dati accettabile dalle esigenze di processo e continuità. Includere configurazioni, certificati, licenze, ricette e dipendenze.
Richiedere una consegna manutenibile: sorgenti e configurazioni approvati, strumenti di engineering, confini del supporto, versioni supportate, obsolescenza, ricambi e procedure di modifica. Definire evidenze di ripristino e aggiornamento prima che il gruppo di progetto venga sciolto.
Impostare assurance e accettazione proporzionate
[REQUISITO NORMATIVO] Per le attività soggette a EU GMP, Annex 11 collega i requisiti utente a impatto GMP, rischio documentato e tracciabilità nel ciclo di vita. Annex 15 tratta qualificazione e validazione. Tradurre gli obblighi in evidenze pertinenti, senza assumere un numero prestabilito di documenti. I testi operativi restano distinti dalle proposte in consultazione del 2025, secondo la verifica del 23 settembre 2026.
[LINEA GUIDA] GAMP 5, seconda edizione, supporta un approccio basato sul rischio. La guidance FDA CSA finale di febbraio 2026 riguarda software di produzione e sistemi di gestione della qualità dei dispositivi medici; non sostituisce universalmente la CSV farmaceutica. [STANDARD] ASTM E2500-25 propone un quadro di verifica dei sistemi produttivi fondato su scienza e rischio. Motivare l'applicazione dei metodi senza presentarli come legislazione.
[RACCOMANDAZIONE GUIDEGXP] Concordare prima dell'acquisto quali evidenze del fornitore siano riutilizzabili, a quali condizioni e quali lacune restino al sito. FAT può dimostrare funzioni configurate; SAT può verificare installazione e interfacce. La denominazione non basta a stabilire la qualificazione. Il rilascio deve identificare configurazione accettata, difetti risolti, rischi residui giustificati, responsabili formati e disposizione delle azioni aperte.
Rivedere la URS attraverso un guasto realistico
Considerare un recipiente batch il cui controllore continui a funzionare durante la perdita di connessione all'historian. Produzione richiede continuità, qualità necessita di evidenze complete e IT propone tentativi automatici. Seguire l'interruzione dalla misura alla revisione finale: dati bufferizzati, capacità disponibile, timestamp e qualità conservati, risposta all'esaurimento del buffer e riconciliazione del recupero.
Il risultato utile consiste in requisiti e scenari di accettazione collegati. «Nessuna perdita dati» lascia troppe decisioni aperte. Valutare se siano giustificati arresto, prosecuzione con registrazioni alternative approvate o hold in uno stato definito. La decisione compete al sito attraverso conoscenza del processo e valutazione del rischio, con il contributo del fornitore.
- Ogni requisito critico risponde a un bisogno produttivo o documentale?
- Sono definiti comportamenti normali, anomali, manuali e di recupero?
- Le interfacce confermano la transazione prevista?
- Il sito può ottenere, rivedere, ripristinare e conservare le evidenze?
- Responsabilità, accettazione e supporto sono inequivocabili?
Le aree decisionali Automation & Digital Systems sviluppano architettura e assurance. La URS è pronta per l'approvazione quando il gruppo sa spiegare il risultato richiesto e come dimostrarne il raggiungimento.
Riferimenti e stato
- Commissione europea, EudraLex Volume 4: Annex 11, Chapter 4 e Annex 15 vigenti.
- Consultazione europea 2025: proposte distinte dai requisiti vigenti.
- ISPE GAMP 5, seconda edizione, luglio 2022: guida di settore.
- FDA CSA, febbraio 2026: versione finale, ambito dispositivi medici.
- ASTM E2500-25: standard attivo; ambito verificato sul sito dell'editore.
- NIST SP 800-82r3: guidance OT finale; revisione 4 ancora in bozza.
