COSTRUZIONE DI PROTOCOLLI DI COMUNICAZIONE TRA PC E ...€¦ · tesi di laurea costruzione di...

TESI DI LAUREA

COSTRUZIONE DI PROTOCOLLI

DI COMUNICAZIONE TRA PC E DISPOSITIVI

DI CONTROLLO

RELATORE PROF. GIULIO DESTRI

CORRELATORE ING. CESARE CHIODELLI

CANDIDATO LUCA LODI RIZZINI

III

Ai miei genitori

V

Ringraziamenti

Desidero innanzitutto ringraziare l’ing. Cesare Chiodelli e il prof. Giulio

Destri per aver permesso lo svolgimento del mio stage lavorativo presso la

ditta CS Soluzione, consentendomi di apprendere le basi per lo sviluppo di

software a livello professionale e impostando la stesura della mia tesi.

Un grazie anche a Luca Visioli, Alberto Picca e Marco Maltraversi per il

lavoro svolto insieme.

Ringrazio anche i miei compagni di università Amadini, Lucia, Fabio e tutti

gli altri con cui ho passato questi quattro anni di studio e tutti gli amici

del mio paese che mi hanno sostenuto ed aiutato.

Ringrazio i miei genitori Curzio e Marina per essermi stati vicini e per

avermi supportato materialmente e moralmente, a cui dedico questo lavoro.

Un ringraziamento speciale a Nicole, per essermi stata vicino

sostenendomi nei momenti difficili del mio percorso di studio.

Vorrei salutare un mio grande amico Marco Belletti, conosciuto da tutti

come Kumbel , da poco deceduto in un incidente stradale.

Tu per me sei stato un ottimo amico di “baraccate”, grigliate , bevute e

tanto altro, non scorderò mai il tuo sorriso che ti accompagnava in ogni

istante e la tua grande dinamicità.

Ciao Kumbel.

VII

Sommario

INTRODUZIONE ...............................................................................................................1

Il contesto del problema: la comunicazione digitale fra dispositivi................................................... 1

Come è stato affrontato il lavoro......................................................................................................................... 2

LA COMUNICAZIONE DIGITALE ..................................................................................4

Le reti di comunicazioni ......................................................................................................................................... 4

Applicazioni delle reti............................................................................................................................................... 5

Aspetti hardware delle reti ..................................................................................................................................... 6 Tecnologia trasmissiva ........................................................................................................................................... 6 Scala dimensionale.................................................................................................................................................. 8

Reti Locali .............................................................................................................................................................. 9 Reti metropolitane............................................................................................................................................. 11 Reti geografiche.................................................................................................................................................. 12

Interconnessione di reti ........................................................................................................................................ 15

Protocolli e aspetti software delle reti........................................................................................................... 16

Gerarchie di protocollo .......................................................................................................................................... 16

Architettura di rete ................................................................................................................................................. 18

Funzionamento del software di rete ................................................................................................................ 19

Servizi connection-oriented e connectionless............................................................................................. 21 Servizi connection-oriented................................................................................................................................. 21 Servizi connectionless........................................................................................................................................... 22

Affidabilità del servizio .......................................................................................................................................... 23

Servizi vs protocolli................................................................................................................................................. 24 Aspetti di progetto dei livelli ............................................................................................................................... 24

Il modello ISO/OSI................................................................................................................................................... 26 Livello fisico ......................................................................................................................................................... 28 Livello Data Link................................................................................................................................................ 29 Livello Network ................................................................................................................................................... 29 Livello Transport................................................................................................................................................ 30 Livello Session .................................................................................................................................................... 31 Livello Presentation........................................................................................................................................... 31 Livello Application ............................................................................................................................................. 31

Internet Protocol Suite o TCP/IP....................................................................................................................... 31 Livello host-to-network .................................................................................................................................... 32 Livello Internet ................................................................................................................................................... 33 Livello Transport................................................................................................................................................ 33 Livello Application ............................................................................................................................................. 33

VIII

Confronto fra modello di riferimento OSI e architettura TCP/IP ............................................................ 34 Confronto fra pile di protocolli OSI e TCP/IP ................................................................................................ 35

LE RETI NEL MONDO REALE: PROBLEMI E STANDARD FISICI.......................................................... 36

Un limite per le reti: il rumore e i disturbi elettromagnetici ............................................................... 36 Trattazione matematica del rumore ................................................................................................................. 36 I tipi di rumore ........................................................................................................................................................ 38 Disturbi elettromagnetici..................................................................................................................................... 39

Lo standard più diffuso ai livelli 1 e 2: Ethernet........................................................................................ 41 I motivi del successo ............................................................................................................................................. 42 Il Frame ..................................................................................................................................................................... 43 Indirizzo Ethernet .................................................................................................................................................. 44 Tipologia di trasmissione ..................................................................................................................................... 44 Ethernet con ripetitori e hub.............................................................................................................................. 47

Uno standard diffusissimo per le reti “corte”: seriale o RS-232.......................................................... 48 Utilizzi ........................................................................................................................................................................ 49 Storia dello standard............................................................................................................................................. 50 Definizione................................................................................................................................................................ 50 Le unità di misura ................................................................................................................................................. 51 Come è fatto un segnale EIA RS-232............................................................................................................... 52 Il bit di parità........................................................................................................................................................... 54

I SISTEMI PER L’AUTOMAZIONE INDUSTRIALE ...................................................55

Architetture tipiche dei sistemi ........................................................................................................................ 55

La piramide CIM ........................................................................................................................................................ 57 Descrizione dei livelli............................................................................................................................................. 57

Livello 0: sensori, attuatori, tools legati al processo esecutivo ........................................................... 57 Livello 1: Controllo di macchina ................................................................................................................... 58 Livello 2: Controllo di cella ............................................................................................................................. 58 Livello 3: Controllo di area ............................................................................................................................. 59 Livello 4: mainframe per il governo del management, gestione commesse e amministrazione centrale delle attività di fabbrica (pianificazione della gestione globale). ........................................ 59

Lo Scada e le sue caratteristiche....................................................................................................................... 60 Acquisizione dati .................................................................................................................................................... 62 Supervisione ............................................................................................................................................................ 63 Controllo ................................................................................................................................................................... 64

Il Plc e le sue caratteristiche............................................................................................................................... 67 Funzionamento ....................................................................................................................................................... 68 Struttura del PLC ................................................................................................................................................... 69 Cpu ............................................................................................................................................................................. 69 Schede di comunicazione .................................................................................................................................... 70

CANALI DI COMUNICAZIONE PER L’AUTOMAZIONE ...........................................71

Caratteristiche generali dei protocolli usati per l’automazione.......................................................... 71

Sistemi seriali vs Sistemi ethernet .................................................................................................................. 72

I protocolli dei sistemi Omron............................................................................................................................ 73 C-Command............................................................................................................................................................. 73 Fins .............................................................................................................................................................................. 76

IX

Strumenti misti : i bridge ethernet-seriali e le loro caratteristiche .................................................. 80

UN’APPLICAZIONE CONCRETA: CONTROLLO DI PLC OMRON ..........................82

Obiettivo del progetto ............................................................................................................................................ 82

L’architettura del nuovo sistema ...................................................................................................................... 84

I sistemi controllati................................................................................................................................................. 85

I Plc e le strutture associate................................................................................................................................ 86

Lo Scada e le sue caratteristiche....................................................................................................................... 87

La base di dati per la persistenza ...................................................................................................................... 88

Visione di insieme .................................................................................................................................................... 93

IL LAVORO OPERATIVO ..............................................................................................96

Difficoltà incontrate................................................................................................................................................ 96

Correzioni in corso d’opera .................................................................................................................................. 97

CONCLUSIONI ................................................................................................................99

Il sistema in esecuzione ........................................................................................................................................ 99

Bilancio del lavoro svolto...................................................................................................................................... 99

Applicazioni e ampliamenti futuri .................................................................................................................. 100

INDICE DELLE FIGURE..............................................................................................102

BIBLIOGRAFIA .............................................................................................................104

1

INTRODUZIONE

Il contesto del problema: la comunicazione digitale fra dispositivi

Oggetto di questa tesi è quello di implementare un protocollo per

comunicazioni digitali in ambito di rete locale per far comunicare fra loro

sistemi digitali che svolgono compiti completamente diversi. Da un lato

abbiamo l’entità composta da uno o più PC che ospitano gli applicativi di

supervisione. Tali applicativi servono sia a rendere disponibile

un’interfaccia uomo-macchina , semplice e snella , per coloro che utilizzano

le applicazioni, mascherando nel contempo la complessità dei dati e delle

metodologie di comunicazione fra le varie componenti, sia a svolgere le

funzioni di supervisione al normale funzionamento degli apparati cui sono

connessi. Gli applicativi sono connessi anche ad un DBMS avente la

funzione di memorizzare sia i dati di configurazione impostati dagli utenti

sia i numerosi dati acquisiti dagli apparati.. All’altro capo della rete sono

apparati PLC, (Programmable Logic Controller). Un PLC è , in pratica, un

dispositivo programmabile, dotato di ingressi e uscite analogiche e digitali e

una o più connessioni di reti, specializzato nella gestione dei processi

industriali. Il PLC esegue un programma ed elabora i segnali digitali ed

analogici provenienti dai sensori ricevuti attraverso gli ingressi , generando

sulle proprie uscite i corrispondenti comandi per gli attuatori presenti in

un impianto industriale, i quali riescono a gestire una moltitudine di

funzioni dalla più elementare (rilevare la temperatura, accendere una

lampadina, ecc..) alle più sofisticate e complesse (muovere un braccio

meccanico, programmare l’accensione/avviamento di macchine, automi,

ecc..). La tesi si propone di realizzare l’ implementazione dei protocolli

standard che, nell’ambito di contesti aziendali operativi, con tutti i vincoli

che caratterizzano tali ambienti, permettendo la comunicazione efficiente

fra PC e PLC su supporti di rete Ethernet-TCP\IP e RS-232. Nella seconda

2

parte della tesi verrà presentata l’applicazione operativa dei software così

sviluppati entro il contesto di un’azienda di medie dimensioni, per

realizzare la gestione integrata di alcuni impianti tecnologici come ad

esempio l’apertura e chiusura meccanica di porte e finestre, l’accensione

della fontana situata nel giardino dell’azienda, l’avviamento di

riscaldamento e climatizzatore e, oltre a questi aspetti prettamente

domotici, per gestire anche l’accensione e spegnimento di impianti

propriamente industriali, quali bruciatori, compressori, presse. Il tirocinio e

l’allegato progetto sono stati compiuti presso l’azienda CS Soluzioni di

Casalmaggiore (CR).

Come è stato affrontato il lavoro

I protocolli di comunicazione da realizzare devono essere snelli,

minimizzando gli overhead di carico, per permettere un comunicazione in

tempo reale ma, allo stesso tempo, anche robusti rispetto a diversi tipi di

canale fisico(Ethernet,RS-232) ad adatti ad un’ applicazion a sistemi reali.

La tesi e stata svolta operando in particolare con i sistemi PLC Omron,

tecnologia italiana molto diffusa presso le medie imprese. Omron utilizza

due protocolli, proprietari ma ampliamente documentati, per la

comunicazione: il protocollo C-Command, più vecchio, per la

comunicazione su canale RS-232 ed il protocollo FINS, più recente e

completamente rinnovato rispetto al precedente per la comunicazione su

canali TCP/IP su Ethernet. La prima parte della tesi è consistita nello

studio dei due protocolli, cui e seguita l’implementazione, debug e verifica

su piattaforma hardware reale dei due protocolli, realizzando la

trasmissione bidirezionale di byte ed array di byte, contenenti le

informazioni opportune, tra la memoria del PC e la memoria del PLC,

utilizzando il linguaggio C# di microsoft con l’ambiente di sviluppo

integrato Visual Studio 2008. Una volta ottenuto una comunicazione

bidirezionale funzionate efficace, le librerie di comunicazione così ottenute

3

sono state integrate in un sistema molto complesso atto a governare reti di

PLC Omron che controllano impianti industriali quali compressori,

bruciatori, ventilatori e infrastrutture edilizie come le finestre superiori dei

capannoni. Tale sistema è costituito da una piattaforma SCADA con

opportuna interfaccia utente , realizzata completamente il linguaggio C#

con architettura pienamente Objet-oriented e stratificata, da una base di

dati in un RDBMS Oracle 10g Express, dalle librerie di comunicazione e da

reti di PLC Omron, connessi ai PC industriali ove operano le console

grafiche dello SCADA in alcuni casi tramite connessione RS-232 e in alcuni

casi tramite Ethernet. E’ stato inoltre verificato l’uso di un componente di

conversione seriale-Ethernet che però, per poter essere utilizzato nelle sue

piene potenzialità, ha richiesto l’inserimento di nuove strutture software

nel sistema. In collaborazione con le persone di CS Soluzioni incaricate

della realizzazione del sistema si è contribuito ad ogni sua fase, in

particolare al design della base di dati, come sarà presentato in dettaglio

nei capitoli seguenti. La struttura della tesi nei capitoli successivi è la

seguente: Saranno presentate in primo luogo le reti di comunicazione, per

contestualizzare in modo adeguato il cuore del lavoro, ossia lo sviluppo del

protocollo di comunicazione. Successivamente sarà presentato in dettaglio

il contesto software di super visione entro i sistemi di automazione

industriale e , in particolare , la struttura dei protocolli Fins e C-Command

di Omron; Nel capitolo seguente sarà presentato il progetto svolto nei suoi

vari aspetti, partendo dalle librerie di comunicazione per arrivare ala

visione del sistema nel suo insieme. Infine saranno presentate le

conclusioni con un bilancio del lavoro svolto ed eventuali prospettive di

sviluppo.

4

LA COMUNICAZIONE DIGITALE

Le reti di comunicazioni

Il ‘900 fu, dal punto di vista della strumentazione tecnologica, un

susseguirsi di successi. Principalmente nell’ ultimo cinquantennio,

l’attenzione degli studiosi fu rivolta a nuove metodologie di informazione,

che possono essere sintetizzate in tre punti:

• raccolta e memorizzazione;

• elaborazione;

• distribuzione.

Nel nostro secolo si sono via via diffusi:

• il sistema telefonico, a livello mondiale;

• la radio e la televisione;

• il computer;

• i satelliti per telecomunicazioni.

Queste tecnologie stanno rapidamente convergendo, in particolare, la

combinazione di elaboratori e sistemi di telecomunicazione ha avuto una

profonda influenza sull'organizzazione dei sistemi di calcolo. Infatti si è

passati dal vecchio modello mainframe - terminali, in cui la potenza di

calcolo è concentrata in un unico grande elaboratore, a cui si accede per

mezzo di un certo numero di terminali, a quello attuale, in cui vi è un

grande numero di elaboratori autonomi, interconnessi fra loro. Per

autonomi si vuole intendere che non deve esserci fra loro una relazione tipo

master/slave (ad es., l'uno non può forzare lo spegnimento dell'altro) bensì

interconnessione che sta a significare la capacità di scambiarsi

informazioni (sfruttando un opportuno mezzo fisico). Un sistema di calcolo

siffatto è detto rete di elaboratori o computer network. Rete di elaboratori

non è sinonimo di sistema distribuito. Infatti in un sistema distribuito

l'esistenza di più elaboratori è invisibile all'utente, che ha l'impressione di

avere a che fare con un unico sistema di calcolo; in una rete di elaboratori,

5

l'utente è conscio dell'esistenza di molteplici elaboratori, che devono essere

esplicitamente riferiti.

Applicazioni delle reti

Moltissimi sono gli usi delle reti di elaboratori, sia per le organizzazioni che

per i singoli individui. Per le aziende, associazioni, organizzazione si

possono sintetizzare in questi piccoli punti:

• condivisione di risorse: si possono rendere disponibili a qualsiasi

programma e informazioni anche distanti migliaia di km;

• affidabilità: si ottiene mettendo in rete sorgenti alternative delle

risorse (ad es. duplicando le applicazioni e i dati su più computer).

E' importante in sistemi che devono funzionare a tutti i costi

(traffico aereo, centrali nucleari, sistemi militari, ecc.);

• diminuzione dei costi: una rete di personal computer costa molto

meno di un mainframe. A volte alcuni elaboratori sono più potenti

ed offrono agli altri dei servizi (modello client-server, vedi figura

sottostante);

• scalabilità: si possono aumentare le prestazioni del sistema

aumentando il numero di elaboratori (entro certi limiti);

• comunicazione fra persone: è possibile inviarsi messaggi,

scambiarsi file, ecc.

6

Richiesta

Risposta

Rete

Elab. cliente Elab. server

Proc. cliente Proc. server

Figura 1-1: Il modello client-server

Per i singoli individui (di solito da casa propria tramite "fornitori di

accesso": viene usata per l’accesso ad informazioni remote, (ad es.:accesso

a servizi bancari, acquisti da casa; navigazione sul World Wide Web);

oppure per la comunicazioni fra persone (posta elettronica); divertimento:

video on demand (selezione e ricezione via rete di un qualunque spettacolo

tratto da un catalogo); giochi interattivi (contro macchine o avversari

umani).

Aspetti hardware delle reti

I due parametri utili per definire le caratteristiche di una rete, anche se

non vi é una tassonomia universalmente accettata, sono:

la tecnologia trasmissiva e la scala dimensionale.

Tecnologia trasmissiva

Esistono due tipologie per quanto riguarda la tecnologia trasmissiva e sono:

le reti broadcast e le reti punto a punto. Una rete broadcast è

caratterizzata da processi di comunicazione punto-multipunto, in cui i

singoli nodi sono connessi tramite lo stesso supporto trasmissivo. Se sono

presenti supporti trasmissivi di tipo diverso occorre che alcuni nodi

svolgano la funzione di gateway (repeater o bridge) rigenerando

7

l'informazione in modo da essere propagata sul nuovo supporto. In alcuni

casi è possibile che si voglia impedire tale funzionalità e quindi il gateway

sarà sostituito da un router configurato per filtrare il traffico (firewall).

Se gli elementi della rete utilizzano supporti trasmissivi condivisi, il

principale problema che è necessario affrontare è la gestione dei conflitti

nell'uso della rete, per cui esistono diverse tecniche di gestione e di

risoluzione (aloha,csma,csma/cd ...). Le reti broadcast sono dotate di un

unico "canale" di comunicazione che è condiviso da tutti gli elaboratori.

Brevi messaggi, spesso chiamati pacchetti, inviati da un elaboratore sono

ricevuti da tutti gli altri elaboratori. Un indirizzo all'interno del pacchetto

specifica il destinatario.

Rete

Elaboratori

Figura 1-2: una rete broadcast

Quando un elaboratore riceve un pacchetto, esamina l'indirizzo di

destinazione; se questo coincide col proprio indirizzo il pacchetto viene

elaborato, altrimenti viene ignorato. Le reti broadcast, in genere,

consentono anche di inviare un pacchetto a tutti gli altri elaboratori,

usando un opportuno indirizzo (broadcasting). Tutti prendono in

considerazione il pacchetto. Un'altra possibilità è inviare il pacchetto ad un

sottoinsieme degli elaboratori (multicasting). In tal caso solo gli elaboratori

di tale sottoinsieme lo prendono in considerazione, gli altri lo ignorano. Le reti punto a punto consistono invece in un insieme di connessioni fra

coppie di elaboratori.

8

Elaboratore

Connessione

Pacchetto

Figura 1-3: una rete punto a punto

Per arrivare dalla sorgente alla destinazione, un pacchetto può dover

attraversare uno o più elaboratori o nodi intermedi. Spesso esistono più

cammini alternativi, per cui gli algoritmi di instradamento (routing) hanno

un ruolo molto importante. In generale le reti geograficamente localizzate

tendono ad essere broadcast; mentre le reti geograficamente molto estese

tendono ad essere punto a punto. Esistono però alcune eccezioni, ad

esempio la rete geografica realizzata via satellite (e quindi broadcast) ed

infine la rete locale basata su ATM (e quindi punto a punto).

Scala dimensionale

