50 / 84
NOVEMBRE 2015
FIELDBUS & NETWORKS
50
Fieldbus & Networks
L
a diffusione dei bus di campo
e, più in generale, delle reti di
controllo locale nel settore dei
trasporti ha avuto inizio negli
anni ’80, principalmente allo
scopo di rendere disponibili a macchinisti
e piloti strumenti di diagnostica atti a mi-
gliore sicurezza e affidabilità del veicolo.
Sebbene sviluppate principalmente per
applicazioni in ambito automazione e au-
tomotive, soluzioni basate, per esempio,
su Canbus, Profibus o FIP hanno trovato
nel tempo valido impiego anche a bordo
treno. Il processo di standardizzazione ha
portato alla definizione di un’architettura
di riferimento denominata TCN (Train
Communication Network) che ancora oggi
rappresenta la soluzione principalmente
adottata. Tra le iniziative più interessanti
in questo ambito va certamente ricordato
il progetto InteGRail, iniziato nel 2005 e
durato 4 anni, realizzato con un budget
complessivo di 20 milioni, in gran parte
finanziati dalla Comunità Europea, e che
ha visto la partecipazione dei principali
enti e aziende del settore, come Alstom,
Ansaldo, Bombardier, Trenitalia… Più
di recente, il crescente interesse per le
tecnologie IP ha sospinto l’introduzione,
anche a bordo treno, di architetture basate
su Ethernet.
Introduzione
all’architettura TCN
(IEC 61375)
Lo standard IEC 61735-1 definisce un’ar-
chitettura gerarchica a due livelli, che
comprende (si veda Figura 1a) le reti
‘Train Backbone’ (o ‘Train Bus’) e ‘Con-
sist Network’. La prima, che rappresenta
la dorsale di comunicazione, è utilizzata
principalmente per la connessione dei di-
versi veicoli o carrozze, mentre la seconda
trova impiego per la comunicazione tra i
vari dispositivi o sottosistemi di bordo. Lo
standard prevede che tutte le implementa-
zioni di tali reti supportino protocolli real
time con servizi dedicati per la gestione di
database distribuiti, periodicamente ag-
giornati, e per lo scambio di messaggi ‘on
demand’ inmodalità ‘unicast’ o ‘multicast’.
L’architettura può prevedere un qualche
livello di ridondanza per maggiore affida-
bilità (si vedano Figura 1b e 1c), così da iso-
lare eventuali guasti e assicurare costante
operatività. Inoltre, è previsto supporto
per riconfigurabilità dinamica mediante
le procedure di ‘Automatic Train Inau-
guration’, o configurazioni fisse (si veda
Figura 1c) con reti ad anello. Ovviamente
sono definiti protocolli di interfacciamento
standard delle reti Consist Network con la
dorsale principale rappresentata dal Train
Backbone, in modo da consentire la con-
nessione di sottosistemi basati su diverse
Consist Network. Le prime implementa-
zioni delle architetture TCN si sono basate
sui protocolli WTB (Wired Train Bus) per
quanto concerne la parte di rete Train
Backbone, e MWB (Multifunction Vehicle
Bus) e Canopen per le sezioni Consist Net-
work.
Il bus WTB utilizza doppini schermati
per l’implementazione del livello fisico e
codifica Manchester dei dati, con proto-
collo Hdlc; il livello di segnale è RS485. Lo
standard ha diverse similitudini con il più
vecchio protocollo WorldFIP fieldbus (EN
50170 - Part 4). La velocità di trasmissione
dati massima, per esempio, è 1 Mbps. È
previsto che siano connessi in rete fino a
32 nodi, dislocati su fino a 22 veicoli, con
la possibilità, quindi, che un veicolo ospiti
più di un nodo, e con una lunghezza mas-
sima del bus che arriva fino a 860 m. La
comunicazione è di tipo master-slave e
configurata sulla base di intervalli perio-
dici entro i quali ogni nodo slave può tra-
smettere i propri messaggi. All’interno di
ogni periodo il nodo trasmette i propri dati
‘time critical’, indicati anche come ‘process
data’ o ‘R-telegram’ e, opzionalmente, dati
sporadici, indicati come ‘E-telegrams’.
QUANDO PARLIAMO DI INFRASTRUTTURE
UNO DEGLI AMBITI CHE PIÙ CI VENGONO IN
MENTE È QUELLO DEI TRASPORTI. VEDIAMO, IN
PARTICOLARE, QUALI PROTOCOLLI E SOLUZIONI DI
RETE SI SONO AFFERMATI IN CAMPO FERROVIARIO
RETI PER LE
INFRASTRUTTURE
di
Mariano Severi
Fonte: www.eureka-smart-cities.org