In quasi tutti i progetti di automazione andati male c’è un punto in comune: nessuno aveva messo per iscritto, prima di iniziare, cosa doveva fare la macchina. Si parte dagli schemi, si scrive il software “che tanto si capisce in corso d’opera”, e il conto arriva al collaudo — quando cambiare una scelta costa dieci volte di più.
La functional description (o analisi funzionale, o specifica funzionale) è il documento che descrive il comportamento della macchina in linguaggio comprensibile a tutti: cliente, progettista meccanico, elettrico e software. Non è burocrazia: è il punto in cui si prendono le decisioni.
Cosa contiene
- Descrizione del processo: cosa fa la macchina, in che sequenza, con quali tempi ciclo
- Modi di funzionamento: automatico, manuale, setup, pulizia, emergenza — e come si passa dall’uno all’altro
- Elenco di attuatori e sensori, con comportamento atteso e condizioni di consenso
- Gestione degli allarmi: cosa succede quando qualcosa va storto, come si riparte, cosa perde e cosa conserva la macchina
- Ricette e parametri: cosa è configurabile dall’operatore e con quali livelli di accesso
- Interfaccia operatore: quali informazioni servono in campo e quali azioni devono essere a portata di mano
- Requisiti di sicurezza: funzioni di sicurezza previste e relativo Performance Level richiesto
- Dati e tracciabilità: cosa va registrato, con quale risoluzione e dove finisce
- Criteri di accettazione: come si stabilisce, in FAT e SAT, che la macchina è conforme
Perché conviene, anche quando sembra tempo perso
Fa emergere le domande scomode presto. “Cosa fa la macchina se manca il pezzo a metà ciclo?” è una domanda che costa mezz’ora in fase di analisi e due giorni in fase di avviamento.
Allinea meccanica, elettrico e software. Il documento è il posto in cui il progettista meccanico scopre che serve un sensore in più, e il software scopre che quel movimento non è ripetibile come si pensava.
Rende il collaudo un fatto oggettivo. Con criteri di accettazione scritti, il FAT non è una trattativa: si verifica punto per punto quanto concordato.
Sopravvive alle persone. Fra tre anni, chi dovrà modificare quella macchina troverà un documento invece di dover interpretare il codice.
Come la usiamo
In Dal Ben Automation la functional description è il primo deliverable di ogni progetto, prima degli schemi e prima del software. Viene condivisa con il cliente, discussa e approvata: da lì nascono la progettazione elettrica, l’architettura di controllo e i piani di test.
Non serve un documento di duecento pagine. Serve un documento onesto, che dica anche ciò che non è ancora deciso — perché un punto aperto e dichiarato è gestibile, un punto dato per scontato no.