INTRODUZIONE

Automazione: studia le metodologie e le tecnologie che

permettono il controllo di flussi, energia, materiali,
informazioni etc… per la realizzazione di processi.

Automatica: forte connotazione matematica. Studio delle

proprietà strutturali dei modelli matematici, simulazione,
progetto e verifica di sistemi di controllo. Diagnosi dei guasti.

Per intenderci:
Automazione
Tilli
Automatica
Castaldi
È un campo fortemente interdisciplinare.

La corretta e scrupolosa progettazione funzionale di un sistema di controllo ha molti vantaggi:

• Dimensionamento “ottimo” del sistema.
• Possibile rimappare su diversa tecnologia.
• Documentazione/riutilizzabilità.

Piramide dell’automazione: la struttura gerarchica e modulare

semplifica la gestione della complessità. In ogni livello i diversi
moduli vedono il sistema fisico reale più i controllori dei livelli
inferiori.
LIVELLI ALTI: dati complessi e strutturati, assenza di vincoli
temporali stretti.
LIVELLI BASSI: dati semplici a frequenza elevata.

Controllo diretto di variabili temporali: v. Castaldi.

Controllo logico: è il controllo “supervisore”
controllo della sequenza di operazioni da compiere. È
essenzialmente realizzato con operazioni di logica combinatoria o sequenziale.
Spesso il controllo logico si trova a un livello gerarchico superiore rispetto al controllo di sequenze.

Modelli funzionali dei controlli
in generale MIMO (Multiple-Input-Multiple-Output) costituiti da più SISO
in cascata (o, comunque, opportunamente configurati).

Modello generale di riferimento:

• Unità di elaborazione: fatta in diverse tecnologie, anche distribuita. Tecnologia utilizzata:
elettronica digitale di tipo programmabile + informatica. PRO: potenza computazionale, affidabilità,
flessibilità, interazione con l’operatore, interfacciamento con l’esterno. CONTRO: difficile gestire
campionamento e quantizzazione.
Miglioramento: informatica real-time per le applicazioni più delicate.
Alternativa possibile: elettronica analogica + elettromeccanica
scelta in via d’estinzione, ma
ancora molto valida dove il compromesso costo/tempo di campionamento è critico oppure dove il
controllo di sequenza è semplice.
• Sistema di comunicazione: dipendente dalle unità di elaborazione. Di tipo digitale, topologia
punto-punto e bus/rete a cablaggio semplificato. Prospettiva interessante: bus/rete standardizzati
per riutilizzo, espandibilità, intercambiabilità. Problemi: collisioni e ritardi.
 • Sensori: configurabili. Forniscono misure e trasferiscono l’informazione dal dominio del sistema
fisico al dominio del sistema di elaborazione. Schema e architettura di interfacciamento: sensore

elettronica analogica
trasmissione analogica
adattamento livelli (analogico)
convertitore
A/D. PRO: semplice. CONTRO: necessità di compatibilità EM, cablaggi con molti sensori.
Alternativa: sensore
elettronica analogica
conversione A/D
trasmissione digitale. PRO:
robustezza, flessibilità, maggiore compatibilità EM. CONTRO: complessità sul campo, ritardi,
necessità di determinismo.
• Attuatori: dispositivi di potenza con un minimo di intelligenza. Convertono il comando di controllo
in azioni sul sistema fisico. Problematiche duali rispetto ai sensori, ma soluzioni simili.
• Comunicazione con l’esterno: bus o reti digitali standard. Vincoli di determinismo e bassi ritardi
meno stringenti. No carichi computazionali rilevanti per unità di elaborazione.

Mappare uno specifico schema funzionale in uno tecnologico.

1. Definizione della tipologia di unità di elaborazione, nonché delle specifiche implementative
dettagliate (tempo di campionamento, precisione…).
2. Definizione della tipologia di sensori e attuatori.
3. Raggruppamento degli algoritmi di controllo per affinità e contiguità gerarchica.
4. Definizione del sistema di comunicazione fra sistemi di elaborazione.
5. Definizione del sistema di interfacciamento con l’esterno.

MICROCONTROLLORI E DSP

Due soluzioni possibili:

• Elaboratori general purpose
PC standard.
• Elaboratori dedicati e “speciali”
microcontrollori (piccoli) e processori di segnali (più potenti).

Microcontrollore: speciale microprocessore per il controllo, orientato a grande capacità di gestione I/O,
riducendo costi e ingombri. Componenti principali: memoria, convertitori D/A o A/D, interfaccia di
comunicazione seriale, gestione di tempo ed eventi, I/O digitale.

DSP: processore progettato per minimizzare i costi dell’elaborazione digitale dei segnali. Usato spesso
anche come co-processore matematico. Prestazioni molto elevate (ottenibili e superabili con processori da
PC, ma con costi/ingombri molto maggiori). Architettura speciale che comprende: moltiplicatore hardware
integrato, supporto ad operazioni “al volo”, struttura a pipe-line, supporto per very long instruction word.
Linguaggio assembler ottimizzato per l’esecuzione di prodotti scalari (operazioni MAC – Multiply
Accumulate).

SISTEMI DI ELABORAZIONE REAL-TIME PER L’AUTOMAZIONE

Le funzioni di controllo sono strettamente legate al tempo: ci sono molte specifiche da rispettare.
Sistemi real-time
sistemi di elaborazione con vincoli temporali, richiesta di:
• Correttezza logica: risultati forniti devono essere quelli previsti.
• Correttezza temporale: risultati prodotti entro certi limiti prefissati (deadlines).
o Hard real time: non è ammesso il non rispetto delle deadlines (es. allarmi).
o Soft real time: il non rispetto delle dealdines è tollerato entro certi limiti (es. risposta di un
ascensore ad una chiamata).
Altra distinzione:
o Real time stretto: vincoli temporali stretti rispetto ai tempi di calcolo necessari per eseguire le
operazioni richieste (caso più frequente, ahimé). Risulta fondamentale la corretta
organizzazione delle fasi di elaborazione per il rispetto delle deadlines.
 o Real time largo: vincoli temporali larghi rispetto ai tempi di calcolo (v. sopra).