Un criterio alternativo di classificazione è la scala dimensionale delle reti.

In questo contesto si distinguono: reti locali, reti metropolitane e reti

geografiche.

9

Distanza fra processori Ambito Tipo di rete

10 m. Stanza Rete locale

100 m. Edificio Rete locale

1 km. Campus Rete locale

10 km. Città Rete metropolitana

100 km. Nazione Rete geografica

1000 km. Continente Rete geografica

10.000 km. Pianeta Internet

(Rete geografica)

La distanza è un fattore molto importante, poiché a differenti scale

dimensionali si usano differenti tecniche.

Reti Locali

Le reti locali (Local Area Network, LAN), in genere sono possedute da una

organizzazione (reti private), hanno un'estensione che arriva fino a qualche

km, si distendono nell'ambito di un singolo edificio o campus (non si

possono, di norma, posare cavi sul suolo pubblico), sono utilizzate

prevalentemente per connettere PC o workstation. Esse si distinguono dagli

altri tipi di rete per tre caratteristiche diverse: La prima è la dimensione

che non può andare oltre un certo limite, per cui è noto a priori il tempo e

quindi il ritardo di trasmissione. Questa conoscenza permette di utilizzare

delle tecniche particolari per la gestione del canale di comunicazione.

La seconda è la tecnologia trasmissiva. Le LAN sono in generale reti

broadcast. Velocità di trasmissione tipiche sono da 10,100,1000 Mbps con

basso ritardo di propagazione del segnale da un capo all'altro del canale e

basso tasso di errore. Ultima ma non meno importante é la topologia: sono

possibili diverse topologie, le più diffuse alcuni anni fa erano il bus ed il

ring. Nell’ambito della topologia bus in ogni istante solo un elaboratore può

10

trasmettere, gli altri devono astenersi, inoltre è necessario un meccanismo

di arbitraggio per risolvere i conflitti quando due o più elaboratori vogliono

trasmettere contemporaneamente e l'arbitraggio può essere centralizzato o

distribuito; lo standard IEEE 802.3 (chiamato impropriamente Ethernet) è

per una rete broadcast, basata su un bus, con arbitraggio distribuito,

operante a 10,100 oppure 1000 Mbps; infine gli elaboratori trasmettono

quando vogliono; esistono alcuni protocolli, che permettono di evitare le

collisioni. Nella topologia ring ogni bit circumnaviga l'anello in un tempo

tipicamente inferiore a quello di trasmissione di un pacchetto. Anche qui è

necessario un meccanismo di arbitraggio (spesso basato sul possesso di un

gettone (token) che abilita alla trasmissione. Lo standard IEEE 802.5

(derivante dalla rete IBM Token Ring) è una rete broadcast basata su ring,

con arbitraggio distribuito, operante a 4 o 16 Mbps.

Bus

Ring

Figura 1-4: topologie bus e ring

Infine le reti broadcast possono essere classificate a loro volta in due

sottogruppi a seconda del meccanismo scelto per l'arbitraggio. Il primo é

allocazione statica: le regole per decidere chi sarà il prossimo a trasmettere

sono fissate a priori, ad esempio assegnando un time slot ad ogni

elaboratore con un algoritmo round-robin. Lo svantaggio è rappresentato

dallo spreco dei time slot assegnati a stazioni che non devono trasmettere.

Il secondo è allocazione dinamica: si decide di volta in volta chi sarà il

prossimo a trasmettere; è necessario un meccanismo di arbitraggio delle

11

contese, che può essere anche in questo caso un arbitraggio centralizzato,

un’apposita apparecchiatura, ad esempio, una bus arbitration unit, che

accetta richieste di trasmissione e decide chi abilitare oppure può essere

un arbitraggio distribuito: ognuno decide per conto proprio.

Reti metropolitane

Le reti metropolitane (Metropolitan Area Network, MAN) hanno

un'estensione tipicamente urbana (quindi anche molto superiore a quella di

una LAN) e sono generalmente pubbliche (cioè un'azienda, ad es. Telecom

Italia, Ommitel, Infostrada mettono la rete a disposizione di chiunque

desideri, previo pagamento di una relativa tariffa). Fino a qualche anno fa

erano basate essenzialmente sulle tecnologie delle reti geografiche,

utilizzate su scala urbana. Recentemente però è stato definito un apposito

standard, lo IEEE 802.6 o DQDB (Distributed Queue Dual Bus), che é

effettivamente impiegato in varie realizzazioni, molto più vicino alla

tecnologia LAN che WAN. Esiste un mezzo trasmissivo di tipo broadcast

(due bus in 802.6) a cui tutti i computer sono attaccati.

Head end

Head end

…

Flusso

Flusso

Elaboratore

Figura 1-5: Distributed Queue Dual Bus

Ogni bus (cavo coassiale o fibra ottica) é unidirezionale, ed ha una head-

end che modula l'attività di trasmissione.

12

Reti geografiche

Le reti geografiche (Wide Area Network, WAN) si estendono a livello di una

nazione, di un continente o dell'intero pianeta. Una WAN è tipicamente

costituita da due componenti distinte: un insieme di elaboratori (host

oppure end system), sui quali girano i programmi usati dagli utenti una

comunication subnet (o subnet), che connette gli end system fra loro. Il suo

compito è trasportare messaggi da un end system all'altro, così come il

sistema telefonico trasporta parole da chi parla a chi ascolta. Di norma la

subnet è costituita, a sua volta, da due componenti: linee di trasmissione

(dette anche circuiti, canali, trunk) e elementi di commutazione (switching

element). Gli elementi di commutazione sono elaboratori specializzati

utilizzati per connettere fra loro due o più linee di trasmissione. Quando

arrivano dati su una linea, l'elemento di commutazione deve scegliere una

linea in uscita sul quale instradarli. Non esiste una terminologia standard

per identificare gli elementi di commutazione. Termini usati sono i sistemi

intermedi, i nodi di commutazione pacchetti o router. Una tipica WAN è

utilizzata per connettere più LAN fra loro:

Subnet

WAN

LAN

Router

Host

Linea di trasmiss.

Figura 1-6: struttura tipica di una WAN

13

In generale una WAN contiene numerose linee (spesso telefoniche), che

congiungono coppie di router. Ogni router, in generale, deve: ricevere un

pacchetto da una linea in ingresso, memorizzarlo per intero in un buffer

interno ed infine, appena la necessaria linea in uscita è libera, instradare il

pacchetto su essa. Una subnet basata su questo principio può essere

chiamata: punto a punto, store and forward o a commutazione di pacchetto

(packet switched).Molte topologie di interconnessione possono essere

impiegate fra i router:

• a stella (ridondanza zero);

• ad anello (ridondanza zero);

• ad albero (ridondanza zero);

• magliata (ridondanza media);

• completamente connessa (ridondanza massima).

Stella AlberoAnello

Compl. connessaMagliatura

Figura 1-7: topologie di interconnessione

14

Un'altra possibilità è una WAN basata su satellite oppure radio al suolo.

Utilizzando il satellite cioè ogni router sente l'output del satellite e invia a

sua volta dati al satellite. Dunque, in generale si ha un broadcast downlink

(cioè dal satellite a terra) e broadcast uplink (cioè da terra al satellite) .

Satellite

Router + antenna Router + antenna

Downlink beam

Uplink beam

Figura 1-8: interconnessione di router via satellite

Ogni router quindi utilizza onde Radio al suolo: ogni router sente l'output

dei propri vicini (entro una certa distanza massima) ed anche in questo

caso siamo in presenza di una rete broadcast.

Router + antenna Router + antennaRouter + antenna

Area di copertura del segnale

Figura 1-9: interconnessione di router via radio al suolo

Una WAN può essere anche realizzata in maniera mista: in parte cablata,

in parte basata su radio o satellite.

15

Interconnessione di reti

Una interconnessione di reti, talvolta anche chiamata internetwork, è

formata quando reti diverse (sia LAN che MAN o WAN) sono collegate fra

loro. A prima vista, almeno in alcuni casi, la cosa è apparentemente uguale

alla definizione di WAN vista precedentemente (se al posto di subnet si

scrive WAN, abbiamo una internetwork costituita da una WAN e quattro

LAN). Alcuni problemi però sorgono quando si vogliono connettere fra di

loro reti progettualmente diverse (spesso incompatibili fra loro). In questo

caso si deve ricorrere a speciali attrezzature, dette gateway (o router

multiprotocollo), che, oltre ad instradare i pacchetti da una rete all'altra,

effettuano le operazioni necessarie per rendere possibili tali trasferimenti.

WAN 1 WAN 1

Router multiprotocollo (gateway)

Figura 1-10: interconnessione di reti

In questo contesto e concretamente è utilizzata questa terminologia:

internet come sinonimo di internetwork, cioè la interconnessione di più reti

generiche; ed Internet (con la I maiuscola) per riferirsi alla specifica

internetwork, basata su TCP/IP, che ormai tutti conoscono.

L’ uso della terminologia non è sempre preciso ed univoco.

Si indica:

• con sottorete (subnet): l'insieme dei router e delle linee di

trasmissione;

• con rete (network): una subnet più tutti gli host collegati;

16

• con internetwork: una collezione di più network, anche non

omogenee, collegate per mezzo di gateway.

Subnet

Host

Network

Gateway

Subnet

Host

Network

Internetwork

Figura 1-11: relazioni fra subnet, network e internetwork

Protocolli e aspetti software delle reti

Le prime reti furono progettate cominciando dall'hardware e sviluppando il

software solo successivamente, quasi come se esso fosse un'accessoria

appendice dell'hardware. Questo approccio non può più funzionare.

Il SW di rete è oggi altamente strutturato. Vogliamo esaminare ora, a

grandi linee, tale strutturazione, che servirà come base per introdurre il

lavoro svolto.

Gerarchie di protocollo

Per ridurre la complessità di progetto, le reti sono in generale organizzate a

livelli, ciascuno costruito sopra il precedente. Fra un tipo di rete ed

un’altra possono essere diversi: il numero, i nomi, il contenuto e le funzioni

dei livelli. Comunque è sempre rispettato il principio generale secondo il

17

quale lo scopo di un livello è offrire certi servizi ai livelli più alti,

nascondendo i dettagli sul come tali servizi siano implementati.

• Il livello n su un host porta avanti una conversazione col livello n su

di un'altro host.

• Le regole e le convenzioni che governano la comunicazione sono

collettivamente indicate col termine di protocollo.

• Le entità (processi) che effettuano tale conversazione si chiamano

peer entity (entità di pari livello).

Livello 5 Livello 5

Livello 4 Livello 4

Livello 3 Livello 3

Livello 2 Livello 2

Livello 1 Livello 1

Protocollo di livello 5





Interfaccia liv. 4/5








HOST 1 HOST 2

Mezzo fisico Figura 1-12: Dialogo fra peer entity

In realtà non c'è un trasferimento diretto dal livello n di host 1 al livello n di

host 2. Ogni livello di host 1 passa i dati, assieme a delle informazioni di

controllo, al livello sottostante. Al di sotto del livello 1 c'è il mezzo fisico,

attraverso il quale i dati vengono trasferiti da host 1 ad host 2. Quando

arrivano a host 2, i dati vengono passati da ogni livello (a partire dal livello

1) a quello superiore, fino a raggiungere il livello n. Fra ogni coppia di livelli

adiacenti è definita una interfaccia, che caratterizza sia le operazioni

primitive, che possono essere richieste al livello sottostante e i servizi, che

18

possono essere offerti dal livello sotto di esso. I vantaggi di una buona

progettazione delle interfacce sono la minimizzazione delle informazioni da

trasferire e la possibilità di modificare l'implementazione del livello (ad es.,

ove le linee telefoniche venissero sostituite da canali satellitari) con una più

attuale che offra gli stessi servizi.

Architettura di rete

L'insieme dei livelli e dei relativi protocolli è detto architettura di rete. La

specifica dell' architettura deve essere abbastanza dettagliata da consentire

la realizzazione di SW e/o HW che, per ogni livello, rispetti il relativo

protocollo. Viceversa, i dettagli implementativi di ogni livello e le interfacce

fra livelli non sono parte dell'architettura, in quanto sono nascosti

all'interno di un singolo host. E' quindi possibile che sui vari host della rete

ci siano implementazioni che differiscono fra di loro anche in termini di

interfacce fra livelli, purché ogni host implementi correttamente i protocolli

previsti dall'architettura. In questo caso possono dialogare fra loro anche

host aventi caratteristiche (processore, sistema operativo, costruttore)

diverse. Dunque, nell'ambito di una specifica architettura di rete, si ha che

tutti gli host devono contenere implementazioni conformi in termini di

livelli e di protocolli. Un'architettura di rete può essere: proprietaria,

standard de facto, standard de iure.

Un'architettura proprietaria è basata su scelte indipendenti ed arbitrarie

del costruttore ed è generalmente incompatibile con architetture diverse.

Nel senso più stretto del termine è un'architettura per la quale il

costruttore non rende pubbliche le specifiche, per cui nessun altro può

produrre apparati compatibili. Alcuni esempi sono IBM SNA (System

Network Architecture), Digital Decnet Phase IV; Novell IPX e Appletalk.

Un'architettura standard de facto è un'architettura basata su specifiche di

pubblico dominio (per cui diversi costruttori possono proporre la propria

19

implementazione) che ha conosciuto una larghissima diffusione. L’esempio

lampante di questa architettura é Internet Protocol Suite (detta anche

architettura TCP/IP).

Un'architettura standard de iure è un'architettura basata su specifiche

(ovviamente di pubblico dominio) approvate da enti internazionali che si

occupano di standardizzazione. Anche in questo caso ogni costruttore può

proporne una propria implementazione. Nello specifico possono essere

considerate standard de iure standard IEEE 802 per le reti locali;

architettura OSI (Open Systems Interconnection) e Decnet Phase V

(conforme allo standard OSI). L'insieme dei protocolli utilizzati su un host e

relativi ad una specifica architettura di rete va sotto il nome di pila di

protocolli (protocol stack). Si noti che un host può avere

contemporaneamente attive più pile di protocolli per eventualmente

comunicare con host differenti.

Funzionamento del software di rete

Per comprendere i meccanismi basilari di funzionamento del software di

rete si può pensare alla seguente analogia umana, nella quale un filosofo

indiano vuole conversare con uno stregone africano:

Filosofo indù (parla solo industano)

Stregone africano (parla solo swahili)

Traduttore Traduttore

Segretaria Segretaria

Dialogo sui massimi sistemi

Uso della lingua inglese

Uso del fax

Mezzo fisico Figura 1-13: Dialogo fra grandi menti

20

Nel caso delle reti, la comunicazione fra le due entità di livello superiore

avviene con una modalità che, almeno in linea di principio, è uguale in

tutte le architetture di rete:





HOST 1 HOST 2

M

MH4

H4H3 M2H3M1

H4H3 M1H2 T2 M2H3H2 T2

M

MH4

H4H3 M2H3M1

H4H3 M1H2 T2 M2H3H2 T2

Canale fisico

Figura 1-14: Flusso dell'informazione fra peer entity

Il programma applicativo (livello 5) deve mandare un messaggio M alla sua

peer entity. Il livello 5 consegna M al livello 4 per la trasmissione, il livello

4 aggiunge un suo header in testa al messaggio questo header contiene

informazioni di controllo, tra le quali: numero di sequenza del messaggio;

dimensione del messaggio, time stamp e priorità. Il livello 4 consegna il

risultato al livello 3, il quale può trovarsi nella necessità di frammentare i

dati da trasmettere in unità più piccole, (pacchetti) a ciascuna delle quali

aggiunge il suo header. Il livello 3 passa i pacchetti al livello 2. A questo

21

punto il livello 2 aggiunge ad ogni pacchetto il proprio header (e magari un

trailer) e lo spedisce sul canale fisico; nella macchina di destinazione i

pacchetti fanno il percorso inverso, con ogni livello che elimina

(elaborandoli) l'header ed il trailer di propria competenza, e passa il resto al

livello superiore. Si possono definire alcuni aspetti importanti: le peer

entity pensano concettualmente ad una comunicazione orizzontale fra loro,

basata sul protocollo del proprio livello, mentre in realtà comunicano

ciascuna col livello sottostante attraverso l'interfaccia fra i due livelli;

spesso i livelli bassi sono implementati in hardware o firmware (per ragioni

di efficienza). Nonostante questo, spesso gli algoritmi di gestione sono

complessi.

Servizi connection-oriented e connectionless

Ci sono due principali classi di servizi offerti da un livello a quello

superiore: servizi connection-oriented e servizi connectionless.

Servizi connection-oriented

I servizi connection-oriented sono modellati secondo il sistema telefonico,

dove per parlare con qualcuno si alza il telefono, si chiama, si parla e poi si

riattacca. Ovvero: si stabilisce una connessione; si scambiano informazioni

e si rilascia la connessione. Analogamente, un servizio connection-oriented

si sviluppa in 3 fasi:

1. si stabilisce una connessione, cioè si crea con opportuni mezzi un

"canale di comunicazione" fra la sorgente e la destinazione. La relativa

attività tipicamente coinvolge un certo numero di elaboratori nel

cammino fra sorgente e destinazione;

2. la connessione, una volta stabilita, agisce come un tubo digitale lungo il

quale scorrono tutti i dati trasmessi, che arrivano nello stesso ordine in

cui sono partiti;

22

3. si rilascia la connessione (attività che coinvolge di nuovo tutti gli

elaboratori sul cammino).

Sorgente Destinazion

Pacchetto

(a)

Sorgente Destinazion

(b)

Connessione

Figura 1-15: Servizi connection-oriented (a) e connectionless (b)

Servizi connectionless

I servizi connectionless sono modellati secondo il sistema postale: ogni

lettera viaggia indipendentemente dalle altre; arriva quando arriva, e forse

non arriva. Inoltre, due lettere con uguale mittente e destinatario possono

viaggiare per strade diverse. Analogamente, in un servizio connectionless, i

23

pacchetti viaggiano indipendentemente gli uni dagli altri, possono prendere

strade diverse ed arrivare in ordine diverso da quello di partenza o non

