Ridondanza nei PLC: logica 2oo3 con tre sensori di livello in TIA Portal

Che cosa succede se un sensore di livello si attiva per errore? E se, al contrario, non rileva il liquido quando dovrebbe? In un impianto industriale, affidare una decisione importante a un solo segnale può rendere difficile distinguere un evento reale da un’anomalia.

In questo tutorial realizziamo in Siemens TIA Portal un esempio didattico di ridondanza con tre sensori di livello. Useremo una logica di voto 2oo3: il PLC riconoscerà il livello alto quando almeno due sensori su tre saranno attivi. Aggiungeremo poi il filtraggio degli ingressi, la diagnosi del disaccordo e il blocco del riempimento.

Che cosa significa logica di voto 2oo3?

La sigla 2oo3 deriva dall’inglese two out of three: due su tre. I tre sensori forniscono segnali indipendenti e il sistema considera raggiunto il livello alto quando almeno due concordano nel segnalarlo.

Chiamiamo i tre ingressi LSH_1, LSH_2 e LSH_3. Nell’esempio, il valore TRUE significa che il sensore rileva il livello alto.

Questa tabella descrive la maggioranza logica. La disposizione fisica dei sensori richiede però attenzione: se sono installati a quote diverse, durante la salita del liquido si attiveranno naturalmente in momenti diversi. Il livello al quale interviene il voto 2oo3 e il tempo di disaccordo devono quindi essere coerenti con il processo reale.

1. Creiamo il blocco funzione in TIA Portal

Nel progetto TIA Portal creiamo un blocco funzione chiamato FB_RedundantLevelVoting. Lo realizziamo in KOP/LAD e organizziamo le reti nell’ordine in cui i segnali vengono elaborati: filtraggio, voto, diagnostica e consenso al riempimento.

Ingressi del blocco

Uscite del blocco

Nella sezione Static dichiariamo anche LSH1_OK, LSH2_OK e LSH3_OK, oltre alle istanze dei quattro temporizzatori IEC: uno per ogni sensore e uno per il disaccordo.

2. Filtriamo i tre segnali con i timer TON

Le prime tre reti sono uguali nella struttura. Ciascun ingresso viene validato soltanto se rimane attivo per il tempo impostato in DebounceTime.

Enable AND LSH_1 → TON tLSH1 → LSH1_OK
Enable AND LSH_2 → TON tLSH2 → LSH2_OK
Enable AND LSH_3 → TON tLSH3 → LSH3_OK

Per una prima prova in simulazione possiamo impostare DebounceTime = T#1s. Se un segnale torna inattivo prima della scadenza, il timer TON si azzera e l’ingresso non viene validato.

Osservazione: in questa versione filtriamo l’attivazione. La perdita del segnale viene invece recepita subito. Nella progettazione dell’impianto occorre scegliere i tempi in base alla dinamica del processo e alla risposta richiesta.

3. Costruiamo la rete di voto 2oo3

Ora utilizziamo i tre segnali validati. In KOP realizziamo tre rami in parallelo, ciascuno con una coppia di contatti in serie:

HighLevel_Voted =
    (LSH1_OK AND LSH2_OK)
 OR (LSH1_OK AND LSH3_OK)
 OR (LSH2_OK AND LSH3_OK)

L’uscita HighLevel_Voted diventa vera non appena due dei tre segnali validati sono attivi. Un solo sensore attivo, invece, non è sufficiente per generare il livello alto votato.

4. Rileviamo il disaccordo tra i sensori

I tre sensori sono concordi soltanto in due situazioni: tutti inattivi oppure tutti attivi. Qualsiasi altra combinazione produce SensorDisagreement.

SensorDisagreement =
    Enable
AND NOT (
    (NOT LSH1_OK AND NOT LSH2_OK AND NOT LSH3_OK)
 OR (LSH1_OK AND LSH2_OK AND LSH3_OK)
)

Un disaccordo momentaneo non equivale automaticamente a un guasto. Per esempio, con sensori montati a quote diverse, il liquido può raggiungere il primo interruttore prima degli altri. Usiamo quindi un ulteriore TON, tDisagree, per misurare quanto dura questa condizione.

tDisagree.IN = SensorDisagreement
tDisagree.PT = DisagreeTime

In simulazione possiamo partire da DisagreeTime = T#5s. In un’applicazione reale il valore va definito osservando la velocità di riempimento, la distanza tra i sensori e i tempi di intervento richiesti.

