Lezioni, Automazione dei processi industriali M

P

K amplificazione dell’errore ad errori piccoli corrispondono compensazioni grandi;

é, à

P il controllore è quindi molto più sensibile agli errori;

anche il minimo errore viene compensato

immediatamente;

K errori a regime bassi;

é,

P

K sovraelongazione e instabilità

é, é;

P

K azione di controllo più frequente, sistema più veloce.

ê,

P “gas del sistema”.

è anche detto

K P 1

È possibile dimostrare che e = K

∞ P

Per ottenere e = 0 è necessario avere K = è impossibile avere un guadagno infinito.

∞:

P

∞

Automazione dei processi industriali M – modulo 3 Sistemi di controllo del moto – Simone Benassi

  28  

La forza di controllo deve essere diversa da 0 anche se l’errore a regime è 0.

La caratteristica dell’integrale è che esso è diverso da 0 anche se il segnale è nullo.

Per questo motivo si accosta l’integrale al proporzionale, per fare in modo che u(t) 0: si è così in

≠

controllore Integrale.

presenza di un t*

u(t) = K e(τ) dτ l’integrale mi serve per avere errore a regime nullo

I   à

I  

0

Questa espressione modella un guadagno proporzionale infinito K = e quindi e = 0

à ∞

P ∞

S e instabilità é

A questo punto è necessario un elemento che aumenti la stabilità del sistema.

Questo elemento può essere rappresentato dalla derivata che aiuta a capire se il sistema è da

trattenere.

Utilizzando quindi la funzione derivativa aumento la stabilità del sistema, ponendosi di fronte ad un

controllore Derivativo.

de(t)

u(t) = K

D D dt

Riassumendo si ha:

Regolatore di posizione controllore P (l’integratore non serve poiché già presente: 1/S);

à

Regolatore di velocità controllore PI;

à

Regolatore di corrente controllore PI.

à

Siamo di fronte a tre sistemi di primo ordine che da soli non possono diventare instabili: per questo

motivo il controllore derivativo non è necessario.

Automazione dei processi industriali M – modulo 3 Sistemi di controllo del moto – Simone Benassi

  29  

4.SISTEMI DI CONTROLLO IN TEMPO REALE

Un sistema di controllo in tempo reale esegue dei task che devono essere corretti e devono arrivare

entro un certo limite di tempo.

Per questo motivo un task (algoritmo) deve possedere due caratteristiche:

Logicamente corretto;

Temporalmente corretto.

Un SO non riesce ad eseguire i task parallelamente.

Non è detto che un sistema REAL TIME sia anche un sistema veloce, ma è sicuro che il

comportamento dello stesso sistema debba essere assolutamente prevedibile, deterministico.

Il progetto di un sistema REAL TIME deve quindi essere effettuato in maniera adeguata.

I vincoli REAL TIME sono importantissimi a basso livello (livello di campo e macchina), dove i

dati sono semplici e campionati con altissima frequenza.

Definizioni:

Sistema “hard real time” il non rispetto delle deadline temporali non è ammesso.

à

Un esempio è il controllo digitale.

Porterebbe a danneggiamenti del sistema o di altri apparati.

Sistema “soft real time” il non rispetto delle deadline temporali è ammissibile, in una

à

certa percentuale.

Le specifiche temporali indicano solo in modo sommario i

tempi da rispettare.

Quindi il degrado della performance e del livello di servizio è

ammissibile: il grado del livello di servizio cala al crescere

delle deadline temporali non rispettate.

Risulta necessario dare priorità ai task più critici, in particolare

a quelli inerenti la sicurezza.

Sistema real time “largo” la deadline è larga rispetto ai tempi di calcolo necessari per

à

eseguire le operazioni richieste.

L’intervallo di tempo in cui viene elaborato il task è piccolo

rispetto all’intervallo di tempo nel quale può essere eseguito.

Sistema real time “stretto” la deadline è stretta rispetto ai tempi di calcolo necessari per

à

eseguire le operazioni richieste.

L’intervallo di tempo in cui viene elaborato il task è grande

rispetto all’intervallo di tempo nel quale può essere

eseguito.

Le deadline sono larghe o strette in relazione all’hardware sul quale vengono eseguiti i task.

È quindi sempre presente un trade-off fra costi e prestazione.

Automazione dei processi industriali M – modulo 4 Sistemi di controllo in tempo reale – Simone Benassi

  30  

I sistemi REAL TIME devono eseguire più attività (task), anche completamente indipendenti fra di

loro.

Le attività sono di norma innescate a seguito di eventi e devono terminare entro un certo limite di

tempo.

Time scope finestra temporale del task tra l’evento che lo innesca e la relativa deadline.

à

I time scope di diversi task possono essere fra loro sovrapposti: per questo motivo risulta necessario