I sistemi RT devono svolgere più applicazioni (task) che possono essere completamente indipendenti.
Un’attività RT, una volta avviata, deve iniziare a compiere un’elaborazione per fornire risposte prima che
sia trascorso un certo tempo dall’evento.
Due tipi di attività:
• Trasformazionale: attività avviata quando accade un certo evento. Tutti i dati vengono rilavati
dall’esterno all’avvio dell’applicazione e tutti i risultati vengono dati al suo termine. Deadline di
risposta diventa una deadline sul tempo di durata dell’applicazione. Non è prevista interazione con
l’esterno.
• Reattivo: applicazione riceve eventi (e dati) e produce risposte durante tutto il tempo fra
avviamento e terminazione. Presente interazione continua fra ambiente e applicazione. La deadline
non è tanto sull’attività quanto sulle risposte.
Eventi:
• Periodici: si ripetono ad intervalli fissi.
• Non periodici: classificati in
o Aperiodici: si possono presentare a intervalli di tempo qualunque.
o Sporadici: si possono ripetere ad intervalli di tempo superiori ad un certo lower bound.
I sistemi RT possono dover eseguire più attività contemporaneamente (in parallelo). Possono farlo con un
processore solo (il parallelismo è logico, ma non reale
programmazione concorrente, sempre necessaria
se {# dei processori < # dei task paralleli} e/o se vi sono risorse condivise), o con più processori (parallelismo
anche reale).
Elemento centrale della programmazione
concorrente: scheduling
algoritmi per distribuire le
risorse d’elaborazione a varie entità o tasks

ordinamento nel tempo delle elaborazioni richieste
dai task su un certo parco-CPU. Influenzano
pesantemente le deadlines.

Un task RT può avere i seguenti stati:

• Inactive: non vi sono eventi pendenti da servire.
• Active: vi sono eventi da gestire (running, in esecuzione, ready, in attesa, blocked, in attesa di
risorse condivise o di un vincolo).
Tipologie di algoritmi di scheduling:
• Per sistemi a mono o a multi-processore.
• Preemptive o non-preemptive (task interrompibili o meno).
• Off-line: ordinamento dell’esecuzione definito a priori.
PRO: bassissimo overhead a runtime. Sincronizzazione implicitamente risolta, elevata predicibilità.
Molto performanti e semplici. CONTRO: bassa flessibilità, necessaria conoscenza completa a
priori.
• On-line: ordinamento definito a tempo di esecuzione in base al parametro “priorità” (statica,
stabilita a priori, dinamica, variabile durante l’esecuzione).
PRO: flessibilità alta, non necessaria conoscenza a priori. Più efficaci (capacità di trovare
schedulazione conforme a vincoli RT).
CONTRO: overhead di calcolo a run-time, bassa predicibilità, maggiore complessità.
Di seguito faremo l’ipotesi di avere:
• Sistemi monoprocessore.
• Task con periodi di ripetizione noti e costanti.
• Task non interagenti.
U = fattore di utilizzazione
n
Ci 
Parametro importante = fattore di utilizzazione
U = ∑ → Ci = tempo di elaborazione
i =1 Ti T = tempo d'utilizzazione
 i
U pari o inferiore a 1 è sempre condizione necessaria e, con certi algoritmi, sufficiente per schedulabilità.

Possibili scelte:
• FIFO (First-In First-Out): è on-line a priorità dinamica, non-preemptive, semplice. Ordinamento
esecuzione secondo ordine di attivazione. Nessuna garanzia di rispetto delle deadlines. Condizione
U ≤ 1 è necessaria ma non sufficiente.
• RMPO (Rate Monotonic Priority Ordering)
on-line a priorità statica, preemptive. Ad ogni task viene
assegnata una priorità proporzionale a 1/Ti (processiamo subito i più “sbrigativi”). Anche questa
volta possiamo non rispettare le deadlines (non è detto che i più sbrigativi siano quelli a deadline più
vicina). Condizione necessaria e sufficiente per la schedulabilità RMPO: U ≤ n  2 n − 1  . Condizione
1

 
U ≤ 1 è necessaria ma non sufficiente. Computazionalmente, va meglio dell’EDF (v. oltre), ma per
efficacia è inferiore.
• EDF (Earlies Dead-Line First)
on-line, priorità dinamica, preemptive. Ad ogni task viene assegnata
priorità inversamente proporzionale al tempo rimanente prima della deadline. Condizione U ≤ 1 è
necessaria e sufficiente. Trattasi dell’algoritmo ottimo per efficacia (vince su tutti gli altri); di contro,
non è facilissimo da implementare.

Task armonici
ordinabili tali che Ti = kiT( i −1) , ki ∈ ℕ (sono multipli!).

RMPO equivale a EDF con task armonici (abbiniamo efficacia ed efficienza).

Scelta offline, non-preemptive
Timeline scheduling: si divide il tempo in time-slice (uguali) assegnate in
modo fisso ai task. PRO: determinismo assoluto, elevata efficienza (tipico per off-line e non-preemption),
maggiore affidabilità e predicibilità. CONTRO: flessibilità nulla, efficacia bassa.

RELAZIONI TRA I SISTEMI DI CONTROLLO E I SISTEMI REAL TIME

Due tipologie di attività svolte dai sistemi di controllo nel livello dei controlli della PA:
• Controllo diretto di variabili temporali (time-driven): controllo digitale in retroazione di sistemi
dinamici tempo continui (es. regolazione di temperatura in un forno). Attività trasformazionale
scatenata da evento ciclico (campionamento delle variabili dell’impianto). Spesso i relativi controlli
sono di tipo hard real time.
• Controllo di sequenze: supervisione e gestione delle diverse fasi di funzionamento dell’impianto da
controllare. Tipicamente realizzata tramite una macchina a stati, anche molto complessa. Attività
reattiva interagente con eventi periodici e non. Spesso i relativi controlli sono soft real time.
I sistemi complessi dispongono di entrambe queste tipologie.
Interazione tra attività RT e attività di controllo: tipicamente minimale in quanto i domini di controllo
sono disgiunti. Non vi sono risorse condivise perché sensori, attuatori e periferiche di comunicazione sono
assegnati in modo esclusivo, a priori e in modo immutabile.

SISTEMI OPERATIVI PER L’ELABORAZIONE RT

Un SO real time deve essere in grado di gestire l’I/O delle periferiche e i diversi tasks, di rilevare gli eventi,
di effettuare lo scheduling, di verificare il rispetto delle deadlines. Il campionamento degli eventi e la gestione
del tempo viene quindi effettuata dal SO: i task lavorano senza coscienza del tempo e possono essere
interrotti dal SO (in alternativa si sospendono autonomamente).

Modello di esecuzione (rappresentazione dell’effettivo svolgimento nel tempo dell’esecuzione delle attività
real-time): insieme di eventi/attività RT + unità di elaborazione/SO real-time. Il modello d’esecuzione deve
soddisfare le richieste RT di tutte le applicazioni.
Due approcci:
• event driven: ad ogni evento il SO
o prende il controllo della CPU
o analizza l’evento e decide quale task attivare
o esegue l’algoritmo di scheduling
o manda in esecuzione il task scelto
Essenzialmente, il cardine sta nella gestione a interrupt. Eventi possono essere complessi e ci deve
essere verifica delle deadlines. PRO: approccio intuitivo, massime potenzialità, semplificato per
controllo, buona flessibilità e garanzia, possibile verificare la schedulabilità a priori (EDF). CONTRO:
complesso, in quanto intrinsecamente legato alla schedulazione on-line, alto overhead di SO.
• time driven: non si reagisce al singolo evento, bensì il SO è chiamato a intervalli regolari (ogni Ts =
tempo di scansione) di tempo per campionare la condizione di tutte le grandezze d’interesse.
Particolarmente adatto alla schedulazione off-line, ma può essere utilizzato anche nel caso online
a patto che non vi sia perdita di eventi e che il loro ordinamento non sia significativo.
Essenzialmente consiste nella gestione a polling degli eventi, soluzione che sposta il
riconoscimento degli stessi da HW a SW del SO (l’applicazione reattiva è resa ciclica pseudo-
trasformazionale sincronizzata alla scansione del SO). Gestibile ma comunque complesso

richiede grande tempo di elaborazione. Esistono però accorgimenti per ridurre al minimo la
complessità e il tempo per riconoscere gli eventi
semplificazione per ottenere il massimo
grado possibile di efficacia dagli algoritmi di scheduling. Auspicabile la sincronizzazione tra
campionamento del SO e l’evento periodico, in modo che si possano innescare i task senza
bisogno di verificare l’evento (meno overhead e deadline automaticamente uguale a prossimo ciclo

scelta non obbligatoria ma che semplifica molto). Ad ogni scansione il SO passa il
campionamento delle grandezze al task che
o discrimina l’evento
o aggiorna IN e OUT
o attende il nuovo evento
PRO: semplicità. DIFETTI: task attivato anche in assenza di evento.
Soffermandoci sul time-driven, si ha:
• time driven monotask: time driven e monotask si sposano bene, c’è un’unica deadline molto semplice
(cioè il campionamento successivo: ciclo completo è leggi input
esegui task entro la fine di Ts
[Sample Time = tempo di campionamento]
attua outputs
etc…). Tempo di risposta max: 2Ts.
Scelta del tempo di campionamento: nel caso di applicazione trasformazionale ciclica
Ts coincide
con il periodo di ripetizione dell’evento di innesco. Caso di applicazione reattiva mappata su pseudo-
trasformazionale ciclica
2Ts (tempo di reazione max) dev’essere inferiore al time scope nonché
alla distanza minima fra due eventi; inoltre dev’essere uguale o maggiore al tempo massimo di
calcolo necessario.
• time driven multitask: servono accorgimenti per minimizzare l’overhead e aumentare l’efficacia.
o a tempo di scansione unico
analogo al caso monotask ma all’interno di un ciclo possono
essere eseguiti più task, l’importante è che si faccia in tempo. Questa scelta è semplice in
quanto si tratta di fare scheduling statico seriale, ma si gestiscono male task che non
richiedono tempi di intervento brevi e hanno carichi elevati.
o a più tempi di scansione (multipli o non multipli fra loro), per evitare sovra campionamento.
Più deadline da rispettare, schedulazione più complessa ma semplificabile se i tempi sono
armonici.
PRO del Time Driven CONTRO del Time Driven
Gestione a polling
HW semplice Mancanza di flessibilità, gestione di eventi sporadici non
Semplificato riconoscimento degli eventi sfruttando ottimizzata, uniformità di campionamento (fs adattata
sincronizzazione con eventi periodici all’evento più frequente)
sovradimensionamento dell’HW
Possibilità di usare schedulazione semplice a priorità statica, rispetto a quanto necessario
con singolo tempo di scansione o multipli (armonici)
Semplicità del sistema operativo - Predicibilità
 SISTEMI DIGITALI REAL TIME PER IL CONTROLLO
Controllori embedded: dedicati ad una particolare applicazione, sono parte integrante del sistema. HW e SO
generalmente custom fortemente orientato all’applicazione specifica. Tipicamente sono dentro ai prodotti
finali. Sono realizzati da costruttori/realizzatori di sistemi di controllo
HW, SO, SW tutti fatti dalla stess
azienda.
Controllori industriali: realizzati per coprire una vasta gamma di applicazioni di controllo (HW e SW general
purpose). Servono a controllare i sistemi di produzione. Sono realizzati da costruttori di controllori.
Tipicamente con architettura modulare a bus (all’interno dell’elaboratore); diffusi microprocessori e DSP,
meno i microcontrollori. Buona configurabilità e modularità, elevate prestazioni (possibile architettura
multiprocessore). Il SO e l’interfaccia di programmazione sono definiti dal costruttore del controllore e il
SO è tipicamente time driven. Le applicazioni sono definite dal progettista del sistema. Due grandi famiglie
di controllori industriali:
• PLC
soft real time, soprattutto per controllo di sequenze e industria manifatturiera (produzione
di pezzi meccanici, componenti, elettrodomestici, farmaci, etc…).
• DCS
per controllo digitale standard (PID), hard real time, utilizzo in industria di processo
(distribuzione gas, produzione carta, industria petrolifera, energetica…).

Alcune architetture tecnologiche basate su controllori industriali:

• Industria di processo: unità di riferimento = impianto. Prevale il controllo diretto di variabili
temporali (PID) e il controllo digitale con ancora qualche soluzione analogica o meccanica.
Controllo di sequenze modesto, con poche sequenze, rare azioni dirette sul campo (sensori e
attuatori), spesso gestito manualmente. Monitoraggio dell’operatore molto approfondito.
• Industria manifatturiera: unità di riferimento = macchina. Insieme di meccanismi che devono
produrre un moto coordinato; controllo di sequenze quasi del tutto automatizzato e di grande
importanza. Rilevanti le azioni dirette sul campo. Controllo diretto di variabili temporali quasi
esclusivamente confinato all’interno degli azionamenti elettrici. Monitoraggio/intervento
dell’operatore saltuario.

CONTROLLORI INDUSTRIALI: PLC

Programmable Logic Controller: controllore industriale general purpose per eccellenza. Architettura HW-SO
general-purpose legata principalmente al controllo di sequenze. Trattasi di un componente fondamentale di
ogni sistema di automazione con sequenze complesse. È un dispositivo o sistema digitale programmabile
di tipo real time con un set di istruzioni atte a implementare specifiche funzioni di logica combinatoria,
sequenziale, nonché temporizzazioni e conteggi.

Evoluzione storica dei dispositivi per il controllo logico:

• Contatti logici: siamo agli albori
funzioni OR, AND, etc… fatti a bassissimo livello di astrazione.
• Relais industriale (una specie di switch)
mattone elementare per la realizzazione di funzioni
logiche con contatti. Fondamentali per motivi elettrici (isolamento galvanico tra in e out) e
funzionali (possibilità di introdurre il not dei comandi, costruzione di funzioni logiche sequenziali,
temporizzazioni, etc…).
• General Motors (1968): passaggio logica cablata
logica programmabile. Nascono i PLC! Facilità di
programmazione e riprogrammazione sul campo, con linguaggio basato su ladder diagrams.
Differenze nell’architettura del processore: introduzione di un S.O. real time, realizzazione delle
parti (CPU, a 1 bit ed efficientissimo, ROM, RAM, batterizzata per lo sviluppo del programma…),
possibilità di acquisire segnali analogici, parallelismo e creazione struttura interna. Possibilità di
effettuare il debugging. Human Machine Interface (visualizzazione stato dell’impianto e ricezione di
comandi da utente umano) non sempre presente. Presenza di moduli speciali per interfacciare il
PLC con la rete locale, con processori ausiliari e unità di backup.
Modello di esecuzione PLC: inizializzazione
abilitazione uscite
lettura input
tasks
attuazione
output
lettura input … (loop).

Sistema operativo PLC: deve poter garantire l’inizializzazione e la scansione ciclica (time driven), deve avere
la gestione automatica dell’I/O nonché quella dei timer e del counter.

Linguaggio di programmazione: inizialmente era ladder (schemi a Relais) o funzionale (schemi logici); più
recentemente è diventato un linguaggio vero e proprio.

CONTROLLO LOGICO
La progettazione di un controllo logico è un compito complesso ma cruciale per la buona riuscita del
progetto.
FASI:
• lavoro di gruppo per definire il progetto
• realizzazione: hardware (acquisto + progettazione) e software (progettazione che tiene conto delle
scelte HW)
• collaudo: fase costosa e delicata, conviene investire di più sulla progettazione per poi risparmiare in
collaudo
• creazione della documentazione
STRUMENTI DI MODELLAZIONE:
• descrizione letterale (a parole): lunga, imprecisa, poco funzionale
• descrizione logica: troppo particolareggiata
• diagrammi temporali: pesante, carente
• diagramma degli stati: interessante soluzione del tipo “reti logiche”, rappresentazione concentrata
ed efficace.

Nasce quindi lo standard IEC 61131-3
scopo: definire linguaggi standard per la programmazione di PLC.
Caratteristiche in comune fra i vari linguaggi proposti:
• functions: procedure prive di memoria che con certi IN producono certi OUT;
• function blocks: come sopra, ma con memoria;
• programs: insieme di unità e/o istruzioni che costituiscono l’implementazione del controllo di
sequenze di una macchina/impianto.
Sono stati proposti cinque linguaggi:
• due linguaggi testuali
• ST (Structured Text): linguaggio testuale pseduo-Pascal;
• IL (Instruction List): testuale, pseudo-Assembly;
• tre linguaggi grafici
• LD (Ladder Diagram): riprende gli schemi a relais, flusso di potenza da sx a dx elaborazione da
alto a basso;
• FBD (Function Block Diagram): grafico, riprende le logiche cablate, esecuzione dall’alto al basso;
• SFC (Sequential Function Chart): elevate potenza espressiva, leggibilità e semplicità e scarso
legame con l’implementazione
ottimo per la rappresentazione funzionale del controllo di
sequenze!! È l’evoluzione del diagramma a stati e permette un alto grado di astrazione. Deriva
da Grafcet (francese).

SFC
Concetti base:
• Stato: l’evoluzione temporale del funzionamento di un impianto è un insieme di stati (o fasi, o
passi), i quali rappresentano una condizione operativa della macchina.
• Evento: occorrenza di una particolare condizione.
 • Transizione (da uno stato ad un altro): provocata da un evento.
• Condizioni (di transizione): il verificarsi di una condizione corrisponde all’evento che determina il
passaggio ad un altro stato.
Sintassi e regole:
• Stati: ad ogni stato vanno associate le azioni da eseguire quando quello stato è attivo. Due stati
vanno sempre separati da una transizione.
• Transizioni: due transizioni successive non
separate da uno stato sono proibite.
• Stato attivo/inattivo: se lo stato è attivo le sue
azioni vengono eseguite. Possono esistere
più stati attivi contemporaneamente.
• Inizializzazione: occorre definire alcuni stati
di inizializzazione (attivi all’avviamento). Gli stati iniziali possono essere più d’uno).
• Abilitazione delle transizioni: una transizione si dice abilitata quando tutti gli stati precedenti alla
transizione sono attivi. Una transizione diventa attiva quando è abilitata e, contemporaneamente, la
condizione necessaria è vera.
• Cambio di stato: la transizione attiva determina il cambio di stato. Se più transizioni sono attive
contemporaneamente allora vengono simultaneamente superate.
Variabili:
• Step flag: statename.x
è 1 quando lo stato è attivo;
• Step time: statename.t
tempo trascorso dall’attivazione dello stato.
Azioni associate allo stato: possono essere
• non memorizzata (not stored): eseguita finché lo stato è attivo;
• pulsata (pulsed): eseguita solo una volta quando lo stato è attivato;
• set: eseguita finché non sopraggiunge il reset;
• reset: termina il set;
• time limited: termina l’esecuzione dopo un certo tempo;
• time delayed: inizia l’esecuzione dopo un certo tempo;
• combinazioni varie: stored/delayed, delayed/stored, stored/time-limited…

