Sistemi E Tecnologie Per L'automazione - Ver. 0.9

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ù 1 vicina). Condizione necessaria e sufficiente per la schedulabilità RMPO: U ≤ n  2 n − 1  . 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 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 pseudotrasformazionale 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 pseudotrasformazionale 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 autosincronizzati
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).

DETERMINISMO JITTER SINCRONIZZAZ. CONDIZIONI DI BUON FUNZIONAM. ALTRO

CSMA-CD

CSMA-CR

TOKEN

POLLING (M/S)

TDMA

Non deterministico

Potenzialmente det.

Deterministico

Deterministico

Deterministico

Elevato

Elevato

Basso

Ridotto

Non supportata

Non supportata

Possibile

Basso (per messaggi non troppo lunghi) Parziale

Traffico basso (ciclico o aciclico)

Traffico noto a priori (per poter calcolare il latency delay)

Preferibilmente traffico noto

Poche stazioni e traffico periodico

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

Possibile Traffico ciclico noto (allineamento con le slot temporali del BUS) Scarsa efficienza, possibili soluzioni ATDMA per migliorare

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