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.

Parametro importante = fattore di utilizzazione ���� 1

fattore di utilizzazione tempo di elaborazione

= tempo d'utilizzazione

ni

ii i

i

UC

U CT

T=

== → =

∑

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: 1

2 1nU n ≤ −

. Condizione

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 ( )1 ,

i i iiT k T k−= ∈ℕ (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 Semplificato riconoscimento degli eventi sfruttando

sincronizzazione con eventi periodici Possibilità di usare schedulazione semplice a priorità statica,

con singolo tempo di scansione o multipli (armonici) Semplicità del sistema operativo - Predicibilità

Mancanza di flessibilità, gestione di eventi sporadici non ottimizzata, uniformità di campionamento (fs adattata

all’evento più frequente) � sovradimensionamento dell’HW rispetto a quanto necessario

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).

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.

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

DETERMINISMO Non deterministico Potenzialmente det. Deterministico Deterministico Deterministico

JITTER Elevato Elevato Basso Basso (per messaggi non troppo lunghi)

Ridotto

SINCRONIZZAZ. Non supportata Non supportata Possibile Parziale Possibile

CONDIZIONI

DI BUON

FUNZIONAM.

Traffico basso (ciclico o aciclico)

Traffico noto a priori (per poter calcolare il

latency delay)

Preferibilmente traffico noto

Poche stazioni e traffico periodico

Traffico ciclico noto (allineamento con le

slot temporali del BUS)

ALTRO Elevata adattabilità, pericolo di perdita

del token, non efficiente a basso

traffico e con molti nodi

Efficienza piuttosto bassa a causa dei

messaggi di autorizzazione

master/slave

Scarsa efficienza, possibili soluzioni

ATDMA per migliorare

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 zf � l’orologio funziona a un

sottomultiplo di questa frequenza � Granularità dell’orologio � quanti microtick (durata 1/ zf ) 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”.