EMBEDDED
50 • NOVEMBRE • 2013
72
HARDWARE
INDUSTRIAL AUTOMATION
256 frame. Nella figura 2 vengono ripor-
tati i differenti tempi di risposta e i requi-
siti di latenza per vari slave/protocolli.
Per supportare il protocollo scelto il
progetto del livello MAC nel dispositivo
slave si differenzia dal quello del livello
MAC Ethernet tradizionale e richiede
uno sviluppo specifico. Dal punto di
vista della realizzazione del sistema, nel
caso sia necessario supportare un’imple-
mentazione di un MAC standard oltre
a un’implementazione specifica, il pro-
getto può includere entrambi i MAC
oppure prevedere la riprogrammabilità
in hardware.
Le tendenze nel campo della
comunicazione industriale
La maggior parte dei progetti che sup-
portano Industrial Ethernet utilizzano
moduli o schede add-on. Quando si rea-
lizza un azionamento che deve supportare un particolare proto-
collo IE è necessario integrare uno specifico modulo corredato
dal firmware opportuno. Un’implementazione di questo tipo
non rappresenta certamente la soluzione ideale nel momento
in cui è prevista un’elevata diffusione di funzionalità di comu-
nicazione in ambito industriale. Un pre-requisito chiave per
l’integrazione è senza dubbio la maturità di tutti i principali stan-
dard per protocolli: in questo modo è possibile minimizzare le
probabilità di dover modificare l’hardware di supporto. Quindi
l’integrazione deve essere effettuata mediante dispositivi carat-
terizzati da fattori di forma ridotta e non deve comportare costi
aggiuntivi di una certa entità. La prima fase di questo processo
di integrazione che è attualmente in corso prevede il ricorso a
chip dedicati per i diversi standard di comunicazione. Chip di
questo tipo supportano più standard è possono anche essere
eliminati nel caso non sia necessaria la funzione di comunicazio-
ne. L’obbiettivo finale è la completa integrazione all’interno del
nucleo centrale del sistema: in altre parole l’hardware di comu-
nicazione e gli stack del protocollo vengono gestiti all’interno
del sistema principale su un unico chip.
In questo modo è possibile ridurre ulteriormente lo spazio
occupato sulla scheda e i costi aggiuntivi legati all’uso di dispo-
sitivi che abilitano la comunicazione. L’impiego di core IP e di
stack pre-configurati aiutano gli utenti a istanziare il protocollo
scelto per mezzo di un insieme di firmware o addirittura di una
configurazione software.
I requisiti per garantire il funzionamento di un modello come
quello appena delineato sono la disponibilità di un’interfaccia
specifica per separare le esigenze di
comunicazione da quelle di un’inter-
faccia standard e di una piattaforma
hardware comune in grado di far
girare tutti i protocolli. Oltre a ciò,
anche le più importanti aziende che
hanno sviluppato implementazioni
proprietarie – sia per ragioni lega-
te alla manutenzione del software
sia per la mancata disponibilità di
soluzioni di terze parti al tempo in
cui avevano bisogno degli stack
del protocollo - stanno riducendo le
risorse messe a disposizione per la
manutenzione delle loro soluzioni.
La comunicazione è una “commo-
dity” e non porta nessun valore
Fig. 2 - Differenti tempi di risposta e requisiti di latenza per vari slave/
protocolli
Fig. 3 – Struttura di un FPGA della serie Cyclone V di Altera
