Background Image
Table of Contents Table of Contents
Previous Page  64 / 84 Next Page
Information
Show Menu
Previous Page 64 / 84 Next Page
Page Background

EMBEDDED

58 • novembre • 2015

software

|

IIE

64

senza slittamenti. EtherCat e, in forma analoga,

Sercos non fanno ricorso agli switch tradizionali.

Entrambi i protocolli esaminano sempre solo un

numero limitato di byte di un messaggio ether-

net mentre attraversa la connessione di interfac-

cia. Ricorrendo a un’espressione poco tecnica, ma

efficace, è corretto dire che i dati utente vengono

utilizzati e letti “al volo”.

Si apre a questo punto un ulteriore punto di di-

scussione. L’interfaccia tra il microcontrollore

e la connessione switch/interfaccia deve essere

molto più rapida della velocità teorica della rete.

Tuttavia, un messaggio ethernet può essere tra-

smesso solo a 100 mBit/s. D’altro canto, ogni pac-

chetto che viene ricevuto deve poter essere letto

dal microcontrollore alla sua velocità ottimale

per assicurare la regolare integrazione dei com-

ponenti hardware e software. A tale scopo è pos-

sibile utilizzare DMA o, per i pacchetti più brevi,

l’accesso diretto ottimizzato. L’implementazione

del microcontrollore può essere notevolmente

accelerata e semplificata grazie al multitasking

hardware, come dimostrato con successo dal si-

stema fido1100 (Fig. 1). Un percorso alternativo

verso l’obiettivo consiste nell’utilizzo di micro-

controllori multi-core.

Nel frattempo, è in corso un’opera di sviluppo co-

stante dei protocolli, mentre nuovi operatori con

nuovi requisiti continuano a fare la loro compar-

sa sul mercato. Ad esempio, Sercos pubblicizza

l’elegante integrazione di Sercos III ed EtherNet/

IP in una stessa rete con l’espressione “Blended

Networks”. In questi casi, una sola connessione

di interfaccia deve soddisfare entrambi i proto-

colli.

Fortunatamente, si tratta di un problema risol-

vibile. La situazione di eterogeneità è destinata

ad aumentare prima che possa aver luogo un’e-

ventuale unificazione. Il barlume di speranza

menzionato sopra è evidentemente destinato a

restare senza seguito (per adesso...?).

Bibliografia

Browne, H. W. (2011). Whitepaper: Real-Time Perfor-

mance of Industrial Ethernet in Field Devices. Albu-

querque, NM, USA.

IEC 61784. (2010). Digital data communications for

measurement and control. IEC.

Klasen, O. V. (2011). Industrial Communication. Ber-

lin: VDE Verlag.

Cosa si chiede all’architettura

dell’interfaccia futura?

Adattabilità ed espandibilità

Lo sviluppo delle soluzioni software e dei semi-

conduttori per i protocolli ethernet industriale è

un’opera particolarmente dispendiosa in termini

di tempo e denaro. Per essere economicamente

vantaggiosa, una soluzione deve essere flessibile

al punto da adattarsi agli sviluppi e miglioramenti

futuri.

Filtraggio

Per quanto riguarda in particolare i protocolli fles-

sibili EtherNet/IP e PROFINET, che coesistono

sullo stesso cavo con l’ethernet standard, è fon-

damentale che un dispositivo di campo venga ca-

ricato solo con i suoi specifici pacchetti ethernet.

Questo filtraggio deve essere eseguito a livello di

hardware.

Prioritizzazione dei messaggi

Un server Web nel dispositivo di campo può es-

sere opportuno, purché il suo funzionamento non

interferisca con l’elaborazione in tempo reale. In

altri termini, la connessione di interfaccia deve

prevedere metodi efficaci di prioritizzazione dei

messaggi. La prioritizzazione deve essere consi-

derata sia a livello hardware che software.

Supporto per protocolli eterogenei

Capita spesso di dover supportare simultanea-

mente protocolli diversi. Nel caso PROFINET, ad

esempio: per l’avvio del sistema, viene utilizzato

DCP per configurare la rete, quindi TCP, SNMP e

LLDP per identificare la topologia. La sincronizza-

zione dei clock basati su IEEE1588 richiede un ul-

teriore protocollo, seguito in definitiva dal traffico

in tempo reale. Una solida operatività deve essere

possibile in ogni fase.

Esistono anche protocolli, quali Sercos ed Ether-

Cat, che appaiono completamente diversi rispetto

agli approcci tradizionali (utilizzo di switch ether-

net di livello 2). Anche questi devono poter essere

supportati.

Supporto per il software

Anche l’hardware migliore si rivela inutile se il sof-

tware non è in grado di sfruttarne le prerogative.

Oltre ad essere facile da gestire, l’interfaccia tra

i componenti hardware e software deve mettere

a disposizione un’elevata ampiezza di banda. I van-

taggi di un hardware di qualità devono essere tra-

sferibili al software senza alcuna perdita.