STRUTTURE DI COLLEGAMENTO

• Scelta alternativa: più transizioni collegate ad uno stesso passo. Il flusso segue un solo percorso (le
condizioni devono essere strutturate affinché siano mutualmente esclusive
evitiamo ambiguità).
• Convergenza (singola): serve per chiudere la diramazione di più percorsi generati da una scelta
alternativa.
 • Parallelismo (divergenza doppia): da una singola transizione a più passi percorsi
contemporaneamente.
• Sincronizzazione (convergenza doppia): da più passi ad una sola transizione. Si va oltre solo
quando convergono tutti i passi

Strutture di collegamento speciali: per rendere

mutuamente esclusive due sequenze. Uso dei
semafori e di sincronizzazioni: si può passare
oltre solo quando il semaforo concede il
passaggio (flusso “attivo” attraverso la freccetta).
Non ci si deve però dimenticare di utilizzare
(oltre al meccanismo del semaforo) condizioni
mutuamente esclusive alle due sequenze.

La mutua esclusione va fatta nel controllo, così

risparmiamo in risorse di elaborazione,
attuazione e misura. Nei SO ci sono
infrastrutture per il controllo di sequenze? Normalmente no perché i task interagenti non sono graditi per
schedulazione. Però posso dividere i task in sezioni (macrostati, rappresentazione sintetica di pezzi di SFC)
controllate dai semafori.
 RETI INFORMATICHE NELL’AUTOMAZIONE

