C’è una domanda che ogni ingegnere di automazione si è posto almeno una volta davanti a un progetto batch: “Da dove si comincia?”
La risposta, spesso sottovalutata, è dalla Functional Specification (FS). Non dalla programmazione, non dall’hardware — dalla documentazione. E quando il processo segue lo standard ISA-88, scrivere una Functional Specification S88-aware non è solo buona pratica: è la differenza tra un progetto fluido e uno che accumula debito tecnico fin dal primo giorno.
In questa guida spieghiamo cos’è una Functional Specification per un sistema batch S88, come strutturarla, quali sono gli errori più comuni e come sfruttarla come leva di efficienza progettuale.

Cos’è una Functional Specification per un progetto S88

La Functional Specification (FS) definisce cosa il sistema di automazione deve fare, non come farlo. È il documento ponte tra i requisiti utente (URS — User Requirement Specification) e il design tecnico vero e proprio.
Gli input di una FS S88 sono:
– Process Description: descrizione narrativa del processo produttivo
– P&ID (Piping & Instrumentation Diagram): schema delle apparecchiature e degli strumenti
– PFD (Process Flow Diagram): flusso del processo
– Instrument List: lista degli strumenti di misura e controllo
Il suo output è un documento approvato da tutte le discipline coinvolte — processo, automazione, qualità — che costituisce la base contrattuale per la progettazione e la validazione del sistema.

Functional Specification e GAMP: il ruolo nella validazione

In ambito regolamentato (pharma, biotech), la Functional Specification si inserisce nel ciclo di vita GAMP5 (Good Automated Manufacturing Practice) come documento di livello Design Specification. Viene referenziata nelle attività di Operational Qualification (OQ) ed è il documento su cui si basano i test di accettazione in fabbrica (FAT) e in sito (SAT).
Questo significa che una FS S88 mal strutturata non è solo un problema di engineering: è un rischio di validazione con impatto diretto sui tempi di startup e sui costi di compliance.

Passo 1 — Identificare i moduli partendo dai P&ID

Il lavoro di stesura di una Functional Specification S88 comincia sui P&ID. Il metodo è deliberatamente analogico: si stampano i diagrammi, si prendono evidenziatori di colori diversi e si tracciano i confini dei moduli S88 direttamente sullo schema.
Per ciascun modulo identificato si verifica che:
– Svolga una funzione precisa e coerente
– Possa operare in modo indipendente dagli altri moduli
– Gestisca in autonomia allarmi e interblocchi di propria competenza
– Abbia confini di responsabilità chiari con i moduli adiacenti
Dopo questa prima identificazione si costruisce la gerarchia S88:
Process Cell → Unit → Equipment Module → Control Module
In questa fase è fondamentale distinguere i moduli condivisi tra più unit (es. un sistema CIP comune a più fermentatori) da quelli dedicati a una singola unit. I moduli condivisi hanno implicazioni dirette sulla gestione della concorrenza e delle risorse nel Procedural Model.

Suggerimento pratico: coinvolgere il process engineer e l’automation engineer nella stessa sessione di markup sui P&ID evita costose revisioni successive. Le decisioni di modularità prese in questa fase determinano la struttura dell’intera automazione.

Passo 2 — Introdurre il class-based control nella FS

Uno dei contributi più preziosi di una Functional Specification S88-aware è l’introduzione esplicita del controllo basato su classi (class-based control). Questo è il punto che genera il maggiore impatto economico sull’intero progetto.
Lo standard ISA-88 di per sé non definisce le classi: è compito della Functional Specification farlo. Il principio è semplice: moduli fisicamente identici o funzionalmente analoghi vengono raggruppati in classi, specificate, progettate e validate una volta sola.

Esempio pratico di class-based control

In un impianto con sei fermentatori identici da 120 litri:
– Si definisce una classe FermentorUnit_120L con tutte le fasi comuni (SIP, CIP, Fermentation, Transfer, Drain)
– Si sviluppano e validano le Phase class una sola volta
– Le sei istanze ereditano tutto dalla classe; differiscono solo nei tag name degli strumenti reali
Il risparmio rispetto a specificare e sviluppare i sei fermentatori indipendentemente è diretto: n classi invece di n × m istanze. In un progetto reale con 117 fasi istanziate, la corretta applicazione del class-based control ha ridotto le classi da specificare a 46, con un risparmio di 1.000-1.300 ore di engineering (dati dettagliati nel case study S88 fermentazione).

Passo 3 — Specificare l’exception handling come parte del design

L’errore più comune e costoso nei progetti batch è trattare l’exception handling come un after-thought: qualcosa da aggiungere durante il commissioning quando i problemi si manifestano.
Una Functional Specification S88 ben strutturata include la matrice di gestione delle eccezioni per ogni Phase, definendo per ciascuna anomalia possibile:

Evento	Condizione di attivazione	Azione richiesta	Stato finale
Timeout agitatore	Velocità < set point per > 30 s	Hold e allarme operatore	Held
Perdita sensore temperatura	Segnale fuori range	Hold e allarme urgente	Held
Anomalia pressione	ΔP > soglia	Abort batch	Aborted
Interruzione alimentazione	Power fail	Stop controllato	Stopped

Le domande fondamentali da rispondere per ogni eccezione sono: l’operatore può riprendere il processo (Hold → Restart)? Il batch è compromesso e deve essere abortito (Abort)? Il prodotto può essere recuperato?
Queste decisioni dipendono dalla fase del processo (una contaminazione in inoculazione è diversa da una contaminazione in fermentazione avanzata) e dalla criticità del parametro deviato. Vanno prese con il process engineer, non dall’automation engineer da solo in fase di programmazione

Passo 4 — Organizzare i moduli: module basis vs plant basis

La FS deve stabilire come vengono organizzati i tag e la logica di controllo nel sistema: secondo una logica orientata ai moduli S88 (module basis) o secondo una logica geografica dell’impianto (plant basis).
L’approccio module basis è coerente con S88 e raccomandato: ogni Equipment Module e Control Module ha i propri tag, la propria logica e i propri allarmi organizzati gerarchicamente. Questo garantisce la massima coerenza con il Procedural Model e semplifica la manutenzione.
L’approccio plant basis — ancora comune in molti DCS tradizionali — organizza i tag per area geografica dell’impianto. Può essere più intuitivo per gli operatori, ma introduce ridondanza e complessità nella gestione delle classi S88.
La FS deve esplicitare la scelta e documentarne le ragioni: questa decisione impatta sull’organizzazione del DCS/PLC, sulla struttura dei display HMI e sulle modalità di validazione.

Cosa non deve mancare in una Functional Specification S88

Una FS S88 completa include almeno:
– Gerarchia fisica (Physical Model): Process Cell, Unit, Equipment Module, Control Module con confini chiari
– Lista delle Phase class: nome, descrizione, stati, transizioni, parametri
– Lista degli Equipment Module class: funzione, interblocchi, allarmi
– Lista dei Control Module class: tipo (AI, AO, PID, valve, motor…), range, allarmi
– Matrice exception handling: per ogni Phase, tutti gli eventi anomali e le reazioni
– Gestione risorse condivise: logica di allocazione e rilascio delle unit condivise
– Interfacce: verso altri sistemi (ERP, MES, LIMS) e verso subsistemi (weighing, utilities)
– Requisiti di batch record: dati da registrare, formato, retention

Domande frequenti sulla Functional Specification S88

Qual è la differenza tra Functional Specification e Design Specification?

La Functional Specification (FS) descrive cosa il sistema deve fare: funzioni, comportamenti attesi, requisiti. La Design Specification (DS) descrive come viene implementato: architettura hardware, piattaforma DCS/PLC, struttura del codice. La FS precede la DS nel ciclo di vita GAMP

Chi deve approvare la Functional Specification?

In un progetto S88 in ambito regolamentato, la FS deve essere approvata da: Process Engineering, Automation Engineering, Quality Assurance e — quando rilevante — dall’utente finale (Plant Manager o Production Manager). L’approvazione multidisciplinare è il prerequisito per la sua valenza come documento di validazione.

Quando coinvolgere gli automation engineer nella stesura della FS?

Il prima possibile: idealmente mentre i P&ID sono ancora in revisione draft. Questo permette agli automation engineer di segnalare problemi di automabilità (es. posizionamento degli strumenti, accesso ai segnali, logiche di interblocco) prima che il design fisico sia congelato, evitando costosi change order in fase avanzata.

Quanto deve essere dettagliata la Functional Specification?

La FS deve essere abbastanza dettagliata da permettere a vendor diversi di formulare offerte comparabili, e da permettere al team di validazione di costruire i test protocol senza ambiguità. Non deve specificare la piattaforma o il linguaggio di programmazione — quello è compito della Design Specification.

Conclusione: la FS come asset di progetto e aziendale

Una Functional Specification S88-aware non è un documento per chi programma. È un asset aziendale che serve al project manager per confrontare offerte su basi omogenee, all’azienda per preservare il know-how di processo indipendentemente dal turnover del personale, e a chi farà le modifiche tra cinque anni, quando l’impianto dovrà espandersi o adeguarsi a nuovi requisiti.
Il tempo investito in una FS solida si recupera moltiplicato durante l’implementazione, il commissioning e — soprattutto — nella vita operativa dell’impianto.

Il passo successivo: vedere come questi principi si traducono in numeri reali nel case study sull’automazione batch di un impianto di fermentazione, dove l’approccio class-based ha generato un risparmio stimato di 1.000-1.300 ore.
📌 Scopri i nostri servizi di consulenza batch: www.italiautomazione.com