La ISO 13849-1:2023 è la norma che stabilisce come progettare e verificare le parti di un sistema di comando legate alla sicurezza (in inglese SRP/CS, safety-related parts of control systems) e come dimostrare che raggiungono il livello di prestazione richiesto. Per chi scrive codice su un PLC di sicurezza conta per due motivi. Il programma applicativo è una delle parti di sicurezza, con requisiti suoi. E un software scritto bene non basta se a monte il PL richiesto (PLr) è stato scelto male o se l’architettura hardware non lo può raggiungere. Questo articolo segue il percorso completo: dal rischio al PLr, dal PLr all’architettura, da lì al codice e alla validazione.
In particolar modo vedremo:
Cosa cambia per il programmatore con l’edizione 2023
L’edizione 2023 ha sostituito quella del 2015. Per chi lavora sul software le novità che contano sono tre:
- la specifica dei requisiti di sicurezza diventa un documento esplicito, da scrivere prima di progettare. Non è più un elenco implicito sparso fra schemi e commenti;
- il software resta diviso in due famiglie, SRESW (embedded, scritto da chi produce il dispositivo) e SRASW (applicativo, scritto da chi integra la macchina), e i requisiti vengono graduati in base al PL;
- il collegamento con la validazione secondo la ISO 13849-2 è più stretto: verifica e validazione accompagnano tutto il progetto e non si riducono a un collaudo finale.
Sul piano legale il quadro di riferimento passa dalla Direttiva Macchine 2006/42/CE al Regolamento (UE) 2023/1230, applicabile dal 20 gennaio 2027. Prima di usare la norma per la presunzione di conformità bisogna controllare sulla Gazzetta ufficiale dell’UE quale edizione della EN ISO 13849-1 è citata come armonizzata.
Procedura: dal PLr al software applicativo validato
- Individua la funzione di sicurezza. Il punto di partenza è la valutazione del rischio secondo la ISO 12100. Per ogni pericolo che si riduce con il sistema di comando si definisce una funzione con ingresso, logica, uscita e stato sicuro. Per esempio: «all’apertura del riparo mobile il mandrino si ferma con arresto di categoria 1 e resta fermo finché il riparo non è chiuso e non c’è un nuovo comando di avvio». Un riparo, un fungo e una barriera fotoelettrica sono tre funzioni diverse anche se finiscono sullo stesso contattore.
- Determina il PLr. Con il grafo del rischio dell’allegato A si valutano tre parametri: la gravità della lesione (S1 o S2), la frequenza o durata dell’esposizione (F1 o F2) e la possibilità di evitare il pericolo o limitare il danno (P1 o P2). Il risultato va da PLr a a PLr e. Ogni scelta va motivata per iscritto: in un audit si discute il «perché P1» e non la lettera che ne esce.
- Scrivi la specifica dei requisiti di sicurezza. Per ogni funzione la specifica riporta il PLr, i modi operativi in cui è attiva, il tempo di reazione ammesso, il comportamento a ogni guasto rilevato, il ripristino e le interazioni con le altre funzioni (muting, by-pass in manutenzione, selettori di modo). Da questo documento escono i casi di test.
- Scegli l’architettura e calcola il PL raggiunto. Per ogni canale si combinano categoria (B, 1, 2, 3, 4), MTTFD, copertura diagnostica media DCavg e misure contro i guasti di causa comune (CCF, almeno 65 punti secondo l’allegato F per le categorie 2, 3 e 4). Il PL che ne risulta deve essere maggiore o uguale al PLr. Strumenti come SISTEMA dell’IFA fanno il calcolo, ma i dati di ingresso (B10D, numero di manovre all’anno, DC dichiarate) restano responsabilità tua.
- Progetta il software applicativo. Il codice segue la specifica e l’architettura, non il contrario. Moduli piccoli, ognuno legato a una funzione di sicurezza. Blocchi certificati del costruttore per E-Stop, feedback dei contattori ed equivalenza dei sensori. Logica di sicurezza separata dalla logica standard. Valori iniziali e stati di uscita sicuri al riavvio.
- Codifica con regole scritte. Servono un manuale di stile (nomi, commenti, divieti), niente salti all’indietro né logica auto-modificante, variabili di sicurezza scritte da un solo punto, scambi standard→sicurezza solo in lettura e filtrati. Gli errori di programmazione comuni vanno prevenuti dalla regola, non scoperti in collaudo.
- Verifica il codice. Revisione del codice con la specifica in mano, controllo di flusso dati e di controllo per i PL alti, test funzionali dei singoli blocchi e poi delle funzioni integrate. Le prove si fanno anche con guasti iniettati: filo staccato, contatto incollato, discrepanza fra i canali, sensore in cortocircuito.
- Valida secondo la ISO 13849-2. Il piano di validazione indica cosa si prova, con quale metodo e con quale criterio di accettazione. Su ogni funzione si esegue la prova a macchina reale, si registra l’esito e si conserva la firma (CRC o checksum) del programma validato. Ogni modifica successiva riapre la verifica almeno sulle funzioni toccate e su quelle che interagiscono con loro.
Requisiti del software in funzione del PL
La norma non chiede lo stesso rigore per un PLr b e per un PLr e. La tabella riassume come cresce l’impegno sul software applicativo. È una sintesi ragionata: le misure precise vanno lette nella norma.
| Aspetto | PLr a – b | PLr c | PLr d – e |
|---|---|---|---|
| Specifica dei requisiti | Necessaria, anche sintetica | Completa e revisionata | Completa, revisionata da una persona diversa dall’autore |
| Linguaggio | LVL consigliato | LVL, con blocchi certificati dove disponibili | LVL; un FVL solo seguendo i requisiti del software embedded |
| Struttura del codice | Modulare, commentata | Modulare, regole di codifica scritte | Modulare, regole vincolanti, logica di sicurezza separata |
| Verifica | Test funzionale | Test funzionale e revisione del codice | Revisione, analisi di flusso dati e controllo, test con guasti iniettati |
| Gestione modifiche | Registro delle versioni | Analisi d’impatto documentata | Analisi d’impatto, nuova verifica delle funzioni coinvolte, firma del programma |
LVL sta per limited variability language: ladder, FBD e in generale i linguaggi con blocchi predefiniti dei PLC di sicurezza. FVL (full variability language) indica linguaggi come C o assembler. Su un PLC safety quasi tutto il software applicativo sta in LVL, ed è il caso più semplice da dimostrare.
Le soglie quantitative da tenere a mente
| PL | Probabilità media di guasto pericoloso per ora (PFHD) |
|---|---|
| a | da 10-5 a meno di 10-4 |
| b | da 3×10-6 a meno di 10-5 |
| c | da 10-6 a meno di 3×10-6 |
| d | da 10-7 a meno di 10-6 |
| e | da 10-8 a meno di 10-7 |
Il software non ha un tasso di guasto proprio: i suoi errori sono sistematici e non casuali. Per questo il PFHD si calcola solo sull’hardware, e la qualità del software si dimostra con il processo: specifica, regole, verifica, validazione. Un PL d calcolato con un codice mai revisionato è un PL d solo sulla carta.
Errori frequenti nei progetti reali
- PLr deciso a valle. Si sceglie il PLC e poi si «trova» un PLr compatibile. L’ordine giusto è l’opposto, e il fascicolo tecnico lo mostra.
- Diagnostica dichiarata ma non programmata. Si inserisce nel calcolo una DC del 99% per il monitoraggio dei contattori, ma il feedback non è cablato o il blocco EDM è by-passato da un bit forzato.
- Reset automatico nascosto. Una funzione che riparte da sola alla chiusura del riparo, perché un fronte di salita è finito nel ramo sbagliato. Il riavvio intenzionale va previsto nella specifica e provato.
- Modifiche «piccole» non tracciate. Un tempo di filtro cambiato in messa in servizio senza nuova validazione cambia la funzione di sicurezza.
- By-pass di manutenzione nella logica standard. Qualsiasi condizione che disattiva o modifica una funzione di sicurezza appartiene al programma di sicurezza e va protetta.
Domande frequenti (FAQ)
Se uso un PLC certificato PL e, il mio software è automaticamente PL e?
No. La certificazione riguarda il dispositivo e il suo software embedded. Il PL della funzione dipende da tutta la catena (sensori, logica, attuatori) e dal software applicativo che scrivi tu, che va specificato, verificato e validato secondo il PLr della funzione.
Che differenza c’è fra verifica e validazione?
La verifica controlla che ogni fase rispetti quello che le chiede la fase precedente: il codice rispetta la specifica, il PL calcolato raggiunge il PLr. La validazione controlla che la funzione, provata sulla macchina, riduca davvero il rischio individuato. Si possono superare tutte le verifiche e fallire la validazione se la specifica era sbagliata.
Meglio ISO 13849-1 o IEC 62061?
Entrambe sono riconosciute per i sistemi di comando delle macchine. La ISO 13849-1 ha architetture designate e un metodo semplificato che la rendono più pratica per le tecnologie miste (elettriche, pneumatiche, idrauliche). La IEC 62061 è più vicina all’approccio della IEC 61508 e si presta a sistemi elettronici complessi. Dentro la stessa funzione conviene non mescolarle senza un criterio esplicito.
Dopo una modifica al programma devo rivalidare tutto?
Non sempre. Serve un’analisi d’impatto documentata che individui le funzioni toccate direttamente e quelle che condividono variabili, blocchi o uscite con il codice modificato. Su quelle si ripetono verifica e validazione. La firma del programma registrata permette di dimostrare cosa è cambiato rispetto alla versione validata.
“Semplifica, automatizza, sorridi: il mantra del programmatore zen.”
Dott. Strongoli Alessandro
Programmatore
CEO IO PROGRAMMO srl
Fail-safe e funzioni di sicurezza in TIA Portal.
Corso SAFETY su Udemy