Definizione di rete informatica: infrastruttura costituita da elementi HW e SW per la comunicazione di dati

digitali tra diversi sistemi di elaborazione. Una rete informatica è completamente definita quando sono
definiti tutti i livelli HW e SW.
Due topologie principali:
1. Broadcast – unico canale fisico di comunicazione condiviso da tutti i nodi della rete (un messaggio è
visto da tutti)
necessità di arbitraggio/controllo collisioni.
a. Rete a bus
fascio di connettori condiviso.
b. Rete ad anello
i singoli bit inviati circolano sull’anello.
2. Punto-punto – connessioni dedicate tra coppie di nodi è necessario definire il cammino per
trasmettere fra due nodi non fisicamente connessi.
a. Rete a stella
elemento centrale connesso con tutti gli altri.
b. Rete punto-multipunto.
c. Rete a maglia
vari canali punto-punto: tra ogni coppia di nodi deve esistere almeno un
percorso in entrambe le direzioni.

Pila ISO-OSI: organizzata a stack (vantaggi: astrazione e modularità, rimpiazzabilità dei vari livelli,
interoperabilità fra i livelli), è un modello di riferimento per l’organizzazione HW/SW delle reti
informatiche. Ad ogni livello (layer) corrisponde una o più funzionalità: il layer n di un nodo si occupa di
interfacciarsi con quello n-1 e di comunicare con il layer n di un altro nodo mediante un protocollo. Le
prestazioni dei livelli inferiori condizionano quelle dei livelli superiori: se un livello deve fare una certa
cosa, devono esistere limiti inferiori alla velocità con cui tale cosa dev’essere fatta.
Ethernet
livello 1 + livello 2: molto usata!
LIVELLO 1: fisico
trasmette fisicamente il segnale. Vengono definite la topologia (a maglia, a bus, etc…)
e le caratteristiche del supporto fisico (propagazione guidata, libera, etc…), nonché i dettagli realizzativi
(materiali, tempi di propagazione, banda, numero di canali fisici o virtuali, numero di nodi agganciabili a
ciascun canale, etc…). Si sceglie inoltre la metodologia di rappresentazione dei bit (numero di livelli, forma
dei segnali, comunicazione S/P…).
LIVELLO 2: data link
divisione del dato in frames (pacchetti conformi alle necessità HW della rete di
comunicazione), invio degli stessi e (in ricezione) spedizione degli ACK. Si inseriscono header (per
identificare mittente e destinatario) e terminator per ogni pacchetto; dopodiché si procede alla spedizione
dei singoli frames. Altre funzionalità tipiche: verifica dell’errore (CRC), notifica di ricezione (ACK),
ritrasmissione, meccanismi di controllo del flusso, accesso al canale fisico/virtuale per la trasmissione
(MAC: Medium Access Controller). Scelte per l’allocazione del canale:
• Statica: il tempo è diviso in quanti (TDMA: Time Division Multiple Access) ed ogni nodo può eseguire
l’accesso solo in corrispondenza del quanto associato al nodo stesso. Si previene conflitto, i tempi di
trasmissione massimi sono facili da calcolare, ma tempo di trasmissione massimo e medio
coincidono.
• Dinamica…
o A controllo centralizzato: un’entità suprema (master) controlla tutto. Si previene il conflitto,
tempi di trasmissione massimi e medi si calcolano facilmente e dipendono dalla politica del
master.
o A controllo decentralizzato: ogni nodo decide autonomamente se iniziare a trasmettere.
Possibile collisione e tempi di trasmissione difficilmente calcolabili.
 Gestione controllata: sistemi a token ring/bus. Ogni nodo trasmette quando è in