arrivare affatto. La fase è una sola : invio del pacchetto (corrisponde

all'immissione della lettera nella buca).

Affidabilità del servizio

Un servizio è generalmente caratterizzato dall'essere o no affidabile (reliable). Un servizio affidabile non perde mai dati, cioè assicura che tutti i

dati spediti siano consegnati al destinatario. Ciò generalmente richiede che

il ricevente invii un acknowledgement (conferma) alla sorgente per ogni

pacchetto ricevuto. Si introduce ovviamente overhead, che in certe

situazioni può non essere desiderabile. Viceversa, un servizio non

affidabile non offre la certezza che i dati spediti arrivino effettivamente a

destinazione. Si noti che se un certo livello non offre nessun servizio

affidabile, qualora tale funzionalità sia desiderata dovrà essere fornita da

almeno uno dei livelli superiori (cosa che accade spesso). Si propongono

ora alcuni esempi di protocolli specifici aventi lo scopo di migliorare

l’affidabilità:

⇒ reliable connection oriented: trasferimento di file (non devono

mancare pezzi e il file non deve essere "rimescolato");

⇒ non reliable connection oriented: nelle trasmissioni isocrone

(stremming audio e video ) le relazioni temporali fra i bit del

flusso devono essere mantenute. E' meglio qualche disturbo

ogni tanto, piuttosto che interruzioni momentanee, ma

avvertibili del flusso di dati;

⇒ non reliable connectionless (detto anche datagram service, da

telegram): distribuzione di posta elettronica pubblicitaria, non

importa se qualche messaggio si perde.

24

⇒ reliable connectionless (detto anche acknowledged datagram

service): si invia un breve messaggio e si vuole essere

assolutamente sicuri che è arrivato.

Servizi vs protocolli

Servizi e protocolli sono spesso confusi, ma sono concetti ben distinti. Il

servizio è un insieme di operazioni primitive che un livello offre al livello

superiore. Come queste operazioni siano implementate non riguarda il

livello superiore. Mentre il protocollo rappresenta un insieme di regole che

governano il formato ed il significato delle informazioni (messaggi, frame,

pacchetti) che le peer entity si scambiano fra loro. Le entità usano i

protocolli per implementare i propri servizi

Livello n Livello n

Livello n - 1 Livello n - 1

Protocollo

Protocollo

Servizi Servizi

HOST 1 HOST 2

Figura 1-16: Relazione fra protocolli e servizi

Aspetti di progetto dei livelli

Le decisioni che governano l’utilizzo e la scelta implementativa di un

protocollo sono:

1. Meccanismi di identificazione di mittente e destinatario (cioè

indirizzamento), in ogni livello.

25

2. Regole per il trasferimento dati (livelli bassi):

• in una sola direzione (simplex connection);

• in due direzioni ma non contemporaneamente (half-duplex

connection).

• in due direzioni contemporaneamente (full-duplex connection);

3. Meccanismi per il controllo degli errori di trasmissione; è possibile:

• rilevarli oppure no;

• correggerli oppure no;

• avvertire il mittente oppure no.

4. Meccanismi per il mantenimento (o la ricostruzione) dell'ordine originario

dei dati.

5. Meccanismi per regolare le velocità di sorgente e destinazione.

6. Decisioni sulla dimensione (minima o massima) dei messaggi da inviare,

e su come eventualmente frammentarli.

7. Meccanismi di multiplexing di varie "conversazioni" su di un'unica

connessione (se stabilire la connessione è costoso).

8. Meccanismi di routing dei messaggi, se esistono più strade alternative,

ed eventualmente di suddivisione di una "conversazione" su più

connessioni contemporaneamente (per aumentare la velocità di

trasferimento dei dati).

Modelli di riferimento nel mondo delle reti

Iniziamo ad esaminare due importanti realtà nel mondo delle reti: per

primo il modello OSI Reference Model che è senza dubbio determinante per

la creazione e l’utilizzo di Internet Protocol Suite (detta anche architettura

TCP/IP o, piuttosto impropriamente, TCP/IP reference model). Un modello

di riferimento è cosa diversa da un'architettura di rete: esso definisce il

numero, le relazioni e le caratteristiche funzionali dei livelli, ma non

26

determina i protocolli effettivi. L’architettura di rete invece fissa, livello per

livello, i protocolli effettivi

Il modello ISO/OSI

L'OSI (Open Systems Interconnection) Reference Model è il frutto del lavoro

della ISO (International Standard Organization), ed ha lo scopo di fornire

uno standard per la connessione di sistemi aperti, cioè in grado di

colloquiare gli uni con gli altri, una base comune per lo sviluppo di

standard per l'interconnessione di sistemi e un modello rispetto cui

confrontare le varie architetture di rete. Esso non include di per se la

definizione di protocolli specifici. Sono stati seguiti durante lo sviluppo del

modello OSI alcune regole fondamentali tra le quali :

• ogni livello deve avere un diverso livello di astrazione;

• ogni livello deve avere una funzione ben definita;

• la scelta dei livelli deve:

• minimizzare il passaggio delle informazioni fra di essi;

• evitare troppe funzioni in un livello, ma contemporaneamente non

eccedere nella quantità dei livelli.

Il modello OSI consiste di 7 livelli strutturati seguendo le regole sopra

citate.

27

Fisico Fisico

HOST 1 HOST 2

Data Link Data Link

Network Network

Transport Transport

Session Session

ROUTER ROUTER

Presentation Presentation

Application ApplicationApplication protocol

Presentation protocol

Session protocol

Application protocol

Network Network

Data Link Data Link

Fisico Fisico

Subnet di comunicazione

Protocolli host - router Protocolli router - router Protocolli host - router

1

2

3

4

5

6

7

Figura 1-17: Il modello OSI

Spesso, per visualizzare le competenze (in termini di livelli gestiti) dei vari

elaboratori sul cammino, si usano diagrammi simili al seguente:

28

HOST 1

1

2

3

4

5

6

7

HOST 2

ROUTER ROUTER

1

2

3

1

2

3

1

2

3

4

5

6

7

Figura 1-18: Rappresentazione schematica dei livelli gestiti lungo un cammino

Si noti che il modello OSI non è un'architettura di rete, perché suggerisce

solo cosa devono fare i livelli, ma non stabilisce né i servizi né i protocolli.

Per questo esistono separati documenti di definizione degli standard.

Livello fisico

Ha a che fare con la trasmissione di bit "grezzi" su un canale di

comunicazione. Gli aspetti di progetto sono volti a garantire che se parte

un 1, arrivi effettivamente un 1 e non uno zero e largamente riguardanti le

caratteristiche meccaniche, elettriche e procedurali delle interfacce di rete

(componenti che connettono l'elaboratore al mezzo fisico) e quelle relative al

mezzo fisico. Si caratterizzano alcune grandezze fisiche tra le quali:

tensioni, scelte per rappresentare 0 ed 1, durata (in microsecondi) di un

bit; trasmissione simultanea in due direzioni oppure non meno importane

la forma dei connettori.

29

Livello Data Link

Lo scopo di questo livello è far si che un mezzo fisico trasmissivo appaia, al

livello superiore, esente da errori di trasmissione non rilevati.

Normalmente funziona in questo modo: spezzetta i dati provenienti dal

livello superiore in frame (da qualche centinaia a qualche migliaia di byte),

invia i frame in sequenza; aspetta un acknowledgement frame (ack) per

ogni frame inviato. Il livello Data Link deve offrire questi servizi:

• aggiungere delimitatori (framing) all'inizio ed alla fine del frame;

• gestire errori di trasmissione causati da: errori in ricezione; perdita di

frame; duplicazione di frame (da perdita di ack);

• regolare il traffico (per impedire che il ricevente sia "sommerso" di

dati);

• implementare meccanismi per l'invio degli ack: frame separati (che

però competono col regolare traffico nella stessa direzione);

piggybacking (da pickaback, cioè trasportare sulle spalle).

Le reti broadcast hanno l’ulteriore problema del controllo dell'accesso al

canale trasmissivo, che è condiviso. Per questo hanno uno speciale

sottolivello del livello data link, il sottolivello MAC (Medium Access Control).

Livello Network

Lo scopo del livello è controllare il funzionamento della subnet di

comunicazione. Inizialmente tale livello offriva solamente servizi connection

oriented; successivamente fu aggiunta la modalità connectionless. Il livello

Network deve offrire questi servizi:

30

• routing: cioè scelta del cammino da utilizzare. Il suddetto può essere

statico (fissato ogni tanto e raramente variabile) o dinamico

(continuamente aggiornato, anche da un pacchetto all'altro);

• gestione della congestione: a volte troppi pacchetti arrivano ad un

router (es.: da molte linee in ingresso ad un unica linea di uscita);

• accounting: in cui gli operatori della rete possono far pagare l'uso

agli utenti sulla base del traffico generato;

• conversione di dati nel passaggio fra una rete ed un'altra (diversa) e

quindi indirizzi da rimappare; pacchetti da frammentare; protocolli

diversi da gestire.

Livello Transport

Lo scopo di questo livello è accettare dati dal livello superiore, spezzettarli

in pacchetti, passarli al livello network ed assicurarsi che arrivino alla peer

entity che si trova all'altra estremità della connessione. In più, fare ciò

efficientemente, isolando i livelli superiori dai cambiamenti della tecnologia

di rete sottostante. Il livello transport è il primo livello realmente end-to-

end, cioè da host sorgente a host destinatario: le peer entity di questo

livello portano avanti una conversazione senza intermediari. Si noterà che

certe problematiche sono, in ambito end-to-end, le stesse che il livello data

link ha nell'ambito di una singola linea di comunicazione; le soluzioni però

sono alquanto diverse per la presenza della subnet di comunicazione. I suoi

compiti sono quelli di creare connessioni di livello network (attraverso i

propri servizi) ; creare un canale punto a punto affidabile, che consegni i

dati in ordine e senza errori (il servizio più diffuso, connection oriented);

inviare messaggi isolati, con o senza garanzia di consegna (connectionless);

ed infine broadcasting di messaggi a molti destinatari (connectionless).

31

Livello Session

Ha a che fare con servizi più raffinati che non sono quelli del transport

layer, come ad es.: token management: autorizza le due parti, a turno, alla

trasmissione. Come vedremo nel seguito, questo livello non ha mai avuto

un grande successo.

Livello Presentation

E' interessato alla sintassi ed alla semantica delle informazioni da

trasferire. Ad esempio, si occupa di convertire tipi di dati standard

(caratteri, interi) da rappresentazioni specifiche della piattaforma HW di

partenza in una rappresentazione "on the wire" e poi in quella specifica dell'

HW di arrivo. Anche questo livello non ha avuto molto successo.

Livello Application

Prevede che qui risieda tutta la varietà di protocolli che sono necessari per

offrire i vari servizi agli utenti, quali ad esempio: terminale virtuale;

trasferimento file; posta elettronica ecc…. Attraverso l'uso di questi

protocolli si possono scrivere applicazioni che offrono i suddetti servizi agli

utenti finali.

Internet Protocol Suite o TCP/IP

La "madre di tutte le reti" fu Arpanet, originata da un progetto di ricerca

finanziato dal DoD (Department of Defense) americano. Lo scopo era

creare una rete estremamente affidabile anche in caso di catastrofi (o eventi

bellici) che ne eliminassero una parte. Arpanet, attraverso varie evoluzioni,

come spiegato nell’introduzione, ha dato origine alla attuale Internet. Nel

corso dello sviluppo, per integrare via via tipi diversi di reti, si vide la

necessità di una nuova architettura, mirata fin dall'inizio a consentire

32

l'interconnessione di molteplici reti (internetwork). L'architettura divenne,

più tardi, nota coi nomi di Internet Protocol Suite, architettura TCP/IP e

TCP/IP reference model, dal nome dei suoi due protocolli principali. Essa

non è un modello nel senso stretto del termine, in quanto include i

protocolli effettivi, che sono specificati per mezzo di documenti detti RFC

(Request For Comments). I livelli TCP/IP hanno questa relazione con quelli

OSI:

OSI Tcp/Ip

Fisico

Data Link

Network

Tranport

Session

Presentation

Application

Host - to - Network

Internet

Transport

Application

Figura 1-19: Relazione fra i livelli OSI e TCP/IP

I requisiti di progetto stabiliti fin dall'inizio (estrema affidabilità e tolleranza

ai guasti, possibilità di interconnessione di più reti) portarono alla scelta di

una rete: packet-switched basata su un livello connectionless di

internetwork.

Livello host-to-network

Il livello più basso non è specificato nell'architettura, che prevede di

utilizzare quelli disponibili per le varie piattaforme HW e conformi agli

standard. Tutto ciò che si assume è la capacità dell'host di inviare

pacchetti IP sulla rete.

33

Livello Internet

E' il livello che tiene insieme l'intera architettura. Il suo ruolo è permettere

ad un host di iniettare pacchetti in una qualunque rete e fare il possibile

per farli viaggiare, indipendentemente gli uni dagli altri e magari per strade

diverse, fino alla destinazione, che può essere situata anche in un'altra

rete. Dunque per quanto detto tale sistema è connectionless. E' un servizio

best-effort datagram. E' definito un formato ufficiale dei pacchetti ed un

protocollo, IP (Internet Protocol).

Livello Transport

E' progettato per consentire la conversazione delle peer entity sugli host

sorgente e destinazione (end-to-end). Sono definiti due protocolli in questo

livello:

⇒ TCP (Transmission Control Protocol): è un protocollo connesso

ed affidabile (ossia tutti i pacchetti arrivano, e nell'ordine

giusto). Frammenta il flusso in arrivo dal livello superiore in

messaggi separati che vengono passati al livello Internet. In

arrivo, i pacchetti vengono riassemblati in un flusso di output

per il livello superiore.

⇒ UDP (User Datagram Protocol): è un protocollo non connesso e

non affidabile, i pacchetti possono arrivare in ordine diverso o

non arrivare affatto.

Livello Application

Nell'architettura TCP/IP non ci sono i livelli session e presentation (non

furono ritenuti necessari; l'esperienza col modello OSI ha mostrato che

questa visione è condivisibile). Sopra il livello transport c'è direttamente il

livello application, che contiene tutti i protocolli di alto livello i quali

34

vengono usati dalle applicazioni reali. I primi protocolli furono: Telnet:

terminale virtuale; FTP (File Transfer Protocol): file transfer e SMTP (Simple

Mail Transfer Protocol) e POP (Post Office Protocol) utilizzati posta

elettronica. Successivamente se ne sono aggiunti altri, fra cui: DNS

(Domain Name Service): mapping fra nomi di host e indirizzi IP numerici;

NNTP (Network News Transfer Protocol): trasferimento di articoli per i

newsgroup; HTTP (HyperText Transfer Protocol): alla base del Word Wide

Web. I vari protocolli nell'architettura TCP/IP si collocano come segue:

Host -to - Network

Internet

Transport

Application

Vari standard per LAN, WAN e MAN

IP

Tcp Udp

Telnet Ftp Smtp Http Nntp ecc.

Figura 1-20: Relazione fra i livelli e i protocolli dell'architettura TCP/IP

Confronto fra modello di riferimento OSI e architettura TCP/IP

Le somiglianze fra i vari protocolli si fondano sul presupposto che sono

basati entrambi sul concetto di pila di protocolli indipendenti e che hanno

funzionalità simili in entrambi per i vari livelli. Al contrario le differenze

riguardano il fatto che il modello OSI nasce come modello di riferimento

(utilissimo per le discussioni generali), i protocolli vengono solo

successivamente; il TCP/IP invece nasce coi protocolli, il modello di

riferimento viene a posteriori. Il fatto che il modello OSI fosse nato prima

dei relativi protocolli si ebbero da una parte benefici e dall’altra

conseguenze negative: il modello era, ed è tuttora, molto generale (punto a

favore); vi era insufficiente esperienza nella progettazione dei livelli (punto

a sfavore). Ad esempio: il livello data-link (pensato all'origine per linee

punto-punto) ha dovuto essere sdoppiato per gestire reti broadcast; ed

35

infine mancò del tutto l'idea di internetworking: si pensava ad una rete

separata, gestita dallo stato, per ogni nazione. I protocolli dell'architettura

TCP/IP sono invece il punto di partenza del progetto, per cui l'architettura

è molto efficiente (punto a favore); il reference model non è generale, in

quanto descrive solo questa particolare architettura (punto a sfavore) ed è

difficile rimpiazzare i protocolli se necessario (punto a sfavore).

Confronto fra pile di protocolli OSI e TCP/IP

I protocolli OSI non sono riusciti ad affermarsi sul mercato per una serie di

ragioni: Scelta di tempo non appropriata: la definizione dei protocolli è

arrivata troppo tardi, quando cioè quelli TCP/IP si erano già

considerevolmente diffusi; le aziende non se la sono sentite di investire

risorse nello sviluppo di una ulteriore architettura di rete; l’infelicità di

scelte tecnologiche: i sette livelli (e i relativi protocolli) sono stati dettati in

realtà dalla architettura SNA dell' IBM, più che da considerazioni di

progetto; grande complessità e conseguente difficoltà di implementazione;

inutili i livelli session e presentation; la non ottimale attribuzione di

funzioni ai vari livelli: alcune funzioni appaiono in molti livelli ad es.

controllo errore e flusso in tutti i livelli e altre funzioni mancano del tutto

ad es. sicurezza e gestione rete ; l’infelice implementazione: le prime

realizzazioni erano lente ed inefficienti, mentre contemporaneamente

TCP/IP era molto ben implementato (e per di più gratis!). In effetti i

protocolli dell'architettura TCP/IP invece sono stati implementati

efficientemente fin dall'inizio, per cui si sono affermati sempre più, e quindi

hanno goduto di un crescente supporto che li ha resi ancora migliori. Ad

ogni modo, neanche l'architettura TCP/IP è priva di problemi, infatti :

l'architettura TCP/IP non ha utilità come modello (non serve ad altro che a

descrivere se stessa); non c'è una chiara distinzione fra protocolli, servizi e

interfacce, il che rende più difficile l'evoluzione dell'architettura; alcune

36

scelte di progetto cominciano a pesare oggi (ad es., indirizzi IP a soli 16

bit). In conclusione: il modello OSI è ottimo come “modello”, mentre i suoi

protocolli hanno avuto poco successo; TCP/IP è ottima (per ora e si crede

per ancora molti anni con l’introduzione di IPv6 ) come architettura di rete,

ma inutile come modello.

LE RETI NEL MONDO REALE: PROBLEMI E STANDARD FISICI

Un limite per le reti: il rumore e i disturbi elettromagnetici

Il rumore in elettronica è l'insieme di segnali in tensione o corrente elettrica

indesiderati che si sovrappongono al segnale utile. Si distingue tra rumore

e disturbo, per rumore solitamente si intende segnali di origine interna,

mentre i disturbi sono segnali che provengono dall'esterno. Il rumore

consiste in "fluttuazioni" dovute a proprietà fondamentali della materia,

come ad esempio nel flusso degli elettroni che forma una corrente,e in

quanto tali di origine interna e non eliminabili. Queste fluttuazioni che si

osservano a livello macroscopico derivano da fluttuazioni a livello

microscopico. Si manifestano nella forma di segnali casuali il cui

andamento nel tempo non è descrivibile analiticamente, ma solo in termini

statistici.

Trattazione matematica del rumore

In genere, essendo intrinsecamente stocastico, il rumore viene analizzato

usando la teoria dei processi stocastici: si assume perciò che il rumore sia

stazionario cioè ha proprietà invarianti nel tempo e sia ergodico cioè tutte le

proprietà d'insieme del processo sono estraibili da una singola

osservazione. Perché sia possibile trattare il rumore bisogna che se ne

possa associare una qualche distribuzione di probabilità. In genere se la

37

distribuzione è gaussiana, come nella maggior parte dei casi, allora la sua

distribuzione è nota:

dove η rappresenta il suo valore medio e σ la sua deviazione standard

entrambi costanti nel tempo se il processo è stazionario. Inoltre è

necessario conoscere la funzione di autocorrelazione:

che rappresenta la correlazione fra due campioni del processo a distanza

temporale τ. la correlazione è massima per τ = 0, cioè quando la

correlazione è il valore quadratico medio del

processo. Per , la funzione di autocorrelazione rappresenta il grado di

prevedibilità di una realizzazione al tempo t + τ una volta nota al tempo t.

Dunque lo studio del rumore passa per la definizione di una appropriata

distribuzione di probabilità e come funzione di correlazione nel caso dei

segnali. Si usa lo spettro di potenza e si utilizzano le relazioni di Wiener-

Kinchin:

cioè della trasformata e antitrasformata di Fourier della funzione di

autocorrelazione. Lo spettro ottenuto è , ma in genere essendo

simmetrico si utilizza lo spettro di potenza unilatero positivo. Le relazioni di

Wiener-Kinchin possono allora scriversi esplicitamente:

38

A seconda dei casi le grandezze possono essere misurate in tensione allora

l'unità di misura degli spettri è V2 / Hz o in corrente allora A2 / Hz. Dagli

spettri di potenza dei segnali si possono anche ricavare gli spettri di

ampiezza di rumore:

Per calcolare il valore efficace della tensione o della corrente in un

intervallo di banda si applica semplicemente:

I tipi di rumore

La sorgente di rumore più comune negli apparati e dispositivi elettronici è il

rumore termico, esso è infatti intrinseco di ogni elemento dissipativo (es.

resistori) che si trovi ad una temperatura diversa dallo zero assoluto.

Scoperto da Jonhson e teorizzato analiticamente da Nyquist. Nyquist

(1924) ha dimostrato che un segnale analogico di banda h (da 0 ad h Hz)

può essere completamente ricostruito mediante una campionatura

effettuata 2h volte al secondo. Dunque esso "convoglia" una quantità di

informazione rappresentabile con un numero di bit pari a 2h*(logaritmo in

base 2 del numero di possibili valori del segnale) per ogni secondo. Una

