NOVEMBRE 2014
FIELDBUS & NETWORKS
49
dire la capacità del protocollo di sicurezza
di individuare errori. In molti casi, un si-
stema di comunicazione con BER uguale
a 10-2 non è praticamente utilizzabile
per la trasmissione. Se pensiamo al caso
della comunicazione Ethernet, per esem-
pio, i frame prevedono una lunghezza
minima di 68 Byte (544 Bit). Ciò significa
che ogni frame verrebbe corrotto e non
sarebbe possibile instaurare una comuni-
cazione corretta. Ne consegue che alcuni
protocolli di sicurezza utilizzano un BER
di 10-3 (per cui viene corrotto ‘solo’ 1 bit
ogni 1.000) come base per il calcolo della
probabilità residua di errore. Ciò è con-
sentito, ma richiede un’accurata valuta-
zione e progettazione dell’architettura di
impianto da parte dell’utilizzatore finale.
Spesso poi sono presenti tecnologie di
comunicazione subordinate, come bus
di backplane, interfacce seriali interne ai
dispositivi, o componenti attivi standard
quali hub e switch, che distribuiscono o
inoltrano i messaggi di sicurezza.
Tutti questi componenti devono essere
inclusi nel calcolo del BER del sistema
di trasmissione. La probabilità residua di
errore del protocollo Safety over Ethercat
è basata sul BER più elevato, corrispon-
dente a 10-2. Il protocollo è indipendente
dal mezzo di comunicazione e si presta
per controlli di sicurezza di tipo sia cen-
tralizzato, sia distribuito. Il mezzo di co-
municazione è arbitrario e non limitato
a Ethercat. Per la trasmissione su cavi
elettrici, fibra ottica, o anche via radio
si possono utilizzare bus di campo clas-
sici, Ethernet o anche mezzi simili. Non
occorrono accortezze o verifiche da parte
dell’utilizzatore finale. Per il costruttore
di dispositivi questo comporta una no-
tevole semplificazione dell’implementa-
zione. L’interfaccia di comunicazione può
essere a singolo canale, come previsto
dalla definizione di ‘black channel’, e si
possono impiegare inalterate le inter-
facce di comunicazione interne ai di-
spositivi o il backplane nei sistemi di I/O
modulari.
Un’architettura
di sicurezza per l’intero
impianto
Gli impianti di produzione normal-
mente comprendono più fasi di lavo-
razione distinte, ciascuna eseguita da
un modulo-macchina
indipendente. L’inte-
razione tra questi
moduli, gestita da un
controllore centrale, è
resa possibile da una
rete di comunicazione
che raggiunge tutte
le parti dell’impianto.
I moduli-macchina
possono essere forniti
da costruttori diversi,
pertanto possono uti-
lizzare internamente
sistemi di comunica-
zione differenti.
Le funzioni di sicu-
rezza locali delle di-
verse parti d’impianto
sono normalmente
gestite all’interno del modulo stesso.
Se, per esempio, una funzione di arresto
viene attivata dall’apertura di uno spor-
tello di protezione, le movimentazioni
pericolose all’interno del modulo ven-
gono fermate in sicurezza. In aggiunta
a ciò, i moduli-macchina devono poter
scambiare informazioni di sicurezza con
tutto il resto dell’impianto, per esempio
per realizzare un arresto di emergenza
globale, o per informare i moduli che
precedono e seguono circa l’attivazione
di una funzione di emergenza. L’interfac-
cia verso ogni modulo dell’impianto deve
utilizzare un’informazione già elaborata e
filtrata, e quindi essere molto essenziale
e standardizzata con un profilo aperto.
Dopo aver raccolto gli esiti di numerose
discussioni tra gli utenti finali e come
risultato della collaborazione con un
gruppo di Omac (Organization for Ma-
chine Automation and Control), è stato
sviluppato un ‘Safety Interface Profile’
che rispetta le caratteristiche richieste.
Si tratta di un’interfaccia estremamente
semplice, che definisce un byte di con-
trollo per attivare le funzioni di sicurezza
in una porzione d’impianto. Tale byte
consente di attivare funzioni di arresto o
di movimento in sicurezza all’interno di
un modulo-macchina. Un byte di stato
fornisce poi un feedback da parte del
modulo circa il proprio stato relativa-
mente alle funzioni di sicurezza, in modo
tale da garantire, per esempio, la con-
ferma dell’errore in ogni punto dell’im-
pianto. L’interfaccia è indipendente dal
protocollo di sicurezza utilizzato e, dove
necessario, implementabile anche senza
bus di sicurezza sotto forma d’interfaccia
I/O cablata.
Grazie alla sua indipendenza dal mezzo
di trasporto, Safety over Ethercat è per-
fettamente idoneo alla trasmissione di
questo profilo tra le diverse parti d’im-
pianto. All’interno di ciascun modulo,
inoltre, si possono eventualmente imple-
mentare funzionalità di gateway verso lo
specifico protocollo di sicurezza utilizzato
all’interno del modulo.
(*) Esperto di Functional Safety di ETG - Ethercat
Technology Group - Germania
Ethercat Technology Group -
www.ethercat.orgIl ‘black channel’ copre l’intero percorso di
comunicazione tra i layer del protocollo di sicurezza dei
dispositivi
Un proÀlo basato
su un’interfaccia
aperta consente
lo scambio di dati
standard tra i
diversi moduli di
un impianto