possesso del token (abilitazione) e poi lo dà in giro quando ha finito di trasmettere.
 A collisione: CSMA-CD (Carrier Sense Multiple Access: Collision Detection)
ogni
nodo è in ascolto sul canale e, quando lo percepisce libero, può trasmettere.
Possibilità di collisione: tutti si bloccano. CSMA-CR (Carrier Sense Multiple Access:
Collision Resolution)
alla collisione c’è un nodo che vince e prosegue.
LIVELLO 3: rete
decisione del percorso (routing) da nodo a nodo.
LIVELLO 4: trasporto
divisione/ricostruzione del dato in/da pacchetti (conformi alle necessità SW della
rete informatica).
LIVELLO 5: sessione
gestione delle connessioni fra nodi (poco utilizzato).
LIVELLO 6: presentazione
codifica del dato e verifica della correttezza (poco utilizzato
controllo degli
errori ai livelli più bassi).
LIVELLO 7: protocolli dell’applicazione finale (HTTP, POP, FTP, …).

Per l’automazione spesso usati i fieldbus (PRO: semplicità del cablaggio, flessibilità): trasportano dati di
piccole dimensioni (misure, comandi, allarmi, piccoli messaggi). Standard di livello fisico: RS485.
Due tipi di messaggi:
• State messages: fotografano completamente la condizione di interesse di un certo istante. Sono di
solito periodici (periodo noto e deciso in funzione di accuratezza temporale necessaria); non si
richiede ACK. Il traffico è periodico anch’esso; è d’uopo sincronizzare la trasmissione periodica con
l’esecuzione ciclica dei task (si minimizza la latenza). Preferiti nei controlli per la loro semplice
gestione; tipica frequenza dei dati: 1-10 kHz.
• Event messages: fotografano la variazione dello stato. Di solito sono sporadici
traffico non noto a
priori. In situazioni con vincoli RT è importante l’istante temporale in cui avviene la variazione
della condizione.
La divisione in pacchetti è praticamente assente. I messaggi vengono schedulati in base alla loro priorità e
all’ordine di invio.
Dai fieldbus si richiedono:
• Robustezza meccanica.
• Robustezza EM (spesso lavorano in ambiente ostile)
Spesso si sceglie un supporto fisico solido e
guidato (e magari schermato). Codifiche più diffuse: a pochi livelli (2 o 3). Utilizzazione della
codifica di Manchester: il dato e il clock sono combinati per generare un’unica stringa di dati auto-
sincronizzati
dividiamo ogni periodo di bit in due parti uguali (clock)
1 logico = alto nel primo
sottointervallo; 0 logico = l’opposto. PRO: maggiore robustezza e facilità di sincronizzazione.
CONTRO: serve una banda doppia (periodo dimezzato). Manchester differenziale: 1 logico =
transizione nel primo sottointervallo; 0 logico
assenza di transizione nel primo sottointervallo.
PRO: sincronizzazione sempre garantita (cosa non ovvia col Manchester “liscio”).
• Soddisfacimenti di vincoli RT.
o Ritardo di trasmissione contenuto (elevata efficienza della rete), poco overhead.
o Determinismo: dati consegnati entro una deadline fissa. Tipicamente ci si basa sulla filosofia
del caso peggiore. Si considera la frequenza delle collisioni e si gestiscono gli errori di
trasmissione. Differenza tra caso medio e caso peggiore = jitter. Dev’essere il più basso
possibile: meglio reti non velocissime con poco jitter che reti velocissime e jitterose.
o Possibilità di sincronizzare i nodi (soprattutto nei sistemi di controllo distribuiti)