conseguenza di tale teorema è che il massimo data rate (detto anche, con

un termine non del tutto appropriato, velocità di trasmissione) di un canale

39

di comunicazione dotato di una banda passante da 0 Hz ad h Hz (passa-

basso di banda h) che trasporta un segnale consistente di V livelli discreti è

massimo data rate (bit/sec.) = 2h log2V

Questo risultato implica che un segnale binario non va oltre i 6 kpbs su

una linea di banda passante pari a 3 kHz. Come vedremo, i modem veloci

sfruttano un segnale con un numero V di livelli piuttosto elevato per

riuscire a trasmettere, su una linea funzionante ad x baud, più di x

bit/sec. (il termine baud indica la velocità di segnalazione di una linea,

ossia quante volte al secondo essa è in grado di cambiare valore). Questo

rumore è conseguenza dell'agitazione termica dei portatori di carica in un

conduttore. Il loro movimento caotico è tale da creare ai capi di un resistore

una differenza di potenziale che mediamente vale 0 Volt (si dice che il

valore medio del processo rumore bianco è nullo), ma che se misurata con

uno strumento che non carichi il resistore è altamente variabile e

descrivibile solo in termini statistici: il valore quadratico medio (quadrato

del valore efficace) dipende dalla temperatura ed è pari a .

Disturbi elettromagnetici

Per poter parlare di Disturbi elettromagnetici bisogna prima parlare di

Compatibilità elettromagnetica. Il termine compatibilità elettromagnetica

(EMC, dall'inglese Electromagnetic Compatibility) si riferisce alla disciplina,

nell'ambito dell'ingegneria elettrica ed elettronica, che studia la

generazione, la trasmissione e la ricezione non intenzionali di energia

elettromagnetica in relazione agli effetti indesiderati che queste possono

comportare, con l'obiettivo di garantire il corretto funzionamento nel

medesimo ambiente dei diversi apparati che coinvolgono fenomeni

elettromagnetici nel loro funzionamento.

40

Figura 1.21 - Schema di propagazione di disturbi elettromagnetici tra un dispositivo

sorgente di disturbi (Device 1, EMC Source) e un dispositivo soggetto a tali disturbi

(Device 2, EMC Sinc). In rosso i disturbi irradiati; in azzurro i disturbi condotti.

Nelle prove di compatibilità elettromagnetica quando si verificano le

emissioni Device 1 è il dispositivo da testare (DUT Device under test),

mentre Device 2 è lo strumento di misura dei disturbi. Le parti si invertono

quando si fanno le prove di immunità (o suscettibilità). Nel perseguire il

suo intento, la compatibilità elettromagnetica prende in considerazione

diverse problematiche: le problematiche di emissione si riferiscono alla

riduzione della generazione non intenzionale di energia elettromagnetica ed

alle contromisure atte ad evitare la sua trasmissione e le problematiche di

suscettibilità (o immunità), si riferiscono invece al corretto funzionamento

degli apparati elettrici ed elettronici in presenza di disturbi elettromagnetici

provenienti dall'esterno. Quando, nell'ambito della compatibilità

elettromagnetica, si prendono in considerazione disturbi elettromagnetici

che si propagano in strutture guidanti quali conduttori metallici, ci si

riferisce a problematiche di suscettibilità ed emissione condotte (in azzurro

nella figura 1), quando invece ci si riferisce a disturbi propagatisi in spazio

41

libero, ci si riferisce a problematiche di suscettibilità ed emissione irradiata

(radiata, irraggiata), indicate in rosso nella figura 1. In passato le

problematiche di compatibilità elettromagnetica erano lasciate alla

valutazione dei singoli produttori o regolamentate a livello nazionale. Gli

sviluppi sempre più rapidi dell'elettronica e l'interscambio commerciale

sempre più intenso hanno reso necessario imporre delle normative comuni

di regolamentazione. Con la nascita dell'Unione Europea, in particolare, si

è cercato di unificare la legislazione in materia. Le normative proposte in

sede comunitaria sono poi state ratificate dai parlamenti degli stati

membri. L'Italia, in particolare, ha approvato tali normative e dal 1°

gennaio 1997 l'apposizione del marchio CE comporta il rispetto di

normative specifiche su queste problematiche (oltre al rispetto di altre

normative relative alla sicurezza elettrica

Lo standard più diffuso ai livelli 1 e 2: Ethernet

Ethernet è il nome di un protocollo per reti locali, sviluppato a livello

sperimentale da Robert Metcalfe e David Boggs, suo assistente , alla Xerox

PARC. La data ufficiale è il 1973 quando Metcalfe scrisse un promemoria

ai suoi capi della Xerox sulle potenzialità di Ethernet. Nel 1976 Metcalfe e

Boggs pubblicano un articolo dal titolo Ethernet: Distributed Packet-

Switching For Local Computer Networks. L'obiettivo originale

dell'esperimento era ottenere una trasmissione affidabile a 3Mbps su cavo

coassiale in condizioni di traffico contenuto, ma in grado di tollerare bene

occasionali picchi di carico. Per regolamentare l'accesso al mezzo

trasmissivo era stato adottato un protocollo di tipo CSMA/CD (Carrier

Sense Multiple Access / Collision Detection). Il successo dell'esperimento

suscitò forte interesse e portò alla formazione di un gruppo di imprese,

costituito da Xerox Corporation, Intel Corporation e Digital Equipment

Corporation, che nel 1978 portarono alla standardizzazione 802.3 e il 30

42

settembre 1980 a pubblicare la versione 1.0 dello standard Ethernet.

Intanto Metcalfe lasciò Xerox nel 1979 per promuovere l'uso del PC e delle

LAN per cui fondò 3Com. Metcalfe spesso attribuisce il successo di 3Com a

Jerry Saltzer. Questi collaborò alla stesura di un articolo importantissimo

dove suggeriva che l'architettura token ring fosse teoricamente superiore

alla Ethernet. Con questo le grosse aziende decisero di non puntare su

Ethernet mentre, al contrario, 3Com poté creare un business intorno al

sistema riuscendo a guadagnarsi un ottimo vantaggio tecnico e a dominare

sul mercato quando Ethernet prese piede. Successivamente, l'interesse

delle imprese del settore aumentò al punto che l'IEEE costituì alcuni

gruppi di studio finalizzati a perfezionare e consolidare Ethernet, nonché a

creare numerosi altri standard correlati. Uno dei risultati raggiunti fu la

pubblicazione, nel 1985, della prima versione dello standard IEEE 802.3,

basato sull'originale specifica Ethernet, ma non completamente

identificabile con essa. In seguito, lo standard Ethernet come tale non è più

stato mantenuto, ma il termine continua ad essere usato quasi come fosse

un sinonimo di IEEE 802.3, sebbene i due standard non coincidano affatto.

I motivi del successo

Ethernet attualmente è il sistema LAN più diffuso per diverse ragioni: é

nata molto presto e si è diffusa velocemente per cui nuove tecnologie come

FDDI e ATM hanno trovato il campo occupato. Rispetto ai sistemi

concorrenti è più economica e facile da usare e la diffusione delle

componenti hardware ne facilitano l'adozione. Funziona bene e genera

pochi problemi. È adeguata all'utilizzo con TCP/IP e, nonostante i suoi

concorrenti fossero più veloci nella trasmissione dati, Ethernet si è sempre

ben difesa.

43

Il Frame

Nonostante Ethernet abbia diverse tipologie, l'elemento comune è nella

struttura del frame che viene definito DIX (DEC, Intel, Xerox) ed è rimasto

fedele alla versione originale:

Figura 1.22 : schema pacchetto Ethernet

Questo è il frame ricevuto dallo strato di rete nella pila di protocolli. Gli

elementi sono:

Preamble: Preambolo (8 byte): I primi 7 byte hanno valore 10101010 e

servono a svegliare gli adattatori del ricevente e a sincronizzare gli

oscillatori con quelli del mittente. L'ultimo byte ha valore 10101011 e la

serie dei due bit a 1 indica al destinatario che sta arrivando del contenuto

importante.

Destination MAC address: Indirizzo di destinazione (6 byte). Questo campo

contiene l'indirizzo LAN dell'adattatore di destinazione, se l'indirizzo non

corrisponde il Livello fisico del protocollo lo scarta e non lo invia agli strati

successivi.

Source MAC address: Indirizzo sorgente (6 byte);

EtherType: Campo tipo (2 byte): Questo campo indica il tipo di protocollo

del livello di rete in uso durante la trasmissione oppure (nel caso di frame

IEEE 802.3) la lunghezza del campo dati;

Payload: Campo dati (da 46 a 1500 byte): contiene i dati reali e possono

essere di lunghezza variabile in base all'unità massima di trasmissione

44

della Ethernet. Se i dati superano la capacità massima, vengono suddivisi

in più pacchetti;

FCS Frame Check Sequenze: Controllo a ridondanza ciclica (CRC) (4 byte):

permette di rilevare se sono presenti errori di trasmissione, in pratica il

ricevente calcola il CRC mediante un algoritmo e lo confronta con quello

ricevuto in questo campo. È molto simile al frame IEEE 802.3 tranne che

per il campo tipo che nell'802.11 diventa Tipo o Lunghezza e il preambolo

ridotto a 7 byte con 1 byte trasformato in Start of Frame.

Indirizzo Ethernet

Gli indirizzi sono tutti a 6 byte in quanto Ethernet definisce uno schema di

indirizzamento a 48 bit: ogni nodo collegato, quindi, ha un indirizzo

Ethernet univoco di questa lunghezza. Esso corrisponde all'indirizzo fisico

della macchina ed è associato all'hardware. Sono anche detti indirizzi

hardware, indirizzi MAC (o MAC address) o indirizzi di livello 2.

Tipologia di trasmissione

La codifica usata per i segnali binari è la codifica Manchester. che prevede

una transizione del valore del segnale nel mezzo di ogni bit, zero o uno che

sia.

45

+ 0,85 V

- 0,85 V

Durata del bit

Durata del bit

Codifica di Zero

Codifica di Uno

0 V

Figura 1-23: Codifica Manchester

Fra i vantaggi di tale codifica è facilità di sincronizzazione fra mittente e

destinatario; il codice trasmissivo è bilanciato, cioè vi è uguale energia per

lo zero e per l'uno, e quindi la trasmissione di dati, anche se genera diverse

quantità di zeri e uni, non produce componenti in corrente continua, molto

dannosa, perché ostacola la trasmissione dei segnali, per questo è facile

rilevare le collisioni. Si noti però che tale codifica richiede, a parità di

velocità di trasmissione, una banda doppia rispetto alla codifica diretta

(ogni bit richiede la trasmissione di due valori distinti). Ethernet è una

tecnologia che fornisce al livello di rete un servizio senza connessione, in

pratica il mittente invia il frame nella LAN senza alcun handshake iniziale,

questo frame viene inviato in modalità broadcast (o a bus condiviso) e

attraversa tutta la LAN. Quando viene ricevuto da tutti gli adattatori

presenti sulla LAN, quello che vi riconoscerà il suo indirizzo di destinazione

lo recepirà, mentre tutti gli altri lo scarteranno. Il frame ricevuto può

contenere errori, la maggior parte dei quali sono verificabili dal controllo

CRC noto anche come polynomial code. I polynomial code sono basati

sull'idea di considerare le stringhe di bit come rappresentazioni di polinomi

a coefficienti 0 e 1 (un numero ad m bit corrisponde ad un polinomio di

grado m-1). Ad esempio, la stringa di bit 1101 corrisponde al polinomio x3

46

+ x2 + x0. L'aritmetica polinomiale è fatta modulo 2, secondo le regole della

teoria algebrica dei campi. In particolare: addizione e sottrazione sono

equivalenti all'or esclusivo (non c'è riporto o prestito); e la divisione è come

in binario, calcolata attraverso la sottrazione modulo 2. Il mittente ed il

destinatario si mettono d'accordo su un polinomio generatore G(x), che

deve avere il bit più significativo e quello meno significativo entrambi uguali

ad 1. Supponiamo che G(x) abbia r bit. Il frame M(x), del quale si vuole

calcolare il checksum, deve essere più lungo di G(x). Supponiamo che

abbia m bit, con m > r. L'idea è di appendere in coda al frame un

checksum tale che il polinomio corrispondente (che ha grado m + r -1) sia

divisibile per G(x). Quando il ricevitore riceve il frame più il checksum,

divide il tutto per G(x). Se il risultato è zero è tutto OK, altrimenti c'è stato

un errore. Un frame che non supera il controllo CRC, viene scartato.

Ethernet non prevede la ritrasmissione del frame scartato, né una notifica

della sua perdita agli strati superiori. Ethernet non è quindi affidabile, ma

anche semplice ed economica. Sarà compito degli strati superiori (ad

esempio TCP) provvedere alla ritrasmissione. La gestione delle collisioni e

dell'occupazione simultanea del canale di trasmissione viene gestita

mediante il CSMA/CD. CSMA/CD che è l'acronimo inglese di Carrier Sense

Multiple Access with Collision Detection, ovvero accesso multiplo tramite

rilevamento della portate e con rilevamento delle collisioni. È un'evoluzione

del protocollo MAC del CSMA ed è nato per la risoluzione del conflitti di

trasmissione dovuti al CSMA puro. L'algoritmo è il seguente: l'adattatore

sistema il frame in un buffer; se il canale è inattivo si procede alla

trasmissione, se è occupato attende prima di ritrasmettere; mentre si

trasmette l'adattatore monitora la rete (è questo il vero e proprio Collision

Detection), se non riceve segnali da altri adattatori considera il frame

spedito. Tale segnale si ricava confrontandolo con quello che trasmette: se

i due differiscono è avvenuta una collisione, quindi va interrotta la

trasmissione. Se l'adattatore riceve, durante una trasmissione, un segnale

da un altro adattatore, arresta la trasmissione e trasmette un segnale di

47

disturbo (jam). Dopo aver abortito la trasmissione attende in maniera

esponenziale (backoff esponenziale) in questo modo: gli adattatori

aspettano un tempo casuale entro un valore massimo d (il protocollo che

usa il CSMA/CD fissa tale valore). Se viene generata nuovamente una

collisione il valore d viene raddoppiato, così fino a che questo è

sufficientemente grande. Questa tecnica viene chiamata recessione binaria

esponenziale. Avviene perché se altri adattatori sono contemporaneamente

in attesa, tutti simultaneamente tenteranno di trasmettere provocando

altre collisioni. Il segnale di disturbo viene inviato per avvertire tutti gli

adattatori che è avvenuta una collisione. Anche da questo punto di vista

ciò permette all'Ethernet, in certe condizioni, di avere un'efficienza di

trasmissione del 100%. L'efficienza è vista come la frazione di tempo a

lungo termine durante la quale sono trasmessi frame senza collisioni con

altri mittenti. Nei sistemi Ethernet recenti, il problema non si presenta in

quanto con gli switch e la crescita della capacità (vedi Gigabit Ethernet) si

eliminano le collisioni e si rende molto più improbabile la congestione.

Ethernet con ripetitori e hub

Ethernet tende a crescere ma il cavo Ethernet ha una capacità limitata sia

in lunghezza (100 mt.) sia in capacità di traffico, per cui le LAN di grosse

dimensioni vengono suddivise in reti più ridotte interconnesse tra loro da

particolari nodi tra i quali possiamo trovare dei ripetitori, degli hub o

elementi più sofisticati come bridge o switch. Il ripetitore semplicemente

replica il segnale ricevuto. Il cavo Ethernet può quindi assumere lunghezze

molto maggiori alle sue capacità. L'unico vincolo è che tra due computer ci

devono essere al massimo due ripetitori per salvaguardare la

temporizzazione di CSMA/CD. Il bridge è un elemento di interconnessione

più sofisticato dell'hub perché opera sui pacchetti e non sui segnali

elettrici. Con questo sistema si possono creare segmenti di LAN

48

indipendenti in cui le collisioni e i ritardi restano limitati. Molti bridge sono

adattativi o ad apprendimento per cui sono provvisti di un software con

elenchi di indirizzi per ogni scheda ethernet che posseggono. In questo

modo quando arriva un pacchetto, estrapolano l'indirizzo di destinazione, e

inviano lo stesso pacchetto nel segmento giusto in base agli elenchi

associati alle schede. Molto più sofisticati sono gli switch che sono

composti da un numero elevato di schede ethernet che consente ad ogni

host di essere connesso direttamente. Allo switch vengono poi collegati

uno o più cavi Ethernet ad alta velocità che collegano altri segmenti di LAN.

In questo modo lo switch intercetta i pacchetti e li ridireziona ad un host

oppure sui segmenti Ethernet. La gestione dei pacchetti, quindi, è

ottimizzata perché questi sono subito indirizzati alla destinazione evitando,

per quanto possibile, collisioni. In questo modo ogni scheda ha un suo

dominio di collisione.

Uno standard diffusissimo per le reti “corte”: seriale o RS-232

EIA RS-232 equivalente allo standard Europeo CCITT V21/V24, è uno

standard che definisce una interfaccia seriale a bassa velocità per lo

scambio di dati tra dispositivi digitali. Stendendo un cavo fisico tra due

apparecchiature elettroniche dotate di una porta RS-232 (tra cui i PC) è

possibile realizzare una comunicazione tra di loro

49

FIGURA 1.24 : Retro di un PC con due porte RS-232 (i due connettori maschio in basso)

Utilizzi

Lo standard EIA RS-232 nacque nei primi anni '60 per opera della

"Electronic Industries Association" ed era orientato alla comunicazione tra i

mainframe e i terminali attraverso la linea telefonica, utilizzando un

modem. Oggi la porta seriale EIA RS-232 è presente in quasi tutti i PC

desktop, anche se è stata soppiantata dall'interfaccia USB (o da PS/2) in

quasi tutti gli utilizzi. La gran parte dei PC portatili invece non viene ormai

più dotata di questa interfaccia. Tra gli utilizzi della porta seriale, si

possono citare: connessione di terminali ad un calcolatore

(tradizionalmente un mainframe, ma anche un PC); connessione di

periferiche: la porta seriale è stata usata per collegare i mouse ai primi PC,

stampante (soppiantato dalla porta parallela, e poi da USB e dalle

stampanti di rete) dispositivi specializzati, come ad esempio lettori di codici

a barre e di tessere magnetiche (soppiantato da USB), ancora tutt’oggi in

uso collegare a un PLC ad un singolo PC od altri, connessione a dispositivi

embedded, ad esempio Dispositivi di rete, per scopi di configurazione e

monitoraggio. In questo utilizzo RS-232 è ancora ampiamente usato,

anche se spesso è necessario dotarsi di un adattatore seriale/USB per

utilizzare come terminale un computer privo di porta seriale.

50

Storia dello standard

L'interfaccia seriale EIA RS-232 è uno standard costituito da una serie di

protocolli meccanici, elettrici ed informatici che rendono possibile lo

scambio di informazioni a bassa velocità tra dispositivi digitali. Esso

includeva le caratteristiche elettriche dei segnali, la struttura e

temporizzazioni dei dati seriali, la definizione dei segnali e dei protocolli per

il controllo del flusso di dati seriali su un canale telefonico, il connettore e

la disposizione dei suoi pin ed infine il tipo e la lunghezza massima dei

possibili cavi di collegamento. Nel corso di questi oltre 40 anni lo standard

si è evoluto pur mantenendosi in larga parte invariato. L'evoluzione è

riconoscibile dalla sigla, leggendo l'ultima lettera; l'ultima revisione è del

1997 ed è indicata come EIA RS-232f. Probabilmente la versione più

diffusa è la RS232c, del 1969, corrisponde alle specifiche europee CCITT

raccomandazione V.24. Pur essendo un protocollo piuttosto vecchio,

attualmente la EIA RS-232 è ancora largamente utilizzata per la

comunicazione a bassa velocità tra microcontrollori, dispositivi industriali

ed altri circuiti relativamente semplici che non necessitano di particolare

velocità; è invece praticamente scomparsa in ambito "desktop", ambito nel