5. Memorizziamo il guasto sensori

Se il disaccordo persiste oltre DisagreeTime, il timer attiva la propria uscita Q. A quel punto memorizziamo SensorFault:

SET SensorFault
quando tDisagree.Q = TRUE

Il guasto può essere ripristinato dall’operatore solo quando il disaccordo è scomparso e il timer non segnala più la condizione anomala:

RESET SensorFault
quando Reset
  AND NOT SensorDisagreement
  AND NOT tDisagree.Q

Nel blocco definiamo una priorità del SET nel caso in cui impostazione e ripristino vengano richiesti nello stesso ciclo di scansione: un guasto presente deve rimanere visibile.

6. Individuiamo il sensore sospetto

Quando due segnali coincidono e il terzo è diverso, possiamo indicare all’operatore quale sensore merita una verifica:

S1_Suspect = (LSH2_OK = LSH3_OK) AND (LSH1_OK <> LSH2_OK)
S2_Suspect = (LSH1_OK = LSH3_OK) AND (LSH2_OK <> LSH1_OK)
S3_Suspect = (LSH1_OK = LSH2_OK) AND (LSH3_OK <> LSH1_OK)

Se, per esempio, i segnali sono 1–1–0, il blocco indica S3_Suspect. La parola sospetto è intenzionale: il confronto mostra soltanto quale segnale differisce dagli altri due. Non dimostra da solo che quel sensore sia guasto, soprattutto quando i dispositivi sono installati a quote differenti.

7. Memorizziamo l’intervento per livello alto

Quando HighLevel_Voted diventa vero, impostiamo HighLevel_Trip. L’intervento rimane memorizzato anche se il livello torna a scendere.

SET HighLevel_Trip
quando HighLevel_Voted = TRUE

RESET HighLevel_Trip
quando Reset AND NOT HighLevel_Voted

In questo modo la pressione del pulsante di reset non cancella l’intervento mentre almeno due sensori continuano a rilevare il livello alto.

8. Generiamo il consenso al riempimento

L’ultima rete produce il segnale che può essere utilizzato nella logica della pompa o della valvola di ingresso:

FillPermissive =
    Enable
AND NOT HighLevel_Trip
AND NOT SensorFault

Il riempimento è consentito solo quando il blocco è abilitato e non sono presenti né un intervento per livello alto né un guasto sensori memorizzato. Sull’HMI conviene visualizzare separatamente il motivo della mancata autorizzazione: livello alto, disaccordo o guasto sensori.

9. Verifichiamo il funzionamento in simulazione

Prima di usare il blocco in un progetto applicativo, proviamo almeno queste sequenze con PLCSIM o con una tabella di controllo:

1. 0–0–0: nessun livello alto e nessun disaccordo.
2. Un ingresso attivo per meno di DebounceTime: il segnale non viene validato.
3. 1–0–0 dopo il filtraggio: compare il disaccordo, ma il voto 2oo3 resta falso.
4. 1–1–0: il voto diventa vero e si memorizza HighLevel_Trip.
5. Disaccordo oltre DisagreeTime: si memorizza SensorFault.
6. Ritorno a 0–0–0: trip e guasto restano memorizzati fino al reset.
7. Reset con livello alto ancora presente: il trip non deve cancellarsi.
8. Reset con sensori concordi e livello rientrato: il consenso può tornare disponibile.

Conclusioni

Questo esempio mostra che la ridondanza nei PLC non consiste semplicemente nell’aggiungere sensori. Bisogna decidere come confrontarne i segnali, quanto tempo concedere a un disaccordo, quali anomalie memorizzare e quando autorizzare il ripristino.

La logica 2oo3 è un esercizio efficace per collegare in un unico progetto ingressi digitali, timer IEC, diagnostica, allarmi HMI e interblocchi. È anche un buon punto di partenza per discutere con gli studenti la differenza tra disponibilità del processo, rilevamento dei guasti e sicurezza funzionale.

Nota tecnica: il progetto illustrato ha finalità didattiche. Se il rilevamento del troppo pieno svolge una funzione di sicurezza, l’architettura completa deve essere progettata e verificata in base alla valutazione dei rischi. Una logica 2oo3 implementata su normali ingressi PLC non costituisce, da sola, una funzione di sicurezza certificata.

Hai già utilizzato una logica di voto 2oo3 nei tuoi progetti PLC? Raccontami nei commenti come hai gestito la diagnostica dei sensori.