sincronizzazione dell’innesco dei tasks. (PRO: dà maggiori possibilità. CONTRO:
complesso).

Approfondimento sul MAC. Quando una stazione deve inviare i dati, ascolta il canale: se è libero
trasmette immediatamente, altrimenti ritenta in seguito (tempi d’attesa fissi o casuali). Due stazioni
comunicano contemporaneamente
collisione!
tutti smettono di trasmettere. Esistono fortunatamente
protocolli a rilevamento della collisione (Collision Detection) e a risoluzione della collusione (Collision
Resolution). In base a questi ultimi la stazione che vince l’arbitraggio prosegue nella trasmissione fino al
completamento. Per il rilevamento della collisione il frame deve avere una durata minima Tf maggiore del
caso peggiore del ritardo di rilevamento della collisione (caso peggiore: A e B sono ai due capi estremi della
linea, A parla e B inizia a trasmettere nell’esatto momento in cui sta arrivando il dato di A
τ perché B
rilevi la connessione e altri τ perché la rilevi A). Se τ = tempo di propagazione del segnale, Tr = tempo di
reazione dei driver di linea si ha Tf ≥ 2 τ + Tr. Se Tf = Nbit * Tbit si ha τ < 0,5 (Nbit * Tbit – Tr).
A volte si ha anche la CSMA-BA (Bitwise Arbitration)
vince l’arbitraggio chi sta spedendo un bit
“dominante” (si può scegliere 1 “dominante” e 0 “recessivo” o anche viceversa, basta saperlo a priori): in
tal caso, però, l’arbitraggio deve avvenire durante la trasmissione del bit (Tr dev’essere abbastanza basso).