sequenzializzare l’esecuzione dei task.

Se potessimo basarci su un’architettura a multiprocessore l’esecuzione parallela dei task sarebbe

possibile se per ogni task fosse presente un processore dedicato questo è impossibile poiché nella

à

realtà il numero di processori è sempre inferiore al numero di task da eseguire.

parallelismo reale parallelismo logico.

Non è quindi realizzabile un ma solo un

#PROCESSORI < #TASK

Risulta quindi necessario definire la sequenza di esecuzione dei vari task.

La sequenzializzazione risulta un processo molto complesso poiché nel caso di sistema “hard real

time” i task devono essere conclusi entro e non oltre le relative deadline nel 100% della casistica.

Scheduling scheduling programmazione

L’operazione di sequenzializzazione prende il nome di o

concorrente. Time scope t

ready esecuzione

Task ready task innescato da un evento ma non ancora in esecuzione.

à È un task pronto ed in attesa di essere eseguito.

Scheduler parte del SO che si preoccupa di definire quali task deve eseguire il processore istante

à per istante.

È un’unità che assegna la risorsa computazionale (dispatching) secondo un preciso

algoritmo di scheduling.

Operazione di dispatching operazione che trasforma un task ready in un task in esecuzione.

à

Il problema sta nel decidere come ordinare la coda dei task ready, composta da più task in attesa di

essere eseguiti, che si riflette nella definizione dell’ordine di esecuzione dei task.

Automazione dei processi industriali M – modulo 4 Sistemi di controllo in tempo reale – Simone Benassi

  31  

politica FIFO

Il primo esempio è ordinare i task ready secondo una (First In First Out).

Questa politica non è “furba”, efficiente, poiché non è detto che vengano rispettate le deadline

temporali di tutti i task.

Inoltre questa politica non prevede l’ipotesi di interrompere l’esecuzione di un task: se non è

prevista questa caratteristica l’algoritmo è da considerarsi inefficiente.

Time scope OK

t

ready esecuzione

Time scope NO

t

ready esecuzione

Operazione di preemtion operazione con la quale si interrompe un task per mettere in

à esecuzione un altro task più critico.

Lo scheduler deve essere in grado di sospendere l’esecuzione di un task all’arrivo di in task più

critico, e di inserire il task interrotto nuovamente nella coda dei task ready (task in attesa).

priorità

L’idea di base è quella di definire una per ogni task e sfruttare la preemtion per eseguire

sempre il task più critico, in termini di deadline.

Occorre quindi definire un algoritmo di scheduling che definisca queste priorità.

insieme di task è schedulabile

Un se esiste un algoritmo di scheduling che permette il rispetto di

tutte le deadline temporali. tipologie di scheduling:

È possibile distinguere diverse

Monoprocessore/Multiprocessore vedremo solo il caso monoprocessore;

à

Preemtion/No Preemtion vedremo solo il caso preemtion;

à

Off line l’ordine di esecuzione dei task è definito a priori: in memoria è già presente

à

l’ordine di esecuzione dei task.

In questo caso non viene definita la priorità di ogni task.

Automazione dei processi industriali M – modulo 4 Sistemi di controllo in tempo reale – Simone Benassi

  32  

On line l’istante di esecuzione di ogni task viene decisa istante per istante in base ai task

à

innescati e in base ad una priorità degli stessi da definire.

È possibile distinguere due tipologie di parametri, sui quali basare la definizione

delle priorità:

-statico parametri (priorità) stabiliti a priori; priorità dei task definite una

à volta per tutte;

-dinamico parametri (priorità) variabili durante l’esecuzione; priorità variabili

à nel tempo.

Attenzione perché Statico ≠ Off line.

Guaranteed schedulazione che rispetta tutte le deadline temporali dei task.

à

È un test di garanzia utilizzabile per i sistemi hard real time.

Utilizzato nella maggior parte dei casi con sistemi “hard real time”.

Best Effort si accetta un livello di prestazione in funzione delle deadline rispettate.

à

Si cerca ovviamente di schedulare al meglio possibile facendo considerazioni

medie, utilizzando algoritmi euristici.

Utilizzato nella maggior parte dei casi con sistemi “soft real time”.

task:

Prima di vedere alcuni tipici algoritmi di schedulazione, definiamo un

Generico task Ai:

a activation time richiesta di risoluzione di un problema.

à à

i

d deadline assoluta istante di tempo relativo al termine del time scope.

à à

i

s start time istante della messa in esecuzione.

à à

i

e end time istante di terminazione dell’esecuzione.

à à

i

C = e - s computation time intervallo di tempo necessario per risolvere il

à à

i i i problema: potrebbe essere suddiviso in più intervalli.

È un parametro definibile a priori.

D = d - a deadline relativa durata del time scope.

à à

i i i

R = e -