quale lo standard è nato per la comunicazione tra un computer ed un

modem. Le informazioni raccolte, relative principalmente al livello elettrico,

sono state codificate inizialmente dallo standard EIA/TIA-232-E e

successivamente modificate in alcuni dettagli secondari dallo standard

EIA/TIA-562.

Definizione

Seriale significa che i bit che costituiscono l’informazione sono trasmessi

uno alla volta su di un solo "filo". Questo termine è in genere contrapposto

a "parallelo": in questo caso i dati sono trasmessi contemporaneamente su

51

più fili, per esempio 8, 16 o 32. Parlando astrattamente si potrebbe pensare

che la trasmissione seriale sia intrinsecamente più lenta di quella parallela

(su di un filo possono passare meno informazioni che su 16). In realtà

questo non è vero in assoluto, soprattutto a causa della difficoltà di

controllare lo skew (disallineamento temporale tra i vari segnali) dei molti

trasmettitori in un bus parallelo, e dipende dalle tecnologie adottate: per

esempio in una fibra ottica, in un cavo ethernet, USB o FireWire (tutti

standard seriali) le informazioni transitano ad una velocità paragonabile a

quella di un bus PCI a 32 fili. In questo capitolo si tratterà solo di

interfacce seriali "lente" cioè gestibili da PC e microcontrollori "normali".

Asincrono significa, in questo contesto, che i dati sono trasmessi, byte per

byte, in modo anche non consecutivo e senza l'aggiunta di un segnale di

clock, cioè di un segnale comune che permette di sincronizzare la

trasmissione con la ricezione; ovviamente sia il trasmettitore che il

ricevitore devono comunque essere dotati di un clock locale per poter

interpretare i dati. La sincronizzazione dei due clock è necessaria ed è fatta

in corrispondenza della prima transizione sulla linea dei dati.

Le unità di misura

Le unità di misura della velocità di trasmissione sono essenzialmente due:

il baud ed il bit per secondo (bps o, meno spesso, b/s), spesso trattate

erroneamente come sinonimi. Il baud rate indica il numero di transizioni al

secondo che avvengono sulla linea; il bps indica, come dice il nome, quanti

bit al secondo sono trasmessi lungo la linea. Nel caso di trasmissione

binaria (cioè è presente un livello alto ed uno basso) le due cose ovviamente

coincidono numericamente, da cui la parziale equivalenza dei due termini.

Nel caso di trasmissioni a più livelli, invece, è possibile trasmettere con una

sola transizione più bit: se per esempio posso trasmettere otto diversi valori

di tensione tra 0 ed 7 volt, con un solo valore di tensione invio tre bit (0 V =

52

000, 1 V = 001, 2 V = 010…) ed in questo caso una trasmissione a 1000

baud equivale ad una a 3000 bps. Nel caso dello standard EIA RS-232 i

livelli utilizzati sono due quindi il baud rate coincide numericamente con il

bps.

Come è fatto un segnale EIA RS-232

Figura 1.25:Segnale della porta RS232

Il modo più semplice per descrivere un segnale EIA RS-232 è partire con un

esempio. Nell’immagine è visualizzato, in modo idealizzato, cosa appare

collegando un oscilloscopio ad un filo su cui transita un segnale EIA RS-

232 a 9600 bps del tipo 8n2 (in seguito verrà indicato il significato di

questa sigla ) rappresentante il valore binario 01001011. L’ampiezza del

segnale è caratterizzata da un valore "alto" pari a circa +12 V ed un valore

"basso" pari a –12 V. Da notare che, nello standard EIA RS-232 un segnale

alto rappresenta lo zero logico ed uno basso un uno, è quindi una codifica

a logica negativa, ossia rovesciata rispetto al comune pensare. A volte un

segnale alto (+12 V, cioè uno zero logico) è indicato come space ed uno

basso (-12 V, uno logico) come mark. Tutte le transizioni appaiono in

