Ogni progetto di automazione, che si tratti di un impianto grass-root, di un revamping di sistemi esistenti o di semplice automazione a bordo macchina, ha una chiave di successo imprescindibile: la corretta organizzazione, impostazione, gestione e verifica della documentazione di progetto.

Questa chiave può ‘aprire’ la porta ad flusso di lavoro lineare e semplificato che guida il progetto non solo nella fase di design, ma anche in quelle di procurement, construction, commissioning e change control. Le GAMP (Good Automated Manufacturing Practices) sono in tal senso il faro di riferimento non solo laddove abitualmente applicate come in ambito farmaceutico, ma anche in ambiti diversamente regolati come quello petrolchimico. Quando non si scrive in modo sufficientemente preciso ciò che si vuole, non si dice come lo si vuole realizzare, non si identificano ruoli, responsabilità e carichi di lavoro, non si indicano chiari orizzonti temporali e scadenze e non si stabiliscono criteri di verifica di ciò che si è implementato univoci e non interpretabili, si aprono aree di rischio che portano sempre a costi non pianificati e ritardi anche importanti.

Quante volte vi è capitato di dover affrontare un progetto di automazione partendo da specifiche scritte sulla “carta del formaggio” o trasmesse a voce dal classico tecnico molto esperto che è in impianto da anni e conosce tutti i risvolti e i dettagli del processo ma non ha alcuno strumento per renderli condivisi e condivisibili? A noi di Italia Automazione è capitato e quando questo è successo ha sempre significato un impatto netto e quantificabile sulle tempistiche sia di design che di commissioning e startup. Cosa abbiamo imparato da queste esperienze? Una cosa molto semplice: che non si può verificare ciò che non si è ADEGUATAMENTE documentato. Per questo serve un metodo chiaro e consolidato per la gestione del flusso di lavoro che proprio sulla documentazione faccia leva per garantire che il sistema di automazione finale faccia ciò che ci si aspetta e rispetti le performance attese.

Il ciclo di vita di un nuovo sistema di automazione parte con la stesura della specifica dei requisiti utente (URS), documento fondamentale sviluppato dall’end-user (non dalla società di ingegneria e neppure dal system integrator!) ed orientato alla comprensione chiara e
precisa del prodotto/processo includendo ove possibile indicazione dei CQA (Critical Quality Attributes) o comunque dei parametri di performance attese. L’estensione ed il dettaglio dei requisiti dovranno essere commisurati ai rischi ed alla complessità del processo e dovranno essere sufficienti per le successive fasi di analisi dei rischi, specifica, configurazione/sviluppo e verifica del sistema.
Sulla base delle URS verrà sviluppato (tipicamente dalla società di ingegneria o direttamente dal system integrator) il documento di Specifica Funzionale (FS) che dovrà definire cosa ci si aspetta che il sistema faccia e quali funzioni devono essere previste. E’ buona pratica far si che le FS traccino in modo chiaro e sistematico i requisiti utente definiti nelle URS e che documentino in modo esplicito tutti i vincoli di design evitando ambiguità, duplicazione di informazioni, contraddizioni. L’utilizzo di naming convention consistenti, la definizione chiara delle interfacce interne ed esterne, l’indicazione dei limiti di configurazione e delle modalità di gestione delle eccezioni, errori, guasti e l’applicazione di modalità descrittive chiare e non interpretabili, aiuteranno il riutilizzo efficace di tale documento nella fase di verifica del sistema.
A questo punto potrà essere sviluppato (tipicamente dal system integrator) il documento di Specifica di Design (DS) che dovrà definire in modo non abiguo, chiaro e preciso come è stato implementato quanto indicato in FS. La DS può essere talvolta suddivisa in due documenti distinti di Specifica di Design Hardware (HDS) e Specifica di Design Software (SDS). Lo scopo di tale documento è quello di dettagliare i componenti Hardware del sistema, definire ad alto livello i moduli che compongono il Software del sistema, definire le interfacce tra i vari moduli e con i sistemi esterni, definire nel dettaglio le operazioni svolte dai singoli moduli software ed indicare le configurazioni di tutti i parametri e settaggi.