CSMA-CD CSMA-CR TOKEN POLLING (M/S) TDMA

DETERMINISMO Non deterministico Potenzialmente det. Deterministico Deterministico Deterministico

JITTER Elevato Elevato Basso Basso (per messaggi Ridotto

non troppo lunghi)
SINCRONIZZAZ. Non supportata Non supportata Possibile Parziale Possibile

CONDIZIONI Traffico basso (ciclico Traffico noto a priori Preferibilmente Poche stazioni e Traffico ciclico noto
o aciclico) (per poter calcolare il traffico noto traffico periodico (allineamento con le
DI BUON
latency delay) slot temporali del
FUNZIONAM. BUS)
ALTRO Elevata adattabilità, Efficienza piuttosto Scarsa efficienza,
pericolo di perdita bassa a causa dei possibili soluzioni
del token, non messaggi di ATDMA per
efficiente a basso autorizzazione migliorare
traffico e con molti master/slave
nodi
Approfondimento topologie (livello MAC).
• Token ring
rete ad anello con connessioni punto-punto fra le varie interfacce. L’accesso al mezzo
avviene mediante token (sequenza speciale di bit che circola sulla rete). Quando una stazione vuole
spedire un frame, rimuove il token dall’anello e inizia a trasmettere il frame. Tutte le stazioni
ascoltano quindi il frame (la rete è di fatto broadcast). Quando il frame è trasmesso si rilascia il token.
Caratteristiche: controllo di accesso dinamico, decentralizzato e senza collisione (per trasmettere ci
vuole il token).
• Token bus
come il token ring, ma si sta su un bus (mezzo trasmissivo comune a tutti i nodi). Le
stazioni sono organizzate in anello solo “logicamente” (ogni stazione ha un predecessore e un
successore). Vantaggio: la rottura di un elemento non interrompe la comunicazione fra tutti gli altri.
• Master/slave (polling): un nodo speciale (master) manda un messaggio esplicito al nodo che può
trasmettere. Trattasi di una soluzione dinamica, centralizzata e senza collisioni. Contro: se si rompe
il master siamo fregati.
• TDMA: divisione del tempo in slot. Un particolare terminale può comunicare solo “durante il suo
slot”.
o Sincrono: accesso è assegnato periodicamente a tutti i nodi in modo ciclico.
o Asincrono: accesso assegnato in base alla necessità.
Si richiede sincronizzazione dei clock dei nodi.

Application layer per i fieldbus: definisce cosa si scambiano i task di controllo e le specifiche che devono
garantire i livelli sottostanti. Tipi di messaggi: misure, comandi, allarmi, info non complesse.
Eventuali features:
• possibilità di settare la priorità dei messaggi;
• possibilità di marcare i messaggi (temporalmente o con numero di sequenza);
• bufferizzazione di ingresso e uscita con schedulazione.
Modelli di comunicazione utilizzati:
• Client-server: richieste specifiche da un client (es. PLC) a un server (es. sensore/attuatore).
• Producer-consumer (preferibile): messaggio a tutti e poi lo usa chi è veramente interessato.
Scelta interessante: ethernet per fieldbus. Rete broadcast, con diversi tipi di supporto e diverse velocità,
CSMA-CD. PRO: ethernet è veloce e costa poco, con switch poche collisione. CONTRO: overhead rilevante,
difficile avere determinismo. Conclusioni: ethernet è utile per controllo e supervisione (con poche richieste
realtime). Altra opzione: ethernet modificato per applicazioni industriali. Altra ancora (estrema!): fieldbus
wireless.
 SISTEMI DI CONTROLLO DISTRIBUITO
Passaggio da sistemi centralizzati a distribuiti: PRO = distribuzione sui nodi di rete di “intelligenza di
calcolo”, elaborazione parallela, maggiore incapsulamento fra implementazione ed elaborazione. Una
soluzione distribuita consente di individuare più facilmente un malfunzionamento, nonché di isolarlo
senza creare danni al resto. CONTRO = maggiore complessità, problema della sincronizzazione.
Necessario scomporre il sistema in parti per individuare le problematiche e le soluzioni principali.
Cosa deve fare, in più, il livello dei controlli per poter supportare un modello distribuito?
• Data collection: misura di tutte le variabili di interesse, costruzione in memoria di un’immagine RT
delle grandezze.
• Signal conditioning: elaborazioni sul dato grezzo per trasformarlo in una grandezza utilizzabile.
• Alarm monitoring: rilevamento situazioni anormali.
• Funzioni di controllo: controllo in retroazione dell’impianto, dei vincoli RT.
• Man-Machine interaction: comunicazione tra l’operatore e la macchina.
Requisiti:
• Dependability: qualità del servizio, prestazioni
o Reliability: affidabilità (funzione probabilistica che esprime la probabilità che un sistema
garantisca il corretto funzionamento fino all’istante di tempo t).
o Safety: affidabilità relativa agli eventi di guasto critici, quelli che producono danni seri.
o Certification: processo di certificazione per qualificare l’impianto o la macchina.
o Maintainability: tempo necessario per riparare un sistema dopo un guasto.
o Availability: frazione di tempo in cui un sistema soggetto a riparazioni/rotture funziona
nell’unità di tempo.
o Security: capacità di impedire accessi non autorizzati alle informazioni contenute nel sistema
o ai servizi forniti.
Architettura:

NODO: computer autonomo che svolge una funzione del sistema distribuito. Ogni nodo contiene al suo
interno un calcolatore e funzioni di gestione per la comunicazione con altri nodi, nonché interfacce per la
trasmissione/ricezione su rete di comunicazione (mezzo trasmissivo + comunication controller).
Comunication-network interface (CNI): rappresenta il livello di scambio dei messaggi e deve
inviare/ricevere informazioni dai nodi (con limiti di tempo e di latenza). Deve gestire messaggi che
contengono informazioni relativi a eventi e messaggi che contengono informazioni di stato.