corrispondenza di multipli di 104us (pari ad 1/9600 cioè ciascun bit dura

esattamente l'inverso del baud rate). La linea si trova inizialmente nello

stato di riposo, alta (nessun dato in transito); la prima transizione da alto a

basso indica l’inizio della trasmissione (inizia il "bit di start", lungo

53

esattamente 104us). Segue il bit meno significativo (LSB), dopo altri 104

uS il secondo bit, e così via, per otto volte, fino al bit più significativo

(MSB). Da notare che il byte è trasmesso "al contrario", cioè va letto da

destra verso sinistra. Segue infine un periodo di riposo della linea di

almeno 208us, cioè due bit di stop e quindi (eventualmente) inizia un

nuovo pacchetto di bit. Esistono diversi tipi di codifiche e metodi per capire

quando e dove una serie di dati termina, qui in seguito verranno mostrati e

proposti i principali. Se la trasmissione è più veloce o più lenta, la distanza

tra i fronti varia di conseguenza (p.e. a 1200 bps le transizioni avvengono a

multipli di 0,833 ms, pari a 1/1200) invece di trasmettere 8 bit, ne posso

trasmettere 5, 6, 7 o anche 9 (ma quest’ultima possibilità non è prevista

dalle porte seriali dei normali PC). Al termine è possibile aggiungere un bit

di parità. Alla fine la linea rimane nello stato di riposo per almeno 1, 1.5 o

2 bit; se non si ha più nulla da trasmettere, il "riposo" è molto più lungo,

ovviamente. Molti sistemi non possono utilizzare 1.5 bit di stop che

venivano usati dalle telescriventi a 110 baud di velocità perché permetteva

il CR/LF (ritorno carrello/salto linea). In genere, nei personal computer, il

formato del pacchetto ricetrasmesso è indicato da una sigla composta da

numeri e cifre, per esempio 8n1 e 7e2: la prima cifra indica quanti bit di

dati sono trasmessi (nei due esempi rispettivamente 8 e 7). La prima lettera

segna il tipo di parità (rispettivamente nessuna ed even-parity, cioè parità

pari). La seconda cifra il numero di bit di stop (rispettivamente 1 e 2).

Tenendo conto che esiste sempre un solo bit di start, un singolo blocco di

bit è quindi, per i due esempi riportati, costituito rispettivamente da 10

(1+8+0+1) e 11 (1+7+1+2) bit. Da notare che di questi bit solo 8 e,

rispettivamente, 7 sono effettivamente utili. Lo standard originale prevede

una velocità da 75 baud a 19200 baud. Uno standard successivo (RS-562)

ha portato il limite a 64 Kbps lasciando gli altri parametri elettrici

praticamente invariati e rendendo quindi i due standard compatibili a

bassa velocità. Nei normali PC le cosiddette interfacce seriali RS-232

arrivano in genere almeno a 115 Kbps o anche più: pur essendo

54

formalmente al di fuori di ogni standard ufficiale non si hanno particolari

problemi di interconnessione. Ovviamente sia trasmettitore che ricevitore

devono accordarsi sul modo di trasmettere i dati prima di iniziare la

trasmissione. È importante garantire il rigoroso rispetto della durata dei

singoli bit: infatti non è presente alcun segnale di clock comune a

trasmettitore e ricevitore e l'unico elemento di sincronizzazione è dato dal

fronte di discesa del bit di start. Come linea guida occorre considerare che

il campionamento in ricezione è effettuato di norma al centro di ciascun bit:

l'errore massimo ammesso è quindi, teoricamente, pari alla durata di

mezzo bit (circa il 5% della frequenza di clock, considerando che anche il

decimo bit deve essere correttamente sincronizzato). Naturalmente questo

limite non tiene conto della possibile difficoltà di riconoscere con precisione

il fronte del bit di start (soprattutto su grandi distanze ed in ambiente

rumoroso) e della presenza di interferenze intersimboliche tra bit adiacenti:

per questo spesso è consigliabile usare un clock con una precisione

migliore dell'1% imponendo di fatto l'uso di oscillatori a quarzo. Si

potrebbe anche ipotizzare un meccanismo che tenta di estrarre il clock dai

fronti intermedi, ma si tratta nel caso specifico di un lavoro poco utile, visto

che la lunghezza del pacchetto è piuttosto breve.

Il bit di parità

Oltre ai bit dei dati (in numero variabile tra 5 e 9) viene inserito un bit di

parità (opzionale) per verificare la correttezza del dato ricevuto. Di questo

particolare ma importante bit ne esistono 5 importanti versioni:

• None: nessun tipo di parità, cioè nessun bit aggiunto;

• Pari (even): il numero di mark (incluso il bit di parità) è sempre pari;

• Dispari (odd): il numero di mark (incluso il bit di parità) è sempre

dispari;

55

• Mark: il bit di parità vale sempre mark;

• Space: il bit di parità vale sempre space;

Il bit di parità può essere LRC o VRC , cioè la funzione di parità, un XOR di

bit a bit della stringa dati incluso il bit di parità stesso, può essere eseguita

sia lateralmente che verticalmente sui dati inviati, ottenendo una stringa

dati di parità finale con il relativo bit di parità : il LRC di tale stringa dati di

controllo deve combinarsi secondo le parità precedentemente eseguite

verticalmente che sul blocco VRC-dati creato.

I SISTEMI PER L’AUTOMAZIONE INDUSTRIALE

Architetture tipiche dei sistemi

In questa sezione verrà effettuata un’analisi inerente le architetture tipiche

dei sistemi in ambito industriale. Non esiste un modello unico e standard,

perchè le applicazioni e le necessità di ogni azienda sono svariate e

molteplici, tutte però si appoggiano ad uno schema logico chiamato CIM

(Computer Integrated Manifacturing) come impiego articolato e cooperante

della tecnologia informatica nei processi di progettazione, produzione,

distribuzione volto comunque continuamente ad acquisire un durevole

vantaggio competitivo. La grossa fetta di mercato dove questa tecnologia

può essere applicata riguarda tutte le funzioni dell’impresa che possono

essere assistite dall’elaboratore o automatizzate e quindi eseguite e

controllate dalle macchine con un alto livello di integrazione. Di seguito

viene riportata una rappresentazione grafica che mostra i vari livelli di

questo semplice e snello schema logico.

56

Figura 2-1: schema logico architettura CIM

57

La piramide CIM

Figura 2-2 : piramide Cim

Descrizione dei livelli

Livello 0: sensori, attuatori, tools legati al processo esecutivo

E’ costituito dall’insieme dei sensori e degli attuatori, ossia dai dispositivi di

campo che vengono interfacciati direttamente all’impianto industriale

costituendo la sezione di ingresso – uscita del sistema di controllo. La

funzione del livello 0 è quella di riportare al livello sovrastante le misure di

processo e di attuare i comandi ricevuti da esso. Il livello di intelligenza

richiesto ai dispositivi di campo è limitata, dovendo essi soltanto tradurre

grandezze fisiche di varia natura (es. temperatura, pressione, tensione,

ecc.) a segnali tipicamente di tipo elettrico (corrente e tensione) e viceversa.

Livello 0 : Piano di Officina (Sensor/Actuator )

Livello 1: Sistemi di Controllo (Field Area)

Livello 2 :Supervisione di Cella (Cell Area)

Livello 3 :Supervisione Integrata

Livello 4 : Gestione Stabilimento

Gestione Azienda

58

E’ bene notare come sia crescente la tendenza di dotare sensori ed attuatori

di intelligenza dedicata anche alla gestione di una interfaccia di

comunicazione digitale e seriale.

Livello 1: Controllo di macchina

Sistemi industriali che comandano direttamente i processi al livello 0

(comando individuale delle macchine e del processo o controllo di

macchina). E’ costituito dai controllori, solitamente di tipo automatico o

semiautomatico, interfacciati con i sensori e gli attuatori dei dispostivi

meccanici facenti parte di una stessa unità operatrice. Le apparecchiature

del livello 1 sono i controllori a logica programmabile (PLC, ecc ), semplici

sistemi di controllo distribuito (DCS, Distributed Control System), centri di

lavorazione a controllo numerico (CNC, Computer Numeric Controller). Le

funzioni cui il controllo di macchina è preposto sono la regolazione diretta

delle variabili e la realizzazione sequenziale di operazioni; tali operazioni

non sono in genere molto complesse, ma devono essere coordinate con

quelle fatte eseguire alle altre macchine attraverso l’operato del livello

superiore.

Livello 2: Controllo di cella

Workshop computer (comando centralizzato delle macchine e del processo

o controllo di cella). I controllori costituenti questo livello regolano il

funzionamento di tutte le macchine operatrici costituenti una cella di

lavoro attraverso la comunicazione con i relativi controllori; le operazioni

svolte a questo livello sono analoghe a quelle del livello 1 risultando

soltanto più complesse e a maggior spettro in varietà e dimensioni. In modo

analogo i controllori PLC e DCS del livello 2 sono più potenti in termini di

capacità elaborativa, memoria, comunicazione, ecc…. Crescente interesse,

59

soprattutto dal punto di vista economico, rivestono le moderne soluzioni di

automazione basate su Personal Computer (PC).

Livello 3: Controllo di area

High performance computer per il management e la supervisione delle

unità di processo (gestione della produzione o controllo di area).

E’ costituito dal sistema di supervisione, controllo e acquisizione dati

(SCADA); le apparecchiature su cui sono implementate le piattaforme

software sono tipicamente Work Station o PC nelle applicazioni più

semplici. Le funzioni svolte a livello 3 sono quelle legate alla gestione

dell’intero processo controllato: gestione operativa intesa come

impostazione del lotto da produrre o dei cicli di lavorazione, gestione delle

situazioni di allarme, analisi dei risultati, ecc….Il controllo di area differisce

sostanzialmente da quello di macchina e di cella, in quanto i requisiti di

elaborazione real-time sono fortemente ridotti; le funzioni infatti che devono

essere svolte a questo livello sono fortemente dipendenti dall’operatore

eventualmente coadiuvato da sistemi automatici di tipo gestionale che però

lavorano su orizzonti temporali e con obiettivi completamente differenti.

Restano invece molto importanti i tempi di risposta dell’intero sistema per

quanto concerne la rilevazione e segnalazione di eventuali situazioni di

allarme in cui l’operatore può e deve essere in grado di prendere

provvedimenti.

Livello 4: mainframe per il governo del management, gestione commesse e amministrazione centrale delle attività di fabbrica

(pianificazione della gestione globale).

Questo ultimo ed importante livello mostra i veri risultati del lavoro svolto

dai livelli sottostanti lavorando e trattando dati non solo grezzi e a volte

privi di significato ma dati elaborati e molto complessi i quali possono

essere utilizzati in tutti i modi possibili a partire dal semplice calcolo

60

statistico di errori di produzione e di conseguenza ha una maggior resa dal

punto di vista sia produttivo che dal punto di vista di costi a grosse

indagini di mercato e altro ancora.

Come accennato sopra, sposando questa causa, si ottengono ottimi

risultati e vantaggi tra i quali:

• ottimizzazione e pianificazione dei processi produttivi

• migliore utilizzo delle risorse

• riduzione del tempo di produzione

• semplificazione dell'installazione e manutenzione ad esempio

taratura a distanza e rilevamento guasti massima flessibilità di

produzione

• riconfigurazione del sistema a nuove lavorazioni in tempi brevi

• miglioramento del controllo della qualità

• controllo di ogni singolo prodotto invece che solo alcuni

campioni

Lo Scada e le sue caratteristiche

La definizione comunemente utilizzata per l’identificazione di sistemi

SCADA corrisponde al significato esteso dell’acronimo e rappresenta senza

dubbio il mezzo più semplice per introdurre il modello rappresentato da

questo tipo di sistemi. L’acronimo SCADA sta per Supervisory Control And

Data Acquisition ed è nient’altro che l’enumerazione delle tre funzionalità

principali realizzate dai sistemi: supervisione, controllo e acquisizione dati.

In realtà la versione estesa dell’acronimo SCADA non è una definizione

poiché in nessun modo permette di discriminare quelli che effettivamente

vengono considerati sistemi SCADA da una gran quantità di sistemi o

semplicemente di dispositivi più o meno complessi che svolgono le tre

funzioni o parte di esse. Ciò che manca all’acronimo per essere una

definizione compiuta `e la descrizione del modo in cui questo tipo di

61

sistema espleta le proprie funzioni e il campo di applicazione. Utilizzando il

linguaggio della matematica possiamo dire che i sistemi SCADA sono

insiemi di funzioni dei quali si usa dare una definizione enumerando le

funzioni dell’insieme senza che queste siano qualificate in termini di

dominio e codominio (determinati dalle caratteristiche del campo di

applicazione) e in termini di proprietà delle funzioni, è come se la

trigonometria potesse essere definita come Seno Coseno Tangente e

Cotangente senza la definizione delle caratteristiche di continuità,

periodicità e quant’altro necessario a giustificare l’esistenza stessa del

termine “trigonometria” e del metodo di calcolo che questa rappresenta.

Così come in matematica lo studio di un insieme di funzioni come “caso

particolare” serve a estendere la comprensione del problema ma non la

conoscenza, nel caso dei sistemi di controllo la distinzione tra sistemi

SCADA e altri sistemi affini serve a comprendere meglio il ruolo che `e stato

attribuito loro dall’applicazione che hanno avuto per la risoluzione di

problemi di controllo. Le parte seguente mostra una breve descrizione delle

funzioni svolte da un sistema SCADA e le differenze che possono essere

individuate nel confronto tra questo tipo di sistemi e un altro tipo, affine al

primo, anch’esso destinato a realizzare funzioni di controllo e

comunemente indicato con l’acronimo DCS (Distributed Control System).

62

Figura 2.3 : Schema logico SCADA

Acquisizione dati

L’acquisizione dati è una funzione che nella maggior parte dei casi ha un

ruolo di supporto alle funzioni di supervisione e controllo poiché mette in

relazione il sistema con il processo controllato consentendo la conoscenza

dello stato in cui si trova il processo e l’azione di controllo esercitata per

mezzo della variazione di parametri caratteristici del processo. In questo

senso “acquisizione dati” significa in realtà scambio dati in entrambe le

direzioni: dal processo verso il sistema e viceversa. In alcuni sistemi

classificati come sistemi SCADA l’acquisizione è la funzione principale

svolta dal sistema; questo è il caso in cui non ci sono procedure di controllo

implementate dal sistema e la fase di supervisione può essere realizzata

sporadicamente o come analisi a posteriori degli stati acquisiti dal

processo. Esempio di questo tipo di casi è un qualsiasi sistema di

telerilevamento nel quale il primo obiettivo è la raccolta e l’organizzazione

dei dati sui quali possono essere condotte analisi non necessariamente

predefinite. L’acquisizione dati entra nella definizione di sistema SCADA

per il fatto che non è possibile espletare funzioni di supervisione senza

63

acquisire informazioni sullo stato in cui si trova il processo osservato così

come non è possibile orientarne il comportamento, cioè controllarlo, senza

avere la possibilità di influenzare lo stato cambiando il valore di parametri

che lo caratterizzano. La funzione di acquisizione dati di un sistema SCADA

è considerata generalmente una funzione di scambio puro e semplice di

informazioni tra la parte di sistema che realizza supervisione e controllo e

processo controllato, cioè si considera assente qualsiasi processo

decisionale interposto tra le strutture di supervisione e controllo e il

processo controllato. Nei casi in cui questa condizione viene a mancare si

ha a che fare con sistemi che realizzano qualcosa di diverso rispetto a

quanto viene fatto da un sistema SCADA inteso in senso classico, si hanno

cioè strutture a intelligenza distribuita. Uno dei motivi per il quali esiste

questa distinzione consiste nel fatto che la distribuzione della capacità di

elaborazione si rende necessaria solitamente nei casi in cui il processo

controllato ha dimensioni geograficamente rilevanti, tali da ostacolare la

realizzazione di un sistema di elaborazione concentrato e collocato a

ridosso del processo.

Supervisione

La supervisione è l’attività per mezzo della quale un sistema SCADA rende

possibile l’osservazione dello stato e dell’evoluzione degli stati di un

processo controllato. Con tale funzionalità prendono corpo: la

visualizzazione delle informazioni relative allo stato attuale del processo, la

gestione delle informazioni storiche, la gestione degli stati che costituiscono

eccezioni rispetto alla normale evoluzione del processo controllato.

La funzione di supervisione costituisce un fine per qualsiasi sistema

SCADA. Questa funzione è determinante nella caratterizzazione di un

sistema nel senso che un sistema che non permetta di accedere alle

64

informazioni di stato corrente e/o storiche del processo osservato e/o

controllato non può essere definito come sistema SCADA.

Controllo

La funzione di controllo rappresenta la capacità di un sistema di prendere

decisioni relative all’evoluzione dello stato del processo controllato in

funzione dell’evoluzione del processo medesimo. La modalità con la quale

le procedure di controllo vengono realizzate nell’ambito dell’intera

architettura del sistema dipende fortemente dal tipo di processo, essendo

questo in grado di imporre scelte architetturali sia hardware che software.

In questo senso i sistemi SCADA sono comunemente intesi come sistemi

che hanno la funzione di acquisizione dati nell’intera catena di acquisizione

che dai sensori al sistema di elaborazione e archiviazione veicola

informazioni che sono i dati grezzi prelevati come valori di parametri di

stato del processo. L’esercizio di controllo é quindi concentrato nel sistema

di elaborazione il quale, una volta eseguite opportune procedure di

elaborazione, sfrutta il sistema di acquisizione dati in senso inverso per

cambiare il valore di opportuni parametri di stato del processo controllato.

La varietà dei processi controllati da sistemi classificati come sistemi

SCADA si manifesta in notevoli differenze tra le diverse realizzazioni La

qualità dello sviluppo di sistemi di controllo dipendente in ugual misura

dalla capacità di realizzazione di sistemi tecnologici e dall’efficacia

dell’analisi del processo da controllare. Quest’ultima impone vincoli

significativi nella realizzazione di sistemi di controllo rendendo quest’ultimo

un processo, che di volta in volta, richiede tecniche di sviluppo adeguate

difficilmente riconducibili a modelli convenzionali. L’analisi del processo

controllato produce informazioni che influenzano le scelte progettuali sia

dal punto di vista tecnologico che organizzativo ed è norma aurea anteporre

l’approfondimento della conoscenza del processo alla definizione delle

65

caratteristiche del sistema destinato a controllarlo. Nel seguito sono

presentati alcuni elementi classici di indagine per la determinazione delle

caratteristiche fondamentali del sistema di controllo. La qualificazione del

processo rispetto a questi elementi permette di individuare vincoli nella

definizione delle specifiche tecniche,funzionali, organizzative che nella

maggior parte dei casi si traducono negli elementi distintivi del sistema

realizzato rispetto a tutti gli altri.

⇒ Realtime: il termine realtime si riferisce alla capacità del

sistema di reagire alle sollecitazioni del processo con ritardi

trascurabili rispetto alla dinamica evolutiva del processo

medesimo. Allo stesso tempo la reazione del sistema deve essere

caratterizzata da tempi di elaborazione compatibili con quelli

imposti dagli obiettivi del controllo. Le funzioni svolte da un

sistema di controllo sono tali da rendere questa capacità di

reazione un requisito solitamente irrinunciabile mentre altri

elementi di complessità del sistema e del processo controllato

⇒ Alta affidabilità: una qualità della quale i sistemi di controllo

non possono fare a meno è l’affidabilità intesa secondo il

significato dato nel gergo tecnologico anglosassone al termine

reliability. Un sistema di controllo è un mosaico di componenti

ognuno dei quali caratterizzato da un determinato, o

determinabile, grado di affidabilità, cioè da un valore di

probabilità di malfunzionamento espresso come percentuale del

tempo di esercizio del componente medesimo. Nella

realizzazione di un sistema è necessario tenere in

considerazione l’affidabilità dei singoli componenti per

provvedere alla eventuale implementazione di contromisure

destinate a contenere l’influenza che un dato sottosistema ha

sull’affidabilità dell’architettura complessiva.

66

⇒ Alta disponibilità: la disponibilità è la percentuale di tempo per

la quale deve essere assicurato lo stato di esercizio del sistema,

cioè il valore complementare della percentuale di tempo in cui il

sistema è in stato di fermo a causa di guasti,

manutenzioni,aggiornamenti o altro. La disponibilità può

essere riferita all’intero sistema o a parti critiche dello stesso e,

come le altre, è una caratteristica che si esprime in vincoli che

differiscono in funzione del tipo di processo da controllare. Un

processo può avere esigenze stringenti di disponibilità per

motivi di sicurezza (si pensi ai sistemi di controllo di processi

produttivi tipici dell’industria chimica nei quali l’indisponibilità

del sistema di controllo può pregiudicare l’attività del processo

di produzione lasciandolo in stati potenzialmente molto

pericolosi per la sicurezza delle strutture e l’incolumità degli

operatori) o di continuità del servizio (questo `e il caso dei

sistemi di gestione del traffico). In altri casi la disponibilità è

un’esigenza di secondo piano rispetto ad altre caratteristiche

anche se i vincoli che essa produce sono comunque stringenti.

⇒ Grado d’interazione uomo-macchina: la realizzazione delle

funzioni di un sistema di supervisione e controllo comporta

sempre la realizzazione di sottosistemi responsabili

dell’interazione tra gli operatori e il sistema medesimo

denominati interfacce uomo-macchina (in inglese si usa

l’acronimo HMI di human-machine interface). La complessità

dello sviluppo è in funzione del tipo di interazione richiesta

mentre quest’ultima dipende dalle caratteristiche del processo

controllato. L’interfaccia uomo-macchina può realizzare molti

gradi di interazione comprendendo funzionalità di semplice

osservazione dello stato di esercizio del sistema, nel caso di

sistemi che realizzano procedure completamente automatizzate,

67

o funzionalità responsabili della esecuzione di procedure

manuali gestite dagli operatori. In casi analoghi a quello dei

sistemi di telerilevamento ambientale le procedure automatiche

sono responsabili dell’acquisizione dei dati e di un’eventuale

primo trattamento degli stessi (un esempio è dato dalle

procedure di validazione) mentre l’interfaccia uomo-macchina

rende disponibili funzionalità per tipi di analisi dell’informazione

altrimenti non realizzabili. In altri casi, cioè in quelli che

prevedono forme di controllo oltre che di supervisione, risulta

fondamentale la realizzazione di interfacce di facile utilizzo e di

funzionalità accessorie necessarie alla comprensione dello stato

di esercizio del sistema comprendenti la gestione della notifica

degli allarmi e la visualizzazione di grafici relativi alle grandezze

più rappresentative.

Il Plc e le sue caratteristiche

Il controllore logico programmabile o programmable logic controller (PLC) è

un computer industriale specializzato in origine nella gestione dei processi

industriali. Il PLC esegue un programma ed elabora i segnali digitali ed

analogici provenienti da sensori e diretti agli attuatori Un attuatore è un

meccanismo attraverso cui un agente (per esempio l'unità di controllo

elettronico, come può essere la centralina automobilistica) agisce su un

ambiente, inoltre l'agente può essere o un agente intelligente artificiale o un

qualsiasi altro essere autonomo (umano, animale). In senso lato, un

attuatore è talvolta definito come un qualsiasi dispositivo che converte

dell'energia da una forma ad un'altra, in modo che questa agisca

nell'ambiente fisico al posto dell'uomo. Anche un meccanismo che mette

qualcosa in azione automaticamente è detto attuatore. Gli attuatori

presenti in un impianto industriale, nel tempo, con la progressiva

68

miniaturizzazione della componentistica elettronica e la diminuzione dei

costi, sono entrati anche nell'uso domestico. Si porta in proposito come

esempio l'installazione di un PLC nel quadro elettrico di un'abitazione, a

valle degli interruttori magnetotermico e differenziale (salvavita), esso

permette la gestione automatica dei molteplici sistemi e impianti installati

nella casa: impianto di riscaldamento, antifurto, irrigazione, LAN, luci,

ecc.... Un PLC è un oggetto hardware componibile. La caratteristica

principale è la sua robustezza estrema, infatti normalmente il PLC è posto

in quadri elettrici in ambienti rumorosi, con molte interferenze elettriche,

con temperature elevate o con grande umidità. In certi casi il PLC è in

funzione 24 ore su 24, per 365 giorni all'anno, su impianti che non

possono fermarsi mai. La struttura del PLC viene adattata in base al

processo da automatizzare. Durante la progettazione del sistema di

controllo, vengono scelte le schede adatte alle grandezze elettriche in gioco.

Funzionamento

La prima cosa che il PLC compie è la lettura degli ingressi e con questo si

intende tutti quelli digitali che analogici, on board o su bus di campo

(schede remote collegate al PLC o con una rete di comunicazione). Lo stato

degli ingressi, una volta letto, viene memorizzato in una memoria che è

definita "Registro immagine degli ingressi". A questo punto le istruzioni di

comando vengono elaborate in sequenza dalla CPU e il risultato viene

memorizzato nel "Registro immagine delle uscite". Infine, il contenuto

dell'immagine delle uscite viene scritto sulle uscite fisiche ovvero le uscite

vengono attivate. Poiché l'elaborazione delle istruzioni si ripete

continuamente, si parla di elaborazione ciclica; il tempo che il controllore

impiega per una singola elaborazione viene detto tempo di ciclo

(solitamente pochi millisecondi).

69

Struttura del PLC

Un PLC è composto da un alimentatore, dalla CPU che in certi casi può

avere interna o esterna una memoria RAM o Flash o EPROM, da un certo

numero di schede di ingressi digitali e uscite digitali, e nel caso in cui sia

necessario gestire grandezze analogiche, il PLC può ospitare delle schede di

ingresso o di uscita sia analogiche che digitali. Il PLC normalmente opera

in rete con altri PLC, quindi sono necessarie delle schede di comunicazione

adatte al protocollo di rete già implementato sugli altri PLC. Nel caso di

operazioni di movimentazione, come nel campo della robotica, il PLC ospita

delle schede acquisizione controllo assi, cioè delle schede molto veloci e

sofisticate che permettono di gestire spostamenti e posizionamento.

Cpu

La CPU è il cervello del PLC. E’ una scheda complessa basata su un

microprocessore con un sistema operativo proprietario, e con una zona di

memoria a disposizione del programma utente, cioè del programma di

automazione. La memoria utente è spesso esterna come ad esempio nel

caso di memoria EPROM. Il vantaggio di una memoria esterna è legata alla

semplicità di programmazione o di modifica del microcontrollori o

microprocessori. La CPU durante il funzionamento a regime, colloquia con

tutte le schede connesse sul BUS del PLC, trasferendo dati e comandi sia

verso il mondo esterno, sia dal mondo interno. Una delle caratteristiche

peculiari delle CPU dei PLC è la loro capacità di poter gestire le modifiche

del programma di gestione del processo durante il normale funzionamento.

Questa possibilità è estremamente utile nel caso di impianti che devono

essere sempre attivi. All'interno della CPU sono varie parti, tra cui:

70

• unità di gestione, ovvero informazioni di gestione del PLC stesso,

impostate dal costruttore e trasparenti all'utente;

• archivio di temporizzatori e contatori funzionali all'operatività del

PLC;

• memorie immagine del processo, cioè le informazioni in ingresso ed i

comandi in uscita del processo;

• memoria utente, in cui vengono scritti i programmi che il PLC deve

eseguire;

• interfaccia per il dispositivo di programmazione, che comunica con gli

strumenti di programmazione;

• bus dati, comando, indirizzi per la veicolazione dei dati fra le varie

parti e con l'esterno della CPU.

Schede di comunicazione

Il PLC durante il suo funzionamento può comunicare con computer, con

altri PLC oppure con altri dispositivi come le macchine CNC (i torni e/o le

frese a controllo numerico delle aziende). La comunicazione con computer e

altri dispositivi avviene tramite tipi di connessione standard come:

• RS232 (quella utilizzata nel progetto attuato)

• RS422/RS485

• TCP/IP,UDP/IP

• USB

La comunicazione con altri PLC avviene tramite protocolli standard, ad

esempio:

• Profibus

• DeviceNet

• TCP/IP

• Modbus (molto importante)

• Fins, C-command

71

CANALI DI COMUNICAZIONE PER L’AUTOMAZIONE

Caratteristiche generali dei protocolli usati per l’automazione

I protocolli di comunicazione usati per l’automazione sono molto simili a

quelli utilizzati in altri ambiti, ma devono accentuare particolari

caratteristiche per far si che lo scopo per cui vengono creati sia raggiunto

nei migliori dei modi. Nel nostro studio ci siamo soffermati solo ad

analizzare particolari protocolli, in particolare quelli utilizzati per la

comunicazione tra Pc e Plc o tra vari Plc e precisamente su due protocolli,

proprietari di Omron, i C-Command e Fins. Sono stati incontrati, ma non

approfonditi, anche altri protocolli come ModBus, o alcuni proprietari di

Vago (altra nota marca di Plc) e Simens. Tutti soddisfano ed enfatizzano

caratteristiche comuni tra le quali:

Velocità ed immediatezza: si vuole intendere che sono protocolli molto

snelli, veloci e di semplice utilizzo e che sono in grado di fornire funzioni

immediate senza la perdita di tempo in header e tail inutili.

Tali caratteristiche sono determinanti, in certi casi, soprattutto in catene di

montaggio dove la sincronizzazione di apparati meccanici deve

assolutamente essere rispettata.

Robustezza: in ogni istante e come spiegato prima si deve conoscere se il

pacchetto spedito é arrivato correttamente, se non è arrivato o se la

risposta contiene errori. Un altro punto riguardante la robustezza è che il

protocollo deve essere immune ai grandi disturbi elettromagnetici presenti

in una normale azienda dove viene installato. La schermatura dei cavi di

comunicazione costituisce senza dubbio la soluzione ottimale oltre al fatto

che il protocollo deve essere progettato in modo da capire in ogni istante se

durante la comunicazione ci sono stati eventuali errori.

72

Semplicità: questi protocolli non vengono utilizzati solo tra plc e pc ma

anche tra vari plc, per cui devono essere semplici poiché la

programmazione in questi apparati elettronici non è ancora cosi evoluta

come in quella dei pc. La semplicità, d’altra parte, non é sinonimo di facile

implementazione, infatti implementare questi protocolli su un normale

ambiente di sviluppo di pc comporta un’ottima conoscenza elettronica

riguardo alle varie conversioni. Ad esempio, per lavorare direttamente entro

il Plc, è necessario conoscere a fondo la conversione tra numeri in base

decimale in numeri in base esadecimale (la codifica che usano i Plc ), la

conversione in Bcd e la conversione in Big-endian

Sistemi seriali vs Sistemi ethernet

I principali protocolli utilizzati e progettati dalla maggior parte dei

produttori e venditori di plc si basano su sistemi Ethernet o su sistemi

seriali. Esistono, però, alcune eccezioni nelle quali gli stessi sono

implementati tramite specifici mezzi trasmissivi o reti private, sui quali in

questa sede non ci soffermeremo, in quanto esula dall’argomento trattato.

Relativamente ai sistemi Ethernet e seriali è rilevante sottolineare che non

esiste un vero e proprio paragone tra i due mezzi trasmissivi. I sistemi

seriali sono ormai datati e progressivamente vengono sostituiti da sistemi

USB o da sistemi Ethernet. La tecnologia seriale fu il primo tipo di

collegamento tra i vari dispositivi di controllo. La comunicazione via porta

seriale è un canale uno a uno tra i due dispositivi, è relativamente lenta, è

impossibile in alcun modo poter inserire uno strato software per capire

cosa viene inviato e ricevuto dai due partecipanti alla comunicazione. Come

già spiegato in un precedente capitolo i settaggi della porta seriale devono

essere necessariamente fissati a priori e mantenuti costanti, e non viene

offerta la possibilità di modificare i parametri durante la comunicazione. Al

contrario Ethernet, come già sottolineato in precedenza, elimina questi

73

Header code FCS

limiti: con esso i parametri possono in qualsiasi momento essere variati,

offre una velocità di trasmissione nemmeno paragonabile alla precedente

soluzione, senza contare la possibilità di “sniffare” tutto ciò che passa

attraverso la rete. Ciò detto costituisce ulteriore conferma del fatto che non

può e non deve esserci paragone tra le due tecniche di comunicazione.

I protocolli dei sistemi Omron

C-Command

Uno dei protocolli usati da Omron per la comunicazione tra i plc e tra pc e

plc viene definito e denotato come C-Command. I C-Command sono uno

dei primi protocolli utilizzati dalla ditta implementati attorno agli anni ’80

erano il punto di forza dell’azienda. Comunicano solo ed esclusivamente

mediante porta seriale. Vorremmo brevemente spiegare il protocollo in tutte

le sue parti partendo con il mostrare in un breve disegno la sintassi e

semantica del pacchetto di invio

@ 101 100 Text * CR

Figura 3-1 :pacchetto richiesta C-Command

@ : Utilizzato come inizializzatore

Unit Number : Specifica in BCD da 0 a 32 il numero dell’host link con cui

si deve comunicare

Header Code : specifica il comando che dovrà eseguire il ricevente

Text : Contiene i parametri di ogni comando specificato

nell’header code

FCS : E’ il controllo sulla corretto ricevimento del pacchetto, non

è nient’altro che l’ X-or a due a due dei bit precedenti

Unit Number Teminator

74

Terminator : Contiene l’asterisco e un carattere speciale di terminazione

Nella tabella unicode corrispondeva al carattere 13

Il campo text varia a seconda dell’header code presente e può contenere, ad

esempio, indirizzi di memoria e bit se il pacchetto contiene le istruzioni di

lettura o scrittura, può contenere un orario se il pacchetto si riferisce alla

sincronizzazione dell’orologio. Vorremmo ora costruire una breve tabella

nella quale sono contenuti i possibili header code supportati e da noi

implementanti in questo protocollo:

Tipo Header

Code

Descrizione

RR Lettura memoria CIO

RL Lettura memoria LR

RH Lettura memoria HR

RC Lettura memoria Timer e Counter

RG Lettura memoria stato Timer e Counter

RD Lettura memoria DM

RJ Lettura memoria AR

I/O lettura

memoria

RE Lettura memoria EM

WR Scrittura memoria CIO

WL Scrittura memoria LR

WH Scrittura memoria HR

WC Scrittura memoria Timer e Couter

WD Scrittura memoria DM

WJ Scrittura memoria AR

I/O scrittura

memoria

WE Scrittura memoria EM

R# Lettura timer 1

R$ Lettura Timer 2

Lettura

Timer/Counter

R% Lettura Timer 3

75

W# Scrittura Timer 1

W$ Scrittura Timer 2

Scrittura

Timer/counter

W% Scrittura Timer 3

MS Lettura dello stato

SC Cambiamento di modalità operativa

Stato Unità

CPU

MF Lettura di errori

KS Forzatura a 1

KR Forzatura a 0

FK Forzatura multipla di bit

Forzatura

settaggio

resettaggio bit

KC Cancellazione di tutte le forzature

Modello PLC MM Modello del PLC

Testaggio TS Test

RP Lettura del programma in memoria Modalità

lavoro WP Scrittura del programma in memoria

Creazione

tabella

MI Creazione tabella I/O

QQMR Registro di memoria I/O Creazione

registri QQIR Lettura del registro

XZ Reset della macchina

** Inizializzazione

Processi di

comunicazione

IC Comando lasciato a disposizione dell’utente

Figura 3-2: tabella comandi C-Command

Se il pacchetto di invio é stato ricevuto correttamente segue la sintassi e la

semantica del pacchetto di risposta

@ 101 100 160 160 161 160 Text 160 160 * CR

Figura 3-3 :pacchetto risposta C-Command

Unit Number Header code FCS Teminator End code

76

Il campo Text in certe risposte può anche essere vuoto a seconda del

comando inviato. Se ci sono però stati problemi non dal punto di vista di

sintassi del comando ma se ad esempio una particolare istruzione non è

supportata in una determinata modalità in cui il PLC viene a trovarsi, se vi

è stato un errore nel calcolo FCS, se ancora viene definito un indirizzo di

memoria non incluso nel range disponibile in quel determinato PLC, nel

campo end code viene visualizzato un valore diverso da 00, che si riferisce

ad uno specifico errore. Al contrario se sono avvenuti errori di sintassi e

semantica del pacchetto, viene ricevuto un secondo pacchetto di errore:

@ 101 100 160 160 161 160 160 160 * CR

Figura 3-4: pacchetto errore C-Command

Fins

Rappresenta l’ultimo protocollo nato in casa OMRON. E’ molto affidabile ed

efficiente. Supporta la comunicazione via porta seriale o tramite Ethernet

(mediante socket UDP). Come fatto per il precedente C-Command si

illustrano di seguito la semantica e la sintassi del protocollo:

00 02 160 160 160 MR SR Text ICF RSV GCT DNA DA1 DA2 SNA SA1 SA2 SID Command

Figura 3-5: pacchetto richiesta Fins

Attenzione se però la comunicazione avviene tramite porta seriale bisogna

aggiungere la @ all’inizio e FCS e i due caratteri terminatori alla fine.

Analogamente al precedente si mostrerà il significato di ogni sigla:

Unit Number FCS Teminator End code Header code

77

ICF (Information control field) Configurato per mostrare la

sequenza del datagramma

RSV (Reserve) Bit usati dal sistema

GCT (Gateway Count) Indica quanti nodi di rete il pacchetto può

attraversare da 0 a 8.

DNA (Destination network address) Specifica in esadecimale la rete

di destinazione

DA1 (Destination node address) Specifica il nodo di rete di

destinazione

DA2 (Destination unit address) Specifica l’unità di comunicazione

di destinazione

SNA (Source network address) Specifica in esadecimale la rete

sorgente

SA1 (Source node address) Specifica il nodo di rete di sorgente

SA2 (Source unit address) Specifica l’unità di comunicazione di

sorgente

SID (Service ID) usato per identificare il processo di trasmissione

COMMAND

CODE

Varia da comando a comando

TEXT Varia relativamente al comando inviato

Il settaggio di questi parametri varia però se stiamo utilizzando un

comunicazione seriale, infatti esistono alcune sigle speciali per identificare

che la comunicazione avviene mediante questo mezzo trasmissivo. Questo

protocollo non è così diverso dal precedente. Il campo Text contiene i

parametri dei relativi comandi ad esempio per la lettura di una memoria il

campo command code contiene il comandi di lettura, il Text contiene il

codice della memoria in cui dovrà essere effettuata la lettura, l’indirizzo di

memoria, e se richiesto anche l’indirizzo del bit. Segue l’elencazione in

tabella dei comandi:

78

Command

Code Tipo MR SR

Descrizione

01 01 Lettura memoria

01 02 Scrittura memoria

01 03 Scrittura si blocchi di memoria

01 04 Lettura blocchi di memoria

Accesso memoria

01 05 Trasferimento e copiatura blocchi di

memoria

02 01 Lettura area parametri

02 02 Scrittura area parametri

Parametri di

accesso memoria

02 03 Pulizia area parametri

03 06 Lettura area del programma

03 07 Scrittura area del programma

Area di memoria

del programma

03 08 Pulizia area del programma

04 01 Modalità Run Modalità

operativa 04 02 Modalità Stop/Program

05 01 Lettura modello della Cpu Configurazione

dispositivo 05 02 Lettura dati per la connessione

06 01 Stato della Unità CPU Lettura dello

stato 06 20 Lettura tempo Clock CPU

07 01 Lettura Orologio interno Sincronizzazione

07 02 Scrittura Orologio interno

Messaggio

display

09 20 Tabella Comandi Fins supportati

0C 01 Memoria di accesso di altre periferiche

0C 02 Forzatura Memoria di accesso

Periferiche

esterne

0C 03 Eliminazione Memoria di accesso

79

21 01 Lettura file di log

21 02 Cancellazione file di log

Errori

21 03 Eliminazione del File

21 40 Scrittura area di accesso Fins Errori protocollo

FINS 21 41 Pulizia Area di scrittura comandi fins

22 01 Lettura File

22 02 Lettura di un singolo file

22 03 Scrittura di un singolo file

22 04 Cancellazione File

22 05 Formattazione Memoria

22 07 Copiatura File

22 08 Modifica none del File

22 0A Memoria Di appoggio di trasferimento file

22 0B Parametri di trasferimento File

22 0C Programma di trasferimento file

22 15 Creazione\Cancellazione Directory

Memoria

riservata ai File

22 20 Trasferimento memoria esterna

23 01 Forzatura Bit Forzature

23 02 Eliminazione Forzature

Figura 3-6 : Comandi fins

Analogamente al precedente se la risposta non contiene errori di sintassi il

pacchetto ricevuto viene visualizzato come segue:

00 02 160 160 160 MR SR Text ICF RSV GCT DNA DA1 DA2 SNA SA1 SA2 SID Command End Code

Figura 3-7: pacchetto risposta Fins

80

Anche in questo caso la risposta contiene un altro campo denominato End

Code, che contiene un possibile errore avvenuto durante la comunicazione.

Se tutto è andato a buon fine il suddetto conterrà 00.

Strumenti misti : i bridge ethernet-seriali e le loro caratteristiche

Nell’ambito del progetto per la comunicazione mediante i protocolli sopra

citati è stato utilizzato un piccolo apparecchio elettronico comunemente

chiamato bridge ethernet-seriale. Questo dispositivo permette la

interconnessione fra reti o interfacce anche se logicamente e fisicamente

diverse. In commercio ne esistono di svariati tipi di forme, marche, modelli

e con caratteristiche diverse, in grado quindi di soddisfare la vasta gamma

di problematiche, per cui svolgono la funzione. Ci si soffermerà solo ad

analizzare quello da noi utilizzato, in quanto non ci sembra il caso di

illustrare le funzionalità di tanti altri, che non abbiamo avuto modo di

utilizzare. Il nostro bridge ethernet-seriale è un apparecchio di dimensioni

relativamente piccole, di seguito verrà mostrata la foto (è stato eliminato il

produttore per problemi di copyright).

Figura 3-8: Bridge Ethernet-seriale

81

In questa foto non è visibile, ma come interfaccia di ingresso ha un

connettore RJ45 , mentre in uscita, come si vede chiaramente in figura, vi

è un connettore RS232 o comunemente chiamata porta Seriale. Al suo

interno contiene un piccolo server, nel quale è possibile settare i principali

parametri di configurazione, tra i quali: indirizzo ip e porta del bridge,

parametri di configurazione della porta seriale in uscita, ecc…. Oltre a

questi semplici e importanti parametri offre anche la possibilità di lavorare

in diverse modalità, a seconda della funzione ed infine contiene un access

list (ACL), la quale elenca tutti i possibili indirizzi IP che sono abilitati a

comunicare con o attraverso il bridge . Il corretto funzionamento è

permesso anche grazie ai driver forniti dall’azienda produttrice. Quando

un applicativo vuole comunicare tramite la porta seriale i driver controllano

se la porta seriale esiste veramente (porta fisica); in questo caso la

comunicazione avviene normalmente. Al contrario quando si tenta di

accedere ad una porta seriale inesistente (porta virtuale) i driver

redirezionano la comunicazione (inserendo header e tail appropriati) sulla

scheda ethernet e viene inviato il pacchetto in modo broadcast. Gli

eventuali bridge collegati alla rete ricevono il pacchetto, se la porta seriale

di destinazione coincide con i parametri precedentemente stabiliti,

convertono il segnale e lo trasmettono tramite l’interfaccia di output,

mentre se la porta non coincide, il pacchetto viene ignorato.

82

UN’APPLICAZIONE CONCRETA: CONTROLLO DI PLC OMRON

Obiettivo del progetto

L’esigenza dell’attuazione del progetto in esame proveniva da un’azienda di

medie dimensioni della provincia di Parma del settore metalmeccanico.

L’azienda si trovava in una situazione critica dove la comunicazione fra i

vari dispositivi (i Plc) utilizzava mezzi antiquati, lenti e tecnologicamente

inadeguati. Come esempio vorremmo riportare che la comunicazione era

possibile solo tramite uno switch seriale e manuale. Il richiedente quindi

chiedeva un intervento drastico, modificando radicalmente l’architettura,

metodi e protocolli di comunicazione. Modificando, o meglio creando a

nuovo ad hoc, l’architettura, i vincoli e le esigenze da rispettare non erano

molte (almeno ad un primo ed alto stato di analisi), a parte i soliti vincoli di

costi e flessibilità dell’infrastruttura per ampliamenti futuri. L’azienda ci

invitava a progettare ed implementare un applicativo su piattaforma

Windows XP, unico e di facile utilizzo che potesse espletare tutte le funzioni

che l’architettura e i software già installati già compivano. Questo software

quindi aveva il compito di: comunicare con i vari Plc, e quindi

implementare i protocolli di comunicazione propri dell’azienda produttrice

dei dispositivi. Comunicare e manipolare con un base di dati per

mantenere consistenza e persistenza dei dati utilizzati in ogni fase del

progetto. Ed infine creare un interfaccia grafica locale, simile a quelle già

presente in azienda in altri applicativi, in grado di mettere a disposizione

tutte le funzionalità e le proprietà che questo applicativo offre. La ditta

richiedeva la messa in funzione di un sistema che potesse far comunicare e

configurare i sei PLC presenti nella stessa azienda e responsabili

dell’attivazione sia di macchine utilizzate nella produzione che di operazioni

domotiche.

83

Figura 4-1 : vecchia architettura progetto

La situazione descritta nella figura rappresenta lo stato reale in cui si

veniva ad operare e la carenza strutturale vigente. Si notano pure sei

elementi sostanziali rappresentanti da altrettanti PLC Omron, dei quali

quattro della serie CPM2A con comunicazione seriale mediante C-

Command, e i rimanenti due Omron della serie C200HS comunicanti tra

loro mediante modulo Ethernet con protocollo Fins. I 4 CPM2A

comunicavano tra loro con un PC dedicato ed un piccolo software scritto in

MS-Dos. Tra i PLC e il PC era posizionato un piccolo switch seriale ancora

manuale. Per comunicare con uno di questi quattro si era costretti a:

posizionare il selettore dello switch sul nodo d’uscita voluto caricare il

modulo del programma DOS corrispondente al PLC selezionato solo così si

era in grado di comunicare con suddetto PLC. Gli ultimi due PLC rimasti

erano in contatto tramite un’altra applicazione scritta in Visual Basic,

coadiuvata da un controllo Active X che implementava le varie funzioni di

84

comunicazione, mentre il programma VB eseguiva l’ interfacciamento tra

l’utente e la macchina. Come facilmente si deduce, la situazione non era

più sostenibile e imponeva un intervento radicale al fine di ottenere i

seguenti benefici: eliminare lo switch manuale, quindi portarsi su una

tecnologia ethernet sicura ed affidabile. Sostituire la macchina MS-Dos

dedicata e l’applicativo VB con un programma ad hoc portabile in grado di

fondere in un unico programma le funzionalità svolte prima. Nei prossimi

capitoli verrà mostrato come e in che modo è stato possibile attuare il

progetto.

L’architettura del nuovo sistema

A seguito di una prima analisi del problema sono emerse le caratteristiche

essenziali e i vincoli che il sistema doveva soddisfare. Abbiamo cercato di

creare un architettura ad hoc che permettesse di soddisfare le esigenze ed

è emerso che:

i 6 Plc precedenti sono rimasti; come ovvio era impossibile eliminare o

sostituire i Plc, in quanto il programma e l’aggiornamento sarebbe

diventato troppo oneroso, sia con riferimento all’acquisto di nuove

macchine che riguardo alla nuova programmazione sulle stesse.

L’azienda disponeva già di una architettura DBMS centralizzata, con Oracle

sotto sistema ERP Baan e di altri applicazioni, in particolare installazioni

Oracle Express usate da un altro programma creato da AreaAsp e CS

Soluzioni per il monitoraggio di postazioni di lavoro. Si è ritenuto

opportuno sfruttare questa tecnologia per creare un Database ad hoc il

quale potesse contenere tutte le informazioni necessarie per le varie fasi. Le

informazioni contenute riguardano sia la parte di impostazione, vengono

cioè memorizzati i settaggi necessari per la comunicazione (indirizzo IP o

porta Seriale dei vari Plc, parametri dei protocolli, ecc…), ma anche tutta

un’altra parte per mantenere, reperire informazioni anche senza dover

85

continuamente interrogare i Plc, soprattutto quelli connessi con

collegamenti seriali mantenendo ottime le prestazioni di accesso in base ad

un costo temporale. Come spiegato sopra questa applicazione richiede

anche un costante aggiornamento dell’orologio interno dei vari Plc.

Abbiamo utilizzato un piccolo server presente in azienda, costantemente

acceso per il monitoraggio di un’ altra applicazione, inserendo un piccolo

modulo software - chiamato appunto Sincronizzatore – che, dopo un tempo

costante, aggiorna l’ orologio di ogni Plc con l’ora corrente del server in cui

l’ applicativo è installato. L’ultimo ma non meno importante componente è

il programma di interfaccia utente, installato sulla postazione di controllo,

unico vero collante tra le varie parti del sistema.

Questa, viste le soluzioni precedenti e i vari software presenti in azienda,

necessitava essere snella, rapida da comprendere ed usare e infine dotata

di molti shortcut key (o tasti i scelta rapida) molto simile a vecchie

applicazioni Dos.

I sistemi controllati

Dopo aver mostrato l’architettura generale del sistema, abbiamo svolto una

breve e semplice analisi, dalla quale sono emerse le entità coinvolte

meritevoli di considerazione.

Qui sotto si propone un piccolo e breve elenco per capirle comprenderle al

meglio.

I PLC: Sono 6 e precisamente di due famiglie : 4 sono CP1A egli ultimi 2

C200HS. I primi comunicano solo ed esclusivamente mediante porta

seriale, mentre gli ultimi 2 comunicano tramite Ethernet e/o porta seriale.

Le caratteristiche tecniche e logiche di queste entità sono già state

illustrate nei capitoli precedenti.

86

Lo SCADA : é un piccolo modulo software installato su un server che ha il

compito di sincronizzare gli orologi all’ interno dei PLC. Le caratteristiche

teoriche degli scada sono state chiarite in precedenza mentre per la parte

implementava é rimandata ad un successivo capitolo.

DBMS : Si tratta di una postazione Oracle già largamente utilizzata in

azienda sia per gestire la contabilità, che come base dati per altri

applicativi. Nel presente progetto viene utilizzata per mantenere la

persistenza e la consistenza dei dati. La logica di costruzione della base di

dati è definita e abbondantemente descritta successivamente.

L’ INTERFACCIA UTENTE: L’interfaccia locale da noi ideata fa in modo che

tutte le varie parti sopra elencate vengano unite, collegate in modo che tutti

gli utenti, anche con poche conoscenze tecniche, possano usufruire e

sfruttare le potenzialità offerte dal sistema. Si è pensato di crearne solo

una locale con tecnologia Windows Form, essendo l’ applicativo interno

all’azienda e non richiedente una visualizzazione o una manipolazione in

sedi al di fuori dell’azienda.

I Plc e le strutture associate

Per comunicare fra i vari PLC, abbiamo dovuto inserire dispositive o schede

elettroniche, atte al raggiungimento di una comunicazione snella e veloce.

Nei nuovi PLC, cioè quelli della famiglia C200HS, è possibile inserire una

scheda di rete, chiamata precisamente ETN-11, la quale, a sua volta,

contiene un connettore RJ45, il classico connettore di rete Ethernet.

Questo fa si che tra un normale computer e suddetto PLC, la

comunicazione avvenga tramite rete Ethernet. I dispositivi associati sono i

più comuni utilizzati in qualsiasi altro ambiente, dove la comunicazione

avviene mediante l’anzidetta tecnologia. (Hub,router,switch,ecc..) Per i

87

restanti PLC, quelli facenti parte della famiglia CP1A, tale modulo ETN-11,

non era più in produzione, pertanto la comunicazione poteva avvenire solo

ed esclusivamente mediante porta seriale. E’ stato quindi necessario

ricorrere ad un bridge ethernet seriale, in grado di ricevere in input un

segnale ethernet, convertirlo in un segnale seriale, inviarlo al plc e

viceversa. In questo modo tutta la comunicazione globale avviene tramite

cavi RJ45, mentre il cosiddetto “ultimo miglio” avviene tramite canale

seriale.

Lo Scada e le sue caratteristiche

Dal punto di vista teorico lo scada è stato trattato in modo esaustivo nei

capitoli precedenti. Un’architettura di questo tipo però entra pedantemente

a far parte del nostro applicativo come sincronizzatore degli orologi interni

del plc. Vorremmo quindi spiegare brevemente la infrastruttura e la

architettura da noi sfruttata e utilizzata. La tecnologia usata é stata, nel

complesso, molto semplice. Come interfaccia grafica abbiamo pensato di

creare una piccola form che derivasse dalla classe WindowsForm presente

in C# in modo da avere tutte le potenzialità di una classica interfaccia

utente , ma con la possibilità di creare overriding e overloading dei metodi

per poter eliminare alcuni aspetti delle form per noi poco interessanti. La

form da noi creata risulta molto semplice e intuitiva, contiene il simbolo

dell’azienda, una progressbar e alcune label per visualizzare il risultato. Il

sincronizzatore opera in questo modo: sfruttando i componenti C# e

precisamente il componente Timer ne sono stati creati 7 uno generale e i

restanti associati ad ogni singolo stabile. Il primo chiamato -timer generale-

viene attivato ogni 15 minuti, questo non fa altro che attivare un altro

timer, e precisamente quello dello stabile A ( la scelta é ricaduta su questo

perché è il primo in ordine alfabetico, non per motivi tecnici) Il timer dello

stabile A richiama il comando per la sincronizzazione dell’orologio interno.

88

Inoltre, analizzando a fondo il programma del Plc ci siamo accorti che

l’orario era ripetuto all’interno di memorie utilizzate esclusivamente dal

programma e precisamente nella Dm 0, 1 e 2. L’orario però in queste 3

celle di memorie era diviso in questo modo: nella prima erano memorizzati i

secondi, nella seconda era memorizzato l’orario come minuti dalla

mezzanotte, cioè un numero intero compreso tra 0 se si trattava della

mezzanotte del giorno corrente e 1439 se si trattava della mezzanotte

meno un minuto. Ed infine nella terza ed ultima Dm era memorizzato il

giorno come un numero intero progressivo e compreso tra 1 se si trattava

di lunedì e 7 se si trattava della domenica. Questo timer rimane attivo per 1

minuto infatti il tempo che intercorre tra l’ invio del primo pacchetto

(sincronizzazione orologio) e la risposta dell’ultimo (scrittura avvenuta

correttamente) anche in casi peggiori è sicuramente minore . Ultimate in

modo corretto le sue operazioni attiva il secondo timer che svolge le

medesime operazioni. Terminate poi la sincronizzazioni dei primi 4 stabili

si passa alla sincronizzazione degli ultimi 2 stabili. In questo caso però il

programma contenuto all’interno dei PLC costantemente ed in automatico

aggiorna il suo orario anch’esso creato nelle sue dm cosi in questo caso é

bastato solo creare un piccolo socket e inviare tramite esso il comando

Fins appropriato. Terminato ciò si disabilitano e si rimane in attesa della

nuova abilitazione. Se il sincronizzatore per qualche motivo non riesce a

comunicare o i parametri dei comandi inviatogli sono errati in automatico

inserisce all’interno del database un record nella tabella dei log contenente

il tipo di errore.

La base di dati per la persistenza

Come in ogni applicazione che si rispetti anche in questo caso serviva una

base dati per la persistenza, la coerenza, la manutenibilità e i possibili

89

aggiornamenti o ampliamenti futuri. La nostra base di dati deve essere in

grado di soddisfare i seguenti requisiti:

• Contenere tutti i dati relativi ai dettagli generali dell’applicazione,

come ad esempio i parametri di connessione ai vari plc, i parametri

del protocollo Fins, e alcuni parametri riferiti ad alcune preferenze

dell’utente

• Contenere gli stessi dati, ovviamente in un formato diverso , presenti

in ogni Plc , per far si che gli utenti di questa futura applicazione, non

siano costretti a collegarsi ad un particolare Plc per poter visualizzare

i dati contenuti, ma con semplici istruzioni SQL possano essere

visibili , aumentando in questo modo l’efficienza globale (rispetto al

tempo di esecuzione).

• Contenere i dati e i vari privilegi degli utenti che andranno ad

utilizzare questa applicazione aumentando in questo modo la

sicurezza .

• Contenere un piccolo storico delle operazioni svolte per mantenere la

tracciabilità e la possibilità di effettuare un rollBack delle possibili

operazioni dannose commesse all’interno del sistema.

Dopo una lunga analisi (con non poche discussioni) siamo arrivati a

definire un piccola base di dati.

90

Figura 4-2: diagramma ER

91

Il Diagramma ER sovrastante spiega i collegamenti logici tra le varie

tabelle, mentre non spiega la semantica delle tabelle, che però viene di

seguito illustrata

PLC_LIST : oltre che ha contenere i 6 plc con i suoi dati “personali” sono

presenti anche i parametri di connessione.

RELE : contiene la lista delle uscite abilitate, che noi per semplicità

abbiamo definito in questo modo. Infine contiene tutti i vari parametri che

servono all’applicazione per trattare in modo corretto le possibili uscite o

rele che i Plc associati ofrono.

FASCIA : suddetta tabella contiene gli orari di inizio e fine di ogni relé

precedentemente abilitato. Una sua particolarità è quella di non caricare

antecedentemente tutte le fasce che potranno essere inizializzate, ma solo

quelle veramente abilitate, (cioè quelle che hanno subito una modifica da

un utente abilitato), in modo da evitare spreco di spazio. E’ stato il motivo

per cui è stato necessario inserire un campo numerico posizione che

permette, anche grazie al giorno e al relé , di risalire con precisione e senza

margine di errore la reale ubicazione della fascia.

UTENTI : questa piccola tabella contiene i minimi dati anagrafici di un

futuro utilizzatore dell’applicativo. Per mantenere alto il livello di sicurezza

tutta questa tabella verrà criptata utilizzando una chiave di 32 caratteri

PRIVILEGI : contiene i relé o gli stabili che un dato utente può manipolare

(modificare fasce orarie). Se un determinato utente e un Power Admin ,

sinonimo di Amministratore generale, questa tabelle viene ignorata poiché

questo particolare utente ha tutti i privilegi.

92

LOG e SESSIONI : la tabella dei log contiene le operazioni principali svolte

dagli utenti, mentre nella tabella sessioni è contenuto l’ora di ingresso,

inteso come login effettuato in modo corretto, e l’ora di uscita, intesa come

disconnessione o chiusura della form principale, di un utente.

Per l’implementazione di questa base di dati inizialmente ho creato tutte le

tabelle mediante comandi SQL . Per ogni tabella, poi, ho utilizzato una

sequence cioè un contatore che viene impiegato come chiave primaria.

L’unicità di questo particolare elemento viene costruita mediante la

realizzazione di un trigger che, dopo l’inserimento di un determinato

record, incrementa il contatore e lo inserisce nel campo prestabilito. Al

termine mi sono preoccupato di generare dei particolari trigger in grado di

mantenere coerenza e consistenza tra le chiavi primarie e le chiavi esterne

presenti nelle varie tabelle. In corso d’opera poi il cliente, ha modificato le

richieste, esigendo la possibilità che l’applicazione svolgesse il suo normale

compito (anche con funzionalità ridotte) senza la base di dati. Bisognava

quindi trovare una soluzione veloce, ottimale senza dover stravolgere il

codice e la logica già definite e scritte. Dopo una breve analisi e una lunga

ricerca tramite Internet, si è giunti alla soluzione creando dei file Xml in

grado di simulare la stessa base di dati (o almeno una parte…) su questi

particolare file. Pure in questa occasione abbiamo sfruttato le potenzialità

offerte dall’ ambiente di sviluppo e in particolare la libreria di classi

chiamate System.Linq. Tale libreria richiede in input uno schema (sfruttato

nel file per creare i tag e i nodi principali) e una serie di dati nello stesso

formato utilizzato in un database ed in output restituisce il file Xml. Come

si intuisce da quanto detto prima,la libreria non è nient’altro che un parser

Xml che permette di creare e gestire una piccola o modesta base di dati su

file, questo comporta anche la possibile ricerca, cancellazione, o modifica

dei record, chiamati, nello specifico, nodi. Il pacchetto Linq in questo caso

mette a disposizione un particolare linguaggio molto simile al linguaggio sql

atto a svolgere tutte le operazioni sopra citate. Per inserirlo nella logica

precedentemente definita abbiamo creato un serie di classi che hanno il

93

compito di svolgere le funzioni di manipolazione di dati su Xml, cioè un

adapter . Infine, sfruttando al massimo le capacità della programmazione

OOP abbiamo aggiunto un nuovo strato software, con il compito di

mantenere congruente la base di dati con file Xml. Ogni volta che viene

salvato un particolare record all’interno del database, viene salvato

contemporaneamente sul file Xml, cioè un wrapper, un “cappello” che

maschera il salvataggio.

Visione di insieme

Il disegno sottostante illustra la struttura generale dell’ architettura da noi

realizzata:

Figura 4-3: nuova architettura

94

Come si può notare sono presenti i sei plc dei quali due collegati

direttamente alla rete ethernet, mentre i restanti collegati mediante il

bridge ethernet-seriale. La base dati oracle è accessibile da ogni Pc o

dispositivo collegato.

Figura 4-4: Schermata principale

La schermata principale che, come spiegato, contiene e collega tutti gli

aspetti fondamentali. Questo infatti maschera la vera implementazione,

costituendo buona parte del lavoro svolto durante il tirocinio. Tutto

l’applicativo è stato diviso in pacchetti, contenenti ciascuno un insieme di

classi atte a soddisfare una determinata tipologia di problema. Vorrei

brevemente elencare i pacchetti presenti nell’applicativo da me

implementato. Il primo pacchetto contiene le classi che si occupano del

canale di comunicazione e precisamente quello seriale ed ethernet (socket

95

UDP). Il secondo implementa i vari protocolli proprietari di Omron . Il terzo

pacchetto implementa la connessione e la comunicazione al database. Il

quarto si occupa di strutturare in memoria locale tutti i dati e le

informazioni presenti nel database. Ogni entità, quindi, viene rimappata in

memoria mediante le classi atte alla manipolazione dei dati all’interno del

database e all’interno dell’applicazione stessa. Il quinto pacchetto si occupa

delle varie conversioni dei dati per la comunicazione o per la corretta

sintassi dei dati utilizzati all’interno del PLC. L’ultimo pacchetto contiene

tutte le interfacce grafiche (quella rappresentata nella figura sovrastante è

solo la principale, ma, ne sono state realizzate molte altre al fine di

raggiungere un discreto grado di semplicità e immediatezza riguardo la

manipolazione dei dati). Il medesimo pacchetto sviluppa funzioni in grado

di soddisfare appieno le richieste del cliente. Un esempio è la navigazione

completa dell’interfaccia mediante short-key.

Figura 4-5: schermata sincronizzatore

La figura 4-5 rappresenta l’interfaccia del sincronizzatore. Questo piccolo

applicativo non è contenuto nel precedente, ma per svilupparlo ho

utilizzato pacchetti, classi e funzioni proprie di quello sopra citato.

96

IL LAVORO OPERATIVO

Difficoltà incontrate

Dopo aver mostrato nei vari capitoli precedenti tutto ciò che riguarda

l’applicativo, visto sia dal punto di vista teorico sia dal punto di vista di

implementazione e progettazione vorrei soffermarmi sulle difficoltà avute e

incontrate in corso d’opera. Dal punto di vista di progettazione non

abbiamo incontrato particolari difficoltà perché il sistema era

completamente da rifare, i vincoli erano pochi tra i quali la struttura della

rete e anche la sua disposizione. Il problema maggiore è stata la vera e

propria implementazione, data anche dalla nostra poca esperienza con

l’ambiente di sviluppo. Abbiamo cominciato ad implementare i C-

Command, i manuali a disposizione erano tanti ma non sempre

descrivevano effettivamente ciò che si doveva fare nella realtà. E’ giusto

sottolineare che il protocollo utilizza una comunicazione seriale pertanto

era impossibile inserire tra i due attori uno strato software per capire o

visualizzare ciò che i medesimi si inviavano. Dopo alcune prove, ricerche e

tentativi il protocollo è stato implementato correttamente. Siamo poi

passati al protocollo Fins, in questo caso i manuali erano molto più efficaci

ed efficienti, le spiegazioni erano dettagliate (anche se alcuni parametri non

erano documentati sufficientemente). Il problema incontrato in questo

caso era rappresentato dall’implementazione di un socket UDP con il nuovo

linguaggio di programmazione, anche in questo caso, dopo molte ricerche

su Internet, la cosa si è risolta nei migliore dei modi. Il lavoro di

implementazione del socket, non è stato in seguito utilizzato entro il

progetto complessivo perchè in corso d’opera è risultato preferibile usare

un componente “chiuso” associato ai convertitori Ethernet-seriali. Il passo

successivo é stata la creazione del database. Questo passaggio non ha

creato alcuna difficoltà, sia dal punto di vista della progettazione sia quella

implementativi. Creato il diagramma ER è stato molto semplice ed intuitivo

97

l’implementazione tramite linguaggio sql. Forse l’unico ostacolo é stata la

creazione di “sequenze”. Oracle non contiene un campo speciale di chiave

primaria che permette in automatico la creazione di un numero univoco

che rappresenta ogni record. In Oracle bisogna creare una successione e

un trigger in grado di sopperire la mancanza di questo campo speciale. Un

ulteriore passaggio è stato quello di creare i metodi e le classi per la

comunicazione e la manipolazione di ogni entità all’interno dei database.

Dal punto di vista di logica implementativa non ci sono stati problemi

poiché è bastata la mia poca esperienza a portare a termine questo step.

Qualche difficoltà si è presentata con la vera e propria implementazione.

Per ultimo abbiamo affrontato il lavoro non poco difficoltoso della creazione

dell’interfaccia utente Per risolvere e soddisfare le richieste del cliente si

sono dovute creare molte icone semplici e intuitive da inserire nelle varie

parti del programma per facilitare gli accessi all’utenza. E’ stato poi

semplice “incollare” i vari passaggi sopra elencati, in quanto nelle varie fasi

di progettazione di ogni singola si sono applicate le tecniche apprese nel

corso di laurea.

Correzioni in corso d’opera

Avendo sviluppato un’ottima documentazione e un’ottima progettazione le

correzioni in corso d’opera sono state relative solo ad alcuni componenti e

alla realizzazione nell’interfaccia grafica. Per spiegare meglio il tutto si cita

l’esempio più lampante: durante l’implementazione dei C-Command

abbiamo creato una piccola classe chiamata SerialPortWrapper che

utilizzava al suo interno il componente porta seriale contenuto in C#. Fino

a che la comunicazione tra PC e PLC avviene in modo diretto non vi è alcun

problema, quindi abbiamo proseguito per questa strada, quando però tra i

PC e PLC si è dovuto inserire il bridge Ethernet seriale, la comunicazione si

bloccava. In un primo momento pensavamo che il problema si dovesse

98

attribuire al Bridge, ma scaricando da Internet un piccolo applicativo Open

Source scritto in Visual Basic 6, abbiamo constatato che la comunicazione

avveniva in modo non solo corretto, ma anche veloce. Il problema quindi si

è spostato dal Bridge al programma in sé. Chiedendo parere ad esperti si è

compreso che la gestione dell’oggetto porta seriale all’interno di C# era

completamente diverso e non supportava di conseguenza le porte virtuali.

Si è deciso pertanto di importare l’oggetto porta seriale, creando un Active

X da VB 6. Nel momento in cui abbiamo dovuto implementare la classe

socket, avendo riscontrato lo stesso problema, si è proceduto

analogamente. Su espressa e specifica richiesta del cliente, sono state

successivamente apportate variazioni e correzioni all’interfaccia grafica.

99

CONCLUSIONI

Il sistema in esecuzione

Dopo una prima fase di test eseguita in ufficio si è portato l’applicativo in

azienda, procedendo in questo modo: si è mantenuto l’applicativo vecchio e

si è installato a fianco il nostro nuovo. La situazione rimarrà tale per circa

quattro mesi, così da poter avviare una approfondita fase di collaudo in

azienda e, nel caso di riscontrassero problemi, non venga interrotta la

normale esecuzione del sistema. In questa prima fase si è constatato che il

programma è abbastanza affidabile per quanto riguarda la comunicazione

con il PLC. Sono emerse delle normali incongruenze dovute a piccoli errori

di programmazione o dei vari parametri, che impostati durante la fase di

sviluppo, avevano un determinato valore diverso da quello rilevato in

azienda. Questa tipologia di errore si sa che è inevitabile ed è sempre da

tenere in considerazione per questo motivo, come spiegato si è scelto di

mantenere in parallelo le due soluzioni.

Bilancio del lavoro svolto

Mi ritengo abbastanza soddisfatto del lavoro svolto, ho potuto imparare,

capire e sviluppare un applicativo di medie dimensioni seguendo ed

implementando ogni parte, partendo prima dall’analisi fino al più basso dei

livelli cioè la vera e propria stesura del codice ricordando e applicando,

anche a volte con molte difficoltà tutte le regole, i vincoli e le ottimizzazioni,

conosciute e apprese nel corso di laurea. Un’ottima analisi a monte

permette di avere delle fondamenta solide per evitare spiacevoli

inconvenienti e che il programma si svolga in modo fluido e senza

particolari intoppi. L’analisi infatti, coadiuvata dai tutors, approfondita e

studiata nei minimi dettagli, ha prodotto un ottimo risultato. Lo sviluppo

del database, per il quale sono maggiormente appassionato, è stato

100

interessante ed istruttivo. Utilizzando un sistema di DBMS nuovo e di alto

livello ho avuto modo di ampliare la mia esperienza e la mia conoscenza. Mi

sono avvicinato al mondo del PLC, anche se di una singola marca, ma

parlando in ufficio con gente più esperta di me, ho potuto comprendere che

anche gli altri PLC di diversa marca, mantengono caratteristiche pressoché

simili. Non ho dubbi ad affermare di aver pertanto acquisito concrete

capacità di lavorare su PLC di qualsiasi altra marca. La vera e propria

implementazione è stata complicata, ma nello stesso tempo anche

interessante. Ho potuto e dovuto scrivere righe di codice agendo su varie

parti, anche completamente diverse, ma riutilizzabili sicuramente in altri

programmi. Si parte infatti dalla creazione di codice atto alla

comunicazione (porta seriale, e socket), la realizzazione di un protocollo (nel

caso specifico C Command e Fins, includendo pure la gestioni dei diversi

errori), la comunicazione con un data base, l’implementazione di query per

la manipolazione dei dati, la realizzazione di controlli per la manipolazione

di file XML ed infine una miriade di procedure, funzioni, classi e pacchetti

allo scopo di raggiungere la corretta e completa funzionalità del software.

Applicazioni e ampliamenti futuri

Avendo sfruttato tutte le proprietà e le caratteristiche sia apprese al corso

di laurea sia offerte nell’ambiente di sviluppo, la prima applicazione

potrebbe essere lo sviluppo di un’interfaccia web, in modo tale da poter

manipolare e monitorare i dati anche all’esterno dell’azienda. Con poche

modifiche del codice è possibile inserire una nuova entità, che definiamo

come “profilo” o meglio configurazione. L’entità raggrupperebbe un insieme

di relé impostati in modo tale da gestire gli interventi rispondendo ad

esigenze di orari e periodi diversi. Per spiegarmi meglio, gli orari invernali

sono diversi da quelli estivi, gli orari feriali non sono gli stessi rispetti i

festivi o i prefestivi, le ore diurne richiedono comandi differenti a quelli

101

notturni ecc…. L’utente avrebbe quindi la possibilità di opzione sui diversi

profili e un’amplia possibilità di caricamento dati. Non vediamo rilevanti

applicazioni o aggiornamenti futuri in quanto l’applicazioni e stata creata

ad hoc per quell’azienda rispettando le tutti i suoi vincoli ed esigenze. Ciò

non toglie pero che parti di codice vengano inserite in un altro contesto e

essere riutilizzate per scopi completamente diversi , si pensi al protocollo di

comunicazione Omron , la connessione al DataBase , la gestione dei file

Xml ,ecc…

102

INDICE DELLE FIGURE

1-1 Il modello client-server

1-2 Una rete broadcast

1-3 Una rete punto a punto

1-4 Topologie Bus e Ring

1-5 Distribuited Queue Dual Bus

1-6 Struttura tipica di una WAN

1-7 Topologie di interconnessione

1-8 Interconnessione di router via satellite

1-9 Interconnessione di router via radio al suolo

1-10 Interconnessione di reti

1-11 Relazioni fra subnet, network e internetwork

1-12 Dialogo fra peer entity

1-13 Dialogo fra grandi menti

1-14 Flusso di informazioni fra peer entity

1-15 Servizi connection-oriented (a) e connectionless (b)

1-16 Relazioni fra protocolli e servizi

1-17 Modello OSI

1-18 Rappresentazione schematura dei livelli gestiti lungo un

cammino

1-19 Relazione fra i livelli OSI e TCP/IP

1-20 Relazione tra i livelli e i protocolli dell’architettura TCP/IP

1-21 Schema di propagazione di disturbi elettromagnetici tra un

dispositivo sorgente di disturbi (Device 1, EMC Source) e un

dispositivo soggetto a tali disturbi (Device 2, EMC Sinc). In

rosso i disturbi irradiati; in azzurro i disturbi condotti.

1.22 Schema pacchetto Ethernet

1-23 Codifica Manchester

103

1-24 Retro di un PC con due porte RS-232 (i due connettori

maschio in basso)

1-25 Segnale della porta RS232

2-1 Schema logico architettura CIM

2.2 Piramide CIM

2.3

Schema logico SCADA

3-1 Pacchetto richiesta C-Command

3-2 Tabella comandi C-Command

3-3 Pacchetto risposta C-Command

3-4 Pacchetto errore C-Command

3-5 Pacchetto richiesta Fins

3-6 Comandi Fins

3-7 Pacchetto risposta Fins

3-8 Bridge Ethernet-seriale

4-1 Vecchia architettura progetto

4-2 Diagramma

4-3 Nuova architettura

4-4 Schermata principale

4-5 Schermata sincronizzatore

104

BIBLIOGRAFIA [1] G.Destri : Introduzione ai sistemi informativi aziendali, Mup Editore,

Parma, 2007

[2] G.Destri : UML nella progettazione software 2003 ,slide per il corso di

ingegneria del software

[3] C.Chiodelli :Sistema Intelidomus IP,2005

[4] C.chiodelli :Building & home Automation 2004

[5] Tanenbaum Andrew S. : Reti di Calcolatori , Addison Wesley ,2003

[6] G.Bongiovanni : sistemi di elaborazione Università di Roma 2000

[7] Omron : manuali operativi Cp1x, 1996 http://www.omron.com/

[8] Omron : manuali Operativi C200H, 1999 http://www.omron.com/

[9] Moxa : manuali Operativi Nport 5110, 2005

[10] I.Bacchi : Progettazione di applicativi per la super visione domotica

2005

[11] Wikipedia : Standard Seriale

[12] Wikipedia : Rumore ed interferenze elettromagnetiche.

COSTRUZIONE DI PROTOCOLLI DI COMUNICAZIONE TRA PC E ...€¦ · tesi di laurea costruzione di...

Documents

Transcript of COSTRUZIONE DI PROTOCOLLI DI COMUNICAZIONE TRA PC E ...€¦ · tesi di laurea costruzione di...