Gestione degli eventi:

• Event triggered: tutte le attività sono avviate dal manifestarsi di un evento.
• Time triggered: attività attivate a intervalli regolari.

Rete di comunicazione: è una risorsa critica, perché la perdita di comunicazione comporta la conseguente
perdita di tutti i servizi. Il gateway ha un importanza cruciale perché adatta diverse strutture di rete fra loro.
Componibilità: importantissima da garantire
l’integrazione di un nuovo componente non altera le
proprietà precedentemente testate sul componente. La rete di comunicazione gioca un importante ruolo nel
garantire la componibilità di un’architettura distribuita. La componibilità richiede che
• Ogni nodo e la CNI devono avere una dinamica completamente specificata nel tempo.
• L‘integrazione non deve modificare le proprietà temporali.
• Le proprietà temporali devono poter essere testate in maniera indipendente.

Strategie di gestione per la comunicazione in rete:

• Controllo esterno: la decisione dell’istante di trasmissione di un messaggio viene presa dall’host.
Gestione di tipo event triggered. Gli hosts influenzano pesantemente la rete: il controllo temporale,
essendo esterno, risente del fatto che è l’host a decidere quando inviare un messaggio. Non
garantisce componibilità.
• Controllo interno: è time triggered e l’host questa volta non decide un tubo, perché i messaggi sono
trasportati da/verso i nodi. Garantisce componibilità.
• Controllo autonomo: la decisione dell’istante di trasmissione viene presa autonomamente.
Usualmente è time triggered. Il sottosistema ha un meccanismo di schedulazione all’invio dei
messaggi.
Messaggi:
• Event message: messaggio con informazioni relative a eventi. Sono accodati presso il ricevitore e
vengono cancellati alla lettura. Tipico dei sistemi non RT.
• State message: messaggio con informazioni di stato, gestito con la strategia del controllo autonomo.
Tipico dei sistemi RT distribuiti.

Scalabilità: i sistemi di controllo devono evolvere nel tempo (aggiunta di nuove funzionalità,
aggiornamento di quelle già esistenti). L’architettura time-triggered è scalabile perché il controllo dello
scambio dati è autonomo e non centralizzato.
Estendibilità: un’architettura scalabile non deve avere nessun collo di bottiglia né nella capacità di
elaborazione né in quella di comunicazione. Un’architettura distribuita è intrinsecamente
estendibile! Estendere significa anche incrementare la capacità di un sistema.
Complessità: si riferisce al numero di parti e al tipo/numero di interazioni che devono essere considerate
per comprendere la funzione del sistema. Si può ridurre grazie all’incapsulamento.

Gestione del tempo: importantissima per la sincronizzazione e per l’approccio time triggered. Approccio
preferibile: orologi locali ai vari elementi eventualmente sincronizzati per schedulare il time triggering di
ogni parte. Gestione del tempo condivisa serve a sincronizzare la gestione di elementi in modo componibile
e a ricostruire sequenze di eventi in modo distribuito.
Ordinamento degli eventi:
• Temporale
sequenza di eventi ordinata temporalmente (problema: come modellare quelli
simultanei?)
• Causale
dipendenza causale può essere di grande interesse quando si hanno catene di eventi che
dipendono l’uno dall’altro.
Standard per la misura del tempo:
• TAI
Tempo Atomico Internazionale
si basa sulla radiazione del Cesio 133 (scala “continua”).
• UTC
Universal Time Coordinated
derivato da osservazioni astronomiche (scala “discontinua”)
Misura del tempo:
• Orologio (clock)
ogni nodo ha un suo clock, frequenza f z
l’orologio funziona a un
sottomultiplo di questa frequenza
Granularità dell’orologio
quanti microtick (durata 1/ f z ) ci
sono fra due di questi sottomultipli. Drift dell’orologio: scostamento della sua frequenza rispetto a
quella del clock = microtick. La frequenza dell’orologio dipende da temperatura, qualità del quarzo,
tensione, etc…
 • Timestamp
clock indica il rilevamento e la marcatura dell’evento event da parte dell’orologio clock
(dicitura: clock(event) ).
• Offset fra due orologi
errore di misura fra i due orologi in termini di microtick
In un sistema di elaborazione:
• Precisione di un insieme di orologi
massimo offset fra ogni coppia di orologi.
• Accuratezza di un orologio rispetto al riferimento
massimo offset fra l’orologio e il riferimento.
Si necessita di periodica ri-sincronizzazione! In un sistema distribuito ogni nodo ha il suo orologio quindi
bisogna fare il meglio che possiamo: dobbiamo introdurre una base dei tempi locale comune a tutti i nodi
(tempo globale) utilizzando n microtick di un orologio (= macrogranulo . Il tempo globale è ragionevole se
l’errore di sincronizzazione è al più 1 macrogranulo (se sono più di due l’errore di sincronizzazione può
diventare pericoloso per la corretta successione degli eventi
non possiamo ricostruire l’ordine temporale
e due eventi possono anche essere rilevati in ordine opposto!). Il tick globale deve essere continuamente
risincronizzato per ottenere una ragionevole calibratura.

Limiti nella misura del tempo: se un singolo evento è osservato da due nodi può essere che le due
marcature siano diverse di un tick
non è possibile ricostruire l’ordine.
Le marcature devono fra loro distare almeno 2 ticks!

Altra scelta: sincronizzazione tramite un master centrale, che invia periodicamente il valore del suo
contatore a tutti
possibili problemi: la precisione di sincronizzazione dipende dalla rete che porta in giro
il segnale del master (jitter = pericolo!). Serve un master di backup in caso di guasti. La sincronizzazione degli
orologi può avvenire variando (provvisoriamente) la frequenza o modificando il numero di microtick
quanto basta per riportare il tutto al passo. Occorre un “server del tempo”.